Key Findings#

• The client check data encryption path is semantically AES-128-CBC: data is processed in 16-byte blocks, each block is XORed with the IV or previous ciphertext block, then encrypted.
• The runtime is not a normal AES implementation. It is a PB-template-driven white-box table interpreter: runtime code = interpreter, PB template = concrete AES instance.
• 00000008 has a weak FinalTable shape. Each byte lane can be fitted as an AES final-round SBox lane, yielding the round-10 key and then the AES-128 master key through inverse key schedule.
• 00000003 adds byte-level encoding. Its FinalTable no longer directly reveals the final-round key, but the hidden XOR coordinates can still be recovered from TableValue, allowing first-round TableKey fitting.
• In 8.7.0, the VER08 template is best modeled as descriptor plus template blob plus length plus transform gateway. The gateway materializes protobuf wire records into a typed object before the later OLLVM-style table interpreter consumes them.
• The IV is not a cryptanalytic problem. It is a CBC chaining value carried by the template. Stronger protection needs per-message IV policy, template integrity, stronger table encoding, and cross-byte fusion.
• The page challenge is generated by an edge function. Every refresh produces a random hex input and the corresponding 03/08 AES-CBC ciphertexts for validation against a hook, offline interpreter, or recovered standard AES implementation.

Edge-Generated White-Box AES Challenge#

The vector below is generated when the page loads. Every refresh creates a new 24-byte hex input. The server applies the client check data block-padding semantics and returns ciphertext for both 00000008 and 00000003 profiles.

The browser receives only the input, lengths, padding mode, and ciphertexts. The profile key/IV material is used server-side.

If the card says the server profile is not configured, the deployment has not received the 03/08 equivalent profiles yet. The edge function fails closed and does not return placeholder ciphertext.

Start With Plain AES-CBC#

White-box AES is easier to understand once the plain CBC layer is clear:

1
ciphertext = AES-CBC-Encrypt(key, iv, plaintext)

CBC mode is short:

1
C[-1] = IV
2

3
for each 16-byte plaintext block P[i]:
4
    X[i] = P[i] xor C[i-1]
5
    C[i] = AES_Encrypt(K, X[i])

AES-128 block encryption then follows the familiar round structure:

1
state = input
2
state = AddRoundKey(state, K0)
3

4
for round 1..9:
5
    state = SubBytes(state)
6
    state = ShiftRows(state)
7
    state = MixColumns(state)
8
    state = AddRoundKey(state, Kround)
9

10
state = SubBytes(state)
11
state = ShiftRows(state)
12
state = AddRoundKey(state, K10)

SubBytes is the byte SBox, ShiftRows rotates rows in the 4x4 state, MixColumns linearly mixes each column, and AddRoundKey XORs round-key bytes into the state. AES-128 has eleven round keys, K0..K10.

A normal implementation often exposes AES constants, SBox tables, T-tables, key schedule code, or a library call boundary. A white-box implementation tries to remove those obvious shapes from source code by folding them into tables.

The White-Box Intuition: Turn Formulae Into Tables#

A normal AES round can be viewed as:

1
output_column = MixColumns(SubBytes(input_column xor round_key_column))

A white-box implementation precomputes pieces of that relation:

1
TableKey[position][input_byte] -> contribution bytes

The runtime uses the current state byte as a lookup index, obtains contribution bytes, and then combines those contributions through another table:

1
TableValue[encoded_contribution_0, encoded_contribution_1, ...] -> output_byte

The source no longer contains a clear SBox[x xor key] expression, nor a visible MixColumns formula such as 2*x ^ 3*y ^ z. It mostly contains indexing, offsets, and byte movement.

For the 03/08 family, the core model is:

1
runtime code = generic table interpreter
2
PB template   = concrete AES-CBC instance

Changing the PB template changes the profile while the interpreter remains the same.

ClientCheckData Encryption Flow#

At the outer layer, the dataflow is:

Inside the interpreter:

Several boundaries are useful during analysis:

