Automated repair of binary and assembly programs for cooperating embedded devices

Abstract

We present a method for automatically repairing arbitrary software defects in embedded systems, which have limited memory, disk and CPU capacities, but exist in great numbers. We extend evolutionary computation (EC) algorithms that search for valid repairs at the source code level to assembly and ELF format binaries, compensating for limited system resources with several algorithmic innovations. Our method does not require access to the source code or build toolchain of the software under repair, does not require program instrumentation, specialized execution environments, or virtual machines, or prior knowledge of the bug type.We repair defects in ARM and x86 assembly as well as ELF binaries, observing decreases of 86% in memory and 95% in disk requirements, with 62% decrease in repair time, compared to similar source-level techniques. These advances allow repairs previously possible only with C source code to be applied to any ARM or x86 assembly or ELF executable. Efficiency gains are achieved by introducing stochastic fault localization, with much lower overhead than comparable deterministic methods, and low-level program representations.When distributed over multiple devices, our algorithm finds repairs faster than predicted by naïve parallelism. Four devices using our approach are five times more efficient than a single device because of our collaboration model. The algorithm is implemented on Nokia N900 smartphones, with inter-phone communication fitting in 900 bytes sent in 7 SMS text messages per device per repair on average.

Automating Patching of Vulnerable Open-Source Software Versions in Application Binaries

“…Axis [37] and AFix [25] focus on automatically fixing atomicity violations. Schulte et al [52][53][54] propose evolutionary algorithms to repair programs. GenProg [32] and Par [29] propose genetic-programming methods for patching.…”

Optimizing Tradeoffs of Non-Functional Properties in Software

“…As with any sampling-based approach, these techniques are subject to aliasing if the metric varies too rapidly relative to the sampling interval, as discussed in chapter 3. In these cases, the profile may be smoothed via convolution to distribute the recorded metric over nearby instructions [154]. However, certain metrics such as execution counts are not affected by the recording overhead, and may therefore be collected exactly.…”

“…Instead, we adopt a patch-based representation [166,167] in which genomes consist of list of transformations that, when applied to the original program, produce the desired variant. Similar to previous work [154,155], we implement three kinds of transformations to assembly programs: delete a line, swap two lines, and copy a line into a new location. The "target" of a transformation is the location of the line to be deleted, of either line to be swapped, or of the line after which a new line is to be copied.…”

“…to target optimization efforts on a particular region. Previous work on program repair has used profile information for fault localization [121,154], directing repair effort to regions associated with buggy behavior. We also use profiling, but instead use it to direct our search to transform regions associated with frequent execution, which are hopefully also associated with high energy use.…”

“…The files comprising an assembly program are transmuted into an executable by assembling them-that is, converting them into object code-and linking the object code into the executable. We refer to this process as building the program.Previous work applying search-based software engineering (SBSE) to assembly programs used a representation that very closely matches the assembly code itself[154]. However the sheer scale of many WSC applications-Kanev et al reported in 2015 that binaries running in Google's data centers frequently exceeded 100 MB[165]implementation.…”