apk-reverse/docs/verification-jiongnew/TARGET-FACTS.md

# Target facts — `jiongnew.apk`

Everything here is **observed** unless labelled otherwise. Method: read-only analysis of the APK
(`zipfile` + `androguard` 4.x + direct dex structure parsing) plus install/launch on two devices.
Nothing in this file comes from the handover document — where the handover and the measurements
disagree, the disagreement is recorded.

```
sha256   0C2B063E6D1A3BD05777611ABF2F1A64056E290E4F6728C1B12DC202747DC645
size     74,394,920 B (70.95 MiB)
entries  1,982   (zip testzip() == None)
```

## Manifest

Read with androguard's AXML parser. The handover document warned that hand-reading the binary AXML
gets the class-name prefix wrong; that warning held up — the parser is the reason these values are
trustworthy rather than the string scrape the handover was reduced to.

| Field | Value |
|---|---|
| `package` | `com.tingfeng.tool` |
| `application android:name` | **`app.video.guoguo.GApplication`** |
| `main activity` | `app.video.guoguo.SplashActivity` |
| `versionCode` / `versionName` | `84` / `1.5.8.0` |
| `minSdk` / `targetSdk` / `compileSdk` | `24` / `35` / `34` |
| `extractNativeLibs` | `true` |
| `usesCleartextTraffic` | `true` |
| `debuggable` | absent (release build) |
| `allowBackup` | `false` |
| application tag count | 1 |

Two questions the handover explicitly left open, now closed:

1. **`application android:name` is `app.video.guoguo.GApplication` — not a packer stub.**
   This is an ordinary app class. The handover's string scrape only surfaced a 穿山甲/pangle stub
   and could not rule out a shell; the parsed manifest rules it out. Combined with the absence of
   hardening-library names in the native list, this target has **no packer on the dex side**
   (observed) — though see `FINDINGS.md` for the *loader* signal that muddies this.
2. **The app does not run.** It aborts during startup on every attempt, on two different devices.
   Detail below; this is the single most consequential fact about the target.

Counts: 115 activities, 14 services, 2 receivers, 18 providers, 28 permissions.
All non-app components belong to bundled ad SDKs (kwad/ksad, qq.e, baidu mobads, beizi, sigmob,
meishu, bytedance openlive, windmill) plus Flutter plugins (`io.flutter.plugins.*`, `urllauncher`,
`imagepicker`) and Sentry (`io.sentry.android.core.*`).

## Dex

| File | Bytes | Compressed |
|---|---|---|
| `classes.dex` | 8,636,420 | 3,243,680 |
| `classes2.dex` | 7,910,800 | 2,918,337 |
| `classes3.dex` | 7,067,828 | 2,503,205 |
| `classes4.dex` | 4,032,596 | 1,509,375 |
| **total** | **27,647,644** | 10,174,597 |

Per-dex string-table sizes measured directly from the header (`string_ids_size` at `0x38`):
63,267 / 55,279 / 46,693 / 27,549.

**Cross-check against the handover:** the four dex sizes match the handover's table to the byte.
Also present at APK root and not mentioned in the handover: `DebugProbesKt.bin`,
`kotlin-tooling-metadata.json`, `androidsupportmultidexversion.txt` — a Kotlin app.

## Native libraries

36 libraries, 18 per ABI (`arm64-v8a` + `armeabi-v7a`), total 92,097,048 B uncompressed. The
handover's 36/18+18 count reproduces exactly.

Largest: `lib/armeabi-v7a/libapp.so` 13,730,388 · `lib/arm64-v8a/libapp.so` 12,256,160 ·
`libjingle_peerconnection_so.so` (WebRTC/声网) 11,377,944 / 6,536,952 · `libflutter.so`
10,814,192 / 7,614,304 · `libcore.so` 6,723,088 / 4,937,444 · `libloader.so` 6,221,896 / 4,540,264 ·
`libalivcffmpeg.so` 6,136,472 / 5,092,604 · `libsaasCorePlayer.so` 4,885,216 / 3,440,932 ·
`libsentry.so` 681,784 / 440,816 · `liblua-core.so` 384,472 / 265,796 ·
`libplt-base.so` 373,056 / 245,956 · `libsaasDownloader.so` 354,496 / 267,916 ·
`libdevInfo.so` 280,632 / 153,228 · `libti-monitor.so` 115,872 / 66,324 ·
`libsgcore.so` 92,360 / 112,500 · `libsentry-android.so` 16,832 / 12,080 ·
`libzeus_direct_dex.so` 14,160 / 9,756 · `libpangleflipped.so` 10,064 / 9,756 ·
`libdatastore_shared_counter.so` 7,112 / 4,416.

