uCreator: virtualization-based Android spyware platform targeting WeChat, Telegram and other messaging apps

Introduction

uCreater (the vendor's own name for the product is YingGai) is a commercial Android surveillance platform built around 群控 (“mass control”). Branded through packages in the com.ucreator.* namespace, it is not a single malware family but a productized framework: a VirtualApp/LSPatch engine, a library of per-application hook modules, a Redis and HTTP control plane, a cloud-phone farm for live screen control, and a Windows operator console. Customers can rent the platform and deploy its capabilities against different applications on a target device. Despite this breadth and multi year usage, I found little public threat reporting documenting the platform's architecture.

The intended targets appear (still unknown) to be ordinary users of mobile wallets and messaging applications across China and Southeast Asia, including GCash (Philippines), WeChat, WeCom, QQ, Telegram, WhatsApp, LINE, Zalo, KakaoTalk, Viber, and MoMo. The recovered code supports capabilities including OTP interception, wallet and messenger data extraction, session manipulation, camera spoofing intended to defeat KYC liveness checks, and contact harvesting. These capabilities are consistent with account compromise and subsequent fraud, although the precise monetization and deployment patterns remain incompletely established.

One distinction matters throughout this report: this is an analysis of technical capability, not a measurement of victim impact. The target roster shows what the platform is built to attack, not how many people have been compromised. During the investigation, I obtained access to a C2 server which did contain victim-related artifacts. These provided some indications of geographic targeting, including users apparently located in China and the United States. But it did not establish a reliable victim count or clear attribution for individual operations. That access however did indicate that the platform can be used to target specific individuals.

Victims do not necessarily install a standalone application advertised as spyware. Instead, the observed distribution model includes repackaged copies of legitimate applications, including Telegram variants, WeChat, and GCash, distributed through sideloading or social engineering flows. Another distribution route uses the vendor's container application, 洋葱盒子 (“Onion Box”). The repackaged APK can be relatively thin: target-specific instrumentation is retrieved after installation from the operator's Alibaba OSS and MinIO infrastructure, including buckets and paths named Huuk_<target> and fengzhuang-app (literally, “packaging”). Distribution hosts include telegram-apk.uzyzx.com. I could reconstruct much of the post-installation execution chain from the recovered code, but I could not directly establish the initial delivery mechanism for every victim.

The product has a longer history than the samples examined here. The package com.ucreater.autotool dates to approximately 2014, and Windows tooling linked to ucreater.com was signed during 2016–2019. The YingGai mobile product line appears in records from September 2021. The artifacts analysed for this report date from 2024–2026: uip.exe builds from February to December 2024, Telegram repacks from July and November 2024, the va_vx WeChat host and tg framework from December 2024, and the Onion Box client from March 2026. The C2 apex's ICP filing, 湘ICP备2024061212号, dates to 2024.

The infrastructure provides some indication of the operation's scale, although not its victim volume. I identified approximately 20 target applications with code-confirmed support, six operator-associated domains with dozens of subdomains, three Redis buses, two MQTT buses, and a cloud-phone/RTC infrastructure cluster in Changsha spanning multiple ISPs. The resale and customer-facing architecture is consistent with a platform serving multiple downstream operators. A Censys search for the operator's Tengine gateway fingerprint returned approximately 48 hosts. Taken together, these findings suggest a multi-year, productized operation. Unfortunately they do not establish how many customers deployed it or how many devices were compromised.

Muddy corporate links & unresolved relationships

Attributing the platform to a single legal entity is more difficult than identifying its technical infrastructure. Three companies in Changsha and Hunan are associated with different parts of the operation, but the available evidence does not yet establish that they share a common owner.

Hunan Youchuang Technology Co., Ltd. (湖南由创科技有限公司) is associated with the ucreater.com brand through the available registration and infrastructure evidence. A self-signed TLS certificate containing the organisation field O=湖南由创科技有限责任公司 was also observed on the C2 infrastructure at videoflow.cn. Changsha Sukai Network Co., Ltd. (长沙速凯网络有限责任公司) is associated with the ICP filing for the C2 apex qianxuncc.cn. Changsha Zhuoqing E-commerce Co., Ltd. (长沙卓擎电子商务有限公司) appears as the Authenticode signing identity for uip.exe, with a DigiCert-issued signing certificate.

These associations connect separate corporate identities to different components of the ecosystem. A shared beneficial owner or coordinated corporate structure is plausible, but remains unproven by the registry evidence examined so far.

There is also an unresolved public-security lead. During infrastructure mapping, a domain associated with the Hunan Intelligent Police Public Safety Technology Research Institute (湖南智警公共安全技术研究院有限公司), hunanzhijing.com, appeared on the same Tengine gateway fingerprint as infrastructure associated with the operation. An official Hunan government document also identifies that institute in connection with an intelligent-policing and big-data research project involving a provincial citizen-information administration body.

Neither finding establishes a relationship between the institute and uCreater. Shared cloud ingress demonstrates co-tenancy, not common ownership, collaboration, or operational control. I have not established a corporate, technical, or contractual link between the institute and the uCreater-associated companies. The institute's documented public-security work is therefore context for further investigation, not evidence that police developed, operated, endorsed, or deployed this spyware.

Other infrastructure relationships require the same caution. The Southeast Asian relay used by the Telegram component, 43.225.141.209 (Huawei Cloud Thailand), was co-tenanted with gambling services identified as gold5play and gold4play, an advertising-account service named toufanghao (投放号), and an SMS service named mdssms. This suggests an environment hosting multiple grey-market services, but does not establish that the uCreater operator owns or controls those businesses. The cloud-phone web client also presented a live certificate for a different vendor brand, *.tanjingpaas.com, while the C2 gateway exposed a Vue application titled 舆情交易 (“public-opinion/sentiment trading”). These remain leads around the edges of the core attribution, not established parts of the uCreater operation.

Virtualization to a surveillance platform

Zimperium's analysis of virtualization-based mobile threats describes the broader security implications of VirtualApp, LSPatch, Pine, and related techniques. By hosting or instrumenting applications at runtime, this approach can expose functionality and data from an application's authenticated execution context without requiring root. The original application code, installed package, and runtime environment are not necessarily unmodified, however; the precise integrity implications depend on the implementation.

uCreater is notable because it turns these techniques into a reusable, remotely managed product. Three findings distinguish the platform in the samples examined here:

• A self-describing command interface inside target applications. Each hooked application can expose a local HTTP command server with approximately 40 numbered handlers implementing an IHttpDoc interface, including getDesc() and getParam(). This makes the available operations discoverable through the interface itself, rather than requiring the operator to work exclusively with a fixed collection of commands.
• Direct access to application data in its authenticated runtime. The Telegram module can issue SQL queries through the application's own live database interface, including MessagesStorage, rather than relying solely on extracting and decrypting database files from disk. This can expose data available to the running application even when the corresponding files are protected at rest.
• Target-specific capabilities delivered after installation. Hook modules and manifests are retrieved from OSS/MinIO infrastructure using target-specific identifiers such as Huuk_<target>. This separates the initial application package from much of the functionality delivered later, complicating static analysis of the installer alone.

The Telegram module presents a particularly serious capability. The recovered implementation includes functionality to capture the account's two-step-verification password in cleartext and remove its own session from the victim's device-authorisation list. Together, these operations could support account takeover and concealment of the intrusion. The extent to which every step has been exercised end-to-end should be distinguished from what the code establishes.

The result is more than a conventional banking trojan or a read-only credential stealer. It is a remotely managed Android surveillance platform that can instrument legitimate applications, interact with their authenticated state, and expose application-specific operations to downstream operators. The following sections examine the code, infrastructure, and evidence behind that assessment.

Technical

APK Virtualization

uCreator belongs to the class Zimperium flagged as the dark side of virtualization: Android app-virtualization and no-root hooking turned. The building blocks are off-the-shelf: VirtualApp (a container that loads and runs another app’s code inside its own process), LSPatch (root-less Xposed, merged into a repackaged APK), and Pine (an ART inline-hook engine). The goal of all three is to get the attacker’s code inside the target app’s process while the real app runs normally signed-in, decrypted, trusted by the OS.

It gets there two ways: for messengers it ships a repackaged build of the real app (Telegram-X / Telegram-Web, WeChat) with the module merged via LSPatch or injected from assets/TgJarPine.dex via Pine. For WeChat it can instead run the untouched app inside a VirtualApp container (the va_vx / 洋葱盒子 multi-open host). Either path lands the module in-process.

The closest published reference to spyware/RAT behaviour like this is Zimperium’s GodFather work. I think this is the first well documented case of weaponized on-device virtualization. GodFather spins the banking app up inside a virtual container and drops a fake overlay on top to phish credentials: the victim is really typing into the attacker’s screen. uCreator shares the substrate but it draws no overlay. It instruments the real UI and logic from the inside and hooking methods (XposedBridge.hookAllMethods), reflecting into the app’s own classes, and reading the app’s own database with the app’s own handles. This is a case really of overlay-the-app versus instrument-the-app with the the second being quieter and also not being confined to a login screen. As an operator, it scales to any app the vendor writes a module for.

They are also separate actors different signing certs, different infrastructure, no shared domains related only by the technique and coding style. This interesting part here for me is that GodFather proved virtualization could carry an overlay whereas uCreator takes the same primitive and scales it into a general-purpose, remotely-programmable RAT platform over whatever app you point it at.

The injection entrypoint is a stock Xposed hook which lands as a thin, handing off to a compat layer that fans the hooks, the command server and the Redis subscriber out into the process:

The Telegram hook ships as a separate secondary DEX bundled as an APK asset and is loaded at runtime rather than living in the primary dex.LSPatch separately drops the original app to cache/lspatch/origin/.apk. Both are reliable host-side signatures.

The platform splits into a framework (com.ucreator.tg, the LSPatch/Xposed engine + command handlers), per-target hook modules, and a Windows operator console (not covering that in this). The Telegram arm ships as a repackaged Telegram-X / Telegram-Web whose injected logic decompiles into com.ucreator.tgjar. The two Telegram samples below were pulled by their runtime C2 contact, not by signature, so they’re confirmed live.

Modern Android 16/17 hardening

In-process hooking, the core of this kit, remains technically viable on Android 16/17. I have recovered samples targeting Android 16, but have yet to identify Android 17-specific samples in the wild.

On a Pixel 10 Pro running Android 17 (API 37), I confirmed that Frida can still establish an in-process ART method hook. The underlying instrumentation technique therefore remains viable on the tested build. The limitation is the compatibility of the captured kit's instrumentation engine. Its bundled Pine implementation targets older ART internals and does not correctly resolve the hidden-API enforcement symbol on Android 16/17.

Since Android 9, Android has restricted applications' access to non-SDK (“hidden”) framework APIs. VirtualApp and Pine depend on internal framework and runtime interfaces, including ART's ArtMethod and ArtField representations. Their ability to operate therefore depends, in part, on how they interact with hidden-API enforcement.

Two approaches are relevant here:

1. Runtime exemptions: invoking the hidden VMRuntime.setHiddenApiExemptions interface to request exemptions from hidden-API restrictions. Its presence does not, by itself, establish that an ordinary application can successfully invoke it in every execution environment.
2. ART-level modification: locating and modifying the enforcement logic in libart.so, including art::hiddenapi::ShouldDenyAccessToMember, which participates in deciding whether access to a hidden member should be denied.

The second approach is the one relevant to the captured Pine implementation. Its compatibility depends on resolving the correct ART symbols and matching the runtime's implementation. Changes to those internals can break an existing engine even when the underlying instrumentation technique remains possible.

On the tested Android 17 build, the captured Pine implementation attempts to resolve ShouldDenyAccessToMember using a C++-mangled symbol name associated with the older implementation. Android 16/17 ART changes the function signature by introducing a Handle<mirror::Class> parameter, changing the corresponding symbol.

The captured Pine implementation looks for a symbol beginning with:

_ZN3art9hiddenapi24ShouldDenyAccessToMemberINS_8ArtFieldEEEbPT_RKNSt3__18functionI...

The newer implementation has a corresponding symbol beginning with:

_ZN3art9hiddenapi24ShouldDenyAccessToMemberINS_8ArtFieldEEEbNS_6HandleINS_6mirror5ClassEEEPT_RK...

The signature change explains why the captured implementation's existing symbol lookup is incompatible with the newer ART implementation. It does not establish that the enforcement mechanism can no longer be located or that in-process hooking has been prevented.

The distinction is important here since this is evidence of a compatibility failure in the captured engine, not evidence that Android 17 has eliminated the attack technique. Frida's successful hook demonstrates that in-process ART instrumentation remains possible on the tested Android 17 device. It does not, however, prove that the complete uCreater execution chain works on that build.

The newest sample I examined, dated 29 July 2026, still ships the older Pine implementation. I have not yet verified whether porting Pine to the newer ART implementation restores the kit's hidden-API bypass and full functionality.

For now, the evidence supports a narrower conclusion: Android 16/17 introduces compatibility work for this implementation, rather than a demonstrated platform-wide prevention of virtualization-based instrumentation. Whether uCreater operators have already adapted their engine for Android 17 is something I'm curious about. It's also worth noting that I haven't tested this on Chinese phones yet, so coverage may differ from Pixels.

Samples

The platform splits into a framework (com.ucreator.tg, the LSPatch/Xposed engine + command handlers), per-target hook modules, and a Windows operator console (out of scope here). The Telegram arm ships as a repackaged Telegram-X / Telegram-Web whose injected logic decompiles into com.ucreator.tgjar. The two Telegram samples below were pulled by their runtime C2 contact, not by signature, so they’re confirmed live.

In app command server

Instead of a monolithic loop like traditional RAT's, each hooked app stands up a local HTTP server (com.ucreator.syncsocketlib.server.http) with a HandlerRegistry. Every capability is an enum-singleton handler registered under a numbered path. The operator — reachable through the Redis bus / tunnel — issues an HTTP request with JSON params; the handler runs inside the target’s process, with the target’s identity and permissions.

Each handler is an enum that implements HttpHandler; handleRequest parses the request, constructs a *_UcRequest, runs it, and serializes the result straight into the HTTP response body:

Message interception

For _4_101 its base class reads an operator-supplied sql string verbatim, runs it against Telegram’s own SQLite handle, and deserializes each result blob back into a Telegram TL object. There is no query whitelist isParamLegal() only checks the string is non-empty and that ? placeholders match selectionArgs:

So the SQLite access itself is pure reflection into Telegram internals, through a set of …reflect.mirror.org.telegram.* shim classes. RequestHelper grabs the live MessagesStorage.database handle and calls queryFinalized / byteBufferValue / TLdeserialize directly the same path Telegram uses to read its own cache4.db:

2FA & account takeover

The module hooks SRPHelper.getX - the routine Telegram calls while computing the SRP proof for the 2FA cloud password and lifts the password in cleartext from the argument before it’s ever hashed, stashing it in prefs for exfil:

With the password in hand, the TL_account_* surface (reached through the same mirror classes) lets the operator enumerate and reset authorizations, change or confirm the bound phone number, and in the worst case delete the account. Dedicated business classes back the lockout path -Uc_Business_RefuseLogin, Uc_Business_Frozen - so the operator can push the legitimate owner out while keeping the session alive.

C2 & payload delivery

The callback host is not hardcoded as a single value - it’s resolved at runtime from the Redis bus (key Domain:Basics, optionally per-channel), cached in prefs, with a hardcoded fallback. That’s why the observed callback domain rotates between builds (hpncallback.gold5play.com, hpncallback.qianxunlbs.com):

Beacons are signed JSON POSTs to /api/callback/Tg*. ReceptionCommandTask is the command pull device fingerprint + signature header, three retries with quadratic backoff:

Observed callback endpoints (which you can see on VT): /api/callback/TgHeartCallback, /TgRegisterLogCallback, /api/Callback/TgInstallEventCallback, /api/Callback/TgRedisStatusChange, and hw.android.videoflow.cn:9090/api/hwversion/Upload.

Hook delivery is dynamic. The repackaged app doesn’t carry the per-target hook - it fetches an updateinfo manifest from Alibaba OSS and MinIO:

GET http://kfpt.oss-cn-hangzhou.aliyuncs.com/android/app/YingGai/Huuk_TG/tghuuk_PATCH002_updateinfo
GET http://paas.minio.opsapi.cn/fengzhuang-app/hook-tg/tghuuk_PATCH002_updateinfo.json
GET http://kfpt.oss-cn-hangzhou.aliyuncs.com/android/app/YingGai/contacts.vcf
POST http://hpncallback.qianxunlbs.com/api/callback/TgHeartCallback

On the WeChat side the bus is blunter: a Jedis pub/sub subscription keyed on a per-device machine ID, host and credentials hardcoded in a child DEX.

WeChat arm (va_vx)

For contrast: samples containing *va_vx runs WeChat inside a VirtualApp sandbox and exposes the same numbered-command pattern, but its goal is the account, not the chat history. Command _2_0_UploadAppLoginInfo is WeChat-specific and extracts the login identity for a given user id, there is no SQLCipher/WCDB access anywhere in the sample:

From there the flow is harvest > zip app-data > OSS > clone, with a bundled LoginWeChat_v1.0.1.js driving the login and contacts.vcf lifting the address book. The Telegram arm is strictly more invasive so it keeps the real app and reads its database live.

Backend C2 leak

With the help of Jurre, it was found that the operators actually had accidentally leaked their own back end platform via a self hosted GitLab instance. Their typical infrastructure was all entirely IP allowlisted, accept for one Gitlab Instance. Which contained their entire source code for the C2.

Inside was a Spring Cloud microservice swarm which did: the command-dispatch service, the authorization-capture service, the harvest and backup services, the message-bus bridge, and had the code for the Vue admin console the platform's customers log into.

Sitting beside the code was its configuration - bus topics, database and cache endpoints, object-storage buckets - and the full commit history of the team that builds it: roughly three dozen developers, all on China time, still pushing commits this month, at least one on a corporate email domain tied to a Changsha software firm.

The leaked backend reveals that the phone implant is only half of the platform sold as a service: operators run a multi-tenant cloud console that merchants and resellers rent, each command stamped with a merchant id so every customer drives its own slice of the fleet against its own chosen victims.

An operator action becomes a throttled, queued job aimed at a specific hijacked account on a specific handset - REST services build the command and drop it on Kafka, a bridge hands it to RocketMQ (splitting personal-WeChat from WeCom tasks and honoring a delay timer), and it crosses the trust boundary to farmed and victim phones, where the implant runs the real app inside the discussed VirtualApp sandboxs and carries out authorization capture, mass friend-adding, roster and profile harvesting, and whole-account backup. Results and stolen data flow back the other way, through callbacks into harvest and backup services and on into central databases and an Aliyun object-storage bucket where exfiltrated contact files and full app-data archives accumulate.

Holding it all together is a config-driven scheduler - hourly windows from Nacos, randomized daily caps in Redis, per-account behavior budgets. These pace the fleet so its activity reads as human and slips platform risk controls, a practice the code names 养号, “account cultivation.” The teardown showed a phone could be turned against its owner but on review of the backend it shows it being done at fleet scale and as a product.

Note that this backend did not appear to cover implants for Telegram and other messaging services despite there being clear indication that they were targeting those. There were multiple Gitlab instances hosted with only this one exposed, so it's likely that the other repos perhaps are for other types of deployments.

The leaked GitLab gave up more than source code, since the full commit history was there it gave up the people who wrote it. Across the thirteen repositories, the commit history names something like three dozen developers, all working on China time (UTC+8), some with commits landing as recently as this month. The @author tags tie specific people to specific capabilities, though they’re worth reading as persons of interest rather than proven operators. Building the tooling isn’t the same as aiming it at victims, and commit metadata can be forged. With that caveat, here’s the team, down to the committer emails as they appear in the repos:

• Owner / admin. Created the GitLab namespace and stood up the core backend repos (kfpt-business, kfpt-instruct, qszgManager). Committer wudongpeng wu547534740@126.com.
• Lead engineer. About 2,670 commits, owns the robot console and most of the UIs, active into autumn 2026. Committer yangjinyuan yang_150test@126.com.
• Backend lead. Core business logic (kfpt-business, kfpt-data-system, kfpt-instruct, kfpt-utils). Committer zhang.y, GitLab username zy980115, no email in metadata.
• Command dispatch and WeCom auth code grab. Authored kfpt-instruct. Committer kangqijiao 13574128013@163.com.
• Authorization capture (10002 / 9001 / 8030 / 8002). The OAuth code, QR scan, mini program and official account grabs in kfpt-auth. Committer ningzuokun 191332131@qq.com.
• Add friends engine and core. Commits under 敖癸 / 何志刚 from both the personal vampirehgg@qq.com and the corporate hezhigang@tanzhou.cn, Tanzhou (潭州), a Changsha software firm, and the one hard corporate tie in the set.
• VirtualApp sandbox component. Owns the sandbox repository. Committer yishengjian 1214534695@qq.com.
• Still active. Two developers pushed commits within the last week (18373861382@163.com, 997395359@qq.com).

Infra & attribution

The operator core sits on Aliyun + Huawei Cloud under qianxuncc.cn / videoflow.cn / ops*.cn, fronted by a tengine gateway and a .NET Ocelot cloud-phone backend with SRS/RTMP media nodes hosted in Changsha. Three Redis instances and two MQTT endpoints carry control; kfpt (exfil + hooks) and ops-yunguan are the OSS buckets. The throwaway callback and distribution domains (qianxunlbs.com, uzyzx.com, the gold5play subdomains) are already NXDOMAIN so the core gateways stay up.

Attribution lands on a Changsha/Hunan vendor behind three shells, each tied by a different hard artifact: 湖南由创科技 (ICP on ucreater.com, the com.ucreator brand, and a self-signed O=湖南由创科技有限责任公司 cert on videoflow.cn), 长沙速凯网络 (ICP on the C2 apex), and 长沙卓擎电子商务 (Authenticode on uip.exe).

Mapping points to a commercial resale structure, and targeting driven by wallets and OTPs. My assumption is financially-motivated crimeware.

Indicators

Samples (SHA-256)

2fc4bad71eda25b9022ea7cb090d6419911ecd67e50e746b418f8a617a980301  com.ucreator.tg (main_module_2.8.6)
0142749a159be3e41d28f910eebf28b577a282880bd0c2383bd7404189f4ff94  com.uckj.tgx (→ com.ucreator.tgjar)
dcec9640271a782553599197bcb85367971a5bb4aa84c3787d1e49a3f4f9420e  org.thunderdog.challegram (repack, 2024-11)
805834e6b8c12e180117a1816b48e387c33b53520f5a91cbf858441dc895e717  org.telegram.messenger.web (repack, 2024-07)
a90e3ab2b5cf306439a378faf7107a89196116ad7ee4ad5791c2ba8839ba21c4  org.thunderdog.challegram (tgx_QX)
f82ac2c525d1ed82e57b3f27ae689aeda46875a893ca4c42876b3166ba66bb20  com.ucreator.va_vx
99c5be579d218acfd2c7e2662528e7ad32a1a605d8efd1da732c13931bc30c4c  com.ucreator.va_yjb_client (洋葱盒子)
9c8b147f76312e651faabb1411a3270efca984dd8f33bd8ded3ea611c7c583a1  uip.exe (Windows console)

Certs

33f687f3dd7cdf241d7547ec8f5a3ad1ac4b8eb8  va_yjb_client (unique)
3644440f20eb1b5f5342ce06218dd3dfb83f6580  videoflow.cn self-signed certificate — O=湖南由创科技有限责任公司
7A9F9A7E699F84979F22EC1C409DFAB28ACA7CAE  uip.exe Authenticode — 长沙卓擎电子商务有限公司

C2 / endpoints

Callback hosts:
hpncallback.gold5play.com
hpncallback.qianxunlbs.com
Redis key: Domain:Basics (both NXDOMAIN)

Callback API:
/api/callback/{TgHeartCallback,TgRegisterLogCallback,TgReceptionCommandCallback}
/api/Callback/{TgInstallEventCallback,TgRedisStatusChange}

Version upload:
hw.android.videoflow.cn:9090/api/hwversion/Upload
121.37.194.194 (LIVE)

Hook delivery:
kfpt.oss-cn-hangzhou.aliyuncs.com/android/app/YingGai/Huuk_<TARGET>/
paas.minio.opsapi.cn/fengzhuang-app/hook-<target>/ (NXDOMAIN)

Exfiltration paths:
/android/app/YingGai/contacts.vcf
/MediaRes/contacts.txt
/Scripts/LoginWeChat_v1.0.1.js

Redis (va_vx):
r-bp1jehsclgbuu48m7tpd.redis.rds.aliyuncs.com:65531
Password redacted

Redis (sandbox):
159.138.229.12:26379
159.138.237.10:32115
Huawei Cloud

Proxy:
s5.ips5.cn/api/socks5/getGlobalS5Resource
43.225.141.209 (Thailand)

Distribution host:
telegram-apk.uzyzx.com/telegram/getfirebase (NXDOMAIN)