ShuMei device fingerprint (shumeiBoxId)

Purpose of the ShuMei (数美) anti-fraud SDK: produce the shumeiBoxId login field. OLLVM-hardened libsmsdk.so + com.ishumei.smantifraud Java.

Identifiers

• smid = deviceprofile/v4 response detail.deviceId, 88 chars
• shumeiBoxId = "B" + smid (89 chars) once assigned; "D"-prefixed local fallback before that; empty is valid
• shumeiId = separate server push ~0.5 s after Login, cached, reported as ta.lw_shumei_id on the next Login

Flow static

SmSdkManager.callCreate() with organization "9dNCYkjHeFMYZMOjxgX8", appId "default", X.509 cert (CN=e.ishumei.com, OU=SM, C==CN), area AREA_FJNY, URLs shumei-api.lastwargame.com:19091 for /deviceprofile/v4 and /v3/cloudconf. Only the background resend adds "retry":1; the error handler triggers for any code except 1902.

Crypto

• cloudconf: hybrid RSA-OAEP (SHA-256 digest + MGF1, empty label) wrapping a per-request AES-256 key; AES-CBC IV "0102030405060708" (16 ASCII bytes).
• deviceprofile (native w1): r = 16 random alphanumerics; key = MD5(r) lowercase hex (32-byte AES-256 key); data = Base64(AES-256-CBC(rawDeflate(aNN-json))); ep = Base64(RSA-OAEP(cert, r)); tn = Base64(RSA-OAEP(cert, "0")), ignored by the server. Raw DEFLATE (RFC 1951), not zlib. Undecryptable bodies → 1902.

Constants & body

os android; sdkver 3.14.3; area fjny → 011; built-in datasites region-pinned on fengkongcloud.com (fp-it, fp-sa-it, fp-na-it-acc + retries), bypassed by the game proxy. Body: top level organization, os, appId, encode (2), compress (3), data, tn, ep; a1…a174 inside the protected data; sdkver/md5/pri/bb belong to cloudconf; smid/appname/sessionId/wevent to the v3 event flow.

• Response codes: 1100 success (detail: deviceId, oldDeviceId, sid, c, t); 1902 generic rejection [live 2026-10-10]; 1903 hard error; empty body → 9101 "invalid organization".
• iOS (1.0.344, build 786, SDK statically linked in UnityFramework.framework): same org/URLs, 1024-bit RSA key at file offset 0x863ffdf. [live 2026-10-12] iOS key + w1 scheme → 1902 under every os value and padding combo tried; the Android 2048-bit key succeeds (1100, 88-char smid) for both ios and android outer os values. The iOS protection scheme is unreversed.

Field specifics

a9 = current time; a171 = host uptime (/proc/uptime / kern.boottime); a170 = a171; a40 = a9 − a171; a80 = session <millis>-<5 digits> (Go port of java.util.Random seeded with millis); a133 = random 150–600 ms; Wi-Fi a19/a30/a31 empty by default (no ACCESS_FINE_LOCATION) — -cs-shumei-ssid/-cs-shumei-bssid add them [live 2026-10-12, both shapes → 1100]; a38 = appVersion matching Login; notCollect = {"input","protect"}; merged exclusions reported as a85 = ["input","tel","gps","protect"]; default cloud config 15,108 bytes decoded (base64 + AES-256-CBC + zlib), sets sensitive.gps/sensitive.tel false; a63 (input methods) never collected.

Per-install state (shumeiInstall)

a24 androidId = 16 random lowercase hex; a84 mediaDrmId = 32 random bytes (Widevine) + ___; a163 puuid = UUID v4; a125 = {fit, lut}, installed 30–400 days ago, updated within 20 days; a126 boxId (absent until first registration); a167/a168 boxIdSavedAt (0 initially); timestamps RFC 3339. An install is bound to one Login deviceId; a different deviceId → fresh install; without the config, every run looks like a new phone.

[live 2026-10-12] three registrations with one install all returned 1100 with different 88-char smids each (fresh / with a126 echo / without) — smid is re-issued on every reply; a minted box id was never stored in the top-level shumeiBoxId.

What this means for enforcement

The server accepts an empty shumeiBoxId (first-class path, client_config switch 25) and a freshly minted one at every login live. The fingerprint does not function as a hardware anchor on the login path — treat any "device ban" claim that leans on ShuMei with suspicion.