1. Un</br>able’s MySecretSecrets

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

3. 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

4. Obfuscation techniques
Manual obfuscation
JCuttlefish
Obfuscation techniques
What we did

5. 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

6. 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

7. 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

8. 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

9. Deobfuscation

10. 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.

11. 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

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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. Afterthoughts

19. 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

20. 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

21. Thank You