Welcome!

Flare-On 2024 is gone and I just made a presentation about the challenge #5 at the local meetup called 0xOpoSec. I think it’s a nice challenge to introduce a few RE and forensics concepts, and a perfect candidate to present this year. The slides are available here, and the Unicorn Engine emulator I used to extract the flag from the final shellcode here. Last year I did the same with challenge #12, also with a Unicorn Engine emulator....

I apologize if this information is already known, but I couldn’t find any references about it and I wanted to understand what was going on and share with you because I think there is some value doing it. In case this wasn’t known, I apologize to the Go team for not talking to them first and jumping the full disclosure gun (I don’t think it’s that severe). I really like Go!...

Note: the original post was written in 2017 when there weren’t many posts discussing direct attacks to firmware flash. It also took a while to get in touch with the ISP to give them a chance to fix some of the issues described (in particular the ACS access) and then it was left in draft mode until today. I just made a quick revision and fixed quite a few dead links....

Back in 2017 (feels like ages ago) I decided to take a peek into the ShadowBrokers leaks and reverse some of the tools. I started on dewdrop simply because it had a macOS version. I made local presentations at 0xOpoSec and BSidesLisbon but those slides were never published for obvious reasons (aka live implants all over the Internet). Significant time has passed and everyone went crazy last week with the beautiful NSO exploit VM published by Project Zero, so why not ride the wave and present a simple NSA BPF VM. It is still an interesting work and you have to admire the great engineering that goes behind this code. It’s not everyday that you can take a peek at code developed by a well funded state actor. This post is only going to focus on the BPF part of the implant so you will have to fill in the blanks about everything else. ...

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