SUPER Android Analyzer Downloads News

SUPER Android Analyzer is here!

SUPER Android Analyzer is here. SUPER, the Secure, Unified, Powerful and Extensible Rust Android Analyzer version 0.1.0 has been released, and with it, all the power of it is now on your hands.

SUPER logo

But first, let’s talk about SUPER. What is SUPER? 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. We currently detect SQL Injections, XSS vulnerabilities, superuser checks, and a bunch of other vulnerabilities detected by a total of 37 rules, that will be expanded and optimized in future updates.

But, why create a new analyzer? Is it not enough with MobSF, Qark, Androbugs…? Well, we think it’s not enough. All of them have two main issues we wanted to fix: They are written in Java or Python and they are not easily extensible. They are not meant to be used by businesses directly working in Android analysis, and don’t put that kind of functionality first.

Our approach solves those issues in different ways: We first decided to use Rust as our programming language. The language developed openly by Mozilla Foundation gives us lots of utilities to work with regular expressions, files etc. and, most importantly, it enables us to create a secure software that does not depend in JVM or JIT compilers. With Rust, buffer overflows, segmentation faults etc. are directly not possible, which makes sense in a security centered application. And it also gives us enough power to do efficient analysis, giving us the option to automate it in high volume. This is given by Rust zero-cost abstractions, that gives us an efficiency only comparable to C/C++.

And secondly, we decided to make the software 100% extensible: All rules are centered in a rules.json file, and each company or tester could create its own rules to analyze what they need. It’s also modular, so that new developments can easily add new functionality. Finally, a templating system for results reports (that will be improved in future updates) gives users the ability to personalize the report.

Only with this first release, still not being stable, SUPER has shown to be much faster than other frameworks, while catching more potential vulnerabilities. Moreover, SUPER gives some good practice advices to enable programmers to select better their development practices.

It also gives great code review tools, directly in the HTML report, so that anyone can search through the generated code with syntax highlighting for even better vulnerability analysis.


There are multiple ways of installing SUPER in your computer. SUPER is really portable, and it’s possible to run under Windows, Linux and MacOS X:


We have created a package for Windows 64 bits and can be downloaded below. If you want to run SUPER in 32-bit Windows, you will need to compile it from source.

We currently depend on OpenSSL and Java, which are not installed in Windows by default. That’s why Windows users need to download and install OpenSSL and Java and add it to the PATH variable of the system:

It’s very easy to run SUPER in Windows. We provide an executable which extracts SUPER to the specified folder so users don’t need to configure anything else. To run SUPER, double click in the .exe file that you just downloaded. Select the extraction folder, and once extracted, start a console in that folder. You can run the program with the super command. For more information on usage, check the usage section of the post.


We have made it really easy to install SUPER in Linux. We have many packages for different distributions so you will be able to probably find yours. If that’s not the case, you can use a package similar to your distribution (CentOS package for RedHat based distributions, Debian/Ubuntu packages for Debian based distributions, etc.) or if you prefer (or don’t find an appropriate package), you can compile it from source, as it’s shown in the last section of the installation.


