dextra utility began its life as an alternative to the AOSP's dexdump and dx --dump, both of which are rather basic, and produce copious, but unstructured output. In addition to supporting all their features, it also supports various output modes, specific class, method and field lookup, as well as determining static field values. I later updated it to support ART (which is also one of the reasons why the tool was renamed).
The dextra tool is provided as one of the free downloads provided for the "Android Internals" book (http://NewAndroidBook.com/). You are welcome to use it even if you don't buy the book (though naturally you're even more welcome to buy the book :-). Its method of operation and a lot more about Dalvik internals is covered in detail, in Chapters 10 and 11. Its latest version, as a tar file with binaries for OS X, Linux/Android x86_64 or Linux/Android ARMv7, can always be obtained at this page right here.
You might want to check back frequently, as I'm currently updating the tool, and adding features, specifically in the decompilation department. Latest compilation date (May 23rd 2016) supports significant improvements to the disassembler and decompiler engine.
For updates, you might want to check out the RSS feed, or follow my company's feed, @Technologeeks, which (aside from the occasional OS X/iOS related stuff) tweets about updates to this and other tools.
If you want to learn how Dextra actually works - DEX and ART get almost a full day in the Android Internals & Reverse Engineering Training course my company, Technologeeks, offers. Come join us!
dextra is designed to be fairly easy to use either independently or as a scriptable component. Some examples follow:
- With no arguments, dextra will try to explain itself as clearly as possible:
- In its basic usage, dextra with just a DEX, ODEX, ART or OAT argument will display the classes:
- Things get more interesting when you use
-m(to display methods),
-f(to display fields) and
-j(for Java-style output).
-v(verbose) is optional, and will print out class, field, method and string indices as Java comments. Since classes.dex normally contains hundreds of classes, a good idea is to use "
-c ..." to filter for the class you want.
- You can lookup specific fields, method, or strings, with
-Srespectively - like so:
- Things are even better in color, which you can use with --color or by setting the environment variable of JCOLOR to 1. This produces this nice output:
New features in 1.2
- -c and -p can now be used on OAT files: Super useful for quickly locating a class or package in a jumbo .oat like boot.oat:
- -dextract: will extract the DEX file(s) from the OAT file
- -D Decompile, not just disassemble. That is, produce Java code. This may be used indepdently of -d (to show both decomp and disass). This is experimental, however - still working on it (e.g. that ";" after the class name..)
New features in 1.3
- As of 1.3 DexTRA recognizes ART reflected classes, but at this point using hard-coded offsets. This will most likely render it incompatible with future releases (*sigh*), but the only way to make this forward-compatible would be to implement a mini-reflection engine inside DexTRA itself. Which I will, probably, at some point. But now is not that point.
- With the functions in the code, it's trivial to turn DexTRA into a fuzzer. I personally see this as a fairly fruitless endeavor, since even if there is some heinous overflow in the ART parser (and there is, I can practically guarantee), one would have to write to /data/dalvik-cache (or /system/framework/../boot.oat|art), which requires system access. And if you have system, you're pretty much done.
New features in 1.5
- With no arguments, will simply print out what type of file (OAT/ART version) you're passing in
- -h will now just show the header and nothing else. There's a new -l switch to list contents.
- Android M Preview (OAT 062 and ART 015) support.
-pswitches now extended to work inside OAT and ART:
and, of course, with color:
New features in 1.17.64 (new versioning scheme)
- 01/27/2015 Changes: Auto-Color for ttys, and better DEX bytecode handling
- Dumps fill-array-data
- Handles instance-of, throw, and many other instructions
- signed/unsigned glitches fix
- Decompilation now handles const assignments
- Handles and resolves offsets
- Full smali disassembly (not just opcodes, as was previous version)
- Still not handling all opcodes (lazy on the arithmetic/logical) but will get to that eventually..
- Versioning scheme changed - version is now 1.artVersion.oatVersion. This ensures monotonically increasing version numbers with Google's capricious changes. I've also included the exact compilation date, so you can see if you have the latest version.
- Android M Preview 2 through Final (OAT 064 and ART 017, hence version number 1.17.64) support. Why Google keeps changing the internal structure of ART breaking compatibility so bad eludes me. But (so far) I'm keeping up. Strings are different (again), and most importantly the ART header is entirely incompatible with previous versions - but at least makes more sense.
Note: I am discontinuing support for ART 015/OAT 062 since they're likely to not ever see the light of day again as M progressed into final (which is compatible with PR2).
- # of image roots no longer hard coded for any version. Dynamically locating image roots and classes on the fly (working with ART's own reflection)
- Output even more
grep(1)friendly, so that to look for a specific class at an address you can:
-deltato apply image delta. This is useful when comparing output to
oatdumpon a device, which will provide shifted addresses.
-Tto dump DEX types now implemented (wasn't that useful, and nobody mentioned it till now.. )
- Decompilation (
-j -D -d) significantly improved, to get arguments to functions and even follow if statements. Still far from where I want it to be, but already getting useful!
New features in 1.27.75
New features in 1.29.79
New features in 1.30.88
New features in 1.38.11403/24/2017 Changes
- If you want any feature which I'm not covering (or not doing a good job at), let me know. I will gladly take requests.
(No need to report any of these)
- Samsung devices are funky. The oat/art headers there are somehow non-compliant. I'm working on this
- Decompilation, being the latest feature is far from perfect. Specifically, I'm still working on:
- dealing with a variable being set inside a conditional block, but retaining its original value when outside block
- enabling indefinite # of nested conditional blocks (currently only 2)
- handling goto better
-deep(array dump for ART files) crashes sometimes.
Please report any other bug - especially crashes - so I can improve dextra
dextra extensively, and also people have been nice enough to send me dumps aplenty. That said, with all the devices out there (and myriad versions of ART), the tool may crash. If you encounter any bug I don't know about, you've run into a use case I didn't consider. So, please shoot me a line. The only way I can fix bugs is by first knowing they exist.
- Why not use oatdump? If you like oatdump, you can and should use it. That said, oatdump is A) crude B) delivers copious output (we're talking upwards of 1GB!) which is not friendly C) only runs in Android since it essentially initializes ART and doesn't really parse, so much as load and dump, and is therefore D) not really applicable outside the exact version of ART your device runs, or on other devices..
- Why is this not open source? Because it isn't, at least for the moment. I reimplemented the entire DEX/ART/OAT parsing logic and a lightweight VM from scratch here - no mere feat. I do make the "engine" of Dextra available as a dylib for integration with other fuzzers/tools/etc. But that'll require a license. Drop me a line if interested.
- Why is the tool sometime crashing on _____.art or ____.oat? Because Google changes the format internally faster than I can keep up (q.v. Volume II which discussed format changes in depth). Tough. But if you send me samples, I'll fix the tool so it doesn't crash on your favorite .oat or .art.
* - The tool was originally named "dexter", but was renamed because of A) conflict with another tool (not mine) with different functionality and B) support for ART.