[odex] .smali differences between decompile and "decompile/recompile/decompile"
Closed this issue · 9 comments
GoogleCodeExporter commented
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:
GoogleCodeExporter commented
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 commented
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:
GoogleCodeExporter commented
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 commented
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 commented
"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 commented
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:
GoogleCodeExporter commented
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 commented
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 commented
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