Packer-name scan (rglob over `libjiagu`, `libDexHelper`, `libnesec`, `libmobisec`, `libsecexe`,
`libshella`, `libsgmain`, `libtup`, `libprotectClass`, `libexec.so`, `libexecmain`, `StubApp`,
`libnativehelper`, `libapktool`): **zero hits**. Consistent with the handover.

`libloader.so` is the interesting one — 6.2 MB with the largest `.dynsym` in the set, and the
reason it was the right sample for `elf_plt.py`. See `TOOL-VERDICTS.md`.

## Flutter / Dart

Pinned from the engine banner, which is the authoritative source and does not depend on symbols:

```
lib/arm64-v8a/libflutter.so @ 0x1fe035:
  3.6.0 (stable) (Thu Dec 5 07:46:24 2024 -0800) on "android_arm64"
```

Snapshot identity, from blutter's own `extract_dart_info`:

```
Dart 3.6.0
Snapshot  f956f595844a2f845a55707faaaa51e4
Target    arm64 / android
Flags     product no-code_comments no-dwarf_stack_traces_mode
          dedup_instructions no-tsan no-msan compressed-pointers
```

So: **Dart 3.6.0, compiled with compressed pointers, in a PRODUCT build with code comments and
Dwarf stack traces stripped.** The `product` flag matters — it is the reason field and local names
are absent at the format level, not merely hard to recover.

`libapp.so` is stripped: `.dynsym` is 144 bytes. Its ELF header is `EM_AARCH64` (e_machine `0xB7`)
for the arm64 ABI and `EM_ARM` (`0x28`) for the v7a one.

No `assets/flutter_assets/version` file exists (21 entries under `flutter_assets/`), so the usual
cheap version probe fails here — the banner above is the reliable route.

**Discrepancy worth recording:** `aotopsy doctor` reports **Dart 3.6.2** for the same
`libapp.so`, while the engine banner and the snapshot hash both say 3.6.0. See `FINDINGS.md`.

## Assets

| Asset | Bytes | Note |
|---|---|---|
| `assets/1274036544` | 6,632,594 | 穿山甲/pangle plugin container (`ZEUS_PLUGIN_PANGLE` in manifest) |
| `assets/gdt_plugin/gdtadv2.jar` | 2,238,863 | 腾讯优量汇 plugin (contains dex) |
| `assets/bdxadsdk.jar` | 1,302,180 | 百度 ad SDK |
| `assets/flutter_assets/assets/jiong_white.zip` | 986,623 | theme resources |
| `assets/flutter_assets/assets/jiong_black.zip` | 986,413 | theme resources |
| `assets/flutter_assets/NOTICES.Z` | 123,708 | Flutter licence bundle |
| `assets/reward.json` | 16,404 | ← see below |
| `assets/feed.json` | 16,251 | ← |
| `assets/splash.json` | 10,843 | ← |
| `assets/intertitial.json` | 10,592 | ← note the spelling |
| `assets/banner.json` | 9,151 | ← |
| `assets/draw.json` | 4,644 | **not in the handover inventory** |
| `assets/fullscreen.json` | 4,201 | **not in the handover inventory** |
| `assets/ksad_idc.json` | 327 | Kuaishou IDC list |
| `assets/dexopt/baseline.prof`, `.profm` | 4,235 / 385 | Kotlin/Android baseline profiles |

Also `assets/flutter_assets/packages/luavm/lua/*.lua` (10 Lua files: dkjson, http, url, ftp, ltn12,
smtp, socket, tp, headers, mbox, mime) and `liblua-core.so` — a third logic surface beside dex and
Dart. Not pursued in this pass.

The handover listed 5 ad-config JSONs; the measurement finds **7**. The two additions
(`draw.json`, `fullscreen.json`) are the same shape as the other five.

**The ad-config JSONs are not ad configuration.** They are test fixtures bundled inside the
美数/meishu aggregation SDK, and their read path is dead code in this build. The load-bearing parts:

- Reader: `classes3.dex` → `Lcom/meishu/sdk/core/utils/TestToolUtil;->getTest{Splash,Banner,
  Intertitial,Fullscreen,Reward,Draw,Feed}Json(Landroid/content/Context;Z)Ljava/lang/String;`
  → `Context.getAssets()` + `const-string/jumbo "splash.json"`. Seven methods, seven filenames. (observed)
