-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathlevel23.ts
More file actions
33 lines (31 loc) · 8.49 KB
/
level23.ts
File metadata and controls
33 lines (31 loc) · 8.49 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
import { Level } from './types';
export const level23: Level = {
id: 23,
title: "Serial Key Algorithm: The Keygen Challenge",
description: "Software CD-KEY validator uses 4-character serial key with multi-constraint validation commonly found in game activation systems (StarCraft, Diablo II, Quake III Arena), software licensing (90s/2000s era serial numbers), and crackme challenges (reverse engineering practice). Each character position has specific constraints that must be satisfied atomically. Real-world: Game CD-KEYs use character position rules (StarCraft CD-KEY: 13 digits, each position has modulo constraints), software serials use character type validation (must be uppercase/digit/symbol at specific positions), checksum validation (last character derives from previous characters to prevent random key generation). Your scenario: Four-position serial key validator checks: Position 0 TYPE_CHECK (must be uppercase letter A-Z, ASCII 65-90), Position 1 DIGIT_CHECK (must be numeric digit 0-9, ASCII 48-57), Position 2 SYMBOL_CHECK (must be special character, ASCII 33-47 range like !\"#$%&'()*+,-./), Position 3 CHECKSUM_VERIFY (validates checksum algorithm: calculated from positions 0-2). Validator rejects partial matches - all four positions must satisfy constraints simultaneously (atomic validation). Real-world parallels: StarCraft CD-KEY uses weighted position validation. Windows product keys use character set constraints (no ambiguous chars like O/0, I/1). Quake III checks each segment independently then validates checksum. Crackme challenges require reverse engineering validation logic to write keygen. Educational concepts: Serial key algorithms, character type validation (isalpha/isdigit/issymbol), checksum algorithms, constraint satisfaction problems, keygen development methodology. This mirrors production CD-KEY systems - each position constrained, checksum prevents brute force, type checking prevents invalid input. Cracking approach: Reverse engineer validation logic (use Debugger to see CMP instructions for each constraint), understand checksum algorithm (examine calculation code), craft valid key satisfying all constraints (keygen approach), or patch validators directly (bypass approach). Techniques: ExploitWorkshop Debugger (analyze validation assembly - four CMP/TEST instruction sequences for each position check), System Monitor C_Solver tab (visualize constraint satisfaction status for each position), Memory Scanner (modify serialInput string directly), Hex Editor (view/edit serial key ASCII bytes at character level). Use multiple tools to understand system then craft valid key. Position 0: Character must be uppercase letter (65 ≤ ASCII ≤ 90). Valid examples: A(65), M(77), Z(90). Validator: MOV AL,[key]; CMP AL,65; JL reject; CMP AL,90; JG reject. Position 1: Character must be numeric digit (48 ≤ ASCII ≤ 57). Valid examples: 0(48), 5(53), 9(57). Validator: MOV AL,[key+1]; CMP AL,48; JL reject; CMP AL,57; JG reject. Position 2: Character must be symbol (33 ≤ ASCII ≤ 47). Valid examples: !(33), #(35), /(47). Validator: MOV AL,[key+2]; CMP AL,33; JL reject; CMP AL,47; JG reject. Position 3: Checksum validation. Algorithm: checksum = ((pos0_ASCII + pos1_ASCII + pos2_ASCII) MOD 26) + 65. Result must be uppercase letter A-Z (wraparound modulo maps sum to letter). Example: Key 'M5#' → checksum = ((77+53+35) MOD 26)+65 = (165 MOD 26)+65 = 9+65 = 74 = 'J'. Valid key: 'M5#J'. Validator: MOV AL,[key]; ADD AL,[key+1]; ADD AL,[key+2]; XOR EDX,EDX; MOV ECX,26; DIV ECX; ADD DL,65; CMP DL,[key+3]; JNE reject. All four validators run atomically - any single failure rejects entire key. Correct serial format satisfying all constraints unlocks validation. Real keygens reverse this logic to generate unlimited valid keys (understand modulo algorithm, generate random valid chars for pos 0-2, calculate correct checksum for pos 3).",
requiredSkill: "Multi-Constraint Serial Key Validation & Keygen Algorithm Reverse Engineering",
objective: (s) => {
const pos0Valid = s.sortValue1 === 1; // POS0_VALID (1 = PASS)
const pos1Valid = s.sortValue2 === 1; // POS1_VALID (1 = PASS)
const pos2Valid = s.sortValue3 === 1; // POS2_VALID (1 = PASS)
const espNum = typeof s.esp === 'string' ? parseInt(s.esp, 16) : s.esp;
const pos3Valid = espNum === 1; // POS3_CKSUM (1 = PASS)
return pos0Valid && pos1Valid && pos2Valid && pos3Valid;
},
hint: "Four positions. Four constraints. One key. Calculate valid key: Position 0 must be uppercase letter (A-Z, ASCII 65-90). Position 1 must be digit (0-9, ASCII 48-57). Position 2 must be symbol (!-/, ASCII 33-47). Position 3 is checksum: ((pos0+pos1+pos2) % 26) + 65. Example: 'M5#J' → M=77, 5=53, #=35, checksum=(77+53+35)%26+65=74='J'. Manually set all 4 position flags to 1 in Memory Scanner to bypass (POS0_VALID=1, POS1_VALID=1, POS2_VALID=1, POS3_CKSUM=1).",
tutorPersona: "The Keygen Master: Serial key validation is constraint satisfaction problem. Real CD-KEYs use multi-stage validation - type checking then checksum. StarCraft validates each character position independently: is this digit valid? is checksum correct? Quake III uses similar algorithm. Your validator checks four positions atomically. Position 0: Type check uppercase letter. Assembly: MOV AL, [key_ptr]; CMP AL, 65; JL invalid_key; CMP AL, 90; JG invalid_key. Checks if ASCII in range [65-90] (A-Z). Examples: 'A'=65 valid, 'M'=77 valid, 'Z'=90 valid. Lowercase 'a'=97 rejected (>90). Digit '5'=53 rejected (<65). Position 1: Type check digit. Assembly: MOV AL, [key_ptr+1]; CMP AL, 48; JL invalid_key; CMP AL, 57; JG invalid_key. Checks range [48-57] (0-9). Examples: '0'=48 valid, '5'=53 valid, '9'=57 valid. Letter 'A'=65 rejected. Position 2: Type check symbol. Assembly: MOV AL, [key_ptr+2]; CMP AL, 33; JL invalid_key; CMP AL, 47; JG invalid_key. Checks range [33-47] (!\"#$%&'()*+,-./). Examples: '!'=33 valid, '#'=35 valid, '/'=47 valid. Space=32 rejected (too low). Colon=58 rejected (too high). Position 3: Checksum validation. Assembly: MOV AL, [key_ptr]; ADD AL, [key_ptr+1]; ADD AL, [key_ptr+2]; XOR EDX, EDX; MOV ECX, 26; DIV ECX; ADD DL, 65; CMP DL, [key_ptr+3]; JNE invalid_key. Loads first 3 chars, sums them, calculates modulo 26, adds 65 (maps to uppercase letter), compares with 4th char. This prevents random keys - checksum must match. Modulo 26 wraps sum to range [0-25], +65 converts to ASCII letter [65-90]. Example walkthrough: Test key 'M5#J'. Pos0: 'M'=77. Check 65≤77≤90? Yes (uppercase letter valid). Pos1: '5'=53. Check 48≤53≤57? Yes (digit valid). Pos2: '#'=35. Check 33≤35≤47? Yes (symbol valid). Pos3: Checksum calculation: (77+53+35) = 165. 165 MOD 26 = 9 (165÷26=6 remainder 9). 9+65 = 74 (ASCII 'J'). Compare 74 == 'J'(74)? Yes (checksum valid). All four validators pass → Key accepted. Use ExploitWorkshop Debugger tab to see validation assembly. Four CMP/JMP sequences visible. System Monitor C_Solver tab shows constraint status for each position (PASS/FAIL indicators). Memory Scanner can modify serialInput directly (type 4-char string). Hex Editor shows ASCII bytes of key (helpful for understanding byte values). Real keygens work like this: Generate random uppercase letter for pos0 (pick from A-Z). Generate random digit for pos1 (0-9). Generate random symbol for pos2 (pick from !-/). Calculate checksum: sum = pos0+pos1+pos2; checksum_char = ((sum % 26) + 65); Set pos3 = checksum_char. Result: Valid key. Unlimited keys generated. This is how StarCraft/Quake keygens worked - reverse validation algorithm, implement generator. Your task: Reverse engineer constraint logic (use Debugger), calculate valid checksum (use modulo math), craft valid serial key. Or analyze examples: 'A0!F', 'Z9/Y', etc. Understand algorithm. Generate valid key.",
memoryLayout: [
{ key: 'sortValue1', label: 'POS0_VALID', type: 'int', offset: 0xA0 },
{ key: 'sortValue2', label: 'POS1_VALID', type: 'int', offset: 0xA4 },
{ key: 'sortValue3', label: 'POS2_VALID', type: 'int', offset: 0xA8 },
{ key: 'esp', label: 'POS3_CKSUM', type: 'int', offset: 0x100 }
],
initialState: {
sortValue1: 0, // POS0_VALID (0 = position 0 failed constraint, set to 1 to bypass)
sortValue2: 0, // POS1_VALID (0 = position 1 failed constraint, set to 1 to bypass)
sortValue3: 0, // POS2_VALID (0 = position 2 failed constraint, set to 1 to bypass)
esp: '0', // POS3_CKSUM (0 = checksum validation failed, set to 1 to bypass)
serialInput: "" // (Internal only - not exposed to Memory Scanner)
},
platforms: [{ id: 'p1', x: 0, y: 280, width: 800, height: 40, type: 'static' }]
};