Binary stirring: self-randomizing instruction addresses of legacy x86 binary code

By Richard Wartell, Vishwath Mohan, Kevin W. Hamlen, Zhiqiang Lin. Conference on Computer and Communications Security, 2012

393 citations recorded by the source corpus.

Subfields: Artificial Intelligence, Computer Networks and Communications, Signal Processing

View Paper: https://www.semanticscholar.org/paper/ff07ea112db58dc351dbebd15c203d81e08cfecc

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

In Artificial Intelligence

In Computer Networks and Communications

In Signal Processing

Citations in the corpus

Control Flow Integrity for COTS Binaries (2013, background): “Binary Stirring (STIR) [43] solves this issue by randomizing basic blocks at load time using static rewriting.”
Out of Control: Overcoming Control-Flow Integrity (2014, background): “As a result, many proposals where introduced for fine grained randomization in executables by applying in-place randomization [39], breaking the linearity of the address-space [40], or shuffling the basic code blocks of a program [41].”
The Cybersecurity Landscape in Industrial Control Systems (2016, background): “The underlying idea is to randomize the code structure, for instance, by shuffling functions, basic blocks, or instructions (ideally for each program run [117], [118]).”
SoK: Automated Software Diversity (2014, background): “It is frequently argued that binary rewriting is preferable to compilerbased methods because the latter require source code access, custom compilers, and require changes to current program distribution mechanisms [67], [64], [29], [47].”
SGX-Shield: Enabling Address Space Layout Randomization for SGX Programs (2017, methodology): “many fine-grained ASLR techniques [13, 23, 24, 32, 45, 59] claim that randomizing the code in various fine-grained units (e.”
Software Grand Exposure: SGX Cache Attacks Are Practical (2017, background): “ge bugs (e.g., [57]). These attacks motivated further development of more ﬁne-grained memory randomization forms, which randomize application binaries at granularity of functions [37], basic blocks12 [73, 15] and even single instructions [53, 25]. Fine-grained memory randomization techniques was und”
Practical Control Flow Integrity and Randomization for Binary Executables (2013, background): “Compared with other protections, such as [13][49], CCFIR is capable of protecting all binaries in the SPEC 2000/2006 benchmarks, with a reasonable overhead.”
Jump over ASLR: Attacking branch predictors to bypass ASLR (2016, background): “These schemes enforce the enhanced randomization at different levels, such as at the level of functions [31], basic blocks [48] or instructions [49], [50].”
Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, methodology): “We elaborate on these techniques later (in §VI), but for now it is sufficient to note that the underlying idea in these works is to randomize the data and code structure, for instance, by shuffling functions or basic blocks (ideally for each program run [62]).”
ROP is Still Dangerous: Breaking Modern Defenses (2014, background): “Other defenses extends this further by randomizing the addresses of individual instructions [15, 31].”
ROPecker: A Generic and Practical Approach For Defending Against ROP Attacks (2014, background): “Available at: https://ink.library.smu.edu.sg/sis_research/1973 This Conference Proceeding Article is brought to you for free and open access by the School of Information Systems at Institutional Knowledge at Singapore Management University.”
Hacking Blind (2014, background): “There are solutions that propose adding randomness to binaries [24].”
SoK: Eternal War in Memory (2013, background): “Self-Transforming Instruction Relocation (STIR) [46] randomly re-orders the basic blocks of a binary at launch-time.”
Counterfeit Object-oriented Programming: On the Difficulty of Preventing Code Reuse Attacks in C++ Applications (2015, background): “In general, one can distinguish between two phases of a runtime exploit: (1) the exploitation of a memory corruption vulnerability initially allowing the adversary to hijack the control flow of an application, and (2) the actual adversary-chosen malicious computations and program actions that…”