Dynamic Code Encryption as an Anti Dump and Anti Reverse Engineering measure
syprog.blogspot.com
syprog.blogspot.com
Adobe, for example, used to go to great lengths to prevent people from cracking their software. In the end, though, a crack still came out within a few weeks. Was it really worth months of highly-paid-developer-time to slow down piracy for maybe a month at best? (Evidently not, since CS5 and above can be disabled by adding a line to your HOSTS file.)
Even as an individual who's sold software in the past, it's usually not worth it. I don't have the time myself, and commercial software which does this costs hundreds to thousands of dollars. I may not be happy if people pirate my software (I'm actually fine with it), but it's not worth the cost to prevent it.
That said, I found the article extremely interesting!
I dream of never needing to get something reproduced because when something goes wrong there is a real useful data and execution trace, no matter whether the bug manifested as a crash or incorrect behavior. IMO the compilation/execution strategy of chicken scheme is a big step towards enabling this.
IMO good software has the same properties as good hardware: the internals accessible to diagnose and solve problems.
Sure, people may "steal" your code, but then again, if your business model relies on keeping code secret instead of being helpful to customers, you have already lost. You're not some kind of priest protecting your superior, holy code from lesser minds.
Edit: Also, code obfuscation says "I don't trust you, customer!" if nothing else.
(And implying that software vendors who don't obfuscate their code shouldn't complain about piracy seems analogous to the old chestnut of blaming rape victims for dressing immodestly).
Also interesting to see an article like this on the front page of HN...
For building your own virtual machines, check out the ideas of the people here (Mips virtual machine should be easy, and enough to fool noobie-moderate level crackers) http://stackoverflow.com/questions/573115/what-is-your-favou...
For antidebugging tricks, Peter Ferrie has pretty much written the bible on these when it comes to Windows: http://pferrie.host22.com/papers/antidebug.pdf There's a couple of these papers, make sure you read all of them. For platforms other than Windows, you will have to come up with your own stuff, or Google well :)
For obfuscation, the best tricks are the ones you see in the real world. Check out the excellent Unpackme archives and tutorials of tuts4you: http://tuts4you.com/download.php
Another book on obfsucation that I see get mentioned a lot (which I don't recommend, but it still deserves a mention) is this one: http://www.amazon.com/Surreptitious-Software-Obfuscation-Wat...
And finally, if you're a noobie interested in getting involved in Reverse Engineering, check out Lena's excellent tutorial series: http://tuts4you.com/download.php?view.2876
If you want more info on anything specific, say so...
They're all "trivial" to remove for a given value of "trivial." What you can do is to detect whether or not exactly the intended code is running, and you can only get away with this for awhile if you separate the detection from any visible consequences by a significant time span.
Also interesting to see an article like this on the front page of HN...
We've seen things like this time and again: Technology X fails at task Z. The conventional wisdom is that technology X is somehow hopeless in the entire problem domain. Everyone is scared of using technology X. Someone realizes that technology X >can< be used for task Y, but everyone just laughs at him and spouts the conventional wisdom.
It's easy to recognize things like this in hindsight. What's hard is to recognize them ahead of time and to profit from the information asymmetry. For this reason, I think this is appropriate for the front page of HN.
now if you can avoid that (by applying some transform that allows the program to function but without having to carry its inverse) then ...