• CBC XOR is visible, so block boundaries are clear.
• Transpose and TransposeBack convert between byte arrays and AES-like state layout.
• ShiftRows remains visible and appears after each round.
• The nine main rounds become TableKey -> TableValue -> ShiftRows.
• The AES final round is collapsed into FinalTable.

This is not AES disappearing. It is AES represented as a table interpreter.

The 8.7.0 VER08 Template Boundary#

In the 8.7.0 client check data path, VER08 should not be understood as an isolated AES_encrypt() function. The cleaner boundary is:

1
collect CCD fields
2
  -> build dataBody
3
    -> build middle wrapper with field 3 = dataBody
4
      -> zlib-compatible compression
5
        -> VER08 AES-CBC-compatible envelope
6
          -> outer ccData

The white-box AES layer is only the envelope layer. If a hook or offline validator mixes raw business fields, the pre-compression wrapper, compressed bytes, and white-box entry bytes, it will produce false algorithm mismatches.

The 8.7.0 VER08 entry can be modeled with four pieces:

1
template descriptor
2
template blob
3
template length
4
transform gateway

1
ADRL X8, dword_11D077548
2
LDR  W21, [X8]
3
...
4
ADRL X1, unk_11D036528
5
ADRL X2, unk_11D037454
6
MOV  X3, X21
7
MOV  X4, X20
8
BL   sub_1129E7A20

1
dword_11D077548 -> template length word
2
unk_11D036528   -> template descriptor
3
unk_11D037454   -> template blob
4
X21             -> template length value
5
X20             -> scratch / arena-like context
6
sub_1129E7A20   -> VER08 template/table expansion gateway

1
wire-format template parser
2
  -> descriptor-backed object materializer
3
    -> table expansion / transform gateway

1
void sub_1129E7A20(
2
    VerObject *out,
3
    VerDescriptor *descriptor,
4
    uint8_t *blob,
5
    int blob_len,
6
    Arena *arena_or_scratch);

1
struct WireRecord {
2
    uint32_t tag;  // protobuf wire tag, field_number = tag >> 3
3
    uint32_t lo;   // scalar low bits or value start offset
4
    uint32_t hi;   // scalar high bits or value end offset
5
};

1
initial record storage: stack scratch, capacity 18
2
growth path: heap array, capacity grows in 0x40-record chunks
3
record size: 0x0c
4
supported wire types: 0, 1, 2, 5
5
rejected wire types: 3, 4
6
length-delimited values: stored as source offsets, not copied immediately

1
entry array pointer: 0x11d036108
2
entry count:         22
3
entry size:          0x30
4

5
fields 1,2:   type 12, flag 1
6
field 3:      type 5,  flag 1
7
fields 4-8:   type 12, flag 0
8
fields 9-12:  type 12, flag 1
9
fields 13-21: type 12, flag 0
10
field 50:     type 13, flag 0

1
0x1129ea26c..0x1129ea288
2
  type-12 bytes/slice materialization:
3
  stores source pointer and length
4

5
0x1129e8a54..0x1129e8a70
6
  scalar/simple materialization into typed field object
7

8
0x1129ea000..0x1129ea044
9
  nested-message handler exists,
10
  but top-level VER08 table fields use bytes/slice slots

What Lives In The PB Template#

The template is a protobuf wire-format blob. Its fields can be understood by role:

For 8.7.0 VER08, the roles are more concrete:

1
field 1   version selector: "00000008"
2
field 2   16-byte CBC IV
3
field 3   scalar control parameter, observed as 0x3060
4
field 9   small required table block, 0x80 bytes
5
field 10  large TableKey block, 0x24000 bytes
6
field 11  small required table block, 0x40 bytes
7
field 12  large TableValue block, 0x1b000 bytes
8
field 18  FinalTable block, 0x1000 bytes
9
field 50  scalar profile parameter, observed as 3

The same descriptor family also reserves optional slots that are not the main table carriers for the current VER08 instance. This matters for version migration: when a later version shifts field numbers, start by recovering the roles of version, IV, large table blocks, scalar control, and gateway xrefs rather than searching for a raw key.

The large table sizes mirror AES structure:

