How do commercial obfuscators achieve to crash .net Reflector and ILDASM ?

Question

Some commercial obfuscators claim they can crash ILDASM (and other similar tools such as Reflector)

Any idea on how they achieve that?

As stated in numerous threads here, someone with enough motivation/time/skill will always find a way to read your code (aka if it's runnable, it's decompilable), but it seems to me that most casual code readers won't bother decompiling my code if Reflector can't do it for them.

This level of protection of my IP (ie, protected against anybody but the hardcore guys who would probably find a way around every single trick I would throw at them anyway) would definitely be enough for me.

Answer 1

Some quite possibly introduce invalid IL which the CLR is able to run but ILDASM etc don't handle. To my mind that's a Bad Thing - the CLR may well complain about it in the future.

Other ones may well create valid IL which just happens to trip up ILDASM and Reflector due to being unexpected in some way. As a silly example, suppose an identifier contains an unprintable character. From what I remember, this is valid as the CLR treats identifiers as opaque blobs, but something trying to display them may well fail. This is likely to only be a temporary help - while ILDASM isn't updated that often, Reflector has frequent updates and I'd expect the developers to fix issues like this when they find out about them.

The third alternative which helps against high level decompilation but not disassembly is to create IL which has no obvious analog in C#/VB, but which is perfectly valid. In fact, iterator blocks sometimes already do this (look near the bottom of the article).

I would expect anything that's legal and guaranteed to be runnable to be disassemblable (urgh) either now or at least some time in the future. Crashing Reflector now (or rather, when the marketing blurb was written) isn't a good indication of future crashing.