This is a recap of the events of the last week where we participated in... an exciting and honestly one-of-a-kind battle, if you might call it that. It all started when we had access to the GitHub repo Battle of Galen Erso, and I didn't know what to expect for one. Whereas I have seen Kubernetes around and have downloaded Orbstack and seen it in some of the configuration files, I have never really worked with it directly, so there's a bit of fear towards that particular side of things, but the idea behind it is actually very interesting.
The battle was a game where we were supposed to attack Bitcoin Core nodes in a private network. This bit of information is going to become very important for the next part of the story. After initially getting the GitHub repo cloned:
git clone https://github.com/bitcoin-dev-project/battle-of-galen-erso
cd battle-of-galen-erso/
I then went and just checked in some of the folders to understand what was going on. There's not really much, but you can tell that if you were to go into the test framework folder, you would definitely get lost. So I then went ahead to deploy the local cluster (called "scrimmage") that was supposed to run different scenarios on my machine. Surprisingly, I already had the things needed to run Kubernetes locally just by installing Obstack, which was actually very interesting.
The Competition Begins
I didn't really get time to experiment with the local stack since right about then, the competition began. Remember when I said that in the back of my mind I had the idea that our goal was to attack as many tanks as possible? Well, I made a sad mistake.
After looking into the scenarios folder for a short while, I started to see that there were scripts and each one somehow corresponded to the versions of some of the Bitcoin nodes. So this gave me an idea - these were clues. Checking inside the scripts, the very first one for the 5K inventory messages is actually pretty straightforward because you are given the information about how to send an inventory message; you just need to change it a little bit and send 5000 messages.
The Learning Experience
I had an idea to start with the low hanging fruit and then pick out the rest based on the scripts in the folder. So I began attacking every node I could find that had the 5K INV name attached to it. The first time I realised there was a problem was when I checked the scoreboard - it seemed like every other team was getting ahead of us despite me clearly having taken down at least three different nodes.
I completely apologize to whichever teams I did this to, by the way! But going back to the story, that's when I realised that these different tanks had team colours associated with them. I had detected team colours for other teams but hadn't attacked the mint team, and when I finally did, that's when we got the points.
The documentation states that you can only access your particular nodes, which is why I thought there was no way we would attack other teams, or at least it wouldn't be set up in such a way that we could attack someone else's team. And that's when I realised my mistake - I had already given the rest of the teams a head start!
Moving Forward
There was nothing I could do about this and I had to just learn and move on. But I think it was important to learn to read instructions more carefully before participating in competitions like this. After that, I slowly went through the rest of the scripts one by one, adding tiny bits and pieces to the code. The framework was already set.
The only one which failed to work for me was the one which had the 96, and up to now I do not know what exactly could have been done to fix that. For the rest of the nodes, it was surprisingly easy to find out the vulnerabilities because these were disclosed on the fake Bitcoin website BitcornCore. That made it a lot simpler to get started.
However, when it came to the nodes running older versions of Bitcoin Core, it became apparent that it was going to be more difficult. We had to look through the actual Bitcoin Core blog to find the CVEs we were going to attack. And we needed to do this without having as much control or information from the nodes themselves.
Technical Challenges and Team Collaboration
After going through a number of CVEs, it became apparent that the problem wasn't that the CVE wasn't working - I just didn't have enough technical knowledge about the CVE to execute it, or at least not enough to bypass some of the measures put in place to prevent the exploitation.
This entire time we were sharing information with my team and going back and forth about different exploits we had found, hoping to make them work. But that didn't happen.
Reflection and Appreciation
I'm grateful for the experience and glad to have been part of something that required thinking outside the box - something that required consulting different sources like GitHub issues, blogs, search engines, and substack. It was definitely not what you're used to on a regular basis, but it gives you more appreciation for the evolution of these different Bitcoin Core standards and how anyone can contribute to the network by finding potentially harmful issues.
This is evident in the various GitHub issues where you see different people coming together to propose solutions, and I am still committed to trying out these different exploits in my free time on my local machine to see if I can find a way to make them work.
I hope that more blogs can be put out about different teams and their various experiences, especially from the person who managed to create invalid headers, because that is something I found very interesting.
Still, this whole program is surreal, and the fact that you get to challenge yourself every week is one of the best experiences you can have. It really is humbling.
