| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| 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™.