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

Abstract: A mobile communication network 12 provides communication between devices 10 and is controlled at 14. When a user wishes to gain access to the network 12, a device 10 is required to send a request signal to the control 14. This request signal identifies the user device, not the user. The control makes security checks to ensure that the device is authorised, before returning an authorising signal 20. The user device is configured to prevent communication by the user until an authorising signal has been received.

Abstract: Software on a wireless device is protected by an arrangement in which an identifier is derived from the hardware of the device on which the software is to be run. The identifier is sent to a server which derives a derived identifier by applying a function g to the identifier. The derived identifier is returned to the device which executes a function h. Function h is the inverse of function g. Comparison with the original identifier thus confirms that operation of the software is authorised. In the event that it is not, the server does not send back a derived identifier.

Abstract: Executable software 30B is protected by inserting an additional block of code 50, immediately after the header 30A. The block 50 is executable to analyse all or part of the structure 30 to determine whether or not any change has been made to the structure after the creation of the structure. For example, a CRC value may be checked. When the software 30B is to be executed, the security block 50 executes first, to check if any changes have been made, such as by the effect of a virus. If this is detected, a compressed copy 52 is used to replace at least the program region 30B, prior to execution being handed to the block 30B.

Abstract: Software contained in memory 50 is encrypted by means of an encryption routine EN1 to the encrypted form illustrated at 50A. A decryption routine DE1, corresponding with encryption routine EN1, is embedded at 70 in the memory 50B. A further encryption routine EN2 is then applied to the contents of memory 50B, to create a further encrypted form at 50C. A decryption routine DE2, corresponding with encryption routine EN2 is embedded in the memory 50D. Further encryption routines can be applied, one after another, with a decryption routine being embedded in the memory before the next encryption routine is applied. The result is an encrypted form of the original software, protected by several layers of encryption, each with an associated decryption routine which has itself been encrypted by subsequent encryption routines.

Abstract: Software is protected by providing an incomplete copy for loading into RAM 30. One or more blocks of code 32 are missing. The choice and location of the missing code 32 is preferably substantially random. Thus, the RAM portion 30 contains an incomplete copy of the protected software, lacking additional code to be executable.

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: When an executable program is to be loaded into RAM 10, the RAM initially contains a loader module 12a, the program 10, an ENGINE 22 and encrypted resources 24, such as encrypted .DLL files. When the program 14 is to be run, the loader module 12a will call the ENGINE 22, which will access the sub-routine resources required by the program 14, identify any of these which are already available in the system, load those already available, and decrypt and load any which are not available. This ensures that the required subroutines are available to the program 14 on each occasion that the program 14 is executed.

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.