For now, MacOS users will need to build the package from source. We already have an issue (#18) to create packages for it, though, and should be solved by SUPER 0.2.0.

Compiling from source

In the case that you want or need to compile SUPER from its sources, you will need to download those sources first. You can download SUPER 0.1.0 sources in zip or in tar.gz. You can also clone the Git repository by running:

git clone

Once you clone or download+decompress the source code in a folder and move to it, you will need to compile it. This is really easy to do, but you will need Rust/Cargo to be installed in your system. You can install it with the instructions provided in Once installed, compiling SUPER is as simple as running the following:

cargo build --release

This will create target/release/super, which will be the executable that you will be able to use in the following steps.


To use SUPER you will need to configure in the config.toml file the paths of vendor, downloads and other folders. If the package was installed using one of the provided packages, the default configuration will work. If not, probably the same folder where super is called from will work (usually the installation folder, or the current workspace). If willing to use other paths, a sample configuration file can be found in the config.toml.sample file.

Lots of parameters can be configured in that file, such as the threads that will be used for the analysis or the rule file. We currently require some Java dependencies that are included in the packages. This should change once #22 is implemented.

Once configured, the use is simple: Move the .apk file that you want to test to the downloads folder. If the folder does not exist, you will need to create it. The name of the .apk file should be {package_name}.apk. For example: After that, running SUPER is as easy as running this:

super {package_name}

If SUPER is installed in the current directory, in Unix, you will need to run ./super instead. The package name will be the .apk file name without the extension. So in the example above, the command would be this:


This will decompress all the files in the dist/{package_name} folder, analyze them with the rules in the rules.json file (and configuration in the config.toml file) and generate the results in the results/{package_name} folder.

In the results page, an index.html file will contain the report, while a report.json file will have a machine readable format of that report. In the case of using the verbose mode (see below), the report will also be shown in the terminal.

Command line interface

If you run super --help, you will see the following:

SUPER Android Analyzer 0.1.0
SUPER Android Analyzer Team <>
Audits Android apps for vulnerabilities

    super [FLAGS] <package>

        --bench      Show benchmarks for the analysis.
        --force      If you'd like to force the auditor to do everything from the beginning.
    -h, --help       Prints help information
    -q, --quiet      If you'd like a zen auditor that won't talk unless it's 100% necessary.
    -V, --version    Prints version information
    -v, --verbose    If you'd like the auditor to talk more than necessary.

    <package>    The package string of the application to test.

The usage is really straightforward. The -v or --verbose option will show loads of information in the terminal itself, and the analysis will be performed much slower. The intention in verbose mode is partially to show how the vulnerabilities are cached and how the analysis is performed.

In normal mode, small messages will be printed indicating the analysis stage. The analysis is usually really fast (takes a really big app less than one minute in a Carbon X1), but it will in any case show some prints. This can be avoided by using the -q or the --quiet option. This will avoid all output from stdout even though there might be some output in stderr if something doesn’t go as expected.

The --force option will regenerate the distribution files and results even if that application has already been analyzed. By default, if the application distribution files exist in dist/{package_name} they won’t be generated, and if the results are already in results/{package_name} they won’t be generated either. Those are independent, so if the distribution files are generated but the report has been deleted, only the report will be generated.

The --bench flag will generate benchmarks for the current analysis. This is useful to see the real performance of the analysis. An example benchmark can be this:

ApkTool decompression: 7.278750647s
Dex extraction: 0.98327826s
Dex to Jar decompilation: 11.473415714s
Decompilation: 11.695567790s
Manifest analysis: 0.5059071s
Certificate analysis: 0.5984248s
Rule loading: 0.15836818s
File analysis: 1.312931838s
Total code analysis: 1.349633866s
Total static analysis: 1.362122448s
Report generation: 1.154849626s
Total time: 33.824436350s

As you can see, most of the time is expent in the extraction and decompilation phases, which are one of the priorities for the next version (#22), since they use external Java dependencies.


SUPER has been developed in GitHub as an open source software. It’s licenses under GPLv3 (or, at your option, any later version). We use Git-flow as our development model and we have created some guidelines to contribute. It has been developed by the SUPER team.

Things to do

There are still lots of things to do (that’s why this version is 0.1.0 and not 1.0.0). You can find them in the issue tracker. We have created some labels to make it easier track issues and to select those to fix or implement. So, for example, we have a list of easy issues, a list of bugs, etc. We even have some issues for newcomers!

Our results

For this first version we analyzed a total of 61 applications in the Google Play Store, in different categories. The complete list is shown here. An online report repository is going to be created in the future to show all the generated reports for many applications and versions, but for now, a post will be shown in the next days with information about the vulnerabilities that were found.

The applications analyzed have been these:

Fork me on GitHub