Saturday, November 7, 2009

smali/baksmali v1.0

It's 1.0. Yep, sure is. Go get it here.

Why should you get the new version you ask? Well, it's been spiffified, of course. The new spiffiness includes:

  • The label syntax has changed from "label:" to ":label". This makes the lexer happy. And a happy lexer uses less memory and runs faster. Yay for happy lexers

  • Added a -r/--rewrite-labels option for smali, which will rewrite the smali files you give it, changing any labels in the old format to the new format.

  • deodexerant now opens the odex files as read-only, so you can run deodexerant directly on the odex files in /system, without having to remount, or copy them to /data.

  • You can give baksmali an apk file now, so you don't have to manually extract out the classes.dex file

And one final note: deodexerant will *not* work on 2.0 devices. Once the 2.0 source is released, I should be able to build a new deodexerant binary that will work on 2.0.

Update: There are now also wrapper scripts available for smali/baksmali, so you can call "baksmali ..." instead of "java -jar baksmali.jar ..."

Update 2: Now that the Eclair source is out, I've added a new build of deodexerant to the downloads page that works with 2.0


  1. *golf clap* excellent! another update! you are never going to leave the android world are you? ;-)

  2. how u install the deodexterant?

  3. Who said anything about leaving? :)

  4. The usual method is with adb push. You might want to take a look at

  5. fabulous work JF
    I just had this subject theoretically in school but I will browse and play a little with your source to see how it's done in real world ;-)

  6. Thanks :)

    What subject? Language design? Compiler construction?

  7. hmmmm... it's some time ago
    If I remembered rigth it was in "CT" wich means Computer Technique but was just a short excurse in how compilers work but not very deep as our teacher said assembler is the highest "high level" language he accepts ;-) and in the discussion about microcontrollers and programming them in C he explained how a compiler works and why programming uC with a high level language other than assembler will not bring a satisfying result (not my opinion).
    Another was "algorithms and Datastructures" in the part about parsing and how assemblers don't do much different as parsing stuff into another form.
    It wasn't very deep but I'm more interested in how compiler works and your work on samli, especialy open source it will be a good way to learn with hands on.

  8. "how assemblers don’t do much different as parsing stuff into another form" - Very true. I designed the smali "assembly language" to be as close to a direct translation of the underlying dex file as possible. With high level compilers, it takes the input language, and generates the low-level assembly output, which is probably significantly different than the high level language. But with an assembler/disassm, there really isn't much modification of the input going on. It's almost a direct translation from the dex binary format to the text smali format.

    "why programming uC with a high level language other than assembler will not bring a satisfying result" - depending on the uC, I would tend to agree. I've done some work on a small 8051 uC (I rewrote the firmware for my datahand keyboard from scratch), which has around 20k flash memory and runs at 12mhz, where each instruction takes 12 cycles (or some multiple of 12 cycles). And it has something like 256bytes of memory. With such constraints, it's better to program it directly with assembly, so you have direct control over exactly how the memory and registers are used. Plus you know *exactly* how long everything takes to run, which is often important when you're doing things at that level.

  9. Hey all. I'm hoping that JF or someone can help me. I am working on smali/baksmali'ing framework.odex on my cdma hero to change a couple of things. The baksmali goes perfectly fine but when I try to smali I get bombarded with errors in every single .smali file:

    c:\test\framework\out\android\app\ActivityManagerProxy.smali[4364,32] no viable
    alternative at character '}'

    no viable alternative at character ':'

    My syntax that I used was: c:\test\framework>java -Xmx512m -jar c:\android\sdk\tools\smali.jar out

    I also tried with -o test.dex and got the same thing. I tried without the memory switch but got a memory error (it's a huge odex). I also tried 0.96 and got the same errors. Any help that you can give is appreciated. :) I am using v1.0. Thanks.

  10. Hi, thanks for this! I'm running into issues with services.odex though. I can deodex it, but when using smali to compile it back, I get the following:

    java -Xmx512M -jar smali.jar -o classes.dex out
    /home/wysie/Desktop/tempfiles/out/com/android/server/WindowManagerService.smali[25760,4] The offset/label is out of range. The offset is -133 and the range for this opcode is [-128, 127].

    Thanks :)

  11. Did you modify that smali file before re-assembling it? If so, it's possible you inserted some code between the goto/jump and its target, and made the target out of range.

    BUT, if you didn't modify it at all, that's certainly very strange. If that's the case, what rom did you take the services.odex from? A dl link to the rom would be appreciated - or you could email the odex file to me.

  12. Hey jf, thanks for the reply! Nope, I did not modify the file at all, was simply trying to de-odex services.odex and framework.odex. Had trouble de-odexing framework.odex, and services.odex works but I can't compile it back using smali.

    I'm using it on Amon_RA's ROM here:

    Thanks JesusFreke! :)

  13. by the way, is your email JesusFreke[at] I can email you the odex files later :). thank you.

  14. Hi JF, jubeh@xda has posted some stuff regarding framework de-odexing here:

    Hope it helps :D.

  15. I'm also at the same point as you, though. services deodexes just fine, but then trying to smali it back will fail.
    I know now my approach is correct and I should be able to de-odex the core framework by doing it in the reverse order of which it dexopts for the first time, but services.jar happens to be the very last jar to be de-odexed and while the others will de-odex fine (except etc.jar, it will throw a bunch of errors and won't baksmali completely), even if I try to boot with core, framework, and android.policy de-odexed, services and ext will fail verification (ofcourse) and the system will just hang at a boot loop.
    I'm mentioning it because I'm very sure the problem is with smali/baksmali.
    My test rom is the adp1 ota image for 1.6. What? you say, that build doesn't have any odexes, does it?.
    Well, no, it doesn't, but I ran dexopt-wrapper all over it and then baksmali-ed it all back to classes.dex for fun (yeah, i was that bored, research actually). So to replicate, just download the image from (oh, they're down) and dexopt-wrapper it and then try to deodexerant it back.
    I have to ask, JF, which build are YOU using. I'd like to test compiling the framework on that.

  16. The only reason you would need to deodex stuff in any particular order is if you deodex one file, and then resmali it and put it back on the phone, and then deodex the next file, etc. But if you just deodex everything before replacing any files on the phone, you don't have to deodex them in any particular order. Much easier :D

    As for the services.odex issue, I'm aware of it, and working on a fix. In the meantime, just replace the goto/16 or goto instructions that it complains about with a goto/32 instruction instead.

  17. I see how that makes sense. I was with the logic where, if you create odexes for a build, you first have to follow the boot classpath and then do all the rest because there are dependencies generated (in some way, I don't understand fully how) based not only on the dalvik machine and memory configuration but also the running framework, so if you dexopt-wrapper the apps, then the secondary framework, then the core framework, there will be a lot of broken dependencies since the information written to the original apps odexe's were dependent on the original configuration of the classes for the framework (non-odexed) and when you odex the framework after that, it breaks all that. Again, I'm not entirely sure why that is, but that's what seems to be happening.

    Anyway, I thought this was the same situation, but thinking about it, it makes sense that those dependencies are stripped when you de-odex, and as long as you don't change anything in the current build from which you're running deodexerant, the applet should be able to determine those dependencies, memory configurations, etc and strip those to leave you with the kind of "universal" dex code we all know and love.

    I hope I'm on the right track.

  18. Yeah, you can definitely deodex everything in any order you want, as long as you don't replace any jars/apks on the phone until after you've deodexed everything. I'm 100% certain about that. Don't believe anyone who says otherwise ;)

  19. [...] This post was Twitted by Wysie_Soh [...]

  20. Hi JF, thanks in advance for any help that you give me. I de-odexed my services.odex file on my CLIQ and the program put everything in the out directory. (I am trying to change the color on my notification bar.) I edited my files and am ready to rebuild. Everything that I have read about rebuilding the services.odex file goes something like this...

    java -jar baksmali.jar -o < .dex file

    Now here is where I get confused. Is a .odex file the same as a .dex file? Or do I have to perform another step for an .odex file?

    Thank You

  21. This comment has been removed by a blog administrator.


Note: Only a member of this blog may post a comment.