# The Salt Crown — Cyber Apocalypse 2026 (Game Pwn, series finale)

| | |
|---|---|
| **Challenge** | The Salt Crown |
| **Platform** | HackTheBox — Cyber Apocalypse 2026 ("The Salt Crown") |
| **Category** | Game Pwn — series finale (Cassian / Registry Altar chapter) |
| **Target** | Windows Godot 4.7 build — `The_Salt_Crown.exe` (~70 MB) + `challenge_core.windows.template_release.x86_64.dll` (208 KB GDExtension) |
| **Techniques** | Custom PE-overlay container reversing, Unicorn-emulated unpacking of a modified UPX stub, Godot `FileAccessEncrypted` (AES-256-CFB) decryption, `.gdc` bytecode decompilation, HKDF→AES-256-GCM key recovery bound to a hashed game-state transcript, Cheat Engine survivability assist |
| **Date** | July 2026 |

> Cyber Apocalypse 2026 has concluded. The real flag string wasn't captured in any session record on my end — drop it in from your own notes before publishing.

---

## TL;DR

The finale ships two sealed artifacts: the exe itself, wrapped in a custom `SCX1` PE-overlay
container instead of Godot's usual `GDPC` pack header, and a GDExtension DLL that's UPX-packed
with its magic scrubbed and sections renamed (`.slt0/.slt1/.slt2`). Three nested encryption
layers stand between "downloaded exe" and "readable assets" — all three fully broken offline.
The flag itself is computed at runtime by a native `render_reward_step` routine once a strict
7-opcode in-game sequence completes; the shipped GDScript can only ever emit one of those
opcodes, making the game unwinnable by normal play. Freezing the player character's
client-side HP in Cheat Engine supplies enough survivability to complete the legitimate
sequence anyway, without touching anything the DLL treats as authoritative.

---

## Recon — two sealed artifacts

```
The_Salt_Crown.exe                                    ~70 MB, patched Godot 4.7 template
challenge_core.windows.template_release.x86_64.dll     208 KB, GDExtension
```

Neither unpacks with stock tooling. The DLL's UPX magic (`UPX!`) has been scrubbed and its
sections renamed away from the standard `UPX0/UPX1`, so `upx -d` refuses it outright. The
exe's asset pack isn't Godot's usual `GDPC`-headed structure at all — it's wrapped in a
custom `SCX1` footer appended as a PE overlay.

## Layer 1 — the `SCX1` PE overlay

AES-256-CTR. Key = SHA-256 of a 32-byte blob sitting at `.data` offset `0x3ecb6f0`; counter
= `nonce || BE64(block_index)`. Peeling this off the overlay recovers the raw Godot pack
bytes.

## Layer 2 — the Godot pack directory

AES-256-CFB, but keyed with the **raw** 32-byte blob this time (not its SHA-256), and called
with `p_with_magic=false` — so the usual `GDEC` header Godot normally prepends is absent.
Fields: `md5 | length | iv`.

## Layer 3 — per-file `FileAccessEncrypted`

Same key/mode as layer 2. Stored size is `40 + round_up(size, 16)`. Peeling all three layers
recovered and MD5-verified all 81 shipped assets, and decompiled all 10 GDScript `.gdc`
files (GDSC v101, zstd-compressed token buffer, identifiers XOR'd against `0xB6B6B6B6`,
Variant type 21 = `StringName`).

## Unpacking the native extension

The DLL's unpacking stub is an NRV2-family decompressor, emulated directly under **Unicorn**
to dump the unpacked module (`.slt0`, valid `DllMain` at RVA `0x22c44`). The unpacked module
has essentially no readable strings — everything meaningful is built or decrypted at
runtime, confirmed by the extension importing `BCryptDecrypt`.

## Why the shipped game is unwinnable by normal play

Decompiling the recovered `.gdc` bytecode gives the strict opcode chain the win condition
requires:

