home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.uni-stuttgart.de/pub/systems/acorn/
/
Acorn.tar
/
Acorn
/
riscos
/
unixtools
/
checksum.spk
/
Checksum
/
!ReadMe
next >
Wrap
Text File
|
1990-07-16
|
3KB
|
103 lines
Quick Docs for Checksum V1.01 (C) Richard K. Lloyd 1990
----------------------------- Code/docs are freely distributable
Introduction
------------
Many systems employ checksums on binary executables (VAX/VMS and the Amiga
for example), but the Archimedes DOES NOT. Using checksums has the following
pros and cons:
Advantages
----------
1. Stops other people modifying your code - especially putting their name
in there instead of yours !
2. Prevents viruses (unless they're "checksum aware" of course) from attacking
your executable.
3. Stops horrendous things happening if a sector load is faulty and loads
gibberish as your code ("no change there" I hear you cry).
Disadvantages
-------------
1. Prevents innocuous file hacking (e.g. changing ":0.$.Kiddie.Game" to
"<Kiddie$Game>" using a memory editor).
2. Not exactly impossible to circumvent for the determined (NOP out a
couple of instructions).
So what about Checksum ?
------------------------
Syntax:
*Checksum [<Input filename>] [<Output filename>]
If both parameters are omitted, then you will be prompted for both.
If only the Input filename is specified, then it is assumed that you wish
to write the CRC-checked executable to the same filename - you will be
prompted for confirmation (as you would be if the output file already exists).
Checksum loads in an executable, generates a checksum for it and then appends
some ARM code to the end to calculate the run-time CRC and compare it with
the previously known CRC (an error message will be generated if the CRCs
fail to match). The new CRC-checked executable is then saved (136 bytes
bigger than the original).
Version 1.01 (mainly a bug-fix release)
------------
* Added command-line parsing of input and output filenames.
* Fixed offset problem with executables > 4K. I'd used an STR instruction,
which is restricted to +/- 4K from the instruction.
* Changed faulty CRC step from 4 to 1 when OS_CRC is called. This makes the
call slower, but now checks every byte rather than every fourth byte !
Version 1.00
------------
* Saves the first instruction of the executable (initialisation offset
for modules) and replaces it with a branch to the CRC-checking code.
After a successful check, the first instruction is replaced and then
branched to. Yes, I know this sounds like the embyronics of a virus,
but it's the exact opposite - it actually prevents viruses from attacking
CRC-protected executables.
* Knows about modules and their funnies (such as no initialisation code).
* Retains filetypes (or load/exec addresses).
* Checks the executable to see if it already has CRC-checking code
put there by itself and will abort if it spots any such code.
Future Improvements to Checksum V1.01
-------------------------------------
* Put a Desktop front-end onto the thing.
* Parse command-line filenames, only prompting for filenames if omitted.
* Add support for BASIC programs to be checksummed.
Estimated Release Date of Checksum V1.10
----------------------------------------
End of August 1990 - another program to go onto the (long !) list of updates...
Where to find me to report bugs or improvements to Checksum
-----------------------------------------------------------
Snail Mail JANET e-mail
---------- ------------
Richard K. Lloyd, rkl@uk.ac.liv.cs.mva
1, Banks Road,
Lower Heswall,
Wirral,
Merseyside.