000001
`
`Symantec 1020
`IPR of U.S. Pat. No. 7,757,298
`
`

`
`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 1 of6
`
`6,006,328
`
`EXEGUTABLE PROGRAM
`
`COMPUTER OPERATING SYSTEM
`
`F/62 /.
`
`PRIOR ART
`
`. _ _ _ _ _. _
`I APPLICATION cons
`
`
`
`L______J
`
`23\
`USERS
`
`
`
`FIG? 3.
`
`000002
`
`000002
`
`

`
`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 2 of6
`
`6,006,328
`
`
`
`
` {To-WTETIEYT
`PROGRAM coma:
`
`
`SYSTEM BUFFERS
`
`OTHER DRIVERS AND
`
`
`
`OTHER HARDWARE
`
`COMPUTER HARDWARE
`
`FIG: 4.
`
`PRIOR ART
`
`'8
`
`\4o
`
` APPLICATOR
`
`
`
`
`
`6|
`
`I6
`
`EXECUTABLE PROGRAM
`
`I
`
`(PROGRAM. CXC)
`
`
`
`I OBFUSCATOR
`
`
`/62
`T
`T
`
`
`CIPHER
`
`T
`63
`
`
`ID-DATA PROTECTION
`
`FIG 6.
`
`000003
`
`000003
`
`

`
`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 3 of6
`
`6,006,328
`
`ROGUE PROGRAM
`
`KEYBOARD
`DRIVER
`
`OTHER DRIVERS a
`svsrm BUFFERS
`
`.
`:
`
`I I :
`
`REPLACEMENT
`
`:\
`ID-DATA cum I
`
`:
`
`PROGRAM come;
`APPUCATION coofi
`
`I‘: Z.‘_.'‘_''‘..'_-_’‘
`
`OPERATMG SYSTEM
`
`KEYBOARD
`
`HARDWARE
`
`COMPUTER HARDWARE
`
`FIG 5.
`
`m 7'
`cons
`72
`
`'5”
`
`7‘
`
`FIG. 2 PRIOR ART
`
`000004
`
`000004
`
`

`
`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 4 of6
`
`6,006,328
`
`EXE FILE HEADER
`
`
`
`
` ADDRESS CONTENTS TYPE
`OOH
`EXE PROGRAM IDENTIFIER
`A4DH
`1 WORD
`
`02H FILE LEN TH MOD 512
`
`1 WORD
`
`
`
`06H N MBER OF SEGMENT ADDRESS FOR PASSING
`
`l WORD
`
`08H HEADER SIZE IN PARAGRAPHS
`
`OAH MINIMUM NUMBER OF PARAGRAPHS NEEDED
`
`I WORD
`
`1 WORD
`
`
`
`
`
`
`CH MINIMUM NUMBER OF PARAGRAPH
`
`NEEDED
`
`1 WORD
`
`0 O
`
`
` H
`
`STACK SEGMENT DI PLACEMENT
`EH
`
`10H SP REGISTER ONTENTS WHEN PROGRAM START
`
`
`
`
`12H
`
`14H
`IP RE I TER CONTENT WHEN PROGRAM TART
`
`HE K
`
`M BA ED ON EXE FILE H Al“;
`
`
`
`16H START OF CODE SEGMENT IN EXE FILE
`
`18H RELOCATION TABLE ADDRESS IN EXE FILE
`
`1 WORD m
`
`1 WORD 33
`
`OVERLAY NUMBER
`1AH
`
`_ H
`
`B FFER MEMO’,
`
` xxH
`
`ADDRESS OF PASSING SEGMENT ADDRESSES
`
`RELOCATION TABLE
`
`XXH
`
`
`PROGRAM CODE
`
`DATA
`
`
`AND STACK SEGMENT
`
`FIG 8.
`
`PRIOR ART
`
`000005
`
`000005
`
`

`
`U.S. Patent
`
`Dec. 21, 1999
`
`Sheets 0f6
`
`6,006,328
`
`PROGRAM EXE (I6)
`
`NEW EXE (30)
`
` RELOCATION
`CODE (PART A)
`
`
`
`DATA
`
`
`
`OVERLAYS
`
`NETSAFE 2
`
`CODE (PART B)
`
`
`
`inane.
`
`CODE (PART 0)
`
` RELOCATION
`
`CODE (PART A)
`
`(PART B)
`
`(PART C)
`
`DATA
`
`
`
`
`
`OVERLAYS
`
`F/6 .9. PRIOR ART
`
`
`
`
`FIG.
`
`/0.
`
`NEW EXE 50 (IN MEMORY)
`
`NEW EXE 50 (IN MEMORY)
`
`
`
`NETSAFE 2
`
`I23
`
`FIG /2.
`
`I03
`
`CODE (PART A)
`(ENCRYPTED)
`
`PSP
`
`0 "5
`CODE (PART (I)
`'06
`(ENCRYPTED)
`
`
`
`DATA
`
`STACK
`
`
`WORKSPACE
`
`NETSAF E 2
`(PARTIALLY ENCRYPTE
`
`F/62 //.
`
`7.’)
`
`III
`
`II2
`
`"5
`
`000006
`
`000006
`
`

`
`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 6 of6
`
`6,006,328
`
`I3! \ mrgnaupr {ABLE
`NUMBER POINTER
`
`-
`
`
`
`_ _ _
`
`FIG /3.
`
`000007
`
`NEW EXE 30(|N MEMORY)
`
`
`
`
`
`cons
`
`DATA
`
`STACK
`
`WORKSPACE
`
`
`
`
`
`
`NETSAFE 2
`
`SECURE HARDWARE
`
`ID-DATA ENTRY CODE
`
`us
`
`5|
`
`000007
`
`

`
`@006328
`
`1
`COMPUTER SOFTWARE
`
`AUTHENTICATION, PROTECTION, AND
`SECURITY SYSTEM
`
`This is a continuation of application Ser. No. 08/679,077,
`filed Jul. 12, 1996.
`
`BACKGROUND OF THE INVENTION
`
`invention relates to a computer program
`The present
`having enhanced security features, and also to a system and
`method for enhancing the security features of a computer
`program. In particular, the present invention relates to such
`a program, and the system and method for creating the
`program, having increased security features to prevent ID
`data (as defined) eavesdropping and/or theft and/or ensure
`authenticity.
`
`Description of the Prior Art
`
`Computers are becoming widely interconnected and
`heavily relied upon to process and store sensitive informa-
`tion. The risk of unauthorised access to computers and
`information has increased with this increased interconnec-
`
`tivity.
`Many security advances exist in the areas of identification
`& authentication of users, cryptography, virus prevention,
`and the like, however—almost all of these advances ulti-
`mately rely upon computer software. Most computer sys-
`tems are, or are accessed by, small personal computers, and
`most software used on these personal computers is suscep-
`tible to “local attacks”—attacks which are mounted from
`
`inside said personal computers against said software by
`other software or people.
`Passwords, User-ID’s, credit-card numbers and expiry
`dates, bank account and PIN numbers, smart-card data,
`biometric information (for example: the data comprising a
`retina or fingerprint scan), cryptographic keys, and the like,
`are all examples of identification, authentication or similar
`data which is either sensitive in itself, or may allow access
`to sensitive, restricted or other information or services.
`Hereafter,
`the term ID-Date will be used to refer to the
`abovementioned identification, authentication or similar
`data, excluding ID-Data which is valid only for a single use,
`or which is designed to expire at regular intervals of short
`periods of time, say less than two minutes.
`Illegal access to computer system information can be
`obtained by exploiting various security flaws found in
`computer software products. A common flaw is the suscep-
`tibility of said software to the theft of ID-Data either directly
`from said software as it executes, or, from the operating
`system or hardware on which said software is executing.
`Another common flaw is the susceptibility of said software
`to (illegal) modification. Such modifications may remove,
`disable, or compromise the security features of said soft-
`ware.
`
`Viruses, Terminate-and stay-resident programs (TSRs),
`co-resident software, multi-threaded operating system
`processes, Trojan Horses, Worms, Hackers, Spoof programs,
`keypress password capturers, macro-recorders, sniffers, and
`the like can be effective at stealing ID-Data and are
`examples of (a)
`rogue software,
`(b) people capable of
`subverting security software, or, (c) software which can be
`configured for illegimate purposes. Hereafter, the term rogue
`software will be used to refer to software or subversions
`
`such as the above mentioned (a) (b) and (c), used for the
`purpose of stealing ID-Data. The definition of our term
`“rogue software” when used herein also includes software or
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`other means used to tamper with other software. The term
`tampering is defined hereafter.
`There are many ways to introduce rogue software into a
`computer system. Viruses spread automatically by introduc-
`ing themselves. Trojan-Horses are usually introduced by
`tricking users into allowing them to execute (such as by
`masquerading as a new or well-known computer game or
`other product). Existing security problems may be utilised to
`introduce rogue software, some well known problems
`include lava bugs, errors, or oversights, ineffective physical
`security (for example: permitting rogue software to be
`introduced directly on floppy disk by an intruder); electronic
`mail attachments which automatically execute or execute
`after a simple mouse-click, incorrect security settings on
`internet, world-wide-web, TCP/IP or modems, and tamper-
`ing (see definition hereafter) with legitimate software
`in-transit as it flows from remote internet sites into a users
`
`computer, to name a few.
`Rogue software, once introduced, can steal ID-Data as
`mentioned hereinbefore.
`It may monitor keyboard (for
`example: by recording every key, as the user presses each
`one, in order to steal a password as it is being typed in),
`serial-port, mouse, screen, or other devices to steal ID-Data
`directly from them.
`It may monitor other software,
`applications, the operating system, or disks to steal ID-Data
`from there also. Once stolen, this ID-Data may be stored
`locally (for example: in memory or on-disk) or transmitted
`to remote locations (for example: by modem or network) or
`used immediately to perform illegal operations. Hereafter,
`the term eavesdropping will be used to refer to the moni-
`toring of a computer to record ID-Data.
`For example, a key press recorder could secretly, and
`unbeknown to the computer user, record all the keys pressed
`by the user into a hidden systems file. The information
`recorded could include a user’s password and other sensitive
`information which an organisation would obviously wish to
`protect.
`Additionally, rogue software may remove, disable, or
`compromise existing computer software security features by
`modifying the memory, disk or other image of said computer
`software. Rogue software may also utilise tampering tech-
`niques to alter existing computer software in order to steal
`ID-Data from it, or may attach itself to existing computer
`software (as is the case with many computer viruses).
`Hereafter, the term tampering will be used to refer to the
`abovementioned modification of computer software. Tam-
`pering may take place either locally (within a users PC) or
`remotely (for example: at one of the points which a com-
`puter program passes through as it is being download).
`Further, counterfeit software can be substituted for legiti-
`mate software. The counterfeit will appear real to a com-
`puter user, but actually acts to subvert security, such as by
`stealing ID-Data. Sometimes called “Spoof” programs or
`Trojan Horses, counterfeit software of this type may invoke
`the original legitimate software after having stolen ID-Data,
`so as not to arouse a user’s suspicion.
`Another potential security flaw found in computer soft-
`ware products is susceptibility to examination and reverse-
`engineering. Known (but generally secret) and other security
`problems or mistakes can be discovered by hackers and the
`like from the examination of existing computer software and
`by tracing its operation.
`Additionally, Computer software piracy is a growing
`problem, and the existing simple means which prevent this
`problem (such as registration or serial numbers and
`customer-names being encoded within the product) are
`becoming less effective.
`
`000008
`
`000008
`
`

`
`@006328
`
`3
`There is necessity within the try-before-you-buy software
`market for vendors to employ effective features which allow
`old software to expire without fear of hackers or the like
`removing said expiry features and for secure registration of
`software to be provided through the use of software unlock-
`codes.
`
`There is also need for software to be able to prevent
`security attacks upon itself (ie: tampering) and upon its own
`attack-detection code. There may also be a future need for
`software to identify the attacker for subsequent prosecution.
`There also exists cases where untamperable software
`usage metering may be desirable, and where effective
`password-protection of software execution may also be
`desirable.
`
`Known advances in certain areas of computer security
`have been successful and documented. There have been
`
`some advances in anti-virus technology which help detect
`and prevent certain security problems. There have been
`numerous advances in hardware-assisted computer security
`add-ons and devices, such as smartcards and biometric input
`devices. There have been advances in cryptographic tech-
`niques. Generally, all of these advances require authentic,
`un-tampered-with computer software in order to work.
`There have been relatively few advances in software based
`integrity self-checking (eg: tamper protection), and no prior
`software-based advances in preventing eavesdropping or the
`electronic theft of ID-Data, and no prior software-based
`advances in self-authentication.
`
`SUMMARY OF THE INVENTION
`
`This invention seeks to provide computer software having
`enhanced security features, to a process which substantially
`enhances the security of computer software (hereafter
`referred to as the improved process) and to a method by
`which to apply said improved process (hereafter referred to
`as the applicator).
`The improved process consists of including computer
`code to automatically detect tampering of said computer
`software, and computer code to prevent the theft of ID-Data
`by replacing existing vulnerable (to rogue software eaves-
`dropping or attack) software or operating system code with
`secure equivalents which utilise anti-spy techniques (as
`described later in this document).
`Preferably, the improved process also consists of includ-
`ing computer code to prevent decompilation, reverse-
`engineering, and disassembly by the inclusion of obfuscat-
`ing code inserts, and the use of executable encryption.
`Preferably, the improved process also consists of includ-
`ing code to prevent execution-tracing and debugging by the
`use of code designed to detect and prevent these operations.
`Preferably,
`the improved process consists of, or also
`includes, human-recognisable audio-visual components
`which permit the authenticity of said computer software to
`be easily verified by the user on each invocation using
`techniques described later in this document.
`The idea which lead to the creation of this invention can
`
`be summarised as follows: If a piece of computer software
`that is executing can be shown to be the genuine article, and
`this software can protect itself against eavesdropping, and
`this software can prevent tampering of itself,
`then is it
`possible for this software to function in a secure manner,
`even within an insecure operating system. This invention
`permits the creation of such a piece of computer software—
`having a tangible, useful security advantage and hence
`improving its value.
`
`4
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`The present invention will become more fully understood
`from the following detailed description of preferred but
`non-limiting embodiments thereof, described in connection
`with the accompanying drawings, wherein:
`FIG. 1 illustrates the standard operation of a computer
`system known in the prior art;
`FIG. 2 illustrates the known operation of a rogue or
`“spoof” program;
`FIG. 3 illustrates application code updated with the pre-
`ferred embodiment;
`FIG. 4 illustrates the known operation of a rogue eaves-
`dropping program;
`FIG. 5 illustrates the interaction of the components of the
`updated application;
`FIG. 6 illustrates the general structure of the preferred
`embodiment of the applicator;
`FIG. 7 illustrates a standard layout for a program to be
`executed on a computer system;
`FIG. 8 illustrates the standard layout of an EXE header
`under the MS-DOS operating system.
`FIG. 9 illustrates a standard layout of an EXE program
`under MS-DOS;
`FIG. 10 illustrates an altered executable form constructed
`
`in accordance with the specific embodiment;
`FIG. 11 illustrates a first stage of execution of the new.exe
`executable;
`FIG. 12 illustrates a second stage of execution of the
`new.exe executable file; and,
`FIG. 13 illustrates a third stage of execution of the
`new.exe executable file.
`
`DETAILED DESCRIPTION OF PREFERRED
`EMBODIMENTS
`
`40
`
`Throughout the drawings, like numerals will be used to
`identify similar features, except where expressly otherwise
`indicated.
`
`As will be described hereinafter, the present invention has
`general applicability to many different operating systems
`including MICROSOFT DOSTM (Microsoft Disk Operating
`System) APPLE MACINTOSH OPERATING SYSTEM,
`UNIXTM, etc.
`Detailed hereafter are several security-enhancing tech-
`niques to combat eavesdropping. Security is provided by (a)
`hampering examination of software-code operating system
`code or or parts thereof through the use of the encryption or
`partial encryption of said code, (b) preventing the disassem-
`bly of said code through the inclusion of dummy instructions
`and prefixes and additional code to mislead and hamper
`disassembly (ie: obfuscating inserts), (c) preventing the
`computerised tracing of the execution of said code (for
`example: with code debugging tools) through the use of
`instructions to detect, mislead, and hamper tracing,
`(d)
`preventing tampering of said code through the use of scan-
`ning to locate alterations, either or both on-disk and in
`memory either once at the start of execution, or continuously
`upon certain events, or (e) preventing ID-Data theft through
`the inclusion of secure input/output routines (for example:
`routines to bypass the standard operating system keyboard
`calls and use custom-written higher-security routines as a
`replacement) to replace insecure computer-system routines.
`Hereafter, the term anti-spy will be used to refer to any
`combination of one or more of the abovementioned tech-
`
`45
`
`50
`
`55
`
`60
`
`65
`
`000009
`
`000009
`
`

`
`@006328
`
`5
`
`niques [(a) through (e) or parts thereof] used to prevent
`eavesdropping.
`Referring now to FIG. 1 there is illustrated the standard
`scenario for “running” a given executable program 16, under
`the control of a computer operating system 17 on a computer
`18. In the preferred embodiment of the present invention, the
`executable program 16 is subjected to modification, as will
`be described hereinafter, to ensure its integrity and improve
`its security. There are five aspects of this inventions
`improved process, although said provess is still substantially
`improved even if not all of them are present. These aspects
`are: (1) Preventing eavesdropping (2) preventing disassem-
`bly and examination (3) detecting tampering (4) preventing
`execution-tracing and (5) ensuring authenticity.
`Preferred embodiments illustrates each of these aspects of
`the present invention will now be described.
`
`Aspect 1. Preventing Eavesdropping
`
`As hereinbefore described, it is desirable to prevent rogue
`software from eavesdropping on ID-Date. By replacing
`software which is vulnerable to eavesdropping with equiva-
`lent software which is far more secure,
`this purpose is
`achieved. To remove the vulnerability from the secure
`equivalent software, replacement routines may communi-
`cate directly with the hardware of the computer (for
`example, they may communicate with the keyboard circuitry
`instead of using the system-supplied (and hence possibly
`insecure) application interface keyboard-entry function-
`calls.) while disabling system interrupts which would permit
`rogue software to eavesdrop. Said replacement routines are
`coded to store ID-Data retrieved in a secure manner. ID-Data
`
`is not stored in full in plaintext (ie: unencrypted) in system
`or application buffers.
`
`Aspect 2. Preventing Disassembly and Examination
`
`is desirable to hamper
`it
`As hereinbefore described,
`disassembly (or de-compilation or reverse engineering) to
`protect software against eavesdropping and tampering, and
`to hinder examination of said software which might lead to
`secret security problems or mistakes being disclosed.
`Obfuscating inserts can successfully prevent automatic
`disassembly. Obfuscation is achieved by following uncon-
`ditional jump instructions (for example, Intel JMP or CLC/
`JNC combination or CALL (without a return expected) or
`any flow-of-control altering instruction (which is known not
`to return to the usual place) with one or more dummy
`op-code bytes which will cause subsequent op-codes to be
`erroneously disassembled (for example,
`the Intel 0xEA
`prefix will cause disassembly of the subsequent 4 op-codes
`to be incorrect, displaying them as the offset to the JMP
`instruction indicated by the 0xEA prefix instead of the
`instructions they actually represent).
`Dummy instructions may also be included to hamper
`disassembly by deliberately misleading a disassembler into
`believing a particular flow of control will occur, when in fact
`it will not.
`
`Flow of control can be designed to occur based upon CPU
`flag values determined from instructions executed a long
`time ago. Together with tracing preventing,
`this makes
`manual disassembly nearly impossible.
`The majority of the executable portions of the software
`can be encrypted for external storage. The decryption taking
`place in-memory after the software is loaded from external
`sources, under the control of a decryption “header” which
`prevents its own tampering and disassembly etc. This makes
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`manual and automatic disassembly nearly impossible, since
`the decryption should be designed to fail if tampering or
`tracing is detected.
`
`Aspect 3. Detecting Tampering
`
`is desirable to detect
`it
`As hereinbefore described,
`tampering, since this may lead to the reduction of software
`security.
`This can be achieved with the use of code which is
`
`protected from disassembly and examination through obfus-
`cation and encryption, which re-reads its own external-
`image and compares it with its known memory image or
`precalculated check-data to detect hot-patching (ie.
`the
`modification of software sometime after it has been loaded
`
`from disk, but (usually) before execution of the modified
`section has commenced).
`Additionally, the software can scan the memory image of
`itself one or more times, or continuously, to ensure that
`unexpected alterations do not occur.
`Certain modifications to the external copy of software are
`reflected in subtle changes to the environment in which the
`modified software will be executed (for example: the size of
`the code, if altered, will be reflected in the initial code size
`value supplied to the executing program being incorrect.).
`Additionally, certain modification to the operating system
`and environment of said software can also be monitored (for
`example: certain interrupt vector table pointers in Intel-
`processor applications) to detect unexpected changes by
`rogue software. These changes can also be detected to
`prevent tampering.
`Once tampering is detected, program flow-of-control
`needs to be changed so that
`the potential compromise
`associated with ID-Data theft is avoided. This may be the
`security-enhanced program terminating with a message indi-
`cating that its integrity has been compromised before all of
`the ID Data is entered. Alternatively, the fact that tampering
`has been detected may be kept secret and the ID-Data
`retrieved, however, immediately upon retrieval, the ID-Data
`entered can be invalidated thus preventing access to that
`which the now potentially compromised ID-Data would
`have otherwise allowed. This latter method allows for the
`
`possibility of security-enhanced software informing remote
`or other authorities that tampering was detected and possibly
`other information, such as what specifically was altered and
`by whom. Care must be taken to ensure the integrity of the
`“remote-informing” code before ID-Data entry is permitted.
`
`Aspect 4 Preventing Execution-Tracing
`
`Apart from “spoofing” (described in aspect 5 hereafter)
`the last resort of a rogue who is prevented from disassembly,
`tampering, and eavesdropping on software is to trace the
`execution of said software in order to facilitate the compro-
`mise of its security. Hampering tracing (tracing, is some-
`times called debugging) prevents this.
`There are numerous methods of detecting a debug-
`environment (ie: when tracing is taking place). When com-
`bined with decryption and tamper-protection as hereinbefore
`described, it makes the rogues task of detecting and bypass-
`ing debug-detection extremely difficult. Reference and
`examples to Intel and MS-DOS environments follow
`hereafter, although it will be apparent to one skilled in the art
`that
`these and similar methods are applicable on other
`platforms.
`Standard Intel x86 interrupts 1 and 3 are used by debug-
`gers to facilitate code tracing. By utilising these interrupts
`
`000010
`
`000010
`
`

`
`6,006,328
`
`7
`
`(which are not normally used by normal applications) in
`security-enhanced software,
`it hampers debugging, since
`built-in debugging functions are now not automatically
`available.
`
`Monitoring the system timer to determine if software
`execution has spent too long accomplishing certain tasks can
`detect a situation where code tracing has been in effect and
`a breakpoint was reached.
`Disabling the keyboard will hamper debuggers, since
`tracing instructions are usually issued from the keyboard.
`Similarly, disabling other places from where tracing instruc-
`tions are usually issued (eg: serial ports, printer ports, and
`mouse) or displayed (eg: screen) will also hamper tracing.
`System interrupts can be re-vectored for use within the
`secure software to perform tasks not usually performed by
`those interrupts. Debuggers usually rely upon system inter-
`rupts also, so to do this would usually disable or destroy a
`debugger being used to trace the software. Disabling inter-
`rupts and performing timing-sensitive instructions between
`them will further hamper debugging. When tracing software,
`instructions are usually executed one-at-a-time in order for
`the user to understand their operation. Many system inter-
`rupts must occur regularly (eg: timer and memory re-fresh
`operations), so debuggers usually do not disable interrupts
`even when they encounter an interrupt-disabling instruction.
`If timers and the like are re-vectored in two separate stages,
`any timer (etc) interrupt occurring in between the two stages
`will fail, and usually crash the computer. Further, interrupts
`can be disabled or enabled using obscure means (with
`flag-altering instructions for example) to hamper tracing.
`Discretely testing the status of disabled or enabled system
`facilities (eg. interrupts, keyboard, vector-pointers) to ensure
`that a debug environment has not altered or by-passed them
`will seriously hamper tracing also.
`Certain computer processors have instruction caches. In
`some circumstances, it is possible to alter the instructions
`immediately before the CPU encounters them, but
`the
`altered instruction will not be executed normally because the
`cache copy has the “old” one still. In debug environments,
`the cache is usually flushed, so any altered instructions will
`actually be executed. This again hampers tracing.
`Using strong cryptographic schemes such as DES “(Data
`Encryption Standard)”, or RSA “(RIVEST, SHAMIR,
`ADELMAN, Algorithm) ” or
`the like will present
`the
`examination of any decryption routines from revealing a
`simple patch to disable said routines. When tracing software,
`the program stack is usually used by the debugger either
`during the tracing operations or at other times. This is easily
`detected, and by using the area of the stack which will be
`destroyed by unexpected stack-use for code or critical data,
`software can be designed to self-destruct in this situation.
`Scanning the command environment and the execution
`instruction can detect the execution of software by unusual
`means. Searching for “DEBUG” in the command line, or
`scanning memory for known debuggers for example will
`detect
`tracing. Additional, by detecting which operating
`system process initiated the load of the software, unexpected
`processes (eg: debuggers) can be detected.
`Monitoring system buffers (eg:
`the key board memory
`buffer) or hardware (eg: the keyboard circuitry and internal
`buffers) for unexpected use (eg: keyboard input and pro-
`cessing is occurring when the software is not requesting it)
`will also detect debuggers, which usually rely in part on
`system functions in order to operate.
`Building a process or multiple processes which are tra-
`ditionally difficult to trace, such as a resident or child process
`
`8
`which executes during system interrupts or after the parent
`process has terminated will again hamper tracing.
`Bypassing system routines (eg:
`in DOS, using direct
`memory writes instead of DOS system calls to revector
`interrupts) will further hamper debugging and rogue soft-
`ware monitoring, as will unravelling loop constructs (which
`will make tracing long and cumbersome). Code checksums
`and operating-system checks (eg: interrupt table pointers)
`can be designed to detect debug-breakpoint
`instruction
`inserts or other modifications. Using the result of the check-
`sum for some obscure purpose (eg: decryption, or (much
`later) control-flow changes) will further hamper tracing.
`It will be apparent to one skilled in the art of low-level
`software programming that a combination of techniques to
`detect, prevent, and mislead tracing will provide a mecha-
`nism making tracing very difficult, if not impossible. At the
`very least, it will require an expert with very expensive tools
`and perhaps some understanding of the original software
`design a very long time to make any debugging progress—a
`situation which is recognised in military software security
`accrediation worldwide as highly desirable.
`
`Aspect 5 Ensuring Authenticity
`In accordance with an aspect of the present invention
`there is provided a method of providing for a secure entry of
`ID-Data in a computer system comprising activating a visual
`display or animation and/or audio feedback (hereinafter
`called an audio/visual component) as part of said secure
`entry of ID-Data so as to hamper emulation of said secure
`entry process. Preferably, the animation includes feedback
`portions as part of the ID-Data entry process. Preferably, the
`animation is repeatable and varied in accordance with the
`information entered. The animation preferably comprises
`2.5D or 3D animation and includes animation of any
`ID-Data input.
`Preferably, the animation is designed to tax the computer
`resources utilised and thereby making any forgery thereof
`more difficult.
`
`It will be apparent to one skilled in the art of low-level
`software programming that the five aspects described herein
`may be combined to provide substantially stronger security
`than any aspect taken on its own. For instance, to combine
`tamper-detection with encryption, the precalculated check-
`data as derived during tamper-detection described herein-
`before may actually be one part of the decryption-key which
`is required to successfully decrypt the remaining executable
`software. If prevention-of-tracing and environment charac-
`teristics (including debugger detection as described
`hereafter) are additional portions of said decryption-key, it
`makes the determination of said decryption-key by any
`person or computer program other than the secure original
`an extremely difficult, if not impossible, task.
`Further, it will also be apparent to one skilled in the art of
`low-level software programming that a simple construct
`such as a JNE to alter program flow-of-control after tam-
`pering has been detected is insufficient, since the JNE
`construct
`itself is subject
`to tampering. The decryption
`process described hereinbefore is preferable since there is no
`single point of alternation that can possibly yield a tampered
`executable that would execute. Indeed, the executable pro-
`tected with encryption will not even be transformed into its
`intended form if tampering is detected.
`GENERAL DESCRIPTION OF PREFERRED
`
`EMBODIMENT(S)
`Notwithstanding any other forms which may fall within
`the scope of the present invention, preferred forms of the
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`00001 1
`
`000011
`
`

`
`@006328
`
`9
`invention will now be described, by way of example only,
`with references to the accompanying drawings.
`In the preferred embodiment of the present invention the
`user interface for
`the acquiring of ID-Data is secured
`whereby the duplication of the interface is rendered math-
`ematically complex such that cipher-code breaking tech-
`niques are required to produce a counterfeit
`look-alike
`interface. By making the authentication interface (ie:
`ID-Data entry screen—for example: a logon screen or a
`screen for entering credit card details) unable to be
`emulated, tampered with, or reversed engineered, the appli-
`cation program allows for a higher degree of security and
`authenticity even in insecure environments such as the
`Internet or home software applications. Referring now to
`FIG. 2, there is illustrated a classic form of rogue attack on
`a computer system. In this form of rogue attack, a rogue’s
`“spoof” program 22 is inserted between application software
`16 and the user 23. The application 16 normally has a
`portion 24 devoted to ID-Data entry and verification or the
`entry of commercially sensitive information (including pass-
`words etc) to the application in addition to the application
`code 25. The spoof program 22 is designed to exactly reflect
`the presented user interface of ID-Data entry code 24 to the
`user. The user 23 is then fooled into utilising the masquer-
`ading spoof program 22 as if it was the application 16.
`Hence the user can be tricked into divulging secret infor-
`mation to the spoof program 22. An example may include a
`classic “login spoof” wherein the spoof program 22 prints
`the login prompt (ie: ID-Data entry) message on the screen
`and the user mistakes the login prompt for a legitimate one,
`supplying a user name and password to this program 22
`which records this information as well as passing it on to the
`login code 24 of application 15 so as not to arouse the
`suspicion of user 23—or by issuing a message, such as
`“incorrect password, please try again” and then passing
`control to the login code 24 of application 16.
`Referring now to FIG. 4, there is illustrated a relatively
`new form of rogue attack 40. This form of attach proceeds
`similarity to the spoof attack of FIG. 2, with the following
`difference. Instead of a spoof program 22, a rogue program
`41 is inserted which secretly eavesdrops on ID-Data entry
`code 24, or on application code 25, or on operating system
`17, or on h