So to David Nugent do I speak these words:


Friday August 11 1995 11:22, David Nugent wrote to steven pasztor:


 >> 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.
 DN> Steven, this won't work. A circular dependancy can only be resolved if
 DN> there is an equilibrium, but there's no guarantee in the CRC algorithm
 DN> that such an equilibrium exists. You might even get to the situation where
 DN> one value placed in the executable results in another value that needs to 
 DN> be, and placing that one there results in the other; ie. no resolution.
 DN> More likely, you'll get a far more elaborate 'circle' of any number of
 DN> values which has no resolution whatsoever.

 This is true...  But if the bytes being "patched" are at the
end, then doing a CRC up to the end, and storing that value would enable
you to only calculate the bit you're adding, making the search reasonably
fast.  In the case where there is no solution, then you can always resort
to other more conventional methods.  The thing is that if it DOES work,
than cool, every byte in the file is being checked.  If not, as long as
you're not trying to get it out in a hurry then there's no harm done.

 Would you happen to know the odds of not being able to create a certain
checksum if you were adding, say, eight bytes to the end of the file?


 >> 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.
 DN> It might also take several years. It might also never happen. Chances are
 DN> that the latter will be true.

 If it doesn't work, have a backup method.  Or use an algorithm which has a
better chance of working.  I dare say that for the purposes of stoping a
little hacking or a viral infection, it need not be the worlds best
algorithm! Besides, it'll never be anything a little hard cracking won't
solve.

 If it is the latter, than I guess you'd be using the back up method a lot.
But on the other occasions, you've got a program where the
"hacker" can't change ANYTHING within the program without having
to resort to a hard crack.


 >> Also, you could use the program's CRC to decode the
 >> registration key, extracting a "control" section which
 DN> What's this hangup with CRCs? They's nothing particular holy about them,
 DN> and there are far better (and cheaper) hashing algorithms in existance,
 DN> certainly there are far better encryption algorithms.

 Of course there are...  But CRC is a nice common one...  And it's got a
shorter name than most...

 Besides, I personally don't bother with CRCs, unless I'm giving a program
to one of my friends (one or two in particular) who have a habit of typeing
their name over top of my own using the trusty Norton DiskEdit...  Last
time I did it, I stored the CRC in the file's date...  Not too secure, but
interesting! :-)


nevets - "Steven" spelt the way it should be!


... 'TiL DeaTH Do uS PaRT -- 'TiL SHe KiLLS HiM.
--- FMail/386 1.0g