I have some rules I follow on every hunt. not guidelines. rules....

146 views Sep 05, 2026 ~2 min read

                            1
                        
I have some rules I follow on every hunt. not guidelines. rules. going to drop the first eight in this thread because they're the ones that actually changed my results

                            2
                        
rule 1: read the language before the code. the exact version the project uses. not "I know rust". the specific overflow behavior in that toolchain, that solc version's quirks. entire bug classes live in language semantics and you're blind to them otherwise

                            3
                        
for rust that means ownership, lifetimes, unsafe blocks, and how overflow behaves in debug vs release. for solidity it's abi.encodePacked collisions, checked vs unchecked math, and what delegatecall does to msg.sender. know these before line 1

                            4
                        
js: float precision, coercion, prototype pollution, how errors move through async code. java: catch(Exception) does NOT catch StackOverflowError or OutOfMemoryError. Error isn't under Exception in the hierarchy. that gap alone has paid me

                            5
                        
rule 2: read everything anyone has ever written about the protocol. audits, post-mortems, writeups, CVEs, forum drama. also similar protocols. and note what got added AFTER the last audit. nobody has reviewed that. go there, this found me bugs on of the most popular protocols out there.

                            6
                        
rule 3: read every file in scope top to bottom before touching a single technique. one sentence summary per file. write down external calls, state writes, fund transfers, and every TODO/FIXME. the real findings are always across files, never in one

                            7
                        
rule 4: read the docs. all of them. I know. but the number one reason my early reports got closed was "this is intended behavior, it's in the spec." it was in the spec. I hadn't read the spec

                            8
                        
rule 5: track everything. on every audit I keep five files open:

potential findings w/ file:line
progress tracker
coverage checklist (goal is 100%, not "most")
known issues
fix pattern notes unglamorous. works

                            9
                        
never delete anything from your potential findings file. ever. I've had something I dismissed on day 1 turn out to be the missing piece of a chain on day 5. mark it dismissed, write why, leave it there

                            10
                        
rule 6: mine every fix commit in the repo history. for each one: what was the old code doing, what's the fix, what's the abstract pattern, does it exist elsewhere, is it fixed there too, is it exploitable, and what grep would find it

                            11
                        
rule 7: for every function that changes state, list every other function that changes the same state. compare them check by check. if one validates something the other doesn't, you probably have something. this is where most of my findings come from honestly

                            12
                        
rule 8: once you decide a path is safe, flip it. what would an attacker do to prove you wrong? my worst misses weren't things I didn't look at. they were things I looked at and decided were fine too fast

I have some rules I follow on every hunt. not guidelines. rules....

Actions

What You Can Do

Actions

What You Can Do

More in Productivity