Every IoT and embedded device manufacturer – the company says – tries to achieve secure and safe products, “Even with the robust development processes, it's difficult to ensure complete security in finished products [and] more so in legacy products. As the ever-expanding IoT marketplace puts a bigger emphasis on embedded device security, better techniques are required to improve security.”
Analyzing application binaries allows GrammaTech's rewriting tools to discover the use of potentially problematic code patterns, libraries, or OS functions. The rewritten binaries have wrappers around such code to prevent erroneous behaviour. For example, function call stack usage can be instrumented to prevent stack overflow and subsequent code injection. Another example would be preventing calls to known problematic library functions such as strcpy() from causing buffer overflow errors.
Rewriting a binary executable into a robust hardened version provides quality and security assurance for any version of the application -- current and future versions are protected. GrammaTech's hardening tools static rewrite binaries into more robust and secure applications.
Binary rewriting techniques comprise confinement and diversification. The goal of confinement is to prevent undetected vulnerabilities from causing a failure in an executing application. Techniques to detect and prevent certain specific classes of vulnerabilities already exist to some extent, but often lead to a program failure state - which, in turn, leads to a denial of service. Although an attack might be prevented, these consequences are unacceptable in critical systems. GrammaTech has been researching sophisticated confinement techniques that allow applications to detect the same kinds of attacks, but continue operation (while still containing the vulnerability). Combining binary analysis to detect the potential vulnerability with static rewriting to confine the exploit, it's possible to greatly reduce and even eliminate the impact.
Diversification techniques are used to alter the default code and memory layout to prevent potential exploits. By rearranging the subroutine calling sequence, stack, heap, and global data layout, it's possible