Help/Support help with Mario Kart Tour iOS IL2CPP dumping — Registration Pointers (static analysis)

[Taylor Meyer 288 iPad (9th gen) 26.2]

@Batch

Hi everyone don't mean to be a bug 

I'm working on dumping Mario Kart Tour (iOS, Unity 2022.3.68f1) using a custom Il2CppDumper and I'm stuck on the correct `Il2CppCodeRegistration` and `Il2CppMetadataRegistration` pointers.  

I think the pointers are correct but whatever I do, it just refuses to dump the Global-Metadata.dat. It might be something with the XOR key? I obtained the Global-Metadata.dat at runtime using iGameGod. Because they embedded the metadata in the iOS binary. I'm also trying to get better at this and learn. (I do not have a jailbroken device)

I've done extensive static analysis already:

 

### Key Findings

- **Metadata Loader**: `sub_2478B14` (0x2478B14) — simple per-dword XOR decryptor.

  - Key: `dword_7AE6128` = `0x20015111`  <--- the key might be wrong but not sure

  - Encrypted table: `dword_5F0FD1C`

  - Called from `sub_518AEF0` (main init function at 0x518AEF0)

 

- **Registration Setup**:

  - `sub_518AEF0` loads decrypted metadata into `qword_7C8CBA0` / `qword_7C8CBA8`

  - Populates `qword_7C8CB98` (CodeRegistration) and `qword_7C8CBC0` (MetadataRegistration)

  - Pointer chain: `unk_5B96820` → `off_70E1050` → `unk_7A1D788`

 

- **Critical Static Pointers** (from detailed xref tracing):
 

 ```c

  #define IL2CPP_OVERRIDE_CODE_REG 0x6E6C478     // 0x6E6C478

  #define IL2CPP_OVERRIDE_META_REG 0x5B96820     // 0x5B96820

  ```

  These come from the stub `sub_24F51D8` which does:
 

 ```arm

  ADRL X0, unk_6E6C478

  ADRL X1, unk_5B96820

  ADRL X2, unk_54F5004

  B    sub_51382B4

  ```

 

I tried 2 different dumpers and none worked, then resorted to running and debugging this one in VS Code via Kilo Code with the Rust Analyzer Via my SuperGrok Oauth Subscription: 

https://github.com/rodroidmods/il2cpp-dumper-rs

Note: I did end up deleting the modified il2cpp-dumper-rs cloned project because I just could not get it to work

additionally, I checked the iL2cpp classes and methods in the Binary and they seemed correct to me or I could have missed something. and the other thing is I noticed is as soon as I added the XOR key decryption function in the VS Code it seemed like it wanted to work but was still getting hung up on something.
 

This is purely for educational / research purposes.

 

Thanks in advance for any help or tips on what to try!

Updated Monday at 05:56 AM by Taylor Meyer

[Batch 10.1k iPhone 7 15.7]

I think maybe the magic bytes are different from the normal one and straight up refuse it? Also if you dumper global-metadata.dat from igg, should be fully decrypted. And are you sure the CodeRegistration and MetadataRegistration are correct? And also those dumpers may not support new metadata version, so you need to adjust them as well, the hung up probably on this or on how you decrypt.
I suggest you to:

• Find the metadata version 
• See if your CodeRegistration and MetadataRegistration are correct
• See if they modified any Struct

[Taylor Meyer 288 iPad (9th gen) 26.2]

47 minutes ago, Batch said:

I think maybe the magic bytes are different from the normal one and straight up refuse it? Also if you dumper global-metadata.dat from igg, should be fully decrypted. And are you sure the CodeRegistration and MetadataRegistration are correct? And also those dumpers may not support new metadata version, so you need to adjust them as well, the hung up probably on this or on how you decrypt.
I suggest you to:

• Find the metadata version 
• See if your CodeRegistration and MetadataRegistration are correct
• See if they modified any Struct

thank you Batch I will check when I have a chance then let you know appreciate it 🙏

[Batch 10.1k iPhone 7 15.7]

So i analyzed this one, im adding into my dumper with static analysis, can confirm that your CodeRegistration and MetadataRegistration are correct, there's no struct changes and metadata version is 31. Also note that this game is really really hard to dump 

[Taylor Meyer 288 iPad (9th gen) 26.2]

