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.
Disassembler
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:
Session
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.
Binaries
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 !
Documentation
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.
Decompiler
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) androguard.re"
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)