- The only callers are `TestToolUtil.getJsonByType` and `AdLoader.getTestData()`, and **neither has
  a single `invoke` referencing it anywhere in the four dex** (coverage: 175,829 method bodies with
  code; the 362 bodies that decoded uncleanly were rechecked by raw byte search for the target
  `method_idx` — zero hits). (observed)
- Dart cannot be the reader: `intertitial` (the distinctive misspelling) has **zero** hits in
  `libapp.so` in both UTF-8 and UTF-16LE, so the Dart side cannot even form the filename. The files
  also sit in `assets/` rather than `assets/flutter_assets/` and are absent from `AssetManifest.json`,
  so `rootBundle` structurally cannot reach them. (observed)
- Content self-identifies as fixture data: `reward.title="测试激励视频"`, `feed.title="测试"`,
  `splash.clk_area="测试测试测试"`, `appstore_id="1234567"`, monitor hosts contain `-demo`. (observed)
- **Runtime confirmation of the dead-path conclusion** (run independently by the lead after the
  static analysis): `getExternalCacheDir()/.adConfig/jsonConfig/` does not exist, and no
  `*adConfig*` / `*jsonConfig*` path exists anywhere under either the external or the private data
  directory. The only directory the app did create under `cache/` is `sentry/`. (observed)
- No on/off field exists in any of the seven files: matching
  `enable|show|switch|open|close|disable|isOpen|isPlay|visible|frequency|interval` yields
  **zero** candidates. (observed)

Consequence: deleting the seven JSONs is safe and pointless — no caller, so no dependency, so no
effect on ads. The handover's hypothesis that "the convergence point is probably the config
consumption layer" is **refuted** for this asset family. The real convergence point is a
two-layer aggregation boundary (Dart `windmill_ad_plugin` ↔ `com.windmill.windmill_ad_plugin`
MethodChannel at `WindmillAd.createAdInstance`, channel names
`com.windmill/{splash,reward,interstitial,banner,native}`; below that
`com.meishu.sdk.core.loader.AdLoader.loadAd` → `https://sdk.1rtb.net/sdk/req_ad` fanning out to
CSJ/GDT/KS/BAIDU/OPPO/HW/TopOn). (observed for the mechanism, inferred for its completeness)

## Launch behaviour — the app does not start

`observed`. This is the fact that constrains everything else.

Installed and launched on the Android 11/arm64 physical device:

```
adb -s SSBYPJKFNVEU6PGA install -r -t jiongnew.apk     -> Success (4.1 s)
   codePath  = /data/app/~~fDojk_Ku0C15jUkrmP36vA==/com.tingfeng.tool-gncxaby8OxxhG9E1TuF3aw==
   primaryCpuAbi = arm64-v8a, versionCode 84, targetSdk 35
adb -s SSBYPJKFNVEU6PGA shell am start -n com.tingfeng.tool/app.video.guoguo.SplashActivity
```

Timeline on the device (logcat):

```
04:41:59.217  Start proc 20512 for pre-top-activity {...SplashActivity}
04:41:59.280  E LoaderLog: 10026 / 101004
04:41:59.307  E Instrumentation: Uninitialized ActivityThread, likely app-created
               Instrumentation, disabling AppComponentFactory
04:41:59.765  I InputDispatcher: Focus entered window ... SplashActivity    <- window shown
04:42:00.297  F libc: FORTIFY: pthread_mutex_lock called on a destroyed mutex (0x7260f77b30)
04:42:00.301  F OpenGLRenderer: Failed to set damage region ... EGL_NOT_INITIALIZED
04:42:00.352  F libc: Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 20512
               (m.tingfeng.tool), pid 20512
04:42:00.409  E DEBUG: failed to open directory /proc/20512/fd: Permission denied
04:42:00.410  F crash_dump64: failed to attach to thread 20512, already traced by 0 ()
04:42:00.411  W tombstoned: crash socket received short read of length 0 (expected 12)
04:42:00.444  I Zygote: Process 20512 exited cleanly (0)
04:42:00.453  I ActivityManager: Process com.tingfeng.tool (pid 20512) has died: fg TOP
```

Survival time ≈ 1.1 s from window focus to abort, ~1.3 s from process start.

**Environmental control (single variable changed):** the same APK on the other attached device —
`emulator-5554`, x86_64, SDK 28, a different ROM and a different ABI — reproduces the identical
signature:

