3 ms·

Just run the dex2jar tool on any android .apk and view the results in jd-gui. I've looked at a few apk's and weirdness like the one noted above is quite common.

by gardarh 14y ago

Just run the dex2jar tool on any android .apk and view the results in jd-gui. I've looked at a few apk's and weirdness like the one noted above is quite common. The code is being reverse engineered from a .smali file and the reverse engineering process appears imperfect. Of course any const names would be stripped away from the decompiled code leaving hardcoded integers (such as the 0 in paramArrayOfX509Certificate[0].checkValidity() ). I'm not saying that the conclusion of the article is wrong, I'm merely trying to explain why the code blob above looks so weird.

sukuriant 14y ago
0 is the first element in the array; so, I bet that wasn't a constant, but honestly what the programmer did. In either case, we have the bytecode; and shouldn't what is written above compile to the same bytecode?
- gardarh 14y ago
  To demonstrate my point, try writing the following into C.java: public class C { public int foo() { return 1; int b = 1 + 2; } } Then compile it (javac C.java). You will get the following: C.java:4: unreachable statement int b = 1 + 2; ^ C.java:5: missing return statement } ^ 2 errors Therefore this code is not compileable, thus telling us that the initial code blob could never have run in the first place. I'm not sure why the decompiler returns non-compiling java code, I just know it does.
- jgeralnik 14y ago
  Some code obfuscators will introduce illegal programming constructs. Most VMs will tolerate these but the decompiled source cannot be recompiled without fixing these. Not saying that's what happened here, but it is an option.
  - sukuriant 14y ago
    So it is a very real possibility that an obfuscation technique that basically throws random bits of code with random extra params in another method and calls them at it would could have been used here. Interesting. It would certainly make more sense.

by gardarh 14y ago

sukuriant 14y ago

0 is the first element in the array; so, I bet that wasn't a constant, but honestly what the programmer did. In either case, we have the bytecode; and shouldn't what is written above compile to the same bytecode?

gardarh 14y ago
To demonstrate my point, try writing the following into C.java: public class C { public int foo() { return 1; int b = 1 + 2; } } Then compile it (javac C.java). You will get the following: C.java:4: unreachable statement int b = 1 + 2; ^ C.java:5: missing return statement } ^ 2 errors Therefore this code is not compileable, thus telling us that the initial code blob could never have run in the first place. I'm not sure why the decompiler returns non-compiling java code, I just know it does.
jgeralnik 14y ago
Some code obfuscators will introduce illegal programming constructs. Most VMs will tolerate these but the decompiled source cannot be recompiled without fixing these. Not saying that's what happened here, but it is an option.
- sukuriant 14y ago
  So it is a very real possibility that an obfuscation technique that basically throws random bits of code with random extra params in another method and calls them at it would could have been used here. Interesting. It would certainly make more sense.