A Self-Compiling Android Data Obfuscation Tool · DELFT UNIVERSITY OF TECHNOLOGY STUDENT PROJECT 1 A Self-Compiling Android Data Obfuscation Tool Olivier Hokke, Alex Kolpa, Joris

DELFT UNIVERSITY OF TECHNOLOGY STUDENT PROJECT 1

A Self-Compiling Android Data Obfuscation ToolOlivier Hokke, Alex Kolpa, Joris van den Oever, Alex Walterbos, and Johan Pouwelse (Course supervisor)

Abstract—Smartphones are becoming more significant in storing and transferring data. However, techniques ensuring this data isnot compromised after a confiscation of the device are not readily available. DroidStealth is an open source Android applicationwhich combines data encryption and application obfuscation techniques to provide users with a way to securely hide content on theirsmartphones. This includes hiding the application’s default launch methods and providing methods such as dial-to-launch or invisiblelaunch buttons. A novel technique provided by DroidStealth is the ability to transform its appearance to be able to hide in plain sight ondevices. To achieve this, it uses self-compilation, without requiring any special permissions. This Two-Layer protection aims to protectthe user and its data from casual search in various situations.

Index Terms—casual search, privacy, nomadic software, data obfuscation, data encryption

F

1 INTRODUCTION

Using encryption technology on your smartphone mayraise suspicion. We present a tool which goes beyondencrypting sensitive data: It obfuscates the data, anditself.

There are over 1.5 billion smartphone users all over theworld[1], and over 80% of the population in developednations have mobile broadband subscriptions [2]. A largepercentage of this population captures their daily lifeon their phone. For many, a large part of this data ispersonal and is something they want to keep private.

A large part of the Android security model is builtaround preventing attackers from unlocking the device.Once unlocked, either through forceful user cooperationor other means, a large part of the data becomes acces-sible. This gives a reason to actively encrypt and hidedata from watchful eyes.

One such situation arose during the Arab Spring.It became clear that such sensitive data, stored onsmartphones, can have a significant impact [3]. Smart-phone users provided on-the-ground information of theprotests and government reactions through various so-cial media platforms. As such, these platforms get closelymonitored or even blocked by some governments [4].Because of this, spreading content directly from phone tophone has become a popular approach in places whereconventional platforms are either locked down or un-der close surveillance. However, this means that peoplecarry sensitive material with them, posing the risk thatthe data will still be compromised. Governments suchas Iran have even ordered citizens to hand over theirdevices and log in on their accounts [5].

It is obviously a necessity to be able to hide datauntil it can be shared in a safe manner. In this paperwe will explore data hiding on smartphones and presentDroidStealth, a solution aiming to protect against casualsmartphone searches.

2 PROBLEM DESCRIPTION

As described, there is a need for a tool to hide sensi-tive data, where encryption alone does not suffice. Tounderstand and properly describe the problem we havestudied the variables involved, and defined them below.

2.1 Audience

The audience of the application is broadly defined.DroidStealth’s inspiration originates from the ‘citizenjournalism’[6] that played a significant role in the ArabSpring. Based on this, people dealing with an oppressivesociety was chosen as a worst case scenario. Howeveranyone interested in hiding and securing data on theirdevice is part of the target audience for this application.

2.2 Casual Search

We aim to protect against casual search. In the scopeof this article, we define ‘casual search’ as follows: "Aquick attempt to find information on a mobile devicewithout applying advanced technical knowledge of thedevice, nor specific knowledge of the protecting methodsproposed and implemented as described in this article".Someone applying a casual search will be called a casualinspector, or casual searcher. This reasoning also assumesthat casual search is the most used search method: A‘quick glance’ through a mobile device is more likelyto occur than a thorough investigation of the device bysomeone who is experienced and trained where to look.This would be time consuming and hard to manage ona larger scale.

2.3 Beyond Simple Encryption

An obvious solution to keep data safe from inspectionby the wrong audience is encrypting the data. Using asecure encryption has two useful properties: First, thedata would become inaccessible to any inspector. Sec-ond, the encryption would render the files unreadable

arX

iv:1

502.

0162

5v1

[cs

.CR

] 5

Feb

201

5

