Re: executable obfuscator?
Re: executable obfuscator?
- Subject: Re: executable obfuscator?
- From: Greg Guerin <email@hidden>
- Date: Thu, 14 Dec 2006 15:28:22 -0700
Steve Hershey wrote:
>3. intellectual property discovery
>
>The impetus for my question was #3, but the thread
>drifted toward #1, which is not surprising since many
>developers on this list would like to prevent
>'cracked' versions of their software from appearing in
>the public domain.
>
>The papers I found on-line didn't mention things that
>I could do to source code that would have a beneficial
>effect on executables. The next step for me is to
>actually disassemble some gcc executables and see what
>hackers actually see. Naked strings may well stand out
>as an
>obvious source of information to would-be hackers.
You still need to define who you're defending against. If you don't know
that, you can't make a good decision.
Just because you can't see a vulnerability doesn't mean someone else won't.
That's one reason security is hard: you can use a lock that you can't
break, but someone else with more skill or different ideas might well be
able to defeat that lock without difficulty.
Protecting IP embodied in executables is profoundly difficult. It's more
of an ongoing arms-race than a fixed defensible point. Despite
code-encryption, virtual machines, and all the other tricks that you can't
break, others can. I highly recommend reading about how the original Xbox
was cracked. It's an interesting tale not just for the mistakes, but for
the extent of defenses that were erected. Still, it was broken. Although
one can learn from such mistakes, never assume that one won't introduce
one's own new mistakes in the process.
<http://www.xbox-linux.org/wiki/The_Hidden_Boot_Code_of_the_Xbox>
Another thing to remember is that the process of reverse-engineering IP is
greatly aided by the sophistication of code optimizers. Introducing
spurious code that has no effect on the real calculation of interest is
common. Unfortunately, removing code that has no effect on the calculation
of interest is EXACTLY what a code optimizer is written to do. And global
optimizers can do it across multiple functions, with common static-lifetime
variables. Always assume your adversary has at least as good a toolset as
you do, and is at least as skilled in using them.
You also need to put a price on your IP getting cracked. Monetize it so
you can judge what your defenses should look like. If you don't monetize
it or have some sense of the cost of being cracked, you're wasting your
time trying to figure out how to defend it. It's the cart/horse problem.
The surest and only way to prevent reverse engineering is to never have the
executable on a client machine. That means RPC of some kind, or a
service-oriented architecture where only you control the service. I don't
know how practical that is with your IP'ed code, but it's a good idea to at
least evaluate the complexity, costs, etc. Compare that to the risks of
distributing code that may be cracked, if not today, perhaps in a year or
two.
>Returning to #3, one of the interesting things I have
>learned is that some software publishers try to
>prevent customers from obtaining intellectual property
>from executables (and thereby compromising their trade
>secrets) by specifically forbidding reverse
>engineering in their software licenses. However, there
>appears to be some doubt whether these restrictions
>would actually hold up in court.
Even if such restrictions hold up in a U.S. court, they may not hold up in
international courts, or in the local courts of other countries with
different IP laws. Know your attacker's ground.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden