I got bored on a forum doing arithmetic on ‘millions of residential IPs’, ended up reverse-engineering a botnet’s C2 from one infected phone, and reported it. The whole messy thread — and where it led.
Fourth post on where residential proxy exits come from. The SYN fingerprints said the pool wasn’t real users; MediaGet closed the Windows arm; this is the Android arm, and it’s a no. I opened the kind of hidden, packed payload I’ve twice failed to open before, and it’s a cheat framework with Chinese telemetry and no C2 of its own. The proxy correlation I chased alongside it holds up as a measurement and not as evidence — and my own March fingerprint data had already told me the Android channel was a minority tributary, which I only noticed afterwards.
Finishing a thread I left dangling: the torrent client from the booby-trapped-game post, named and taken apart. Its installer doesn’t contain a single payload URL — it asks a server, and the server answers based on what country you’re in. Eleven proxy vendors wired into the UI package, one slot per machine, and the geos that look clean turn out to be the ones with no consent screen. Two of the vendors it shipped me have since been dismantled by Google-led actions.
Every WebRTC leak check reads a value the browser reports, and an anti-detect browser reports whatever keeps you happy. So I stopped reading its answer and started checking mine: run the STUN server yourself, and whether a packet actually arrived becomes the one thing the browser can’t forge. Here’s the idea, a widget to test your own browser, and an honest tour of everywhere it fails.
Most tools ask whether a TLS fingerprint resembles Chrome. I wanted a different question — how does it behave? So I sat inside a residential proxy network, named a million handshakes, and found the bulk of the ‘bot’ traffic isn’t faking Chrome. It’s driving it.
The monitor radio from last post’s shopping list showed up, so I stopped driving synthetic beacons and pointed it at a real Telegram video call — captured twice at once: from the air, encrypted, and from inside the target, decrypted, as ground truth. The call’s shape crossed the encryption at r = 0.8–0.9, a wrong-window null stayed dark, and the whole thing was legible without reading one byte of content. Then the honest half: a background stream drowned the call until it got loud, the downlink data frames stayed as unreadable as ever, and a clever one-way ICMP trick failed a null control cleanly.
A NAT is a router that subtracts one from the TTL, so every NAT layer is a hop you can count. I built a small tool that reverse-traces a visitor back through the hole their own connection punched — and asked the honest question: is any of it useful for catching bots? Mostly no, sometimes cheaply yes.
A weekend bench experiment: drive a size/timing pattern through a doubly-encrypted, proxied flow and watch it reappear in a device’s WiFi frames. The physics held at r=0.9 on my own hardware — and then the real fight was with a cheap monitor adapter that decoded almost none of the frames I actually needed. A lab notebook that ends in a shopping list, false positive included.
Final follow-up post debunking the “open UDP relay = DDoS amplifier” fear: chaining launders origin but de-amplifies at the target, self-looping only DoSes the relay itself, loopback forwarding is a UDP SSRF, and even a paid commercial proxy fails the RFC 1928 §6 source check — every behavior reframed as a single-packet detection fingerprint.
Final version of the SOCKS5 open-UDP-relay teardown: de-quantified the scan-list phrasing, aligned a log comment to first-person voice, and thinned one forward-reference scaffold, with all tables, numbers, RFC references, and the “signals, not weapons” defensive framing preserved verbatim.