DELFT UNIVERSITY OF TECHNOLOGY STUDENT PROJECT 2

and unrecognizable to a human inspector, thus makingthem less incriminating.

However, finding inaccessible data can be a reasonto extend a casual search with more intensive searchmethods, in which case the data might be compromisedafter all. The same applies to the application that holdsthe data; any restriction to opening an application canbe seen as suspicious. To address both issues, the appli-cation should not only obfuscate the data, but the toolitself as well.

In this article, we will use the term ‘locked data’to refer to encrypted, inaccessible data. With ‘lockedapplication’ we mean the application with its accessrestriction, as we will explain in Section 3.

2.4 Root PermissionsWe assume that users do not have root access on theirphones. ‘Rooting’ an Android device unlocks admin-istrative privileges, allowing the user or applicationsto access restricted files, and communicate with devicefeatures more directly. By doing this, it underminesAndroid’s security model[7].

It can be compared with root access as in Unix sys-tems, and Administrator privileges in Windows systems.Because ‘root access’ allows manipulating system files,it provides more powerful tools that could benefit thesolution to the problem addressed.

Enabling root access is a technical challenge, and hassignificant disadvantages for the user. Therefore, Droid-Stealth does not require root access, and is thereforerestricted from using its privileges.

2.5 Spreading the application without a central appstoreIn situations where a central distributor of applications,app store, is monitored and censored distribution of theapplication can prove difficult. These stores can easilybe inspected for installed applications, for which thereis no way of circumventing, since it is the primaryway to distribute these applications. A simple search inAndroid’s Play Store would be sufficient to expose thepresence of the application, a risk many users wouldnot be willing to take. Not placing DroidStealth inthe Play Store would prevent this problem, but makesdistributing the application difficult.

A way of circumventing this limitation on distributionwould be a ‘nomadic’ distribution method for the appli-cation. Instead of providing the application through acentral point that can be monitored, the users should beable to share it directly with those interested.

2.6 Data Type RestrictionsThe sensitive data that the user wants to keep safe cantake many forms. The data managed in DroidStealthwill likely consist mostly of photos and videos, withthe occasional document. However, we cannot predict

exactly what data the user would want to hide in theapplication. Therefore, the application should supportthe file types that the device could normally handle,since we do not want to restrict the user to certain filetypes.

3 APPROACH

Our solution combines password encryption and hidingof the DroidStealth tool itself.

3.1 Password encryptionThe first layer of protection offered by DroidStealth isaccess restriction. This restriction consists of two parts,one for the data itself and one for the application.

All data within DroidStealth is encrypted by default.When the user adds a file to be managed by the ap-plication, it is automatically removed from its originallocation, encrypted, and added to a dedicated datafolder. This way, the data cannot be accessed by anotherapplication, and restricts users to opening these filesexclusively through DroidStealth. Even when the userwants to open an arbitrary file managed by DroidStealth,the conscious step of decrypting the file must be madefirst, raising awareness of the risk of exposure.

Every launch of the application requires the user toenter a pin code, which the user defines the first timeDroidStealth is opened. Only by entering this pin codeupon launch can the user access the files managed byDroidStealth. Should it be forgotten, the data in theapplication will remain encrypted forever.

3.2 Hiding of DroidStealthFinding encrypted and inaccessible data or applicationscan raise suspicion towards the user. Since simply en-crypting the data is not enough, our approach providesan added step of obfuscation that increases securityof the data: DroidStealth hides itself. This combinationprovides the two-layered protection, which is the keysolution implemented in DroidStealth.

With the purpose of hiding all incriminating aspectsof the encrypted data, we apply two ways of hid-ing DroidStealth on the device: Providing alternativelaunching methods, and ‘hiding the application in plainsight’ by changing DroidStealth’s appearance. The firstis employed if the user wants to hide DroidStealthfrom easy access on Android devices, while changing itsappearance allows for easy access as well as protectionfrom casual search.

3.2.1 Alternative Launch MethodsThe default way of launching an application on an An-droid device is through the ‘app drawer’. This overviewof all installed applications would normally show theDroidStealth logo, and provide a way of opening it. Theapplication would then be visible to anyone browsingthe app drawer, including a casual inspector.

DELFT UNIVERSITY OF TECHNOLOGY STUDENT PROJECT 3

