[ale] File Integrity Check
Benjamin Scherrey
scherrey at switchco.com
Fri Aug 13 10:54:12 EDT 1999
Since a checksum is, by definition, a hash, it will always be possible
to make a checksum appear to be correct. Some, however, are better
than others. I recall coding EPROMs to run during the POST process of
an IBM PC which required a memory range to checksum to zero before it
executed. The checksum was purposely simple and by adding $0xFF's to
the end of the file you'd eventually get the checksum to wrap around
to zero. A hash that considers file size and timestamp, as well as
content will be more difficult to 'fake'. An even more secure
mechanism would be to run two different checksum types on the file
although this is probably theoretically the same as generating a
checksum with twice the resulting bits with a truly randomizing
algorithm. I'm not familiar with the 'sum' program. If all it does is
add bytes together in the file then I'd say this was a completely
inadequate mechanism. Better checksums make use of bit shifting and
xor computations.
later,
Ben Scherrey
PS: Any of you math types are quite welcome to correct any
misconceptions I may be propagating...
Russell Enderby wrote:
>
> In pursuit of determining critical system files for modifications I was
> thinking the checksum prog 'sum' would be sufficient. Understanding
> that time,date, and file size can be modified under the ext2fs/ufs
> directory table. Is it possible to also make the 'sum' checksum appear
> to be correct?
>
> I was under the impression tripwire uses its own special checksum prog
> to verify files, although would 'sum' be sufficient as well? If not
> does anyone know of better more thorough checksum app?
More information about the Ale
mailing list