🚀 go-pugleaf

Eric Minso wrote:
> Beth wrote:
> > You still have to be _very careful_...virus writers are in the
> > business of duping people into doing stupid things...
> > [.....]
> > the bullet-proof vest, we _DON'T_ want the situation of seeing you
> > walking around with a big bullet hole in you...the satisfaction of
> > being able to say "I told you so" holds none of its usual smugness
in
> > that situation...
>
> Thank you for your long answer :-)
[ snip ]
> I'm not trying to write the total protection, I know that a good
> hacker will always find a way to crack the software, but I want to
> have a protection.
[ snip ]
> In order to lower the computer cost, the sofwares available on the
> CD-ROM are locked and the customer do not pay the licence for them.
A
> serial number allows him to unlock only three or four softwares that
> he can choose.
>
> The interest for the customer is that he installs only softwares he
> wants.
>
> A few time ago, some software editors have claimed that the
protection
> system is too easy to hack and asked to the company a better
> protection for their softwares.
>
> So I was asked to study a way to protect these executables.

Right; And you don't have the source code too?

Well, as Bob has mentioned, one method immediately springs to
mind...treat the executable as a datafile and encrypt that...then you
write a "chassis" kind of thing that's an executable which just has a
decryptor routine...you then link in the encrypted data with this
"chassis" frame so that it decrypts the executable...you can allocate
the memory, decrypt the executable into that (relocating, if necessary
:) and then jumping into the decrypted code...the "key" that's used in
the decryptor can be a "serial code" or whatever, handed out to the
customer when they pay for what they want...thus, you can only unlock
it when you know the serial code...and you _don't_ go leaving the
"key" that unlocks the program inside the decryptor itself...that's a
little too easy to unlock...just like you don't go leaving your car
keys in the ignition and the door wide open when you walk away from a
car...

Also, you can't really stop a determined cracker...instead, the best
you can do is just make cracking your program so intolerably annoying
to crack open, that they just can't be bothered to try...here's one
really mad idea...only decrypt a small section of the program at one
time...say, 64KB "chunks"...install an exception handler that catches
illegal memory accesses and if the program tries to access something
outside its current "chunk", it'll trigger an exception which your
program can use to decrypt the other chunk...the oldest chunks
delibrately have their data wiped over with some "blank" page before
being deallocated and made invalid again...

And, overall, your decryptor program does not allow more than two or
three "chunks" to be resident in memory at the same time...this helps
make it more awkward because the hacker can't just run your program in
a debugger and wait for it all to be decrypted and then save the
decrypted program straight from memory into another file (thereby,
by-passing your protection in one easy step with their debugger
:)...the whole program is never in memory in one go, so it'd have to
be jigsaw pieced together by trying to get the program to do a little
bit of everything to bring each "chunk" into memory...

The price for that, though, is that it'll have a constant performance
penalty because of the need to always decrypt new "chunks" all the
time...bigger chunks make this happen less often and improve
performance but make it easier to piece together the parts of the
program...smaller chunks have a worse performance penalty but there's
so many jigsaw pieces to put together, it should help to put off any
would-be crackers with the thought of all that hard work in front of
them :)

Also, your exception handler can grab onto any debugging "int 3" or
single-stepping exceptions and delibrately mess those up (a so-called
"anti-debugging" trick...so, if the cracker is trying to run this
under a debugger - only debuggers need "int 3" or single-stepping -
then your program delibrately freaks out and does stupid, nonsensical
things, so as to totally and utterly confuse any debugger or anyone
using the debugger as to what's actually going on...they'll try
"attach" and then, suddenly, your program just goes totally weird and
becomes unreadable and forces the debugger to hang...again, as always,
this stuff can be worked around but it's designed to annoy the hell
out of any cracker trying so that they just decide to give up trying
:)...another one is to put in some self-modifying code that effects
the instructions it's just about to execute...that is, assemble in a
"NOP" or something but then overwrite that with the real
instructions...simple disassemblers won't be able to deal with this
and will see "NOP" rather than the real instruction and will then be
"out of synch" with all the instructions afterwards, disassembling
them to the wrong opcodes :)...

