Systems and methods of cyber hardening software by modifying one or more assembly source files. In some embodiments, the disclosed SME tool transparently and seamlessly integrates into the build process of the assembly source files being modified. For example, upon integration of the disclosed SME tool into the application's development environment, the modifications in the final executable are transparent to the developer and can support other cyber hardening techniques. The SME tool includes a preprocessing tool for identifying attributes (e.g., functions) associated with the assembly source file. The SME tool also includes a transformation tool for making modifications of the assembly source file. In some embodiments, the transformations correspond to applying one or more transformations to the attributes associated with the assembly source file.

A method, system and product comprising determining a characterization of a terminal of a plurality of terminals within a binary code based on influences of the terminal, wherein the characterization of the terminal indicates a role of the terminal in the binary code; based on the characterization of the terminal, determining that the terminal is potentially affected by external input that is inputted to a device executing the binary code; determining for the terminal a corresponding propagation path within the binary code, wherein the propagation path indicates a reachability of the terminal within the binary code; locating in the binary code a code patch associated with a functionality of the binary code, wherein the code patch is associated with the propagation path of the terminal, wherein the code patch can be executed independently from the binary code; extracting the code patch from the binary code for testing; and generating an emulation of the code patch to enable fuzz testing of the emulation, whereby the code patch is tested independently.

A method, system and product comprising determining a characterization of a terminal of a plurality of terminals within a binary code based on influences of the terminal, wherein the characterization of the terminal indicates a role of the terminal in the binary code; based on the characterization of the terminal, determining that the terminal is potentially affected by external input that is inputted to a device executing the binary code; determining for the terminal a corresponding propagation path within the binary code, wherein the propagation path indicates a reachability of the terminal within the binary code; locating in the binary code a code patch associated with a functionality of the binary code, wherein the code patch is associated with the propagation path of the terminal, wherein the code patch can be executed independently from the binary code; extracting the code patch from the binary code for testing; and generating an emulation of the code patch to enable fuzz testing of the emulation, whereby the code patch is tested independently.

One embodiment comprises a stateless container of binaries and a broker. The stateless container of binaries includes a code memory having stored thereon code for a first version of a first functional component of a content management system, the first functional component executable to provide a first version of a service. The broker may be executable to: receive a request for the service from a client application, the request associated with a user of the content management system; determine that the first version of the service is accessible with regard to the user; determine an available first server that hosts the first version of the service; provide an indication of the first version of the service to the client application; and provide an IP address and a port number associated with the available first server to the client application.

One embodiment comprises a stateless container of binaries and a broker. The stateless container of binaries includes a code memory having stored thereon code for a first version of a first functional component of a content management system, the first functional component executable to provide a first version of a service. The broker may be executable to: receive a request for the service from a client application, the request associated with a user of the content management system; determine that the first version of the service is accessible with regard to the user; determine an available first server that hosts the first version of the service; provide an indication of the first version of the service to the client application; and provide an IP address and a port number associated with the available first server to the client application.

According to some illustrative embodiments of the invention, a method is performed that includes using a representation of a computer software program, using identified addresses which correspond to a part of the representation, and converting the representation into a created binary program, which includes reserving spaces at the identified addresses in the created binary program's address space at the same addresses as the identified addresses in the representation.

The present disclosure is directed to a system for on-demand binary translation state map generation. Instead of interpreting the native code to be executed, binary translation circuitry (BT circuitry) may execute a binary translation (BT) in place of the native code. When a stop occurs (e.g., due to an interrupt, a modification of the native code, etc.), the BT circuitry may generate a binary translation state map (BT state map) that allows the location of the stop to be mapped back to the native code. Generation of the BT state map may involve determining a location and offset for the stop, performing region formation based on the location, loading instructions from the region (e.g., while accounting for the need to emulate instructions), forming the BT state map based at least on the size of the loaded instructions, and then mapping the stop back to the native code utilizing the offset.

A method includes translating at least one application source code file associated with a legacy controller in a distributed control system to instructions executable by a controller simulation computing device, wherein the legacy controller is associated with a legacy operating system and the controller simulation computing device is associated with a second operating system different from the legacy operating system. The method also includes simulating operation of the legacy controller using the instructions and an emulation of the legacy operating system in the controller simulation computing device. The method further includes determining configuration data for the legacy controller during the simulated operation of the legacy controller. In addition, the method includes saving the configuration data to a configuration data file.

A method includes receiving at least one source code file associated with a legacy hardware platform, the at least one source code file being part of a software migration from the legacy hardware platform to a target hardware platform. The method also includes identifying one or more absolute memory addresses of the legacy hardware platform included in the at least one source code file. The method further includes for each of the one or more absolute memory addresses, including an address remapping function in an assembly language instruction block associated with the target hardware platform.

A sequence of input language (IL) instructions of a guest system is converted, for example by binary translation, into a corresponding sequence of output language (OL) instructions of a host system, which executes the OL instructions. In order to determine the return address after any IL call to a subroutine at a target entry address P, the corresponding OL return address is stored in an array at a location determined by an index calculated as a function of P. After completion of execution of the OL translation of the IL subroutine, execution is transferred to the address stored in the array at the location where the OL return address was previously stored. A confirm instruction block is included in each OL call site to determine whether the transfer was to the correct or incorrect call site, and a back-up routine is included to handle the cases of incorrect call sites.