`
`Exhibit 1
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 2 of 21
`
`US007162735B2
`
`(12) United States Patent
`Safa
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,162,735 B2
`Jan. 9, 2007
`
`(54) DIGITAL DATA PROTECTION
`ARRANGEMENT
`
`*) Notice:
`
`(75) Inventor: John Aram Safa, Nottingham (GB)
`(73) Assignee: Simplex Major Sdn. Bhd, Selangor DE
`(MY)
`Subject to any disclaimer, the term of this
`y
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 932 days.
`(21) Appl. No.: 09/905,571
`(22) Filed:
`Jul. 13, 2001
`(65)
`Prior Publication Data
`US 2002fOO38428 A1
`Mar. 28, 2002
`
`Foreign Application Priority Data
`(30)
`Jul. 18, 2000
`(GB) ................................. OO17481.3
`Feb. 7, 2001
`(GB) ................................. O1 O2982.6
`
`(51) Int. Cl.
`(2006.01)
`GOOF 7/30
`(52) U.S. Cl. ............................... 726/6; 726/21: 726/27
`(58) Field of Classification Search ................ 713/200,
`713/190–193: 726/3, 21, 27, 6
`See application file for complete search history.
`References Cited
`
`(56)
`
`U.S. PATENT DOCUMENTS
`
`4,120,030 A 10, 1978 Johnstone
`4,525,599 A
`6, 1985 Curran et al.
`4,633,388 A 12, 1986 Chiu
`4,634,807 A
`1/1987 Chorley et al.
`4,847,902 A
`7/1989 Hampson
`4,888,802 A 12/1989 Cooney
`5,081,675 A
`1/1992 Kittirutsunetorn
`5,224,166 A
`6/1993 Hartman, Jr.
`
`9/1997 McCarty
`5,666,411 A
`5,982,887 A 11/1999 Hirotani
`5,995,623 A 11/1999 Kawano et al.
`6,006,328 A 12, 1999 Drake
`6,052,780 A
`4/2000 Glover
`6,185,686 B1
`2/2001 Glover
`
`FOREIGN PATENT DOCUMENTS
`
`EP
`EP
`EP
`EP
`GB
`GB
`WO
`WO
`
`O 191 162
`O 727 746
`O 768 601
`0 706 118
`2 140 592
`2330 932
`OO,26791
`01.08345
`
`2, 1993
`8, 1996
`4f1997
`3, 2000
`11, 1984
`5, 1999
`5, 2000
`2, 2001
`
`OTHER PUBLICATIONS
`e-NeXSh: achieving an effectively non-executable stack and heap
`via system-call policing Kc, G.S.; Keromytis, A.D., Computer
`Security Applications Conference, 21st Annual Dec. 5-9, 2005 pp.
`15.*
`
`(Continued)
`Primary Examiner David Jung
`(74) Attorney, Agent, or Firm Smith-Hill and Bedell
`(57)
`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.
`
`40 Claims, 9 Drawing Sheets
`
`-
`Jod- &Janus
`
`say
`
`t
`
`sees
`
`ce s e s is a s 6
`
`foe
`
`age
`
`S.
`
`Poes
`
`
`
`co
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 3 of 21
`
`US 7,162,735 B2
`Page 2
`
`OTHER PUBLICATIONS
`
`Managing system and active-content integrity Michener, J.R., Acar,
`T: Computer vol. 33, Issue 7, Jul. 2000 pp. 108-110.*
`
`A method for detecting obfuscated calls in malicious binaries Arun
`Lakhotia; Eric Uday Kumar; Venable, M.; Software Engineering,
`IEEE Transactions on vol. 31, Issue 11, Nov. 2005 pp. 955-968.*
`* cited by examiner
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 4 of 21
`
`U.S. Patent
`
`Jan. 9, 2007
`
`Sheet 1 of 9
`
`US 7,162,735 B2
`
`
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 5 of 21
`
`U.S. Patent
`
`Jan. 9, 2007
`
`Sheet 2 of 9
`
`US 7,162,735 B2
`
`fe 2 c.
`
`
`
`A.
`T
`
`(2.
`Sep
`
`
`
`Sea
`a
`
`
`
`22
`
`O
`
`lax1
`fro1eC11on N &
`
`14 G
`
`2e.
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 6 of 21
`
`U.S. Patent
`
`Jan. 9, 2007
`
`Sheet 3 of 9
`
`US 7,162,735 B2
`
`
`
`
`
`3CO -
`
`T - a
`
`- SNS
`
`em.
`
`-rm - we
`
`-r a 1-h
`
`do
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 7 of 21
`
`U.S. Patent
`
`Jan. 9, 2007
`
`Sheet 4 of 9
`
`US 7,162,735 B2
`
`P2d 6 RA r^
`
`S.
`
`Y
`
`i
`
`1
`
`I 3, 200
`
`
`
`fic 5. A
`
`fict 5-l
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 8 of 21
`
`U.S. Patent
`
`Jan. 9, 2007
`
`Sheet 5 Of 9
`
`US 7,162,735 B2
`
`Y
`
`fN) & Ne
`
`bo
`
`52.
`
`
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 9 of 21
`
`U.S. Patent
`
`Jan. 9, 2007
`
`Sheet 6 of 9
`
`US 7,162,735 B2
`
`EN) G. N. a.
`
`fg fic
`
`62
`
`O
`
`
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 10 of 21
`
`U.S. Patent
`
`Jan. 9, 2007
`
`Sheet 7 Of 9
`
`US 7,162,735 B2
`
`2.
`
`f
`
`Application
`(eNC2Y Piao)
`
`
`
`
`
`A ?plit CAT on
`(éN clay Ata ())
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 11 of 21
`
`U.S. Patent
`
`Jan. 9, 2007
`
`Sheet 8 of 9
`
`US 7,162,735 B2
`
`
`
`TOA
`
`
`
`TO3
`
`
`
`
`
`O
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CC
`
`fiNAL - Né of glC cle
`
`Co
`
`Oec2Y at
`LASia a
`Key is
`
`or
`li rules
`R toro 2. Thir
`Cf2 c of limes
`
`10 2.co
`
`on 1 c 2 oc
`
`- f2ST L Na Of Vax,
`
`3 Loue
`
`2.
`
`Fle O
`
`ae g
`
`foe C2y2 AfL 4-4Tar)
`
`ed as
`
`At? at C-1 onw
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 12 of 21
`
`U.S. Patent
`
`Jan. 9, 2007
`
`Sheet 9 of 9
`
`US 7,162,735 B2
`
`
`
`
`
`r
`
`"ris M.
`
`1
`
`Y
`
`I
`
`-
`
`- - -- 1
`
`AAP). cAfer
`(e NJCA/Preo)
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 13 of 21
`
`US 7,162,735 B2
`
`1.
`DIGITAL DATA PROTECTION
`ARRANGEMENT
`
`2
`instructions for decryption. The protected data may contain
`executable code and/or a data file. The arrangement may
`comprise processing means operable to execute code, and
`memory means within which the said executable code is
`stored, the executable code being stored in the memory
`means with a start point at a memory location indicated
`within the arrangement as the start point for the protected
`data, whereby the processor means will cause the said
`executable code to be executed when seeking to access the
`protected data. The executable code is preferably operable to
`recreate the protected data in Substantially unencrypted
`form.
`The protected data may contain at least one executable
`instruction which contains a plurality of steps, the steps
`being executable in more than one order to implement the
`instruction, and the executable code being operable to create
`the instruction by creating the steps in an order which
`changes on each execution of the executable code. The order
`of the steps is preferably chosen Substantially at random on
`each execution. The steps may include at least one step
`which initiates the operation of security means operable to
`detect corruption of the protected data. The executable code
`may be executed to create the steps on each occasion that the
`executable instruction is to be executed.
`The executable code may be arranged to provide, upon
`each execution, a part of the protected data in usable form
`and other data in corrupt form, whereby more than one
`execution is required to provide the whole of the protected
`data in usable form. Each part may correspond with a
`complete executable routine within the protected data,
`whereby a complete set of routines forming the protected
`data can be created by repeated execution of the executable
`code. Each execution of the executable code preferably
`causes previously created usable code to be corrupted,
`whereby only the code created by the most recent execution
`will be in usable form during operation of the arrangement.
`The invention also provides a computer system compris
`ing memory means containing a digital protection arrange
`ment according to any of the preceding definitions.
`The invention also provides a data carrier containing
`Software which, when installed on a computer system, is
`operable as a digital data protection arrangement in accor
`dance with any of the preceding definitions.
`The invention also provides computer software which,
`when installed on a computer system, is operable as a digital
`data protection arrangement in accordance with any of the
`preceding definitions.
`The invention also provides computer software operable
`to provide protection for a second item of computer soft
`ware, the protection Software comprising security means
`operable to authorise execution of the protected software in
`response to Successful completion of one or more security
`checks, and having at least one block of executable code
`which is stored in non-executable form and which requires
`execution to authorise execution of the protected Software,
`and the protection Software further comprising conversion
`means operable to convert the said block of code to an
`executable form by means of an algorithm which requires at
`least one conversion key, the conversion means being further
`operable to derive a conversion key, for use in the algorithm,
`by reference to a target block of code in executable or
`non-executable form, whereby an appropriate conversion
`key will be derived only if the target block is unmodified.
`The invention also provides a computer memory device
`containing computer software as set out above.
`
`This application claims priority under 35 USC 119 of
`United Kingdom Patent Application No. 0017481.3 filed Jul.
`18, 2000 and United Kingdom Patent Application No.
`0102962.6 filed Feb. 7, 2001.
`The present invention relates to protection arrangements
`for digital data.
`Digital data, including software files and data files, may
`need protection for various reasons. For instance, protection
`may be required against unauthorised copying. In the case of
`Software, protection may be required against corruption by
`virus attack, hacking or the like.
`The invention seeks to provide an improved protection
`arrangement for digital data.
`The invention provides a digital data protection arrange
`ment comprising executable code which incorporates Sufi
`cient information relating to the protected data to be able to
`create, when executed, further code which contains the
`protected data in usable form.
`The arrangement may comprise security means operable
`to detect corruption of the protected data, the further code
`incorporating at least one instruction to call the security
`means to assess any corruption. Preferably the call instruc
`tion is contained within the further code at the required
`location of a set of executable code, and wherein the security
`means is operable to recreate the set of executable code
`when executed, to replace the call instruction. The security
`means is preferably operable to delete the further code in the
`event that any corruption is detected.
`The arrangement may further comprise relocation means
`operable to change the location of the security means and to
`modify the call instruction to refer to the new location. The
`relocation means may be contained within the protected
`data, to operate repeatedly while the protected code is in use.
`The executable code may contain executable instructions
`for creating the protected code. Execution of the executable
`code preferably installs the decryption instructions for
`execution, Subsequent execution of the decryption instruc
`tions causing decryption of the protected data. The decryp
`tion instructions may be stored initially in non-executable
`form and which requires execution to authorise execution of
`the protected Software, the arrangement further including
`conversion means operable to convert the said block of code
`to an executable form by means of an algorithm which
`requires at least one conversion key, and further operable to
`derive a conversion key, for use in the algorithm, by refer
`ence to a target block of code which is in executable or
`nonexecutable form, whereby an appropriate conversion key
`will be derived only if the target block is unmodified.
`The security means may comprise a plurality of blocks of
`executable code stored in non-executable form and each of
`which requires execution to authorise execution of the
`protected Software, the conversion means being operable to
`convert each block to executable form. Conversion of each
`block is preferably achieved by a conversion key derived
`from a respective target block. At least one block is prefer
`ably operable, upon execution, to convert another block to
`an executable form for subsequent execution. Each block is
`preferably operable, upon execution, to convert another
`block to an executable form for Subsequent execution.
`The or each target block may be contained within the
`protected software or within the first security means.
`The or each algorithm for converting code may include a
`CRC algorithm. The executable code may incorporate the
`protected data in encrypted form, together with executable
`
`5
`
`10
`
`15
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 14 of 21
`
`3
`The invention also provides a computer system containing
`an item of computer software protected by means of com
`puter Software as set out above.
`Examples of the present invention will now be described
`in more detail, by way of example only, and with reference
`to the accompanying drawings, in which:
`FIG. 1 illustrates, in a highly simplified form, a computer
`system for use in implementing the present invention;
`FIG. 2 is a highly schematic representation of a known
`arrangement for storing software in RAM;
`FIG. 3 illustrates the use of RAM in accordance with the
`present invention;
`FIG. 4 illustrates the use of RAM in accordance with the
`present invention and incorporating a relocation arrange
`ment,
`FIG. 5 illustrates the use of RAM in accordance with the
`present invention and incorporating embedded security pro
`cedures.
`FIG. 6 illustrates the use of RAM in accordance with the
`invention and incorporating a self-modification arrange
`ment,
`FIG. 7 illustrates the use of RAM in accordance with the
`invention and incorporating arrangements for partial decryp
`tion of protected data;
`FIG. 8 is a schematic diagram of the contents of RAM in
`a system implementing a further example of the invention
`using a separate security block;
`FIG. 9 corresponds with FIG. 8, showing an alternative to
`the example of FIG. 8:
`FIG. 10 schematically illustrates part of the listing of the
`security software of FIGS. 8 and 9:
`FIG. 11 schematically illustrates the end of the listing of
`the security software of FIGS. 8 and 9; and
`FIG. 12 schematically illustrates a further form of imple
`mentation of the invention;
`In order to explain the invention, it is useful first to
`describe briefly a simple computing arrangement with which
`the present invention may be implemented. FIG. 1 shows a
`computing arrangement 10 which consists of conventional
`hardware components, including a processor 12 to which
`appropriate input and output devices are connected, such as
`a keyboard 14 and a display 16. Memory is provided in the
`form of a hard drive 18, or similar bulk memory device, and
`in the form of RAM (Random Access Memory) 20, for use
`by the processor 12 during the execution of software. The
`arrangement may be of the type known as an IBM PC, or
`equivalent or similar machine.
`FIG. 2 illustrates how RAM 20 is conventionally used to
`run software stored on the drive 18 of an arrangement 10.
`Initially, the software is loaded by the processor 12 from the
`drive 18 into RAM 20, resulting in a sequence of machine
`code steps 22 (illustrated as STEP1, STEP2 etc.), stored in
`sequence in the RAM 20. The sequence of steps ends with
`an EXIT instruction 24. It will be appreciated that in a
`practical example, the number of steps may vary from that
`shown, and will usually be very much greater in number.
`The first step, STEP 1, is conventionally preceded by a
`LOADER block of code 26 which, when executed, causes
`other resources to be identified and made available to the
`software in the RAM, such as drivers for input/output
`devices 14, 16, or other software resources commonly
`shared by various different application programs.
`In the course of loading the software to the form illus
`trated in FIG. 2, the processor 12 of the arrangement 10 will
`record a start point for the block of executable data illus
`trated, i.e. the memory location in the RAM 20 at which the
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 7,162,735 B2
`
`5
`
`10
`
`15
`
`4
`LOADER 26 begins. The noting of this start point is
`illustrated schematically in FIG. 2 (and in other FIGS) by the
`use of an arrow 28.
`When the arrangement 10 is instructed to run the software
`now contained within the RAM 20, the processor 12 first
`goes to that location of the RAM 20 which is identified as
`the start point 28 and begins to execute the executable data
`found at that location. Thus, the processor 12 will first
`execute the LOADER 26, followed by the steps 22, even
`tually finishing at the EXIT step 24.
`It is apparent from FIG. 2 that the software in the RAM
`20 is exposed in unencrypted form and is therefore vulner
`able to attack by virus Software, to unauthorised copying, or
`to analysis by a malevolent user seeking to attack the
`software by virus creation or otherwise.
`
`EXAMPLE 1.
`
`FIG. 3 illustrates a basic arrangement according to the
`invention, by which the protection of the software is
`improved. FIG. 3A illustrates the state of the RAM 20 when
`software protected in accordance with the invention is first
`loaded from the drive 18.
`In the condition of FIG. 3A, the RAM 20 contains an
`initial block of executable code called here an ENGINE 30
`and located at the start point 28 noted by the processor 12 for
`the protected software Below the ENGINE 30 the RAM 20
`is empty at 32.
`The ENGINE 30 is executable code, as has been stated.
`However, the ENGINE 30 is not executable to implement
`the protected software. Instead, the engine 30 is executable
`in order to recreate the protected software and write this into
`the empty region 32 of the RAM 20 when the ENGINE 30
`is executed. Thus, in a simple form, the ENGINE 30 may
`consist of an encrypted version of the protected data (or
`addresses at which an encrypted version is available),
`together with executable software for decrypting the soft
`ware and writing it to the region 32.
`It is to be clearly understood that in this document, the
`term encryption and related terms refer to any technique,
`including compression, by which data is converted from its
`usable form into another form which is not immediately
`executable. Decryption and related terms are used to refer to
`the reverse process, including the process of decompression.
`It is to be noted in FIG. 3A that the engine 30 is situated
`at the start point 28. Consequently, when the protected
`software is called, the processor 12 will first go to the
`location 28 and thus begin to execute the code which forms
`the ENGINE 30. Initially therefore, the protected software
`will be recreated in unencrypted form to fill the space 32, as
`illustrated in FIG. 3B.
`As the processor 12 continues to execute the ENGINE 30,
`the program pointer will eventually reach the beginning of
`STEP1, illustrated at 34 in FIG. 3B, by which time, STEP
`1 and the remainder of the protected data will have been
`recreated in the space 32, so that execution of the protected
`software will then commence.
`It will be realised that the execution of the ENGINE 30
`constitutes an additional step in comparison with the con
`ventional arrangement illustrated in FIG. 2. However, it is
`envisaged that the operation of the ENGINE 30 in machine
`code will be sufficiently swift to prevent this extra step being
`noticeable to a user.
`Having explained this basic operation as illustrated in
`FIG. 3, it can be seen that the protected data is less
`Vulnerable to copying or analysis than in the conventional
`arrangement in FIG. 2. This is because the protected data is
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 15 of 21
`
`US 7,162,735 B2
`
`5
`not available for attack, copying or analysis until the
`ENGINE 30 has executed, i.e. until the protected software
`has been called. Simply loading the protected data from the
`drive 18 to the RAM 20 is not sufficient to expose the
`protected data to attack, copying or analysis.
`While the arrangements of FIGS. 3A and 3B improve on
`the arrangement of FIG. 2, it is apparent that once the
`ENGINE 30 has run, the protected data is then exposed at
`FIG. 3B in the same manner as it was exposed once in RAM
`in the form of FIG. 2. In order to further improve the
`10
`protection, the ENGINE 30 can be modified to recreate data
`in the space 32 in the following manner.
`
`5
`
`6
`data contained in the RAM 20 (i.e. the whole of the contents
`of section 32 of the RAM), thereby deleting the virus or
`effects of a virus which has contaminated the protected code.
`It will be apparent that when operating in machine code
`and in a realistic situation involving very many lines of code,
`many CALL instructions 36 may be created by the ENGINE
`30A and at locations which will be difficult for a malevolent
`watcher to predict or to distinguish from call instructions
`conventionally found within a complex block of machine
`code. It therefore becomes much more difficult for a malevo
`lent watcher to analyse the operation of the protection, or for
`a virus to disable that protection. This protection can be
`further enhanced by having the engine 30A watch for a block
`of code which itself changes, perhaps each time a CALL
`instruction is inserted, thus making the insertion of the call
`instructions pseudo-random to the outside observer.
`
`EXAMPLE 3
`
`FIGS. 4A and 4B illustrate a protection arrangement with
`some similarities to the arrangements of FIGS. 3C, D and E.
`but providing additional security, as follows.
`Whereas the arrangement of example 2 uses a block 38
`which is separately identifiable, being located at the end of
`the block being protected, this example makes use of a block
`operating in a similar manner to the block 38, but embedded
`within the software being protected. This embedding pro
`cess can be explained by first considering FIG. 4A. FIG. 4A
`illustrates the RAM 20 when the engine (this time labelled
`30B) has created many lines of code of the protected
`Software, but has not yet completed execution, and has not
`yet created protection corresponding with the block 38.
`While FIG. 4A is also diagrammatic, it shows the state of the
`RAM 20 in more detail than is shown in FIGS. 3C to 3E. In
`particular, numbers are shown to the left of the RAM 20,
`indicating the line numbers of the corresponding machine
`code listing, representing the boundaries between various
`procedures provided by the machine code, these boundaries
`also being represented by lines which partition the RAM 20.
`Thus, below the engine 30B, a code for a first process PROC
`1 extends down to line 1,000, followed by code for a second
`process PROC 2 down to line 1,500, a third process PROC
`3 down to line 2,500 and finally a fourth process, PROC 4,
`down to line 3,200.
`In order to complete its execution, the engine 30B seeks
`to insert instructions which correspond with the block 38
`into the RAM 20, between the engine 30B and the end of the
`list at line 3,200. This is achieved by first looking through
`the contents of the RAM 20, to identify regions which
`contain no data. While the processes PROC 1 etc. are shown
`as contiguous within the RAM 20, areas of memory will
`nevertheless contain no data for various reasons. In particu
`lar, assembler and compiler software commonly has inefli
`ciencies in its routines, resulting in the creation of dataless
`areas of RAM. The engine 30B seeks to identify these areas.
`However, the algorithm by which the engine 30B functions,
`must also take into account that dataless areas can also arise
`for other reasons. For example, a process PROC 1 etc. might
`require access to a scratch pad for recording current values
`of variables, or the state of flags set during execution. These
`areas of RAM might initially be set to contain only Zeros,
`thus appearing dataless.
`Consequently, the engine 30B will first look through the
`RAM 20 to identify any areas which appear to be dataless.
`Each time an apparently dataless area is located, its location
`will be recorded by the engine 30B, for future reference. In
`FIG. 4A, for example, a relatively large area is apparently
`
`EXAMPLE 2
`
`15
`
`In the example of FIG. 3C to 3E, the RAM 20 initially
`contains only an ENGINE, labelled 30A in this example, and
`empty RAM32, as illustrated in FIG. 3A. Execution of the
`ENGINE 30A again fills the space 32. However, two
`changes are evident by comparison of FIG. 3D and FIG. 3B.
`First, STEP 2 has been replaced by a CALL instruction 36,
`and a PROTECTION block 38 has been inserted by the
`ENGINE 30A after the EXIT instruction 24. This is achieved
`in the following manner.
`While the ENGINE 30A is running to decrypt the pro
`tected data, the ENGINE 30A monitors the resulting
`decrypted code, looking for certain patterns or sequences of
`code. Further details of this will be explained below, in
`relation to Example 3. The ENGINE30A may be looking for
`one sequence or more than one sequence. Naturally, the
`length of the sequence being sought will affect the likelihood
`of the sequence being located. In this example, the ENGINE
`30A is looking for a sequence which corresponds with STEP
`2. When this predetermined set of code is located, in this
`case STEP 2, the ENGINE 30A does not write the prede
`termined set of code, but instead, writes a CALL instruction
`36, instructing the PROTECTION block 38 to be called.
`Consequently, when the ENGINE30A has run, the protected
`data is not fully visible, there being a CALL instruction 36
`in place of STEP 2.
`When the protected software runs, the program will, at
`some point, reach the location at which STEP 2 would be
`expected to begin, and will see the CALL instruction 36.
`Execution of the PROTECTION block 38 then begins. The
`block 38 has two functions. In one, code for STEP 2 will be
`created (in a manner similar to the operation of the engine
`30) and written over the CALL instruction 36, so completing
`the decryption of the protected code. The block 38 will also
`make security checks, such as by consulting conventional
`virus protection or the like, to ensure that the virus protec
`tion has properly run and that no corruption has been
`detected. In the event that nothing is amiss, the protection
`block 38 finishes, returning execution to the location from
`which the call to the protection block 38 occurred. That
`location is now the start of code for STEP 2. Operation then
`continues in the normal way, beginning with STEP 2.
`Again, it is envisaged that by operating entirely in
`machine code, this additional step can be so fast as to be
`unnoticeable to a user.
`It can thus be understood that the protected code does not
`become fully decrypted until the code is running, thus
`significantly reducing the risk of virus attack, unauthorised
`copying or malevolent analysis.
`If the PROTECTION block 38 finds something amiss
`when checking, appropriate retaliation may be implemented.
`In a simple examples particularly effective against virus
`attack, the block 38 will delete the version of the protected
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`
`
`Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 16 of 21
`
`US 7,162,735 B2
`
`8
`
`TABLE 1-continued
`
`56
`33F6
`57
`56
`8975FC
`E806F8FFFF
`8975FC
`E853F8FFFF
`894SFC
`FF30
`E8EOF7FFFF
`
`push esi
`Xor esi, esi
`push edi
`push esi
`mov dword ptrebp-04), esi
`cal O10073SD
`mov dword ptrebp-04), esi
`cal O1 OO73B2
`mov dword ptrebp-04), eax
`push dword ptreax
`call 01007349
`
`O1OO7B4A
`O1OO7B4B
`O1OO7B4D
`O1OO7B4E
`O1OO7B4F
`O1OO7BS2
`:01.007B57
`O1OO7BSA
`:01.007B5F
`O1OO7B62
`O1OO7B64
`
`It can be seen that the short section of listing in Table 1
`contains three call instructions, as will frequently arise
`within a complex piece of software. Each call instruction
`consists of the two bytes E8, followed by four bytes giving
`the address called.
`Table 1 thus shows the true listing of the protected
`software, such as a section beginning at line 800, within
`process PROC 1.
`When the engine 30B has inserted a call instruction, as
`described above, for instance at line 01007B45, the follow
`ing list results:
`
`TABLE 2
`
`O1OO7B45
`O1OO7B4A
`O1OO7B4B
`O1OO7B4D
`O1OO7B4E
`O1OO7B4F
`O1OO7BS2
`:01.007B57
`O1OO7BSA
`:01.007B5F
`O1OO7B62
`O1OO7B64
`
`E8XXXX XXXX call XX XXXX XX
`56
`push esi
`33F6
`Xor esi, esi
`57
`push edi
`56
`push esi
`8975FC
`mov dword ptrebp-04), esi
`E806F8FFFF
`cal O10073SD
`8975FC
`mov dword ptrebp-04), esi
`E853F8FFFF
`cal O1 OO73B2
`894SFC
`mov dword ptrebp-04), eax
`FF30
`push dword ptreax
`E8EOF7FFFF
`call 01007349
`
`Consideration of Table 1 alongside Table 2 shows that the
`call instruction inserted as the first line of Table 2 does not
`appear extraordinary in any way. Thus, identifying calls to
`the security functions in order to disable those security
`functions becomes a task of such enormous complexity as to
`be unlikely to be achievable in practice. For example, even
`if a potential hacker realised that security functions had been
`embedded within the software, it would be necessary to
`work methodically through every call instruction within the
`software, in order to identify which, if any, were calling the
`security functions, in order to disable them. A machine code
`listing of a complex modern Software application will
`include a very large number of call instructions.
`It will be apparent from the above description that Table
`2 illustrates the intermediate stage at which the call instruc
`tion (C in FIG. 4B) has been inserted, but the following
`section of code has not been encrypted.
`It can also be understood that a few lines of legitimate
`code are over-written by the new call instruction These lines
`can be recorded within the security function, to be recreated
`when the security function runs, or alternatively, call instruc
`tions to a particular security function can be used only in
`place of particular target lines of code, so that on each
`occasion a particular security function is called, the same
`code will be required to replace the call instruction.
`It will also be apparent that a call instruction should not
`be written over a block of code to which a call might
`legitimately made from elsewhere within the software,
`which would have the effect of causing the software to fail.
`
`7
`within process PROC 2 and containing only Zeros, thus
`apparently being dataless. Smaller areas containing Zeros are
`evident within process PROC 3. In a real example, many
`more apparently dataless areas are likely to be located.
`Once all of these dataless areas have been identified, the
`engine 30B can then analyse them to determine which are
`indeed dataless and which only appear so. For example, the
`engine 30B may disassemble the whole of the software, and
`assess the disassembled listing, looking for any instructions
`which call those areas identified as apparently dataless, or
`any instructions which jump to those areas, or instructions
`which read or write to these areas. If any such instructions
`identify those areas, it is likely that the corresponding area
`is to be used by the software, for instance as a scratch pad.
`The area is therefore removed from the list of apparently
`dataless areas, because the area will be used for data, at least
`intermittently, during execution of the software.
`Once each of the apparently dataless areas has been
`checked in this manner, the engine 30B can begin to make
`use of the dataless areas. In this example, it is assumed the
`two areas within process PROC 3 are found to have call or
`jump instructions identifying them and are thus removed
`from the list of dataless areas, whereas the area within
`process PROC 2 remains on the list.
`The dataless area within process PROC 2 is then filled by
`the engine 30B inserting one or more of the functions of the
`block 38, which may be security checks or the like, and by
`executable code representing a decryption algorithm. This
`filling, beginning at line 1,300, is illustrated in FIG. 4B by
`shading.
`In order to make use of the block of code now created at
`line 1,300, the engine 30B then modifies blocks of data
`elsewhere within the software, such as at line 800 within
`process 1. The contents of the section beginning at line 800
`are read by the engine 30B. This includes an encryption
`algorithm which is used to encrypt the original contents of
`the area. The encrypted version is th