throbber
Case 1:20-cv-03810-VEC Document 1-1 Filed 05/15/20 Page 1 of 21
`
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket