Mercury v1.1 is Released

By on 7 September, 2012

After the launch of Mercury in March 2012, the framework has attracted many new contributors and an overwhelming number of new ideas for its future. The next logical steps were to continue the development of new features, stabilise existing ones and add new modules for performing various tasks. Since its release, Mercury has become the de facto standard framework for security testing on Android and is used by phone vendors, large companies and Android tinkerers from around the world. It has also been included in new releases of Backtrack and Santoku Linux, showing community acceptance of its ninjaness.

The new version is compatible with new Android releases including Ice Cream Sandwich and Jelly Bean, meaning you can now run Mercury on the latest and greatest hardware. This enables you to be the first to find and report previously undisclosed bugs on that newly released phone!

Many new features have been added that ease the process of reviewing Android devices in their entirety or just single apps.

For those of you interested in vulnerabilities in vendor products, the new version is the start of a collection of these in a framework. The first privilege escalation was included, allowing the escalation to root from Mercury’s unprivileged context. A module was created to check for vulnerabilities in content providers discovered on Samsung devices. These findings were presented at Blackhat Europe 2012 and the advisory for these issues can be found here.

The results of running this module on a vulnerable version of the Samsung Galaxy SII is shown below:


Running this on the Samsung Galaxy SIII yields the following:


Proper use of Mercury can sometimes be confusing as there is nothing that quite feels the same as its interface. Better in-line help was added to this release and other user interface improvements. Typing help <command> will now provide some examples of typical use-cases as well. Output of commands can now be saved to a file, which solves the problem of cut off responses for users with a short console history *cough Windows cough* or anyone wanting to save results. There are a few more tricks in the user interface that can be found in the user guide.

Adding new features was not enough. We wanted to add something that allowed you to add new features on the fly, without recompiling the Mercury APK. The Reflection Interface was born. This was so cutting edge, it got its own blog post. This allows one to, from the Python client, tell the Android code what objects to create and what to do with them. This allows true flexibility and a powerful framework for adding features that did not exist at runtime. The future of Mercury will be built on this premise, with a lightweight agent running on the Android device that accepts dynamic java classes to execute and report the result back.

Security consultants

The first set of vulnerabilities found by the MWR team was done manually by reviewing the AndroidManifest.xml of each package on the phone. With Mercury, a combination of the attacksurface command and the the info command in each section will get you the same results in a tenth of the time. If you are interested in looking for common problems on devices, the scanner modules will be of interest to you. As an example, this is scanner.provider.sqlinjection finding SQL injection flaws in default content providers on an Android 4.0.3 Emulator.


Don’t get too excited, these SQL injection vulnerabilities don’t lead to any serious information disclosure, but you get the idea right? Don’t just look at content provider problems because these tools are available. Content providers are the tip of the iceberg! Ask us questions or bounce ideas. Create new modules with Mercury. Go forth and innovate!

Application Developers and Phone manufacturers

View the attack surface of your application from the point of view of an unprivileged application. Answer the following questions by following the Mercury user guide:

  • What is exported to other applications?
  • Do you have any native components in your application?
  • Can your application receive unprotected broadcasts?
  • What permissions does your application have? Are they all necessary?

Why not find security issues before release? This does not even need to be done by security staff. Doing small checks with Mercury regularly during development can save money and ensure that no security “oopsies” slip through the cracks.

We hope that you will enjoy the new version of Mercury as much as we do.

Download Mercury v1.1 here

View the user guide here