Agreed, and good point! Also, multiple and various checks, with non-fatal
but tech-support-calling results is also a very good anti-priracy aide.
But back to the memory dump issue...
The only way to get a "good" and working memory image, is for the hacker to
have already purchased the software (or have access to one legitimate copy).
He won't get a "good" memory image on a bootleg copy because either the
decoded memory image will be garbage or the pre-CRC check of the cipher will
fail, and there never will be any memory image to snoop.
Now if the hacker does get a good memory image from a legitimate copy, and
is using a debugger, it's a whole other ballgame to get all the
memory-resident code out of it's "runtime" state back into a "preload"
state. They'd have to get all the code extracted, and rebuild it within an
another shell, and hope to get all the correct resources and other parts of
the code. This is where your idea kicks in. The hacker will be looking at
the memory image (and the resulting application data) at runtime, not
loadtime. So there can be other checks in the deciphered code to make sure
that the memory layout should be a certain way at a certain time. I've seen
copy-protection schemes that even know a debugger is running, which is also
doable, and can thwart debugging attempts by throwing the hacker curve balls
they don't expect.
To some degree, this *IS* rocket science - it's a game of outsmarting the
hacker, and trying to 2nd guess them. For example, the entire code doesn't
need to be decoded all at once, only major modules can be decoded in an
overlay fashion. This way, they never get to see the entire program
deciphered all at one time.
I do believe that no copy-protection scheme is 100% bullet-proof, but as it
gets more difficult to crack really good schemes, only the best-of-the-best
can be sucessful, and then your app's chances of being pirated goes down
significantly because you rule out all the couch-potato-hackers. :)
Doug.
-----Original Message-----
From: Richard M. Hartman [mailto:[EMAIL PROTECTED]]
Sent: Friday May 5, 2000 16:42
To: Palm Developer Forum
Subject: Re: palm software cracking
The weak link in this chain is that, in order to run the
program it has to be decrypted into memory somewhere.
Once that is done, a memory dump can get at the
unencrypted version of the software.
The best protection comes w/ multiple checks at
various points in the software rather than one single
check at startup.
--
-Richard M. Hartman
[EMAIL PROTECTED]
186,000 mi/sec: not just a good idea, it's the LAW!
Doug McFadyen wrote in message <10682@palm-dev-forum>...
>
>
>Totally aside from issues of warez sites, the issues of protecting software
>WITHOUT ticking off your legitimate users, has always interested me. For
>years, software protection schemes basically made paying customers waste
>time with key disks (floppies, CD-ROMs, etc), while the hackers had already
>cracked your software while it was still in beta testing, before it was
>released to retail. :)
>
>Part of the problem, obviously, stems from the fact that all the
complicated
>anti-piracy code usually ends up with something like:
> if (fOkToRun)
> RunApp();
>And once this single weakest-link-of-the-chain is located, all the complex
>copy-protection code goes out the window. Most software that has a "key
>registration" facility suffers from the very fact that the security encode
>and decoder are BOTH present in the user's copy of the software. That is,
a
>hacker gets to see both sides of the equation, and all the variables to the
>equation are therefore known.
>
>Now, with the Palm (at least my Palm IIIc), there's a nifty thing called a
>serial number. Each palm unit has a unique serial number, which AFAIK, can
>be queried from a Palm app. Now, if we move the software key validation
>sequence off of the user's copy of the software, and move it to the
software
>distribution point-of-sale, then we can start to use some nifty
>public-key-private-key encryption techniques.
>
>For example. Say you're trying out the new xyzzy.prc application. It's
the
>freeware/demo version, so it is very limited and does not do everything.
>Now you want to buy it to get the full features. You go to the
>www.xyzzy-r-us.com website, and say you want to buy the program. As you
are
>filling out the registration form, it asks you for your Palm's serial
number
>(conveniently located on the back of the unit). Once your registration is
>authorized, the download you eventually receive will be UNIQUE and SPECIFIC
>to your Palm device's serial number. Of course, this requires a web-server
>that can run an application to generate the user-specific download code.
>
>Now, the xyzzy.zip file your receive will contain a specially encrypted
>xyzzy.prc file that only runs on your system. In simple terms, the
>application contains a code-stub that uses your system's serial number to
>decrypt the actual run-time part of the code. (I haven't done this, but I
>think it can be made to work.) Because the code itself is encrypted, and
>because the app now only contains the decryption algorithm, and because
your
>instance of xyzzy.prc is unique to you, it is MUCH MUCH harder to hack. If
>you beamed the app to a hacker, the code won't run because their Palm's
>serial number (which is the key) is different, and AFAIK, you can't change
a
>device's serial number. And assuming the hacker who just got a bootleg
>xyzzy.prc file doesn't know the serial number for which it works, he
>probably won't be able to hack it because the code itself is encrypted and
>he doesn't get to see the encryption code at all, because xyzzy.prc doesn't
>contain it. Not only that, since the code itself is encrypted, he can't
>just find the single "if" statement to hack out.
>
>Now this is all theory, and a good idea, but I have not done this yet - but
>I'm thinking about it! :)
>
>If this concept can be made to work, it means that hackers are put out of
>business (because your key generator is using huge 128bit keys, etc), and
>the legitimate user is only inconvenienced ONCE at the point of sale, not
>everytime they run the program. Of course, just like the Pentium-III
fiasco
>with serial numbers, there will be those screaming about privacy, because
>they will believe that somehow their Palm's serial number means that I can
>find out their dog's name, and their annual salary. ;)
>
>Just my $0.02 worth!
>Doug.
>
>
>
--
For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/tech/support/forums/
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
