Abstract: Attempts to make code secure often are associated with performance penalties. To facilitate striking an acceptable balance between performance and security, vulnerable areas of source code are identified. The vulnerable areas are examined for areas that are actually safe and the safe areas are filtered from the universe of code that receives security mitigations. The remaining code receives security mitigations appropriate to the level of risk of the code.

Abstract: Attempts to make code secure often are associated with performance penalties. To facilitate striking an acceptable balance between performance and security, vulnerable areas of source code are identified. The vulnerable areas are examined for areas that are actually safe and the safe areas are filtered from the universe of code that receives security mitigations. The remaining code receives security mitigations appropriate to the level of risk of the code.

Abstract: Attempts to make code secure often are associated with performance penalties. To facilitate striking an acceptable balance between performance and security, vulnerable areas of source code are identified. The vulnerable areas are examined for areas that are actually safe and the safe areas are filtered from the universe of code that receives security mitigations. The remaining code receives security mitigations appropriate to the level of risk of the code.

Abstract: Attempts to make code secure often are associated with performance penalties. To facilitate striking an acceptable balance between performance and security, vulnerable areas of source code are identified. The vulnerable areas are examined for areas that are actually safe and the safe areas are filtered from the universe of code that receives security mitigations. The remaining code receives security mitigations appropriate to the level of risk of the code.

Abstract: Security mechanisms detect and intervene in a malicious attack against a runtime function, even in the presence of a coding flaw such as a buffer overrun or overflow. One such exemplary mechanism uses a predetermined security list of the valid targets for a first runtime function (such as longjmp). For every call to a second runtime function (e.g., setjmp) that prepares for a later invocation of the first runtime function, the dispatcher finds and stores a reference to this list. When a subsequent attack targets the runtime functions by creating an attacker-provided setjmp target address (e.g., the attack overwrites the longjmp target address so that the pointer points somewhere else, such as code provided by the attacker or code that already exists that will eventually pass control to code provided by the attacker), the new (attacker provided) target address is compared to a reference list of the real (valid) target addresses. The list of real target addresses is stored in memory.

Abstract: Safe exceptions detect and intervene in a malicious attack against an application or system component, even in the presence of a coding flaw such as a buffer overrun. A list of all the exception handlers in an image (e.g., a DLL or EXE) is desirably created. When loading the image into a process, the operating system loader finds and stores a reference to this list. When a subsequent attack targets exception handling by creating an attacker provided exception handler, the new attacker provided exception handler is compared to a list of the real exception handlers. The list of real exception handlers is stored in memory, and desirably cannot be modified. In particular, when an exception occurs, the operating system finds the proper exception handler from information on the stack (this may be under attack, so the information is not trusted) and compares it to the previously created read-only reference list.

Abstract: This present invention extends the mechanism for locating solution access information and then obtaining and implementing the correct solution for updating software programs. The user can communicate with one system on the network, tell it what the user is interested in, and then the system replies on a file by file basis where to locate the desired information. Thus, the user no longer has to register, e.g. in the environment variables, the individual paths for where a multitude of different applications find their additional related information on the network. According to the teachings of the present invention, a user will have to make basically zero changes to the system, and instead will automatically discover the name location of a server that is going to provide the user with the information associated with any user executable file. In particular, one embodiment of the present invention includes a computer implemented method.

Abstract: An annotation source representation is supported by a compiler and/or linker to annotate program code, so that analysis tools, such as debuggers and profilers, have more information with which to analyze an executable program. The annotation source representation in the source code is compiled into annotation information so that the annotation remains in the executable code, but is not executed. The annotation information in the executable program is associated with the code that the annotation function is associated with. The present invention eliminates the need of parallel/companion input command files, eliminates the need of compiling a special version of the executable program for purposes of analysis, and eliminates the need of implementing debug statements in the source code.

Abstract: Safe exceptions detect and intervene in a malicious attack against an application or system component, even in the presence of a coding flaw such as a buffer overrun. A list of all the exception handlers in an image (e.g., a DLL or EXE) is desirably created. When loading the image into a process, the operating system loader finds and stores a reference to this list. When a subsequent attack targets exception handling by creating an attacker provided exception handler, the new attacker provided exception handler is compared to a list of the real exception handlers. The list of real exception handlers is stored in memory, and desirably cannot be modified. In particular, when an exception occurs, the operating system finds the proper exception handler from information on the stack (this may be under attack, so the information is not trusted) and compares it to the previously created read-only reference list.

Abstract: A data compressor uses data known to exist on a destination computer for compressing an input data stream by encoding portions of the input data stream as references to matching portions of the known data. The known data is preprocessed to better correlate with the input data stream. The preprocessing includes identifying and modifying internal references in the known data, such as relative offsets and addresses of jump and call instructions in executable code or cross references and hyperlinks in documents. The preprocessing is driven by generating a set of data that describes specific individual modifications or alternatively indicates relationships between the known data and the input data stream, such as code or data block motion, from which individual modifications can be deterministically made.