22 minutes ago, Batch said:

So i analyzed this one, im adding into my dumper with static analysis, can confirm that your CodeRegistration and MetadataRegistration are correct, there's no struct changes and metadata version is 31. Also note that this game is really really hard to dump 

interesting would like to know what the issue is so I can learn from this? like is it one of the _IL2cpp functions? 

Edit: or maybe a bug with the XOR Decryption? 

Updated Monday at 09:40 PM by Taylor Meyer

[Batch 10.1k iPhone 7 15.7]

13 hours ago, Taylor Meyer said:

interesting would like to know what the issue is so I can learn from this? like is it one of the _IL2cpp functions? 

Edit: or maybe a bug with the XOR Decryption? 

They encrypted the sh!t out of it ahah, you need to reconstruct everything lol

But if you dump clean global-metadata.dat i think it's just XOR decryption bug. Use AI to help you out, here a hint:

const ZAKA_CODEGEN_MODULES_VA: u64 = 0x7B01720;
const ZAKA_NAME_XOR_KEY_VA: u64 = 0x706CF50;
const ZAKA_NAME_XOR_KEY_LEN: usize = 128;
const ZAKA_NAME_XOR_KEY_PREFIX: [u8; 8] = [0x2C, 0xC5, 0xD5, 0x9F, 0xCC, 0xCE, 0x8C, 0xFE];
const MAX_ZAKA_MODULE_NAME_BYTES: usize = 256;

 

[Taylor Meyer 288 iPad (9th gen) 26.2]

20 hours ago, Batch said:

They encrypted the sh!t out of it ahah, you need to reconstruct everything lol

But if you dump clean global-metadata.dat i think it's just XOR decryption bug. Use AI to help you out, here a hint:

const ZAKA_CODEGEN_MODULES_VA: u64 = 0x7B01720;
const ZAKA_NAME_XOR_KEY_VA: u64 = 0x706CF50;
const ZAKA_NAME_XOR_KEY_LEN: usize = 128;
const ZAKA_NAME_XOR_KEY_PREFIX: [u8; 8] = [0x2C, 0xC5, 0xD5, 0x9F, 0xCC, 0xCE, 0x8C, 0xFE];
const MAX_ZAKA_MODULE_NAME_BYTES: usize = 256;

 

Hi

Thanks again for the info earlier. I spent basically the whole day trying to implement the Mario Kart Tour support based on what you posted.

**Quick update:**

- I added the 128-byte name XOR key logic + the CodeGen Modules table handling.

- I also have the manual CR/MR fields working in the GUI.

- Unfortunately it’s still not working. The dumper either fails at auto-detection or the name decryption / CodeGen module part doesn’t apply correctly.

 

I didn’t delete the project this time, so everything is still there.

 

Would you be able to help me with one of these?

 

1. A good **placeholder prompt** I can feed it to my AI (Grok Build / KiloCode) so it can properly implement the MKT name decryption and CodeGen table logic?

2. Or some key things I should check / verify in the code to see where it’s going wrong?

 

Here’s the current information I tried on, also if there is somehow I could copy

 

- **Unity Version**: 2022.3.68f1

- **Metadata Version**: 31

- **Il2CppCodeRegistration**: `0x6E6C478`

- **Il2CppMetadataRegistration**: `0x5B96820`

- **Main Metadata XOR Key**: `0x20015111`

- **Name XOR Key Location**: `0x706CF50` (128 bytes)

- **Key Prefix**: `[0x2C, 0xC5, 0xD5, 0x9F, 0xCC, 0xCE, 0x8C, 0xFE]`

- **CodeGen Modules Table**: `0x7B01720`

[Taylor Meyer 288 iPad (9th gen) 26.2]

21 hours ago, Batch said:

They encrypted the sh!t out of it ahah, you need to reconstruct everything lol

But if you dump clean global-metadata.dat i think it's just XOR decryption bug. Use AI to help you out, here a hint:

const ZAKA_CODEGEN_MODULES_VA: u64 = 0x7B01720;
const ZAKA_NAME_XOR_KEY_VA: u64 = 0x706CF50;
const ZAKA_NAME_XOR_KEY_LEN: usize = 128;
const ZAKA_NAME_XOR_KEY_PREFIX: [u8; 8] = [0x2C, 0xC5, 0xD5, 0x9F, 0xCC, 0xCE, 0x8C, 0xFE];
const MAX_ZAKA_MODULE_NAME_BYTES: usize = 256;

 