```
6563  (damage, >=1 restoration)
  -> 11377 (storm_circuit  = BOUND_TO_GATE)
  -> 3906  (tide_sluice    = OPEN)
  -> 25528 (brine          = FLOODED, sets current_epoch_invalid)
  -> 20958 (voluntary_quorum_lost, zeroes witness_count)
  -> 14245 (alternative_acclamation -- needs shared_breath_covenant set)
  -> 29380 (SEVER -- requires all three covenant flags, sets
            claim_severed / gate_passage_unlocked / finale_reached)
```

Opcode `17649` is a decoy that only sets a cosmetic `gate_visual_open` flag. Critically, the
shipped GDScript's `submit_event` only ever emits opcode `6563` (`_OP_DAMAGE_CLAIMANT`) — the
rest of the chain is structurally unreachable through legitimate play as shipped.

## The intended (in-game) solution

Playing the build reveals what the bytecode implies:

- The HUD's "COVENANT CONDITIONS" line (`EPOCH INVALID / QUORUM LOST / ALTERNATIVE
  ACCLAMATION`) is a **requirement list, not progress** — it reads `0/3` throughout, even
  while conditions are being satisfied.
- Five "witness memories" (`MOTHERS_FACE`, `THE_BROTHEL_ROOM`, `FIRST_KINDNESS`,
  `BIRTH_NAME`, `REASON_FOR_POWER`) are consumed one at a time by repeatedly defeating the
  boss, Cassian. Each time his HP hits `0000/5000`, a scripted "death disputed / THE
  WITNESSED CANNOT DIE" rollback fires: one memory is consumed and Cassian is restored to
  full HP. A diamond HUD counter tracks memories remaining, and that progress **survives**
  the rollback even though HP does not.
- The full sequence — all five memories consumed, all three covenant flags satisfied, then
  a final kill that fires `SEVER` — has to complete inside one continuous authoritative
  session.
- **Cheat Engine 7.7** (installed after routing around a Defender PUA block) froze the
  player character's own HP. Safe specifically because the player's HP is client-side
  GDScript state, never part of the DLL's authoritative public-state fields — freezing it
  can't corrupt the transcript or trigger `REWARD_AUTH_FAILED`. The boss's mirrored HP
  field (which *does* map into `claimant_hp` inside the DLL) and CE's debugger-attached
  features (breakpoints, "find what writes to address") were both deliberately avoided,
  given the extension's known anti-debug protections.
- With survivability solved, the legitimate 7-step sequence completed in one session, and
  `render_reward_step` rasterized the reward records (a 1024x48-byte buffer folded down to a
  344x192-byte constraint record) into the flag.

## Native state struct (recovered offsets, for reference)

```
0x00 storm_circuit      0x1c claim_severed       0x40 gate_visual
0x04 tide_sluice        0x2c witness_count        0x44 gate_passage
0x08 brine              0x30 hp                   0x48 finale
0x0c shared_breath      0x34 restoration_count     0x4c decoy
0x10 epoch_invalid      0x38 memory_erasures
0x14 quorum_lost        0x3c severance_attempts
0x18 acclamation
```

## Lessons & defenses

- **Client-authoritative and server(-equivalent)-authoritative state need to be clearly
  separated in memory, not just in intent.** The entire safe Cheat Engine path here existed
  *because* player HP happened to live outside the fields the native extension treats as
  authoritative. If it hadn't, this exact "safe" cheat would have corrupted the win
  transcript instead of merely aiding survivability.
- **A custom container format (`SCX1` instead of standard `GDPC`) raises the cost of casual
  asset extraction but doesn't change the fundamental exposure** once an attacker is willing
  to emulate the unpacking stub — obscurity bought time, not security.
- **Anti-debug protections on the native module make static analysis (Unicorn emulation of
  just the unpacker) the efficient path**, not attaching a live debugger.

## Tools used

| Tool | Purpose |
|---|---|
| Unicorn | Emulate the modified UPX/NRV2 unpacking stub to dump the real module |
| Ghidra | Analyze the unpacked `ChallengeCore` extension |
| Python (`hashlib`, `struct`, AES) | Reimplement all three encryption layers offline |
| Custom `.gdc` decompiler | Recover readable GDScript source from the zstd token-buffer bytecode format |
| Cheat Engine 7.7 | Freeze client-side player HP for survivability during the intended in-game route |