Gerben Javado – Recon Android apps to widen scope


Recon Android apps to widen the scope

Although it is the “normal” knowledge that works for the mobile app, I often talk to people who had been hunted for some time but did not include mobile applications in their tests. I am somewhat weird Because many more vulnerabilities were discovered through the inspection of the mobile app and rocket science was not detected. In this blog, in this way, I will try and provide a detailed but basic overview to test the Android app (although most of the methods also apply to iOS) and their use to widen the scope of their bug bounty program Do I.


Prior to decompressing the actual app, it is understandable to define the use of this device, hardware, and early techniques or those that you can use before. You have basically two options to run the app: I like to use my phone for an emulator or the reason for my own (roulette) phone compatibility, but I have an Android emulator Genymotion installed if I ever have my own An Android app is required on a laptop.

The second step is to make sure that the app (APK) file is installed on your device. Here you can install the app on the Google Play Store and browse to /data/app/{PACKAGE_NAME}/base.apk on your mobile device, you can get an APK or get it from an APK library like APKPure.

Once you have installed the app, make sure that your phone traffic through your proxy burp suit. Setting this up should be fairly easy using tutorial setup and tutorial certificate.

Using the app

Often one of the most important things is that you are proxying all the functions/actions that you can find in the mobile app via Burp, just as you would in a normal web app. The main point here is to find as much as possible. In my experienced companies almost always use different endpoint for their mobile app, which they do for their web app. Often mobile apps use API like structures, which contain less XSSes and other client-side vulnerabilities, but more server-side vulnerabilities like IDORs. There is no test for this stage, where you use the Burp.

If for some reason the app is not making a connection to the server or Burp is not holding any responses you are working with SSL pinning or non-HT traffic. My first advice is to try to see if any strange data reaching a port from the packet capture app is anything to 80 or 443 or those numbers (8443), then try to see it. If you are just looking at empty data on an https port (443), then you are working with SSL pinning. While I am not an expert in this trust, such as SSL TrustKiller and SSLUnpinning can help them get past (bypassing standard libraries). For more information read the detailed blog on bypassing certificate pinning by Patrik Fehrenbach.

Static analysis

Although I am not a protagonist in stable analysis, I have discovered some simple tricks, making it possible to get a lot from the mobile app code. Small code to read or (obfuscated) all without having to be able to walk through the huge block of Java code. It is also very useful if the app is doing SSL pinning because it is still a method to find endpoint using the app.

First of all, I decompile the APK file with both apktool and dex2jar and merge these files to keep everything in one folder together. After this, my rule is: Use the smiley code for tool analysis and java code to read content found in the smiley code. I’ll explain what I mean.

A method I like is using grep to find some finishing points in small code (also use grep to look for mystery or original proof). Here I navigate to the folder with the small code in the terminal and use the RegEx parameter to specify my search. The point here is that the mobile app is used in all the appointments (searched through Burp) and in order to find more events like this, it is to develop a RegEx. This can be as simple as \.json or http(s)?:// to find endpoints with a json extension or HTTP prefix. The command looks the following (exclude the h if you want the file names):

$ grep -hnrE "\.json" /Users/Gerben/smali/

You can easily find results from this order to find the files that are mentioned in the Z-GUI. Here you can find the parameters that are necessary to rebuild the full URL. These parameters should be quite clear if you want to read at least the programming language.






Three parameters plus the endpoint (feedback.json) in red boxes

One other method which I have recently adopted is using LinkFinder to find all the URLs in an app’s small code. About Linkfender takes about 20-40 seconds, however, all the small files are copied with random names in a folder (preventing overwriting) a little longer. Thus, Tom Hudson and I refuse the app to refute the one-line Has developed a script that copies the files into a subfolder and then runs the LinkFinder on these files (usually two thousand). It can be useful to delete folders with a small code that contain external libraries (e.g. /com/Google/*) to hide results that do not belong to your scope.

$ apktool d app.apk; cd app;mkdir collection; find . -name \*.smali -exec sh -c "cp {} collection/\$(head /dev/urandom | md5 | cut -d' ' -f1).smali" \;; -i 'collection/*.smali' -o cli

You will probably find a bunch of results. Use the RegEx option (-R) in LinkFinder to reduce the endpoints to narrow it down and list those lists that correspond to a certain pattern. Again, the same method applies here, in Java intervals try these ending points using JD-GUI. like:

$ -i 'collection/*.smali' -o cli -r '\.json'

Third, check after decompiling / property and / res / raw folders. Sometimes valuable files can be left here (source: Advanced Android Bug Bounty Skills – Ben Actis, this resource is very good for Android bugs, such as weak intentions).

Finally, comparing these methods between different versions of the app can help you gain an understanding of what was added in a new version. The new endpoint potential is unrecognized and may include new weaknesses.


Please enter your comment!
Please enter your name here