It is possible to hide the application from this drawer,but the user still needs to be able to launch DroidStealthwhen it is hidden. For this, we have implemented twoalternative launching methods, which can be enabled bythe user in the application.

Dialer Launch DroidStealth provides a launch optionthat opens the application by dialing a user-definednumeric sequence. The user enters this numeric sequencein the any regular phone number dialing application, asit would with a phone number. Instead of actually callingthe number, the application launches, requesting the pincode. Furthermore, DroidStealth fully intercepts the call,making sure the number never gets added to the calllog.

Transparent Widget Another option is to launch theapp by means of an invisible widget on the device’shome screen. This widget takes the form of a transparentarea, thus showing the background image, positionedon the home screen by the user. When the widgetarea is tapped once or twice, it remains inactive andsimply appears to be an empty area. However, whenthe widget is tapped five times consecutively, it launchesDroidStealth.

When first created, this widget is temporarily visible,to help the user in placing it and to remember thelocation of the widget. After the first time the widget istapped, it becomes transparent. A comparison of thesetwo states of the widget is shown in figure 1.

When adding a new access widget, all previouslyplaced widgets become visible. This allows the user toretrieve forgotten widgets.

3.2.2 Morphing: Mimicking Other ApplicationsDroidStealth is capable of transforming itself, changingthe application’s icon and name. DroidStealth can thencreate an Android Application Package from which theapplication can be (re-)installed with the new appear-ance. When composing its new appearance, DroidStealthprovides all installed applications on the device. Theuser can therefore both supply its own name and icon,but it can also select an application it wants to mimic.

With the newly acquired appearance, DroidStealthdoes not need to be hidden from the app drawer andno secret launch methods are required. This way, theintuitive ‘default’ launching method is retained, whileDroidStealth is still hidden from a casual inspector.

3.3 DistributionAs mentioned in Section 2.5, having DroidStealth in acentralized store would result in a possible exposurethreat. For this reason, it was decided to let DroidStealthdistribute itself nomadically. This does introduce someproblems, most prominently the fact that users now needto enable ‘side-loading’. Side-loading means enabling theinstalling of ‘untrustworthy’ applications which camefrom outside the Android Play Store. While this is aminor inconvenience, it was deemed less important thatthe visibility that comes from being in the Play Store.

Figure 1. A screenshot of the Android home screencontaining a visible (top half) and an invisible (bottomhalf) DroidStealth Launch widget over a star-ridden back-ground image.

4 IMPLEMENTATION

This section diverges on the technical details of theimplementation of DroidStealth. It explains our solu-tions to challenges we encountered in the morphingand encryption. Challenges and implementation deci-sions regarding the user experience are discussed, andfinally an analysis of the vulnerabilities of DroidStealthis addressed.

4.1 Morphing

As described in section 3, to hide the application someway is needed to alter the appearance of the applicationso that it can be hidden from casual search. To achievea complete change of appearance for an applicationin the app drawer, both its icon and its name needto be changed. However, to explain the full approach,some background on the inner workings of Androidapplication packages might be required.

Android uses its own naming for its packages, socalled Android Packages, or ‘.apk’ files. In reality, thesefiles are very similar to Java archives – so called ‘.jar’files – namely that they are both archives containingbinaries and resources. To construct an apk file, one firstneeds the Dalvik binaries and the resources (images,

DELFT UNIVERSITY OF TECHNOLOGY STUDENT PROJECT 4

animations and layouts among other things), whichcan then be compressed into an archive. Optionally,the archive can be zipaligned, which improves its readperformance by reordering the contents of the packageas to optimize it for Android devices. Once the archivehas been constructed, it only needs to be signed with anappropriate key for the Android system to accept it as avalid package.

For the morphing to be successful, this process neededto be reversed, and then repeated after altering thearchive resources. For this, the original package is re-quired. Fortunately, Android allows access to the originalpackage from within the application without root access(see section 2 for an explanation about what root accessmeans). Reversing of the package construction process,extraction of the files, can be achieved through normalzip extraction, something which is included by defaultin the Java version used for Android. Once the files havebeen extracted, the application resources can be altered.Due to the engineering effort of fully recompiling thebinaries on an Android device, only support for initialself-compiling of the package was implemented. Furtherself-compilation, namely the decompilation, editing, andrecompiling of the Dalvik binaries was considered be-yond the scope of this work.

