Android Blogging Network

smali/baksmali 1.2.6  is out, now with support for gingerbread odex files. A few other minor fixes are also included. You can grab the new version here

• Comments Off

Just a minor release with a few bugfixes that have gone in since the last release

Get it at http://code.google.com/p/smali/downloads/list

• Comments Off

I wanted to take a moment to respond to the recent buzz about using smali/baksmali to break the new Google licensing framework for the Android market.

I do not support/encourage/condone the use of my tools for any form of application piracy, copyright infringement, etc. Given the nature of the tool, it’s natural that it will be used for these types of things. Some people even seem to think that piracy is the sole purpose of these type of tools. However, there are plenty of legitimate uses as well.

I’ll admit, when I first heard the details of the new licensing scheme, my first thought was “I bet that will be easy to crack with smali/baksmali”. But I can almost guarantee that the Google engineers who designed the licensing framework took this possibility into account as well. I hear they’re usually pretty bright over there at Google. To think that they didn’t consider it is almost absurd. What they did was to raise the bar on the effort required to pirate applications. Sure, it’s still possible, but I think that overall it will have a positive effect on piracy rates.

I do find it interesting on an intellectual level to try and break these types of protections. Just to see if I can do it/if it’s possible. There’s a difference between cracking something just to see if you can crack it, and cracking something with the sole purpose of pirating applications. One is good (or at least neutral). The other is evil.

So in the spirit of Google’s motto, I’ll conclude by imploring everyone to use my tools for non-evil.

• Comments Off

1.2.4 is out, with a number of bugfixes

Get it here

Changelist:

• Fixed an issue when using baksmali on a case insensitive file system, and there are classes with names that only vary by case (thanks phd.dre and Brut.all!)
• Fixed an issue where baksmali still printed out .line and .local directives even when the -d/–no-debug-info option is specified (thanks stari4ek!)
• Fixed an issue in smali when in encountered a field or method that was named “null” (thanks dislam!)
• Fixed an issue in smali when encountering a file that has blank annotation sets (thanks flipz and jjiovani!)
• Fixed an issue when there is a <clinit> method with no corresponding code item

• Comments Off

smali/baksmali v1.2.3 is out, and now includes the ability to deodex odex files from froyo.

You can download the new versions on the downloads page of the googlecode project

In addition to the changes related to supporting froyo, the new version has a new lexer that uses much less static memory. (The old lexer had around 30mb of static data. ugh!). The new lexer is written with jflex instead of ANTLR, but it still hooks in with the ANTLR parser.

There was also a significant change in how “undeodexable” instructions are handled. If you want to read up on the details, go take a look at the comments in issue 29 and issue 33. Thanks to Paul from modaco.com, brut.all, master.homer, flipz and JrEE2kX for the reporting/discussion/testing around this issue.

As usual, there are a number of little performance tweaks here and there, and a few new bug spots on the bottom of my shoes.

• Comments Off

Yet Another Baksmali Bugfix Release. v1.2.2 is out for your disassembling pleasure.

As the title suggests, this is mostly a bugfix release, fixing issues 20, 21 and 22.

I’ve also made some significant performance enhancements to baksmali. You can expect deodexing a full firmware to be roughly 50% faster, while performing certain operations on single files can be over 100% faster (dumping the full register info of a large dex file, for example).

Finally, I’ve added the ability to read the base BOOTCLASSPATH dependencies from odex files directly, so you shouldn’t have to specify the full BOOTCLASSPATH (-c) for roms that use a non-standand BOOTCLASSPATH (like HTC Sense roms). Note however, that you will still need to add the  “extra” dependencies for specific applications that need it, because those dependencies aren’t stored in the odex file.

Get it here.

• Comments Off

Yet Another Baksmali Bugfix Release. v1.2.2 is out for your disassembling pleasure.

As the title suggests, this is mostly a bugfix release, fixing issues 20, 21 and 22.

I’ve also made some significant performance enhancements to baksmali. You can expect deodexing a full firmware to be roughly 50% faster, while performing certain operations on single files can be over 100% faster (dumping the full register info of a large dex file, for example).

Finally, I’ve added the ability to read the base BOOTCLASSPATH dependencies from odex files directly, so you shouldn’t have to specify the full BOOTCLASSPATH (-c) for roms that use a non-standand BOOTCLASSPATH (like HTC Sense roms). Note however, that you will still need to add the  “extra” dependencies for specific applications that need it, because those dependencies aren’t stored in the odex file.

Get it here.

• Comments Off

Everyone has heard about Google’s Device Seeding Program. (Yes, it’s real.) So in the next few weeks (days? months?) lots and lots of people will be getting a nice 2nd-gen Android device. Except… nobody gets to choose their device. Google will send either a Nexus One or a Motorola Droid, at random. That is somewhat bad news – if you have T-mobile and bought a G1 on a 2 year contract, it will cost a hundred bucks to get out. VZW is (reportedly) even higher.
So what is a hardworking dev to do?
Here is Android Device Exchange to the rescue – hook up with other owners, device-seed recipients, etc and buy, sell or trade your devices!

• Leave a comment... (1)

I’ve released v1.2.1, which is mostly a bugfix release to v1.2. There are a few performance improvements and enhancements in there as well.

As usual, you can grab a copy on the googlecode download page

• Comments Off

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