inliver233
cf636c4263
New reference: - dart-aot.md: pinning the Dart version, building a matching decompiler, the object-pool model and reference indexes, register/boolean conventions, the three assembly signatures that identify most business logic, the locating workflow, patch strategy, and the traps specific to this layer (including ambiguous identifiers that resolve to protocol fields). New scripts (parameterized, no machine-specific paths): - dart_pprefs.py: object-pool offset -> code-site index, decoded arithmetically. Avoids the full-capstone pass that costs minutes and 1-2 GB and reads as a hang. - dart_pool_strings.py: framed literal recovery with file offsets. Defaults to one-byte because automatic two-byte (UTF-16) detection is unreliable; --find searches both encodings and is the reliable way to locate a known literal. - dart_disasm.py: annotated windowed disassembly (pool + boolean annotations) and a B/BL caller index that needs no disassembler. Fixes and integration: - framework-runtimes.md: point the Dart depth at dart-aot.md, and make the string-encoding rule precise (ASCII is one-byte/UTF-8; CJK is UTF-16LE) instead of leaving it as 'try both'. - pitfalls.md: P26 -- self-built tooling that fails in a way that reads as a target finding (silent arithmetic, helper shadowing a stdlib module, measuring against an incomplete reference, and a knob that does not move the metric). - SKILL.md / README.md: index the new reference and scripts. Validated by running all three scripts against a real Dart AOT sample: the pool-ref index agrees with an independently built index to 99.2%, and the literal extractor's one-byte output was verified string-by-string against a decompiler's pool listing.
121 lines
7.0 KiB
Markdown
121 lines
7.0 KiB
Markdown
# Cross-Platform Runtimes
|
|
|
|
Load this when the app's UI is not native, or when Java-layer hooks produce no hits at all.
|
|
|
|
Many apps ship a native shell plus a cross-platform runtime. Their business logic, their UI, and their
|
|
feature gates live **inside the runtime**, not in the dex. Patching the dex then does nothing — the Java
|
|
code you can see is mostly glue. Determine the runtime before choosing where to patch.
|
|
|
|
## Identify the runtime early
|
|
|
|
Signals in the APK:
|
|
|
|
| Runtime | Giveaways |
|
|
|---|---|
|
|
| Flutter | `libflutter.so`, `libapp.so`, `assets/flutter_assets/`, Dart snapshot |
|
|
| React Native | `libhermes.so` or `libjsc.so`, `index.android.bundle`, `assets/index.android.bundle` |
|
|
| Unity | `libunity.so`, `libil2cpp.so`, `assets/bin/Data/`, `globalgamemanagers` |
|
|
| Cordova / Ionic | `assets/www/`, `cordova.js` |
|
|
| Xamarin / .NET | `libmonodroid.so`, `assemblies/` in the APK |
|
|
|
|
A `classes.dex` that is small relative to the total payload is another strong hint that the real code
|
|
lives elsewhere.
|
|
|
|
## The layer trap
|
|
|
|
The expensive mistake: seeing a UI element (dialog, paywall, gate) and assuming it is a native control,
|
|
then spending a long time looking for it in the dex.
|
|
|
|
If it is drawn by the runtime, the dex contains only the bridge. Symptoms of being on the wrong layer:
|
|
|
|
- hooking the obvious Java dialog/Activity classes produces **zero** hits while the UI clearly appears;
|
|
- the classes that do appear in stacks are the runtime's own, with obfuscated names;
|
|
- hooking a Java method changes nothing about the visible behaviour.
|
|
|
|
Establish layer ownership **before** investing in a patch direction.
|
|
|
|
### How to tell which layer drew a given UI
|
|
|
|
1. Enumerate the Java dialog and presentation classes and hook their show/creation paths.
|
|
2. Reproduce the UI. If any hook fires, the caller stack names the detection and you are on the Java
|
|
layer.
|
|
3. If nothing fires while the UI is on screen, the UI is runtime-drawn or native-drawn. Switch axis.
|
|
4. Expect runtime-owned windows to appear as ordinary system `Dialog`/`Presentation` objects used as
|
|
**containers** for the runtime's surface. A hit on such a container is not evidence that the visible
|
|
element is a native dialog — read the class name carefully before drawing conclusions.
|
|
|
|
## Flutter specifics
|
|
|
|
- Business logic is compiled ahead-of-time into **`libapp.so`**; UI is rendered by `libflutter.so` with
|
|
no per-widget Java objects.
|
|
- **Widgets, dialogs, and paywalls are not Java views.** They will never appear in Java stack traces,
|
|
and no Java hook can intercept them.
|
|
- The Java side is thin: one Activity, plus plugin classes. Calls cross the boundary through the
|
|
platform-channel mechanism, whose class names are frequently obfuscated.
|
|
- Because channel classes may be renamed, locate them **by method signature and call shape**, not by
|
|
class name.
|
|
|
|
### Where to intervene in a Flutter app
|
|
|
|
| Goal | Layer | Notes |
|
|
|---|---|---|
|
|
| Stop the app being killed / refused at startup | host native library | earliest point, see `native-and-so.md` |
|
|
| Observe what the runtime is told | platform channel | shows the messages that drive the UI |
|
|
| Change a decision permanently | `libapp.so` | most direct, hardest to locate |
|
|
| Change startup behaviour only | host native library constructor | survives runtime restarts |
|
|
|
|
Editing `libapp.so` is the most durable but locating Dart AOT code is genuinely hard. This subject is
|
|
large enough to have its own reference: **`references/dart-aot.md`** covers pinning the Dart version,
|
|
building a decompiler for exactly that version, the object-pool model and how to index it, the register
|
|
and boolean conventions, the three assembly signatures that identify most business logic, the locating
|
|
workflow, and how to patch this layer safely.
|
|
|
|
## Locating logic without symbols
|
|
|
|
- **Strings first.** User-visible text (dialog bodies, feature labels) is the cheapest anchor in any
|
|
runtime. Find it, then find what references it.
|
|
- **Search them in the encoding the runtime actually uses, or you will conclude they do not exist.**
|
|
This is the single most common false negative in cross-platform work. A runtime snapshot does not
|
|
necessarily store text as UTF-8; UTF-16 (little-endian on these targets) is common and entirely
|
|
valid. A UTF-8 search of such a snapshot returns **zero hits**, which reads as "the strings were
|
|
stripped / encrypted, this route is dead" — and that conclusion is wrong.
|
|
|
|
```python
|
|
blob = open('libapp.so', 'rb').read() # or whichever artifact holds the snapshot
|
|
for phrase in ('<feature label>', '<dialog title>'):
|
|
print(phrase, 'utf-8:', blob.find(phrase.encode('utf-8')),
|
|
'utf-16le:', blob.find(phrase.encode('utf-16-le')))
|
|
```
|
|
|
|
Try both, and try a short distinctive substring rather than a long phrase. Which encoding applies
|
|
is predictable rather than random: in a Dart AOT snapshot ASCII literals are stored one-byte (a
|
|
UTF-8 search finds them) while CJK / non-Latin literals are UTF-16LE (a UTF-8 search returns zero).
|
|
`dart-aot.md` §7 gives the exact framing, and `scripts/dart_pool_strings.py --find` locates either
|
|
encoding by file offset.
|
|
- **A phrase that is absent may simply never exist as one literal.** UI text is often assembled from
|
|
fragments or templates, so "the whole sentence" can be missing while both halves are present.
|
|
Search the shortest distinctive token, and expect the interesting anchor to be a *label* rather
|
|
than a sentence.
|
|
- **Landing on a string tells you where the text lives, not which code decided to show it.** Treat the
|
|
hit as an anchor for reference-hunting, not as the answer.
|
|
- **Compare two builds.** The same feature in a slightly different version often reveals the code path.
|
|
- **Watch the boundary, not the interior.** For cross-platform apps it is usually far cheaper to observe
|
|
what crosses between layers than to reverse the interior of the runtime.
|
|
- **Do not assume the obfuscated names are stable or meaningful.** They are not, and treating them as
|
|
identities leads to conclusions that break on the next build.
|
|
- **Obfuscated identifiers can be non-ASCII and invisible.** Renaming passes can replace class and
|
|
member names with characters outside ASCII (combining marks, variant selectors and similar). If a
|
|
class exists at runtime but "cannot be found" by the name you read from a decompiler, suspect
|
|
encoding or normalisation in your tooling rather than a missing class. Resolve such members by
|
|
**shape** — parameter counts, types, interface implementation — instead of by name, and prefer
|
|
runtime enumeration of loaded classes over guessing identifiers.
|
|
|
|
## What this changes about your plan
|
|
|
|
- Budget for the runtime layer **up front**. If the app is Flutter/RN/Unity, the dex is not the main
|
|
battlefield and a dex-only plan will stall.
|
|
- Any behavioural claim must be validated **through the runtime's own UI**, because that is what the
|
|
user sees. A patch that changes internal state without changing the UI is not a fix.
|
|
- Keep the layer you are working in explicit in your notes. "Patched the paywall" is meaningless without
|
|
saying which layer owned it.
|