Un</br>able’s MySecretSecrets

Overview MySecretSecrets Our obfuscation techniques Our deobfuscation techniques and the approach we took What we thought about the project

MyScretSecrets MySecretSecrets - a diary app which stores user entries consisting of an image and text Database tables implemented using SQL Lite User password stored in one table Diary entries stored in another Four main activities Welcome screen List of previous entries screen View previous entry screen Add new entry screen

Obfuscation techniques Manual obfuscation JCuttlefish Obfuscation techniques What we did

Manual Database Changes Change the lifetime of variable Only one table was used to store the password and diary entry data Names of the columns were changed (as could not be changed through automation) Change the lifetime of variable Local variables removed where possible and put in line Fields were used multiple time in different scopes (String variables changed values each time used) Read off slide lol

Manual Additional conditional statements Split up files Unreachable switch/if statements Double negation Numerical comparators Split up files Related functionality separated into multiple classes Dummy classes, methods and variables Had no actual functionality, used as distraction

JCuttleFish Originally an open-sourced Java obfuscator that changes file names, methods, local variables, and method parameters Missed a few occurrences of renamed classes (some did not get renamed) We built on the original tool to automate Layout file renaming String id/name renaming Removing comments and documentation Removing line breaks (although easily deobfuscated) Modified references were updated by storing changes in dictionaries, and iterating through the classes, layout files and manifest file. Occurrences were found using pattern matching

Limitations & Future Improvements Limitations mostly associated with the way Android code works Activities alway have onCreate() which cannot be overwritten and extend _Activity onCreate() made it obvious where activities began logic calls Not all logic could be moved to other classes in manual obfuscation JCuttlefish was a good basic obfuscation tool, not much flexibility Made it more difficult to further extend the tool After searching for decompilers, could have used techniques to prevent the common web decompilers from deobfuscating the our APK

Deobfuscation

Deobfuscation Techniques We split up the applications to deobfuscate among the group. We used two online tools to decompile and deobfuscate the APKs. We then identified the different techniques used by each group, and collaborated on how to break each one. This allowed each of us to figure out the logic of our respective applications.

Obfuscation Technique: Annotations Some groups made use of annotations to pass values into variables. Each variable was assigned fields through its annotations, which were outlined by a custom interface. While reading what values are passed in would appear to give away the true nature of the value, this could be intentionally misleading. To overcome this, we would analyse the interface and see what fields could be added with this annotation. Each variable could be considered to be an object with those fields. From Group 12

Obfuscation Technique: Wrapper Class Some groups made use of wrapper classes to hold values, rather than instance variables or fields. This takes the storage logic away from the code logic, and pairs well with other techniques to make the code more confusing. This can be identified by looking for objects that have a long constructor, or a lot of assignments to their fields. This can be deobfuscated by returning the fields of the class into the calling class as fields or instance variables.

Obfuscation Technique: Rename view id Call numerical ID of view instead of using R.id.viewName to call a view Makes it more difficult to figure out which view is being called. So harder to understand flow of project This can be de-obfuscated by finding findViewByID() and replacing the numerical ID with the r.id.viewName value.

Obfuscation Technique: Rename variables, methods & classes This technique was implemented by most groups and makes it difficult to read at a glance. The purpose of these attributes are obscured, especially when given names that are hard to remember. Can be deobfuscated by renaming all occurrences of variables through an IDE. The code first needs to be understood, for meaningful renaming to be done.

Obfuscation Technique: Dummy variables, methods & classes Dummy attributes make code harder to understand, especially when assigned random names. It might be difficult to keep track of which pieces of code are relevant. Deobfuscated using IDEs such as IntelliJ to tell if variables are never used or methods are never called.

Obfuscation Technique: Complex Conditional Statements Typically long chains of if statements with break conditions. Some conditions always evaluate to the same value. IDEs used to identify unreachable code and dead code. It can also be used to find all usages of variables to determine if the variable will always have a certain value before it’s checked in a conditional statement.

Obfuscation Technique: HashMaps Group five used hashmaps to store each variable type. Each variable is a key- value pair in the hashmap. This makes it harder to identify variables. Deobfuscated by renaming hashmaps to the variable types that they store and renaming the keys to better reflect the variable’s purpose.

Afterthoughts

Afterthoughts Strong obfuscation is more difficult than expected Hard to extend automated tool to cater for all files in Android applications Manual intervention was needed to solve issues after files passed through the tool Presence of existing tools that reverse common obfuscation techniques in apps show the need of stronger obfuscation It is simple to detect the commonly used techniques in other applications Lower-level obfuscation was more effective Harder to understand More difficult to decompile Hard to find supporting tools found to assist reverse engineering

Afterthoughts cont. Clear to see why there a need for well obfuscated applications As a result of reverse engineering More aware of threats to software Encourage us to develop more secure applications

Thank You