How I Broke the Anti-Bot Behind Nike, Kick, and Twitch

I’ve always been into JavaScript VMs and anti-bot solving. I’ve built solvers for pretty much every major anti-bot and captcha system out there (I’m not saying I always scaled them, but they always worked perfectly for my personal usage :)). But I never tackled one where the entire anti-bot runs inside a custom VM. There are a few that do this: Shape Security, Kasada, and Cloudflare. Others like DataDome and PerimeterX use a VM for one field in their fingerprint (PerimeterX might have even removed theirs recently), but the ones I just mentioned go all in. The whole thing is a virtual machine. A friend of mine had already done Cloudflare, so I decided to go after Kasada. Before I even finished the solver and started talking to potential clients, I was only thinking about Kick and Twitch. But I quickly learned that nobody actually needs a solver for those two sites. They’re already pretty bad at bot protection on their own. People are just using real browsers to generate the CT header and only reversing the CD part because it’s lightweight work. They’re basically already farming those sites without a full solver. And if you’re reading that thinking “what the hell is CT? what is CD?” then good, that means you’re in the right place. Let me get into it. What Even Is This Thing? When you visit a site protected by this anti-bot, your browser gets redirected to an invisible iframe that loads a fingerprinting page. If you open DevTools on Kick and filter by 149e9513 (some kind of version identifier they use across all sites), you can see the whole flow: There are 4 requests happening in sequence: p.js loads first. This is the initializer. It sets up the environment, kicks off the PoW (proof of work) parameters, and fires the /mfc request. /mfc runs in parallel. This fetches challenge parameters for the CD (proof of work) portion. ips.js is the big one. This is the actual payload generator. It contains the entire bytecode VM, all the fingerprint probes, the encryption logic, everything. p.js is the one that tells the browser where to fetch it from. /tl is the final POST. The encrypted fingerprint payload gets sent here. If the server likes what it sees, you get back a {"reload":true} response, the iframe reloads, and you receive your x-kpsdk-ct header and cookie. If we look at the /fp response that kicks this whole thing off, it’s just a barebones HTML page: A KPSDK object gets initialized with timing info, a postMessage fires back to the parent, and then the ips.js script loads. That script URL changes on every request and contains unique parameters, namely x-kpsdk-v (the version number) and x-kpsdk-im (a static token extracted from the postMessage call in the /fp page, which you just pass through as a header when posting to /tl). So the flow is simple: p.js sets up → ips.js generates the fingerprint payload → payload gets encrypted and sent to /tl → server decides if you’re human or bot. The CT header (x-kpsdk-ct) is what you need to make authenticated requests to the site. It’s basically your “I’m human” token. The CD header (x-kpsdk-cd) is the proof of work answer, a SHA256 challenge that proves you spent some CPU cycles. Together they form the full anti-bot handshake. Now the real question is: what’s actually inside ips.js? The Script If you open ips.js expecting to read some JavaScript, good luck. The whole file is ~477KB and it’s essentially three things glued together: a bytecode decoder, a massive encoded string containing the…

This excerpt is published under fair use for community discussion. Read the full article at emro.cat.