5

Is reverse engineering managed code from .NET easier or harder? I think it might be Java bytecode that can be easily converted back into source code. Is managed code from .NET similar, and why?

  • I'll let someone else compare .NET to Java, but if the bytecode hasn't been intentionally obfuscated (e.g. by Dotfuscator), it's definitely easier to reverse than unmanaged code. Compare results of dotPeek versus those of Hex-Rays. The VM is a lot less "organically grown" than the x86 architecture (read: much cleaner), and the managed binaries contain a lot more metadata. – DCoder Jun 9 '13 at 14:29
  • 3
    As to .NET versus Java, I find that .NET IL is generally easier to decompile than Java bytecode. For example, the way locals are managed in Java bytecode is more complicated (e.g., double-word types occupy two slots); the end offset of exception handler blocks must be computed manually, as it is not included in the metadata; ranges of local variables may need to be computed if code is compiled without debug information; since Java 5, finally blocks have been inlined. I'm sure there are other minor inconveniences that I am overlooking, though .NET surely has several of its own. – Mike Strobel Jun 10 '13 at 13:12
7

Reverse engineering .net without any anti-reverse engineering protections is trivial.

The reason is that programs like these are compiled down to an intermediate language that we call bytecode which contains high level information (symbol names,data definitions etc) making it possible to recover source code almost similar to the original which simplifies the reverse engineering process.

Because of that obfuscation is very common, so take a look at these .NET Deobfuscation Tools posted at woodmann.

So is .NET malware usually compiled into native images and obfuscated, or is it usually just obfuscated .NET code?

I doubt malware authors want something like .net converted to native code.

The reason behind someone using .net malware is i guess because it can run on many platforms without caring about processor architecture so in .net malware they definitely want CIL to be there.

Also think about the different languages .net supports.

| improve this answer | |
  • I doubt malware authors want something like .net converted to native code. Well I won't be so sure, there might be some advantages to go native over managed. Of course the processor architecture plays an important part however if you are not targeting too exotic devices, you can came up with an acceptable portability assuming only common instruction sets are used. Moreover I think it's actually possible to compile every references into native format, which should make a framework free app. This post has definitely exhausted my curiosity, I will have to try that! – dna Jun 10 '13 at 16:30
  • @dna I agree.I shouldn't have put it that way there might be some advantages on doing that , i just cant think any right now.maybe these can help: symantec.com/connect/blogs/… defcon.org/images/defcon-15/dc15-presentations/… – nomilk Jun 10 '13 at 16:37
  • Thanks for the links. I do agree with you, relying on the CLR is the easiest and most portable way to go - especially since it can focus non Windows OSes as well. Still this article is pretty interesting, ntcore.com/files/netint_native.htm. It introduces a native loader for what I guess - not read everything yet - are a .NET 3.5 native images. Yet the author says it himself : this is just a mess. Shipping the framework along with the app and cheating ngen to target an older CPU. No comment, but still funny! – dna Jun 10 '13 at 19:19
  • @dna Thx for the information ;) – nomilk Jun 10 '13 at 19:34
3

In general, bytecode is easier to reverse engineer than compiled code. It (usually) contains a lot more metadata and uses an idealized computing model. A good obfuscater can make this much harder, but still not nearly as complex as native code written with reverse engineering in mind. This is because bytecode languages don't allow nearly as many 'tricks' as real-world processors because they are designed to be higher level, safer, and portable.

To address your specific issue, you can see how simple the CIL for .NET is at Wikipedia, and MS provides a disassembler in their .NET SDK. Higher-level tools are just a google away.

| improve this answer | |
1

Note that .NET code can also be compiled into native images as described by MS in the article Compiling MSIL to Native Code. this is usally used for obivous security reasons :

  • Code harder to reverse engineer
  • No need of the JIT compiler at runtime
| improve this answer | |
  • Good stuff, thanks guys. So is .NET malware usually compiled into native images and obfuscated, or is it usually just obfuscated .NET code? – zer Jun 10 '13 at 10:58
  • I never analysed a .NET malware. Yet I'm pretty sure you can find them in both formats, probably a little bit more into native binaries. But that's just an educated guess. – dna Jun 10 '13 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.