ineedcodes 1.6.1 → 1.7.0

package/skills/vm-and-bytecode-reverse/SKILL.md

@@ -0,0 +1,450 @@
+---
+name: vm-and-bytecode-reverse
+description: >-
+  Custom VM and bytecode reverse engineering playbook. Use when CTF challenges
+  or protected software implement custom virtual machines with proprietary
+  bytecode, dispatcher loops, or maze-style challenges.gated: true
+---
+
+# SKILL: VM & Bytecode Reverse Engineering — Expert Analysis Playbook
+
+> **AI LOAD INSTRUCTION**: Expert techniques for reversing custom virtual machines and bytecode interpreters. Covers dispatcher identification, opcode mapping, custom ISA reconstruction, disassembler/decompiler writing, maze challenges, and real-world VM protector analysis. Base models often fail to recognize the fetch-decode-execute pattern or attempt to analyze VM bytecode as native code.
+
+## 0. RELATED ROUTING
+
+- [code-obfuscation-deobfuscation](../code-obfuscation-deobfuscation/SKILL.md) when the VM is a commercial protector (VMProtect/Themida)
+- [symbolic-execution-tools](../symbolic-execution-tools/SKILL.md) when using angr to solve VM-based challenges
+- [anti-debugging-techniques](../anti-debugging-techniques/SKILL.md) when the VM includes anti-debug checks
+
+### Quick identification
+
+| Binary Pattern | Likely VM Type | Start With |
+|---|---|---|
+| `while(1) { switch(bytecode[pc]) }` | Switch-based dispatcher | Map each case to an operation |
+| Indirect jump via table `jmp [table + opcode*8]` | Table-based dispatcher | Dump jump table, analyze handlers |
+| Nested if-else chain on byte value | If-chain dispatcher | Same as switch, just different syntax |
+| Stack push/pop dominant operations | Stack-based VM | Identify push, pop, arithmetic ops |
+| `reg[X] = ...` array operations | Register-based VM | Map register indices to operations |
+| 2D grid + direction input | Maze challenge | Extract grid, apply BFS/DFS |
+
+---
+
+## 1. CUSTOM VM IDENTIFICATION
+
+### 1.1 Structural Indicators
+
+```
+VM Architecture Components:
+┌─────────────────────────────────┐
+│  Bytecode Program (data section)│
+├─────────────────────────────────┤
+│  Program Counter (pc/ip)        │
+│  Register File / Stack          │
+│  Memory / Data Area             │
+├─────────────────────────────────┤
+│  Dispatcher Loop                │
+│  ├─ Fetch: opcode = code[pc]    │
+│  ├─ Decode: lookup handler      │
+│  └─ Execute: run handler        │
+└─────────────────────────────────┘
+```
+
+### 1.2 IDA/Ghidra Signatures
+
+**Switch dispatcher** (most common in CTF):
+```c
+while (running) {
+    unsigned char op = bytecode[pc++];
+    switch (op) {
+        case 0x00: /* nop */       break;
+        case 0x01: /* push imm */  stack[sp++] = bytecode[pc++]; break;
+        case 0x02: /* add */       stack[sp-2] += stack[sp-1]; sp--; break;
+        // ...
+        case 0xFF: /* halt */      running = 0; break;
+    }
+}
+```
+
+**Table dispatcher** (more optimized):
+```c
+typedef void (*handler_t)(vm_ctx_t*);
+handler_t handlers[256] = { handle_nop, handle_push, handle_add, ... };
+
+while (running) {
+    handlers[bytecode[pc++]](&ctx);
+}
+```
+
+---
+
+## 2. ANALYSIS METHODOLOGY
+
+### Step 1: Find the Dispatcher
+
+Look for:
+- Large switch statement (many cases) in a loop
+- Array of function pointers indexed by a byte from a data buffer
+- Single function with high cyclomatic complexity
+- Cross-references to a data buffer read byte-by-byte
+
+### Step 2: Map Opcodes to Operations
+
+For each case/handler, determine:
+
+| Property | How to Identify |
+|---|---|
+| Opcode value | Case number or table index |
+| Operation type | Register/stack modifications |
+| Operand count | How many bytes consumed after opcode |
+| Operand type | Immediate value, register index, or memory address |
+| Side effects | Output, memory write, flag modification |
+
+### Step 3: Extract Bytecode Program
+
+```python
+# Typical extraction from binary
+import struct
+
+with open('challenge', 'rb') as f:
+    f.seek(bytecode_offset)
+    bytecode = f.read(bytecode_length)
+
+# Or from IDA:
+# bytecode = idc.get_bytes(bytecode_addr, bytecode_len)
+```
+
+### Step 4: Write Custom Disassembler
+
+```python
+OPCODES = {
+    0x00: ("nop",  0),    # (mnemonic, operand_bytes)
+    0x01: ("push", 1),    # push immediate byte
+    0x02: ("pop",  0),
+    0x03: ("add",  0),
+    0x04: ("sub",  0),
+    0x05: ("xor",  0),
+    0x06: ("cmp",  0),
+    0x07: ("jmp",  2),    # jump to 16-bit address
+    0x08: ("je",   2),
+    0x09: ("jne",  2),
+    0x0A: ("mov",  2),    # mov reg, imm
+    0x0B: ("load", 1),    # load from memory[operand]
+    0x0C: ("store",1),    # store to memory[operand]
+    0x0D: ("print",0),
+    0x0E: ("read", 0),    # read input
+    0xFF: ("halt", 0),
+}
+
+def disassemble(bytecode):
+    pc = 0
+    while pc < len(bytecode):
+        op = bytecode[pc]
+        if op not in OPCODES:
+            print(f"  {pc:04x}: UNKNOWN {op:#04x}")
+            pc += 1
+            continue
+
+        mnemonic, operand_size = OPCODES[op]
+        operands = bytecode[pc+1:pc+1+operand_size]
+        operand_str = ' '.join(f'{b:#04x}' for b in operands)
+        print(f"  {pc:04x}: {mnemonic:8s} {operand_str}")
+        pc += 1 + operand_size
+
+disassemble(bytecode)
+```
+
+### Step 5: Analyze Disassembled Program
+
+With the custom disassembly, apply standard reverse engineering:
+- Identify input reading (read opcode)
+- Trace data flow from input to comparison
+- Determine success/failure conditions
+- Extract the check logic (often XOR/ADD transformations of input compared against constants)
+
+---
+
+## 3. COMMON VM PATTERNS IN CTF
+
+### 3.1 Stack-Based VM
+
+Operations work on a stack (like JVM or Python bytecode).
+
+| Opcode | Operation | Stack Effect |
+|---|---|---|
+| PUSH imm | Push immediate value | [...] → [..., imm] |
+| POP | Discard top | [..., a] → [...] |
+| ADD | Add top two | [..., a, b] → [..., a+b] |
+| SUB | Subtract | [..., a, b] → [..., a-b] |
+| MUL | Multiply | [..., a, b] → [..., a*b] |
+| XOR | Bitwise XOR | [..., a, b] → [..., a^b] |
+| CMP | Compare | [..., a, b] → [..., (a==b)] |
+| JMP addr | Unconditional jump | no change |
+| JZ addr | Jump if top is zero | [..., a] → [...] |
+| PRINT | Output top as char | [..., a] → [...] |
+| READ | Read char to stack | [...] → [..., input] |
+| HALT | Stop execution | - |
+
+### 3.2 Register-Based VM
+
+Operations use register indices (like x86, ARM).
+
+| Opcode | Format | Operation |
+|---|---|---|
+| MOV r, imm | `0x01 RR II II` | reg[R] = imm16 |
+| MOV r1, r2 | `0x02 R1 R2` | reg[R1] = reg[R2] |
+| ADD r1, r2 | `0x03 R1 R2` | reg[R1] += reg[R2] |
+| SUB r1, r2 | `0x04 R1 R2` | reg[R1] -= reg[R2] |
+| XOR r1, r2 | `0x05 R1 R2` | reg[R1] ^= reg[R2] |
+| CMP r1, r2 | `0x06 R1 R2` | flags = compare(r1, r2) |
+| JMP addr | `0x07 AA AA` | pc = addr |
+| JE addr | `0x08 AA AA` | if equal: pc = addr |
+| LOAD r, [addr] | `0x09 RR AA` | reg[R] = mem[addr] |
+| STORE [addr], r | `0x0A AA RR` | mem[addr] = reg[R] |
+| SYSCALL | `0x0B` | I/O operation based on reg[0] |
+| HALT | `0xFF` | stop |
+
+### 3.3 Brainfuck-like / Esoteric VMs
+
+| BF Command | VM Equivalent | Description |
+|---|---|---|
+| `>` | INC ptr | Move data pointer right |
+| `<` | DEC ptr | Move data pointer left |
+| `+` | INC [ptr] | Increment byte at pointer |
+| `-` | DEC [ptr] | Decrement byte at pointer |
+| `.` | OUTPUT [ptr] | Output byte at pointer |
+| `,` | INPUT [ptr] | Input byte to pointer |
+| `[` | JZ forward | Jump past `]` if byte is zero |
+| `]` | JNZ back | Jump back to `[` if byte is nonzero |
+
+---
+
+## 4. MAZE CHALLENGES
+
+### 4.1 Identification
+
+- Binary reads directional input (WASD, arrow keys, UDLR)
+- 2D array in data section (walls, paths, start, end)
+- Position tracking with x,y coordinates
+- Win condition at specific coordinates
+
+### 4.2 Map Extraction
+
+```python
+# Extract maze grid from binary data section
+MAZE_ADDR = 0x601060
+WIDTH = 20
+HEIGHT = 15
+
+# From binary dump:
+maze = []
+for row in range(HEIGHT):
+    line = ""
+    for col in range(WIDTH):
+        cell = bytecode[MAZE_ADDR + row * WIDTH + col - base_addr]
+        if cell == 0: line += "."    # path
+        elif cell == 1: line += "#"  # wall
+        elif cell == 2: line += "S"  # start
+        elif cell == 3: line += "E"  # end
+        else: line += "?"
+    maze.append(line)
+    print(line)
+```
+
+### 4.3 Automated Solving
+
+```python
+from collections import deque
+
+def solve_maze(maze, start, end):
+    """BFS solver returns direction string."""
+    rows, cols = len(maze), len(maze[0])
+    directions = {'U': (-1, 0), 'D': (1, 0), 'L': (0, -1), 'R': (0, 1)}
+    queue = deque([(start, "")])
+    visited = {start}
+
+    while queue:
+        (r, c), path = queue.popleft()
+        if (r, c) == end:
+            return path
+
+        for name, (dr, dc) in directions.items():
+            nr, nc = r + dr, c + dc
+            if (0 <= nr < rows and 0 <= nc < cols and
+                maze[nr][nc] != '#' and (nr, nc) not in visited):
+                visited.add((nr, nc))
+                queue.append(((nr, nc), path + name))
+
+    return None
+
+# Find start and end positions
+for r, row in enumerate(maze):
+    for c, cell in enumerate(row):
+        if cell == 'S': start = (r, c)
+        if cell == 'E': end = (r, c)
+
+solution = solve_maze(maze, start, end)
+print(f"Path: {solution}")
+```
+
+### 4.4 Direction Encoding
+
+Different challenges encode directions differently:
+
+| Encoding | Up | Down | Left | Right |
+|---|---|---|---|---|
+| WASD | W | S | A | D |
+| UDLR | U | D | L | R |
+| Arrow keys | ↑ (0x48) | ↓ (0x50) | ← (0x4B) | → (0x4D) |
+| Numbers | 1 | 2 | 3 | 4 |
+| Hex opcodes | 0x01 | 0x02 | 0x03 | 0x04 |
+
+---
+
+## 5. REAL-WORLD VM PROTECTORS
+
+### 5.1 VMProtect Analysis Approach
+
+```
+1. Find VM entry: search for pushad/pushfd sequence
+2. Identify VM context structure (registers, flags, bytecode pointer)
+3. Locate handler table (often obfuscated with opaque predicates)
+4. For each handler:
+   a. Remove junk code / opaque predicates
+   b. Identify the core operation
+   c. Document handler semantics
+5. Trace bytecode execution (instruction-level trace)
+6. Reconstruct original code from trace
+```
+
+### 5.2 Tigress Obfuscator
+
+Academic VM obfuscator with configurable protection layers.
+
+| Feature | Approach |
+|---|---|
+| Single-dispatch VM | Standard handler extraction |
+| Split handlers | Handlers spread across multiple functions |
+| Nested VMs | Outer VM handler invokes inner VM |
+| Encrypted bytecode | Dynamic decryption before each fetch |
+| Polymorphic handlers | Different code for same operation on each build |
+
+### 5.3 Common VM Protector Patterns
+
+| Protector | Dispatcher Style | Difficulty |
+|---|---|---|
+| VMProtect | Table + opaque predicates | High |
+| Themida (Code Virtualizer) | CISC-like, large handler set | High |
+| Tigress | Configurable, academic | Medium-High |
+| Custom CTF VM | Simple switch | Low-Medium |
+| Movfuscator | All-mov computation | Medium |
+
+---
+
+## 6. TOOLS
+
+| Tool | Purpose | Usage |
+|---|---|---|
+| IDA Pro | Identify dispatcher, reverse handlers | F5 decompile, xref analysis |
+| Ghidra | Free alternative with Sleigh processor modules | Write custom processor for VM ISA |
+| angr | Symbolic execution through VM | Treat entire VM as constraint system |
+| Pin / DynamoRIO | Dynamic instrumentation for tracing | Record opcode handler execution sequence |
+| REVEN | Full-system trace recording | Replay and analyze VM execution |
+| Unicorn | Emulate VM execution | Fast handler emulation |
+| Miasm | IR-based analysis | Lift VM handlers to IR for analysis |
+| Custom Python | Write disassembler/decompiler | Per-challenge custom tooling |
+
+### Ghidra Sleigh Processor Module
+
+For recurring VM architectures, write a Sleigh processor specification:
+
+```
+define space ram      type=ram_space      size=2  default;
+define space register type=register_space  size=1;
+
+define register offset=0 size=1 [ R0 R1 R2 R3 FLAGS PC SP ];
+
+define token opcode(8)
+    op = (0,7)
+;
+
+:NOP    is op=0x00 { }
+:PUSH   imm is op=0x01; imm { SP = SP - 1; *[ram]:1 SP = imm; }
+:POP    is op=0x02 { SP = SP + 1; }
+:ADD    is op=0x03 { local a = *[ram]:1 (SP+1); *[ram]:1 (SP+1) = a + *[ram]:1 SP; SP = SP + 1; }
+```
+
+---
+
+## 7. DECISION TREE
+
+```
+Binary contains custom bytecode interpreter?
+│
+├─ Can you identify the dispatcher?
+│  ├─ Yes (switch/table/if-chain)
+│  │  ├─ Few opcodes (< 20) → Simple CTF VM
+│  │  │  ├─ Stack-based → map push/pop/arithmetic ops
+│  │  │  ├─ Register-based → map mov/add/cmp ops
+│  │  │  └─ Write disassembler → analyze program → solve
+│  │  │
+│  │  └─ Many opcodes (50+) → Commercial protector
+│  │     ├─ Known protector → use specific deprotection tools
+│  │     └─ Custom → trace execution, pattern-match handlers
+│  │
+│  └─ No clear dispatcher
+│     ├─ All-mov instructions → movfuscator
+│     ├─ Encrypted bytecode → find decryption, dump after decode
+│     └─ Split/distributed handlers → trace execution to find them
+│
+├─ Is it a maze challenge?
+│  ├─ Extract grid from data section
+│  ├─ Identify direction encoding
+│  ├─ BFS/DFS to find shortest path
+│  └─ Convert path to expected input format
+│
+├─ Is there input validation in VM?
+│  ├─ Small input space → brute-force via Unicorn emulation
+│  ├─ Known format → constrained angr solve
+│  └─ Complex check → write disassembler, analyze check logic
+│
+└─ Multiple VM layers (VM in VM)?
+   ├─ Analyze outer VM first
+   ├─ Extract inner bytecode
+   ├─ Repeat analysis for inner VM
+   └─ Consider: symbolic execution may handle nested VMs directly
+```
+
+---
+
+## 8. CTF SOLVING WORKFLOW
+
+```
+1. Run the binary — understand I/O behavior
+   └─ What input does it expect? What output on success/failure?
+
+2. Open in IDA/Ghidra — find the main loop
+   └─ Look for while/for loop with switch or indirect jump
+
+3. Identify VM components:
+   ├─ Bytecode location (where is the program data?)
+   ├─ PC/IP variable (how is current position tracked?)
+   ├─ Registers/stack (where is VM state stored?)
+   └─ I/O handlers (which opcodes read input / write output?)
+
+4. Map all opcodes (create the ISA specification)
+   └─ For each case/handler: opcode number, operation, operands
+
+5. Write disassembler in Python
+   └─ Output readable assembly for the bytecode
+
+6. Analyze the disassembled program:
+   ├─ Find input reading
+   ├─ Trace transformations applied to input
+   ├─ Find comparison against expected values
+   └─ Reverse the transformation to find valid input
+
+7. Solve:
+   ├─ If simple transforms (XOR, ADD) → reverse manually
+   ├─ If complex → feed to Z3 as constraints
+   └─ If maze → extract grid, run pathfinding
+```

