smali cannot reassemble baksmali...

[GoogleCodeExporter]

Was doing tests on this one: 
http://pan.baidu.com/s/1bnF22bd#dir/path=/Kirikiroid2

After unpacking with baksmali without parameters I try to reassemble this back, 
no modifications. It works, but only to some precise point - when I try to 
execute a game I get a black screen (seems some of the inner parts fail to run).

If use original classes.dex all works, obv...

I tried apktool and dex2jar, with same results... How is this possible?

Original issue reported on code.google.com by kross...@gmail.com on 3 Mar 2015 at 9:16

[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 mr.je...@gmail.com on 4 Mar 2015 at 10:21

[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 jesusfreke@jesusfreke.com on 4 Mar 2015 at 6:30

[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 mr.je...@gmail.com on 4 Mar 2015 at 11:23

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 jesusfreke@jesusfreke.com on 4 Mar 2015 at 11:45