here is full code set up

 

Spoiler

Quote

 

### 1. Mario Kart Tour Protection Mechanism

Mario Kart Tour (Unity 2022.3.68f1, metadata v31) uses a **two-layer obfuscation scheme** on top of the normal IL2CPP structures. The protection is deliberately designed to break the assumptions that almost all IL2CPP dumpers rely on.

#### Layer 1 – Main Metadata / Registration XOR (`0x20015111`)
- A single 32-bit constant (`0x20015111`) is applied (as a simple XOR) to many **pointers and counts** inside the in-memory IL2CPP registration structures.
- It is **not** (primarily) a metadata-file encryption like the ones the dumper already handles with `try_decrypt_metadata`. It is applied to the live structures that the game builds at runtime (and therefore to any memory dump of the UnityFramework / libil2cpp binary).
- Affected fields include (but are not limited to):
  - Inside `Il2CppCodeRegistration`: `code_gen_modules_count`, `code_gen_modules`, and many other count/pointer fields.
  - Inside each `Il2CppCodeGenModule`: virtually every pointer field (`module_name`, `method_pointers`, `rgctxs`, `rgctx_ranges`, `invoker_indices`, etc.).
  - The array of pointers that forms the CodeGen Modules table itself (each `Il2CppCodeGenModule*` entry is XORed).
- Consequence: when a dumper reads the `Il2CppCodeRegistration` structure using the address it found (or guessed), the `code_gen_modules_count` is a huge garbage number and the `code_gen_modules` pointer is meaningless. The same is true for many other fields the dumper uses to walk methods, generics, rgctx data, etc.

#### Layer 2 – 128-byte Name XOR (at `0x706CF50`)
- There is a second, independent 128-byte rolling key whose **first 8 bytes** are the constant prefix `[0x2C, 0xC5, 0xD5, 0x9F, 0xCC, 0xCE, 0x8C, 0xFE]`.
- This key is applied (cyclic/rolling XOR, byte-by-byte) **only to the module name strings** that live inside the CodeGen module table (the strings pointed to by the `module_name` field of each `Il2CppCodeGenModule`).
- The decrypted names are the normal assembly image names that appear in `global-metadata.dat` (e.g. `Assembly-CSharp.dll`, `mscorlib.dll`, etc.).
- The key is stored at a **fixed virtual address** (`0x706CF50` in the MKT build you are working with). The dumper can locate it by mapping that VA (after base address is known) and checking the prefix.

#### The CodeGen Modules Table Relocation / Obfuscation (`0x7B01720`)
- In a normal Unity IL2CPP binary the `Il2CppCodeRegistration` structure contains a pointer (`code_gen_modules`) and a count that tell the dumper where to find the array of `Il2CppCodeGenModule` entries.
- On MKT this pointer (and the count) are corrupted by the `0x20015111` layer (see Layer 1).
- In addition, the actual table of modules is **not** at the address the (obfuscated) CR field would indicate. It lives at a second fixed VA (`0x7B01720`).
- Therefore even if a dumper somehow obtained a clean `Il2CppCodeRegistration`, reading from the CR’s `code_gen_modules` field would give the wrong table (or garbage).

#### Why Normal Dumpers (and the Original Engine) Fail Catastrophically

1. **Registration discovery breaks first.**
  - Almost every dumper finds `Il2CppCodeRegistration` and `Il2CppMetadataRegistration` by:
    - Searching for the string `"mscorlib.dll\0"` (or `System.Private.CoreLib`) inside data sections and walking backwards, or
    - Searching for known count values (method count, type count) that appear next to pointer pairs.
  - Because the counts and pointers inside the CR/MR structures are XORed with `0x20015111`, these heuristics see random huge numbers and never find the structures. The dumper falls through all its search strategies and eventually emits “Auto-detection failed. Provide CodeRegistration and MetadataRegistration…”.

