5 ms·

This is about Dalvik bytecode format, but the same applies to standard Java bytebode files. Practically any obfuscated Java code will have this, which makes rev

This is about Dalvik bytecode format, but the same applies to standard Java bytebode files. Practically any obfuscated Java code will have this, which makes reverse engineering much more difficult without the tools to handle it.

HighlandSpring 10y ago
Why is it not as simple as mapping the method call instructions to returntype_methodname format? Am I missing something?
- Flowdalic 10y ago
  What if the call site does not use the returned value?
  - tokenizerrr 10y ago
    It's still present in the bytecode (since the VM has to know which method to call).
  - masklinn 10y ago
    The bytecode encodes that information, the method identifier includes name, parameter types and return type.
- barahilia 10y ago
  Yes. Because of overloading there may be 2 functions with the same name and the same return type but different arguments. So you need to include them too.
  - tokenizerrr 10y ago
    No. Java itself handles the differing arguments.
    - MichaelGG 10y ago
      Well one obfuscation technique is to change the argument types. So for instance, you might have foo(string). But after obfuscation, you move the code of foo(string) into foo(object). So a decompiler ends up showing: String s = "123"; foo(s); Java will call foo(string) if this is re-compiled, which is wrong. The decompiler would need to show foo((Object)s). On the CLR you can go even further and erase a lot of the type info and just pass objects around. That is, you can just change all your method signatures to foo(object, object, object) no matter which classes (not structs) you pass. Or have even more fun and randomize the classes. So now foo(string) becomes foo(DBConnectionInfo).
      - tokenizerrr 10y ago
        For that specific example that would actually be fine in Java. Everything is an Object, so even if you have foo(Object) you can just pass it a String and that is then fine both for the JVM and the Java compiler. Since the JVM identifies methods by their name + argument types this would most likely break overloading unless done very carefully. I've decompiled quite a few Java applications and haven't seen anything like this either, but perhaps I've just had the luck to not yet run into it.
        MichaelGG 10y ago
        It wouldn't be fine. It'd call the wrong method. The bytecode invokes the foo(object) one, but a naive decompiling would invoke foo(string). A cast would be required to get it to resolve correctly. Or am I misunderstanding?
        tokenizerrr 10y ago
        I'm talking about decompiled code, which would turn out looking something like http://ideone.com/HCOLU4 http://ideone.com/HCOLU4 which compiles and runs just fine. Maybe I am misunderstanding what you mean?
      - barahilia 10y ago
Animux 10y ago
Do you have some examples for tools to handle the deobfuscation stuff?

HighlandSpring 10y ago

Why is it not as simple as mapping the method call instructions to returntype_methodname format? Am I missing something?

Flowdalic 10y ago
What if the call site does not use the returned value?
- tokenizerrr 10y ago
  It's still present in the bytecode (since the VM has to know which method to call).
- masklinn 10y ago
  The bytecode encodes that information, the method identifier includes name, parameter types and return type.
barahilia 10y ago
Yes. Because of overloading there may be 2 functions with the same name and the same return type but different arguments. So you need to include them too.
- tokenizerrr 10y ago
  No. Java itself handles the differing arguments.
  - MichaelGG 10y ago
    Well one obfuscation technique is to change the argument types. So for instance, you might have foo(string). But after obfuscation, you move the code of foo(string) into foo(object). So a decompiler ends up showing: String s = "123"; foo(s); Java will call foo(string) if this is re-compiled, which is wrong. The decompiler would need to show foo((Object)s). On the CLR you can go even further and erase a lot of the type info and just pass objects around. That is, you can just change all your method signatures to foo(object, object, object) no matter which classes (not structs) you pass. Or have even more fun and randomize the classes. So now foo(string) becomes foo(DBConnectionInfo).
    - tokenizerrr 10y ago
      For that specific example that would actually be fine in Java. Everything is an Object, so even if you have foo(Object) you can just pass it a String and that is then fine both for the JVM and the Java compiler. Since the JVM identifies methods by their name + argument types this would most likely break overloading unless done very carefully. I've decompiled quite a few Java applications and haven't seen anything like this either, but perhaps I've just had the luck to not yet run into it.
      - MichaelGG 10y ago
        It wouldn't be fine. It'd call the wrong method. The bytecode invokes the foo(object) one, but a naive decompiling would invoke foo(string). A cast would be required to get it to resolve correctly. Or am I misunderstanding?
        tokenizerrr 10y ago
        I'm talking about decompiled code, which would turn out looking something like http://ideone.com/HCOLU4 http://ideone.com/HCOLU4 which compiles and runs just fine. Maybe I am misunderstanding what you mean?
    - barahilia 10y ago

Animux 10y ago

Do you have some examples for tools to handle the deobfuscation stuff?