So to Vi Lam do I speak these words:


Friday July 28 1995 19:26, Vi Lam wrote to STEVEN PASZTOR:


 VL> That's brings you to my original question, the problem is it's very hard
 VL> to know the CRC before you compile the program. Once you compile it and
 VL> try to patch its CRC value, the newly patch program would result in a new
 VL> CRC value which would ultimately different from the one you've just patch.
 VL> That is, say you have a arbitrary predefined CRC value somewhere in the
 VL> EXE, after compile it and do the calculation, you'll have a *true* CRC of
 VL> this program. Now you'll patch it to the original value, but doing so
 VL> would result in a new CRC value for this program, then you'll patch this
 VL> new value in again, etc, etc... You'll have to do it iteratively to
 VL> finally get the correct match. Bear in mind that this work would be faster
 VL> if the so called "CRC" value is a checksum similar to
what Andrew Snow
 VL> suggested, but if you are to use "real CRC" like CRC-16
or CRC-32, you'll
 VL> going to put a lot of time into it to get it right.

 Even if you can't find a CRC equation which lends itselt to calculating
the value to pach into it, if you only include the checking routine on the
final release version, then you can always leave a program running all
night, trying to figure out the right value.  If the CRC (or preferably the
value needed to get the CRC to a specific value) is stored at the end, then
the patching program could simply get the crc up to that point, and would
only need to recalculate the crc of the code it's trying.  Leave it running
overnight, and you should have a program ready to distribute by morning.

 Oh, and there is a CRC routine floating around somewhere that can
calculate the actual CRC, and plug it directly into the executable in a
matter of moments.  Can't remember what it was called though...


 SP>> This still isn't perfect, since the "hacker" could
simply hard-crack
 SP>> the  program to ignore a wrong CRC, or may be able to alter the
 SP>> address from where you read the correct CRC, so that it is not at the
 SP>> end of
 VL> [...]
 SP>> viruses, the latter  of which it probably won't catch very many anyway
 SP>> since the ones worth  worrying about are the newer strains which will
 SP>> remove themselves, or "appear"  to have removed
themselves from the
 SP>> file.  The rest will more than likely be  detected by any virus
 SP>> scanner
 VL> That's the two things that you can't avoid, an experienced hacker and a
 VL> well written stealth virus. However I think having some checking scheme
 VL> would help to determine if the integrity of the program has been
 VL> compromised.

 True...  Buy a simple addition of the bytes could probably do that...  A
addition or xor of all the bytes (dwords would be better in the case of
using XOR) in the file would probably be more than sufficient, not to
mention relatively easy to calculate the correct value for...  It'll stop
the simpletons, which the better hackers can bypass anyway.  And it'll stop
any viruses which you'de detect with a 32-bit CRC.


 SP>> Another idea, is to include the "target" value of the
crc within the
 SP>> registration key rather than the EXE header.  However this will only
 SP>> work if a  registration key is used.
 VL> Yes, that would be another easy solution, but it's not as
"elegant" as
 VL> having the CRC in the program itself.

 It just means that virus detection becomes a REGISTERED only feature...  :-)

 Also, you could use the program's CRC to decode the registration key,
extracting a "control" section which will tell you if the key
(and hence the program) is valid.  An "unregistered" key would be
provided, which has the correct CRC encoded into it, along with the user
name "unregistered" and whatever else...


nevets


... *I* didn't do it, the *computer* did it!
--- FMail/386 1.0g