Free?

[Chante]

"Daniel Gibson" <metalcaedes at gmail.com> wrote in message 
news:j8hppc$2nei$2 at 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