2. **Even if registrations were magically obtained, the CodeGen module data is unusable.**
  - The count of modules is wrong (XORed) → the dumper either reads zero modules or tries to read millions of them and crashes or hangs.
  - The pointers in the module pointer array are XORed → `map_vatr` fails or maps to nonsense.
  - The `module_name` pointers inside each `Il2CppCodeGenModule` are XORed → the name strings cannot even be read.
  - The actual name bytes, once read, are still encrypted with the 128-byte key → the resulting “image name” does not match anything in the metadata. All later reconciliation (`get_method_pointer`, rgctx lookup, type image names, etc.) fails.

3. **The two layers are independent and must both be defeated.**
  - Defeating only the 128-byte name encryption is useless if you never reach the CodeGen module table (because registration discovery failed or the count/pointers were garbage).
  - Defeating only the `0x20015111` layer on counts/pointers is useless if the module names are still garbage (the dumper will load modules under wrong names and the rest of the pipeline that depends on image-name matching will produce broken or empty output).

4. **Fixed VAs + memory-dump complications.**
  - The protection relies on the attacker not knowing (or not being able to map) the two magic VAs (`0x706CF50` for the key, `0x7B01720` for the modules table).
  - On a raw memory dump the dumper must first apply a correct image base (the “Base Address” field) before any of those VAs can be turned into file offsets. If the base is wrong, even a perfect prefix check will never find the key.

In short, MKT does not just “encrypt the metadata file.” It systematically corrupts the very data structures that every IL2CPP dumper uses to navigate from registrations → CodeGen modules → method pointers → image names. The two layers plus the relocated table make the normal discovery + walking path completely blind.

---

### 2. How the Current Dumper Engine Works (Normal vs. MKT Path)

#### Normal Game Path (what the engine was originally designed for)

1. **Metadata loading**
  - The `global-metadata.dat` file is read.
  - `try_decrypt_metadata` tries a battery of common single-byte, multi-byte, rolling, position-dependent, and header-only XOR schemes against the known magic `0xFAB11BAF`. If one succeeds, the decrypted bytes are used.
  - The metadata structures (images, types, methods, etc.) are then parsed normally.

2. **Binary format detection + section mapping**
  - The IL2CPP binary (ELF/PE/Mach-O/etc.) is loaded.
  - Program headers / sections are parsed so that virtual addresses can be turned into file offsets (`map_vatr`).

3. **Registration discovery (the critical gate)**
  - A `SectionHelper` is built with counts from the metadata (method count, type count, image count) and the data/code sections of the binary.
  - `find_code_registration()` is called (first the 2019 “string near pointer” search for `mscorlib.dll`, then the older count-heuristic search).
  - `find_metadata_registration()` (v21 or older heuristics) is called.
  - Various fallbacks are tried: symbol table, ARM32 pattern search, etc.
  - If **both** a CodeRegistration and a MetadataRegistration are obtained, `auto_plus_init` (or direct `init`) is called. This reads the two registration structures, applies a few version-specific count hacks, then walks types, methods, generics, and (for v24.2+) calls `load_code_gen_modules`.

4. **CodeGen module loading (normal case)**
  - The CR’s `code_gen_modules` pointer + count are used.
  - For each module the name string is read as-is.
  - The module’s method pointer array, rgctx data, etc. are walked.
  - Names are inserted into maps (`code_gen_modules`, `code_gen_module_method_pointers`, `rgctxs_dictionary`).

5. **Name reconciliation and output**
  - Later stages (method pointer lookup, type image names, etc.) use the image names that came from metadata.
  - `resolve_image_name` / `get_method_pointer` simply look up the name that came from metadata against the maps built from the CodeGen modules. On a normal game the names match exactly.

If any of the registration searches return `None` for either CR or MR, the code eventually calls `prompt_manual_addresses()`, which produces the exact error the user is seeing.

#### What Was Added for Mario Kart Tour (the “MKT implementation”)

The MKT work added three conceptual pieces, all gated behind a positive detection of the protection:

- A **probe** (run early in `init_elf`) that maps VA `0x706CF50`, checks for the 8-byte prefix, and if it matches:
  - Loads the full 128-byte key and stores it in `codegen_name_xor_key`.
  - Stores the known modules table VA (`0x7B01720`) in `manual_codegen_modules_addr`.
  - Sets a boolean flag `mkt_auto_detected = true`.
  - Emits the “Mario Kart Tour style protection detected” message (and later a lot of verbose per-module logging).

