Android Pentesting 101 — Part 2 - Pentestmag

Android Pentesting 101 — Part 2

Android Pentesting 101 — Part 2

by Vaibhav Lakhani and Dhir Parmar


Welcome to Part 2 of Android Pentesting. This series is about how you can hack into Android and find vulnerabilities in it using various methods. If you haven't read part 1, I would highly recommend you please read it before jumping to this section. You can find it over here.

In the second part, we aim to cover the Static Analysis of Android Pentesting, along with various tools. So let's do this !!

So Static Analysis in Android Pentesting is all about reviewing the source code and finding the vulnerabilities, and how can you do that?? The first step is to get the APK file. Well, it’s simple, find an Android Application first and download the APK file on your phone.

Once you have downloaded the APK, use APK Extractor to extract the APK file and then send it to your PC for further analysis. Simultaneously you can also pull it using ADB. The following are the commands for the same:

  1. Grab the package name using adb shell pm list packages -f | grep app_name
  2. Grab the path using the package name obtained above adb shell pm path com.package_name.
  3. Pull the apk using adb pull /data/app/com.package_name..apk

Alternatively, you can use PlaystoreDownloader to download the APK files as well. The next step is to reverse engineer the code. In Part 1 we have already seen how Java Source Code is converted to the APK file, we simply have to reverse the entire procedure so that we get readable files. To perform this:

  1. Extract the APK file using WinRar or a similar tool. (If not extractable convert the apk file to ZIP first that is MyApp.zip)
  2. Once extracted, we get the AndroidManifest.xml file and certain DEX Codes. We have to reverse these DEX Codes. This can be easily done using the command d2j-dex2jar -f classes.dex
  3. The JD-GUI tool can now interpret the jar file and we get to see the source code of the APK file clearly.

Perfect Now it's time for all the manual Analysis. In a general case scenario, the following are checked in Static Analysis

  1. Check if App is Debuggable
  2. Check if any exported activity is true (If yes exploit it using drozer)
  3. Check for typographic errors in custom permissions in AndroidManifest.xml file. A similar test case can be found here
  4. Check for hardcoded API Keys, Comments, Secrets, etc. A similar test case can be found here.
  5. Check for exported broadcast behavior.

Manual testing can sometimes be boring, and hence to speed up the process we have 2 beautiful tools that can help you out:

  1. MobSF: It is an automated malware analysis tool that will help you to speed up your process of Static Analysis. It can be easily downloaded. Let's have a quick look at it.

The first step is to download the APK using various methods as seen above, and then upload the APK to MobSF.

In the screenshot below, you will be able to see about all the Application Details.

The next screen shows about all the activities, services, receivers, providers, etc. You can even view the AndroidManifest.xml file as well and the Source Code and Smali code as well.

You can view all the Security Analysis, Malware Analysis, Code Analysis, File Analysis etc. one by one. A screenshot of the same can be seen below.

You can even print the PDF report for the Static Analysis.

2. BeVigil: The world’s first and only security search engine for mobile applications developed by CloudSek. Personally, I love this particular tool more because it's quite simple to use and you can provide a direct link to the PlayStore URL.

Over here you can view the security score, all the total detected issues, and their description. Let’s take a random example:

  1. If you can see this particular application accepts all SSL certificates, which means that in Dynamic analysis, we do not have to bypass SSL Pinning, and thus we can try to report this vulnerability.
  2. On further analysis we found that some Google API keys were also leaked.

3. We were also able to see that Non parameterized queries were also written which allows an attacker to perform SQL Injection

And so on all of the static files can be analyzed.

That’s all folks for Part Two! We hope that you enjoyed this article! We will be back with another part soon, where we will show you’ll the methodology of Dynamic Analysis while performing Android Pentesting.

Happy Hunting!

Authors:

Vaibhav Lakhani: Twitter, LinkedIn

Dhir Parmar: Twitter, LinkedIn

302Found: Twitter, LinkedIn

Originally published at: https://infosecwriteups.com/android-pentesting-101-part-1-8e31b8cd8b2b

November 29, 2022
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments

© HAKIN9 MEDIA SP. Z O.O. SP. K. 2013

Privacy Preference Center

Necessary

Cookies that are necessary for the site to function properly. This includes, storing the user's cookie consent state for the current domain, managing users carts to using the content network, Cloudflare, to identify trusted web traffic. See full Cookies declaration

gdpr, PYPF, woocommerce_cart_hash, woocommerce_items_in_cart, _wp_wocommerce_session, __cfduid [x2],

Performance

These are used to track user interaction and detect potential problems. These help us improve our services by providing analytical data on how users use this site.

_global_lucky_opt_out, _lo_np_, _lo_cid, _lo_uid, _lo_rid, _lo_v, __lotr
_ga, _gid, _gat, __utma, __utmt, __utmb, __utmc, __utmz
vuid

Advertising


tr, fr
ads/ga-audiences