"Daniel Gibson" <metalcae...@gmail.com> wrote in message news:j8hppc$2nei$2...@digitalmars.com... > Am 28.10.2011 05:18, schrieb Chante: >> Daniel Gibson wrote: >>> Am 26.10.2011 23:38, schrieb Steven Schveighoffer: >>>> >>>> But it's much harder to reverse engineer how someone built a machine >>>> than it is to reverse engineer how software is built. >>> >> >> Note that reverse-engineering is like copying someone else's homework. >> It >> doesn't build any engineering capability. It actually hinders such >> from >> occurring.
Ha! I answered your question of the other post here before you asked it! Kudos to moi! >> >>> Really? >>> I guess it depends on the machine but I imagine it isn't so hard to >>> dismantle a machine to find out how it works? (But I have no >>> experience with that, it's just a guess) >>> Reverse Engineering software can be pretty hard if the author made it >>> deliberately hard, like Skype. >>> >> >> Interesting. How did Skype's engineer make it hard to >> reverse-engineer? >> Have a link? >> >> > > http://www.cs.columbia.edu/~salman/skype/ here are some links. > For example "Silver Neede in the Skype" seems to have some information, > I didn't look at the other stuff. I will check that out next week. Thanks. > > One way to make reverse engineering harder is trying to detect > debuggers (by measuring time and stuff takes longer if a debugger is > involved etc) and then cease working. I was just thinking "deterent" rather than "bullet proof". As such, maybe I'd use: 1. Built-in mechanisms to prevent end-user copying (many possibilities). 2. An obfuscator on the source before compilation. 3. Compression/expansion, use of TPM, etc. 4. Encryption, where it can be applied (operational behavior, not on source code). 2 and 3 seem real easy to automate: as easy as pushing the "compile" button. 1 seems like a small, internally-used library. Oh, so does 4. > > Interestingly Skype for Linux didn't work on my sisters notebook