As explained earlier, both the application icon and theapplication name need to be altered to have a successfulmorphed application. To alter the icons, first the originalicon name that is stored in the resources is extracted fromthe application info, something which Android providesthrough its API. Then it is a matter of iterating overthe extracted content to find the appropriate icon files– Android allows for multiple resolutions of the sameimage to be stored – and replace them with the user spec-ified icon. Once the icons have been replaced, the nameof the application needs to be changed. Unfortunately,this is where the first restriction imposed by Android isencountered.

Android uses a resource map where each resourceitem gets mapped to a unique id generated by thecompiler, which allows for easy re-use of resources inthe making of an application. This does pose an obstacle,since these reference maps are compiled into a binaryformat which is difficult to alter. There is a solutionavailable for desktop environments[8], but it relies onAndroid’s Package Tool, ‘AAPT’. Porting AAPT to An-droid proved to be near impossible due to its system re-quirements, which meant that decompiling the Androidresources would not be a feasible approach. Fortunately,the name of the application is accessed through a fileknown as the Android Manifest, which contains generalinformation about the application package. This manifestproved to be slightly more process-able from withinthe confinements of Android. This meant that the newapplication name could be put directly into the manifest,without having to rely on the decompiling of Androidresources. After these two steps of altering the applica-tion appearance, the contents can be reconstructed again

into a valid Android Package.The first step is rebuilding the archive. Since it is

structurally the same as a Java Archive, existing toolscould be used. For this, the JarBuilder by DominikWerthmueller[9] was used, since it posed the leastamount of dependencies, which is favorable when work-ing with Android, which can be rather picky about whatparts of Java are actually supported in its system. Thisresulted in a complete archive, which still needed to bezipaligned and signed with an appropriate key. Becauseof similar restrictions posed by the decompiling of theAndroid resources, it was decided that including zipalignment was not achievable for now.

Finally, the package needs to be signed. Fortunately,an existing standalone solution is available outsidethe default Android signing methods, the ‘zip-signer’library[10]. However, a signing key still needs to bechosen. For the scope of this project, it was decided thetest key would be sufficient, since actually signing it withappropriate keys which would needed to be tracked toprevent falsification of the application provide severalchallenges which will be discussed in section 5.2.

Once the archive has been signed the morphing hasbeen completed. The user can now be presented with anapplication package which contains the original appli-cation, albeit with a new appearance, according to theuser’s preferences. This application can then be sharedwith other users.

4.2 The Encryption ServiceDroidStealth uses a ‘Service’1 for the encryption of files.This service runs in the background, and listens forIntents started by the application. A queue is usedto order the requests, and the service running in thebackgrounds works through the queue continuously.

The encryption that DroidStealth provides is imple-mented using Facebook’s Conceal API[11]. Conceal pro-vides a set of APIs for data encryption and authentica-tion; we only use the first. The Conceal library does notimplement cryptography algorithms, but instead usesalgorithms used in OpenSSL[12].

Files are encrypted individually. When encryptionwould be applied at folder level, the application wouldhave to decrypt all data upon being opened. Not onlydoes this expose all data during the user’s interactionwith (most likely) only one of the files; but if the userwould then forget to lock the data, all data managedby DroidStealth would remain exposed. By applyingper-file encryption, the risk of exposure is kept to aminimum. Only loading files when needed also meansan increase in startup time, as it is not necessary todecrypt the entire folder.

The process of encrypting an unencrypted file is quitesimple because of the use of the Conceal API: TheCrypto class, provided by the Conceal API, handles

1. An Android Service is a part of an application that runs in thebackground, often used for more intensive or lengthy executions.

DELFT UNIVERSITY OF TECHNOLOGY STUDENT PROJECT 5

