Patent Grant
7237123
1. Field of the Invention
This invention is related to the field of protecting digital information from being copied, modified, or used by unauthorized parties. In particular this invention is related to systems and methods that prevent unauthorized access to, and modification of, digital data as found on computer systems and consumer-appliance systems that utilize Compact Disc (CD), DVD, or other removable media (such as Flash Memory on standard or proprietary cards or sticks, or other non-volatile memory) technologies, or any storage media of any type, or any such content delivered via any network connection of any type.
2. Description of the Related Art
The electronic publishing industry for application software, computer games, appliance-console games, movies, and music, is facing a growing and serious problem; namely, the piracy and unauthorized modification and use of their content. Since digital content is by nature capable of being copied exactly, wherein a copy is identical in every way to the original, and since the tools to do so are increasingly available, the industry is facing increasing losses. Such losses may include the unauthorized copying of a CD containing a game, or the unauthorized reverse engineering and modification of a word processing program to allow for its illegal distribution, or the reverse engineering of a copy protection scheme to disable it, making it possible to make duplicates with ease.
There are many mechanisms available that may be used to limit or prevent unauthorized access to digital content. Following deployment, such mechanisms are often times subsequently compromised by hackers, and the methods and techniques used to compromise them have been widely disseminated and actively used and enhanced. Most protections are simplistic in nature, and depend to large degree on the secrecy of the simple method as much as its inherent security or ingenuity, such that if not defeated prior to publication, the act of publishing them, for example in patent form, reveals enough about them to render them less effective. More than one of these approaches may be defeated if anticipated by using “ProcDump”, a memory lifting tool that is available free on the World Wide Web (such a tool may also be easily written following technical instructions that may also be found on the web) in conjunction with SoftICE, a powerful debugging tool, which may also be found on the web. A computer system is usually the platform and tool of choice for one intent on reverse engineering or cracking these protection mechanisms; even if the protected content's target was not a computer system such as a PC but rather an appliance computing device such as a game console, the content can best be modified (“hacked”) on a computer. In terms of protecting content from copying or modification by a skilled person with a modern computer system, most inventions in the field (see below) are not protected from being reverse engineered, modified, or content-duplicated by means of commonly available tools such as “SoftICE” (an in-circuit emulator and very powerful debugger), “ProcDump” (can capture any data content from any memory location, regardless of how protected the memory was thought to be), “IDA” (a disassembler), and “FileMon” (a file system monitoring and transcribing service tool). There are no design secrets that can be kept from such a set of tools, and there are many more such tools in existence, and more being created all the time. Therefore it becomes far more important to have well designed mechanisms that do not depend on their secrecy, as much as their design, to ensure security.
Many of these mechanisms depend to a great extent on lack of knowledge about the mechanisms by the persons attempting to modify or copy the content. With even partial knowledge, many of these mechanisms can be defeated by even a moderately technical person with access to the web where all the necessary tools and techniques are available. There is a need for security methods that do not depend solely upon their secrecy or obscurity in order to be effective.
To address the limitations of the conventional approaches described above, the present invention is directed to a digital content security method and system that does not depend solely upon secrecy or obscurity in order to be effective.
In one aspect, the present invention is directed to a system and method for storing encrypted data, subdivided into arbitrarily small collections of bits within other files, or between them, or outside a file system's known storage areas entirely. The data size used in the discussion below is 4-bit nibbles and 8-bit bytes, but it should be noted that any data size is applicable to the principles of the present invention. The location for the information is arrived at algorithmically, and no single individual location is inherently secret, but knowledge of the totality of the locations and their order of traversal is critical. The content is encrypted, but before being encrypted, each 8-bit word or byte is broken down into 4-bit nibbles, and is merged 4 bits at a time with a completely unrelated stream of bits, which may also themselves be equally meaningful 4-bit nibbles. Such interleaved multiplexing is not limited to the two-way example above, but may be considered N-way, where N is an arbitrary positive integer of any size.
In another aspect of the present invention, the locations are not dynamically arrived at but are rather chosen by a mapping process and an encoded location map is generated. This map may be itself encrypted, then subdivided into 4-bit nibbles or 8-bit bytes and itself hidden.
In another aspect of the present invention, any encrypted file is locked by taking its decryption key and then encrypting that key using another encryption method or key. The encrypted key is placed in a known location, such as the beginning, end, or at a known offset within the file, or is subdivided into bits and scattered into the file in known, and therefore retrievable, locations. The locked file itself may then be subdivided, multiplexed, further encrypted, and hidden, as needed.
In another aspect of the present invention, content can be replaced with translocated content, such that, in the example of executable content, the file a.exe is replaced with another file a.exe. The contents of a.exe are encrypted, locked, and hidden as described above. Upon execution of a.exe the content is retrieved, decrypted if necessary, executed as desired. This is not to imply a limitation to executable software content such as .exe files; all other digital content, such as an audio a.wav file, can have one or more associations in preference order, with execution environments such as a variety of MP3 or audio software players. The playback environment can be provided within the secured entity, or can be something that was always resident on the system prior to installation of the secured entity.
In another aspect of the present invention, digital content (whether or not it is also hidden and/or encrypted) is modified such that it is tokenized or otherwise obfuscated, and then when it comes time for the content to be used, it is interpreted within a custom interpreter that is a part of the system. An example of such is to modify a compiler such that the assembly language output is nonstandard, and thus require that the execution occur in an interpreter designed for the task. Such construction is possible even using decades-old utilities such as LEXX and YaCC, traditionally compiler creation tools. Such an interpreter is composed of a parser which consumes tokens, converts the tokenized logic to native computing instructions, obfuscates these instructions with anti-disassembly logic, and feeds them to the standard system interfaces. Such interposition of execution layers makes debugging a nontrivial task, and the anti-disassembly logic eliminates the use of many popular disassembly tools
In another aspect, the present invention employs saturation “chaff” logic to create a large amount of harmless and meaningless (yet utterly real in appearance and content, and apparently meaningful) information designed to saturate or confuse logging, reverse engineering, and debugging tools. Such logic can be targeted at specific systems, such that large amounts of I/O to the CD device can be used to mask any meaningful activity that may also be occurring on a device. The saturation invention is particularly useful against attempts to reverse engineer a protection system by monitoring its activity, because any such eventual logging/journal output of these tools must be reviewed and interpreted by human beings, and the overall volume (instead of 100 or 500 lines of logging on a device in a few minutes, this invention can generate tens of thousands of spurious log events in the same time period) can make it difficult or impossible to sort out the useful information from the chaff.
In another aspect, the present invention prevents sophisticated monitoring tools from monitoring and logging file access. This is accomplished by creating a driver extension layer, referred to as a “shim”, and attaching it to all appropriate operating system interfaces. Note that these shim interfaces on most consumer computer operating systems allow chaining, so that multiple layers can be stacked dynamically. This is also commonly called “hooking” on Windows operating systems. The present invention provides security by selecting where to hook (whether you choose to hook before or after a monitoring shim/hooking tool, such as FileMon, is significant; one can even hook both before AND after, to provide the tool with spurious input information). The mechanism rehooks at the desired depth(s) with variable frequency to defeat subsequent monitoring tool invocations.
In another aspect the present invention creates a driver extension layer, and shims or hooks the all relevant operating system interfaces, (and re-attach as above if desired). In this aspect, access filtering capabilities are employed to alter access to secured content, or to security-threat content.
In another aspect, the present invention employs an authorization process, which serves as a significant part of the decision in determining the status and origins of a task or process on the system and make an access determination.
In another aspect, the present invention includes an “assassin” construct; a system entity that operates to monitor activity and take action as needed. If, for example, the system were composed of multiple processes, one or more of which were protective by nature, and someone were to kill or stop one of the protective processes, an assassin process would take note of that occurrence, and would take action. The authorization process described below is a significant part of this decision in determining the status and origins of a task or process on the system. Such action might include disabling the rest of the system to prevent tampering, or killing the tampering process, or both. Assassin constructs are most useful if they serve some other purpose essential to the system, such as if, in the example above, the assassin process also served as a system's decryption service, such that killing the assassin would result in loss of ability to decrypt by the system, guaranteeing failure. Such assassin processes can detect the existence of specific tools both dormant and active, and prohibit the protective system's exposure to them.
In another aspect, the present invention includes an “authorization” construct. Such a process is aware of how the operating system tracks the lineage of processes and tasks, and can determine parentage quickly and accurately, so that is can be used to authorize file accesses to appropriate subtasks of an authorized task. On many operating systems the level of identification required by the system is insufficient so this aspect of the invention can bypass system query utilities and instead walk the system's process memory and track the lineage, creation, and deletion of processes and tasks.
In view of the above, the present invention is first directed to a system and method for preventing unauthorized use of digital content data. Digital content data is subdivided into data segments. The data segments are modified with second data to generate modified data. The modified data are then stored at predetermined memory locations.
It is noted that the digital content data may comprise any form of digital data that is stored, transmitted, or utilized on or between computer systems of all types. Such data includes, but is not limited to, audio, video, documents, electronic text and software and the like.
The data segments are preferably of a variable length, and the second data preferably comprises a randomly generated data stream. The second data may optionally comprise portions of the digital content data.
The modified data may likewise be encrypted and stored, for example with an encryption key, which, may in turn itself be encrypted. The encryption key may be stored with the encrypted modified data at the predetermined memory locations, and may be partitioned among the encrypted modified data.
The digital content data may comprise first and second digital content data, wherein the predetermined memory locations are selected as combinations of the locations at which the first and second digital content data were originally stored. A map of locations at which the modified data is stored may be generated and stored at the predetermined memory locations.
In a preferred embodiment, the memory locations reside on a system and the system is scanned to determine available memory locations. Target memory locations within the available memory locations at which to store the modified data are determined. The modified data is then stored at the target memory locations. The available memory locations may be located within file system locations and outside file system locations.
Modification of the data segments preferably comprises interleaving the data segments with the second data to generate interleaved data. The second data may be tokenized, for example with lexical equivalents of assembly language commands. The lexical equivalents may be consumed by a system interpreter, in turn generating alternative assembly language commands selected to obfuscate the digital content data in the event of an unauthorized access.
The present invention is also directed to a method and system for preventing unauthorized use of digital content data in a system having memory locations comprising. Digital content data is subdivided into data segments, which are, in turn, modified with second data to generate modified data. The system is scanned to determine available memory locations and target memory locations within the available memory locations at which to store the modified data are selected. The modified data are then stored at the target memory locations.
The present invention is further directed to a method and system for preventing unauthorized use of digital content data hosted on a system. Digital content data is modified with saturation data to generate modified data, and the modified data are stored at predetermined memory locations on the system to deter unauthorized access of the digital content data.
In a preferred embodiment, it is determined whether an unauthorized attempt at accessing the digital content data occurs, and in the event of unauthorized access, saturation traffic is generated on the system to deter the unauthorized activity. The saturation traffic may comprise commands that burden system resources, for example as a function of activity utilizing the system resources subject to the unauthorized access.
The present invention is further directed to a method and system for preventing unauthorized use of digital content data hosted on a system wherein a table of contents identifies files stored at memory locations of the system. A first memory location referring to a location at which at which first data file is stored is identified at the table of contents. The first memory location in the table of contents is then modified to refer to a second data file at a second location. Upon an attempt at access by the system of the first data file, the second data file is accessed if the attempt is unauthorized.
In an alternative embodiment, the first data file is replaced with the second data file and upon an attempt at access by the system of the first data file, the second data file is accessed if the attempt is unauthorized.
The present invention is further directed to a method and system for preventing unauthorized use of digital content data hosted on a system. An operating system interface of the system is monitored to determine access of operating system resources. A shim is repeatedly generated on the operating system interface to deter unauthorized access of the digital content data.
The present invention is further directed to a method and system for preventing unauthorized use of digital content data hosted on a system wherein a portion of the digital content data is substituted with token data to generate tokenized data. The tokenized data are stored at predetermined memory locations on the system to deter unauthorized access of the digital content data.
The present invention is further directed to a method and system for preventing unauthorized use of digital content data hosted on a system wherein an operating system interface operating on the system and the digital content data at an assassin process are monitored to determine whether an unauthorized attempt at accessing the digital content data occurs. In the event of unauthorized access, the unauthorized access is deterred and communicated to the operating system interface.
The present invention is further directed to a method and system for preventing unauthorized use of digital content data in a system having memory locations wherein the system is scanned to determine available memory locations based on a file system identifying locations of files on the system. Target memory locations are determined within the available memory locations at which to store the digital content data. The digital content data is stored at the target memory locations.
In another aspect, the present invention includes a software development kit and toolkit, which embodies the aspects of the inventions described above and allows for their application to target content without revealing the details of the construct methods to the user.
The present invention is thus further directed to a system for preventing unauthorized use of digital content data in a system having memory locations wherein the system enables a user to select from a plurality of tool modules, each module providing a service for protecting digital content from unauthorized use such that a user can protect digital content. The tool modules may comprise modules that perform functions selected from the group of functions consisting of: interleaving; tokenization; obfuscation; saturation; translocation; shimming and assassination.
The present invention is further directed to systems and methods that allow for the delivery of content in a fashion that prohibits content modification and duplication by unauthorized persons. The invention mechanisms detailed in this document enable, support and secure the delivery of software titles, audio, video, and text/graphic/e-book/e-presentation formats using both hard media and network content delivery models.
The present invention further processes and packages the components of a digital content product, for example the standard component contents of a hard media digital product, including executable files, documentation files, image files, and audio files. A standard hard media product may be taken in entirety from a CD release and converted into a securely downloadable product. Some or all of the content is indelibly watermarked with serialized purchase information unique to each purchaser at the download site before being downloaded. On a server that deploys this protected content, kit components can be packaged as large archives or can be stored individually (in the same form as a hard media kit, including optionally, directory structures) and then manufactured on-demand, per-user, per purchase. The final kit is packaged as a collection of encrypted archives, or as a single monolithic archive, securely encrypted, and made installable at the appropriate time by a secure installation process. Each installation of the product can optionally be made more secure by requiring authentication; multiple invention methods may be used including network authentication and authentication from locally hidden data and/or local computing device and peripheral configuration information. In the network installation case, installation or re-installation may be disallowed at any time by the vendor based on their criteria (number of times, frequency, etc). Such remote authentication invention methods may be added to hard media based products as well.
The present invention further allows for modification of the product's files, both before the download while still on the server (or before being copied to the server), and also the application files in the product directory after the installation, on the customer computer. This invention inserts hidden data into these product files, this hidden data incorporating among other identifying data a securely encrypted transaction ID, which may also be modified by a function based on information about the target system's component-specific configuration information. The hidden data may alternately or inclusively be a simple numeric index or may also have meaningful content interleaved into itself, such data hiding concepts defined herein. The data may be of any length. These hidden data items are inserted into secret locations within the product files prior to kitting, for example using the mechanisms disclosed herein, at the point of purchase.
The present invention further authorizes the execution of product components by providing a service that correlates attributes of the executable product with the system which is the target of the execution of the product. This applies to hard media and to Electronic Software Distribution (ESD). In this aspect, the ESD content delivery phase may be authenticated by means of purchase (or other) unique transaction-specific information and/or system specific information.
The present invention further processes product files in order to make room for more hidden data items. These additional reserved spaces for hidden data items are integrated directly into any desired product files and are optionally pre-filled with filler content
The present invention further segments the contents of the download kit such that specific small and critical files or even portions of such files are segregated from the main kit. The downloaded installation kit is therefore incomplete in small but critical ways. The installation process requires subsequent authenticated reconnections to the download host, followed by small and volatile downloads of these critical items.
The present invention further segments the contents of the installed digital product such that specific critical files and/or portions of such files are segregated and encrypted in a fashion that makes the installed product only function properly on the intended target system.
According to the present invention, certain chosen program elements are intentionally incomplete, and will be completed by means of executable information extracted from the authorization process, in some cases by hiding the information within the authentication response. For example the authorization process can provide the system with both numerical encrypted information (keys for further system decryption use) and executable content critical to task completion.
According to the present invention, content has certain sections altered such that key elements are removed and hidden elsewhere, (on the media itself in the case of hard media, on the network in other cases, on other system storage devices in the case of something already installed on a computer system) in secret locations. Execution requires these hidden elements be found and replaced in their original locations within the content. These elements are stored in locations that would not be copied easily with either the installer media or the installed product directory.
The present invention is further directed to mechanisms that detect the presence of classes and instances of software development tools (known variously as ICES, Debuggers, dump/lift tools, process fixup tools) and which initiates responses (exit, kill intrusion process, etc) when invoked on a system that has been thus instrumented for hacker purposes.
The present invention further determines whether the environment is safe (criteria include absence of some or all software development tools and emulation environments) and allows the protected title to run. After this occurs, subsequent execution of any and all prohibited tools is disallowed in part this is accomplished by means of methods discussed in the Translocation claims attached herein; by translocation of the desired tool with a stub that exits. Other methods include disabling certain input device (keyboard and mouse) responses as needed.
In another aspect, in order to defend the system from attack, the system exits upon being compromised or otherwise touched by unauthorized tools or methods. The exit itself may be delayed or deferred to obfuscate the logic behind the exit process. Other cooperating components of the invention (processes, threads, tasks and other logical algorithmic entities) can be configured such that if one exits for any reasons all the others exit as well.
In another aspect, all system defense related tasks (such as encryption, decryption, message passing, debugger detection via memory scan, etc) are encapsulated within other routines commonly used by the system. For example, it can be that every file open also triggers a defensive routine that scans memory or rewrites memory. In this manner, any and all system activity act as events that trigger defensive routines, so these routines do not necessarily have to poll or loop as their exclusive method of acting upon the system. Removal of these defenses is non-trivial as they can be deeply integrated into every aspect of the system.
In another aspect, each process, thread or task in the system has a dual or multiple role. One is the true functional role of that component (such as decryption), and the other is the monitoring and protection of all other parts of the system using techniques outlined in this document. Such protective functions are sometimes referred to as Assassin processes. Any attempt to compromise the system will result in a mass exit of all system components. The distributed nature of this protection across dozens of system tasks results in a very powerful redundant protection model where any attempt to tamper with one part of the system results in a protective response from the rest of the system.
In another aspect, all strings and other resource elements used are encrypted and decrypted by the system in a volatile fashion when used, and then disposed of, such that they cannot be easily searched for within the code either statically or in memory.
In another aspect, data values that are critical to the system are read and rewritten by a number of decoy or spoof processes, such that debugger watchpoints on these values, if any, will be triggered excessively, and thus it will be difficult to determine which accesses are decoy and which are valid without much deeper debugging.
In another aspect, system and product code can maintain itself in a difficult-to-modify state even if modification is attempted by a sophisticated debugger, editor or other tool. Key code elements are rewritten in place, in memory, using whatever mode of privilege is required, many times per second (tens, hundreds, tuned to be optimal as needed), at initialization and during execution, so that any attempts to tamper the code will be changed back to the original state. Depending on the nature of the change, the system may also choose to exit as a result of the tampering. For example, a classic hacker attack, the modification of Import Tables, is defeated in this way. All key code segments are duplicated in an encrypted archive, the archive is hidden (perhaps within files, between files, or outside the file system) read from that archive (some part of the read and decryption occurs in the virtual machine context described elsewhere in the document). Decoy archives and decoy read processes are also established which read from nonencrypted decoy code and write it over the sections, or seem to write it over the sections (writes through the I/O subsystem which are then defeated by tapping into the subsystem and tossing the data away) such that attempts to modify these decoy archives result in no change to the running code.
In another aspect, certain critical executable components are processed before shipment to be populated with tens or hundreds of thousands of data values which trigger debugger breakpoints in many debuggers. During normal execution of the title in a non-debug environment, these breakpoints are handled by a null handler and little negative performance impact is achieved. In the debug environment, each breakpoint stops the debugger and requires the intruder to at the least click the mouse and type into the keyboard. A single execution of such a title would require on the order of a hundred thousand mouse-clicks and keyboard presses. The purpose of such is to significantly deter unauthorized debugging, and at the very least to render it as slow and painful as possible.
In another aspect, resistance to tools used to “memory lift” or “memory dump” is achieved by modifying (corrupting) large parts of the code before packaging and storing the original correct parts elsewhere. This modification can take the form of gross and/or subtle corruption, yielding unexecutable code or subtle logical alterations in code that runs. When the code is run in the correct context, a cooperating synchronized system process modifies the code back to the correct executable state but only in a rolling window of context such that at no time is the entire body of the content correct, just those parts that are required at the current execution time. Once executed these lines of code are re-corrupted.
In another aspect, source, object, or executable code is processed to generate variant different versions of executable code, by means of replacement of content with functionally synonymous content. For example in the case of executable content, different assembly language instructions and ordering, that produce the same functional outcome are generated, such that no two such versions share the same fingerprint or the same code-line-number relationship per instruction. This variation is designed to reduce or eliminate the broadly disseminated effectiveness of hacker tutorials and documents that usually depend on specific line-number directions.
The foregoing and other objects, features and advantages of the invention will be apparent from the more particular description of preferred embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention
The present invention will be more completely understood by means of the following detailed description, which should be read in conjunction with the attached drawings,
This invention and its embodiments may be implemented on a personal computer or general purpose digital computer as shown in
The systems and methods of the present invention may be embodied and implemented on a general-purpose digital computer or personal computer system 6 as shown in
The computer system 6 may be a general purpose home or office or mobile computer system. Such systems allow for the usage/consumption/execution of a variety of forms of digital content; the invention disclosed herein can be applied to all forms of such digital content and the foregoing will describe some of the forms of this content on this computing platform family. Such systems are generally multiple-component level hardware-based systems, comprised of a motherboard or main-board, with various specialized components (such as I/O cards, video cards, processors, memory) attached to it by means of connectors. Each such card and the motherboard itself and the attached components have some amount of executable firmware located on various non-volatile memory 3 integrated circuit components, but the majority of the system's operational logic is driven by executable operating system code that is stored on media (non-removable or removable magnetic and or optical media, or non-volatile random access memory media). Usually on a system of this general type such executable code is created by software developers and is written using program code in modern programming languages such as C and C++. Such languages are programmatically compiled into assembly language or machine instruction code and are later executed directly on the system's central processing unit. Other programming languages and techniques, such as those used in Java, JavaScript, and Visual Basic, are interpreted at runtime; they're stored in their original language, or in a moderately tokenized version of their original language, and are then rendered on the fly at execution time into assembly language or machine instruction code and are later executed directly on the system's central processing unit. Other forms of relevant digital content utilized on such a computer system are audio (for example .wav or .mp3 file formats), video (for example .avi file format), e-book and documentation (for example .pdf or variant secure-portable-document-format), and all such content may be significantly security-enhanced by the application of the invention described in this document.
As shown in
In one embodiment of this invention, illustrated in
Prior to writing the output stream, the watermark may optionally be encrypted by a key to further enhance its security. The encryption key itself can also be optionally encrypted in a similar manner in steps 15 (subdivide into segments) 16 (interleave) and 17 (encrypt), and optionally stored in a known location with the data stream 18.
An example of the resultant effect of the system and method of the invention is provided in the following illustration. Assume an identifier 1234 11 that is to be hidden in 100 locations on a game CD (see description below in connection with
The present invention, illustrated in
The following code example details an embodiment of this invention which illustrates the concepts discussed in the above paragraphs which reference
A simple example and embodiment of this aspect of the present invention now follows. Assume three streams of digital content, in this case three files on disk, each of five megabytes in size. File “A” is a text file. File “B” is an audio file. File “C” is a Word document; thus on a general purpose computing device 6 (see
One embodiment of the writing process 18 streams the contents back into the original files A, B and C (see
The following example CmapLocation::WriteFile is a code example of the logic used to create such a map file of locations. Note that there are two types of maps created by the CmapLocation::WriteFile code example below: raw maps and location maps. Raw maps are built upon a linked list structure of locations and lengths and also contain detailed information about the file this mapped area was derived from. Location maps are a further abstraction, and are built upon linked lists of raw map lists, where each location map entry contains information to locate a certain number of data bytes. In the example code below, this value is 16 bytes to support the example encryption method, which is optimized for 16 bit units of data. So in the foregoing example, the location map is created from the raw map by partitioning it into 16 byte blocks. These 16 byte blocks need not be contiguous.
Also note that the following code examples embody another aspect of this invention; namely, a file locker, a mechanism as described below with reference to
With reference to
The operation for choosing the actual locations will now be described with reference to
With reference to
Low-level operating system interfaces are accessed, and device level access is initialized 34 at a level far below the normal file system interfaces, such that the device may be addressed in any and all valid raw physical locations, whether inside or outside the standard file system. The map or map information obtained above at step 33 is used to determine the ordering or reading and the read locations, and these locations are read in order 35. The items read are concatenated in the order read to re-create the original multiplexed interleaved stream. If decrypted previously, the decryption key is read, either from the map 33 or from a predetermined location which may be at the beginning of the encrypted stream 43 (see
Returning to
Using this research data, and proprietary data collected manually by examining many available file types, the present invention embodies a set of programmatic rules that represent techniques for placing data within all the known safe locations (see
The following code example illustrates an embodiment of the invention described above and the programmatic rules illustrated above and with reference to
In another embodiment of this invention illustrated in
In one such implementation, content may be placed within the file system 65 but hidden between the files 56 in space, for example, that is created by the fragmentation of predetermined storage blocks on the storage media such that the files visible in the file system do not entirely occupy the space allocated for them. Such content is placed in unused between-file fragmentation space within the bounds of the file system 56 such that its location is unknown to the table of contents 54 so that no file system access at the file level will be able to locate or access the files. This type of information hiding may require the information be subdivided into small parts and hidden in multiple smaller locations, since the available space between files may be fragmented.
In another embodiment 66 such content may be placed outside the file system entirely 59. In this implementation, the amount of contiguous available space is larger and thus such a file may be placed in contiguous locations, however note that such a file may in fact still be subdivided and placed into multiple disordered discontiguous locations for added security even in the abundant contiguous space in such extra-file system 59 locations.
In an alternative embodiment 67, the content is placed partly between the files within the file system 62, and partly in space outside the file system, namely the extra-file system 63.
The concept of translocation as implemented in this invention and as illustrated in
Similarly in examples 66 and 67, the locations that are populated with the translocated content (in this case the real “ProcDump.exe” we're hiding) are either outside the file system entirely 66, or, in the case of example 67, partly within the fragmented between-file space and partly outside the file system.
Note that in an alternate inverse embodiment of this invention, the original file is not moved at all 55 but rather the translocation replacement file is placed into the new location 56, and the file system's pointers 57 are temporarily updated to point to the translocated replacement file. Note that locations outside the bounds of the file system, for example location 59, may be on the same media as the file system or on entirely different media, for example, random access memory, rewriteable storage, network storage, or any other viable storage medium accessible to the system.
An example process used to create a translocation replacement file is now detailed with reference to
With reference to
As explained above, translocation is defined as the ability to provide ubiquitous redirection, which may be used for both the hiding of information, and for the purpose of defending against attacks by disabling the opponent's access to the necessary reverse engineering tools. Translocation may be embodied in a system that actually moves content, or in a system that redirects access to content without moving it. For example, in the case of moving content, an individual's intent on reverse engineering a protected system may wish to run the Visual C++ development tools to attempt to debug the running system. When the protective system is invoked, among the first things it does is translocate all threatening tools it finds, such that Visual C++ is moved from its old location 55 to a new location 56 (see
An example of translocation that redirects without moving content is similar. With reference to
Note that translocated content leaves no obvious clues; the process used to create 73 these substitute or redirected files as in the example
Another embodiment of this invention as exemplified in
For example, with reference to
With reference to
Details related to the substitution of tokens are provided at
Returning to
With reference to
In the example below, this invention replaces standard assembly language elements with permuted assembly language which has attributes that cause disassembly utilities such as, for example, the popular disassembly tool IDA Pro, sold and distributed by the Belgian firm DataRescue. Such tools depend on assembly language being formed and structured in specific standard ways; the enhanced assembly language generated by this invention offers the same logical function as the code it replaces but is resistant to disassembly as shown in the example code illustrations below.
The first such code example below illustrates this invention's insertion of jmp statements to instances of the following assembly language instructions: inc, dec, call, jmp, and push
For example, this embodiment changes instances of “jumps” to (push and return) calls:
For example, jumping into the middle of an instruction to confuse all disassemblers:
Another code example of the same class of techniques used by this invention:
Note that the “add ah,03Bh” command is instantiated to insert the value 2503h into location ax. By adding five bytes (as opposed to simply using ‘mov ax,2503h’) this code will defeat all known disassemblers. Even if the instructions are disassembled properly, the value of ax will not be known, so every int call after this point will not be commented properly, as long as the system never moves a value into ax. This embodiment of the invention can conceal the value from the disassembler by using ‘add ax’ or ‘sub ax’ whenever possible. Thus any value can be put into ax.
This invention, of course, must make such substitutions in an automated fashion; the code example below illustrates such programmatic assembly language substitution:
In an alternative embodiment of the above aspect of the invention, and a variant example, the inventive system and method, after having tokenized and obfuscated the content and optionally interleaved, multiplexed, encrypted, and/or hidden it, later, as needed, when it is time to execute this content, the content is located and extracted (if it was indeed interleaved, multiplexed, encrypted, and/or hidden), parsed, content type determined, the tokens are parsed and execution occurs in lockstep with the conversion to executable content so the reconstituted content is never written to a file or provided to any entity in the system, but is rather executed on the fly within a custom execution context 101 (see
An embodiment of this invention may generate for example instances of the variant assembly language as illustrated in the example above, and thereby be resistant to disassembly, and may also be made more difficult to debug by defeating automatic disassembly tools using obfuscated assembly language programming techniques, for example inappropriate not-used jumps into the middle of instructions. Such obfuscation, or similarly effective methods accomplished by other means, enhance the security of the invention. Note that this is in addition to the inherent security of running within an interpretive environment. The interpreter operates as a shield from debugging and reverse-engineering tools. The interpreter serves as a layer of abstraction between the protective invention and the real operating system. The values found in system memory and registers will not be directly related to the logical flow of the interpreted program; they will show the debug state of the interpreter itself instead, and that will make assembly language debugging very difficult.
In another embodiment of this invention described with reference to
This targeted saturation embodiment of the present invention operates as follows. The protection by saturation of a system or application first depends on understanding the nature of the normal system traffic generated by that application. Therefore, with reference to
As described in
The functioning of an individual instance of a saturation engine 116 is shown in
All individual saturation engines are controlled by a saturation scheduler as shown in
In another embodiment of this invention as shown in
In the code example below, this dynamic-reconnection mechanism of the present invention manifests itself as a process that attaches to the first location directly at the interface level, and forces all subsequent shims of any other kind to attach themselves after the invention by continually reattaching in the first position:
In another embodiment of this invention, described with reference to
In this embodiment, as above, a filter, shim, device driver extension, or substitute device driver is inserted into system interfaces in this case, interposing itself at step 131 between the reverse engineering monitoring shim and the rest of the system, thus apparently subsuming the role of the operating system interface and providing false and misleading data 132 to the monitoring/reverse-engineering shim/tool. The vulnerability of all such interface shimming techniques in their simplest form is that another such shim intended to compromise such a shim could be inserted after (or before, or both, depending on the intent) this process at any time, thus obviating the utility of such a mechanism. Thus, this embodiment of the invention includes a reattachment mechanism 134 which guarantees a specific attachment location, in this case directly before the opponent reverse-engineering/monitoring shim, as specified by the invention's user. This is accomplished by repeated automated re-insertions 135 into the interface chain. Such reinsertions are done in a fashion that does not impede function by waiting a number of time units 133 between issued instructions. Thus this embodiment of continual-interface-reattachment can eliminate the threat of device redirection and monitoring tools being used to subvert the system.
In another embodiment of the present invention, as illustrated in
The code example below illustrates the invention discussed above in conjunction with
The code example below illustrates the invention discussed above in conjunction with
In another embodiment of the present invention, a protective entity is created; such entity operates as an independent protective agent and secures all protected content from unauthorized access. As depicted in
In the code example below, a first embodiment of the assassin process determines the identity of another assassin process (this is a two-assassin example) and instances 146, and monitors them for exit conditions 148. Upon an exit condition, this embodiment attempts to kill other assassin processes and then kills itself 150.
At this point, this embodiment has proven that two assassin process identifiers were specified. This means that the currently executing entity is the first assassin launched. The monitored identifiers will therefore be that of the second assassin entity and the application entity (target). This embodiment will wait for either one to exit; and assumes the target entity will exit when it is finished, in which case the first assassin entity can clean up and itself exit. If, on the other hand, it is the assassin entity that exits, this means that someone or something (a debug process perhaps) has killed it, so the first assassin entity will attempt to terminate the target entity and then delete all the instances of other system entities that it can.
In another embodiment of the present invention, a determination is made by the system as to whether any given process, thread, entity, or access 154 on/of the system is an authorized process or an unauthorized process with respect to access to any of the protected, encrypted, interleaved, or hidden components of the system. As illustrated in
The code example below illustrates the above aspect of the invention as represented in
The next code example illustrates the above invention as represented in
The code example below illustrates mechanisms utilized to verify the identity of an entity and make a decision as to allowing or disallowing access to the entity.
In another embodiment of this invention, any or all of the above aspects of the invention as illustrated and described above are incorporated into an application, or set of applications, and associated documentation, which are engineered to provide the aforementioned capabilities to digital content creation professionals and other such users. In this manner, digital content that a user desires to protect is provided to an appropriate toolkit as input and the techniques detailed above are applied to the content. The user is not necessarily exposed to the inner operation of the above processes, nor of the applied inventive techniques. The output of such a toolkit is a protected digital content entity. All types of content are supported and are equally applicable to the principles on the invention, including; audio, video, executable, images, text, documents, e-books, and all other digital content of all types on all platforms as described above. The user of this toolkit may choose to include or exclude any of the inventive components mentioned above as part of the configuration of the tool, but at no time is it necessary for the user to understand in any detail how each component works, or how the individual components of the system interact.
In another embodiment, the invention is directed to methods that allow for the electronic delivery of digital content in a fashion that prohibits content modification and duplication by unauthorized persons. The mechanisms detailed herein enable, support and secure the delivery of all forms of electronic content software titles, audio, video, and text/graphic/e-book/e-presentation formats using both hard media and network content delivery models.
In one aspect, the product's files are modified, both before an electronic download while the product still resides on the server (or before being copied to the server), and the application files are also modified in the product directory following installation on the customer computer. Hidden data is inserted into these product files, this hidden data incorporating among other identifying data a securely encrypted transaction ID, which may also be modified by a function based on information about the target system's component-specific configuration information. The hidden data may alternately or inclusively comprise a simple numeric index or may also have meaningful content interleaved into itself, as described above in connection with
There are multiple authorization models supported by the present invention. One such model is an entirely local model where the digital content may be installed or used from locally read hard media. Another such model is a network model in which there is a series of network transactions. In the latter case, the foregoing may describe a “target Computing System or Device” (the client, in other words) and a “Remote Server” (the server). Note the server may in fact comprise multiple server machines, each performing a set of either unique or redundant functions. In general, by putting certain key logical components on the remote server they are insulated from being reverse engineered. A good example, detailed elsewhere, is the generation of a system ID based on the configuration of the target system or client. It is desired under some circumstances that this ID value be converted into a usable encryption/decryption key (either symmetric or asymmetric in function). Based on the security concerns just discussed, if this key generation algorithm were on the client system it might be possible to reverse engineer it and compromise it, and thereby compromise the system. By having it be remote on the server in some embodiments of the invention, it effectively becomes a “black box” whose output may of course be intercepted and examined under some circumstances, but whose inner workings cannot be exposed by debugging, disassembly or other compromise of the client system, thus rendering the invention more secure under these circumstances. This client-server utilization of distributed service functions is optimal when possible but may not always be appropriate, as in the case of a CD or other hard media installation or usage of digital content where there is no network connection. Finally, it is important not to view the network versus hard media models as binary opposites or mutually exclusive models, there exists a hybrid model where the installation or distribution and subsequent usage of the digital content is from hard media but certain steps of the authorization process require a network connection. This model is a good compromise whenever possible because it allows certain key algorithm elements to be remote and therefore not susceptible to being attacked by local debug means, and the usage of it requires that the content creator be willing to make an active network connection of some kind (whether broadband, dial-up, or other) a requirement for usage of their content. This set of decisions is entirely a business model based decision, not one limited by technical means. This invention offers optimum flexibility for all such business decisions, local, remote, or hybrid.
As illustrated in the flow diagram of
In the embodiments of the present invention that support network distribution of content, depending on the context of the usage of the embodiment, the System ID value may be transferred 168 either to a remote server, a locally executing runtime process, or a locally executing installation process, and further manipulated as shown in
With reference to
Returning to
Referring to
A mechanism of the invention authorizes the execution of product components (also referred to as Content) by providing a service that correlates attributes of the executable product with the system that is the target of the execution of the product. This applies to hard media and to Electronic Software Distribution (ESD). In this aspect of the present invention, the ESD content delivery phase may be authenticated by means of purchase (or other) unique transaction-specific information and/or system specific information. On a server that deploys this protected content, kit components are packaged as large archives or stored as raw data (in the same form as a hard media kit, including optionally, directory structures) and then manufactured on-demand, per-user, per purchase. The final kit is packaged as a collection of encrypted archives, or as a single monolithic archive, securely encrypted, and made usable or installable at the appropriate time by a secure product execution process. This process employs many of the techniques detailed above with reference to
In the network installation case, installation or re-installation may be disallowed at any time by the process illustrated in
A mechanism of the invention processes product files in order to make room for larger quantities of hidden data. These additional spaces for hidden data item are integrated directly into any desired product files and are optionally pre-filled with filler content that matches the surrounding data to render them difficult to locate. This process modifies each desired product or content file as follows with reference to
The process of the present invention may optionally segment the contents of the download kit such that specific small and critical files or even portions of such files are segregated from the main kit. The downloaded installation kit is therefore incomplete in small but critical ways. The installation process requires subsequent authenticated reconnections to the download host, followed by small and volatile downloads of these critical items. Further this mechanism segments the contents of the installed digital product such that specific critical files and/or portions of such files are segregated and encrypted in a fashion that makes the installed product function properly only on the intended target system. Further, the process of this invention may intentionally leave incomplete certain chosen program elements, the elements to be completed by means of executable information extracted from an authorization process, in some cases by hiding the information within the authentication response. For example the authorization process can provide the system with both numerical encrypted information (keys for further system decryption use) and executable content critical to task completion. In one option, content may have certain sections altered such that key elements are removed and hidden elsewhere in secret locations, for example on the media itself in the case of hard media, on the network in other cases, on other system storage devices in the case for a component already installed on a computer system. Execution requires that these hidden elements are found and replaced in their original locations within the content. These elements are stored in locations that would not be copied easily with either the installer media or the installed product directory.
In a detailed view of such a process, as in
With reference to
The authentication process on the Target Computer System next optionally de-interleaves and decrypts the response data (according to the processes of
This invention can also be embodied within a variation of the mechanism described above. With reference to
A mechanism of this invention in which there are methods that can detect and discover the presence of classes and instances of software whose effects may be of a compromising nature to the secure system. Such tools whose discovery is desired include those used for software development (known variously as ICES, Debuggers, dump/lift tools, process fixup tools, any and all executing entities on the system at any level of privilege) and which discovery initiates defensive responses (exit, kill intrusion process, etc) when invoked on a system that has been thus instrumented for hacker purposes. In the system and process of the present invention, with reference to
One such example embodiment is illustrated with the code sample below, in which privileged and unprivileged memory on the target computing device is examined using the methods outlined above:
In the code example below, such hardware emulation detection as referenced above is exemplified, in the case of this example, certain status information is compared to known emulated hardware status information:
Other mechanisms of this aspect of the invention include disabling certain input device (keyboard and mouse, for example) responses as needed.
An invention mechanism that disables specific keystrokes is shown next. Referring to
A code example of such keystroke suppresssion follows:
In another aspect, in order to defend the system from attack, the system exits upon being compromised or otherwise touched by unauthorized tools or methods. The exit itself may be delayed or deferred to obfuscate the logic behind the exit process. Other cooperating components of this invention (processes, threads, tasks and other logical algorithmic entities) can be configured such that if one exits for any reasons all the others exit as well. The methods used to determine whether another process has exited include: interprocess communication via standard system synchronization methods; interprocess communication by nonstandard nonobvious synchronization methods including page level memory access using the VM system; page level memory access subverting the VM system by accessing locations physically; implicit exit via polling of a sort; touching areas of memory such that in the event the target process, thread, task or logical construct itself exits, an access violation in the reading process occurs, unhandled, causing it to exit with no decision logic required; event driven exit, where an event occurs that triggers processes to exit; and cross-kill, where the cooperating components of the system kill ALL of each other and THEN themselves upon compromise. These techniques may be used individually or may be utilized in combination to carry out the process of the present invention.
In another aspect, the process of the present invention maintains system security by using message passing and overt system analysis to determine whether other system components have been compromised or have exited. The exit of any entity is sufficient reason for the rest of the system entities to begin exiting in whatever order they determine appropriate. This results in a more or less nondeterministic order of exit for all components, to confuse efforts to understand a cause and effect relationship between actions (such as debugging) and reactions (such as system exit behaviors). As illustrated in
The process illustrated in
The process shown in
The process shown in
In another aspect of the present invention, system defense related tasks (such as encryption, decryption, message passing, debugger detection via memory scan, etc) are encapsulated within other routines commonly used by the system. For example, it can happen that every time a file is open, this action triggers a defensive routine that scans memory or rewrites memory. In this manner, any and all system activities operate as events that trigger defensive routines, so these routines do not necessarily have to poll or loop as their exclusive method of acting upon the system, and so that removal of these defenses is non-trivial as they can be deeply integrated into every aspect of the system. As in
According to the present invention, each process, thread or task in the system can have a dual, or multiple, role. One is the true functional role of that component (such as decryption), and the other is to participate in the distributed exit functions that are a significant part of the protective function of the system. Such protective exit functions are sometimes referred to as Assassin processes. Any attempt to compromise the system will result in a mass exit of all system components. The distributed nature of this protection across dozens of system tasks results in a very powerful redundant protection model where any attempt to tamper with one part of the system results in a protective response from the rest of the system.
In the process shown in
In the case where strings were encrypted as specified in
The systems and methods present invention allow system and product code to maintain itself in a difficult-to-modify state even if modification is attempted by a sophisticated debugger, editor or other tool. Key code elements are rewritten in place, in memory, using whatever mode of privilege is required, many times per second (tens, hundreds, tuned to be optimal as needed), at initialization and during execution, so that any attempts to tamper the code will be changed back to the original state. Depending on the nature of the change, the system may also choose to exit as a result of the tampering. For example, in a classic hacker attack, the modification of Import Tables, is defeated in this way. All key code segments are duplicated in an encrypted archive, the archive is hidden (perhaps within files, between files, or outside the file system), and the segments are later read from that archive (some part of the read and decryption occurs in the virtual machine context described elsewhere in the document). Decoy archives and decoy read processes are also established which read from nonencrypted decoy code and write it over the sections, or appear to write it over the sections (writes through the I/O subsystem which are then defeated by tapping into the subsystem and tossing the data away) such that attempts to modify these decoy archives result in no change to the running code. With reference to
A code example of this continuous overwrite process is reproduced below to provide for additional clarity:
The present invention further accommodates certain critical executable components to be processed before shipment to be populated with tens or hundreds of thousands of data values which trigger debugger breakpoints in many debuggers. During normal execution of the title in a non-debug environment, these breakpoints are handled by a null handler and little negative performance impact is achieved. In the debug environment, each breakpoint stops the debugger and requires the intruder to at the least click the mouse and type into the keyboard. A single execution of such a title would require on the order of a hundred thousand mouse-clicks and keyboard presses. The purpose of such is to significantly deter unauthorized debugging, and at the very least to render it as slow and painful as possible. With reference to
In another aspect of the present invention, resistance to tools used to “memory lift” or “memory dump” is achieved by modifying (corrupting) large portions of the code before packaging and storing the original correct portions elsewhere. This modification can take the form of gross and/or subtle corruption, yielding unexecutable code or subtle logical alterations in code that runs. When the code is run in the correct context, a cooperating synchronized system process modifies the code back to the correct executable state but only in a rolling window of context in a just-in-time fashion such that at no time is the entire body of the content correct, just those parts that are required at the current execution time. Once executed these lines of code are re-corrupted. With reference to
The present invention further includes a system and method by which source, object, or executable code is processed to generate variant different versions of executable code, by means of replacement of content with functionally synonymous content. For example in the case of executable content, different assembly language instructions and ordering, that produce the same functional outcome, such that no two such versions share the same fingerprint or the same code-line-number relationship per instruction. This variation is designed to reduce or eliminate the broadly disseminated effectiveness of hacker tutorials and documents that usually depend on specific line-number directions. As illustrated in
Although the invention has been described in language specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and steps are disclosed as preferred forms of implementing the claimed invention.
While this invention has been particularly shown and described with references to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made herein without departing from the spirit and scope of the invention as defined by the appended claims.
This application is a continuation-in-part application of U.S. patent application Ser. No. 09/960,610, filed Sep. 21, 2001, which application claims the benefit of U.S. Provisional Application Ser. No. 60/234,657, filed Sep. 22, 2000, U.S. Provisional Application Ser. No. 60/240,611, filed Oct. 16, 2000, U.S. Provisional Application Ser. No. 60/242,949, filed Oct. 24, 2000, and U.S. Provisional Application Ser. No. 60/244,704, filed Oct. 31, 2000. This application also claims the benefit of U.S. Provisional Application Ser. No. 60/249,946, filed Nov. 20, 2000, U.S. Provisional Application Ser. No. 60/260,705, filed Jan. 10, 2001, and U.S. Provisional Application Ser. No. 60/285,300, filed Apr. 20, 2001. The contents of the applications referenced above are incorporated herein by reference, in their entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4118789 | Casto et al. | Oct 1978 | A |
| 4278837 | Best | Jul 1981 | A |
| 4306289 | Lumley | Dec 1981 | A |
| 4405829 | Rivest et al. | Sep 1983 | A |
| 4433207 | Best | Feb 1984 | A |
| 4577289 | Comerford et al. | Mar 1986 | A |
| 4593353 | Pickholtz | Jun 1986 | A |
| 4688169 | Joshi | Aug 1987 | A |
| 4827508 | Shear | May 1989 | A |
| 4864494 | Kobus, Jr. | Sep 1989 | A |
| 4864616 | Pond et al. | Sep 1989 | A |
| 4888800 | Marshall et al. | Dec 1989 | A |
| 4916637 | Allen et al. | Apr 1990 | A |
| 4969189 | Ohta et al. | Nov 1990 | A |
| 4977594 | Shear | Dec 1990 | A |
| 4999806 | Chernow et al. | Mar 1991 | A |
| 5014234 | Edwards, Jr. | May 1991 | A |
| 5021997 | Archie et al. | Jun 1991 | A |
| 5023907 | Johnson et al. | Jun 1991 | A |
| 5027396 | Platteter et al. | Jun 1991 | A |
| 5033084 | Beecher | Jul 1991 | A |
| 5050213 | Shear | Sep 1991 | A |
| 5081675 | Kittirutsunetorn | Jan 1992 | A |
| 5113518 | Durst et al. | May 1992 | A |
| 5140634 | Guillou et al. | Aug 1992 | A |
| 5155680 | Wiedemer | Oct 1992 | A |
| 5155837 | Liu et al. | Oct 1992 | A |
| 5155847 | Kirouac et al. | Oct 1992 | A |
| 5166886 | Molnar et al. | Nov 1992 | A |
| 5182770 | Medveczky et al. | Jan 1993 | A |
| 5191611 | Lang | Mar 1993 | A |
| 5199066 | Logan | Mar 1993 | A |
| 5220606 | Greenberg | Jun 1993 | A |
| 5222133 | Chou et al. | Jun 1993 | A |
| 5247683 | Holmes et al. | Sep 1993 | A |
| 5276311 | Hennige | Jan 1994 | A |
| 5313521 | Torii et al. | May 1994 | A |
| 5325433 | Torii et al. | Jun 1994 | A |
| 5327563 | Singh | Jul 1994 | A |
| 5337357 | Chou et al. | Aug 1994 | A |
| 5341429 | Stringer et al. | Aug 1994 | A |
| 5351293 | Michener et al. | Sep 1994 | A |
| 5351297 | Miyaji et al. | Sep 1994 | A |
| 5357573 | Walters | Oct 1994 | A |
| 5361359 | Tajalli et al. | Nov 1994 | A |
| 5367683 | Brett | Nov 1994 | A |
| 5367686 | Fisher et al. | Nov 1994 | A |
| 5379343 | Grube et al. | Jan 1995 | A |
| 5379433 | Yamagishi | Jan 1995 | A |
| 5392351 | Hasebe et al. | Feb 1995 | A |
| 5394469 | Nagel et al. | Feb 1995 | A |
| 5410598 | Shear | Apr 1995 | A |
| 5410703 | Nilsson et al. | Apr 1995 | A |
| 5414850 | Whiting | May 1995 | A |
| 5421009 | Platt | May 1995 | A |
| 5421017 | Scholz et al. | May 1995 | A |
| 5473687 | Lipscomb et al. | Dec 1995 | A |
| 5473690 | Grimonprez et al. | Dec 1995 | A |
| 5473692 | Davis | Dec 1995 | A |
| 5490216 | Richardson, III | Feb 1996 | A |
| 5491804 | Heath et al. | Feb 1996 | A |
| 5497423 | Miyaji | Mar 1996 | A |
| 5502831 | Grube et al. | Mar 1996 | A |
| 5509070 | Schull | Apr 1996 | A |
| 5509074 | Choudhury et al. | Apr 1996 | A |
| 5511123 | Adams | Apr 1996 | A |
| 5524072 | Labaton et al. | Jun 1996 | A |
| 5532920 | Hartrick et al. | Jul 1996 | A |
| 5544246 | Mandelbaum et al. | Aug 1996 | A |
| 5553143 | Ross et al. | Sep 1996 | A |
| 5555304 | Hasebe et al. | Sep 1996 | A |
| 5557346 | Lipner et al. | Sep 1996 | A |
| 5557675 | Schupak | Sep 1996 | A |
| 5570291 | Dudle et al. | Oct 1996 | A |
| 5579222 | Bains et al. | Nov 1996 | A |
| 5579479 | Plum | Nov 1996 | A |
| 5585585 | Paulson et al. | Dec 1996 | A |
| 5592549 | Nagel et al. | Jan 1997 | A |
| 5615061 | Singh | Mar 1997 | A |
| 5615264 | Kazmierczak et al. | Mar 1997 | A |
| 5625690 | Michel et al. | Apr 1997 | A |
| 5625692 | Herzberg et al. | Apr 1997 | A |
| 5638445 | Spelman et al. | Jun 1997 | A |
| 5654746 | McMullan, Jr. et al. | Aug 1997 | A |
| 5671412 | Christiano | Sep 1997 | A |
| 5673315 | Wolf | Sep 1997 | A |
| 5708709 | Rose | Jan 1998 | A |
| 5715169 | Noguchi | Feb 1998 | A |
| 5721781 | Deo et al. | Feb 1998 | A |
| 5737416 | Cooper et al. | Apr 1998 | A |
| 5745879 | Wyman | Apr 1998 | A |
| 5754647 | Hsu | May 1998 | A |
| 5754864 | Hill | May 1998 | A |
| 5757907 | Cooper et al. | May 1998 | A |
| 5758068 | Brandt et al. | May 1998 | A |
| 5761649 | Hill | Jun 1998 | A |
| 5790664 | Coley et al. | Aug 1998 | A |
| 5794230 | Horadan et al. | Aug 1998 | A |
| 5796824 | Hasebe et al. | Aug 1998 | A |
| 5796952 | Davis et al. | Aug 1998 | A |
| 5805802 | Marx | Sep 1998 | A |
| 5809145 | Slik et al. | Sep 1998 | A |
| 5812662 | Hsu et al. | Sep 1998 | A |
| 5812980 | Asai | Sep 1998 | A |
| 5826245 | Sandberg-Diment | Oct 1998 | A |
| 5835735 | Mason et al. | Nov 1998 | A |
| 5835911 | Nakagawa et al. | Nov 1998 | A |
| 5848291 | Milne et al. | Dec 1998 | A |
| 5883954 | Ronning | Mar 1999 | A |
| 5887060 | Ronning | Mar 1999 | A |
| 5892900 | Ginter et al. | Apr 1999 | A |
| 5892904 | Atkinson et al. | Apr 1999 | A |
| 5894516 | Brandenburg | Apr 1999 | A |
| 5903647 | Ronning | May 1999 | A |
| 5905860 | Olsen et al. | May 1999 | A |
| 5907617 | Ronning | May 1999 | A |
| 5909581 | Park | Jun 1999 | A |
| 5910987 | Ginter et al. | Jun 1999 | A |
| 5915019 | Ginter et al. | Jun 1999 | A |
| 5917912 | Ginter et al. | Jun 1999 | A |
| 5920861 | Hall et al. | Jul 1999 | A |
| 5930828 | Jensen et al. | Jul 1999 | A |
| 5933497 | Beetcher et al. | Aug 1999 | A |
| 5933498 | Schneck et al. | Aug 1999 | A |
| 5940504 | Griswold | Aug 1999 | A |
| 5943422 | Van Wie et al. | Aug 1999 | A |
| 5949876 | Ginter et al. | Sep 1999 | A |
| 5953502 | Helbig, Sr. | Sep 1999 | A |
| 5978482 | Dwork et al. | Nov 1999 | A |
| 5982891 | Ginter et al. | Nov 1999 | A |
| 5991399 | Graunke et al. | Nov 1999 | A |
| 5991876 | Johnson et al. | Nov 1999 | A |
| 6006190 | Baena-Arnaiz et al. | Dec 1999 | A |
| 6006328 | Drake | Dec 1999 | A |
| 6006332 | Rabne et al. | Dec 1999 | A |
| 6009274 | Fletcher et al. | Dec 1999 | A |
| 6009401 | Horstmann | Dec 1999 | A |
| 6012144 | Pickett | Jan 2000 | A |
| 6038316 | Dwork et al. | Mar 2000 | A |
| 6041411 | Wyatt | Mar 2000 | A |
| 6052780 | Glover | Apr 2000 | A |
| 6067416 | Fraser | May 2000 | A |
| 6073124 | Krishnan et al. | Jun 2000 | A |
| 6081794 | Saito et al. | Jun 2000 | A |
| 6112181 | Shear et al. | Aug 2000 | A |
| 6138119 | Hall et al. | Oct 2000 | A |
| 6148402 | Campbell | Nov 2000 | A |
| 6151618 | Wahbe et al. | Nov 2000 | A |
| 6157721 | Shear et al. | Dec 2000 | A |
| 6164841 | Mattson, Jr. et al. | Dec 2000 | A |
| 6178509 | Nardone et al. | Jan 2001 | B1 |
| 6185683 | Ginter et al. | Feb 2001 | B1 |
| 6185686 | Glover | Feb 2001 | B1 |
| 6188995 | Garst et al. | Feb 2001 | B1 |
| 6192475 | Wallace | Feb 2001 | B1 |
| 6223288 | Byrne | Apr 2001 | B1 |
| 6226618 | Downs et al. | May 2001 | B1 |
| 6226747 | Larsson et al. | May 2001 | B1 |
| 6233567 | Cohen | May 2001 | B1 |
| 6236727 | Ciacelli et al. | May 2001 | B1 |
| 6243468 | Pearce et al. | Jun 2001 | B1 |
| 6243692 | Floyd et al. | Jun 2001 | B1 |
| 6249870 | Kobayashi et al. | Jun 2001 | B1 |
| 6272636 | Neville et al. | Aug 2001 | B1 |
| 6286041 | Collins, III et al. | Sep 2001 | B1 |
| 6289455 | Kocher et al. | Sep 2001 | B1 |
| 6295613 | Bates et al. | Sep 2001 | B1 |
| 6327652 | England et al. | Dec 2001 | B1 |
| 6330670 | England et al. | Dec 2001 | B1 |
| 6334189 | Granger et al. | Dec 2001 | B1 |
| 6343280 | Clark | Jan 2002 | B2 |
| 6351813 | Mooney et al. | Feb 2002 | B1 |
| 6460023 | Bean et al. | Oct 2002 | B1 |
| 6501905 | Kimura | Dec 2002 | B1 |
| 6589626 | Selinfreund et al. | Jul 2003 | B2 |
| 6611812 | Hurtado et al. | Aug 2003 | B2 |
| 6638593 | Selinfreund et al. | Oct 2003 | B2 |
| 6744905 | Horiike | Jun 2004 | B1 |
| 6816972 | Kutaragi et al. | Nov 2004 | B1 |
| 6838145 | Drew et al. | Jan 2005 | B2 |
| 6859535 | Tatebayashi et al. | Feb 2005 | B1 |
| 6931540 | Edwards et al. | Aug 2005 | B1 |
| 6947973 | Shimura et al. | Sep 2005 | B2 |
| 6957341 | Rice et al. | Oct 2005 | B2 |
| 6973578 | McIchionc | Dec 2005 | B1 |
| 6981140 | Choo | Dec 2005 | B1 |
| 6981279 | Arnold et al. | Dec 2005 | B1 |
| 7010697 | Byrne et al. | Mar 2006 | B2 |
| 7069491 | Sollish et al. | Jun 2006 | B2 |
| 7124114 | Hollar | Oct 2006 | B1 |
| 20010018745 | Laczko, Sr. et al. | Aug 2001 | A1 |
| 20010034846 | Beery | Oct 2001 | A1 |
| 20010037450 | Metlitski et al. | Nov 2001 | A1 |
| 20010037456 | Levy | Nov 2001 | A1 |
| 20010041989 | Vilcauskas, Jr. et al. | Nov 2001 | A1 |
| 20010044782 | Hughes et al. | Nov 2001 | A1 |
| 20020001690 | Selinfreund et al. | Jan 2002 | A1 |
| 20020002468 | Spagna et al. | Jan 2002 | A1 |
| 20020003881 | Reitmeier | Jan 2002 | A1 |
| 20020010863 | Mankefors | Jan 2002 | A1 |
| 20020016918 | Tucker et al. | Feb 2002 | A1 |
| 20020035688 | Kutaragi et al. | Mar 2002 | A1 |
| 20020120871 | Watkins et al. | Aug 2002 | A1 |
| 20020146121 | Cohen | Oct 2002 | A1 |
| 20030147339 | Selinfreund et al. | Aug 2003 | A1 |
| 20050050343 | Selinfreund et al. | Mar 2005 | A1 |
| 20050063256 | Selinfreund et al. | Mar 2005 | A1 |
| 20050083829 | Selinfreund et al. | Apr 2005 | A1 |
| 20050084645 | Selinfreund et al. | Apr 2005 | A1 |
| 20050153109 | Drew et al. | Jul 2005 | A1 |
| 20060023600 | Selinfreund et al. | Feb 2006 | A1 |
| 20060031686 | Atallah et al. | Feb 2006 | A1 |
| 20060107070 | Rice et al. | May 2006 | A1 |
| Number | Date | Country |
|---|---|---|
| EP0844549 | May 1998 | DE |
| WO 9854713 | Mar 1998 | WO |
| WO 9844402 | Aug 1998 | WO |
| WO0117163 | Mar 2001 | WO |
| WO 0202301 | Jan 2002 | WO |
| WO 0203106 | Jan 2002 | WO |
| WO 0203386 | Jan 2002 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20020144153 A1 | Oct 2002 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60285300 | Apr 2001 | US | |
| 60260705 | Jan 2001 | US | |
| 60249946 | Nov 2000 | US | |
| 60244704 | Oct 2000 | US | |
| 60242949 | Oct 2000 | US | |
| 60240611 | Oct 2000 | US | |
| 60234657 | Sep 2000 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 09960610 | Sep 2001 | US |
| Child | 09989910 | US |
