There’s one question about residential proxies I can never quite let go of: where do the exit nodes actually come from? The providers all say the same thing — “real users who opted in.” I’ve poked at that claim before, and every time I come away thinking the device is real enough, but but I’ve never seen much proof that the users actually agreed to any of it..
So this time I tried working the supply chain from the inside out. Instead of asking who the exits are, I asked what they do — specifically, what a pool’s own IPs sit around downloading all day. That thread pulled all the way to a single cracked driving game.
Start with what the pool downloads
First I needed a pile of exit IPs. I harvested a batch from a mid-tier residential provider — rotating, country-targeted, nothing exotic — and looked each address up in public BitTorrent-attribution data. Just: has this IP been seen in a swarm, and for what?
The picture was not subtle. A big chunk of the exits had torrent history, and roughly one in five had pulled down an Android .apk at some point. That is wildly above whatever you’d expect from a random scoop of consumer IPs. And when I ranked the torrents by how many distinct pool IPs touched each one, the top of the list was basically wall-to-wall cracked game mods.
Now, I want to be careful here, because this is the part that’s easy to oversell. This isn’t proof anyone’s infected. It’s a behavioral fingerprint of the crowd. The people who sideload pirated games are the same people who happily install a sketchy “free” app next to it — that correlation exists with or without malware. But it’s still a map. It tells you exactly which APKs are worth opening first, and that’s all I wanted out of it.
Get a second opinion from the DHT
Attribution data is one source, and one source makes me nervous. I wanted something independent that couldn’t be poisoned by the same upstream. So for the most pool-correlated titles I went and watched the swarms myself, live.
That meant a BitTorrent DHT get_peers crawl: bootstrap off the public routers, walk toward the infohash, and scoop up the peers who are downloading that exact file right now. No tracker, no torrent client, just raw KRPC/bencode over UDP. It’s a lovely little protocol to talk to by hand.
Then the real question — I classified every swarm peer by ASN and geo and asked whether these were the same machines the provider was renting out to me. You almost never nail the identical IP; leases churn, and the pool cycles through hundreds of thousands of addresses, so exact matches are a coin toss at best. Instead I tested the granularities that actually mean something: same ISP/ASN, same /16, same /24. For each peer’s country I harvested fresh pool exits and compared.
It held up. Swarm peers and pool exits matched ISP-for-ISP, and in the dense markets they lined up right down to the same /24. Even better as a sanity check: a peer sitting on a datacenter/seedbox ASN was correctly missing from the pool, which checks out — the pool is supposed to be residential, and that’s a datacenter box, and it wasn’t there. Two independent signals, download attribution and live swarm membership, both pointing at the same consumer networks.
The other channel: an installer that just asks
Not everything in the pool gets there through a hidden payload. The same attribution thread turned up a second recruitment channel that hides nothing at all — and it isn’t a game, it’s the torrent client itself.
The pool’s IPs kept leaving a distinctive footprint in public torrent-attribution data — the signature of one particular consumer torrent client, showing up across the exits again and again. That pointed straight at the client, so I installed it on a throwaway VM and watched what its setup actually did.
The installer offered to add two commercial bandwidth-sharing SDKs, bundled right into setup as opt-in add-ons. Not a trojan — you “agree,” somewhere in the flow — but the outcome is the same as any of this: your connection quietly becomes someone’s residential exit node, resold by the gigabyte. The consent is real in the way installer-bundle and EULA consent is always real, which is to say it’s buried in a flow nobody reads, sitting next to the “yes, next, next” you click to reach your download.
That’s the honest-looking end of the same business. There’s no pirated game or hidden library here — just a free tool that signs up its own users at install time and feeds them into the pool.
Grab the whole game, five times over
The single most pool-correlated title turned out to be one very popular driving game. So I did the dumb, thorough thing: I grabbed five different builds from five different places — an established APK mirror, a couple of “mod” sites, a content-locker page, and the legit packaged version — and diffed the lot against each other.
Four of the five were boring, which is the best possible outcome. Normal engine, normal analytics, normal native libraries. The real game, repacked, nothing tucked away.
The fifth was not boring. It was the only build carrying a stack of extra native libraries none of the others had. Buried in there was a small .so with an entropy of 7.84 — that’s an encrypted blob, basically noise — sitting behind a custom loader and some anti-analysis libraries from a commercial Android packer family. That’s what gave it away. Nobody wraps a harmless little library in an encrypted, anti-debugging loader. You go to that trouble for exactly one reason. That payload was deliberately injected and deliberately hidden, by precisely one repacker in the set.
The nice thing is I didn’t have to guess which build was dirty. Four clean references told me, byte for byte, which libraries didn’t belong in the fifth. The diff did the accusing for me.
Watch it run
Static analysis walks straight into a wall the moment it hits an encrypted payload — there’s nothing left to read. So I put the booby-trapped build on a sandboxed device behind a transparent gateway and just watched what it said on the wire.
What came out was ad fraud, and a lot of it:
- A whole swarm of gibberish throwaway domains — random word-salad names that rotate constantly to stay ahead of blocklists.
- The clustering is what gave them up. Four of them sat on the same
/24as a domain named, with no shame whatsoever,effectivecpmnetwork.com. So: the serving edges of one CPM network. - And the offers were the top-of-market popunder vertical — adult-cam CPA, affiliate click-tracker and all.
I also fingerprinted every TLS Client Hello with JA3, because that tends to reveal who’s really making the connections. It split into two clean stacks. One was the device’s own platform/Conscrypt stack — the OS and the well-behaved apps. The other was a Chromium/WebView stack that shattered into dozens of different fingerprints, per-connection extension randomization, which is the unmistakable signature of ad creatives rendering inside a WebView. That per-connection randomization is basically a fingerprint of ads rendering in a WebView.
The honest ledger
This is the point where I have to slow down, because it’s an easy story to overstate.
What I’m confident about: the build is an ad-fraud / adult-CPA carrier. I sat there and watched it serve cam-site popunders through a recognizable CPM network. And it is, provably, the only one of five builds that injects an encrypted, packer-protected native payload the clean builds simply don’t have.
What I’m not confident about: that the encrypted payload is proxyware. It’s the obvious guess — this whole thing started from a pool built out of devices that download exactly these mods, and the payload is concealed in precisely the way a residential-proxy SDK would be. But I haven’t decrypted it. During my whole capture window it just sat there, silent. A packed payload that never wakes up tells you nothing from the outside, no matter how long you sniff. Actually settling “proxy or not” means unpacking it at runtime, and that’s still on the bench.
So two things are true at once, and I’m not going to smear them together to make a better headline. The pirated game is a confirmed ad-fraud vehicle. And it carries a deliberately hidden native payload of unknown function, riding on the exact device profile that fills a residential proxy pool. Correlation isn’t a confession. It is, however, an extremely specific spot to keep digging.
The pipeline is what I actually care about here:: pool exits, torrent attribution, DHT swarm confirmation, multi-sourcing the sample, static diff against clean builds, then runtime observation. Every stage is its own independent observable, and the conclusion only leans on what each stage actually showed me — no more.
Passive enumeration and public attribution only; I report ISP/ASN/subnet aggregates, never individual subscriber addresses. All sample analysis is static and sandboxed. The legitimate, unmodified game is unaffected — the injected payload lives only in one specific cracked repack.