```
05:42:54.501  E LoaderLog: 10020 / 101003
05:42:55.547  F libc: FORTIFY: pthread_mutex_lock called on a destroyed mutex (0x7639156ff120)
05:42:55.855  I Zygote: Process 16507 exited cleanly (0)
```

Same loader line, same FORTIFY abort, ≈1.04 s vs ≈1.07 s. Two devices, two ABIs, two Android
versions, same death. This **rules out** target-specific-to-one-ROM behaviour and rules out a pure
root/Magisk detection as the sole cause. The crash is a property of the app, not of the device.

**The crash channel is owned by a third party.** Three independent signals say so:

1. `crash_dump64` cannot attach — `already traced by 0 ()`. Something else already holds the
   thread via ptrace.
2. No tombstone is written. `/data/tombstones/` newest file is `tombstone_23` from 03:54, while
   this crash happened at 04:42; `tombstoned` logs `crash socket received short read of length 0`.
3. `tombstoned` receives the request for a *different* pid than the one that died
   (`received crash request for pid 23771` while the dying pid was 23813), and `crash_dump64`
   can no longer find the threads (`failed to attach to thread ...: No such process`).

The mechanism is visible in the emulator log immediately before the abort: Sentry's NDK layer is
live and installing itself —

```
05:42:54.877  V libnb: enter native_bridge2_getTrampoline
               Java_io_sentry_ndk_NativeScope_nativeSetTrace, trampoline_addr 0x76391344a080
05:42:54.878  V libnb: ...Java_io_sentry_ndk_NativeScope_nativeAddBreadcrumb, trampoline_addr ...
```

Sentry's native crash handler replaces the signal handlers; the platform handler then cannot
attach and the ordinary evidence trail (tombstone, backtrace, `AndroidRuntime` fatal block) is
destroyed. `libsentry.so` / `libsentry-android.so` are in the APK and
`io.sentry.android.core.SentryInitProvider` is a declared provider. (observed)

**Root cause of the abort itself: not localized.** What is established is the abort site's *shape*
— a `pthread_mutex_lock` on an already-destroyed mutex, on the **main** thread (tid == pid), i.e. a
native lifecycle/teardown ordering bug reached from the startup path, not the fault of an
obfuscation trick or a deliberate anti-tamper abort. Attempts to get a symbolized stack were made
and failed for stated reasons:

- Platform route: impossible. `crash_dump` is pre-empted (above); no tombstone exists to read.
- `setenforce 0` to relax SELinux: rejected — `setenforce: Couldn't set enforcing status to '0':
  Invalid argument`. Permissive mode was not obtainable on this ROM.
- Frida spawn-gating (the documented workaround when platform crash handling is unavailable):
  the device carries a disguised frida-server (`/data/local/tmp/odm_service`, listening
  `127.0.0.1:27099`). `frida-ps -H 127.0.0.1:27099` enumerates processes, but `spawn` fails with
  `Failed to spawn: connection closed`, so the pre-signal-handler window cannot be opened through
  that server. **unverified** whether a plain frida-server would succeed where this one does not.

So the honest statement is: *the app aborts deterministically in native code during startup, on the
main thread, and the platform's ability to show us where has been taken away by a bundled crash
reporter.* The `LoaderLog` line and the app-created `Instrumentation` indicate non-standard startup
plumbing is also in play, but their contribution to the abort is **inferred, not established** —
see `FINDINGS.md` for why that distinction was kept rather than collapsed.

## What this target can and cannot exercise

Kept explicit, because the useful output of this pass is partly a list of what was *not* testable.

| Exercisable | Not exercisable |
|---|---|
| Flutter/Dart AOT analysis (Dart 3.6.0, object pool, call graph) | `native_crash.py`'s "artificially constructed crash" verdict — the crash here is a real internal fault; there is no decoy to detect |
| Multi-dex scale (27.6 MB over 4 files) | `so_constpatch.py`'s "redirect the checker library" scenario — there is **no integrity-check library** in this target |
| `elf_plt.py` at scale (`libloader.so`, 36,974 relocations) | Every hardening scenario in `packers.md` / `code-virtualization-and-custom-linkers.md` — no packer |
| `lib_map.py` against a live process | A **durable** live process at all — the 1.1 s window is the constraint |
| `dart_*` scripts on a real stripped `libapp.so` | Any repack/install verification loop — the unmodified app already fails to start, so there is no working baseline to regress against |
| Config-driven ad analysis (and its refutation) | — |