STA — UTF-16 Serialization Density Experiment v0.3
Structured Text Amplification — Vector 028
This post is part of the series documenting the 32 vectors of Structured Text Amplification (STA). The experiment presented here explores a fundamental property of Android: how the choice of characters in a string affects its in-memory size and, consequently, its ability to exhaust Binder limits and saturate the libminikin text engine.
The complete whitepaper, version v6, covers the research, methodology, evidence, and full vector catalog.
The experiment
Android stores strings internally in UTF-16. This means that the in-memory size of a string does not directly correlate with the number of characters (code points) or its UTF-8 size. The same number of characters can have very different UTF-16 footprints.
For example:
- 70,000 ASCII characters (
/) occupy 140,000 bytes in UTF-16 (×2). - 70,000 emojis (non-BMP,
π) occupy 280,000 bytes in UTF-16 (×4).
This raises a key question for STA:
Can an attacker choose characters that maximize the UTF-16 footprint to reach the Binder limit (1 MB) with less input, or to saturate
libminikinwith more UTF-16 units?
The experiment I present here answers this question. The interactive tool I developed (v0.3) allows you to measure the UTF-16 density of any character, estimate Parcel/Binder size, and systematically explore thresholds.
The interactive tool
The following tool (PoC) measures the encoding properties of different characters and estimates the size they would occupy in a Binder transaction.
Key results
1. Different characters, different footprints
The following table shows the UTF-16 footprint of different characters for the same number of code points (70,000):
| Character | Code points | UTF-16 bytes | UTF-8 bytes | UTF-16 / UTF-8 ratio |
|---|---|---|---|---|
/ (ASCII) | 70,000 | 140,000 | 70,000 | 2.00× |
€ (Euro) | 70,000 | 140,000 | 210,000 | 0.67× |
δΈ (CJK) | 70,000 | 140,000 | 210,000 | 0.67× |
π (Emoji) | 70,000 | 280,000 | 280,000 | 1.00× |
π (Musical) | 70,000 | 280,000 | 280,000 | 1.00× |
Key observation: ASCII characters double in size when converted to UTF-16. Non-BMP characters (emojis) are more compact in UTF-16 relative to UTF-8, but they occupy 4 bytes per character in memory.
2. Code-point equivalence
To match the UTF-16 footprint of 70,000 ASCII characters (140,000 bytes):
- You need 35,000 emojis (
π) to reach the same 140,000 bytes. - You need 70,000 Euro characters (
€) to reach the same 140,000 bytes.
This means the attacker can choose characters to control the relationship between code points and UTF-16 footprint.
3. Parcel / Binder estimation
The v0.3 tool estimates the actual size the string would occupy in a Binder transaction, including:
writeString()size (4-byte length + UTF-16 data + padding)Bundle.putString()overhead (~44 additional bytes)
Binder risk is classified as:
- SAFE (<100 KB)
- WARNING (100-500 KB) — practical risk zone
- DANGER (>500 KB) — very likely
TransactionTooLargeException
The practical limit on many devices is around 500-520 KB, although the theoretical limit is 1 MB.
Implications for STA
This experiment demonstrates that an attacker can control the amplification by choosing specific characters. This affects:
Class A — Binder / SavedState / FragmentManager
- STA-005 (WhatsApp): ASCII payload doubles in UTF-16, accelerating the Binder limit.
- STA-012 (Threads): The attacker can choose ASCII to maximize Bundle size.
- STA-015-DL (SystemUI): Corrupted state persists; UTF-16 size determines whether the limit is exceeded.
- STA-022 (DuckDuckGo): 920 KB URL → 965 KB Parcel; with ASCII, the limit is reached faster.
Class B — libminikin / UI thread
- STA-017 (Chrome/Firefox): More UTF-16 units → more O(n²) work for the line breaker.
- STA-019 (Firefox address bar): The attacker controls the layout workload.
The ×20.6 factor in STA-005
The amplification factor observed in WhatsApp (×20.6) includes:
- Encoding amplification: ASCII → UTF-16 (×2)
- Structural amplification: FragmentManager adds metadata and overhead (×10+)
Key thresholds
| Metric | Value | Notes |
|---|---|---|
| Theoretical Binder limit | 1,048,576 bytes | Documented in AOSP |
| Practical limit on many devices | ~500-520 KB | Before TransactionTooLargeException |
| ASCII characters to reach 1 MB | 524,288 | ≈ half a million |
| Non-BMP characters to reach 1 MB | 262,144 | ≈ a quarter million |
Collaboration
The experiment includes an observation logger that allows you to save results with device, Android version, and observed STA behaviour. Observations can be exported as JSON for collaborative analysis.
If you have access to a device running a different Android version or OEM skin, run the experiment and share your results with the hashtag #STAresearch.
Methodological note
This experiment is a measurement tool, not a vulnerability in itself. It measures encoding properties that may correlate with STA behaviour observed in other vectors. The security impact is evaluated in the Class A and Class B vectors, not in the PoC itself.
Parcel/Binder estimates are approximate and may vary across devices, Android versions, and framework implementations. The PoC provides a quantitative basis for experimental exploration.
Complete whitepaper: Resilience Gaps in Android IPC, SavedState and Text Layout — v6 (August 2026)
— Lostmon · lostmon.blogspot.com
Posts
