search

omanand / dex2jar

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

int-to-char not being translated properly #214

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 

What steps will reproduce the problem?
1. Decompile attached apk
2. Rebuild apk using decompiled jar
3. Deploy to a phone, try to connect to an ssh server.

What is the expected output? What do you see instead?
The working apk connects to the ssh server just fine.  The translated apk 
crashes at this point, with the following output in logcat:

02-04 11:11:18.826: W/dalvikvm(19628): VFY: register1 v1 type 7, wanted 16
02-04 11:11:18.826: W/dalvikvm(19628): VFY:  rejecting opcode 0x76 at 0x0026
02-04 11:11:18.826: W/dalvikvm(19628): VFY:  rejected 
Lde/mud/terminal/vt320;.putString ([C[BII)V
02-04 11:11:18.826: W/dalvikvm(19628): Verifier rejected class 
Lde/mud/terminal/vt320;

What version of the product are you using? On what operating system?
0.0.9.15 on Ubuntu Linux 13.10

Please upload the file which cause the issue if possible.

Please provide any additional information below.

I've done some pretty substantial investigation into this problem using the 
attached apk, and the source code for the project which can be found at 
https://code.google.com/p/connectbot/  The long and short of it is that a 
particular method - putString(char[], byte[], int, int) - fails to verify when 
it has been compiled back to java bytecode using dex2jar and then recompiled to 
dex bytecode using dx.  The reason why it fails is that there is a missing 
int-to-char call.

The original java bytecode - compiled directly from the connectbot source 
before then being passed to dx - for calling putChar from the putString method 
looks like this:

 ...
 38 aload_0
 39 iload 5
 41 i2c
 42 iload 7
 44 iconst_0
 45 invokespecial #260 <de/mud/terminal/vt320.putChar>
...

But the decompiled version that dex2jar reverse engineers from the dex bytecode 
looks like this:

...
 42 aload_0
 43 iload 5
 45 iload 6
 47 iconst_0
 48 invokespecial #983 <de/mud/terminal/vt320.putChar>
...

The i2c call is missing.  Similarly the decompiled versions of the original apk 
and the translated apk in my smali format look like this:

    int-to-char v5, v3

    invoke-direct {p0, v5, v2, v7}, Lde/mud/terminal/vt320;->putChar(CZZ)V

versus this:

    invoke-direct {p0, v4, v0, v1}, Lde/mud/terminal/vt320;->putChar(CZZ)V 

The method call in question looks like this before it is compiled:

putChar((char) lastChar, isWide, false);

I have attached the original java source for the class in question as well, 
which is vt320.java, just to give you a better idea of what the original code 
looked like.  I have also attached vt320.class.good and vt320.smali.good, which 
represent the java and dex bytecode files used to produce the original, correct 
apk.  And I have attached vt320.class.bad and vt320.smali.bad, which represent 
the java bytecode file you get when you decompile the currect apk using dex2jar 
and the dex bytecode that vt320.class.bad then produces when recompiled using 
dx.

Original issue reported on code.google.com by Nathan....@gmail.com on 7 Feb 2014 at 5:22

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Is there a branch that it is good in?

Original comment by Nathan....@gmail.com on 11 Feb 2014 at 2:26