Instruction punning: lightweight instrumentation for x86-64

Chamith, Buddhika; Svensson, Bo Joel; Dalessandro, Luke; Newton, Ryan

doi:10.1145/3062341.3062344

Cited by 11 publications

(4 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In our case, this can be detected by the Intel Processor Tracing (PT) runtime disassembly. In other cases, techniques such as instruction punning [15] or even plain breakpoints might be used to avoid introducing unexpected crashes. However, it should be noted that even in relatively large target programs, we did not observe any such behavior, as the number of patched instructions is low (i.e., typically less than 5 in our empirical evaluation).…”

Section: Instruction Patchingmentioning

confidence: 99%

REDQUEEN: Fuzzing with Input-to-State Correspondence

Aschermann¹,

Schumilo²,

Blazytko³

et al. 2019

Proceedings 2019 Network and Distributed System Security Symposium

199

191

View full text Add to dashboard Cite

Automated software testing based on fuzzing has experienced a revival in recent years. Especially feedback-driven fuzzing has become well-known for its ability to efficiently perform randomized testing with limited input corpora. Despite a lot of progress, two common problems are magic numbers and (nested) checksums. Computationally expensive methods such as taint tracking and symbolic execution are typically used to overcome such roadblocks. Unfortunately, such methods often require access to source code, a rather precise description of the environment (e.g., behavior of library calls or the underlying OS), or the exact semantics of the platform's instruction set. In this paper, we introduce a lightweight, yet very effective alternative to taint tracking and symbolic execution to facilitate and optimize state-of-the-art feedback fuzzing that easily scales to large binary applications and unknown environments. We observe that during the execution of a given program, parts of the input often end up directly (i.e., nearly unmodified) in the program state. This input-to-state correspondence can be exploited to create a robust method to overcome common fuzzing roadblocks in a highly effective and efficient manner. Our prototype implementation, called REDQUEEN, is able to solve magic bytes and (nested) checksum tests automatically for a given binary executable. Additionally, we show that our techniques outperform various state-of-the-art tools on a wide variety of targets across different privilege levels (kernel-space and userland) with no platform-specific code. REDQUEEN is the first method to find more than 100% of the bugs planted in LAVA-M across all targets. Furthermore, we were able to discover 65 new bugs and obtained 16 CVEs in multiple programs and OS kernel drivers. Finally, our evaluation demonstrates that REDQUEEN is fast, widely applicable and outperforms concurrent approaches by up to three orders of magnitude.

show abstract

Section: Instruction Patchingmentioning

confidence: 99%

REDQUEEN: Fuzzing with Input-to-State Correspondence

Aschermann¹,

Schumilo²,

Blazytko³

et al. 2019

Proceedings 2019 Network and Distributed System Security Symposium

199

191

View full text Add to dashboard Cite

show abstract

“…the loader itself and libraries that come before syscall_intercept in .init and .preinit. [11] is an instructionpunning framework for x86-64. LiteInst also suffers from some important limitations.…”

Section: Comparison With Syscall_interceptmentioning

confidence: 99%

“…As regards dynamic binary rewriting, i.e. modifying instructions at runtime, the most prominent tools include: SecondWrite [18], Dyninst (dynamic) [7], DynamoRIO [6], Pin [38], MAMBO [22], ADORE [37] and LiteInst [11]. SecondWrite performs rewriting on LLVM bitcode, which is costly to do dynamically due to the binary lifting process.…”

Section: Related Workmentioning

confidence: 99%

“…SecondWrite performs rewriting on LLVM bitcode, which is costly to do dynamically due to the binary lifting process. Dyninst relies on a separate process and ptrace 11 to achieve this at runtime, which incurs a high overhead in both space and time. DynamoRIO and Pin have been reported to impose runtime penalties of at least 20% and 54%, respectively [39], just to maintain supervised execution, without any additional instrumentation, while SaBRe's overhead on the identity plugin is less than 3% (see Sect.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

SaBRe: load-time selective binary rewriting

Arras

Andronidis

Pina

et al. 2022

Int J Softw Tools Technol Transfer

View full text Add to dashboard Cite

Binary rewriting consists in disassembling a program to modify its instructions. However, existing solutions suffer from shortcomings in terms of soundness and performance. We present SaBRe, a load-time system for selective binary rewriting. SaBRe rewrites specific constructs—particularly system calls and functions—when the program is loaded into memory, and intercepts them using plugins through a simple API. We also discuss the theoretical underpinnings of disassembling and rewriting. We developed two backends—for and —which were used to implement three plugins: a fast system call tracer, a multi-version executor, and a fault injector. Our evaluation shows that SaBRe imposes little overhead, typically below 3%.

show abstract