Sunday, August 5, 2012

Androguard 1.5

We did it.

What ? A stable version of Androguard with a lot of new and exciting features. It was a long road since the beginning of this project, and I think you know it is not easy to do an open source project on your free time.


We wrote and changed everything from the beginning of the project to have now a simple and modifiable disassembler. Each instruction is now represented by a specific class which corresponds to the "format" of the instruction.

For example, when you display a method, you will see each basic block, and the next basic blocks, and at the end the XREF.

But, the thing which is interesting is that you can get the instructions and access to each field of the instruction as described in the DEX format documentation.

For example, the "invoke" instructions is described by the 35c format, which is:

and you will find the same parameters, and general functions to display the instruction, get the name, the value of the opcode, and specific functions to resolve automatically references, like the string, type, method ...

We used a Linear Travel algorithm, but I hope that for the 2.0 release we will have a recursive algorithm to deal with such techniques. But, if you see such techniques in real samples, you can use (but be carefull, it will not help you in all cases !) the set_code_idx method, it will help to change the offset where the disassemble of the buffer starts:


Now, you can save and restore (with cPickle) an analysis session of an Android App, by using save_session and load_session functions in the shell:

But, a more interesting feature is that you can annotate a specific method or an instruction, and it will be displayed:

It is possible to rename a class, a method or a field, by using the set_name method in each corresponding object, and it is really interesting when a sample has been obfuscated:

More information and examples here.

Dex Format

Of course we support APK, and DEX format,  but now we also support ODEX format. We added the support of the debug information of a method and an easy access to all elements with getters.

Moreover, if you read the DEX format specification and our source code, you will find that each part of the specification is a class in our tool.

We also have a BETA version of the modification of the DEX format in order to save it. So you can modify the instructions or anything else in the format and save it, but be careful it is not yet finish and we don't support the modification of the control flow graph.

To see a more interesting example you should check the patch of the crackme challenge of Dexlabs.


Most of the time you can have a shared library (or a binary) embedded in an Android App, and it was not possible to analyse it directly. But SMIASM can do that for you :) So we wrote a simple wrapper to load binary file and to analyse it with this awesome framework !


OMG ! We setup an online website on a new domain name (.re rulz :)) with the documentation of the API and tools. It is a first step to this direction (don't forget to check the wiki too), and we will add more examples. Thx to sphinx open source project.

And we have setup a google group if you would like to talk, but if you have any problem, please open a new issue.


For me, it is really the killer feature. We have a BETA (but working) version of a python decompiler of Android Applications. w00t ! and it is open source baby ! It is not yet another "closed" source software that we have seen in the past, no, it is open and you can improve/modify/share it. So we don't waste your CPU time to translate the dalvik bytecodes to java bytecodes, and to use a close software.

The name of the decompiler is DAD: DAD is Another Decompiler.

You can use it in a "stand-alone" approach :

Or by setting the appropriate decompiler when you create a DalvikVMFormat object with the AnalyzeAPK/DEX functions :

Before printing the source, the decompiler runs a dead code elimination procedure (followed by a register propagation one). So the bytecode of the analyzed application may not be entirely present in the source that if printed. Only the "used" bytecodes will be showed, no need to read a lot of lines which are not used by the apps !

There are some things which need improvement (that's why it's still a beta):

  • the decompiler support almost all of the dalvik bytecodes (not the extended bytecodes) : filled-new-array is not correctly pretty printed, for now it shows filled-new-array(type=xx, size=yy, arg=zz..).
  • switches may pose a problem(crash) in the presence of fall-through cases.
  • types are not yet propagated inside a method, so we currently do not declare the variables inside a method, and there may be some weird things displayed like "if (b == 0)" even though b is a boolean type, or calls with float to functions which takes an integers as parameter (life foo(3.0) with a prototype of foo(int x))

Ok, that's all folks ! But don't forget that we need people to improve the tool and all these awesome features, send us a mail if you are interesting ! "dev (at)"

Thx to VirusTotal Team and the Magnificient7 Program from Rapid7 to help open source security projects. And also to all contributors (Axelle, Yanick, Tim, Patrick, ...), users and donators !

And fuck to all who tried to stop us ! :)

Androguard Core Team (Pouik + Zost)

No comments:

Post a Comment