Research

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.

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.

I chased a residential proxy pool’s own download habits down to one cracked driving game, and found a build that’s a confirmed ad-fraud carrier hiding an encrypted payload I still can’t prove is proxyware.

How I passively fingerprinted hacked Dutch CCTV cameras being resold as residential proxy exit nodes — and reported them to NCSC-NL without ever touching a single box.