Abstract: Instead of transferring a large original file, such as a virtual-machine image file, from a source system to a target system, the original file is encoded to define a recipe file that is transferred. The recipe is then decoded to yield a duplicate of the original file on the target system. Encoding involves identifying standard blocks in the original file and including standard-block identifiers for the standard blocks in the recipe in lieu of the original blocks. Decoding involves an exchange with a standard-block identifier server system, which provides standard blocks in response to received standard-block identifiers.

Abstract: Instead of transferring a large original file, such as a virtual-machine image file, from a source system to a target system, the original file is encoded to define a recipe file that is transferred. The recipe is then decoded to yield a duplicate of the original file on the target system. Encoding involves identifying standard blocks in the original file and including standard-block identifiers for the standard blocks in the recipe in lieu of the original blocks. Decoding involves an exchange with a standard-block identifier server system, which provides standard blocks in response to received standard-block identifiers.

Abstract: Instead of transferring a large original file, such as a virtual-machine image file, from a source system to a target system, the original file is encoded to define a recipe file that is transferred. The recipe is then decoded to yield a duplicate of the original file on the target system. Encoding involves identifying standard blocks in the original file and including standard-block identifiers for the standard blocks in the recipe in lieu of the original blocks. Decoding involves an exchange with a standard-block identifier server system, which provides standard blocks in response to received standard-block identifiers.

Abstract: Instead of transferring a large original file, such as a virtual-machine image file, from a source system to a target system, the original file is encoded to define a recipe file that is transferred. The recipe is then decoded to yield a duplicate of the original file on the target system. Encoding involves identifying standard blocks in the original file and including standard-block identifiers for the standard blocks in the recipe in lieu of the original blocks. Decoding involves an exchange with a standard-block identifier server system, which provides standard blocks in response to received standard-block identifiers.

Abstract: Instead of transferring a large original file from a source system to a target system, the original file is encoded to define a recipe. The recipe is then decoded to yield a duplicate of the original file on the target system. Encoding involves identifying standard blocks in the original file and including standard-block identifiers for the standard blocks in the recipe in lieu of the original blocks. Decoding involves an exchange with a standard-block identifier server system, which provides standard blocks in response to received standard-block identifiers.

Abstract: A constraint is inserted into a program to address a vulnerability of the program to attacks. The constraint includes a segment of code that determines when the program has been asked to execute a “corner case” which does not occur in normal operations. The constraint code can access a library of detector and remediator functions to detect various attacks and remediate against them. Optionally, the detector can be employed without the remediator for analysis. The context of the program can be saved and restored if necessary to continue operating after remediation is performed. The constraints can include descriptors, along with machine instructions or byte code, which indicate how the constraints are to be used.

Abstract: Protected software, such as an application and/or DLL, is monitored by protective software to guard against attacks, while distinguishing spurious, benign events from attacks. In a 1-touch approach, the protected software is monitored in a testing environment to detect spurious, benign events caused by, e.g., incompatibility or interoperability problems. The spurious events can be remediated in different ways, such as by applying a relaxed security policy. In a production mode, or 0-touch mode, when the protected software is subject to attacks, the corresponding remediation can be applied when the spurious events are again detected. Security events which occur in production mode can also be treated as benign when they occur within a specified time window. The applications and/or DLLs can further be classified according to whether they are known to have bad properties, known to be well-behaved, or unknown. Appropriate treatment is provided based on the classification.

Abstract: A constraint is inserted into a program to address a vulnerability of the program to attacks. The constraint includes a segment of code that determines when the program has been asked to execute a “corner case” which does not occur in normal operations. The constraint code can access a library of detector and remediator functions to detect various attacks and remediate against them. Optionally, the detector can be employed without the remediator for analysis. The context of the program can be saved and restored if necessary to continue operating after remediation is performed. The constraints can include descriptors, along with machine instructions or byte code, which indicate how the constraints are to be used.

Abstract: A constraint is inserted into a program to address a vulnerability of the program to attacks. The constraint includes a segment of code that determines when the program has been asked to execute a “corner case” which does not occur in normal operations. The constraint code can access a library of detector and remediator functions to detect various attacks and remediate against them. Optionally, the detector can be employed without the remediator for analysis. The context of the program can be saved and restored if necessary to continue operating after remediation is performed. The constraints can include descriptors, along with machine instructions or byte code, which indicate how the constraints are to be used.

Abstract: Hijacking of an application is prevented by securing execution of a computer program on a computing system. Prior to execution of the computer program, the computer program is analyzed to identify permitted targets of all indirect transfers. An application-specific policy based on the permitted targets is created. When the program is executed on the computing system, the application-specific policy is enforced such that the program is prohibited from executing indirect transfer instructions that do not target one of the permitted targets.

