TIP: Click on subject to list as thread! ANSI
echo: aust_c_here
to: Vi Lam
from: steven pasztor
date: 1995-07-16 18:01:22
subject: Re: CRC SELF-CHECK

Welcome Lam Vi...


Wednesday July 12 1995 20:18, Andrew Snow wrote to Vi Lam:


 AS> Now, if they compare differently, then you know either there was a virus
 AS> attack or some idiot has tried to tamper with the EXE.

 AS> After that, all you have to do is open the file in write mode and seek to
 AS> the end, writing the "crc" variable to the end using
fwrite().  That's at
 AS> compilation time.  In the actual program, do the same thing, but DON'T
 AS> count the last four bytes.  Then read in the last four bytes and compare
 AS> it with "crc".  Great!

 A better idea, is to make that four-byte code the initial value fed into
the "crc" routine, and set it such that the resulting CRC
(including the last four bytes if possible) will be equal to something
within the file's EXE header, (or withing the programs code itself) which
is needed for the EXE to be loaded properly.

 This is better for two reasons:

 1) In the original suggestion, a "hacker" could wait until the
CRC was calculated, and then just replace the last four bytes of the file
with that CRC, making the program think it is still valid.  By making the
bytes at the end the INITIAL value fed into the CRC, there is no easy way
for the "hacker" to re-calculate the crc.

 2) The value you're comparing the CRC can't be altered by the
"hacker", since doing so would cause the program to crash.

 This still isn't perfect, since the "hacker" could simply
hard-crack the program to ignore a wrong CRC, or may be able to alter the
address from where you read the correct CRC, so that it is not at the end
of the file.  Doing so would reduce the algorithm to essentially the same
as in the original message.  However, if the appropriate bytes are pulled
out from calculated locations within the file during the CRC process, and
combined to form the CRC to compare against, than this method would become
much harder, and a hard-crack would become the only viable alternative.

 Note however, that all this is irrelevant to anyone who knows what they're
doing, and will only have a chance of catching idiots and viruses, the
latter of which it probably won't catch very many anyway since the ones
worth worrying about are the newer strains which will remove themselves, or
"appear" to have removed themselves from the file.  The rest will
more than likely be detected by any virus scanner in the market, and IMHO,
if someone doesn't have one, then it's their bad luck, and they deserve
anything they get.  Idiots usually aren't a threat, because the most they
can do is change a few bytes so it says their name.  A registration crack
or something would be way out of their league.

 Another idea, is to include the "target" value of the crc within
the registration key rather than the EXE header.  However this will only
work if a registration key is used.


nevets


... Adults are obsolete children
--- FMail/386 1.0g
* Origin: HELP!!! (3:632/103.123)
SEEN-BY: 50/99 620/243 623/630 632/103 348 998 633/371 634/384 388 635/301
SEEN-BY: 635/502 503 544 727 636/100 639/100 711/401 409 410 430 510 807 808
SEEN-BY: 711/809 932 934 712/515 713/888 714/906 800/1 7877/2809
@PATH: 632/103 348 635/503 50/99 711/808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.