- **Deobfuscation and table override inside the two `load_code_gen_modules` paths** (Elf and the Il2Cpp wrapper):
  - When `mkt_auto_detected` is true, the count read from CR is XORed with `0x20015111` before use.
  - The array of module pointers is read using either the direct VA or the (deobfuscated) CR value, then every pointer in the array is XORed with `0x20015111`.
  - After reading each `Il2CppCodeGenModule`, every pointer field inside it is XORed with `0x20015111`.
  - The 128-byte name key (if present) is then applied to the name string exactly as it would be on a normal game.
  - The rest of the module loading (method pointers, rgctx data) proceeds with the now-clean values.

- **Attempts to solve the registration problem itself**:
  - An anchor-based search (`search_registrations_mkt`) that tries to locate CR/MR by scanning for `(count, ptr)` pairs that, after `^ 0x20015111`, point at the known modules table VA, then walking backwards.
  - (Later) a direct “when MKT was detected, just use the known-good CR/MR constants” fallback that injects `0x6E6C478` / `0x5B96820` so that `init()` can be reached at all.

All of the above MKT-specific logic lives **inside or after** the call to `elf.init(cr, mr)` (or `auto_plus_init`). The 128-byte key, the modules table override, the pointer deobfuscation, and the name decryption are only exercised once a valid CR + MR pair has been obtained and `init` has been called.

#### Where and Why It Is Currently Failing on Mario Kart Tour

The failure message the user sees (“Auto-detection failed. Provide CodeRegistration and MetadataRegistration in Advanced options.”) is emitted by `prompt_manual_addresses()`. That function is only reached when **every** registration discovery attempt returned insufficient results.

From the architecture:

- The MKT probe (the part that finds the 128-byte key and sets `mkt_auto_detected`) runs **before** the registration searches. So the engine can know “this is an MKT binary” while the registration searches are still running.
- The registration searches that actually run are still the **original** ones (`SectionHelper::find_code_registration`, `find_metadata_registration`, symbol search, ARM32 pattern, etc.). These searches look for readable strings or plausible counts in the binary image. Because of Layer 1 (`0x20015111`), those values are garbage, so the searches return `None`.
- The later “MKT anchor search” and the “known-address fallback when `mkt_auto_detected`” were added precisely to bridge this gap. However, the user is still hitting the manual prompt error. This tells us that, in the actual execution path the user is running:
  - Either `mkt_auto_detected` is never becoming true (the probe itself failed — wrong base address, the key bytes are not present at the mapped location, the binary the user has is a different build, etc.), **or**
  - The fallback / anchor logic that is supposed to supply CR/MR when `mkt_auto_detected` is true is not being reached, or is not supplying both values, before the code falls through to `prompt_manual_addresses()`.

In either case the fundamental gating problem remains visible:

**All the rich MKT handling (128-byte name decryption, direct modules table at 0x7B01720, `0x20015111` pointer deobfuscation inside CR/MR and inside every CodeGenModule) is only executed after a successful `init(cr, mr)` call.** 
If the registration discovery phase never produces a usable CR + MR pair, the entire MKT code path is bypassed and the user is forced into manual mode — exactly the symptom they are reporting.

That is why simply detecting the protection signature at `0x706CF50` is not yet sufficient for “true auto-detection” on this title: the engine still treats the absence of registrations as a fatal condition before it ever gets to use the knowledge that “this is MKT, therefore we know the registrations must be at X and Y.”

 

 

 

[Taylor Meyer 288 iPad (9th gen) 26.2]

On 6/9/2026 at 3:57 AM, Batch said:

They encrypted the sh!t out of it ahah, you need to reconstruct everything lol

But if you dump clean global-metadata.dat i think it's just XOR decryption bug. Use AI to help you out, here a hint:

const ZAKA_CODEGEN_MODULES_VA: u64 = 0x7B01720;
const ZAKA_NAME_XOR_KEY_VA: u64 = 0x706CF50;
const ZAKA_NAME_XOR_KEY_LEN: usize = 128;
const ZAKA_NAME_XOR_KEY_PREFIX: [u8; 8] = [0x2C, 0xC5, 0xD5, 0x9F, 0xCC, 0xCE, 0x8C, 0xFE];
const MAX_ZAKA_MODULE_NAME_BYTES: usize = 256;

 

