‘V0 93" 159°
`
`PC!‘/US97/16223
`
`- 23 .
`
`00011
`
`83 c4 04
`
`add
`
`esp, 4
`
`00014 p
`
`8b f0
`
`mov
`
`esi, eax
`
`; Line 25
`
`00016
`
`8b 44 24 0c mov
`
`eax, DWORD PTR_b$[esp]
`
`5
`
`' 0001a
`
`50
`
`'
`
`push
`
`eax
`
`0001b
`
`e8 00 00 00 00 call
`
`_TestSquare
`
`00020
`
`00023
`
`; Line 28
`
`83 c4 04
`
`03 c6
`
`add
`
`add
`
`esp, 4
`
`eax, esi
`
`I0
`
`00025
`
`00026
`
`5e
`
`c3
`
`pop
`
`esi
`
`ret
`
`0
`
`_TestSum ENDP
`
`_TEXT
`
`ENDS
`
`;
`
`COMDAT_TestSqua.re .
`
`15
`
`_TEXT
`
`SEGMENT
`
`_x$ = 8
`
`_TestSquare PROC NEAR
`
`; Line 30 V
`00000
`
`20
`
`; Line 32
`
`0000]
`
`00005
`
`; Line 34
`
`56
`
`'
`
`push
`
`esi
`
`8b 74 24 08 mov
`
`esi, DWORD PTR _x$[esp]
`
`0f a.f f6
`
`imul
`
`esi, esi
`
`00008
`
`‘
`
`56
`
`push
`
`esi
`
`_ 25
`
`00009
`
`ff 15 00 O0 00
`
`00
`
`call
`
`DWORD PTR _lpCallBackFunc2
`
`0000f 83 c4 04
`
`add
`
`esp, 4
`
`00012
`
`Sb c6
`
`mov
`
`eax, esi
`
`;Line 36
`
`30
`
`00014
`
`00015
`
`5e
`
`c3
`
`_TestSquare ENDP
`
`pop
`
`esi
`
`ret
`
`0
`
`; COMDAT
`
`BNSDOCID: <WO_981169oA1_IA>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1001
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1001
`
`

`
`W0 93/11590
`
`PCT/US97/l6223
`
`- 24 -,
`
`Such information also is available from .map output files from the linker where the "f" between
`
`the address (i.e., 0a406100) and the object file (i.e. Algorithms.obj) means it is a "flat" address
`(i.e., hard coded by the linker) and the lack of "f" means that it is an address pointer to be
`
`supplied at run time (load time) where the address that is contained in that address location is
`
`5
`
`used and not the actual address location (i.e., the address that is contained at address location
`
`0a406100 and not 0a406100 itself):
`
`0001200000000
`
`_TestSum
`
`0a40l000 f Algorithmsobj.
`
`0001100000030
`
`_TestSquare
`
`l0
`
`0a40l03O f Algorithmsobj
`V
`
`0003:0000] 100
`
`__lpCallBackFunc2
`
`0a406100 Algorithms.obj
`
`0003:0000] 104
`
`__lpCallBackFuncl
`
`0a406]04 Algorithms.obj
`
`When the code inside the .dll makes a "call" to a dereferenced pointer, it would jump to the
`
`15
`
`correct function in the outer code and return the expected return value (if any). For example:
`
`void CallBackFunctionl (){
`
`// This is the first function that exists in the Stub executable
`
`// whose address has been placed at the appropriate location inside the "dll" code
`// that has now been decrypted in a block of memory. The code inside the "dll"
`
`20
`
`// makes a function call to this function. In its encrypted state, the "dll" does not contain
`
`// this address, but merely has a placeholder for the address. The “dll” has enough space
`
`allocated to hold an
`
`.
`
`// address of this size. After the “dll” has been decrypted at run time, its address is
`
`v 25
`
`// placed in that location so the code inside the "dll"'that references (or more
`// appropriately dereferences) that address can jump (which is function call) to this
`
`// address.
`
`AfxMessageBox(
`
`_T("This is the FIRST Stub.exe call back function being called from the dll."));
`
`30
`
`_
`
`return;
`
`BNSDXIDI <WO_9811690A1_lA>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1002
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1002
`
`

`
`.
`
`-J
`
`“'0 98" *5”
`
`PCT/US97/16223
`
`- 25 -
`
`void CallBackFunction2(DWORD nNumber){
`
`// See comment for CallBackFunction1 except this function receives a parameter off
`
`// of the stack.
`
`It could also return a value as well.
`
`CString
`
`5
`
`cString(
`
`T("This is the SECOND Stub.exe call back function being called from the dll"));
`
`har buffer[20];
`
`ltoa(nNumber, buffer, 10);
`
`l0
`
`cString += _T(" with a parameter of ");
`
`cString += buffer;
`
`cString += _T(".");
`
`AfxMessageBox(cString.GetBuffer(0));
`
`l 5
`
`return;
`
`The outer stub.exe would make the same kinds ofjumps or function calls into the now protected
`
`decrypted code block as follows:
`
`20
`
`DWORD c;
`
`// This command declares a function pointer. This command is different for difierent function
`
`// calls. Here the called function takes two integer parameters and
`
`25
`
`// passes back a DWORD.
`
`DWORD (*lpFunc)(DWORD,DWORD);
`
`// The function pointer is then pointed to the starting address of the function in the
`
`// block of memory that now holds the decrypted DLL.
`
`30
`
`lpFunc = (DWORD ("‘)(DWORD,DWORD)) UnwrapFixUpAndRelocateDll();
`
`// Now call that "function" which is really like all function calls, i.e., ajump to
`
`ansoocio: <wo_ee11s9oAi_iA>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1003
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1003
`
`

`
`W0 93/1159”
`
`PCT/US97/16223
`
`- 25 -
`
`// the address where that function exists.
`
`In this case, two
`
`// variables are passed to that function and returning a value from that function. This function
`
`illustrates that the function call
`
`// can be more complicated than merely a simple jump
`
`// to an address. Inline assembler code may be used to push the variables onto ‘
`
`// the stack frame and return the variable from the eax register, but this function enables
`
`// the C++ compiler to do the same function.
`
`c = (DWORD) (*lpFunc)(a, b);
`
`l0
`
`l5
`
`20
`
`25
`
`30
`
`This mechanism requiresthe unwrap procedure and the now decrypted code to have intimate
`
`knowledge about procedural interfaces of each other but no knowledge about each other's
`
`implementation. This is the way most executable .exe files and .dll files behave but with the
`
`addition of a series of "wrapper" functions on either side for communication. This method works
`
`under Windows 95 and Windows NT 4.0 operating systems and should work under Windows NT
`
`5
`3.51 and other operating systems. '
`Another modified version of this mechanism that works under the Windows NT 4.0
`
`operating system because of functions specific to Windows NT 4.0 would be to have another
`hidden and/or encrypted executable within the digital information product. This executable
`
`would be copied to a physical disk in an unencrypted form, launched or loaded with the
`
`CreateProcess() command in its current form but called with a parameter to load the executable
`
`in suspended mode:
`
`BOOL success = CreateProcess(cFrontEndExe.GetBuffer(O), 0, 0, 0, TRUE,
`
`CREATE_NEW_CONSOI_.El CREATE_SUSPENDED,
`
`0, 0, &startUpInfo, &processInfo);
`
`Then the first process would copy the encrypted dll into its own process and decrypt it, allocate
`
`enough memory using VirtualAllocEx() in its current form in the second process that has just
`
`loaded the expendable front end executable in a suspended state as follows:
`
`LPVOID lpvBlockEx = VirtualAllocEx(processInfo.hProcess,
`
`BNSDCXZID: <WO_9811690A1_|A>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1004
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1004
`
`

`
`*4.
`
`W0 98/1159“
`
`PCT/US97/16223
`
`- 27 -
`
`(LPVOID) nPreferredLoadAddress, nPhantomFileSize,
`
`MEM_RESERVE | MEM_COMMIT,
`
`PAGE_READWRITE);
`
`The decrypted code is copied from the first process to the second suspended process using
`
`WriteProcessMemory() in its current form:
`
`BOOL bWriteProcessMemory = WriteProcessMemory((l-IANDLE) processlnfo.hProcess,
`
`(LPVOID) lpvBlockEx, (LPVOID) nPreferTedAddress,
`
`(DWORD) nPhantomFileSize, (LPDWORD) &nBytesWritten);
`
`The primary thread of the previously launched second process is then resumed:
`
`DWORD nRcsumed = ResumeThread(processlnfo.hThread);
`
`15
`
`Any necessary function pointers are then placed in the correct locations by the second process,
`
`the area of memory is locked to prevent any writes to a swap file, and the memory protection is
`
`changed to execute only as follows:
`
`20
`
`WriteAddress((char*) 0x0a406lO4, (DWORD) &CallBackFunction1);
`
`WriteAddress((char*) 0x0a406l00, (DWORD) &Cal1BackFunction2);
`
`BOOL bVLock = VirtualLock((LPVOID) nPreferredLoadAddress, nPhantomFileSize);
`
`DWORD lpflOldProtect; // variable to get old protection
`
`25
`
`BOOL bVProtect = \«'irtualProtect((LPVOID) nPreferredLoadAddress,
`
`nPhantomFi1eSize,PAGE_EXECUTE, &lpflOldProteet);
`
`The program can continue running by making and receiving calls to and from the decrypted
`
`dynamic link library that now resides in the protected memory of its process using commands
`
`30
`
`such as the following:
`
`DWORD c;
`
`ansoocio: <wo_9at 169OAl_lA>
`
`Petitioner Apple‘ Inc. — Exhibit 10243 p. 1005
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1005
`
`

