5 weeks ago i wrote: "20 reports, 1 paid, one stuck 2 months." said the industry had a payout problem and went silent. spent every night in vendor code, chasing bugs nobody else did. today: 7 paid, #1 hacker of the week on @hackenproof as @redvision (me). we fucking earned this.
a signature proves a message wasn't changed. it does not prove the right message got signed π
my favorite class in anything crypto-adjacent. the server builds a blob, signs it, later verifies the signature is valid, and everyone reads "valid signature = trusted request." the real question nobody asks: which fields are actually inside the signed blob?
amount signed but recipient not? keep the signature, swap the recipient. nonce not covered? replay it. chain id missing? the same signed intent works on a second chain. EIP-712 made this worse, the struct looks exhaustive so devs stop checking what it actually commits to.
the bug is never the cryptography. it's the one critical field living outside the signed bytes. always ask: what does this signature NOT cover? π
@HackenProof@immunefi@Hacker0x01 #infosec #cryptography #web3 #bugbounty #appsec #ethicalhacking #hacking
@AnthropicAI this is the access model the field actually needed. tying capability to verified authorization instead of one blanket safeguard is the right call, and honestly overdue.
one ask from the other side of the table: make sure solo researchers can reach the offensive tiers too, not just companies and red teams. a huge share of real bug bounty work is one person, one terminal, deep in vendor code at 3am. i run solo, finished #1 hacker of the week on @HackenProof, and claude is already the core of how i read bundles, reverse flows, and model trust boundaries.
the lone hunter is half of this industry. verify the person and the authorization, not just the org chart.
the signer trusting input it never actually validated. it checks the signature is well-formed and moves on, but the thing it signed, the recipient, the amount, the chain id, half of that was never covered by what it verifies.
you're not breaking the crypto. you're handing it a valid message the system assumed nobody would ever send. that's the whole class.
@ChalupaBrock exactly. and it's not just the route names. a prod sourcemap hands you the client-side validation logic too, which is basically a map of what the server is probably not re-checking. the routes get you in the door. the validation gaps tell you what to try once you're in.
i read the target's own code before i send a single request π
js bundles, sourcemaps if they shipped them to prod by accident, the mobile app pulled straight from the store and run through jadx, any public repo or npm package with their name on it. half a target's attack surface is sitting in files they already handed you.
here's why it beats scanning: most bugs are an assumption the developer made on the client and never enforced on the server. a role check that only lives in react. a price validated in the browser and trusted on submit. an object id the frontend "knows" belongs to you. a feature flag gating an endpoint that's still live if you call it directly. the server trusts all of it until you prove it shouldn't.
you find those by reading intent, not by firing payloads blind. the sourcemap hands you the internal route names. the APK hands you hardcoded endpoints, exported activities, deeplink handlers, sometimes a key someone forgot to strip. the client-side validation tells you exactly what the server is probably NOT re-checking.
a scanner sees 200 and moves on. it never reads the comment that says "TODO: add authz here". that line is the bug.
read first. fire second π
@HackenProof@Bugcrowd@intigriti@Hacker0x01@yeswehack #bugbounty #appsec #infosec #bugbountytips #websecurity #cybersecurity #ethicalhacking #hacking #OSINT
mostly web and api honestly. auth and oauth flows, dashboards, the internal endpoints behind these crypto platforms. client-side too, xss, postmessage, the dom stuff people stopped checking.
then the crypto layer, mpc libs, oracle feeds, signer services offchain. the contract gets four audits, the machine around it gets none.
so not one lane. web is the bread and butter, the crypto infra is where it gets interesting.
this is exactly what i told you. 2 informative and 1 oos on a codebase two audit firms already combed isn't you missing anything. the valid bugs were gone before you cloned the repo. smart contract bounties on the serious protocols are the most picked-over code in crypto.
the systematic process you built is the real takeaway, that transfers to any target. but if you want valid findings, the room is in the layer under the contracts, not in them. keep going.