int-to-char not being translated properly
GoogleCodeExporter opened this issue · comments
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:
[deleted comment]
Is there a branch that it is good in?
Original comment by Nathan....@gmail.com on 11 Feb 2014 at 2:26