1
TableKey   = 9 rounds * 16 positions * 256 inputs * 4 contribution bytes
2
TableValue = 9 rounds * 16 output positions * 0x300-byte combiner windows
3
FinalTable = 16 positions * 256 entries

These are not arbitrary constants. They align with the 16-byte AES state, the nine rounds that include MixColumns, and the final round without MixColumns.

Single-Block Semantics#

After reducing implementation detail, one block can be described as:

1
state = Transpose(plainBlock xor chainingBlock)
2
state = ShiftRows(state)
3

4
for round = 0..8:
5
    secTable = TableKey[round](state)
6
    state = TableValue[round](secTable)
7
    state = ShiftRows(state)
8

9
state = FinalTable(state)
10
cipherBlock = TransposeBack(state)

On 8.7.0 VER08, that plan can be grounded in field windows:

1
CBCXor with field 2 IV
2
Transpose4x4
3
ShiftRows
4

5
for round = 0..8:
6
    read field 10 TableKey window at round * 0x4000
7
    read field 12 TableValue window at round * 0x3000
8
    ShiftRows
9

10
read field 18 FinalTable
11
TransposeBack4x4

That rhythm is what deserves trace labels: the 0x4000-sized TableKey round window, the 0x3000-sized TableValue round window, the stable ShiftRows interval, and the separate final table.

Compared with normal AES:

Once a trace reveals these boundaries, the AES shape is already mostly exposed.

How Trace Locates The Algorithm#

Searching for AES, SBox, or CBC strings is usually weak. The better route is to compress behavior from the boundary inward.

First, observe length behavior. The ciphertext length is always a multiple of 16. Non-aligned input is padded to the next block; aligned input does not receive an extra full block. That padding behavior is a useful boundary marker.

Second, observe chaining. The first plaintext block is XORed with a 16-byte initial block, and later plaintext blocks are XORed with the previous ciphertext block. That is the CBC shell.

Third, observe state layout. After CBC XOR, the 16 bytes are transposed into a 4x4 state and then shifted by AES row rules. Transpose + ShiftRows is a strong AES fingerprint.

Fourth, observe the 64-byte intermediate buffer. Each TableKey round takes 16 state bytes and emits four contribution bytes for each one. That gives a 64-byte secTable, matching the idea of byte-level contribution generation.

Fifth, observe TableValue access. It does not simply XOR four bytes in source. Each output byte walks three nibble-level lookup stages. In 08 this is semantically close to XOR; in 03 the same shape is encoded into hidden coordinates.

The trace then becomes a named pipeline:

1
padding
2
  -> CBC chaining
3
    -> state transpose
4
      -> visible ShiftRows
5
        -> TableKey contribution
6
          -> TableValue combiner
7
            -> FinalTable
8
              -> ciphertext

That naming is the move from runtime trace to semantic algorithm recovery.

00000008: Why FinalTable Leaks The Last-Round Key#

00000008 is the more direct profile. TableValue is table-driven, but semantically close to XOR. TableKey contributions are close to raw MixColumns contributions. The most important weakness is FinalTable.

Each final lane is:

1
FinalTable[position][x] -> y

For 08, each lane can be fitted as:

1
T[x] = SBox[x xor a] xor b

a is input-side material absorbed by the table, while b corresponds to a byte of the last-round key. Fitting is simple:

1
for a in 0..255:
2
    b = T[0] xor SBox[a]
3
    if T[x] == SBox[x xor a] xor b for every x:
4
        recover b

Repeat that for 16 lanes, reorder from state position to ciphertext position, and the AES round-10 key is recovered:

1
FinalTable
2
  -> 16 lane SBox fit
3
    -> round10 key
4
      -> inverse AES-128 key schedule
5
        -> master key

The AES-128 key schedule is reversible. Given K10, walking the schedule backward yields the master key.

The IV is more direct: it is carried by the template as the CBC initial chaining block.

For 08, the recovery route is therefore:

1
field18 FinalTable -> round10 key -> master key
2
field2 IV          -> IV

That is table-driven AES-CBC, not a strong extraction-resistant white-box design.

00000003: More White-Box-Like, Still Recoverable#

