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. ...

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. ...

Passwords are a modern annoyance and their diversity is something you can’t avoid if you want a minimum amount of account security (don’t forget to turn on those 2FA options, avoiding SMS versions if possible). They get more annoying when you set a super smart new password with that smug feeling that it is such a great password that you will never forget about it (or something crappy you set in a rush). Usually you can’t remember it already in the next day or in the next week, since in a month it is totally wiped out from your memory. This time my victim was Carbon Copy Cloner (CCC). When you generate a backup you can select an encrypted sparse bundle (disk image) as destination, and save its password in the application private keychain. ...

I was bored this weekend and decided to take some rust out of my reversing skills before they disappear for good. I have spent the past two years or so mostly writing C code (secure C is more like an asymptote but that is why it is a fun challenge) and barely doing any serious reverse engineering and security research. So I decided to revisit some unfinished business with qwertyoruiop’s crackme. I had a look when he originally sent it but got distracted with something else at the time and never finished it. I couldn’t find any public write-up about it so I decided to write one. It is mostly targeted to newcomers to reverse engineering and macOS. You can click the pictures to see the full size version. ...

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. ...