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

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.

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

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.

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.

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