The major new functionality in this release is that baksmali now supports deodexing without the help of deodexerant! It also has a new “register info” feature, to show the register types in the disassembly, and numerous minor fixes/changes/enhancements/tweaks/(and probably bugs)

Deodexing

In order to deodex files now, you need to have the boot class path files available for baksmali to use. By default, it looks for the 5 main framework jars in the current directory. You can of course specify additional directories to search in, add additional boot class path files, or change which boot class path files are used altogether.

The DeodexInstructions page has more info on how to deodex with this version. But for a quick primer, you just need to have the 5 main framework files in the current directory (core.jar, ext.jar, framework.jar, android.policy.jar and services.jar), and then specify the -x option for baksmali. For example:

baksmali -x Calculator.odex -o Calculator

Register Info

Another bit of new functionality that can be very helpful is the new “register info” output for baksmali, which can be turned on with the -r parameter. It will analyze the registers and print some register type info before and after each instruction. There are several levels of register info output available, depending on exactly what you want to see. The default is to print the register type for any register that is used by the instruction.

Note that this functionality also requires that baksmali load the boot class path files – so they must be available. Here is an example of what the default register info looks like:

#v0=(Integer);v2=(Integer);
new-array v2, v0, [C
#v2=(Reference,[C);

The register types that are printed just before the instruction are the incoming register types, while the register types that are printed after the instruction show any changes to the registers caused by the instruction.

If you want to see all the register info, you can use -r ALL,FULLMERGE which looks something like this:

#v0=(Integer):merge{0x18:(Null),0x2c:(Integer)}
#v1=(Conflicted):merge{0x18:(Uninit),0x2c:(Integer)}
#v3=(Conflicted):merge{0x18:(Uninit),0x2c:(Char)}
#v2=(Reference,[C);p0=(Reference,Ljava/lang/String;);p1=(Reference,[B);p2=(Integer);p3=(Integer);p4=(Integer);
iget v2, p0, Ljava/lang/String;->count:I
#v0=(Integer);v1=(Conflicted);v2=(Integer);v3=(Conflicted);p0=(Reference,Ljava/lang/String;);p1=(Reference,[B);p2=(Integer);p3=(Integer);p4=(Integer);

Other changes

There are a few other miscellaneous changes as well. Make sure you take a look at the usage info for smali and baksmali. The short parameters for some of the options have changed. In particular some of the options that are mostly for debugging purposes were changed to an uppercase letter, and are now hidden by default. You can use -?? for both smali and baksmali to see the debug options.

baksmali also has a new -f parameter, which adds a comment with the code address before each instruction. This is useful when looking at the FULLMERGE register info, which shows the register info and code addresses for all “incoming” execution paths.

Things to come

With this release, I have added a robust code analyzer/verifier that can infer the register types and validate the instructions. I plan using this to add verification functionality in smali, so that it will optionally verify the code after assembling it. This will let you know there’s a problem with the assembled code without having to push the code to a device and have dalvik complain to you about the invalid code.

I also want to add some way to dump/serialize the results of loading the boot class path files for baksmali, so that it can load the information it needs from the dump file, instead of reading in all 5 boot class path files every time, which should help speed it up.

In the longer term, I would love to be able to debug code on a device at an assembly level. This is just something that is banging around in the back of my head for now.

This version has significant new functionality, and is much better able to handle the larger framework files that are floating around. There are a number of bug fixes as well.

As usual, you can grab the new versions from the googlecode download page

The changes for this version include:

• Added support for a new .locals directive, which can be used instead of the .registers directive, to specify the number of non-parameter registers in the method
• Added support for the --use-locals/-l option in baksmali, to use the .locals directive instead of the .registers directive
• Added support for the --sequential-labels/-q option in baksmali, which causes baksmali to create label names using a sequential numbering scheme, instead of basin it on the bytecode address
• Added support for automatically upgrading const-string to const-string/jumbo when needed and upgrading goto or goto/16 to goto/16 or goto/32 when needed
• Added support for the --no-fix-string-const/-c option in smali, to prevent automatically upgrading const-string instructions to const-string/jumbo
• Added support for the --no-fix-goto/-g option in smali, to prevent automatically upgrading goto and goto/16 instructions
• Added support for the --no-debug-info/-b option in baksmali, to prevent the output of any type of debugging info (.local, .line, .parameter, etc.)
• misc. bugfixes

I’ll try and get a wiki going on the googlecode page with some documentation, as far as usage and syntax goes. But for now, you can look at the examples and tests to see the syntax. There are tests for every opcode, so you should be able to find the syntax you need.

Next up, I’ll get started on baksmali, the disassembler companion to smali.

Will I still be doing “JF” releases? Yes. I may (and I stress may) release a JFized version based on a build from the master branch of the AOSP source. In the mean time, Disconnect has released an image based on some work I had done to get google apps working in master, and haykuro is doing some nice work with the sapphire release. I also plan to keep releasing JF versions of new official G1 firmwares (English only) as they come out.

So what have I been spending my time on the past month or two? I’ve been working on smali/baksmali, an assembler/disassembler for the dex format used by dalvik, Android’s Java VM. . The word “smali” is Icelandic for “assembler” and baksmali is “disassembler” (at least as far as I can tell). If there is anyone reading this who actually speaks Icelandic, feel free to correct me if I’m wrong.

Why Icelandic you ask? Because dalvik is named after an Icelandic fishing village.

The assembler uses a syntax that is based on jasmin’s syntax. It is close to the format that dedexer outputs, but not exactly the same. There are several changes needed to capture specific information needed for reassembly, e.g. the .register directive, prototype info for method calls, etc. Here is a simple “Hello World” class that it is able to assemble.

There is still a lot of work to do on it, so don’t expect anything too very soon.