`
`W0 93/11590
`
`PCT/US97/16223
`
`-23-
`
`DWORD (*lpFunc)(DWORD,DWOi{D);
`
`lpFunc = (DWORD (*)(DWORD,DWORD)) ExpendableGetEntryAddress();
`
`c = (DWORD) (*.lpFunc)(a, b);
`
`The first process can either close down or launch another instance of that same process.
`
`In either of these implementations using the same process or launching into a second
`
`process, the hiddeniencrypted code never passes through a file system driver or memory resident
`
`program in decrypted form. Code can be split up among different dynamic link libraries so that
`
`no two would reside in memory at the sa.me time in order to protect code further. Both of these
`
`systems can be implemented using the Win32 function calls. If additional functions, similar to a
`
`CreateProcess() command or a LoadLibrary() command but that take a process identifier and
`
`address location in memory to load in an executable instead of a physical file, are provided in an
`
`operating system then the entire executable and dynamic link library can be hidden, encrypted,
`
`and protected on the physical disk and then decrypted within protected memory and use the
`
`operating system loader to load it directly to the operating system from memory without residing
`
`in decrypted form on any physical medium.
`
`Having described the operation and use of the computer program product in accordance
`
`with the invention, embodiments of which are described above in connection with Figs. 3-8, and
`
`the operation of the unwrap procedure and device driver it contains, the process of constructing
`
`such -a computer program product will now be described in more detail. Referring now to Fig. 9,
`
`an embodiment of this process for creating a computer program product is shown. This process
`
`can be applied to any digital information including an arbitrary executable computer program,
`
`dynamic link libraries and related files of data. All digital information is treated as mere data by
`
`this process. Each separate data file is combined into a single file by this process, with an
`
`executable program for performing the unwrap procedure,’ and optionally executable program
`
`code for a virtual device driver, into the computer program product. Each file of hidden
`
`information has a unique location and is identified by its own begin and end markers as shown in
`
`Fig. 3. The first step of this process is opening a new data file for the computer program using a '
`
`name that will be used to indicate an executable file (step 200). For example, an executable
`
`word processing program may be named “word_processor.exe” in the Windows95 operating
`
`l0
`
`15
`
`20
`
`25
`
`30
`
`system.
`
`BNSDOCID: <wo,9ai 169OA1_lA>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1006
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1006
`
`

`
`wo 93/1 1590
`
`PC!‘/US97/16223
`
`- 29 -
`
`The three portions of the computer program product are then inserted into the open data
`
`file. First. the unwrap procedure is inserted at the beginning of the file in an executable format in
`
`step 202. The begin tag for the optional device driver is then inserted in step 204. The
`
`executable device driver program code is then inserted in step 206, followed by its corresponding
`
`end tag in step 208. For each hidden file to be inserted into this computer program product, steps
`210 to 216 are performed. First, the begin tag is inserted in step 210. The begin tag also may
`include an indication of a unique name of the file which will be used as its name in the phantom
`
`directory created by the unwrap procedure. The hidden file is then encrypted and/or compressed
`in step 212 and inserted into the data file in step 214. The end tag for the hidden file is then
`
`10
`
`inserted in step 216. The device driver and all of the tags may be encrypted also if the unwrap
`procedure has suitable decryption procedures. The computer program file is closed when the last
`
`A
`
`hidden file is processed.
`
`Using the present invention digital information, such as executable program code or
`
`various kinds of data, is loaded and unloaded as needed, and thus does not take up any more
`
`15
`
`memory than is necessary. At no time does unencrypted digital information, such as computer
`
`program code, exist on disk in accessible and complete decrypted form. Because the original
`
`digital information is available as a read only file in one embodiment of the invention accessible
`
`only to the device driver, the digital information may be accessed over networks, from a CD-
`
`ROM or from a DVD, and can be made to have a limited number of uses. This mechanism is
`
`particularly useful for controlling distribution of computer programs, digitized movies or other
`
`information while reducing the cost of such distribution and control. For example, software may
`
`be distributed over a network on a single use basis, and charges may be levied on a per use basis.
`
`The ability to reverse engineer an application program also may be reduced.
`One benefit with this system over some other systems for preventing unauthorized access
`
`to digital information is that the content provider maintains control of the encryption applied to
`
`the information how it may be decrypted. Any need for either a centralized facility or a
`
`predetermined decryption program is eliminated. ‘An operating systems manufacturer or other
`
`platform vendor merely provides the capability for the information to be accessed and decrypted
`
`20
`
`25
`
`on the fly. Since the valuable information and any other tables of authorization codes,
`
`30
`
`passwords, or hardware identifiers that the content provider may use to secure the information
`
`resides in one large encrypted file, it becomes difficult, if not impossible, for someone to
`
`determine just where any of this information exists.
`
`BVSDCXZID: <WO_B81l690A1_|A>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 10074
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1007
`
`

`
`W0 98/116941
`
`- 30 -
`
`‘
`
`'
`
`PCI‘/US97/16223
`
`‘
`
`' ,
`"5
`
`A potential scenario with authorization procedure in which the present invention may be
`used is the following. A consumer purchases a DVD disk containing a movie. The user puts the
`
`disk into the player. This is the first time the disk is installed. The content provider’s functions
`
`are loaded into the DVD chip, which looks in the encrypted table and sees that this is the first
`
`time this disk is being played. The player then displays on a screen a numeric identifier and toll
`
`free phone number. The consumer calls the toll free phone number and inputs the numeric
`identifier that was displayed on the screen. The content provider provides a numeric password
`
`based on the numeric identifier that the user inputs into the DVD. The content provider may
`
`develop a database of information about its consumers that also may be used to detect pirating of
`the digital information product. Now that thislauthorization has taken place, the software that the
`
`l0
`
`content provider wrote, and is now in the DVD chip, takes a hardware identifier from the DVD
`and encrypts it and puts it in the encrypted and buried table on the disk. Alteratively, the data
`
`may be decrypted in memory and re-encrypted back onto the disk using the hardware identifier
`
`as part of a key. Now that disk will run and show the movie and will only run on that DVD and
`
`no other. The content provider could allow for a table of hardware id’s so they could limit the
`
`number of DVD‘s that disk would run on or a limited number of times it can be shown. It should
`
`be understood that many other authorization procedures may be used.
`
`In the foregoing scenario, the movie is encrypted on the same disk inside of the encrypted
`
`filethat contains the table and functions the content provider distributed. The movie is decrypted
`
`by the decryption functions contained in the file directly to the DVD chip. At no time does the
`
`movie reside anywhere in decrypted form. _The content provider can protect the movie with any
`
`15
`
`20
`
`desired level of security (for both encryption and authorization).
`
`In the present invention, the onus of protection of content does not reside with a hardware
`
`manufacturer or platform provider but in the hands of the content provider. The hardware
`
`>25
`
`manufacturer only provides the mechanism to protect the digital information through the
`
`operating system. The technique and implementation of protection resides in the hands of the
`
`content provider. This mechanism allows the content providers to change the level of security as
`
`i needed without any modifications to the hardware. The security of the content is provided by the
`
`encryption/decryption algorithms, public/private keys, and authorization methods which are
`
`30
`
`determined by the content provider. Even each individual product can have its own
`
`encryption/decryption algorithms and/or public/private keys. All of these can be changed and
`
`enhanced as the market demands.
`
`BNSDOCID: <wo_9e1169oA1_tA>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1008
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1008
`
`

`
`ll
`
`wo 98/11690
`
`PC-r,Us9-,,,5n3
`
`- 31 -
`
`The present invention also could be used for on-line or live use of digital information.
`
`For example, a movie could be retrieved on demand and recorded by a consumer. A set top box
`could receive the digital information, decrypt it, and then re-encrypt and store the information
`
`using, for example, a hardware identifier of the set top box. Since home movies digitally
`
`recorded would be encrypted using the hardware identifier of the device used in recording, that
`
`home movie could not be played on another or only on a limited number of other devices and/or
`
`for only a specified number of times depending on the wishes of the content provider. Since the
`
`algorithms are downloaded at the time of recording from a service provider, e.g., the cable
`
`l0_
`
`company, the content provider (movie company) would provide the encrypted data to the service
`provider to present to their customers. The service provider need not be concerned with the
`encryption/decryption and authorization functions used by the content provider. Similar uses are
`possible with other data transmission systems including, but not limited to. telephone, cellular
`communications, audio transmission including communication and the like.
`
`In another embodiment, the stub executable program is a first process that is implemented
`
`l5
`
`similar to a debugging tool such as the Softlce debugger from NuMega Technologies or the
`
`WinDebug debugger from Microsoft Corporation for Ring 0 kemel level debugging for an Intel
`processor based architecture, or the CodeView debugger for ring 3 application level debugging.
`Such a debugger controls execution of a program to be debugged as a second process and steps
`
`through each program statement or opcode of the debugged program. The debugging tool could
`
`be modified to monitor each opcode that indicates a jump to a program fragment, such as each
`instruction or a block code. If the program fragment to be executed is not decrypted, the
`
`modified debugger decrypts the program fragment before the jump command is allowed to
`
`execute. Each program fragment may be re-encrypted after execution. Clearly, unnecessary
`
`debugging commands may be omitted from the modified debugger.
`
`Having now described a few embodiments of the invention, it should be apparent to those
`
`skilled in the art that the foregoing is merely illustrative and not limiting, having been presented
`
`by way of example only. Numerous modifications and other embodiments are within the scope
`
`of one of ordinary skill in the art and are contemplated as falling within the scope of the
`
`20
`
`25
`
`invention as defined by the appended claims and equivalent thereto.
`
`ausooclo: <wo_9ai ie9oAi_m>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1009
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1009
`
`

`
`W0 93/11590
`
`PCT/U'S97/16223
`
`- 32 -
`
`CLAIMS
`
`1.
`
`A computer-implemented process for executing encrypted computer program logic while
`
`maintaining protection against copying of corresponding decrypted executable computer
`
`program logic, wherein the encrypted computer program logic is stored in association with first
`
`5 . executable computer program logic, the process comprising the steps of:
`
`through an operating system of a computer, reading, loading and executing the first
`
`executable computer program logic as a first process having a protected memory area defined by
`
`the operating system;
`
`the first process decrypting the encrypted computer program logic into second executable
`
`10
`
`computer program logic and storing the second executable computer program logic in the
`
`protected memory area; and
`
`the first process causing loading and execution of the decrypted second computer
`
`program logic in the protected memory area.
`
`15
`
`2.
`
`The process of claim 1, wherein the encrypted computer program logic and the first
`
`executable computer program logic are stored in a single data file accessible through the
`
`operating system.
`
`3.
`
`The process of claim 1, wherein the execution of the decrypted second computer program
`
`20
`
`logic is performed as a second process having a second protected memory area defined by the
`
`operating system.
`
`4.
`
`A digital information product including a computer readable. medium having digital
`
`information stored thereon, the digital information including computer program logic defining
`
`_ 25
`
`first executable computer program logic, wherein the first executable computer program logic
`when executed performs the following steps:
`
`storing the encrypted computer program logic in a data file accessible through an
`
`operating system of a computer, wherein the data file also includes first -executable computer
`program logic;
`I
`
`30
`
`through the operating system, reading, loading and executing the first executable
`
`computer program logic from the data file as a first process having a protected memory area;
`
`BNSDXID: <WO_981l69OA1_lA>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1010
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1010
`
`

`
`W0 93/1159”
`
`PCT/US97ll6223
`
`- 33 -
`
`the first process decrypting the encrypted computer program logic into second executable
`
`computer program logic and storing the second executable computer program logic in the
`
`protected memory area; and
`
`the first process causing loading and execution of the decrypted second computer
`
`program logic in the protected..memory area.
`
`5.
`
`A computer system comprising:
`
`a processor for executing computer program logic;
`
`a main memory operatively connected to the processor for storing digital information
`
`l0
`
`including executable computer program logic at memory locations addressed by the processor;
`
`and
`
`an operating system defined by executable computer program logic stored in the memory
`
`and’ executed by the processor and having a command which when executed by the processor
`
`defines means for creating a- process in response to a request specifying a process identifier and a
`
`I5
`
`memory location in the main memory, wherein the process identifier indicates the process
`
`.
`
`.:.I
`
`making the request and the memory location stores executable computer program logic which
`
`when executed defines the process.
`
`6.
`
`A computer system having an operating system, for decrypting digital information,
`
`comprising:
`
`means for storing the encrypted computer program logic in a data file accessible through
`
`the operating system, wherein the data file also includes first executable computer program logic;
`
`means, invokable through the operating system, for reading, loading and executing the
`
`first executable computer program logic from the data file as a first process having a protected
`
`memory area;
`
`the first process defining means for decrypting the encrypted computer program logic
`
`into second executable computer program logic and storing the second executable computer
`
`program logic in the protected memory area; and
`
`the first process defining means for causing loading and execution of the decrypted
`
`30
`
`second computer program logic in the protected memory area.
`
`BNSf3lD: <WO_981I690A1_lA>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1011
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1011
`
`

`
`W0 98/11690
`
`PCTIUS97/16223
`
`- 34 -
`
`7.
`
`The computer system of claim 6, wherein the encrypted computer program logic and the
`
`first executable computer program logic are stored in a single data file accessible through the
`
`operating system.
`
`8.
`
`The computer system of claim 6, wherein the execution of the decrypted second computer
`
`program logic is perfonned as a second process having a second protected memory area defined
`
`by the operating system.
`
`9. A digital information product, including a computer readable medium with computer readable
`
`IO
`
`information stored thereon, wherein the computer readable infomiation comprises:
`
`a first portion of executable computer program logic; and
`
`a second portion of encrypted digital information; and
`
`wherein the first portion of executable program logic, when executed, defines means,
`
`operative in response to requests for digital infonnation, for accessing the second portion of
`encrypted digital infonnation, for decrypting the encrypted digital information, and for
`
`I5
`
`outputting the decrypted digital information.
`
`10.
`
`The digital information product of claim 9, wherein the encrypted digital information is
`
`encrypted executable computer program logic.
`
`20
`
`1 1.
`
`A computer program product including a self-decrypting encrypted executable computer
`
`program, comprising:
`
`a computer readable medium having computer program logic stored thereon, wherein the
`
`computer program logic defines:
`
`.25
`
`a first module,
`
`a second module,
`wherein the first module, when executed by a computer, definesimeans for loading the
`
`second module into memory of the computer, and
`
`a third module defining the encrypted executable computer program,
`
`30
`
`wherein the second module, when executed by a computer, defines means for
`
`«communicating with an operating system of the computer to receive requests for program code
`
`from the encrypted executable computer program from the third module, and for processing the
`
`BNSDXIDJ <W0__9811690A1_lA>
`
`.
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1012
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1012
`
`

`
`wo 98/11690
`
`PC!‘/US97/16223
`
`- 35 -
`
`requests to access and decrypt the encrypted executable computer program and for providing the
`
`decrypted executable code from the third module to the operating system.
`
`12.
`
`A process for executing encrypted executable computer programs on a computer system
`
`5
`
`having a processor, memory and operating system, comprising the steps of:
`
`receiving computer program logic having a first module defining a start up routine, a
`
`second module, and a third module containing the encrypted executable computer program;
`
`executing the first module of the received computer program logic using the processor,
`
`wherein the step of executing causes the second module to be loaded into the memory of
`
`lo
`
`the computer system, and
`
`generating requests from the operating system for data from the encrypted executable
`
`computer program which are received by the second module, and
`
`accessing and decrypting the encrypted executable computer program and returning the
`
`decrypted executable computer program to the operating system.
`
`15
`
`Ewsoocioz <wo__9a1 1690A I_IA>
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1013
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1013
`
`

`
`WO 98/11690
`
`PC!‘/US97/16223
`
`1 /8
`
`PROCESSOR
`
`
`
`22
`
`26
`
`so
`
`28
`
`INPUT DEVICE
`
`OUTPUT DEVICE
`
`20
`
`
`
`INTERCONNECTION MECHANISM
`
`
`
`
`MEMORY
`
`24
`
`Fig. 1
`
`40
`
`42
`
` 44
`10101100
`
`10101100
`
`INTEGRATED CIRCUIT
`MEMORY
`
`
`
`TO PROCESSOR 22
`
`Fig. 2
`
`BNSIXXJID: <WO_9811690A1_lA>
`
`SUBSTITUTE SHEET (RULE 26)
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1014
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1014
`
`

`
`W0 98/1 1690
`
`PCT/US97I16223
`
`2/8
`
`
`
`UNWRAP
`PROCEDURE
`
`50
`
`
`
`
`
`BEGIN DRIVER
`
`DRIVER
`APPLICATION
`
`END DRIVER
`
`BEGIN APP
`
`56
`
`52
`
`58
`
`60
`
`54
`
`
`
`ENCRYPTED
`AND/OR
`
`COMPRESSED '
`
`
`
`DATA FILEISI
`
`
`
`
`
`
`
`62
`
`Fig. 3
`
`BNSDXID: <WO__9811S90Al_|A>
`
`SUBSTITUTE SHEET (RULE 26)
`
`I Petitioner Apple Inc. — Exhibit 1024, p. 1015
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1015
`
`

`
`WO 98111690
`
`PCT/US97/16223
`
`3/8
`
`
`
`LOAD COMPUTER PROGRAM
`INTO MEMORY AND BEGIN
`EXECUTING UNWRAP PROCEDURE
`
`PERFORM AUTHORIZATION
`
`IDENTIFY LOCATION OF DRNER
`
`70
`
`72
`
`74
`
`IDENTIFY LOCATION OF HIDDEN APPLICATIONISI
`
`76
`
`EXTRACT DRNER AND COPY IT INTO
`MEMORY AND LOAD IT INTO
`
`" OPERATING SYSTEM
`
`DIRECTORY AND FILE
`
`INFORM DRNER OF LOCATION OF
`
`HIDDEN APPLICATION, ANY KEYS OR
`
`PASSWORDS AND NAME OF PHANTOM
`
`LOADED DRIVER OPENS ORIGINAL COMPUTER
`PROGRAM FILE FOR READ ONLY ACCESS
`
`32
`
`UNWRAP PROCEDURE MAKES CALL TO OPERATING
`
`SYSTEM TO EXECUTE FILE IN THE PHANTOM DIRECTORY
`
`TRAP ALL CALLS FROM OPERATING sYsTEM AND
`PROCESS THOSE MADE TO PHANTOM DIRECTORY
`
`DRNER ACCESSES REQUESTED BYTES FROM ORIGINAL
`COMPUTER PROGRAM FILE
`
`RETRIEVED BYTES OF DATA ARE DECRYPTED/DECOMPRESSED
`AND RETURNED TO REQUESTER
`
`F] g 4
`
`'
`DRIVER (AND UNWRAPPERI MAY UNLOAD WHEN DONE
`
`84
`
`35
`
`88
`
`90
`
`92
`
`BNSDOCIO: <wo_9e1 1690A1_lA>
`
`SUBSTITUTE SHEET (RULE 26)
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1016
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1016
`
`

`
`wo 93/1 1690
`
`PC'l‘IUS9‘IIl6z23
`
`4/8
`
`IDENTIFY
`
`OPERATING
`SYSTEM
`
`100
`
`
`
`
`SEARCH FOR BEGIN
`AND END TAGS
`OF DEVICE DRNER
`AND HIDDEN FILES
`
`
`
`
`
`102
`
`
`
`
`
`STRIP OUT DEVICE
`DRNER AND LOAD IT
`INTO THE OPERATING
`SYSTEM
`
`
`
`
`
`INFORM DEVICE DRIVER
`OF NAME OF FILES AND
`OFFSETS OF HIDDEN I
`FILES AND NAME
`OF PHANTOM DIRECTORY
`
`108
`
`
`
`MAKE CALL TO OPERATING
`SYSTEM TO EXECUTE HIDDEN
`FILE IN PHANTOM DIRECTORY
`
`
`
`
`Fig. 5
`
`eusooclo; <WO__9811690A1_lA>
`
`SUBSTITUTE SHEET (RULE 25)
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1017
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1017
`
`

