Zion Leonahenahe Basque
PhD Student in Hacking (Computer Science) at Arizona State University
Actions
Zion Leonahenahe Basque is a Ph.D. student at Arizona State University studying Computer Science with a focus on Systems Security. He hacks online by the handle of mahaloz and is proudly Native Hawaiian. He is a co-captain of the competitive hacking (CTF) team Shellphish and was a previous president of the local ASU Hacking Club.
He does research with the computer security lab SEFCOM at ASU under Dr. Fish Wang and Dr. Yan Shoshitaishvili in decompilation and binary analysis. When he’s not CTFing or researching, he can be found hacking away at new reverse-engineering tools.
Area of Expertise
Topics
Buccaneers of the Binary: Plundering Compiler Optimizations for Decompilation Treasure
From fixing a smart oven to exploiting a pesky drone, reverse engineers have long understood that the world is run by binaries. As such, decompilers, which turn binaries into source-like code, have become a cornerstone tool of the reversing community. Decompilers like IDA Pro, Ghidra, and Binja are hailed as our saviors from the verbose land of assembly.
Despite the accolades we bestow upon our favorite decompilers, we've all encountered the frustration of lousy decompilation. We've wrestled with a series of broken if-statements that stubbornly refuse to become a Switch. We've navigated through a maze of gotos that create an unnecessary spaghetti of code. And we've scratched our heads at code that just seems off—maybe duplicated? Maybe it is non-existent in the source? Regardless, something is wrong.
So what do all these problems have in common? Surprisingly, they aren't just buggy decompilers. They are fundamental flaws in the way we deal with compiler optimizations. Interestingly, not all compiler optimizations are equally destructive, and many can be reversed!
In our USENIX 2024 work, SAILR [1], we not only measured the destructiveness of each compiler optimization but also pioneered techniques to reverse their effects. These cutting-edge algorithms are now implemented in the new angr decompiler, an open-source decompiler made by the hackademics of Shellphish.
In this talk, we will take a deep dive into the rocky seas that are compiler optimizations. We will explore the worst optimizations for your decompiler, with examples, and how you might reverse them, with demos. Finally, we'll talk about what we learned in the process and how we think compiler optimizations will play a future role in decompilers.
[1]: Basque, Zion Leonahenahe, et al. "Ahoy SAILR! There is no need to DREAM of C: A compiler-aware structuring algorithm for binary decompilation." 33st USENIX Security Symposium (USENIX Security 24). 2024.
Bridging the gap in the static and dynamic analysis of binaries through decompiler tomfoolery!
In the modern day, the use of IoT devices in various applications has created a surge of programs that hackers have trouble understanding: binary services and firmware. The programs that run these IoT devices are binaries–compiled programs that lack accompanying source code. Without source code, hackers are forced to reverse-engineer these binaries. To make matters worse, these binaries are usually compiled with optimizations, stripped of symbols, and statically linked to make debugging arduous. Without the ability to reverse and understand these programs, hackers are at the whims of the manufacturers for bug fixes, 0day patching, and overall compatibility.
Lucky for us, decompilers, like the freely available Ghidra, have made understanding binaries statically (without running it) more accessible. Hackers reverse engineer binaries through decompilation and recover Reverse Engineering Artifacts (REAs). These REAs can be anything from the name of functions to the typing of custom structs found in stack frames. Unfortunately, dynamic analysis done through modern debuggers like gdb have not been able to benefit from hackers' efforts in decompilation. Currently, a debugger like gdb only allows you to view the symbols originally in the binary. This also means the hacker is forced to look at assembly instead of decompilation. The effort exerted in static analyses is lost while using debugging tools.
In this talk, we present a novel tool to bridge the gap between static and dynamic analysis called decomp2dbg (d2d). d2d is a bridge software that communicates between the debugger (gdb) and the decompiler (Ghidra) on-the-fly. As the user changes symbols, types, and structs in their decompiler, they are instantly imported into their debugger. This synchronization is accomplished natively through hacks to the gdb ELF-symbol loading system and by lifting decompiler-specific types into C-code. d2d also helps the user understand code context by mapping a pseudo-source view from the decompiler into the debugger. In effect, the user has nearly the same debugging capabilities that she would have if she had source. d2d supports most modern decompilers (IDA, Ghidra, Binja) and exposes a simple Python API to make support in more debuggers accessible. The source code can be found at: https://github.com/mahaloz/decomp2dbg.
We start this talk by giving a brief overview of developments in the static and dynamic analysis of binaries. Next, we take a deep dive into the ELF-symbol loading system and explore how we can encode new symbols into ELFs in gdb. We use that knowledge to automatically rip symbols out of the decompiler and place them in the debugger. Finally, we do a demo using decomp2dbg (with Ghidra and gdb) to reverse-engineer a closed-source binary found on an embedded device. At the end of this talk, participants should have an overview understanding of binary analysis.
RE//verse 2025 Sessionize Event
CactusCon 11 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top