How to build a custom and distributable lldb

Almost two years ago (when covid was just starting and we all happily ignored it) I wrote a post about implementing x86 hardware breakpoints in lldb. This critical debugger feature was missing from lldb. Probably because lldb main users are developers and not serious reverse engineers (lol!) dealing with malicious code and/or just reversing/cracking hostile software protections (cracking is the best and most fun RE target practice).

The build process described in that post worked but I wasn’t very happy with it - not easily portable between macOS systems. Some time ago I tried to fix it but I gave up since I wasn’t in the mood to deal with build systems problems.

[Read More]

How to make LLDB a real debugger

These days the de facto debugger in macOS is LLDB. Apple’s old gdb fork doesn’t work anymore and the GNU gdb version is better these days but still quite meh (in the past it couldn’t deal with fat binary targets and I still think this holds true). So we are all essentially stuck with LLDB, warts and all. I also hate the lack of a gdbinit style output but Deroko started that project and I improved it with lldbinit.

Besides its horrible long command line syntax which is so unpopular that gdb-compatible commands were introduced, my biggest problem with it has been the lack of x86 hardware breakpoint support. While hardware breakpoints might not be needed to debug applications within Xcode, they are essential to any serious reverse engineer dealing with arbitrary untrusted targets such as malware, packers, obfuscators, and DRM. It has been a serious blocker for me against some targets and a source of immense frustration because it should be a basic debugger feature.

Last week I finally got fed up enough to dive into the LLDB C++ codebase and finally try to implement this feature. Instead of just posting a patch, this post is a journey into LLDB internals and how I implemented this feature. Hopefully it will help others exploring the LLDB codebase, which seems unfriendly because of the lack of really good documentation into its architecture. Maybe this could lead to further improvements and make LLDB more reverse engineer friendly.

[Read More]

Crafting an EFI Emulator and Interactive Debugger

In 2016 I reversed Apple’s EFI firmware password reset scheme using SCBO files. There was an old rumor that these files were able to unlock firmware password locked Macs (and even a sketchy video about a universal SCBO able to unlock any Mac). That post is available at Apple EFI firmware passwords and the SCBO myth.

All the interesting computing action happened at the EFI execution level. I made good reversing progress with static analysis, but dynamic analysis with a debugger would make the job much easier. I love debuggers because they allow you to quickly test ideas and cut corners while reversing a target. Reading disassembly listings for long periods is tiring. (U)EFI debuggers can be found in the market but they are usually quite expensive (a couple thousand USD).

My solution was to create an emulator and debugger based on Unicorn. At the time I was working a lot with Unicorn so it was natural to use it to solve this problem (“if all you have is a hammer, everything looks like a nail”). After I wrote the blogpost some people directed me to some emulators (TianoCore EmulatorPkg and efiperun). I never tried them to see if they contained an interactive debugger like I wanted. The pain wasn’t big since this was a couple of days project and it was quite fun to write.

[Read More]

lldbinit - Improving LLDB

Many years ago I had to use gdb for the first time and I absolutely hated it. At the time I was reversing (cof cof cof) Windows apps so SoftIce and friends were my favorite tools. Compared to these gdb was a complete trash, mostly because the naked gdb lacks a nice context display. I like to know what the hell is going around each time I step in the debugger, without having to type a bunch of commands for it. Then I discovered the original gdbinit by +mammon and life with gdb was a bit easier.

[Read More]

How to compile AFL's LLVM mode in OS X

American fuzzy lop aka AFL is one of the easiest and best fuzzers out there and should be part of your development cycle if you care at least one bit about the security of your code.

Its performance in OS X is a bit of a let down because of issues at fork() system call. AFL warns you about this when compiling it:

WARNING: Fuzzing on MacOS X is slow because of the unusually high overhead of fork() on this OS. Consider using Linux or *BSD. You can also use VirtualBox (virtualbox.org) to put AFL inside a Linux or *BSD VM.

[Read More]

Armory Sandbox – Building a USB analyzer with USB armory

Some time ago a friend received a mysterious USB pen with a note talking about some kind of heavily persistent malware. He had that USB pen stored untouched and of course my curiosity took over. Since one should never plug in unknown USB devices into a computer (well, any USB device we purchase is unknown but that is another story) and I didn’t want to “burn” a computer just to take a look at the contents I decided to use my USB armory to build an air gap sandbox that would be harder to infect and for malware to escape from it.

[Read More]

Gatekeerper – A kernel extension to mitigate Gatekeeper bypasses

Last month Patrick Wardle presented Exposing Gatekeeper at VB2015 Prague. The core of the presentation deals with Gatekeeper bypasses originating in the fact that Gatekeeper only verifies the code signatures of the main binary and not of any linked libraries/frameworks/bundles. This means it is possible to run unsigned code using dynamic library hijacking techniques also presented by Patrick in code that should be protected by Gatekeeper. His exploit uses an Apple code signed application that is vulnerable to dylib hijacking and is modified to run unsigned code when downloaded from the Internet. [Read More]

Rootfool – a small tool to dynamically disable and enable SIP in El Capitan

El Capitan is finally released and System Integrity Protection aka SIP aka rootless is finally a reality we must face. Let me briefly describe SIP (technical details maybe in another post, now that El Capitan is final and out of NDAs). This post by Rich Trouton contains a very good description of its userland implementation and configuration. What is SIP anyway? The description that I like to use is that SIP is a giant system-wide sandbox, that controls access to what Apple considers critical files and folders. [Read More]

Can I SUID: a TrustedBSD policy module to control suid binaries execution

Let me present you another TrustedBSD policy module, this time to control execution of suid enabled binaries. The idea to create this started with nemo’s exploitation of bash’s shellshock bug and VMware Fusion. It was an easy local privilege escalation because there are many Fusion suid enabled binaries. This got me thinking that I want to know when this kind of binaries are executed and if possible control access to them. [Read More]