Few names strike more fear into the hearts of blackhats than samczsun, known as perhaps the most prolific whitehat in DeFi security. Immunefi sat down with samczsun in an undisclosed location for an interview about his phenomenological methods and a very honest and frank and completely real discussion about his identity.
First question, the most important question, what’s your favorite anime and why?
The first half of Darling in the Franxx. They could’ve just ended it at episode 15 or maybe episode 21 but instead they crammed a bunch of nonsense into the last few episodes. It makes no sense.
What’s your setup for bug hunting? How complicated is it, or how simple is it? If you were to make it more complex or more simple, what would that look like? Why should whitehats buy $10,000 God-tier gaming rigs to find the type of bugs you find?
There’s a few stages involved here:
1. Finding the right targets
2. Finding the bugs
3. Reporting the bugs
In order to maximize what I see, I have a few different approaches to finding new targets. For example, I run a few microservices that scan the chain for what I consider to be interesting transactions, and that sometimes leads me to contracts I’ve never seen before. I also check through Telegram, Twitter, and of course, Immunefi.
My setup for actually finding bugs is also very simple. I use GitHub, Etherscan, seth, and occasionally an IDE if the project is just too big. A lot of my process is manual code review, I don’t really tend to reach for automated vulnerability detectors since I’ll have to go through it manually anyways (although there’s been a lot of progress in that regard recently so it might be worth taking another look).
After I find the bug, I have to submit the report. I like to submit a fully-weaponized proof-of-concept just so there’s no ambiguity about what the exploit is or what the impact might be. Usually that takes the form of a script that demonstrates how I can make all the money go poof, although a Foundry project would work just as well.
If I were to make it more complex, I would probably work on the first stage. A lot of vulnerability research is being in the right place at the right time, and since I can’t increase my luck the next best thing I can do is increase the number of chances I might get lucky.
What’s your process for choosing which project you’re going to look at?
If a portfolio company has some new code that they’re planning to release, that obviously takes priority. Otherwise, I pick stuff that has high TVL and/or isn’t just some random copy/paste fork. It’s not very mentally challenging to review a StakingRewards clone for the 80th time.
How fast do you scroll through the code and which smart contracts do you pick first? Are you glazing over the code before noticing some strange line and then stopping to investigate? Tell us what the spidey-sense feels like.
It depends. Sometimes I’ll start slow right away just because. Other times I’m pressed for time or just want to check for low-hanging fruit and I’ll skim through the code while pattern matching on common vulnerabilities. Usually if I notice something strange I’ll stop for a second and go, “Wait did I really just read that right?”
When bughunting, do you read the documentation of a project first? Do you try and reconstruct the architecture of how the protocol works, so that you have an idea if a function is doing what it’s supposed to be doing? Do you recommend that other bug hunters think about protocol architecture before looking at bugs?
No, no documentation. Documentation might fall out of date, but the code will never lie. I’ll almost always dive right into the code and try to construct my own view of how things work first. The only exception is when the code is implementing some extremely complex algorithm and I need to refer to the spec to even understand what it’s doing in the first place. I can’t say this approach works for everyone though, it’s totally valid to prep yourself by reading the documentation first.
The purpose of life, as some have said, is to crush your enemies, see them driven before you, and to hear the lamentation of their women. Do you agree with this?
Show no mercy.
Tell us about the moment-by-moment process of finding the Miso bug in SushiSwap.
I had just finished checking through all the contracts individually and was wondering if there was anything I had possibly missed before calling it good. I let my mind wander for a bit and out of nowhere I remembered the Opyn vulnerability. I spent a couple minutes mentally verifying the properties of delegatecall even though I knew it by heart, the same way you might manually verify 2+2 on a calculator even though you’re absolutely sure it’s 4.
After being sufficiently confident that I hadn’t overlooked something, I hopped over to Remix to write my proof-of-concept which would submit a bunch of bids using fake Ether. When I saw it worked, I started working on getting in contact with the Sushi folks. After my colleague Dan Robinson offered to get in touch with them, I went back to look at the rest of the code to see if there was a way to escalate the impact. That’s when I noticed that if the sales cap was reached, any additional Ether would be refunded. This was approximately when my heart rate went up a couple notches, because now it wasn’t just a bug that would mess up the token allocation, but could drain the funds entirely.
Tell us about the moment-by-moment process of finding the 0day in Etherscan.
I was trying to find a bug for the CTF teaser that would let me hide something on Etherscan, but I wasn’t having much luck. I tried a few tricks with the constructor but Etherscan wasn’t having any of it. Out of pure boredom, I scrolled right on the compiled bytecode field and noticed the {ipfs} placeholder. This immediately made me realize that Etherscan was probably allowing arbitrary differences in that placeholder region, or something to that effect. I realized that I couldn’t just manipulate the hash myself since there was no way to get Solidity to generate code which jumped to that region, so I had to fake my own hash somehow and pray that Etherscan would accept it. There was a lot that could go wrong, but I figured it was worth the time investment.
I started by trying to fake a hash through the constructor data, since that was the first way I could think of to insert arbitrary bytes into the *transaction data*, but Etherscan didn’t want to play along. This meant I needed to insert arbitrary data in the deployment bytecode instead. I thought about somehow manipulating Solidity to construct arbitrary bytes using opcodes, but that felt like a nightmare to do. After sitting there thinking about it for a little while longer, I realized that I could just have Solidity push a 32-byte constant, which was equivalent to injecting up to 32 bytes directly into the deployment bytecode. I did some very minor manipulation to make sure that the PUSH opcodes aligned with the data areas in the hash and in an amazing stroke of good luck, Etherscan happily accepted my hash-like structure as another metadata hash.
What does it feel like to find a bug that, if exploited, could lead to a loss of hundreds of millions of dollars? Please post your heart rate variability and level of pupil dilation in millimeters.
It’s a weird combination of elation and dread. Elation because you just found what you were looking for all this time. Dread because now the clock is ticking, and every second that passes is another second for someone else to find the same bug. My heart rate goes way up proportional to the amount at risk.
If you had to gesture vaguely, what is an underexplored area of current blockchain tech or smart contract functionality where there might be a novel class of vulnerabilities?
[Gestures vaguely] Composability. So many ways for it to go wrong.
What are you doing that other whitehats aren’t doing?
Well, most other whitehats aren’t that well versed in the ancient art of Tummo as I am. Apart from that though, nothing that different, except for a head start. I fully expect that within a few years, there’ll be plenty of well-known highly-respected blockchain security researchers much like how there are plenty of well-known highly-respected websec security researchers or whatnot.
You are a Tibetan monk deep in the Himalayas practicing the ancient art of Tummo. You generate enough heat to melt ice off your back and power several mining rigs. In your magnificent beneficence, you occasionally deign to descend the mountain to save the local towndegens from roving bandits. Alternatively, you are an Albanian street urchin and you hunt bugs from one of Enver Hoxha’s abandoned Cold War-era bunkers to feed your growing addiction to handmade carpets spun of the finest Albanian wool. Which is closer to the truth?
Wait a second, how did you know?
