[odex] .smali differences between decompile and "decompile/recompile/decompile"

[GoogleCodeExporter]

What seems to be the problem?
I'm working on a tool that modifies android framework's services.jar / 
services.odex (depending on the odexed/deodexed ROM). For deodexed ROMs, it's 
working great. But not for odexed ROM: When decompiling services.odex, it seems 
that not all odex commands are being decompiled properly, resulting in 
non-working files (causing bootloops basically) after recompilation, converting 
to odex and patching the signature of the odex file. Second decompile shows 
that the files inside the odex file are different, even though no changes in 
smali code have been done (just for testing.. in my tool I'm actually doing 
changes to several of the smali files). For deodexed ROMs, similar procedure 
(just using different smali/baksmali calls and of course without the odexing) 
works fine and the files are the same even after recompilation/decompilation 
again.

What is the exact smali/baksmali command that you ran?
decompile: java -jar smali\baksmali.jar -a 10 -c 
:core.jar:bouncycastle.jar:ext.jar:framework.jar:android.policy.jar:services.jar
:core-junit.jar:com.motorola.android.frameworks.jar:com.motorola.android.widget.
jar -d c:\___test\framework\ -x framework\services.odex -o framework\classout

compile: call java -jar smali\smali.jar -x -a 10 -o framework\classes.dex 
framework\classout

the resulting classes.dex was inserted into the services.jar file, odexed with 
"/system/bin/dexopt-wrapper $storage/services.jar $storage/services.odex 
$BOOTCLASSPATH " in the phone, signature patched via "busybox dd 
if=/system/framework/services.odex of=$storage/services.odex bs=1 count=20 
skip=52 seek=52 conv=notrunc", then I pulled the file back to PC and decompiled 
(=second decompile)

What version of smali/baksmali are you using? What rom are you working
from?
smali/baksmali 1.3.3
ROM for testing is Motorola Defy+ 2.3.7 stock ROM, rooted.

What is the airspeed velocity of an unladen swallow?
european or african swallow? :)

Please provide any additional information below: error messages, symptoms,
etc.

Found messages like "#Replaced unresolvable odex instruction with a throw
throw p4" in the smali code after the initial decompile process, can provide 
the full framework and my workflow steps for investigation if necessary.

I saw a similar problem here in issues, but that apparently was fixed in one of 
the earlier releases that you published, so I'm not sure if that's something 
different or not. Thank you so much..

Attaching sample files with differences (first decompile is the .original 
filename, second decompile happened after re-compiling/odexing), my 
dexopt-wrapper.sh and the binary (not sure if you need it). The binary comes 
from http://forum.xda-developers.com/showthread.php?t=1703489

Original issue reported on code.google.com by peter.pa...@gmail.com on 13 Sep 2012 at 5:32

Attachments:

• attachment.7z

[GoogleCodeExporter]

Thanks for the report. Normally, the "Replaced unresolvable odex instruction 
with a throw" message is harmless - this is only used in places where the 
object register is provably null, which makes it impossible to deodex - there 
is no way to know the intended type of the register at that point.

In this case, it appears that it thinks p4 is null (see the const/4 p4, 0x0 
shortly before). But in fact, I think it can be a ParcelFileDescriptor.

Can you deodex the original odex again, adding this option to the baksmali 
invocation:

-r ARGS,DEST,FULLMERGE

and then attach the resulting smali file. This will add comments for each 
instruction showing the types of registers at each point, which should help me 
determine if it's getting the types wrong.

Original comment by bgruv@google.com on 13 Sep 2012 at 5:52

• Changed state: Accepted

[GoogleCodeExporter]

Thank you for the quick answer. This time the command was : call java -jar 
smali\baksmali.jar -a 10 -c 
:core.jar:bouncycastle.jar:ext.jar:framework.jar:android.policy.jar:services.jar
:core-junit.jar:com.motorola.android.frameworks.jar:com.motorola.android.widget.
jar -d c:\___test\framework\ -x framework\services.odex -o framework\classout 
-r ARGS,DEST,FULLMERGE

result attached (only the ActivityManagerService.smali).

Original comment by peter.pa...@gmail.com on 13 Sep 2012 at 6:05

Attachments:

• ActivityManagerService.7z

[GoogleCodeExporter]

