search

notishell / smali

Automatically exported from code.google.com/p/smali
0 stars 0 forks source link

Baksmali is broken on HoneyComb #58

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What seems to be the problem?

Can't Deodex HoneyComb odex files

What is the exact smali/baksmali command that you ran?

java -jar baksmali.jar -x Gmail.odex

What version of smali/baksmali are you using? What rom are you working
from?

Baksmali 1.2.6. Motorola Xoom HoneyComb 3.0

What is the airspeed velocity of an unladen swallow?

African or European?

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

UNEXPECTED TOP-LEVEL EXCEPTION:
org.jf.dexlib.Util.ExceptionWithContext: Unknown opcode: f1
        at org.jf.dexlib.Util.ExceptionWithContext.withContext(ExceptionWithContext.java:54)
        at org.jf.dexlib.Code.InstructionIterator.IterateInstructions(InstructionIterator.java:87)
        at org.jf.dexlib.CodeItem.readItem(CodeItem.java:157)
        at org.jf.dexlib.Item.readFrom(Item.java:76)
        at org.jf.dexlib.OffsettedSection.readItems(OffsettedSection.java:48)
        at org.jf.dexlib.Section.readFrom(Section.java:143)
        at org.jf.dexlib.DexFile.<init>(DexFile.java:431)
        at org.jf.baksmali.main.main(main.java:250)
Caused by: java.lang.RuntimeException: Unknown opcode: f1
        at org.jf.dexlib.Code.InstructionIterator.IterateInstructions(InstructionIterator.java:51)
        ... 6 more
Error occured at code address 20
code_item @0x32488

Original issue reported on code.google.com by red...@gmail.com on 24 Feb 2011 at 4:48

GoogleCodeExporter commented 9 years ago 
Unfortunately, I can't fix this until the honeycomb code is released.

Original comment by JesusFr...@gmail.com on 25 Feb 2011 at 3:07

GoogleCodeExporter commented 9 years ago 
Small patch for this missing opcode (0xf1). 
The opcode name and value comes from the latest android-sdk dedexer.

WARNING:
Don't use this patch for rebuild, only decompile into smali.
We need rewrite this patch, when the honeycomb source is released.

Original comment by ferenc.b...@gmail.com on 18 Mar 2011 at 11:10

Attachments:

GoogleCodeExporter commented 9 years ago 
could you please post a JAR version with the patch ?
Thanks.

Original comment by kox...@gmail.com on 23 Mar 2011 at 10:30

GoogleCodeExporter commented 9 years ago 
Of course. :)
GL.

Original comment by ferenc.b...@gmail.com on 23 Mar 2011 at 11:17

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
baksmali-127 works for honeycomb,

but when i use smali-1.2.6 try to assembly it back, i got error like below

java -Xmx512M -jar smali-1.2.6.jar out -o classes.dex

out/org/javia/arity/Derivative.smali[42,4] extraneous input 
'return-void-barrier' expecting END_METHOD_DIRECTIVE
out/org/javia/arity/Symbols.smali[509,4] extraneous input 'return-void-barrier' 
expecting END_METHOD_DIRECTIVE
out/org/javia/arity/Token.smali[66,4] mismatched input 'return-void-barrier' 
expecting END_METHOD_DIRECTIVE
out/org/javia/arity/Compiler.smali[89,4] extraneous input 'return-void-barrier' 
expecting END_METHOD_DIRECTIVE
out/org/javia/arity/EvalContext.smali[111,4] extraneous input 
'return-void-barrier' expecting END_METHOD_DIRECTIVE
out/org/javia/arity/CompiledFunction.smali[90,4] extraneous input 
'return-void-barrier' expecting END_METHOD_DIRECTIVE
out/com/android/calculator2/CalculatorEditText$NoTextSelectionMode$1.smali[35,4]
 extraneous input 'return-void-barrier' expecting END_METHOD_DIRECTIVE
