Android applications are bundled in a single file of type APK (Android Package).
They come with an apk suffix but are just ZIP files. If you modify the suffix you can extract their contents.
- Lib — A folder than contains native libraries (machine code). Since Android is cross-platform, it contains a subfolder for each supported processor like x86, x86_64, arm64-v8a, etc.
- Res — It’s a folder that contains resources but with a pre-defined folder hierarchy that the developer can’t modify. It usually contains files of multi-language support, screen orientation, and OS versions.
- Assets — Application resources in folder hierarchy controlled by the developer.
- Classes.dex — Google’s proprietary format for their version of the Java VM, it contains all Java/Kotlin code compiled to their specific bytecode called Dalvik. APK files may contain more than one classes.dex file, due to limitations of the DEX format. Additional files will be numbered (i.e. classes2.dex, classes3.dex and so forth).
- AndroidManifest.xml — A file that describes the application. It contains key information elements about the application like all package names, all application components, etc.
- META-INF — This is a folder that contains verification information. This is what is generated when “signing” the application. This is fingerprint information for every file contained within the APK. This means that any modification to the APK (even replacing an icon) requires resigning the APK, otherwise, the OS will reject the installation, When signing applications these files are updated.
- resources.arsc — A file that contains information that links the code (classes.dex) to the resources (res).
Hooking into the application:-
- Frida [https://frida.re/] -
We can hook into the application using Frida.
Frida-pa -Uai
Using the above command we can list all the apps/packages on our device.
To hook into any specific app we use
Frida -U -n ‘Google’
- Objection( is a runtime mobile exploration toolkit, powered by Frida, built to help you assess the security posture of your mobile applications, without needing a jailbreak.)~ https://github.com/sensepost/objection:
We can also use objection to hook into the application. the command for that is:-
objection — gadget com.android.chrome explore
Reverse Engineering the app:-
Here we want to read the source code of the app to find any hardcoded password or any critical information that should not be hardcoded on the client-side. Also, we try to understand the working and logic of the app that will help us to find vulnerabilities.
To decompile and understand the app we can go with JADX or JD_GUI
OR if we need to quickly modify and patch using the command line we can go ahead with apktool.
Now to get out the apk from emulator/smartphone to your system we use these commands:-
adb shell pm list packages {to list all the packages}
adb shell pm path <desired package name> {to know the path of the app}
Ex:- adb shell pm path com.android.chrome
adb pull /data/app/com.example.someapp-2.apk path/to/desired/destination {to pull apk to desired location}
APKTOOL:- Using this we can disassemble the application, modify the application’s logic and patch the application back and use it with the modified code. It gives us a smali code to work with
JADX:- Its apk decompiler shows us the whole app structure in the graphical user interface. With help of it, we can view the whole application and understand its business logic and various other implementation in a better way.
Traffic analysis:-
For analysis of traffic, we use tools like Burp Suite and OWASP ZAP.
We install the certificate on the device and we can look into traffic.
But apps using SDK greater than 24 then we just can’t install certificates and look into the traffic as it’s blocked by default.
This means user-installed certificates are ignored by default and we can’t intercept SSL traffic.
Now to bypass it:-
- Patch the application to trust the user installed certificates
- Place the user certificate in the system certificate folder
- Manipulate the application runtime.
Intercepting the application we can look at all data transmitted in the burp
Intercepting HTTPS traffic:-
In this scenario, we can notice even if we have installed the burp ca certificate still we are not able to intersect HTTPS traffic.
To handle this we will decompile the application using apktool and move it to androidmanifest.xml
We can notice that some network security has been implemented and the is defined in XML/network_security_config
Looking into that file
We can notice it is set to only trust system certificates.
Now here we can add another line to also trust user-defined certificates.
Now we just can’t install the newly built application as it’s not signed.
We use keytool to generate a new certificate. command:-
keytool -genkey -v -keystore rex.keystore -alias rock -keyalg RSA -keysize 2048 -validity 1000
Now we will use jarsigner to sign the apk. command:-
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore rex.keystore SecureStorev2_noroot.apk rock
After this, we can install the application and notice that now we can intercept HTTPS requests too.
Insecure Data Storage:-
Applications often store sensitive data on the client-side and while pentesting it’s worth testing for those locations.
Some of the common locations for storing data locally are:-
- Shared Preferences — it’s a way to store key-value pairs in XML format
- SQLite Database — our regular database
- Internal Storage -phone’s internal storage
- External Storage — SD cards
We can look around these locations if we can find any important information that might be exploited.
Server Side Vulnerability:-
These are more valuable compared to client-side vulnerability and most of the applications very often interact with the servers.
In the perspective of the android application, these vulnerabilities are mostly standard we can take examples from web app pentesting or REST API testing.
Client-Side Vulnerability:-
Many times developers store data locally without encryption.
Take an example of a vulnerable application.
Looking in the application directory we found a userdata.xml
Further looking we can see the user name and token associated with it.
Also, we can observe here that the token assigned to the user is the md5 hash of the username.
Here we can observe weak cryptography is used by the developer also as the tokens are static and md5 hash of username it might help users to login into someone else’s account. Just by editing the userdata.xml
Also if developers encrypt the database we can try SQL injection to get sensitive data for the application.
Android application components:-
- Activities — these are the screens we see in the application with dynamic functionality
- Services — they can do everything activities can do but it doesn’t have any UI and runs in the backend.
- Broadcast receiver — This help developer to show the broadcast made in the system in their application. For ex. is a charger is connected to a device it made a system-wide broadcast and the developer can set a listener and show a pop-up that the charger is connected.
- Content Providers — they are used to provide content from the database that is defined by the content provider to the applications. for ex. Contacts and SMS
These are the four key android components that we are concerned about.
Now looking at the AndroidManifest.xml file we can know about all the components used in the application.
Now if they are registered it doesn’t mean that they are exposed.
Whether a component is exported or not can be checked in two basic way either the component have defined export as the true or an intent filter is applied in that component.
If we found anything like that it’s worth looking and in an ideal situation we can user adb to start that activity by command:-
abd shell am -n <pacakage name>/.<activity name>
Hence, it’s always recommended to not export any crucial component in this way no other application can invoke it.
If an application allows its user to copy sensitive data to a clipboard it might be abused by another application running on the same device. So it’s always recommended not to allow users to copy sensitive data into the clipboard.
Bypassing Root Detection:-
Many applications have root detection enabled in them which means if the application finds that it’s working on a rooted device it will terminate the application and often we don’t have enough time to run any command or do anything.
So here the first step would be to do static analysis and figure out where all these checks are implemented.
After knowing it what we can do is to put the watch command in objection as soon as the application launches.
Command(to be used after objection is launched) :-
objection –gadget <packagename> explore
android hooking watch class <package name>.<activity name>
Android hooking list classes [this command will provide the information about which all classes are loaded]
To look at methods we can specify the list class_methods in the above command.
We can notice the method .isDeviceRooted is a boolean value and in this case returns as true. We need to return the value as false to bypass this detection.
To do that we will set its value as false using objection.
Command:-
android hooking set return_value <package name>.<class name>.<method name> <value to be set>
This command might work in some cases and might not in some cases because the method might be executed already.
Another option is to define the command while starting up the application with -s
Command (in emulator):-
objection –gadget <packagename> explore -s “android hooking set return_value <package name>.<class name>.<method name> <value to be set>”
Now if that doesn’t work we can use Frida for the same.
Here we use Frida to force open the application and it stays in the frozen stage (which means no code gets executed) until defined to resume.
We can use this feature of Frida and objection to set the isdevicerooted as false.
Commands:-
Terminal[1]:
Frida -U -f <package name>
Terminal[2]:
objection –gadget <packagename> explore -s “android hooking set return_value <package name>.<class name>.<method name> <value to be set>”
Terminal[1]:
%resume
Objection also has the option to disable root detection
android root disable and android root simulation
We can also try them out but they might not work.
End-to-End Encryption:-
If end-to-end encryption is implemented in an application it’s one of the major roadblocks in testing.
What happens in this
The message is encrypted using some custom or available methods and that encrypted message is again encrypted in base64. It means even if we catch transmission in burp we will only get the encrypted message that is encrypted in base64.
To handle this we need to have a deep understanding of the application and how it is encrypting and decrypting the data and we can write some custom Frida script to get the secret.
Ex:-
Bypassing SSL Pinning:-
- The first method is to use objection inbuild command to bypass.
After getting an objection shell we can use:
android sslpinning disable
- The second method installing the Burp CA certificate.
- The third method is writing a custom Frida script.
We need to analyze the application and made some scripts like this to suit our need
- The fourth method is patching the application. In this, we want to invoke the function that’s confirming the connection is secured immediately as the app is launched so that we can use burp to intercept the communications.
-Thank you
1nv3nt0r
<0_o>
[+] Part 0 of android pentesting :- https://1nv3nt0r.medium.com/baby-step-toward-android-app-penetration-testing-2b64d4e96f93
