smali cannot reassemble baksmali...

[GoogleCodeExporter]

smali cannot reassemble baksmali...

[GoogleCodeExporter]

I've got the same problem on a different APK.
It seems that when using baksmali -> smali without modifications the new 
classes.dex file is not the same as the original.

I've used baksmali on the new classes.dex and done some comparing, I found that 
lines like:
.field public static result:Landroid/content/Intent; = null
bacame:
.field public static result:Landroid/content/Intent;

and:
.field public static final TEST_android_focusable:I = 0x0
became:
.field public static final TEST_android_focusable:I

I guess this can cause the unexpected behavior since the fields initialization 
is missing. 

Original comment by [email protected] on 4 Mar 2015 at 10:21

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Nah, those two are semantically identical. result and TEST_android_focusable 
will be initialized to null and 0 in both cases.

Original comment by [email protected] on 4 Mar 2015 at 6:30

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

OK, but this is not the only difference, take a look at the attached two smali 
files.
con#.7 is the file after backsmali on the original classes.dex, conN#.7 is the 
file after I smali and baksmali again to see the differences.
The content is pretty different (and for some reason it changed the N to upper 
case, not sure if it matter).

Original comment by [email protected] on 4 Mar 2015 at 11:23

• Added labels: ****
• Removed labels: ****

Attachments:

• con#.7.smali
• coN#.7.smali

[GoogleCodeExporter]

Those are 2 completely unrelated classes. The #.7 is an arbitrary suffix, which 
is based on the (potentially non-deterministic) order that the classes are 
processed in. 

It's common for obfuscators to use names like that, that differ only in case, 
in an attempt to make tools mis-handle the classes.

baksmali detects that it is on a case-insensitive filesystem, and ensures that 
files with names that only differ in case are written to distinct files. To 
ensure they are distinct, it adds a suffix like #.1, #.2, etc. However, the 
suffix is non-deterministic - in that it depends on the order that the classes 
are processed in. So in this case, these are actually 2 different classes. The 
other con class might be in con.smali, or con#.1.smali, etc.

When smali re-assembles the classes, the filename is ignored, so it doesn't 
affect the resulting dex file. The class name is taken from the .class 
directive. So it would be Lcon; and LcoN; respectively, regardless of the name 
of the file.

Original comment by [email protected] on 4 Mar 2015 at 11:45

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

This is likely to be due to some sort of tamper-checking code in the apk.

Original comment by [email protected] on 17 Mar 2015 at 3:39

• Changed state: Done
• Added labels: ****
• Removed labels: ****