I added a Raspberry Pi 4B recently in my ever expanding homelab. To get the best network with the new gigabit ethernet port on the raspi, and still save power, I added a PoE hat to it so I could power the raspi as well as provide it data through the ethernet port. Everything worked fine except that I ocassionaly got into situations where the raspi stopped responding suddenly. Initially I thought that it’s crashing due to some issues and used to just restart it manually. I tried switching from manjaro-arm to raspbian as well but that showed same symptoms, despite updating to the latest bootloader and firmware as well. Then I noticed that I could hear the fans on the PoE hat whirring up and settling down even when the raspi was inaccessible. This put me in a doubt that the raspi hasn’t actually crashed, because the fans whir up and go down according to the CPU temperature. So this pattern meant that the CPU was still doing something to heat it up. A trip to the kernel logs via journalctl -xe confirmed the doubt and also showed a few weird messages about the ethernet.

Until Now - The State of the union

This blog is generated using hugo, an awesome static site generator. So far, the workflow I used to deploy it was:

• Push commit to the source repository on GitLab
• GitLab CI kicks off on receiving the push
  • CI downloads latest version of hugo and generates the static site
  • Runs aws-cli to sync the new files to AWS S3
• S3 serves the static site
• Cloudflare provides:
  • DNS services (so I can use https://shantanugoel.com without having to prefix it with a www)
  • CDN/Caching services for resilience and keeping S3 bills low for data transfer

Why? What broke the camel’s back

I was mostly happy with this setup with a couple of niggles at the back of my mind, vis. a vis.:

Bazel

Came across bazel build system recently at my new job and found it to be quite nice compared to my earlier mainstays CMake and Make. It’s fast and correct, just as their website says. But I also liked it because it’s explicit with very little magic. And it has a powerful query/tools system that allows you to really analyze your builds and dependencies in depth. Though examples in the wild are a bit less since it is a fairly recent entrant compared to its competitors. For a personal side project, I needed to use SDL2 and it was the first time I had to use an external/pre-built library with bazel. This post documents the process I used for my own future reference and may be help some other lost soul like me. Although, the post talks about SDL2 here specifically, the same process can be used for most other external pre-compiled modules.

About the challenge

In this article, we’ll go through the Protostar stack4 challenge. This would be a bit similar to the stack0 challenge that we already tackled earlier, but it will think about an interesting way to get alternate code to execute instead of just modifying data.

Pre-requisite: Make sure you’ve completed the Part 1 of the Practical Reverse Engineering Tutorials series. It’d also be great if you can try stack1-stack3 challenges on your own as they are similar to stack0.

What is this about?

This article is the 1st part of the Practical Reverse Engineering Tutorials series. This series is geared towards a structured, but almost completely practical, approach to learn Reverse Engineering. Many of the existing articles/books take a long winded approach to teach RE which is prefixed with a lot of theory before the reader can get their hands dirty. This series will take a different approach of picking up various challenges in the order of increasing difficulty and help the reader in exploring ways how to break them. I’ll try to keep mundane theory limited to the portions needed to beat the current challenge in consideration. Hopefully, this keeps the articles short, precise and interesting enough for readers to keep their attention span intact.