`
`W0 98/] 1690
`
`PCT/US97/16223
`
`5/8
`
`HOOK INTO POSITION
`BETWEEN OPERATING
`SYSTEM AND FILE
`
`
`
`SYSTEM DRIVER IFSDI
`
`110
`
`
`
`
`
`
`
`TRAP CALLS TO PHANTOM
`DIRECTORY BY OPERATING SYSTEM
`
`116
`
`
`
`DECRYPT/DECOMPRESS REQUESTED
`DATA FROM ORIGINAL FILE
`AND PASS DATA TO-OPERATING SYSTEM
`
`
`
`Fig. 6 ‘
`
`BNSDXID: <W0_981169_0A1_IA>
`
`SUBSTITUTE SHEET (RULE 26)
`
`Petitiontn‘ Apple Inc. — Exhibit 1024, p. 1018
`
`112
`
`
`
`
`
`RECEIVE. INFORMATION FROM
`UNWRAP PROCEDURE INCLUDING
`NAME OF ORIGINAL FILE AND
`LOCATION OF HIDDEN FILES
`AND PHANTOM DIRECTORY
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1018
`
`

`
`W0 98/1 1690
`
`PCl'IUS9‘7/1 6223
`
`6/8
`
`OPERATING
`
`SYSTEM
`
`
`
`
`
`
`DECRYPTED CODE
`
`130\
`
`CALLS TO
`PHANTOM
`INSTRUCTION
`
`
`To RUN
`D'RECTS’3R‘:
`"PHANTOM / HIDDEN"
`
`
`
`ORIGINAL
`FILE NAME
`UNWRAP
`PROCEDURE
`
`
`
`’
`
`OFFSETS AND
`PHANTOM
`
`DIRECTORY
`
`
`
`
`
`
`128
`
`
`
`ENCRYPTED
`
`
`
`
`
`UNWRAP
`
`PROCEDURE
`
`DEVICE
`
`DRIVER
`
` COMPUTER PROGRAM FILE
`
`HIDDEN
`
`APPLICATION
`
`126
`
`BNSDOCID: <wo_9e1 1690A1_lA>
`
`SUBSTITUTE SHEET (RULE 26)
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1019
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1019
`
`