Abstract: A runtime code manipulation system is provided that supports code transformations on a program while it executes. The runtime code manipulation system uses code caching technology to provide efficient and comprehensive manipulation of an application running on an operating system and hardware. The code cache includes a system for automatically keeping the code cache at an appropriate size for the current working set of an application running.

Abstract: Protected software, such as an application and/or DLL, is monitored by protective software to guard against attacks, while distinguishing spurious, benign events from attacks. In a 1-touch approach, the protected software is monitored in a testing environment to detect spurious, benign events caused by, e.g., incompatibility or interoperability problems. The spurious events can be remediated in different ways, such as by applying a relaxed security policy. In a production mode, or 0-touch mode, when the protected software is subject to attacks, the corresponding remediation can be applied when the spurious events are again detected. Security events which occur in production mode can also be treated as benign when they occur within a specified time window. The applications and/or DLLs can further be classified according to whether they are known to have bad properties, known to be well-behaved, or unknown. Appropriate treatment is provided based on the classification.

Abstract: Protected software, such as an application and/or DLL, is monitored by protective software to guard against attacks, while distinguishing spurious, benign events from attacks. In a 1-touch approach, the protected software is monitored in a testing environment to detect spurious, benign events caused by, e.g., incompatibility or interoperability problems. The spurious events can be remediated in different ways, such as by applying a relaxed security policy. In a production mode, or 0-touch mode, when the protected software is subject to attacks, the corresponding remediation can be applied when the spurious events are again detected. Security events which occur in production mode can also be treated as benign when they occur within a specified time window. The applications and/or DLLs can further be classified according to whether they are known to have bad properties, known to be well-behaved, or unknown. Appropriate treatment is provided based on the classification.

Abstract: Instead of transferring a large original file, such as a virtual-machine image file, from a source system to a target system, the original file is encoded to define a recipe file that is transferred. The recipe is then decoded to yield a duplicate of the original file on the target system. Encoding involves identifying standard blocks in the original file and including standard-block identifiers for the standard blocks in the recipe in lieu of the original blocks. Decoding involves an exchange with a standard-block identifier server system, which provides standard blocks in response to received standard-block identifiers.

Abstract: Hijacking of an application is prevented by securing execution of a computer program on a computing system. Prior to execution of the computer program, the computer program is analyzed to identify permitted targets of all indirect transfers. An application-specific policy based on the permitted targets is created. When the program is executed on the computing system, the application-specific policy is enforced such that the program is prohibited from executing indirect transfer instructions that do not target one of the permitted targets.

Abstract: Hijacking of an application is prevented by monitoring control flow transfers during program execution in order to enforce a security policy. At least three basic techniques are used. The first technique, Restricted Code Origins (RCO), can restrict execution privileges on the basis of the origins of instruction executed. This distinction can ensure that malicious code masquerading as data is never executed, thwarting a large class of security attacks. The second technique, Restricted Control Transfers (RCT), can restrict control transfers based on instruction type, source, and target. The third technique, Un-Circumventable Sandboxing (UCS), guarantees that sandboxing checks around any program operation will never be bypassed.

Abstract: Hijacking of an application is prevented by monitoring control flow transfers during program execution in order to enforce a security policy. At least three basic techniques are used. The first technique, Restricted Code Origins (RCO), can restrict execution privileges on the basis of the origins of instruction executed. This distinction can ensure that malicious code masquerading as data is never executed, thwarting a large class of security attacks. The second technique, Restricted Control Transfers (RCT), can restrict control transfers based on instruction type, source, and target. The third technique, Un-Circumventable Sandboxing (UCS), guarantees that sandboxing checks around any program operation will never be bypassed.

Abstract: A runtime code manipulation system is provided that supports code transformations on a program while it executes. The runtime code manipulation system uses code caching technology to provide efficient and comprehensive manipulation of an application running on an operating system and hardware. The code cache includes a system for automatically keeping the code cache at an appropriate size for the current working set of an application running.

Abstract: A runtime code manipulation system is provided that supports code transformations on a program while it executes. The runtime code manipulation system uses code caching technology to provide efficient and comprehensive manipulation of an application running on an operating system and hardware. The code cache includes a system for automatically keeping the code cache at an appropriate size for the current working set of an application running.

Abstract: Hijacking of an application is prevented by monitoring control flow transfers during program execution in order to enforce a security policy. At least three basic techniques are used. The first technique, Restricted Code Origins (RCO), can restrict execution privileges on the basis of the origins of instruction executed. This distinction can ensure that malicious code masquerading as data is never executed, thwarting a large class of security attacks. The second technique, Restricted Control Transfers (RCT), can restrict control transfers based on instruction type, source, and target. The third technique, Un-Circumventable Sandboxing (UCS), guarantees that sandboxing checks around any program operation will never be bypassed.