Robert Cringeley, in a post early last year, raised some concerns about reverse engineering .NET code:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2005/05/obfuscating-code.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2005/05/obfuscating-code.html
Another option is to ship source. I’ve debugged problems in Delphi apps by stepping into the VCL (Visual Control Library) to see where it was blowing up. Typically it was because my code was doing something bad that it wasn’t expecting.
This way, you can see what’s going under the covers, and can ship an optimised binary. The best of both worlds.
Right. A lot of companies make the (smart, IMHO) decision to sell source licenses and bypass all these issues entirely. I believe Dan Appleman’s stuff is like that:
Using dotNET greatly effects vertical market companies as it exposes their algorithims and other trade secrets. These are companies that serve a narrow market such as health care, CNC controllers, etc.
Security by obcurity is indeed not good to rely on. But it does drive up the cost of reverse engineering as well as other measures. My company made CNC machinery and tried for years to work with our competition. Slowy over the course of a decade we manage to import and export data to most of our competition’s machine. But it was costly and the translation often imperfect. However since our competition went to a dotNET version finding out how to import and export their data has been been two orders of magnitude easier.
The whole process has left me wondering the wisdom of using dotNET in a commerical application. Applications have their innermost secrets exposed when written in a dotNet language. Granted the internals of DLLs and ActiveX components are still as difficult to decode even if they are called from a dotNet application. But needing to code trade secrets in an older framework in order to keep them is defeating the benifits of dotNET.
We found this little fact when poking around with the Reflector. Just grab a commercial product written in .NET and run the Reflector against it. Take, for instance, ASPNET Menu…not legally of course, you could have your own version of that nice product by staring at the source code and decompiling it. It’s wrong…but it works. Remember though…folks have done this for years with Java byte code.
I firmly believe that tools like Reflector and it’s decompiler actually make the .NET platform a more attractive environment to work with. Developer documentation is always insufficient (if not downright inaccurate) - having instant, easy access to the source for any (managed) component - especially the BCL itself, makes a developer far more productive, and thus makes the platform itself more appealing.
I personally find Reflector every bit as useful as downloadable source - maybe more so, because it doesn’t involve downloading big code bases, mucking around in Visual Studio, etc. I’ve never felt the need to download Rotor, for example.
“If you’re shipping high-level source code in any form, including bytecode, self-hosted executables, or encrypted bundles, you’re ultimately shipping your source code. Get used to that idea, or go back to writing in C.”
http://www.matasano.com/log/1055/de-obfuscation-for-the-impatient/
If programs are for communicating with other programmers, why do we have a contest that encourages such complete perversions of best practises?
I’d like to note that the image* of the maid-girl’s head is that of the character Rinia from Moekan / Moekko Company.
More info at the IOCCC:
http://www0.us.ioccc.org/2004/omoikane.hint
http://www0.us.ioccc.org/whowon.html