`
`wo 93/11590
`
`PCI‘IUS97I16223
`
`7/8
`
`ALLOCATE PROTECTEO MEMORY
`
`
`
`
`
`
`
`-
`
`
`
`
`
`
`
`LOCK ALLOCATED MEMORY
`TO PREVENT SWAPPING
`
`
`
`LOAD ENCRYPTED PORTION
`INTO ALLOCATED MEMORY
`
`DECRYPT ENCRYPTED PORTION
`INTO ALLOCATED MEMORY
`
`
`
`FIX UP DECRYPTED CODE
`
`CHANGE MEMORY
`
`PROTECTION TO EXECUTE ONLY
`
`
`
`
`
`
`
`155
`
`158
`
`160
`
`Fig. 8
`
`BNSDOCID: <wo_9a11s9oA1_|A>
`
`SUBSTITUTE SHEET (RULE 26)
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1020
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1020
`
`

`
`W0 98/1 I 690
`
`PCI'IUS97Il 6223
`
`8/8
`
`OPEN NEW DATA FILE
`
`
`
`WITH NAME THAT WILL
`BE USED TO INDICATE
`AN EXECUTABLE FILE
`
`200
`
`INSERT UNWRAP PROCEDURE
`-
`IN EXECUTABLE FORM
`
`202
`
`INSERT BEGIN TAG FOR
`DEVICE DRIVER
`
`204
`
`INSERT EXECUTABLE DEVICE DRIVER
`
`206
`
`INSERT END TAG
`DEVICE DRIVER
`
`208
`
`INSERT BEGIN TAG FOR
`HIDDEN FILE
`
`210
`
`ENCRYPT HIDDEN FILE
`
`212
`
`INSERT ENCRYPTED FILE
`
`214
`
`INSERT END TAG FOR
`HIDDEN FILE AND CLOSE FILE
`
`215
`
`Fig. 9
`
`BNSDOCID: <wO_98n69oA1_IA>
`
`SUBSTITUTE SHEET (RULE 26)
`
`Petitioner Apple Inc. — Exhibit 1024, p. 1021
`
`Petitioner Apple Inc. - Exhibit 1024, p. 1021
`
`

`
`INTERNATIONAL SEARCH REPORT
`
`lntemational application No.
`PCT/US97/l6223
`
`CLASSIFICATION OF SUBJECT MATTER
`A.
`lPC(6)
`:H04L 9/00
`US CL
`: 380/4
`According to lnternational Patent Classification (IPC) or to both national classification and IPC
`B.
`FIELDS SEARCHED
`
`Minimum documentation searched (classification system followed by classification symbols)
`U.S.
`:
`380/4,9,23,25.49,S0,S9
`
`‘
`
`4
`
`Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched
`
`Electronic data base consulted during the international search (name of data base and. where practicable. search terms used)
`
`C.
`
`DOCUMENTS CONSIDERED TO BE RELEVANT
`
`‘
`
`Citation of document. with indication. where appropriate. of the relevant passages
`
`US 4,937,861 A (CUMMINS) 26 June 1990. see Abstract.
`
`US 5,007,082 A (CUMMINS) 09 April 1991, see Abstract.
`
`US