January 21, 2025

Most CTF challenges are created to have a logical set of steps to solve by its creators. Typically, this means there is a single solution to the challenge in mind. With hundreds of creative people looking at the same challenge, unexpected paths to the end goal are bound to happen. CTF goers love a good unintended solution! In a way, you hacked the hacker.
I host a CTF oriented at college and high school students called the Spokane Cyber Cup (SCC). Since I've been doing application security professionally for about 5 years, I would expect these students never to find an unintended solution. In reality, there are always one or two interesting workarounds for the challenges we prepare. This post concerns one of my favorite challenges and hilarious tale around the unintended solution for it- using NaN to break the bank. I hope you enjoy!

The challenge is a C program that is a simple bank deposit and withdraw system. It's a standard-looking pwnable that has four options, as shown in Figure 1:
The Deposit option is capped to a total of 1e10, and you cannot Withdraw more than you currently have. The deposit amount is a 32-bit float. Floats are complicated, as documented by Bruce Dawson in his series on floating point numbers that inspired this challenge.
I'm guessing the option that tickled your fancy was Show Stolen Money. How does it keep track of this? While the actual amount in the bank is a float, there is a separate long long used on the Withdraw option that is used to track the amount stolen.
December 11, 2024
As a pentester, how often do you think to yourself "Why haven't they gotten back to me on my bug report?" Or how about "Why isn't this bug fixed yet?" I have frequently had these sorts of thoughts toward developers as a security researcher. For us, it's fairly common to find a vulnerability, report it, and throw it over a wall to the developers, never to see anything about the bug ever again.
Previously, I worked at Security Innovation doing application security assessments and did a decent amount of bug bounty hunting on the side. I’m currently at Asymmetric Research, where one of my roles is acting as a member of the internal security team for the cross-chain bridging product Wormhole. With billions of dollars in assets at stake, we perform security reviews on new products, design new security features, handle the bug bounty program, and many other security-related tasks. The thoughts that follow in this blog post are entirely my own and do not reflect the opinions of my current or previous employers.
I've been on both sides of the vulnerability wall: reporter and reportee. I've thrown things over and been hit by heavy reports over the years. From being on both sides, I finally understand Why You Can't Fix This Bug Faster.
September 16, 2024

In 2023 at DEFCON 31, a few friends and I decided to tackle the Industrial Control Systems (ICS) Capture the Flag (CTF) competition. To our surprise, the four of us secured 2nd place with almost no prior experience in the ICS security space. With coming so close to winning the event we were hooked on it.
This year, in 2024, my team took first place by a whopping 37% more challenges solved than the next team. In this post, we will walk through the experience of winning the competition in 2024, tips for new competitors and I'll even go through the solution for my favorite challenge. Enjoy!
From 2021-2023, I ran a workshop on heap exploitation at DEFCON. Last year, this took half of a day for myself and my buddy Kevin Choi. This year, the only activity I participated in was the Red Alert ICS CTF; the more time you spend on challenges, the more challenges you can solve. This year, we wanted to take the event more seriously by committing more time to it and preparing for it in advance. How do you even prepare for a CTF like this?
From reading articles about the event and posts on their Twitter, the Red Alert team seems to reuse challenges and challenge types from year to year. After participating last year, we consciously tried to store all our notes. We solved several challenges almost instantaneously this year from writing down solution steps and keeping scripts from the previous year. This gave us a major leg up on many reused or recycled challenges. The key takeaway is to look for patterns at the events and use this knowledge to your advantage.
Another preparation tip is researching the technologies used in ICS, such as Modbus, OPC-UA, and others. Our team had all of the clients/libraries already downloaded for interacting with the protocols and had detailed notes on how each protocol worked. If any of these ICS-specific protocols came up, we were able to solve these challenges very quickly since we only had to focus on the challenge properties and not how to simply interact with the challenge. Josue even attended a few ICS security conferences to get deeper ingrained in the ecosystem.
April 23, 2024
December 27, 2023
Recently, ging3r and I (Strikeout) found a vulnerability in the Gravity Bridge. Since I wrote up the last few vulnerabilities on this blog, Ging3r wanted to use his voice to tell a story. Ging3r decided to write on my blog, becoming the first guest blogger on my site. He's got a good voice and explains the bug well. Enjoy! :)
I’ve been programming and hacking for about 10 years now, and one of my favorite things in this space is the asymmetry inherently created by cryptography. The most powerful governments in the history of the world have been brought low, and forced to spend billions of dollars to find side channels and make extortive deals, all because given b^k = a mod n, it’s quite difficult to figure out k.
It truly is that simple. There is some essential hardness (in the computational complexity sense of the word) that our symbolic representation of that problem latches onto that is thus far impenetrable. Even organizations with high incentivisation to do so and billions of dollars to throw at legions of mathematicians have yet to figure out a simple way to solve such a simple problem.Yet little old me, here in my little old room, can conceptually latch onto and use those essentially hard problems, for any variety of fascinating ends. With real world consequences.
The set of real world consequences of our manipulations of those symbols has, thanks to Satoshi Nakamoto and others, been thoroughly brought into the economic realm. The mixing of ethereal, abstract mathematical concepts with our human flesh and blood economic incentivization schemes is part of what makes the blockchain space so fascinating to me. Where else in history has such a crossing of conceptual wires occurred? Did Diffie and Hellman know that one day they’d play a part in putting the not-so-metaphorical food on the literal table rof a whole army of blockchain devs, auditors, and blackhat hackers?
In this post, I’m going to explain how I (Ging3r) and Strikeout (the owner of this blog) recently discovered a bug in a Cosmos to Ethereum bridge that, while being only a chain halt, still showed some of the remarkable signs of that inherent asymmetry that I find so fascinating. Before I explain, however, there’s a few important prerequisites.

Cosmos is one iteration of interchain technology. Instead of trying to create a whole bunch of unique chains each with their own ecosystem, Cosmos seeks to create an ecosystem where a bunch of unique chains can each do their own thing well, and use their integrated interconnectivity to communicate with all other Cosmos chains seamlessly.
Cosmos uses the idea of application specific blockchains to craft this ecosystem uniquely suited to interconnectivity. The Cosmos SDK provides all the protocols and packages and algorithms, you just build your application specific chain to do it’s application specific thing. Then turn on a few extra knobs and toggles and whistles and such and you can natively interact with all the other chains using the same protocols. I’ll save some ink for both you and I and keep my brief description brief, but you can also read strikeout’s excellent introduction to the Cosmos SDK.