level22.ts

import { Level } from './types';

export const level22: Level = {
  id: 22,
  title: "Validation: The Cerberus Protocol",
  description: "Software license key validator uses 3-stage validation pipeline commonly found in commercial DRM (Windows activation, Adobe licenses), game serial key systems (StarCraft CD-KEY, Steam product keys), hardware dongles (HASP HL, Sentinel HASP), and license servers (FlexLM, RLM). Each license key must pass all three validation stages atomically - partial validation rejected. Stage 1 LENGTH_CHECK: Validates key length equals 16 bytes. Checks string length against expected format (0x10). Real-world: Windows product keys (XXX-XXX format), game serials (fixed 16-char CD-KEY). Stage 2 PREFIX_CHECK: Validates key starts with magic bytes 'ELITE-' (0x45 0x4C 0x49 0x54 0x45 0x2D). Checks first 6 bytes against expected prefix. Real-world: Product families use common prefixes (Windows Server vs Home editions), game versions (retail vs OEM keys). Stage 3 CHECKSUM_VALIDATION: Validates ASCII sum of all key bytes equals 1200 (integrity check). Sums character values, compares to constant. Real-world: Luhn algorithm (credit cards), ISBN checksums, CD-KEY validators compute checksum to detect typos/tampering. Your scenario: Three-headed validation system (Cerberus metaphor) guards software activation. Each validator outputs PASS (1) or FAIL (0) flag. All three flags must be 1 atomically - any single failure blocks activation. Initial state: LENGTH_VALID=0, PREFIX_VALID=0, CHECKSUM_VALID=0 (all checks failing). Real-world parallels: Windows checks key format before contacting activation server. Game clients validate serial locally before online verification. FlexLM validates license file structure before feature unlock. Cracking approach: Reverse engineer validation logic (Debugger shows comparison instructions), patch validation flags directly (set all to 1), or craft valid key that satisfies all constraints. Educational concepts: Multi-stage validation pipelines, atomic validation (all-or-nothing), format validation (length/prefix checks), integrity validation (checksums), serial key algorithms, DRM bypass techniques. This mirrors production license systems - understand validation logic, identify check points, bypass or satisfy all stages. Techniques: Debugger (analyze validation assembly - TEST/CMP instructions for each stage), Memory Scanner (locate validation flags, set LENGTH_VALID=1, PREFIX_VALID=1, CHECKSUM_VALID=1), Hex Editor (examine flag bytes at offsets), hybrid approach. Use multiple tools to understand system then patch atomically.",
  requiredSkill: "Multi-Stage Validation Pipeline Bypass & Serial Key Algorithm Analysis",
  objective: (s) => {
    const lengthValid = s.sortValue1 === 1;    // LENGTH_CHECK (1 = PASS)
    const prefixValid = s.sortValue2 === 1;    // PREFIX_CHECK (1 = PASS)
    const checksumValid = s.sortValue3 === 1;  // CHECKSUM_VALIDATION (1 = PASS)
    return lengthValid && prefixValid && checksumValid;
  },
  hint: "Three validators. Three flags. One license. Use Debugger to analyze validation logic (TEST/CMP instructions). LENGTH_VALID=1, PREFIX_VALID=1, CHECKSUM_VALID=1. Bypass all stages.",
  tutorPersona: "The License Auditor: Software activation is three-headed beast. Stage 1: Length validator. Code checks 'if (strlen(key) != 16) reject()'. Key must be exactly 16 bytes. No more, no less. Set LENGTH_VALID=1 to bypass. Real-world: Windows keys fixed 25 chars (5 groups × 5 chars). Game CD-KEYs often 16 chars (memory-friendly, user-typeable). Length check is first barrier - wrong length rejected immediately without expensive crypto. Stage 2: Prefix validator. Code checks 'if (memcmp(key, \"ELITE-\", 6) != 0) reject()'. First 6 bytes must match magic prefix 0x45 0x4C 0x49 0x54 0x45 0x2D (ASCII 'ELITE-'). Set PREFIX_VALID=1. Real-world: Product families share prefixes. Windows Server keys start 'WIN-', Home keys start 'HOM-'. Game versions: retail keys start 'R-', OEM keys start 'O-'. Prefix identifies product tier, edition, region. Crackers generate keys with correct prefix for target edition. Stage 3: Checksum validator. Code sums ASCII values of all 16 key bytes. Checks 'if (sum != 1200) reject()'. Example: key 'ELITE-ABCDEF123' sums chars. Each char has ASCII value (E=69, L=76, etc). Sum must equal 1200 (integrity constant). Set CHECKSUM_VALID=1. Real-world: CD-KEY algorithms use checksums to detect typos. Luhn algorithm (credit cards, software keys) validates digit sequences. ISBN uses weighted sum. Prevents accidental invalid keys, forces key generators to compute valid checksums. Open Debugger in ExploitWorkshop. See validation assembly: CMP instruction for length (CMP EAX, 0x10), CALL memcmp for prefix, ADD loop for checksum sum. Identify where flags set. Three MOV instructions write validation results to memory. Patch flags: all three must be 1. Use Memory Scanner to find LENGTH_VALID/PREFIX_VALID/CHECKSUM_VALID addresses. Set all to 1. Alternative: craft valid key satisfying all constraints (harder, real cracker approach). This is how keygens work - reverse validation logic, generate keys passing all checks. You're bypassing validators directly. Understand pipeline. Patch all stages. Activate software.",
  memoryLayout: [
    { key: 'sortValue1', label: 'LENGTH_VALID', type: 'int', offset: 0xA0 },
    { key: 'sortValue2', label: 'PREFIX_VALID', type: 'int', offset: 0xA4 },
    { key: 'sortValue3', label: 'CHECKSUM_VALID', type: 'int', offset: 0xA8 }
  ],
  initialState: { 
    sortValue1: 0,  // LENGTH_VALID (0 = FAIL, should be set to 1 for PASS)
    sortValue2: 0,  // PREFIX_VALID (0 = FAIL, should be set to 1 for PASS)
    sortValue3: 0   // CHECKSUM_VALID (0 = FAIL, should be set to 1 for PASS)
  },
  platforms: [{ id: 'p1', x: 0, y: 280, width: 800, height: 40, type: 'static' }]
};