Program differentiation

Abstract

Mobile electronics are undergoing a convergence of formerly multiple dedicated-application devices into a single programmable device -the smart phone. The programmability of these devices increases their vulnerability to malicious attack. In this paper, we propose a new malware management system that seeks to use program differentiation to reduce the propagation of malware when a software vulnerability exists. By modifying aspects of the application control flow, we allow portions of an application executable to be permuted into unique versions for each distributed instance. Differentiation is achieved using hardware and systems software modifications that are amenable to and scalable in embedded systems. Our initial areas for modification include function call/return and system call semantics, as well as a hardware-supported Instruction Register File. Differentiation of executables hinders analysis for vulnerabilities as well as prevents vulnerability exploitation in a single distributed version from propagating to other instances of that application. Computational demands on any instance of the application are minimized, while the resources required to attack multiple systems grows with the number of systems attacked. By focusing on prevention of malware propagation in addition to traditional absolute defenses, we target the economics of malware in order to make attacks prohibitively expensive and infeasible.

Design and implementation of instruction indirection for embedded software obfuscation

“…In addition to the reduction of code length, the IRF can provide randomization of a subset of the instructions [15] . It is possible to protect software from analysis by arbitrarily shuffling the mapping from indices to IRF instructions.…”

“…If the goal of the IRF is tamper resistance, it might be a bad idea to simply put the most frequent instructions in it. Unfortunately, the evaluation of these risks was not presented in [15] .…”

“…In the selection of IRF instructions, the original IRF proposal [13,15] considered only how many instructions are replaced with IRF references. However, as we have explained in Section 2 , the cost of frequency analysis should also be considered, which is quantified by the flatness of the distribution of IRF indices.…”

“…It is referred by an index in fetched instructions. Though it initially aimed at reducing power consumption by packing multiple instructions into a single one [13] , it also has resistance to tampering [15] . It is based on the fact that a reference to the IRF is considered as another expression of the instruction, which is incomprehensible as long as the contents of the IRF are hidden.…”

“…Some routines may not be obfuscated enough by the lack of references to the IRF. Such risks was not evaluated in [15] , although the code reduction and the execution time with the IRF were measured as its side effects . This paper examines the effectiveness of the IRF against tampering, particularly reverse engineering.…”