search

ans-ashkan / smali

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

Number of methods greater after decompiling/recompiling using version 2.0.3 #206

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What seems to be the problem?
There is an APK that I am able to decompile, inject some code, and recompile 
without any problem with smali/baksmali version 1.3.3.
However, when I try to do the same thing with smali/baksmali version 2.0.3, I 
get an UNEXPECTED TOP-LEVEL EXCEPTION that indicates I have too many methods. 
Does smali/baksmali version 2.0.3 work differently than 1.3.3 that can 
potentially add more methods to the APK?

What is the exact smali/baksmali command that you ran?
java -jar baksmali-2.0.3 <myApk>
java -jar smali-2.0.3 <myApk>

What version of smali/baksmali are you using? What rom are you working
from?
Version 2.0.3 was the one giving me problems

What is the airspeed velocity of an unladen swallow?

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

Original issue reported on code.google.com by dongjuna...@gmail.com on 31 Mar 2014 at 8:04

GoogleCodeExporter commented 9 years ago 
stack trace?

Original comment by jesusfreke@jesusfreke.com on 31 Mar 2014 at 8:20

GoogleCodeExporter commented 9 years ago 
    [junit] UNEXPECTED TOP-LEVEL EXCEPTION:
    [junit] org.jf.util.ExceptionWithContext: Unsigned short value out of range: 65554
    [junit]     at org.jf.dexlib2.writer.DexDataWriter.writeUshort(DexDataWriter.java:116)
    [junit]     at org.jf.dexlib2.writer.InstructionWriter.write(InstructionWriter.java:312)
    [junit]     at org.jf.dexlib2.writer.DexWriter.writeCodeItem(DexWriter.java:980)
    [junit]     at org.jf.dexlib2.writer.DexWriter.writeDebugAndCodeItems(DexWriter.java:759)
    [junit]     at org.jf.dexlib2.writer.DexWriter.writeTo(DexWriter.java:214)
    [junit]     at org.jf.dexlib2.writer.DexWriter.writeTo(DexWriter.java:192)
    [junit]     at org.jf.smali.main.main(main.java:227)

Original comment by dongjuna...@gmail.com on 31 Mar 2014 at 8:25

GoogleCodeExporter commented 9 years ago 
Hmm, yeah. that does looks like a method index issue. Can you try compiling it 
with your modifications with 1.3.3 and then disassembling it again? Does it 
have any invoke-*/jumbo methods?

I can't think of any reason that the method count should be different between 
the two versions, so the only thing I can think of is that maybe 1.3.3 is 
automatically using the (now-defunct) /jumbo instructions. I can't remember 
offhand how I had that implemented in the v1 code.

Original comment by jesusfreke@jesusfreke.com on 31 Mar 2014 at 8:45

GoogleCodeExporter commented 9 years ago 
So after decompiling, adding modifications, and recompiling with 1.3.3, I was 
not able to decompile it again with 1.3.3.

I get the following error:
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:91)
        at org.jf.dexlib.CodeItem.readItem(CodeItem.java:154)
        at org.jf.dexlib.Item.readFrom(Item.java:77)
        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:278)
Caused by: java.lang.RuntimeException: regCount does not match the number of 
arguments of the method
        at org.jf.dexlib.Code.Format.Instruction35c.checkItem(Instruction35c.java:161)
        at org.jf.dexlib.Code.Format.Instruction35c.<init>(Instruction35c.java:93)
        at org.jf.dexlib.Code.Format.Instruction35c$Factory.makeInstruction(Instruction35c.java:168)
        at org.jf.dexlib.Code.InstructionIterator.IterateInstructions(InstructionIterator.java:82)
        ... 6 more
Error occured at code address 24
code_item @0x1de924

i did not have any invoke-*/jumbo methods. Only thing with "jumbo" in the code 
was const-string/jumbo

Original comment by dongjuna...@gmail.com on 31 Mar 2014 at 11:52

GoogleCodeExporter commented 9 years ago 
Ah, ok. This actually sounds like it was a bug in the earlier smali then. It 
probably truncated the method ids > 64k, essentially wrapping back around to 0. 
With the new smali, it correctly detects the problem and bails.

There's not much I can do here. The only thing I can think of would be to add 
an option similar to dx's to generates multiple dex files if needed. But you 
could get the same effect by splitting the .smali files into 2 separate dirs 
and assembling each separately.

Original comment by jesusfreke@jesusfreke.com on 31 Mar 2014 at 11:57

GoogleCodeExporter commented 9 years ago 
I see... But are you certain that it truncated the method ids > 64k? I have 
also gotten error in the previously version of smali about having too many 
methods.

The error message in the previous version looked like this:
org.jf.dexlib.Util.ExceptionWithContext: method index is too large. 67025

If it truncated the method ids > 64k, wouldn't it not be able to get this error?
Thank you so much for your help by the way.

Original comment by dongjuna...@gmail.com on 1 Apr 2014 at 12:08

GoogleCodeExporter commented 9 years ago 
Any updates on my comment above?

Original comment by dongjuna...@gmail.com on 14 Apr 2014 at 11:17

GoogleCodeExporter commented 9 years ago 
I'm not sure what the issue was in the previous version. As far as I can tell, 
it's working correctly in the current version.

Original comment by jesusfreke@jesusfreke.com on 14 Apr 2014 at 11:22