00000003 improves on 08. Its FinalTable no longer directly fits SBox[x xor a] xor b, and TableKey contribution bytes are not raw MixColumns contribution in the current byte coordinate.

It blocks the shortest 08-style route:

1
FinalTable -> round10 key

However, the complete truth tables are still present. Each 0x100 TableValue subtable can be treated as an encoded binary combiner:

1
encoded_op(encoded_a, encoded_b) -> encoded_sum

The underlying operation is still XOR, but input and output coordinates have been changed. The recovery route is to normalize the binary operation:

1
read binary combiner table
2
  -> find left/right projections
3
    -> recover hidden identity
4
      -> build XOR-isomorphic coordinates
5
        -> decode contribution bytes

Once the hidden XOR coordinates are recovered, first-round TableKey contribution can be fitted back to AES semantics:

1
decoded_contribution ~= affine(coeff * SBox[x xor keyGuess])

coeff is one of the AES MixColumns coefficients 01/02/03. For each key byte, the candidate that matches all 256 inputs is the recovered byte. Since the first round uses the AES master key directly, no inverse key schedule is needed.

The 03 recovery route is:

1
TableValue
2
  -> recover hidden XOR coordinates
3
    -> decode first-round contribution
4
      -> fit coeff * SBox[x xor keyGuess]
5
        -> master key
6

7
field2
8
  -> IV

It is harder than 08, but still a PB-only recovery because the template carries the complete algorithm instance.

03 vs 08#

03 raises the cost of simple pattern matching and static fitting. A script that directly searches SBox-like final lanes will work on 08 but not on 03. Still, the deeper structures remain:

• complete truth tables are readable;
• output bytes are not strongly fused;
• round boundaries are stable;
• CBC boundaries are stable;
• the IV is template-provided;
• there is no per-build binding material or runtime-derived table in the core semantics.

So 03 is better described as encoded table-driven AES, not a strong white-box design.

From Key/IV Recovery To Semantic Proof#

Recovering key and IV is only the first step. The useful proof is equivalence.

The first layer is single-block verification, including non-aligned inputs so padding participates in the computation.

The second layer is multi-block verification, which exercises CBC chaining. It is not enough to validate AES block encryption alone.

The third layer is profile verification. 08 and 03 take different recovery routes, but both should land on the same abstract interface:

1
encrypt_client_check_data(profile, plaintext_hex) -> cipher_hex

The page challenge is a lightweight entry point for this proof. Refresh the page, take the generated input and ciphertexts, and compare them with a hook boundary, an offline interpreter, or a recovered standard AES-CBC implementation.

Reverse Validation With A Hook#

The hook should not patch the return value. That would destroy the verification. The clean approach is to replace the input once at the encryption boundary, then observe the real ciphertext produced by the runtime path.

The boundary can be modeled as:

1
encrypt_client_check_data(input_bytes) -> cipher_bytes

Record four fields:

1
page.input_hex
2
runtime input after patch
3
runtime cipher_hex
4
page.cipher_hex

When all four align, the edge AES-CBC equivalent implementation, the local encryption boundary, and the recovered 03/08 profile are referring to the same semantics.

A Frida script should start read-only. Confirm argument length, output length, and timing first, then perform one controlled input replacement:

Use a four-step workflow:

1. Observe first, do not write memory. Confirm the function receives envelope plaintext, not raw CCD fields or the pre-compression wrapper.
2. Record the input pointer, input length, output location, and output length. Output length must be a multiple of 16; non-aligned input should only pad to the next block.
3. Replace input once. The replacement length must exactly match the page input_hex length to avoid breaking the caller’s buffer lifetime.
4. Read the real runtime ciphertext in onLeave, then compare it with the page 00000008 or 00000003 cipher_hex.

Jailbroken attach and Frida Gadget repackaging differ only in script loading, not in validation logic. In a jailbroken lab, attach after the process is stable. In a repackaged lab, let Gadget load the same script after initialization. The script should not publish hard-coded addresses; resolve slide and target boundaries inside the authorized local environment.

1
const challenge = {
2
  profile: "00000008",
3
  inputHex: "<page-input-hex>",
4
  expectedCipherHex: "<page-cipher-hex>",
5
};
6

