Reverse engineering is a process of examining, analysing the structure, information and data being used by the software. We just don’t break software, we help our customers understand the risk of having information and details exposed. Let’s see how an android (.apk) file can be reverse engineered
Source code has it all, algorithms, API’s, Server configurations, Hint for the database, structure etc.
1. Dex2Jar (Dalvik executable to .jar)
2. JD-GUI (Java decompiler with Graphical user interface)
What are we going to investigate:
1. Investigate whether the app uses 9 patch images (Learn about 9 patch images here)
2. Source code encryption
3. 3rd party API’s and version (People don’t have a habit of updating the 3rd party API’s) – check the latest API’s here:
4. Pro-guard – Encryption tool for android apps.
Firstly, a brief about what APK is and what it consists off.
APK (Application package) and when any app is downloaded from play store, it would be stored as apk in the filesystem. The system files, resources and data are placed appropriately in the android system and executed when the app is used.
Get the apk of the app that you need to work on. There are several way that you can extract the apk. However, the simplest way is to download (APK extractor)
from play store and select the app to extract the apk and copy it to you local system.
Extract the apk. Use 7zip to extract the apk and place the folder to the place where it is easily accessible (We have real good habit of clicking “next” and don’t worry about any messages that software is try convey us)
To verify whether 9 Patch images are being used.
Open the extracted folder and you would find a folder named “res” (Resources)
Resources will have all the icons / images / Graphical elements. Here is an example.
Read about different image density, image resolution to be used here: Supporting different screen size
When 9 patch images are used, resources will contain 9 patch images (Folder) with few of the above folders eliminated.
9 Patch images can be recommended to decrease the size of the application and this is more helpful when we project the use of the resources by the competitors.
Android being open-source, there are several screen sizes and situations where 9 patch images might not work. Request technical team reason behind the 9 patch images not being used and if we could help them understand the effort, time and problem that could be solved using 9 patch images, boom! Value…
Android uses DVM (Dalvik virtual machine) to execute the program. When any android code is compiled, they create appropriate images for the system to detect and execute. While for the source code .dex (Dalvik executable) file will be created.
Check out some information here: Design and structure, code / wiki / other documentation
Please proceed with step 1 and 2.
When the extracted folder is opened, a DEX File has it all.
Copy the dex file, Open DEX 2 JAR place the .dex file into dex2jar folder.
Open command prompt:
Navigate directory to the dex2jar folder
Tip: Hold ctrl + shift and right click, you could open command prompt directly from the folder.
Enter the below command:
The decompiling has started and you would see success at the end. Now there are several scenarios it would fail (Example: The dex file may be huge with several classes of them may be encrypted or unlinked from the actual source). Please share the failures with me or google, we could fix it together.
Opening the .jar file.
A jar file with classes_dex2jar.jar will be created inside dex2jar folder.
It’s time to look at the source…
Open JD-GUI and just drag and drop the .jar file
You would see all the classes name and the source with the API’s thats being used and several information. Please dig more about the understanding the source.
Encrypted source: If the source is already encrypted, you would see “a, b, c, 1, 2, 3” as the main class names and subclasses, abstracts, public class would hit “A, b and c” or desired classes.
Hey wait, are we done? We got the source, should we just report them?
We could recommend a possible and available answer, Pro-guardwhich optimizes by removing unwanted code, obfuscates making it hard for someone to understand, shrinks by removing methods, fields and fuddles the code. It’s just few lines of code injection and crackers!
Verify third party APIs for the versions and other details.
The build properties may vary from SDK to SDK. For facebook, it’s just on the top most layer named, Facebook SDK version. It’s similar to most of the SDK’s.
The current facebook version can be verified with respective to what was being used. When we are recommending them to use the latest version, we would also be responsible for telling the stakeholders “Why”. We could just project the changelog or fixes for the latest facebook SDK version comparing it with previous one. Moreover, we don’t have to do it, we just have to copy paste the link in which the SDK’s are released.
Share your thoughts and we could discuss more about it. I will write more about testing android apps in the coming days.
Have a great day ahead!