all encryption logic in the process. A ‘plain’ Java inputstream is created from the unencrypted file, and theCrypto class provides an output stream that encryptsdata as it is being passed through. When both streamshave been created, a dedicated algorithm copies the data,buffered in chunks of 4096 bytes, from the unencryptedfile’s input stream to the encrypting output stream. Thefinal result is, as expected, the encrypted version of thepreviously unencrypted file. The decryption process usesthe exact opposite method: An input stream providedby the Crypto class provides the decryption logic, bywhich the encrypted file is read. The output of thatstream is passed to a plain Java output stream, whichwrites the data to a new, unencrypted file.

The files are then stored in a folder outside the appli-cation folder. To allow the updating of the applicationwithout data loss, this separation is required; overwrit-ing the application folder may be required, especiallywhen installing a morphed version of DroidStealth. Thismeans that the folder storing the files is public; otherapplications, as well as the user, can find it on theirdevice via a computer or with a file explorer app. Therisk posed by this is migitated by the encryption of thefiles, as well as the requirement to know of DroidStealth,transcending the scope of ‘casual search’.

We see the above morphing procedure as the firstminimal form of self-compilation for an application.

4.3 User ExperienceWithin this subsection we will elaborate on our designchoices in user experience design related to locking andhiding of both data and the app. We also briefly discussthe philosophy behind the styling.

Once the application has been opened, the user caninteract with the files managed by DroidStealth. Destroy-ing an encrypted file is allowed, but opening and export-ing/sharing files is not; the user will have to decryptthem first. This extra step is part of the interaction tomake the user aware that the files are then decrypted.