You could even get real silly about this and the decryptor unpacks yet
another decryptor (which uses a different method to the first one) and
inside that is the real executable...so, like one of those Russian
dolls, the cracker breaks open your first decryptor, thinking s/he's
broken your protections, only to find that there's yet another layer -
which encrypts using a different algorithm, so they'll have to start
their cracking all over again from the start - inside that...practical
matters would limit things but imagine it being 10, 15 or 20 layers
deep (and every layer is also doing the "never hold the entire
executable in memory at the same time" trick too :)...as we all know,
you can't stop someone who's determined...the trick instead is to put
up so many obstacles in the cracker's way that they really, really,
really need to be determined to even attempt it...you make it such
hassle that the cracker thinks "oh, I give up...this other software
from someone else is far easier to crack, I'll do that"...

Although, that said, one slight problem is that the better the job you
do, the more you'll actually attract crackers...remember, it's an
"ego" and "I'm better than all the other crackers" thing for many of
them...hence, if you have the most impenetrable protections - you own
"Fort Knox" - then this can actually _attract_ crackers...informal
"competitions" between them: Who can crack open all 21 "Russian doll"
layers first? That sort of thing...also, the fact that there's so many
protections may have some crackers thinking "Wow, they are going to
some lengths to protect it! What are they hiding in there?"...that is,
you could actually generate some mystery and their natural curiosity
does the rest...after all, who puts 27 layers of locks and alarms
around their house? Yes, exactly...someone who's got something very
valuable they want to protect from thieves...even if you haven't got
anything that's really all that greatly valuable, having tons and tons
of protections can _make_ them think this, anyway...after all, until
it's cracked open, they don't really ever know what's inside...

So, in a bizzare sense, NOT having too many protections is a
_psychologically-based_ protection in itself..."too easy" only
attracts the "lamers"...so, aiming it at "not too little" but _also_
"not too much" is about right...you don't want it so easy that anyone
and everyone can do it just by reading some "type in this serial code"
file on a website...but, at the same time, if you make this the most
protected piece of code in history then, in fact, they'll be starting
up "cracking competitions" to be the first to crack open your
program...it'll become the new "cracker's benchmark": "huh, if you
can't crack Eric's protections then you're just a sad lamer and not a
cracking guru!"...

Really, though, the only protections that even begin to work are
_physically_ based...for example, dongles or that the "key" to decrypt
the executable is _physically_ kept away from the executable until
it's paid for (though this second one has some implementation
problems...you'd want each copy to have a unique "key" or all it takes
is for one cracker to pay for a legitimate key and then pass that key
onto every other customer...but, also, separately encrypting and
linking every copy is not all that conducive to the usual
mass-production methods used to burn lots of CDs...but one "half-way
house" idea is to create, say, ten or twenty different serial codes so
that there's only a 1 in 10 or 1 in 20 chance that two randomly chosen
copies will share the same serial code...except, of course, until all
twenty codes are discovered...as noted, no such thing as uncrackable
protection...but just so long as it's not "too easy" and makes the
cracker work very hard to get anywhere, that'll put off all but the
most determined (who are the ones you can _never_ stop whatever you
try)...

In the end, the only "protection" that ever works is simply never to
have anything that anyone else wants to steal...obviously, you don't
have a choice in this case but it's about the only "protection" that
actually works...buy a really crap car with rust and bits falling off
and a 50/50 chance that it won't start, that backfires when it does
start, etc....and, heck, leave the door wide open and the keys in the
ignition with a big sign reading "steal me!"...and it'll still be
there when you come back, as even joy riders won't see much "joy" in
stealing an old rust bucket that barely moves...unfortunately, neither
will you find much "joy" in owning it either but, hey, at least
no-one's going to steal it, eh? :)

Beth :)