out/com/android/calculator2/CalculatorEditText$NoTextSelectionMode.smali[35,4] 
extraneous input 'return-void-barrier' expecting END_METHOD_DIRECTIVE
out/com/android/calculator2/PanelSwitcher$1.smali[32,4] extraneous input 
'return-void-barrier' expecting END_METHOD_DIRECTIVE
out/com/android/calculator2/Logic.smali[93,4] extraneous input 
'return-void-barrier' expecting END_METHOD_DIRECTIVE
out/com/android/calculator2/CalculatorDisplay$1.smali[32,4] extraneous input 
'return-void-barrier' expecting END_METHOD_DIRECTIVE

We need a smali fix for 1.2.7 correspondingly. Could you share a fixed smali 
zip?

Original comment by AC.xi...@gmail.com on 15 May 2011 at 5:02

GoogleCodeExporter commented 9 years ago 
I was able to fix the recompile error with a small patch but for some reason I 
when I compile with 1.2.7 I can't get honeycomb to boot. 

When I use smali 1.2.6 to rebuild, everything works as expected.

Original comment by Roach2...@gmail.com on 17 Jun 2011 at 1:51

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm getting this error on 1.2.8 for Honeycomb.

Original comment by baggyrab...@gmail.com on 23 Aug 2011 at 10:14

GoogleCodeExporter commented 9 years ago 
Did the source for honeycomb get released while I wasn't looking? ;)

Original comment by jesusfreke@jesusfreke.com on 23 Aug 2011 at 2:25

GoogleCodeExporter commented 9 years ago 
Ice Cream Sandwich sources are out.

Original comment by rustam...@gmail.com on 15 Nov 2011 at 2:46

GoogleCodeExporter commented 9 years ago 
Indeed they are. And I will be closing this issue soon :D

Original comment by jesusfreke@jesusfreke.com on 15 Nov 2011 at 4:08

GoogleCodeExporter commented 9 years ago 
FIXED. 1.3.0 is out, with support for Honeycomb (and ICS). finally!

Original comment by jesusfreke@jesusfreke.com on 21 Nov 2011 at 7:46

GoogleCodeExporter commented 9 years ago 
It solves the 0xf1 problem but still fails on the same odex files for another 
reason:

UNEXPECTED TOP-LEVEL EXCEPTION:
org.jf.dexlib.Util.ExceptionWithContext: regCount does not match the number of 
arguments of the method
    at org.jf.dexlib.Util.ExceptionWithContext.withContext(ExceptionWithContext.java:54)
    at org.jf.dexlib.Code.InstructionIterator.IterateInstructions(InstructionIterator.java:92)
    at org.jf.dexlib.CodeItem.readItem(CodeItem.java:154)
    at org.jf.dexlib.Item.readFrom(Item.java:76)
    at org.jf.dexlib.OffsettedSection.readItems(OffsettedSection.java:48)
    at org.jf.dexlib.Section.readFrom(Section.java:143)
    at org.jf.dexlib.DexFile.<init>(DexFile.java:431)
    at org.jf.baksmali.main.main(main.java:265)
Caused by: java.lang.RuntimeException: regCount does not match the number of 
arguments of the method
    at org.jf.dexlib.Code.Format.Instruction3rc.checkItem(Instruction3rc.java:129)
    at org.jf.dexlib.Code.Format.Instruction3rc.<init>(Instruction3rc.java:79)
    at org.jf.dexlib.Code.Format.Instruction3rc.<init>(Instruction3rc.java:44)
    at org.jf.dexlib.Code.Format.Instruction3rc$Factory.makeInstruction(Instruction3rc.java:145)
    at org.jf.dexlib.Code.InstructionIterator.IterateInstructions(InstructionIterator.java:84)
    ... 6 more
Error occured at code address 0
code_item @0x1454c

Original comment by weiss.y...@gmail.com on 21 Nov 2011 at 9:24

GoogleCodeExporter commented 9 years ago 
Try -a 13, as mentioned in the blog post :)

