STA — UTF-16 Serialization Density Experiment v0.2

Structured Text Amplification

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 libminikin with 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.

⏳ Status: Experimental

This tool measures encoding density and estimates Android Parcel / Binder size. It does not assert that these differences cause resource amplification. The goal is to quantify differences and explore correlation with STA behaviour.

🔬 Hypothesis under investigation:

Differences in UTF-16 representation (especially non-BMP characters) may shift the effective thresholds for Binder transaction limits, FragmentManager, libminikin and TaskPersister.

Character:

Code points:

(or click a character)

Generated string (70,000 code points):

📦 Estimated Parcel / Binder size

📐 Code-point equivalence: —

Number of code points of another character needed to match the current UTF-16 footprint.

📊 Comparison at same code-point length

Character	Code points	UTF-16 units	UTF-16 bytes	UTF-8 bytes	Ratio	Bytes / CP	Est. Parcel

🔍 Threshold exploration (Binder)

Current test: —

ASCII baseline (code points): (70k ASCII ≈ 140 KB UTF-16)

Equivalent code points of current character to match baseline UTF-16: —

📈 UTF-16 units vs code points

● BMP | ● Non-BMP | dashed line = 1:1 identity

📘 About this tool (v0.3 improvements):

Added estimated Parcel size (writeString + Bundle overhead + 4-byte padding).
Clear Binder risk levels: Safe (<100 KB), Warning (100-500 KB), Danger (>500 KB practical limit).
Custom character support + dark mode.
Export observations as JSON for collaborative #STAresearch.
More accurate equivalence and threshold calculations.
This remains a measurement tool. Security conclusions belong to the full STA research.

⬆ Back to the experiment

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.

📌 Published:
✅ STA — UTF-16 Serialization Density Experiment

📌 Coming next:
⬜ STA — Finding the Binder threshold
⬜ STA-005 — WhatsApp
⬜ STA-015-DL — Google Drive → SystemUI
⬜ STA-017 — Cross-engine ANR

— Lostmon · lostmon.blogspot.com

Lostmon Blogger