Welcome!

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

For quite some time I have wanted to build a site where I could share links to the stuff I read online. There must be already plenty of sites to solve this but none satisfies my main requisite: to be under my full control. I rather do all the work myself than giving up control to a third-party that can lock me down for any reason (Twitter for example). It’s a price that I am willing to pay. One of the main obstacles to build the site was that I needed to add/edit information from my desktop and tablet. I am definitely not a cloud fan so using it to sync between devices was out of question (people do it with Evernote, etc). For a while I thought about developing a mobile or web application to achieve this but was too lazy for that. Last weekend the right idea popped in my mind (I think I was reading something about the topic). I could use GitHub to store the data that I need to edit between devices, and GitHub actions to automate the build process. GitHub allows unlimited private repositories to free users, and the data to store there isn’t critical. I would always have a local copy and if GitHub bans me the impact is meaningless - they are just an intermediary and both ends are controlled by me. ...