Full-pipeline static reconstruction, semantic modeling, runtime correlation, and formal security-property assurance of the XIGNCODE3 anti-cheat system as deployed with the current Black Desert client.
📖 Layer 8 Handbook ·
This archive reconstructs and documents the client-side XIGNCODE3 files delivered inside three encrypted containers and deployed with the current Black Desert client. The pipeline traces every artifact from raw container records through unpacking, native decompilation, semantic modeling, behavioral documentation, a dedicated xhunter1 kernel-driver repair, passive runtime reconciliation, and formal target-specific security-property assurance.
Goal: Understand XIGNCODE3 itself — its file formats, modules, configuration and policy data, user-mode architecture, kernel driver, IPC and reporting relationships, detection families, and observable startup and shutdown behavior.
This project contains no bypass, evasion, check-disabling, or check-manipulation work. The runtime session used the ordinary signed client path with no debugger, no patch, no injection, and no forced termination.
The analysis reveals XIGNCODE3 as a modular, data-driven anti-cheat platform — not a single monolithic binary. The client is delivered inside encrypted containers, unpacked at runtime by a private loader, and orchestrated through a layered architecture separating frequently updated policy data from native checker code.
The system divides its responsibilities across three conceptual layers:
1. Bootstrap and update (xup) — Validates the installed state, checks for updates, and prepares the environment before any protection is active.
2. User-mode runtime — A collection of specialized plug-in families loaded privately and orchestrated by xclio_egg:
xstacts as the broad core runtime, providing scanners, parsers, loader services, Lua scripting support, system-information collectors, and shared reporting infrastructure.xclio/x3_egg/xclio_egghandle private loading, probe coordination, packet caches, signature dispatch, and report job management.xez/xkaga/xobserverdivide environment, process, module, window, display, input, overlay, file, and peripheral checks into separate plug-in families.xsgprovides the explicit user-mode bridge to the kernel driver.xspiritis a legacy UDP/TDI attachment and filtering family present in the container but not loaded in the observed session.
3. Kernel driver (xhunter1.sys) — The privileged monitoring layer. Written at game launch to C:\Windows\xhunter1.sys, loaded as a service, and unloaded before the game exits. Responsible for process and image load notifications, object and registry monitoring, memory and service inspection, access filtering, and structured report delivery to user-mode via IPC.
Data assets — XdNa records, JSON policy, SPO/TARA signatures, Lua tables, and XIP data are kept separate from native checker code and can be updated independently: 486,299 IP geographic boundaries, 288,541 REAL/SPO hash and tag rows, 207 TARA v3 native signatures across 9 groups, and 194 configuration categories governing allow/deny/exclusion rules for drivers, processes, windows, certificates, modules, VMs, and graphics subsystems.
| What you want | Where to go |
|---|---|
| 🗺️ Understand the full project at a glance | Project Map |
| 📖 Current architecture, state, and findings | Layer 8 — Handbook |
| 🔬 Formal security-property proof results | Layer 9 — Assurance Package |
| 🪲 Kernel driver deep-dive | xhunter1 Deep Reconstruction |
| 📊 xhunter1 six-area ceiling metrics | xhunter1 Ceiling Pass |
| 🔩 All pseudocode and call graphs | Layer 5 — Deprotected / Decompiled |
| 🏷️ Module identities, roles, RTTI, similarities | Layer 6 — Semantic Model |
| 🧠 Static behavior model | Layer 7 — Behavior Documentation |
| Weaknesses of XIGNCODE3 | |
| 🧾 Runtime evidence catalog | Layer 8 Evidence Catalog |
| 🔍 Architecture and component guide | Layer 8 Architecture |
| 📡 Detection families and subsystem model | Detection Subsystems |
| ⚙️ Configuration and policy behavior | Configuration Behavior |
| 🔗 IPC channels and report pipeline | IPC Channels · Reporting Pipeline |
The kernel driver is the most significant analysis target and received a dedicated deep reconstruction separate from the main pipeline.
xhunter1.sys is written to disk, loaded as a Windows service, and unloaded before the game exits. It is the privileged monitoring layer of the XIGNCODE3 stack, responsible for:
- Process and image load notifications — Receives callbacks for every new process and image loaded in the kernel while active.
- Object-manager and registry monitoring — Monitors handle operations and registry changes relevant to the protected process.
- Memory and service inspection — Inspects memory regions and service state on demand.
- Access filtering — Can filter or act on access operations to protected objects.
- Report delivery — Packages observations into structured reports and delivers them to user-mode via a named device (
xhunter1) and a named event (XcoreNotifyReportEvent), consumed byxsg.
The driver was separately reconstructed with 4-pass function boundary repair before analysis. The initial Ghidra parse produced 630 fragmented boundary entries; after repair, 520 remained, of which 467 were confirmed as genuine semantic routines.
| Metric | Value |
|---|---|
| Module size at load | 194,448 bytes |
| SHA-256 match to static reconstruction | ✅ Exact |
| Raw function entries (post-repair) | 519 / 520 with pseudocode |
| Genuine semantic routines confirmed | 467 / 467 |
| Ceiling pass reviewed-clean | 397 / 467 |
| Functions named | 78 |
| Write-protocol operations mapped | 44 / 44 |
| False boundary splits repaired | 110 (across 4 passes) |
| Driver active duration (observed session) | 254.8 seconds |
| IPC path | \Device\xhunter1 + XcoreNotifyReportEvent |
→ Full kernel driver analysis →
Eleven detection families were recovered and modeled from the static corpus and configuration data. The family model covers:
- Hash-based identification — 288,541 hash and tag rows from the REAL/SPO dataset identifying known targets by exact binary hash.
- Native byte-pattern matching — 207 TARA v3 signatures across 9 groups scanning for known byte sequences.
- Process and module enumeration — Environment and process inspection through the
xez/xkagafamily. - Window, display, and input monitoring — Overlay, peripheral, and input-device checks through
xobserverandxkaga. - Driver and certificate policy — Allow/deny rules for kernel modules and signing identities from JSON policy.
- VM and graphics detection — Configuration categories governing virtual machine environments and graphics subsystem state.
- Name and descriptor matching — Literal path, name, and metadata checks through multiple policy categories.
- Kernel callback coverage — Process, image, object-manager, and registry notifications from
xhunter1. - Memory inspection — Targeted memory reads and integrity checks from the kernel layer.
- Geolocation-based policy — XIP IPv4 boundary data with 486,299 entries providing per-region rule variation.
- Report orchestration —
xclio_eggcoordinates probe results into an 8-stage detection-to-delivery pipeline.
→ Detection subsystems model →
One passive Windows ETW session captured the complete lifecycle: signed launcher → game menu idle → normal close. The kernel logger reported zero lost events or buffers. No debugger, patch, injection, or forced termination was used.
| Observation | Detail |
|---|---|
| Source containers accessed | Exact supplied xmag_x64.xem and xnina_x64.xem ✅ |
xhunter1.sys identity |
SHA-256 exact match to static reconstruction ✅ |
xhunter1.sys size |
194,448 bytes — matches static model ✅ |
| Driver load timing | +21.654771s after game process creation |
| Driver unload timing | +276.482228s — 3.239886s before game exit |
| Driver active duration | 254.8 seconds |
| Game process runtime | 263.9 seconds |
| Hidden NTFS stream GUIDs correlated | 2 GUIDs matched to 3 xclio_egg static functions ✅ |
| Remote IP/port contacts | 13 pairs; 2 IPs match configured XIGNCODE candidates |
| Kernel logger integrity | Zero lost events or buffers ✅ |
| Lifecycle stages confirmed | 15/15 lifecycle claims with separate static and runtime status |
The Weaknesses of XIGNCODE3 document is a 659-line formal analysis of the architectural limits and specific exposures recovered from this session. It strictly separates directly established weaknesses from plausible hypotheses and inherent client-side trust limits. It contains no remediation section.
| ID | Finding | Exploitability |
|---|---|---|
| V01 | Kernel monitoring starts 5.864 seconds after the protected game process | Conditional |
| V02 | Kernel monitoring ends 3.240 seconds before the process exits | Conditional |
| V03 | Driver activation state produces stable, locally observable artifacts — making V01/V02 timing distinguishable | Practical |
| V04 | Exact-match rules (hash, byte-pattern, name, descriptor) recognize representations, not behavior — a novel representation defeats the specific rule | Practical at one layer |
| ID | Hypothesis |
|---|---|
| H01 | Scheduled checks can miss sufficiently transient state |
| H02 | Private executable mappings lose normal image identity and detection falls back to heuristics |
| H03 | Allowlists and exclusions can transfer trust to unsafe behavior |
| H04 | A signed or allowed kernel component can proxy privileged effects |
| H05 | Kernel findings depend on a multi-stage user-mode delivery path that can diverge |
| H06 | OS-layout-dependent inspection can degrade on unsupported configurations |
| ID | Limit |
|---|---|
| A01 | Equal-privilege kernel code can alter the monitor and its evidence |
| A02 | A lower hypervisor controls guest-visible reality |
| A03 | DMA can access memory outside normal OS event paths |
| A04 | Off-host automation leaves only ordinary display and input evidence locally |
| A05 | Client-only monitoring cannot inspect exclusively off-client state |
No complete XIGNCODE3 bypass was executed or claimed. No end-to-end scenario is labeled "demonstrated."
Layer 9 formalizes 31 security-property proof obligations against hash-identified artifacts — the exact containers and modules from this deployment. Obligations span five categories: Validity, Hyperproperties, Availability, Confidentiality, and Unspecified behavioral properties.
The analysis uses bounded IR lifting via Ghidra Sleigh p-code, angr VEX, and Unicorn emulation. Synthetic state-machine scenarios provide independent validation. Zero concrete solver assignments were retained in the final output.
| Result | Count | Meaning |
|---|---|---|
| ✅ PROVED | 15 | Property holds for the bounded model of the artifact |
| ❌ REFUTED | 1 | Property does not hold — a counterexample exists |
| 🟡 SAT_REACHABLE | 8 | A satisfying path to the property boundary was found; not yet proved or refuted |
| ⚪ UNKNOWN | 7 | Solver timeout or bounded model insufficient |
| Resolved total | 24 / 31 | PROVED + REFUTED + SAT_REACHABLE |
| Independently corroborated | 22 | Obligations supported by evidence from outside Layer 9 |
| Synthetic scenarios | 8 / 8 | Passed all synthetic state-machine assurance scenarios |
| Retained solver assignments | 0 | No concrete exploit data retained |
Each numbered directory is a transformation stage — a progression of the analysis, not an independent copy of the project. Layers 0 and 4 are documentation only.
| Stage | Directory | Output |
|---|---|---|
| 0 | 0_source_inputs | Exact identities and hashes for the three source containers |
| 1 | 1_unwrapped | Container records carved into XdNa, Lomx, TARA, PI5z, image, and asset records |
| 2 | 2_unpacked | Usable PEs, Lua bytecode, signatures, JSON, images, and XIP data |
| 3 | 3_decompiled | Initial Lua decompilation and representative static-tool triage |
| 4 | 4_intermediate_analysis | Documented transition into the full static corpus; no duplicated artifacts |
| 5 | 5_deprotected_decompiled | Full native Ghidra corpora, readable Lua, and decoded data tables |
| 6 | 6_semantic_model | Module identities, roles, RTTI, imports/exports, structures, and similarities |
| 7 | 7_behavior_documentation | Static architecture, workflows, evidence, and limits |
| ↳ | xhunter1 deep reconstruction | 4-pass boundary repair; corrected semantics, structures, and ceiling coverage |
| 8 | 8_maximum_client_reconstruction | Handbook, runtime reconciliation, function index, evidence catalog, and validation |
| 9 | 9_target_specific_assurance | Hash-bound proof obligations, bounded IR, synthetic validation, and results |
| Measurement | Value |
|---|---|
| Containers verified against supplied hashes | 3 / 3 |
| Native modules reconstructed | 17 |
| Post-repair function entries | 32,768 |
| Entries with Ghidra pseudocode | 32,761 |
| Failed entries | 7 |
| Unique RTTI classes / interfaces | 530 |
| Configuration categories indexed | 194 |
| Detection families modeled | 11 |
| XIP IPv4 geographic boundaries decoded | 486,299 |
| REAL / SPO hash-tag rows parsed | 288,541 |
| TARA v3 native signatures parsed | 207 (9 groups) |
| JSON policy categories recovered | Multiple (driver, process, cert, module, VM, graphics, input) |
| xhunter1 genuine semantic routines | 467 / 467 |
| xhunter1 functions named | 78 |
| xhunter1 write-protocol operations mapped | 44 / 44 |
| xhunter1 false boundary splits repaired | 110 |
| Passive runtime sessions imported | 1 |
| Runtime lifecycle stages confirmed | 15 / 15 |
| NTFS stream GUIDs correlated to static model | 2 |
| Layer 9 obligations formalized | 31 / 31 |
| Layer 9 PROVED | 15 |
| Layer 9 REFUTED | 1 |
| Layer 9 SAT_REACHABLE | 8 |
| Layer 9 UNKNOWN | 7 |
| Layer 9 resolved | 24 / 31 |
| Independently corroborated obligations | 22 |
| Synthetic assurance scenarios | 8 / 8 passed |
| Retained concrete solver assignments | 0 |
The historical
validation_layers567.jsonrecords the first-pass total of 32,878 functions with 195 failures. Current totals incorporate the dedicatedxhunter1boundary repair that reduced false splits from 630 fragmented entries to 520.
The archive strictly separates six evidence classes. No finding is promoted without support from the appropriate tier.
| Class | Meaning |
|---|---|
| ✅ Confirmed static fact | Established directly from recovered binary structure, strings, or metadata |
| 🔵 Strong inference | Structural evidence strongly supports the claim; transition not directly observed |
| 🟢 Runtime-confirmed event | Captured verbatim by passive Windows ETW during the observed session |
| 🟡 Exact runtime correlation | Specific static artifact matched one-to-one against a live observation |
| ⚪ Process-level observation | Visible at process granularity; private module owner not identified |
| ❌ Unknown | Explicitly unresolved — never assumed clean or defective |
A successful decompilation does not imply complete semantic understanding. A process-level event does not automatically identify the responsible private module. Exact private symbols, every possible execution path, server internals, and original source are not recoverable from this corpus alone.
→ Terminology, methods, evidence rules, and remaining gaps: Layer 8 Documentation Map · Evidence Model
CC BY 4.0 · Security Policy · Contributing · Cite this work
Static and passive research only — no bypass, evasion, or check-manipulation work is present in this archive.