here is additional finding's 
 

Quote

**Summary of IDASQL investigation (Mario Kart Tour UnityFramework protection constants)**

 Binary is 64-bit ARM, image base effectively 0 (addresses are file VAs). Key data lives in the large `__data` segment (0x05E00000–0x07B8C7D8).

### 1. Name XOR Key Verification (ZAKA_NAME_XOR_KEY_VA = 0x706CF50)
**Queries:**
```sql
SELECT * FROM segments WHERE start_ea <= 0x706CF50 AND end_ea > 0x706CF50;
SELECT ea, value FROM bytes WHERE ea >= 0x706CF50 AND ea < 0x706CF50 + 8 ORDER BY ea;
SELECT ea, printf('%02X', value) AS hex FROM bytes WHERE ea >= 0x706CF50 AND ea < 0x706CF50 + 128 ORDER BY ea;
SELECT COUNT(*) FROM byte_search WHERE pattern = '2C C5 D5 9F CC CE 8C FE';
SELECT address FROM byte_search WHERE pattern = '2C C5 D5 9F CC CE 8C FE' ORDER BY address;
```

**Results:**
- Located in `__data` (start_ea=98724768 / 0x5E00000, end_ea=129456912).
- First 8 bytes exactly: `2C C5 D5 9F CC CE 8C FE` (matches provided prefix).
- Full 128-byte hex (one continuous dump):
  `2CC5D59FCCCE8CFE449D3A2076FB38184BFCB13B6EE2EB9506446C27D01E94DA52013ADD68449B805A5FC949FE10784CD03DC75A7433A03635A960323A7C7D0EA6DC13893F53F13A67326F28DAB229C1AD9C3C651CA67799D45FFC30F89F609D8EF690A3109581A67E218BC7340E3A2A898EBCF4A9F8C0C95F4C72A1929A645D`
- 425 total occurrences of the exact 8-byte prefix in the binary (this specific location at 117886800 / 0x706CF50 is the one used by the deobfuscator). The key is **not** a simple repeating pattern; it has high entropy after the prefix.

### 2. CodeGen Modules Table (ZAKA_CODEGEN_MODULES_VA = 0x7B01720)
**Queries:**
```sql
SELECT * FROM segments WHERE start_ea <= 0x7B01720 AND end_ea > 0x7B01720;
SELECT ea, value, dword, qword FROM bytes WHERE ea >= 0x7B01720 AND ea < 0x7B01720 + 32 ORDER BY ea;
SELECT COUNT(*) AS num_05_markers FROM bytes WHERE ea BETWEEN 0x7B01720 AND 0x7B01720 + 8192 AND value = 5;
SELECT ea FROM bytes WHERE ea BETWEEN 0x7B01720 AND 0x7B01720 + 8192 AND value = 5 ORDER BY ea;
SELECT ea, value FROM bytes WHERE ea >= 128980768 AND ea < 128980768 + 16 ORDER BY ea;
SELECT COUNT(*) AS total_xrefs FROM xrefs WHERE to_ea = 0x7B01720;
```

**Results:**
- Also in `__data`.
- First 16 bytes: `08 A3 CA 05 00 00 00 00 F8 DC C8 05 00 00 00 00` (0x05 appears immediately after small header-like bytes).
- ~130 entries with 0x05 markers in an 8 KB window (exact list of 130 addresses returned; initial stride ~8 bytes, later irregular — consistent with a table of variable-length or pointer-bearing module descriptors).
- 0 direct xrefs to 0x7B01720. No symbolic name at the VA.
- 0x05 is a reliable marker for entry starts (likely a small struct with a type/length byte).

### 3. How the Constants Were Likely Discovered
**Queries:**
```sql
SELECT * FROM xrefs WHERE to_ea = 0x706CF50 ORDER BY from_ea;
SELECT * FROM heads WHERE address BETWEEN 37208500 AND 37209200 ORDER BY address;
SELECT disasm FROM heads WHERE address BETWEEN 37209000 AND 37209060 ORDER BY address;
SELECT address, name FROM names WHERE address BETWEEN 37208500 AND 37209200 OR address BETWEEN 0x7B00000 AND 0x7B02000 ORDER BY address;
SELECT * FROM strings WHERE (address BETWEEN 0x706CF50-0x4000 AND 0x706CF50+0x4000) OR (address BETWEEN 0x7B01720-0x4000 AND 0x7B01720+0x4000) AND length >= 8 ORDER BY address;
SELECT * FROM comments WHERE (address BETWEEN 0x706CF50-0x2000 AND 0x706CF50+0x2000) OR (address BETWEEN 0x7B01720-0x2000 AND 0x7B01720+0x2000) ORDER BY address;
```

