> 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.

In that case, there's no circular dependancy.


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


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


 > 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.

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


 > >> 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...

There are plenty of 'nice common' algoriths, a good many of them a lot
cheaper than polynomial calculation. A simple hash would do. Most of those
involve simple bit-shifting and XOR/OR/AND operations which are remarkably
cheap and small.

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


 > time I did it, I stored the CRC in the file's date...
 > Not too secure, but interesting! :-)

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

---