Obfuscated integration of software protections

Abstract

To counter man-at-the-end attacks such as reverse engineering and tampering, software is often protected with techniques that require support modules to be linked into the application. It is well-known, however, that attackers can exploit the modular nature of applications and their protections to speed up the identification and comprehension process of the relevant code, the assets, and the applied protections. To counter that exploitation of modularity at different levels of granularity, the boundaries between the modules in the program need to be obfuscated. We propose to do so by combining three cross-boundary protection techniques that thwart the disassembly process and in particular the reconstruction of functions: code layout randomization, interprocedurally coupled opaque predicates, and code factoring with intraprocedural control flow idioms. By means of an elaborate experimental evaluation and an extensive sensitivity analysis on realistic use cases and state-of-the-art tools, we demonstrate our technique's potency and resilience to advanced attacks. All relevant code is publicly available online.

Flexible software protection

“…Van den Broeck et al proposed a third application of two-way OPs, namely to connect unrelated code fragments from different functions, with the goal of hampering disassemblers that partitioning the code into components such as functions [24]. They do this by merging control flow paths from different code contexts in different components, if possible in combination with outlining of equivalent fragments from those contexts.…”

“…Our proof of concept implementation applies the principles introduced in Section 2 to one-way predicates used to inject bogus control flow like Collberg's alias-based OPs and to the two-way opaque dispatchers proposed by Van den Broeck et al [24]. For the one-way predicates, we support flow-sensitive as well as flow-insensitive invariants in complex data structures.…”

“…Depending on the objective with which OPs are injected, OPs can be inherently susceptible to this form of attack. For example, in the work of Van den Broeck et al bogus control flow paths are inserted precisely to make disassemblers infer connections between code fragments that are actually not at all related, and thus to thwart the reconstruction of functions [24]. As the connected fragments are not related by construction, a certain lack of normal data dependencies is unavoidable.…”

“…We implemented support for one-way and two-way flexible OPs in Diablo, a post-link-time binary rewriting research tool [62] that already includes support for a range of other MATE protections including control flow obfuscations [61] and diversification [26]. We opted for Diablo because we can reuse the basic functionality for those protections, hence limiting the engineering effort for developing this proof-of-concept implementation.…”

Man-at-the-End Software Protection as a Risk Analysis Process

“…While potency, resilience, and stealth are commonly accepted criteria that should be evaluated [25], no standardized metrics are available for them. Complexity metrics originating from the field of software engineering have been proposed [18] and ad-hoc metrics are used in academic papers [54,71], but none have been empirically validated in the context of MATE SP, and none of them are trusted in practice, i.e., are deemed a sufficient replacement for human expertise and pen testing.…”