7
const targetAddress = ptr("<locally-resolved-envelope-entry>");
8
let patchedOnce = false;
9

10
function hexToBytes(hex) {
11
  const out = new Uint8Array(hex.length / 2);
12
  for (let i = 0; i < out.length; i++) {
13
    out[i] = parseInt(hex.slice(i * 2, i * 2 + 2), 16);
14
  }
15
  return out;
16
}
17

18
function readHex(ptrValue, length) {
19
  return Array.from(new Uint8Array(ptrValue.readByteArray(length)))
20
    .map((value) => value.toString(16).padStart(2, "0"))
21
    .join("");
22
}
23

24
Interceptor.attach(targetAddress, {
25
  onEnter(args) {
26
    const input = resolveInputBuffer(args);
27
    const length = resolveInputLength(args);
28
    const expectedLength = challenge.inputHex.length / 2;
29

30
    this.check = false;
31
    if (patchedOnce || length !== expectedLength) {
32
      return;
33
    }
34

35
    this.beforeHex = readHex(input, length);
36
    input.writeByteArray(hexToBytes(challenge.inputHex));
37
    patchedOnce = true;
38
    this.check = true;
39
  },
40
  onLeave(retval) {
41
    if (!this.check) return;
42
    const cipher = resolveOutputBuffer(retval, this);
43
    const cipherLength = challenge.expectedCipherHex.length / 2;
44
    const cipherHex = readHex(cipher, cipherLength);
45

46
    console.log(JSON.stringify({
47
      profile: challenge.profile,
48
      input_before: this.beforeHex,
49
      input_after: challenge.inputHex,
50
      cipher_runtime: cipherHex,
51
      cipher_expected: challenge.expectedCipherHex,
52
      matched: cipherHex === challenge.expectedCipherHex,
53
    }));
54
  },
55
});

resolveInputBuffer, resolveInputLength, and resolveOutputBuffer depend on the local boundary. Keep the patch near the white-box AES envelope entry. Patching higher-level business objects or lower-level ciphertext destroys the clarity of the test.

If runtime output does not match the page ciphertext, check these first:

• whether the hook point is after compression and before the white-box envelope;
• whether injected input length exactly matches page input_hex;
• whether the captured output buffer belongs to the current call rather than a reused previous result;
• whether the selected profile is wrong, because 00000008 and 00000003 are not interchangeable;
• whether aligned input was accidentally given an extra padding block.

Why White-Box AES Is Hard#

White-box cryptography tries to protect key material even when the attacker can observe, debug, and copy the runtime environment. That is much harder than server-side encryption.

The problem with the 03/08 family is not that there is no obfuscation. The problem is that the obfuscation does not remove enough recoverable structure:

• independent FinalTable lanes invite byte-wise analysis;
• full TableValue truth tables allow hidden XOR coordinate recovery;
• per-input TableKey contribution allows SBox/key fitting;
• a static IV is not a security boundary;
• unsigned templates can be analyzed, replaced, or downgraded.

Stronger designs usually combine several measures:

1
input/output external encoding
2
+ cross-byte fusion
3
+ fused rounds
4
+ per-build table layout
5
+ runtime-derived transient tables
6
+ template signature
7
+ per-message IV
8
+ anti-downgrade policy

White-box AES can still have engineering value. It raises extraction cost and preserves protocol compatibility. But it should not be treated as a guarantee that key material can never be recovered.

Reading Path For Beginners#

If this is your first white-box AES case, read it in this order:

1. Understand AES-CBC: blocks, IV, padding, chaining.
2. Understand AES rounds: SBox, ShiftRows, MixColumns, AddRoundKey.
3. Think of SBox[x xor key] as a lookup table.
4. Think of MixColumns as four contributions combined by XOR.
5. Then map the white-box design: TableKey creates contributions, TableValue combines them, FinalTable finishes the round.
6. Finally, read the recovery logic: 08 leaks through final lanes; 03 requires recovering hidden XOR coordinates first.

Viewed this way, white-box AES is not magic. It is standard AES turned into tables and encodings.

FAQ#