[Tfug] Code obfuscators and watermarking

[Bexley Hall]

Hi, Jeff,

--- Jeffry Johnston <tfug at kidsquid.com> wrote:

> Maybe this will help:
> 
> http://freeworld.thc.org/root/phun/unmaintain.html

Yeah, I'd read something like that before.  :>
I've got my own set of coding standards that I could
"invert" if I was wanting to achieve a similar
goal.

The advantage of an obfuscator is you can still
write *intelligible* and *maintainable* code.
If you manually try to write *crap*, then *you*
get stuck with that crap, too!  :-/
 
> Another idea is to write an interpreter for your own
> esoteric (and of
> course undocumented)  language.  Then, write your
> code in that lang.

The same argument (above) applies.  I've written a
couple of application-specific languages and their
only *justification* is that they make coding the
application EASIER and more intuitive.  Otherwise,
they aren't worth the trouble.

> Apply as many principles from the above site as
> possible when writing
> your interpreter ;)   If you need ideas for your
> esolang:
> http://esolangs.org/wiki/Main_Page
> 
> If possible, combine this with things such as self
> modifying code, or
> on the fly decompression of code and/or data.
> 
> Another idea (thinking in x86 here for a moment):
> Make use of
> instructions like JMP AX ... so now, they can't just
> disassemble the
> code.. they'll have to put your mess in a debugger
> and trace through
> it.. because otherwise they have no idea where that
> jump goes to
> (gotta love that halting problem).

Depending on the target iron, you can do a lot of
simple things that make debugging cumbersome.
But, again, if *you* have to go out of your way
to do this, then you are bearing a cost that would
be better to avoid.

E.g., in the early 80's, video (arcade) games were
routinely counterfeited.  *Blatantly* so!  Some
of the techniques employed to prevent/discourage
those attempts were costly (in terms of time and
resources).  Back then, it was a simpler problem:
all you had to do was delay a counterfeiter from
introducing a knock-off for 3-4 months and he
would be locked out of the market (for that
particular game).  This was because so many games
were "90 day wonders" (i.e., customers tired of them
quickly)
 
> Basically if you can force them to trace through
> your code in a
> debugger, you've won.. That's the best you can
> really hope for in the
> end (there is no winning.. because if the cpu can
> run it, someone with
> WAY too much free time on their hands can crack it,

Yes.  I know of hobbyists who have managed to do
just this with many of the old games.  (sigh)
Makes you wonder if they've "got a life"...

> short of using
> some kind of hardware dongle storing a strong
> encryption key).  Then,
> of course, exploit as many debugger weaknesses/bugs
> as possible.

Even hardware attempts are silly, nowadays.  You
can de-encapsulate and microprobe a die in many
college labs, etc.

But, if you can make your code hard enough to
*understand*, then you make the support issue
a high hurdle for would-be counterfeiters.
(e.g., if John Doe calls asking for a bug fix,
the legitimate owner of the IP simply refuses
to support him -- forcing him to pester the
counterfeiter for this support... the counterfeiter
is then continually chasing the legitimate owner's
new releases in the hope of being able to offer
that support to their counterfeited product)

> Or... just skip all that and put the GPL on your
> code.  Much easier
> and more satisfying since other hobbyists can use it
> too.  That's what
> I recommend ;)  Companies have been bitten a lot
> lately by misusing
> GPL code, and I think it's having an effect.

I'll let *you* try to convince my clients that
they should "give away" the stuff they've paid
me to develop.  :>  (just keep my name out of it)

Thx,
--don

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com