package/skills/vr-cheatsheet-authentication_bypass/SKILL.md

@@ -0,0 +1,184 @@
+---
+name: vr-cheatsheet-authentication_bypass
+description: >-
+  Vulnerability research reference: authentication_bypassgated: true
+---
+# 🔐 Authentication & Identity (JWT, OAuth, SAML) Cheatsheet
+
+---
+
+## 🎟️ 1. JWT (JSON Web Tokens) Attacks
+
+*JWTs are base64-url encoded strings divided into three parts: `Header.Payload.Signature`. Always decode them (e.g., at jwt.io) to inspect the claims.*
+
+### The `alg=none` Bypass
+
+*Many libraries fail to verify the signature if the header explicitly tells them not to.*
+
+1. Decode the Header.
+2. Change `"alg": "HS256"` (or RS256) to `"alg": "none"` (also try `"None"`, `"NONE"`).
+3. Modify the Payload (e.g., `"role": "admin"`).
+4. Remove the signature but **leave the trailing dot**.
+
+* **Payload:** `eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiaGFja2VyIiwicm9sZSI6ImFkbWluIn0.`
+
+### Key Confusion (Algorithm Swap: RS256 -> HS256)
+
+*If the server expects an RSA public key (RS256) but you force it to use HMAC (HS256), the server might verify the token using its own public key as the HMAC secret.*
+
+1. Obtain the server's public key (often at `/.well-known/jwks.json`).
+2. Change the header algorithm to `HS256`.
+3. Sign your forged token using the **public key string** as the HMAC secret.
+
+### JWK (JSON Web Key) Injection
+
+*If the token header accepts a `jwk` parameter, you can inject your own public key and sign the token with your matching private key.*
+
+```json
+// Malicious Header
+{
+  "alg": "RS256",
+  "jwk": {
+    "kty": "RSA",
+    "e": "AQAB",
+    "n": "vOUR_MALICIOUS_PUBLIC_KEY_MODULUS..."
+  }
+}
+
+```
+
+### Offline Cracking
+
+*If the JWT uses HS256 (symmetric key), extract it and attempt to crack the secret offline.*
+
+```bash
+hashcat -a 0 -m 16500 jwt.txt rockyou.txt
+
+```
+
+---
+
+## 🤝 2. OAuth 2.0 & OpenID Connect (OIDC)
+
+*OAuth is an authorization framework; OIDC adds an identity layer on top. Vulnerabilities usually stem from bad implementation, not the protocol itself.*
+
+### Redirect URI Manipulation (Token Stealing)
+
+*The `redirect_uri` parameter controls where the OAuth provider sends the authorization code or token. If this is not strictly whitelisted, you can steal the token.*
+
+* **Target:** `https://provider.com/auth?client_id=123&redirect_uri=https://attacker.com`
+* **Bypasses:**
+* `https://client.com.attacker.com` (Subdomain bypass)
+* `https://client.com/callback?redirect=https://attacker.com` (Open redirect chaining)
+* `https://client.com%2Eattacker.com` (URL encoding)
+* `https://client.com@attacker.com` (Credentials syntax)
+
+
+
+### CSRF via Missing `state` Parameter
+
+*If the initial authorization request lacks a `state` parameter (or the server doesn't validate it), you can force a victim to log into your account.*
+
+1. Attacker initiates a login with the provider but intercepts the response containing the authorization `code`.
+2. Attacker drops the request and sends the callback URL (with the `code`) to the victim.
+3. The victim clicks the link, tying their local session to the attacker's third-party account (useful for capturing sensitive info saved to the account).
+
+### Pre-Account Takeover (Implicit Trust)
+
+*If an application allows email/password registration AND OAuth login (e.g., "Log in with Google"), check if it verifies emails.*
+
+1. Attacker registers an account using `victim@company.com` and a password they control.
+2. Victim later logs in using "Log in with Google".
+3. If the application merges the accounts without verifying the initial email, the attacker still has access via the password.
+
+---
+
+## 🏢 3. SAML (Security Assertion Markup Language)
+
+*SAML uses XML to pass identity assertions between an Identity Provider (IdP) and a Service Provider (SP).*
+
+### XML Signature Wrapping (XSW)
+
+*SAML messages are signed to prevent tampering. XSW involves injecting a fake assertion while keeping the original, validly signed assertion intact to trick the parser.*
+
+1. Intercept the SAML Response (base64 decoded).
+2. Clone the `<Assertion>` block.
+3. Modify the cloned assertion (e.g., change the `<NameID>` to `admin@corp.com`).
+4. Place the cloned assertion in a way that the signature validation logic checks the *original*, but the application logic reads the *fake* one (e.g., moving the original assertion into a wrapper element).
+
+* **Tool:** Use the **SAML Raider** extension in Burp Suite to automate XSW attacks.
+
+### Signature Stripping
+
+*Some poorly configured SPs only validate the signature if it exists.*
+
+1. Intercept the SAML response.
+2. Completely delete the `<ds:Signature>` block.
+3. Modify the assertion and forward it.
+
+### XML Comment Injection
+
+*Tricking the parser's username extraction logic by breaking the string with XML comments.*
+
+* **Target Account:** `admin@corp.com`
+* **Registered Malicious Account:** `admin@corp.com.evil.com`
+* If the parser strips comments before checking the database, it evaluates to `admin@corp.com.evil.com`. If it strips comments *after* string evaluation, it might truncate or bypass filters to match `admin@corp.com`.
+
+---
+
+## 🚪 4. General Authentication & MFA Flaws
+
+### MFA Response Manipulation
+
+*Sometimes the server sends the MFA success/fail status to the client to make routing decisions.*
+
+* Intercept the HTTP response from a failed MFA attempt:
+```http
+HTTP/1.1 401 Unauthorized
+{"success": false, "message": "Invalid Code"}
+
+```
+
+
+* Modify it to simulate success before it hits the browser:
+```http
+HTTP/1.1 200 OK
+{"success": true, "message": "Authenticated"}
+
+```
+
+
+
+### Password Reset Host Header Poisoning
+
+*If the server uses the HTTP `Host` header to generate the password reset link, you can steal the token.*
+
+```http
+POST /api/reset-password HTTP/1.1
+Host: evil-server.com
+Content-Type: application/json
+
+{"email": "admin@target.com"}
+
+```
+
+*If vulnerable, the server emails the victim a link like: `https://evil-server.com/reset?token=123xyz`. When the victim clicks, the attacker captures the token.*
+
+---
+
+## Takeaways
+
+### Offensive Perspective
+
+* **The "Trust but Don't Verify" Paradigm:** Applications often assume that because a token *looks* like it came from a trusted provider (Google, Okta, Auth0), it is safe. Always test what happens when you strip the signature (`alg=none`) or alter the cryptographic algorithm (e.g., swapping RS256 for HS256). If the backend dynamically trusts the `alg` header without enforcing a strict whitelist, the door is wide open.
+* **Exploit the Translation Gap (SAML/OAuth):** In enterprise SSO, vulnerabilities almost always live in the parsing differences between the Identity Provider (IdP) and the Service Provider (SP). For example, in SAML XML Signature Wrapping (XSW), the goal is to find out if the SP's signature validator looks at one part of the document while the actual application logic reads another. Find the desync, find the bug.
+* **State and Context Loss:** Look for missing `state` or `nonce` parameters in OAuth flows. Developers frequently implement the "happy path" for user login but completely forget to protect against an attacker forcing a victim into a specific session (Login CSRF) or intercepting the authorization code via open redirects.
+
+### Defensive Perspective
+
+* **Never Roll Your Own Crypto or Parsers:** Whether it's JWT validation or parsing SAML XML, strictly use established, heavily audited libraries. The vast majority of identity-related CVEs over the last decade stem from developers trying to manually parse claims or verify signatures using custom string manipulation or regex.
+* **Enforce Strict Cryptographic Expectations:** Do not let the client dictate the cryptographic algorithm. If your application expects an RSA-signed token (RS256), configure the backend to explicitly *reject* HS256, `none`, or any other algorithm. Never blindly trust the `alg` header provided by the user's token.
+* **Modernize OAuth Implementations:** Always mandate the `state` parameter to tie the authorization request to the user's specific browser session, preventing CSRF. Furthermore, implement PKCE (Proof Key for Code Exchange) by default—even for confidential backend web clients—to comprehensively protect against authorization code interception.
+* **Harden XML Parsers (SAML):** Before a SAML signature is even verified, the underlying XML parser must be locked down. Explicitly disable XML External Entities (XXE) and Document Type Definitions (DTDs) to prevent entity expansion attacks. Ensure the parser enforces strict schema validation so cloned or wrapper assertions (XSW) cause the transaction to fail safely.
+
+> Source: skraft9/vulnerability-research. Authorized security work only. Gated skill: needs the developer keyword.