**Key findings:**
- Primary cross-reference to the XOR key is at ~0x37209012 (inside an obfuscated function; one name nearby is `+[UnityNotificationLifeCycleManager load]`).
- Exact usage (cleaned disassembly):
  ```
  AND  X9, X8, #0x7F
  ADRL X10, unk_706CF50
  LDRB W9, [X10,X9]
  LDR  X10, [SP,#arg_58]
  LDRB W11, [X10,X8]
  EOR  W9, W11, W9
  STRB W9, [X10,X8]
  ```
  This directly explains `ZAKA_NAME_XOR_KEY_VA`, the 128-byte length (mask 0x7F), and the XOR logic. `MAX_ZAKA_MODULE_NAME_BYTES = 256` is a standard safe buffer size for the names being decrypted here.
- No comments or protection-related strings ("Zaka", "CodeGen", "module", etc.) near either VA.
- Modules table (0x7B01720) has **zero** direct xrefs or names — discovery was almost certainly pattern-based: (a) following the ADRL above, then (b) scanning for arrays of small structs containing 0x05 markers + the nearby 0x20015111 constant, or (c) byte-searching the known 8-byte prefix and correlating with the deobfuscator.
- Byte-search for the prefix returned 425 hits; context + the ADRL pinpoints the correct one.

### 4. Additional Encryption Patterns (global-metadata.dat / dword_5F0FD1C area)
**Queries:**
```sql
SELECT ea, dword FROM bytes WHERE dword = 0x20015111 ORDER BY ea;
SELECT ea, printf('%02X', value) AS hex FROM bytes WHERE ea BETWEEN 99679500 AND 99679600 ORDER BY ea;
SELECT * FROM segments WHERE start_ea <= 99679516 AND end_ea > 99679516;
SELECT ea, dword FROM bytes WHERE (dword = 536936721 OR dword = 0x20015111) ORDER BY ea LIMIT 100;
```

**Results:**
- Exact `0x20015111` (little-endian `11 51 01 20`) appears only **once** in the entire database, at 0x7B00068 (128975144) — only ~0x16B8 bytes before the modules table at 0x7B01720. Highly suspicious proximity.
- At `dword_5F0FD1C` (0x5F0FD1C / 99679516, also in `__data`): the bytes immediately preceding the encrypted blob are `3C C5 D5 9F CC CE 8C FE` (a close variant of the known prefix, differing only in the first byte). The following 64+ bytes are high-entropy (encrypted).
- No other exact `0x20015111` matches. The 8-byte prefix family appears 425 times total, indicating the protection re-uses similar 128-byte XOR keys (or a key schedule) in multiple places.
- No other obvious magic constants or repeating patterns surfaced in the searched metadata-adjacent ranges.

### 5. Additional / Suspicious Findings
- The modules table and the single `0x20015111` constant are adjacent in the same data region; the XOR key usage site directly references the 128-byte table with a 0x7F mask.
- 0 symbolic names or comments on the protection data itself.
- The same 8-byte prefix (or 1-byte variants) precedes multiple encrypted blobs, including the one at 5F0FD1C.
- No evidence of additional independent encryption layers (different XOR constants, rolling keys, or other magics) immediately visible in the areas around these constants or the metadata table. The primary static-dumping blocker appears to be this family of 128-byte XORs (one of which is keyed with the 0x20015111 value or related logic).
- The deobfuscation routine at ~0x37209012 is the smoking gun that ties the provided constants together.

All provided constants check out exactly against the binary. The 8-byte prefix + 128-byte length + usage site with `& 0x7F` + proximity of `0x20015111` to the modules table explain how/why these specific values were chosen. Let me know if you want deeper disassembly of the full routine, more context around 0x7B00068, or searches for other candidate keys.

 

[Batch 10.1k iPhone 7 15.7]

That is just the start, good luck next it will be a journey ahahahah