“What will be the best and fast way to improve hacker mindset beside doing contests?”
I got this in my DMs.
Another one asked me to simplify the “bad state” idea.
So today I’ll show you exactly how I study a hack.
Here’s what most people do:
open the write-up
read the attack steps
think they got it
forget it in a week
Then the same bug sits in their audit, and they walk right past it.
When I started, I spent hours on Solodit issues and old reports.
It helps, but only up to a point.
My example today is the $42M GMX hack. You need 4 facts about it:
GMX V1 is a perps exchange: traders trade against one shared pool
GLP is the pool token: its price comes from AUM (what the pool says it’s worth)
AUM depends on two values: the total short size and the average short price
The size lives in the Vault: the average price lives in another contract,
ShortsTracker
That’s all. Now the 3 steps.
1. Find the bad state before you read the attack
I start every hack with context.
Same list, every time:
Which state matters?
What does the good state look like?
What is the bad state?
What does the bad state allow?
For GMX:
state: short size and average short price
good state: they move together, every time
bad state: size goes up, the average price stays old
it allows: AUM looks bigger, GLP looks more expensive, you redeem for more than you put in
Write these 4 lines before you read a single attack step.
Once you know the bad state, the attack is just one question.
How do I get there?
Try it today: take one hack you’ve already read, close the write-up, and write these 4 lines from the code.
2. Ask what stops you, then when it’s off
Here’s how an attacker thinks.
He starts from what he wants: the bad state.
Then he runs the same loop, again and again:
What do I want?
What stops me?
When is that check off, or who can skip it?
Every “no” becomes the next question.
He stops when he reaches a function anyone can call.
Here’s the loop on GMX, from my notes:
I want size up and the average price old
What stops me? A normal order updates both, through ShortsTracker
Can I skip it? Yes, call the Vault directly
What stops me now? The Vault works only while a leverage flag is on
When is it on? Only while the keeper bot executes an order
So I need my own code to run during the keeper’s order
One more question finishes it.
What do I control?
In that sequence, the attacker controls one thing: _account, the address that gets the ETH back.
He made it a contract.
The ETH lands, his code runs, and the flag is still on.
Everything that is user-supplied is a tricky place.
The rest is the cash out: redeem GLP at the fake price.
The extra money comes from every other GLP holder.
“But I’ll never audit GMX.”
Doesn’t matter. The loop works on any code.
Your homework:
Pick one function in your current audit
Write the bad state you want
Run the loop: what stops me, when is it off, what do I control
Keep going until you hit a function anyone can call, or a check you can’t get around
3. Forget the scope. The attacker does.
A Whitehat reads the bounty page first.
The attacker uses everything that touches the protocol: bots, keepers, oracles, other contracts.
On GMX, the keeper did half the work for him:
it turned the leverage flag on
it sent the ETH to his contract
nobody hacked it, it just did its job
Now look at it as a Whitehat.
The keeper is off-chain, so it’s out of scope.
Submit this, and the project answers:
“Off-chain entity validates it, it’s ok!”
You’d beg for a small bounty.
The attacker drained $42M and kept about $5M after returning the rest.
Before your next audit:
List every actor that calls the protocol: users, keepers, admins, oracles, other protocols
For each one, ask: what does it do for me if I’m the attacker?
Check the scope only after you have the answer
Here’s the full template I fill in for every hack:
HACK: <name> · <date> · <loss>
LINKS: 2-3 write-ups, never one
BEFORE I START
- What are the most important parts to focus on?
- What don't I understand yet? *define it clearly
- What is my final goal?
CONTEXT
- Which state matters?
- Good state:
- Bad state:
- What the bad state allows:
THE LOOP
- What do I want? What stops me? When is it off?
- What do I control?
- //@audit on every line the bad value touches, until the payout
- Where did the extra money come from?
OUTSIDE THE SCOPE
- Who else calls this code?
- What does each one do for the attacker?
SOLIDIFY
- Explain it to yourself in simple words
- Re-read the notes and look for a hole
- Move the questions into your checklist, without names
Pick one hack this week and fill it in.
That’s how you train your hacker mindset without a contest.
My GMX notes came from 3 write-ups: the Neodyme thread, the GMX post-mortem, and the SolidityScan analysis.
If you want to run the full attacker method on a real codebase with me, join the guided audit: a real audit we run together, not a course you watch.
— Arsen