smali/baksmali v1.2 released

Posted on February 22nd, 2010 in Android Newsfeed by jf  Tagged , ,

After lots of hard work over the last month or two, smali/baksmali 1.2 is out!

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.

  • Comments Off

Have a very smali Christmas!

Posted on December 25th, 2009 in Android Newsfeed by jf  Tagged , ,

As my Christmas present to everyone, I present smali/baksmali v1.1

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
  • Comments Off