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.
>
>> 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.

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.

Interestingly Skype for Linux didn't work on my sisters notebook (crashed shortly after starting), but when started in gdb (gnu debugger) it works fine.. dunno if this is related to anti-reverse engineering/debugging stuff not working properly, but I can imagine that all this voodoo breaks under certain circumstances.

Cheers,
- Daniel

Am 28.10.2011 08:49, schrieb Chante:
> I still don't know why anyone bothers doing this. I have no worries about
> that kind of thing (well, not very much and certainly "orders of
> magnitude" less relatively). I worry about releasing novel software with
> the obvious innovations unprotected. Released unprotected, effectively
> puts me out of business the moment Billion Dollar Bitch Software catches
> the drift and sucks up the market. Stops my innovation in its tracks.
> What other than patent can help with this?

A patent won't help you, Billion Dollar Bitch Software has tons of patents and you'll certainly violate some of them.
(And if not they'll claim you do and sue you until you're bankrupt)

"Daniel Gibson" <metalcaedes@gmail.com> wrote in message news:j8hp8a$2nei$1@digitalmars.com...
> Am 28.10.2011 05:31, schrieb Chante:
>> Daniel Gibson wrote:
>>> Am 26.10.2011 23:52, schrieb Steven Schveighoffer:
>>>> On Wed, 26 Oct 2011 17:51:11 -0400, Daniel Gibson <metalcaedes@gmail.com>  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.
>>>>>
>>>>> 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.
>>>>
>>>> If you have no idea how a material is built, such as a new kind of glass, you have to guess.
>>>
>>> Ok, for materials it's probably hard, but there is a possibility of
>>> chemical analysis and stuff like that.
>>> But I guess for things like e.g. car engines it may be easier
>>> (besides
>>> maybe special/new materials used).
>>
>> It's not worth it. If a company is relying on a competitor's engines
>> to
>> develop it's own, it's effectively out of the business of engineering
>> (it's just then a manufacturer of other company's products perhaps).
>> Competitive analyis is fine, but a company cannot be in the engine
>> business without the required engineering prowess required for that.
>>
>
> I don't know.
> I guess you could claim the same thing about companies who have to
> steal code from other companies instead of writing it themselves.

Well isn't that within the realm of what I said?

>
> So what's the difference between "competitive analysis" and "looking at foreign code" anyway?

Looking at source code is just discovering how to do it. Meaning the one doing the looking has no capability: the proverbial "freerider" ("freeloader"?). Evaluating a competitor's software application program for features and usage, etc. is what I'd put in the realm of "competitive analysis".

In the engine company I used to work for, once in five years I remember having to dyno-test a competitor's engine (the company I worked for had it purchased for us) to evaluate what the thing actually did in regards to torque and horsepower. We didn't do much with it at all except for those kinds of things, for dyno cell time was limited and was better put to use on our own engines than a competitors. They did the same things with ours for sure. "Finding the coca-cola formula" of the engine though? What's the point? (Surely the concept of "what's the point?" is lost on the "freerider").

> How can you be sure that your engineers don't copy ideas from competitors engines?
>

What's to copy? The engine block color? The chrome valve covers? We had engineers going to the same advanced training, and supporting the same curriculums at universities and such as the competitors, and there aren't that many secrets. And even "the secrets", aren't important. What about "the silver bullet" though, you ask? Anyone wanting source code, should simply go work for the company producing the products, because those have already admitted they are incapable of producing anything out of the ordinary on their own. I think that because source code gets transformed into a binary executable, people want it because of it's ellusiveness. Give it to them, and they will be dissastisfied and need more "fix". It's never enough, because there is nothing really there. Ignore a girl, and she'll be attracted to you (Tha is, IF, you "have" another girl... loners/losers need not apply). Fall for her though, then the baddest boy on the block will be bangin' her while you can just go find "God" or something and "leave me alone already! (when she finds out that the 70k 'vette came from engineering rather than sales jobs)". Grass is greener... where?

Let's "get to the crux" of what you asked though, and enough with my banter. You used the words: "engineers" and "copy". Tell me, do find any oxymoronishness, to using those two words in the same sentence?

"Daniel Gibson" <metalcaedes@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

"Daniel Gibson" <metalcaedes@gmail.com> wrote in message news:j8hpvm$2nei$3@digitalmars.com...
> Am 28.10.2011 08:49, schrieb Chante:
>> I still don't know why anyone bothers doing this. I have no worries
>> about
>> that kind of thing (well, not very much and certainly "orders of
>> magnitude" less relatively). I worry about releasing novel software
>> with
>> the obvious innovations unprotected. Released unprotected, effectively
>> puts me out of business the moment Billion Dollar Bitch Software
>> catches
>> the drift and sucks up the market. Stops my innovation in its tracks.
>> What other than patent can help with this?
>
> A patent won't help you, Billion Dollar Bitch Software has tons of
> patents and you'll certainly violate some of them.
> (And if not they'll claim you do and sue you until you're bankrupt)

What's that supposed to mean? That I should feel threatened? That I am afraid? I never worked for them. I don't have access to their "patents". Did you mean, but "oh, they were first-to-file"? If I was a warrior, which I am not, I might take that kind of thing as a warring behavior. Since I am not a warrior though, maybe it could be comprehended as an oppressive behavior. (I shouldn't have used the word "bitch", because "ain't no bitch, ever started a war"). (Not that I'd ever work for one though).