As far as I can tell, it is deodexed properly. The instruction that was 
replaced with a throw should never be reachable. The value of p4 at that point 
is always null, so the if-eqz just before it will always jump over it.

You do realize that you have to deodex/reodex everything else, when you modify 
a framework odex, right? :). I believe you can also do some trickery with the 
dex signature in the header, but depending on what you changed, that may or may 
not cause problems.

What is the actual errors that you are seeing?

Original comment by jesusfreke@jesusfreke.com on 15 Sep 2012 at 1:24

[GoogleCodeExporter]

the error is bootlooping :) and yes, I'm copying the signature from the old 
service.odex to the new one, which should prevent having to deodex/odex the 
whole framework..

I just tried the following in my phone:

- baksmali the services.odex to classout (folder)
- smali the resulting classout (without any changes to the smali files) to 
classes.dex
- inserting the new classes.dex to the original services.jar
- backup of old /system/framework/services*
- pushing the new services.jar to /system/framework
- creating new services.odex in /system/framework via 
"/system/bin/dexopt-wrapper /system/framework/services.jar 
/system/framework/services.odex $BOOTCLASSPATH"
- patching the sig in the new services.odex via "busybox dd 
if=/system/framework/services.old.odex of=/system/framework/services.odex bs=1 
count=20 skip=52 seek=52 conv=notrunc"
- reboot to recovery, wipe dalvik cache, reboot
- bootloop :)

the actual odexing/patching was however successful.

# sh ./dexopt-wrapper.sh
Root check passed
Found services.jar on currentdir.. good
Found dexopt-wrapper on currentdir.. good
Mounting /system as read-write
Copying dexopt-wrapper to /system/bin
Setting owner 0.2000 for /system/bin/dexopt-wrapper
Setting permissions 755 for /system/bin/dexopt-wrapper
Creating odex from jar
--- BEGIN '/system/framework/services.jar' (bootstrap=0) ---
--- waiting for verify+opt, pid=6440
--- would reduce privs here
--- END '/system/framework/services.jar' (success) ---
Patching signature
20+0 records in
20+0 records out
20 bytes (20B) copied, 0.001465 seconds, 13.3KB/s
Mounting /system read-only

I wish I could capture the logcat during the bootloop, but I can't :/

You said about deodexing/reodexing everything else - would that mean to 
deodex/reodex every single file in the BOOTCLASSPATH, or even every file 
(odex/apk) in /system/framework ?

Original comment by peter.pa...@gmail.com on 15 Sep 2012 at 10:32

[GoogleCodeExporter]

"bootlooping" is not an error. It is a symptom :)

Why can't you get logcat? It comes up early in the boot process. If nothing 
else, just do a framework stop and start after replacing the odex, rather than 
a full restart of the device.

Original comment by jesusfreke@jesusfreke.com on 15 Sep 2012 at 11:08

[GoogleCodeExporter]

ok, here the log of creating the new odex, replacing the stock one, stopping 
and starting framework.

It rebooted the phone, this time without bootloop, and I tried to reboot one 
more time, without a bootloop. I have to say, I'm clueless. But I'm pretty 
confident now that your tool baksmali/smali is not the problem. I'll be out for 
the next 10+ hours, but then I'll try to do this again, this time with .smali 
code changes.

Attaching [log.txt] during and after the new services.odex creation/patching,
[log2.txt] after the next reboot (with the new services already)

Original comment by peter.pa...@gmail.com on 15 Sep 2012 at 12:35

Attachments:

• log.7z

[GoogleCodeExporter]

I would tend to agree. I'm not sure what's going on, but it doesn't seem like 
it's a problem with baksmali :)

Original comment by jesusfreke@jesusfreke.com on 15 Sep 2012 at 6:50

• Changed state: Done

[GoogleCodeExporter]

You actually pointed me into the right direction with looking at the log during 
the framework restart .. I think I've got it now. Thank you for all the help 
(and for the wonderful tools) :)

Original comment by peter.pa...@gmail.com on 16 Sep 2012 at 12:22

[GoogleCodeExporter]

I've just fallen into the same problem when trying to deodex my services.jar 
separately. Would you please share what did you do to get it solved Peter? Any 
helps would be appreciated.

Alex

Original comment by alex.donh on 26 Dec 2014 at 5:06