Do you use **Hacktricks every day**? Did you find the book **very****useful**? Would you like to **receive extra help** with cybersecurity questions? Would you like to **find more and higher quality content on Hacktricks**?\
[**Support Hacktricks through github sponsors**](https://github.com/sponsors/carlospolop) **so we can dedicate more time to it and also get access to the Hacktricks private group where you will get the help you need and much more!**
If you want to know about my **latest modifications**/**additions** or you have **any suggestion for HackTricks** or **PEASS**, **join the** [**💬**](https://emojipedia.org/speech-balloon/)[**telegram group**](https://t.me/peass), or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/carlospolopm)**.**\
If you want to **share some tricks with the community** you can also submit **pull requests** to [**https://github.com/carlospolop/hacktricks**](https://github.com/carlospolop/hacktricks) that will be reflected in this book and don't forget to **give ⭐** on **github** to **motivate****me** to continue developing this book.
It's highly recommended to start reading this page to know about the **most important parts related to Android security and the most dangerous components in an Android application**:
It allows you to control your device over **USB** or **Network** from a computer, **copy** files back and forth, **install** and uninstall apps, run **shell** commands, perform **backups**, read **logs** and more.
Sometimes it is interesting to **modify the application code** to access **hidden information** (maybe well obfuscated passwords or flags). Then, it could be interesting to decompile the apk, modify the code and recompile it.\
[**In this tutorial** you can **learn how to decompile and APK, modify Smali code and recompile the APK** with the new functionality](smali-changes.md). This could be very useful as an **alternative for several tests during the dynamic analysis** that are going to presented. Then, **keep always in mid this possibility**.
## Other interesting tricks
* [Spoofing your location in Play Store](spoofing-your-location-in-play-store.md)
Just taking a look to the **strings** of the APK you can search for **passwords**, **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **api** keys, **encryption**, **bluetooth uuids**, **tokens** and anything interesting... look even for code execution **backdoors** or authentication backdoors (hardcoded admin credentials to the app).
Pay special attention to **firebase URLs** and check if it is bad configured. [More information about whats is FIrebase and how to exploit it here.](../../pentesting/pentesting-web/buckets/firebase-database.md)
Using any of the **decompilers** mentioned [**here** ](apk-decompilers.md)you will be able to read the _Manifest.xml_. You could also **rename** the **apk** file extension **to .zip** and **unzip** it.\
* First of all, check if **the application is debuggeable**. A production APK shouldn't be (or others will be able to connect to it). You can check if an application is debbugeable looking in the manifest for the attribute `debuggable="true"` inside the tag _\<application_ Example: `<application theme="@2131296387" debuggable="true"`
* [Learn here](drozer-tutorial/#is-debuggeable) how to find debuggeable applications in a phone and exploit them
* **Backup**: The **`android:allowBackup`** attribute defines whether application data can be backed up and restored by a user who has enabled usb debugging. If backup flag is set to true, it allows an attacker to take the backup of the application data via adb even if the device is not rooted. Therefore applications that handle and store sensitive information such as card details, passwords etc. should have this setting explicitly set to **false** because by default it is set to **true** to prevent such risks.
* **NetworkSecurity:** The application network security can be overwritten the defaults values with **`android:networkSecurityConfig="@xml/network_security_config"`**. A file with that name may be put in _**res/xml.**_ This file will configure important security settings like certificate pins or if it allows HTTP traffic. You can read here more information about all the things that can be configure, but check this example about how to configure HTTP traffic for some domains: 
* **Exported activities**: Check for exported activities inside the manifest as this could be dangerous. Later in the dynamic analysis it will be explained how [you can abuse this behaviour](./#exploiting-exported-activities-authorisation-bypass).
* **Content Providers**: If an exported provider is being exposed, you could b able to access/modify interesting information. In dynamic analysis [you will learn how to abuse them](./#exploiting-content-providers-accessing-and-manipulating-sensitive-information).
* Check for **FileProviders** configurations inside the attribute `android:name="android.support.FILE_PROVIDER_PATHS"`. [Read here to learn more about FileProviders](./#fileprovider).
* **Exposed Services**: Depending on what the service is doing internally vulnerabilities could be exploited. In dynamic analysis [you will learn how to abuse them](./#exploiting-services).
* **Broadcast Receivers**: [You will learn how you can possibly exploit them](./#exploiting-broadcast-receivers) during the dynamic analysis.
* **URL scheme**: Read the code of the activity managing the schema and look for vulnerabilities managing the input of the user. More info about [what is an URL scheme here](./#url-schemes).
* **minSdkVersion**, **targetSDKVersion**, **maxSdkVersion**: They indicate the versions of Android the app will run on. It's important to keep them in mind because from a security perspective, supporting old version will allow known vulnerable versions of android to run it.
**Tapjacking** is an attack where a **malicious****application** is launched and **positions itself on top of a victim application**. Once it visibly obscures the victim app, its user interface is designed in such a way as to trick the user to interact with it, while it is passing the interaction along to the victim app.\
In order to detect apps vulnerable to this attacked you should search for **exported activities** in the android manifest (note that an activity with an intent-filter is automatically exported by default). Once you have found the exported activities, **check if they require any permission**. This is because the **malicious application will need that permission also**.\
Finally, it's important to check the code for possible **`setFilterTouchesWhenObscured`** configurations. If set to **`true`**, a button can be automatically disabled if it is obscured:
You can use [**qark**](https://github.com/linkedin/qark) with the `--exploit-apk` parameter to create a malicious application to test for possible **Tapjacking** vulnerabilities.\
The mitigation is relatively simple as the developer may choose not to receive touch events when a view is covered by another. Using the [Android Developer’s Reference](https://developer.android.com/reference/android/view/View#security):
> Sometimes it is essential that an application be able to verify that an action is being performed with the full knowledge and consent of the user, such as granting a permission request, making a purchase or clicking on an advertisement. Unfortunately, a malicious application could try to spoof the user into performing these actions, unaware, by concealing the intended purpose of the view. As a remedy, the framework offers a touch filtering mechanism that can be used to improve the security of views that provide access to sensitive functionality.
>
> To enable touch filtering, call [`setFilterTouchesWhenObscured(boolean)`](https://developer.android.com/reference/android/view/View#setFilterTouchesWhenObscured%28boolean%29) or set the android:filterTouchesWhenObscured layout attribute to true. When enabled, the framework will discard touches that are received whenever the view's window is obscured by another visible window. As a result, the view will not receive touches whenever a toast, dialog or other window appears above the view's window.
Files **created** on **internal** storage are **accessible** only by the **app**. This protection is implemented by Android and is sufficient for most applications. But developers often use `MODE_WORLD_READBALE`&`MODE_WORLD_WRITABLE` to give access to those files to a different application, but this doesn’t limit other apps(malicious) from accessing them.\
During the **static** analysis **check** for the use of those **modes**, during the **dynamic** analysis **check** the **permissions** of the files created (maybe some of them are worldwide readable/writable).\
Files created on **external storage**, such as SD Cards, are **globally readable and writable**. Because external storage can be removed by the user and also modified by any application, you should **not store sensitive information using external storage**.\
As with data from any untrusted source, you should **perform input validation** when handling **data from external storage**. We strongly recommend that you not store executables or class files on external storage prior to dynamic loading. If your app does retrieve executable files from external storage, the files should be signed and cryptographically verified prior to dynamic loading.\
Starting with Android 4.4 (**API 17**), the SD card has a directory structure which **limits access from an app to the directory which is specifically for that app**. This prevents malicious application from gaining read or write access to another app's files.
* **Shared preferences**: Android allow to each application to easily save xml files in the path `/data/data/<packagename>/shared_prefs/` and sometimes it's possible to find sensitive information in clear-text in that folder.
* **Databases**: Android allow to each application to easily save sqlite databases in the path `/data/data/<packagename>/databases/` and sometimes it's possible to find sensitive information in clear-text in that folder.
For some reason sometimes developers accept all the certificates even if for example the hostname does not match with lines of code like the following one:
A good way to test this is to try to capture the traffic using some proxy like Burp without authorising Burp CA inside the device. Also, you can generate with Burp a certificate for a different hostname and use it.
Some developers save sensitive data in the local storage and encrypt it with a key hardcoded/predictable in the code. This shouldn't be done as some reversing could allow attackers to extract the confidential information.
Developers shouldn't use **deprecated algorithms** to perform authorisation **checks**, **store** or **send** data. Some of these algorithms are: RC4, MD4, MD5, SHA1... If **hashes** are used to store passwords for example, hashes brute-force **resistant** should be used with salt.
### Other checks
* It's recommended to **obfuscate the APK** to difficult the reverse engineer labour to attackers.
 and finally you can use [**these recommended tools**](../../reversing/reversing-tools-basic-methods/#net-decompiler) to **read C# code** from the DLLs.
The tool [**mariana-trench**](https://github.com/facebook/mariana-trench) is capable of finding **vulnerabilities** by **scanning** the **code** of the application. This tool contains a series of **known sources** (that indicates to the tool the **places** where the **input** is **controlled by the user**), **sinks** (which indicates to the tool **dangerous****places** where malicious user input could cause damages) and **rules**. These rules indicates the **combination** of **sources-sinks** that indicates a vulnerability.
> First of all, you need an environment where you can install the application and all the environment (Burp CA cert, Drozer and Frida mainly). Therefore, a rooted device (emulated or not) is extremely recommended.
You can create a **free account** in: [https://appetize.io/](https://appetize.io). This platform allows you to **upload** and **execute** APKs, so it is useful to see how an apk is behaving.
* [**Android Studio**](https://developer.android.com/studio) **(**You can create **x86** and **arm** devices, and according to [**this** ](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**latest x86** versions **support ARM libraries** without needing an slow arm emulator). 
* If you want to try to **install** an **image** and then you want to **delete it** you can do that on Windows:`C:\Users\<User>\AppData\Local\Android\sdk\system-images\` or Mac: `/Users/myeongsic/Library/Android/sdk/system-image` 
When creating a new emulator on any platform remember that the bigger the screen is, the slower the emulator will run. So select small screens if possible.
As most people will use **Genymotion**, note this trick. To **install google services** (like AppStore) you need to click on the red marked button of the following image:
Also, notice that in the **configuration of the Android VM in Genymotion** you can select **Bridge Network mode** (this will be useful if you will be connecting to the Android VM from a different VM with the tools).
> Once you have installed the application, the first thing you should do is to try it and investigate what does it do, how does it work and get comfortable with it.\
> I will suggest to **perform this initial dynamic analysis using MobSF dynamic analysis + pidcat**, so will will be able to **learn how the application works** while MobSF **capture** a lot of **interesting** **data** you can review later on.
Often Developers leave debugging information publicly. So any application with `READ_LOGS` permission can **access those logs** and can gain sensitive information through that.\
While navigating through the application use [**pidcat**](https://github.com/JakeWharton/pidcat)_(Recommended, it's easier to use and read_) or [adb logcat](adb-commands.md#logcat) to read the created logs and **look for sensitive information**.
Note that from l**ater versions that Android 4.0**, **applications are only able to access their own logs**. So applications cannot access other apps logs.\
Android provides **clipboard-based** framework to provide copy-paste function in android applications. But this creates serious issue when some **other application** can **access** the **clipboard** which contain some sensitive data. **Copy/Paste** function should be **disabled** for **sensitive part** of the application. For example, disable copying credit card details.
If an application **crashes** during runtime and it **saves logs** somewhere then those logs can be of help to an attacker especially in cases when android application cannot be reverse engineered. Then, avoid creating logs when applications crashes and if logs are sent over the network then ensure that they are sent over an SSL channel.\
Most of the application uses other services in their application like Google Adsense but sometimes they **leak some sensitive data** or the data which is not required to sent to that service. This may happen because of the developer not implementing feature properly. You can **look by intercepting the traffic** of the application and see whether any sensitive data is sent to 3rd parties or not.
Most of the applications will use **internal SQLite databases** to save information. During the pentest take a **look** to the **databases** created, the names of **tables** and **columns** and all the **data** saved because you could find **sensitive information** (which would be a vulnerability).\
Databases should be located in `/data/data/the.package.name/databases` like `/data/data/com.mwr.example.sieve/databases`
If the database is saving confidential information and is **encrypted b**ut you can **find** the **password** inside the application it's still a **vulnerability**.
Enumerate the tables using `.tables` and enumerate the columns of the tables doing `.schema <table_name>`
**Drozer** allows you to **assume the role of an Android app** and interact with other apps. It can do **anything that an installed application can do**, such as make use of Android’s Inter-Process Communication (IPC) mechanism and interact with the underlying operating system. From [Drozer Guide](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf).\
When an Activity is exported you can invoke its screen from an external app. Therefore, if an activity with **sensitive information** is **exported** you could **bypass** the **authentication** mechanisms **to access it.**\
**NOTE**: MobSF will detect as malicious the use of _**singleTask/singleInstance**_ as `android:launchMode` in an activity, but due to [this](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750), apparently this is only dangerous on old versions (API versions <21).
Note that an authorisation bypass is not always a vulnerability, it would depend on how the bypass works and which information is exposed.
{% endhint %}
**Sensitive information leakage**
**Activities can also return results**. If you manage to find an exported and unprotected activity calling the **`setResult`** method and **returning sensitive information**, there is a sensitive information leakage.
\*\*\*\*[**Read this if you want to remind what is a Content Provider.**](android-applications-basics.md#content-provider)\
Content providers are basically used to **share data**. If an app has available content providers you may be able to **extract sensitive** data from them. It also interesting to test possible **SQL injections** and **Path Traversals** as they could be vulnerable.\
As service is basically something that **can receive data**, **process** it and **returns** (or not) a response. Then, if an application is exporting some services you should **check** the **code** to understand what is it doing and **test** it **dynamically** for extracting confidential info, bypassing authentication measures...\
You can look for deep links manually, using tools like MobSF or scripts like [this one](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
Every time you find a deep link check that i**t's not receiving sensitive data (like passwords) via URL parameters**, because any other application could **impersonate the deep link and steal that data!**
You **must check also if any deep link is using a parameter inside the path** of the URL like: `https://api.example.com/v1/users/{username}` , in that case you can force a path traversal accessing something like: `example://app/users?username=../../unwanted-endpoint%3fparam=value` .\
Note that if you find the correct endpoints inside the application you may be able to cause a **Open Redirect** (if part of the path is used as domain name), **account takeover** (if you can modify users details without CSRF token and the vuln endpoint used the correct method) and any other vuln. More [info about this here](http://dphoeniixx.com/2020/12/13-2/).
* **Lack of Certificate Inspection:** Android Application fails to verify the identity of the certificate presented to it. Most of the application ignore the warnings and accept any self-signed certificate presented. Some Application instead pass the traffic through an HTTP connection.
* **Weak Handshake Negotiation:** Application and server perform an SSL/TLS handshake but use an insecure cipher suite which is vulnerable to MITM attacks. So any attacker can easily decrypt that connection.
* **Privacy Information Leakage:** Most of the times it happens that Applications do authentication through a secure channel but rest all connection through non-secure channel. That doesn’t add to security of application because rest sensitive data like session cookie or user data can be intercepted by an malicious user.
From the 3 scenarios presented we are going to discuss **how to verify the identity of the certificate**. The other 2 scenarios depends on the **TLS configuratio**n of the server and if the **application sends unencrypted data**. The pentester should check by it's own the TLS configuration of the server ([here](../../pentesting/pentesting-web/#ssl-tls-vulnerabilites)) and detect if any **confidential information is sent by an unencrypted/vulnerable** channel .\
More information about how to discover and fix these kind of vulnerabilities [**here**](https://manifestsecurity.com/android-application-security-part-10/).
By default, when making an SSL connection, the client(android app) checks that the server’s certificate has a verifiable chain of trust back to a trusted (root) certificate and matches the requested hostname. This lead to problem of **Man in the Middle Attacks(MITM)**.\
In certificate Pinnning, an Android Application itself contains the certificate of server and only transmit data if the same certificate is presented.\
First of all, you should (must) **install the certificate** of the **proxy** tool that you are going to use, probably Burp. If you don't install the CA certificate of the proxy tool, you probably aren't going to see the encrypted traffic in the proxy.\
For applications targeting **API Level 24+ it isn't enough to install the Burp CA** certificate in the device. To bypass this new protection you need to modify the Network Security Config file. So, you could modify this file to authorise your CA certificate or you can [**read this page for a tutorial on how to force the application to accept again all the installed certificate sin the device**](make-apk-accept-ca-certificate.md).
We have already discuss what is SSL Pinning just 2 paragraphs before. When it's implemented in an application you will need to bypass it to inspect the HTTPS traffic or you won't see it.\
Here I'm going to present a few options I've used to bypass this protection:
* Automatically **modify** the **apk** to **bypass** SSLPinning with [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). The best pro of this option, is that you won't need root to bypass the SSL Pinning, but you will need to delete the application and reinstall the new one, and this won't always work.
* You could use **Frida** (discussed below) to bypass this protection. Here you have a guide to use Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
* You can also try to **automatically bypass SSL Pinning** using [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
* If you still think that there is some traffic that you aren't capturing you can try to **forward the traffic to burp using iptables**. Read this blog: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62) 
Note that in this step you should look for common web vulnerabilities. A lot of information about web vulnerabilities be found in this book so I'm not going to mention them here.
Dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers. Learn more at [www.frida.re](https://www.frida.re).\
**It's amazing, you can access running application and hook methods on run time to change the behaviour, change values, extract values, run different code...**\
**If you want to pentest Android applications you need to know how to use Frida.**
**Learn how to use Frida:** [**Frida tutorial**](frida-tutorial/)\
**Some "GUI" for actions with Frida:** [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)\
**Some other abstractions based on Frida:** [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)\
**You can find some Awesome Frida scripts here:** [**https://codeshare.frida.re/**](https://codeshare.frida.re)\*\*\*\*
This tool could help you managing different tools during the dynamic analysis: [https://github.com/NotSoSecure/android\_application\_analyzer](https://github.com/NotSoSecure/android\_application\_analyzer)
This vulnerability resembles **Open Redirect in web security**. Since class `Intent` is `Parcelable`, **objects belonging to this class** can be **passed** as **extra****data** in another `Intent` object.\
Many developers make **use** of this **feature** and create **proxy****components** (activities, broadcast receivers and services) that **take an embedded Intent and pass it to dangerous methods** like `startActivity(...)`, `sendBroadcast(...)`, etc.\
This is dangerous because **an attacker can force the app to launch a non-exported component that cannot be launched directly from another app**, or to grant the attacker access to its content providers. **`WebView`** also sometimes changes a **URL from a string to an `Intent`** object, using the `Intent.parseUri(...)` method, and passes it to `startActivity(...)`.
Probably you know about this kind of vulnerabilities from the Web. You have to be specially careful with this vulnerabilities in an Android application:
* **SQL Injection:** When dealing with dynamic queries or Content-Providers ensure you are using parameterized queries.
* **JavaScript Injection (XSS):** Verify that JavaScript and Plugin support is disabled for any WebViews (disabled by default). [More info here](webview-attacks.md#javascript-enabled).
* **Local File Inclusion:** Verify that File System Access is disabled for any WebViews (enabled by default) `(webview.getSettings().setAllowFileAccess(false);)`. [More info here](webview-attacks.md#javascript-enabled).
**Vulnerability assessment of the application** using a nice web-based frontend. You can also perform dynamic analysis (but you need to prepare the environment).
Notice that MobSF can analyse **Android**(apk)**, IOS**(ipa) **and Windows**(apx) applications (_Windows applications must be analyzed from a MobSF installed in a Windows host_).\
Also, if you create a **ZIP** file with the source code if an **Android** or an **IOS** app (go to the root folder of the application, select everything and create a ZIPfile), it will be able to analyse it also.
MobSF also allows you to **diff/Compare** analysis and to integrate **VirusTotal** (you will need to set your API key in _MobSF/settings.py_ and enable it: `VT_ENABLED = TRUE``VT_API_KEY = <Your API key>``VT_UPLOAD = TRUE`). You can also set `VT_UPLOAD` to `False`, then the **hash** will be **upload** instead of the file.
**MobSF** can also be very helpful for **dynamic analysis** in **Android**, but in that case you will need to install MobSF and **genymotion** in your host (a VM or Docker won't work). _Note: You need to **start first a VM in genymotion** and **then MobSF.**_\
* **Dump application data** (URLs, logs, clipboard, screenshots made by you, screenshots made by "**Exported Activity Tester**", emails, SQLite databases, XML files, and other created files). All of this is done automatically except for the screenshots, you need to press when you want a screenshot or you need to press "**Exported Activity Tester**" to obtain screenshots of all the exported activities.
From android **versions > 5**, it will **automatically start Frida** and will set global **proxy** settings to **capture** traffic. It will only capture traffic from the tested application.
By default, it will also use some Frida Scripts to **bypass SSL pinning**, **root detection** and **debugger detection** and to **monitor interesting APIs**.\
To **start** the dynamic testing press the green bottom: "**Start Instrumentation**". Press the "**Frida Live Logs**" to see the logs generated by the Frida scripts and "**Live API Monitor**" to see all the invocation to hooked methods, arguments passed and returned values (this will appear after pressing "Start Instrumentation").\
MobSF also allows you to load your own **Frida scripts (**to send the results of your Friday scripts to MobSF use the function `send()`). It also has **several pre-written scripts** you can load (you can add more in `MobSF/DynamicAnalyzer/tools/frida_scripts/others/`), just **select them**, press "**Load**" and press "**Start Instrumentation**" (you will be able to see the logs of that scripts inside "**Frida Live Logs**").
* **Trace Class Methods**: **Trace** a **whole class** (see inputs and outputs of all methods of th class). Remember that by default MobSF traces several interesting Android Api methods.
Once you have selected the auxiliary module you want to use you need to press "**Start Intrumentation**" and you will see all the outputs in "**Frida Live Logs**".
**Shell**
Mobsf also brings you a shell with some **adb** commands, **MobSF commands**, and common **shell****commands** at the bottom of the dynamic analysis page. Some interesting commands:
When http traffic is capture you can see an ugly view of the captured traffic on "**HTTP(S) Traffic**" bottom or a nicer view in "**Start HTTPTools**" green bottom. From the second option, you can **send** the **captured requests** to **proxies** like Burp or Owasp ZAP.\
To do so, _power on Burp -->__turn off Intercept --> in MobSB HTTPTools select the request_ --> press "**Send to Fuzzer**" --> _select the proxy address_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
Once you finish the dynamic analysis with MobSF you can press on "**Start Web API Fuzzer**" to **fuzz http requests** an look for vulnerabilities.
{% hint style="info" %}
After performing a dynamic analysis with MobSF the proxy settings me be misconfigured and you won't be able to fix them from the GUI. You can fix the proxy settings by doing:
This tool is designed to look for several **security related Android application vulnerabilities**, either in **source code** or **packaged APKs**. The tool is also **capable of creating a "Proof-of-Concept" deployable APK** and **ADB commands**, to exploit some of the found vulnerabilities (Exposed activities, intents, tapjacking...). As with Drozer, there is no need to root the test device.
SUPER is a command-line application that can be used in Windows, MacOS X and Linux, that analyzes _.apk_ files in search for vulnerabilities. It does this by decompressing APKs and applying a series of rules to detect those vulnerabilities.
All rules are centered in a `rules.json` file, and each company or tester could create its own rules to analyze what they need.
Download the latest binaries from in the [download page](https://superanalyzer.rocks/download.html)
StaCoAn is a **crossplatform** tool which aids developers, bugbounty hunters and ethical hackers performing [static code analysis](https://en.wikipedia.org/wiki/Static\_program\_analysis) on mobile applications\*.
The concept is that you drag and drop your mobile application file (an .apk or .ipa file) on the StaCoAn application and it will generate a visual and portable report for you. You can tweak the settings and wordlists to get a customized experience.
AndroBugs Framework is an Android vulnerability analysis system that helps developers or hackers find potential security vulnerabilities in Android applications.\
**Androwarn** is a tool whose main aim is to detect and warn the user about potential malicious behaviours developped by an Android application.
The detection is performed with the **static analysis** of the application's Dalvik bytecode, represented as **Smali**, with the [`androguard`](https://github.com/androguard/androguard) library.
This tool looks for **common behavior of "bad" applications** like: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution...
**MARA** is a **M**obile **A**pplication **R**everse engineering and **A**nalysis Framework. It is a tool that puts together commonly used mobile application reverse engineering and analysis tools, to assist in testing mobile applications against the OWASP mobile security threats. Its objective is to make this task easier and friendlier to mobile application developers and security professionals.
It is able to:
* Extract Java and Smali code using different tools
* Extract private information from the APK using regexps.
* Analyze the Manifest.
* Analyze found domains using: [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) and [whatweb](https://github.com/urbanadventurer/WhatWeb)
**ProGuard** is an open source command-line tool that shrinks, optimizes and obfuscates Java code. It is able to optimize bytecode as well as detect and remove unused instructions. ProGuard is free software and is distributed under the GNU General Public License, version 2.
ProGuard is distributed as part of the Android SDK and runs when building the application in release mode.
#### DeGuard reverses the process of obfuscation performed by Android obfuscation tools. This enables numerous security analyses, including code inspection and predicting libraries.
You can upload an obfuscated APK to their platform.
It is a **generic android deobfuscator.** Simplify **virtually executes an app** to understand its behavior and then **tries to optimize the code** so it behaves identically but is easier for a human to understand. Each optimization type is simple and generic, so it doesn't matter what the specific type of obfuscation is used.
### [APKiD](https://github.com/rednaga/APKiD)
APKiD gives you information about **how an APK was made**. It identifies many **compilers**, **packers**, **obfuscators**, and other weird stuff. It's [_PEiD_](https://www.aldeid.com/wiki/PEiD) for Android.
### Manual
[Read this tutorial to learn some tricks on **how to reverse custom obfuscation**](manual-deobfuscation.md)\*\*\*\*
AndroL4b is an Android security virtual machine based on ubuntu-mate includes the collection of latest framework, tutorials and labs from different security geeks and researchers for reverse engineering and malware analysis.
