So to David Nugent do I speak these words:


Saturday September 09 1995 16:19, David Nugent wrote to steven pasztor:


 >> DN> one value placed in the executable results in
 >> DN> another value that needs to be, and placing
 >> DN> that one there results in the other; ie. no
 >> DN> resolution. More likely, you'll get a far more
 >> DN> elaborate 'circle' of any number of values which
 >> DN> 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.
 DN> In that case, there's no circular dependancy.

 Thus rendering the entire argument quite invalid.  But hey, it was surely
educational to a few people at least!  :-)


 >> 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?
 DN> If you did it that way, you'd only need to calculate and store it once.

 I thought I'd said that?  Or were you just agreeing with me?  Or is it
just too early in the morning?


 I seem to remember a program that had a (hopefully) unique string as the
checksum (stored in the code segment), and after compiling, you run a
little proggie which calculates and plugs in the real CRC.  It did it
pretty quick (used some equation to calculate the thing) but said that
there were a few cases where it was not possible to find the CRC to shove
in there.  In these few cases it was neccesary to change something and try
again.  Ever heard of or seen it?


 >> 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.
 DN> Or don't use a circular dependancy in the first place. :)

 But that's cheating.  Guess that, as with most of this, comes back to just
how much effort are you willing waste on it, and is it worth the effort it
will take a hacker to hack.


 >> 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.
 DN> There are simpler methods, though. One might include something in a data
 DN> file, you could store the checksum at the end of a segment in the
 DN> executable and only calculate the checksum for the disk image of the
 DN> code/data segments.. all of these would avoid the value of the
 DN> checksum/CRC being dependant upon itself. Certainly these methods are not 
 DN> as difficult to defeat, but then you have to know what you're looking for,
 DN> persumably by reverse-engineering the code itself. Anyone with a little
 DN> knowledge could do it, although it is doubtful that an automated means
 DN> (such as a virus) could do it unless it was specifically aimed at
 DN> defeating the protection. That's probably good enough.

 De Ja Vu, methinks...  I'm sure I said something to the effect of the last
few lines...  Oh well...

 Probably a check of the disk image would be best for anti-virul purposes
since a virus will often detach itself from the program when run.  And as
you and I have stated, someone who knows what they're doing can often
overcome the protection, one way or another.  Checking the data segment is
usefull for catching people who like to alter the little text messages like
a friend of mine...  The number of programs he has that say "Copyright
{his name}" is just astounding! :-)


 >> >> 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
 >> DN> particular holy about them, and there are far
 >> DN> 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...
 DN> There are plenty of 'nice common' algoriths, a good many of them a lot
 DN> cheaper than polynomial calculation. A simple hash would do. Most of those
 DN> involve simple bit-shifting and XOR/OR/AND operations which are remarkably
 DN> cheap and small.

 Just like the negative sum (I think that's what it's called...) used by
some (many?) BIOS's?


 DN> A CRC is simply 'popular' because it was designed as a rebust method of
 DN> checking bit errors on data and is a visible part of file transfer
 DN> protocols. That doesn't make them suitable for all uses, though.

 (howcome the only spelling errors I ever catch are other people's?)

 Agreed.  But in my case, it's much the same as why people prefer to say TV
instead of Television.  It's a shorter word, and a damn lot shorter than
saying CRC-and-all-the-other-sundry-hash-routines-one-might-find!


 >> time I did it, I stored the CRC in the file's date...
 >> Not too secure, but interesting! :-)
 DN> Eh? If handled as a 32-bit value, some values in the file date would be
 DN> invalid, such as the 31st of February, or some date in the 13th, 14th or
 DN> 15th month of the year. Even copying or backing up the file (which would
 DN> cause it to be processed though DOS) might corrupt it - perhaps that is a
 DN> desirable result, but weird dates would certainly make the method used
 DN> more obvious than it should be.

 Yep!  Hence the "but interesting" bit...  Hmmm.....  Storing a
62 in the seconds field will prevent a few viruses from infecting your
program. However it'll also cause a few others to destroy your program the
next time you open it for any reason while the virus's resident...  Can't
win either way.  But then a seconds field containing 0 will do the same in
a few cases, as will 18 in at least one...

 Copying is ok, or at least it worked for me.  However backing up would
likely be a definate problem, and many virus scanners complain also.  Could
be worse...  The CRC could of been stored in the starting allocation unit
space... ;-)


 So, in brief:  To stop viruses, a simple algorithm will do.  To stop
hackers, you might as well use a simple one because if they're determined
enough to beat a simple one, they're probably gonna get through a complex
one anyway. So why not just use a simple one?


nevets


... ############## OH NO, a worm in my Hard-drive!
--- FMail/386 1.0g