Abstract: A method of protecting an executable program from reverse engineering and/or tampering. The method includes receiving a copy of the executable program together with a debug database, the database storing the locations of functional blocks within the executable program. A protection code is inserted into the executable program so as to overwrite at least part of a functional block of the executable program. Subsequent execution of the functional block causes the protection code to be executed. The protection code, when executed, performs an operation and executes a copy of the overwritten part of the functional block.

Abstract: Software loading is effected by means of a header 40 and software modules STUB1, STUB2 etc. The header 40 calls each stub in appropriate order, installing the stub in a loader region 42, executing the stub and then removing it. The STUBS may be encrypted and may be installed at random or pseudo-random locations in the region 42. Generic breaches of security, such as “riding the loader” are prevented because the stubs appear only transiently and at unpredictable positions. Security may be further improved by selecting each stub from a group of alternatives which are differently coded but functionally equivalent.

Abstract: When software is initially loaded to RAM 20, an engine 30A is installed at the beginning of an otherwise empty area of RAM 20. When the protected application is called, the engine first creates a series of steps (FIG. 3D), including a CALL command to a protection block 38. On reaching the call 36, the protection block 38 is executed, to complete various security checks. If these are successful, step 2 is created and written over the call 36 so that execution of steps 2 and 3 can continue as normal. Consequently, the protected software (steps 1, 2 and 3) is not exposed to scrutiny unless the security checks have successfully been completed.

Abstract: A customer computer 12, vendor computer 16 and verification computer 14 are interconnected by means of a network 18, such as the internet The customer 12 can initiate a transaction, such as the purchase of information from the vendor 16. However, the vendor 16 will not proceed until verification of the transaction has been received from the site 14. This is not provided until the customer 12 has sent a unique fingerprint of data to the site 14, identifying the customer machine by reference to hardware device types or serial numbers, software types or licences, e-mail addressed or the like. This fingerprint is stored for future reference in showing that the transaction was validly implemented by the customer machine 12.