Original comment by jesusfreke@jesusfreke.com on 21 Nov 2011 at 9:26

GoogleCodeExporter commented 9 years ago 
I did, but then it fails on the new opcodes (0xf1) :)

Original comment by weiss.y...@gmail.com on 21 Nov 2011 at 9:50

GoogleCodeExporter commented 9 years ago 
weiss.yoav: It sounds like you have a honeycomb-esque dalvik. Have you tried -a 
13? 

The 0xf1 opcode was introduced in honeycomb, so -a 13 should work fine for that.

The "regCount does not match the number of arguments of the method" is related 
to the invoke-direct-empty opcode changing to invoke-object-init/range in ICS. 
So -a 13 should work fine for that as well.

update: I see you just said you tried -a 13 and still got the 0xf1 issue. That 
shouldn't happen. I'll take a look and see if I messed up something in the 
api-level configuration

Original comment by jesusfreke@jesusfreke.com on 21 Nov 2011 at 9:53

GoogleCodeExporter commented 9 years ago 
weiss.yoav: the opcode configuration related to 0xf1 looks correct. You 
*shouldn't* be getting an "Unknown opcode: 0xf1" error for -a 13.

Do you happen to have a link to the firmware you are trying to deodex?

Original comment by jesusfreke@jesusfreke.com on 21 Nov 2011 at 9:56

GoogleCodeExporter commented 9 years ago 
My mistake.  I was trying with -a 8 rather than 13 because I thought it has to 
match the source of the odex (which is Android 2.2 in this case, so 
api-leve=8).  With -a 13 (and with the framework files pulled from that 2.2 
ROM, forced using -d), it works just fine.  Thanks.

Original comment by weiss.y...@gmail.com on 21 Nov 2011 at 10:07

GoogleCodeExporter commented 9 years ago 
Yeah, based on the presence of the return-void-barrier opcode, it sounds like 
you have a honeycomb-esque version of dalvik, even though the platform is 
actually 2.2.

Original comment by jesusfreke@jesusfreke.com on 21 Nov 2011 at 10:10

GoogleCodeExporter commented 9 years ago 
Is it a dual-core platform by chance? If so, that would explain why they are 
using the newer version of dalvik, which is SMP-safe.

Original comment by jesusfreke@jesusfreke.com on 21 Nov 2011 at 10:12

GoogleCodeExporter commented 9 years ago 
Yes, it's a 2.2 ROM of a dual-core device and it uses the latest dalvik.

Original comment by weiss.y...@gmail.com on 21 Nov 2011 at 10:15

GoogleCodeExporter commented 9 years ago 
Gotcha. Just to be clear, the --api-level option should be set based on the 
version of dalvik that is being used, as it determines what set of opcodes that 
baksmali expects. In the large majority of cases, that should be the same as 
the api-level of the platform itself :)

In the past, I've ignored the differences between apis and just assumed that 
all opcodes are available. This has worked fine so far because each new 
platform only added new opcodes, they didn't change existing opcodes. However, 
in ICS, they actually modified one of the existing odex-only opcodes, and there 
isn't any good way to automatically detect which opcode baksmali should use.

In general, it should be safe to use -a 13 for any pre-ICS rom, as there are no 
breaking changes from honeycomb on back.

Original comment by jesusfreke@jesusfreke.com on 21 Nov 2011 at 10:29

GoogleCodeExporter commented 9 years ago 
Thanks.  I'll have a look at these new opcodes.  I wonder whether the api level 
can be reliably detected by some heuristics on the way they're used.  It'll be 
enough to find one such opcode, as the api level stays the same for the entire 
runtime.  The existence of 0xf1 in itself isn't enough since it also exists in 
13, but maybe there's some other opcode that was added (rather than changed 
meaning) in 14.  The opcode doesn't even have to appear in the app's odex.  
It's enough that it appears in the framework.odex in use.

...or you could ask the user to specify -a :)

Original comment by weiss.y...@gmail.com on 21 Nov 2011 at 10:45