To add to this awareness, a warning is shown to theuser, explaining that some files are unlocked and posean exposure risk. This warning is shown as a persistentnotification in the notification drawer of the Androiddevice (see Figure 3. When the notification is pressed,all unlocked files are immediately locked. This providesa user friendly way to swiftly encrypt the files so theycannot be found, without the need to reopen the app.

Figure 3. A non-disclosing notification to remind the userto lock accessible files.

Depending on the file size, encrypting or decryptinga file could take up to several minutes. During thisprocess, a notification which informs the user of the

Figure 2. The content gallery showing files in locked(green), unlocked (red) and currently processed (yellow)files. The upper-left corner shows the notification iconsinforming the user that files are being processed, and thatother files are unlocked, respec

encryption or decryption process. Once the user taps onit, the encryption or decryption is canceled by emptyingthe queue and finishing the current task.

4.3.1 Launching DroidStealth

The trivial, default way of launching DroidStealth isthrough the app drawer of an Android device. Whenlaunching the application the first time, the user isprompted to enter a pin that will be used to accessthe application. On following launches, the app willpresent the user with a numeric keyboard to enter itspin code (see Figure 4 . If the pin is entered correctly,the DroidStealth will launch into the content gallery, asshown in Figure 2. This pin code is required to openthe application trough any launch method. If the userforgets the pin code, the data in the application willremain encrypted forever.

DELFT UNIVERSITY OF TECHNOLOGY STUDENT PROJECT 6

Figure 4. The numerical keyboard presented to the userupon launching DroidStealth.

Alternative Launch Methods As explained in Sec-tion 3, DroidStealth provides alternative launch meth-ods. The application provides a ‘Launch Menu’ wherelaunch methods can be enabled and disabled. To protectthe user from not being able to open the application, atleast one launch method must be enabled at all times.

When the user adds a DroidStealth launch widget tothe device’s home screen, the new widget and all existingwidgets are made temporarily visible. This helps the userto place the new widget, as well as retrieve existing (lost)widget locations. Touching any of the widgets will makeall of them transparent again, and therefore invisibleto the human eye. From that point on, when the userpresses the invisible widget 5 times, the app is launched,showing the pin keyboard.

4.4 Styling

DroidStealth is themed with a dark color in order to giveusers the feeling that they are indeed working in secret,and that their data will be safely hidden. To give Droid-Stealth a professional ambience, we used a rounded butsolid straight font for our titles, and a formal font forall other texts. Combining this with the use of bright,but slightly softened primary and secondary colors, theuser is provided with a balanced and consistent userinterface.

The use of green and red is mirrored from the con-ventional meaning of those colors. Green will always beused to indicate that something is good or safe, red willdo the opposite. Furthermore, we use the color orangewhen indicating a process is being executed. Whenevera file is locking, or unlocking, the status bar of the filewill be orange, and a animated twirl is shown to indicatethat the file is being processed.

Finally, the gallery uses no padding or margins be-tween the thumbnails of files, as we want to optimallymake use of all the screen space. Thumbnails are thusas big as they can be, and thus will be most efficient inshowing the user its contents.

4.5 Vulnerability AnalysisDroidStealth has some vulnerabilities, which are ana-lyzed here. Per vulnerability, we explain how it posesa risk, how big the risk is, and if applicable how thiscould be solved.

4.5.1 Unlocked FilesA potential security threat that can be exploited, is thatunlocked files are stored on the internal SD card of thedevice, and that another app could constantly watch thefolders in which those files would be decrypted. Thenthis other app could save them somewhere else or sendthem over the Internet.

Also, if files are unlocked, and the user’s device istaken from its rightful owner without warning, then theuser might not have gotten enough time to press thenotifications to swiftly lock the secret files back. Invaderswon’t be able to see the data directly, unless they launcha file browser and start searching, but they would beinformed of the existence of secret files. This could be apotential danger, because an attacker could be interestedin those files and do the user harm to get these files.Users should be fully aware that they should only unlockfiles if they are 100% sure that they are in a safe location.

4.5.2 Application visibilityWhile it’s possible to hide DroidStealth from the appdrawer, or even change its appearance, there are stillseveral ways its presence can be determined. The mostdirect one would be to access the list of installed ap-plications through the device settings. While it mighttake an attacker some time if DroidStealth is morphed, itwould be possible to use this list to discover it throughits package name, which doesn’t change at this point.

More thorough search would make use of the ‘adb’tool, which can be used to communicate with authorizedAndroid devices. For this, enabling ‘USB Debugging’ inAndroid’s settings, physically connecting the device to acomputer and allowing it access to the device is needed.While this is be a possible scenario, it makes severalchanges to the security settings of the device (allowingexternal devices to access it), meaning it is consideredout of the scope of ‘casual search’ for this work.

4.6 Spreading DroidStealthAs expressed in the section 2, the application should beable to be spread nomadically. This means there is nocentral distribution point, but users share the applicationbetween each other.

Spreading the application is possible through a mul-titude of ways on Android, via all standard file sharing

DELFT UNIVERSITY OF TECHNOLOGY STUDENT PROJECT 7

methods. These methods include sending the applicationpackage through, for example, email, MMS, and Blue-Tooth. DroidStealth also supports sharing via a morerecently provided feature called Near Field Communi-cation (NFC)[13]. When available on the device, it usesAndroid’s NFC sharing feature called Android Beam totransfer the application to another device when it is heldadjacent to the sending device.

These spreading methods allow the users to shareDroidStealth directly from device to device, eliminatinga central distribution point.

4.7 Open Source

This application was written as an open source project.The code can be found on GitHub[14], and may beused under terms of the licenses provided there. Thesource code of this application is provided, as well as aseparately usable library that can be used to include themorphing feature into another Android application.

5 CONCLUSION AND FUTURE WORK

DroidStealth beats casual search by combining encryp-tion and the tool‘s self-obfuscating approach.

There are several aspects of the application that canbe improved. Which can be categorized under one ofthe following: usability, and morphing. The categorieswill be discussed individually as they are separated bothtechnically and conceptually.

5.1 Usability

In terms of usability there has been no formal studyon what aspects of the application work work well.However, informal testing has shown several avenuesof improvement.

The testing has shown that the alternative launchmethods could use closer attention when it comes to theusability. The counter-intuitive approaches to launchingDroidStealth can be confusing. There is also a risk thatthe methods, or the codes are forgotten when the useronly sporadically opens the app; This would render thedata managed by the application lost forever.

With the providing of alternative access methods,easier access is provided to both the users and possibleattackers. The invisible widget that is provided is easilyfound in the widget list, though it is made more complexto detect when used in combination with a morphedDroidStealth. The dialer launcher poses a risk when auser fills in the wrong launch code, as the entry won’tbe removed from the call log, and thus an attacked couldbe hinted towards the right pin. Also, if a user had mademore mistakes, the attacker could merge the suspiciouscall log entries, and deduct the correct pin. A possiblesolution would be to check the call log for entries thatare similar to the actual one, and to remove those as well.Future work could address this issue with a solution that

creates a more usable alternative launch method, whilemaintaining the security of the application.

Once the application has been launched, the useris required to pay close attention to the state of theapplication, and the state of the files managed by it.A small human error can result in inadvertent databreaches, especially when the data in the application isopened in other apps.

Monitoring the application’s life-cycle more closelycould resolve some of these issues: For example, ‘listen-ing’ to home button presses could be used to triggerthe locking of files automatically whenever the app getsout of focus. Another solution that has been discussedis limiting the time during which a file may be un-locked, which could restore the encryption after a (user-)designated duration.

5.2 MorphingThe basic features of the morphing library have beenimplemented, however it is not without limitations. Twoareas of improvement have been identified, namely apprenaming restrictions and the lack of integrity verifica-tion.

Application names applied in the morphing processhave to be the same length or shorter than the nameoriginally given to the application. Preliminary researchindicates that this limitation can be overcome but not alldetails of packaged Android manifests have been reverseengineered. Alternatively increased support for self-compilation could remove this limitation, as it wouldallow all details of the manifest to be changed as it wouldbe done prior to compilation.

Integrity validation is not included in morphing. Withintegrity validation we mean that the actual code itselfis not modified to change the behaviour of DroidStealth,for example introducing a backdoor. Normally this issomething that the Android package system takes careof, but morphing has unique demands that makes itimpossible to rely on built-in measures. These measuresrely on using a private key for signing the code, howeverto allow updating for the application after morphing theprivate key has to be bundled with the software so itcan be signed again. With access to this key anyone cancreate a modified version of the morphed applicationand spread that as an ‘update’. Solving this problem isnon-trivial and requires more research.

Other future work on the morphing, as mentionedin Section 4.1, would be a fully self-compiling system.Getting this to work would mean at least porting the‘aapt’ and ‘dex’ tools provided by Google for construc-tion of packages and binaries. Using existing systemson desktops, like ApkTool [8], should provide a goodstarting point for anyone interested in continuing thiswork.

5.3 Re-installing the applicationWhen the application is re-installed from, for example,a morphed android application package, the encryption

DELFT UNIVERSITY OF TECHNOLOGY STUDENT PROJECT 8

key used to lock data is replaced. This means that thedata locked before the re-installation is impossible todecrypt; a significant limitation in the usability.

A method of deriving a key that is consistent throughre-installing the application is required, while it remainsunderivable for external parties.

REFERENCES[1] “Smartphone users worldwide will total 1.75 billion in

2014.” [Online]. Available: www.emarketer.com/Article/Smartphone-Users-Worldwide-Will-Total-175-Billion-2014/1010536

[2] “Statistics - international telecommunication union.” [Online].Available: www.itu.int/en/ITU-D/Statistics/Pages/stat/default.aspx

[3] “Smartphones in the arab spring.” [Online]. Available: www.academia.edu/1911044/Smartphones_in_the_Arab_Spring

[4] “Twitter revolutions and cyber crackdowns.” [On-line]. Available: www.apc.org/en/system/files/AlexComninos_MobileInternet.pdf

[5] “Iranian crackdown goes global.” [Online]. Available: http://www.wsj.com/articles/SB125978649644673331

[6] M. J. Duffy, “Smartphones in the arab spring,” International PressInstitute’s 2011 report, 2011.

[7] T. Vidas, D. Votipka, and N. Christin, “All your droid are belongto us: A survey of current android attacks.” in WOOT, 2011, pp.81–90.

[8] [email protected], “Apktool.” [Online]. Available: https://code.google.com/p/android-apktool/

[9] D. Werthmueller, “Jarbuilder.” [Online]. Available: http://sourceforge.net/projects/jarbuild/

[10] kellinwood, “Zipsigner.” [Online]. Available: https://code.google.com/p/zip-signer/

[11] “Facebook conceal, a cryptographics library.” [Online]. Available:https://facebook.github.io/conceal/

[12] “Openssl.” [Online]. Available: www.openssl.org[13] N. Forum, “Nfc forum technical specifications.” [Online].

Available: http://members.nfc-forum.org/specs/spec_list/[14] “Droidstealth and droidmorph source code.” [Online]. Available:

https://github.com/droid-stealth/droidstealth