code-vulnerability-analysis

name	Code Vulnerability Analysis
description	Next-generation 0day discovery & exploit development — comprehensive code analysis, allocator vulnerabilities, compiler-induced bugs, SIMD/vector issues, JIT vulnerabilities, custom allocator attacks, ASLR/kASLR bypass, UAF, OOB, RCE with exploit generation, privilege escalation, backdoor establishment
tags	["vulnerability","exploit","0day","security","code-analysis","C","buffer-overflow","use-after-free","race-condition","integer-overflow","memory-corruption","RCE","remote-code-execution","next-gen-overflow","allocator-exploit","compiler-bug","bounds-check-bypass","SIMD-overflow","vector-overflow","JIT-overflow","integer-wrapping","sign-extension","ASLR-bypass","kASLR-bypass","code-execution","privilege-escalation","exploit-development","PoC","weaponized-exploit","heap-spray","ROP","shellcode","novel-vulnerability","unknown-vulnerability","root-access","backdoor","reverse-shell","post-exploitation","persistence","custom-allocator","structure-padding","VLA-overflow","template-bug","GC-overflow","LTO-bugs","PGO-bugs","format-string","type-confusion","command-injection","heap-overflow","stack-overflow","TOTCU","double-free","memory-leak","info-leak","bypass-mitigations","DEP-bypass","NX-bypass","canary-bypass","ASLR-bypass","ROP-chain","heap-feng-shui","symbolic-execution","data-flow-analysis"]
version	2.1
author	Spectra Security Research

Code Vulnerability Analysis & 0day Discovery

Purpose: Systematic discovery of previously unknown vulnerabilities (0day) through deep code analysis and C-based exploit development.

Authorized Use Cases Only:

• CTF competitions and capture-the-flag challenges
• Authorized security audits and penetration testing
• Bug bounty programs with explicit scope
• Security research with proper disclosure
• Educational purposes with isolated test environments

Prohibited: Unauthorized access, malicious exploitation, targeting production systems without explicit permission.

---

Core Methodology: The 0day Discovery Framework

This skill follows a systematic approach to finding vulnerabilities that have NOT been previously disclosed:

Phase 1: Target Selection & Pre-Analysis Assessment
Phase 2: Attack Surface Mapping
Phase 3: Input Tracing & Data Flow Analysis
Phase 4: Comprehensive Code Analysis
Phase 5: Exploitability Assessment
Phase 6: Exploit Development (Authorized Contexts)
Phase 7: 0day Verification (Critical Step)
Phase 8: Proof-of-Concept & Reporting

---

Phase 1: Target Selection & Pre-Analysis Assessment

1.1 Target Viability Matrix

Before deep analysis, assess if target is worth the effort:

┌────────────────────────────────────────────────────────────┐
│ Factor                     │ High Value │ Low Value       │
├────────────────────────────────────────────────────────────┤
│ Recent code changes        │ < 6 months │ > 2 years      │
│ Complex parsing logic      │ Yes        │ No              │
│ User-controlled input     │ Multiple   │ None/Limited    │
│ Memory unsafe languages    │ C/C++/Rust│ Java/Python     │
│ Previous security history  │ Yes        │ No              │
│ Public CVE count (last yr) │ 0-2        │ 10+             │
│ Codebase size             │ 50K-500K   │ < 5K or > 5M    │
│ Fuzzing coverage           │ None/Low   │ High (AFL++)    │
└────────────────────────────────────────────────────────────┘

1.2 Exclude Known Vulnerabilities

Systematic check to avoid rediscovering known bugs:

# Check CVE database for target
cvesearch -c "<software_name>" -y "<year_range>"

# Search security advisories
searchsploit "<software_name>" <version>

# Check bug bounty disclosed reports
# (HackerOne, Bugcrowd, Immunefi)

# Verify code age vs public disclosures
git log --since="2020-01-01" --grep="fix\|security\|CVE"

---

Phase 2: Attack Surface Mapping

2.1 Entry Point Identification

Identify ALL attacker-controlled input paths:

2.2 Dangerous API Catalog

2.3 Comprehensive Code Analysis

Instead of pattern searching, analyze code holistically:

Holistic Analysis Principles:

• Read entire functions, not grep for dangerous APIs
• Understand data flow from input to output
• Follow all code paths (branches, loops, error handling)
• Consider interaction between components
• Analyze state changes over time
• Understand the system's purpose and design

What to Avoid:

• ❌ Don't grep for memcpy/strcpy and assume vulnerability
• ❌ Don't look at code snippets in isolation
• ❌ Don't rely on pattern matching for security assessment
• ❌ Don't skip "boring" code - bugs hide in unexpected places
• ❌ Don't assume validation exists without reading it

What to Do Instead:

• ✅ Read complete functions from start to finish
• ✅ Understand where ALL inputs come from
• ✅ Trace how data flows through the system
• ✅ Read validation code to verify it's correct
• ✅ Consider edge cases and error conditions
• ✅ Understand the system's threat model

---

Phase 3: Input Tracing & Data Flow Analysis

3.1 Backward Data Tracing

For each dangerous API found:

Tracing Steps:

1. Locate the dangerous API → memcpy at line 4
2. Trace backward: Where does packet_len come from?
   • Function parameter (user-controlled)
3. Trace backward: Where does packet_data come from?
   • Function parameter (user-controlled)
4. Check for validation: Is there ANY bounds check between input and API?
   • NO validation → VULNERABLE
5. Check for mitigations: Stack canary, ASLR, PIE?
   • Determine bypass strategy

3.2 Forward Data Tracing

After identifying input source, trace forward:

Input Source → Parsing → Validation → Use → Dangerous API
                        ↑          ↑         ↑
                    Is there   Can we   Which API
                    validation? bypass?   is hit?

---

Phase 4: Comprehensive Code Analysis

Core Principle: Read complete code, understand context, trace execution paths. Do not rely on pattern matching or grep searches.

Analysis Methodology

For each function or code module:

1. Read the Complete Function

   • Start from the beginning, read to the end
   • Understand what the function does
   • Identify all inputs and outputs
   • Follow all code paths (branches, loops, error handling)

2. Understand Data Sources

   • Where do function parameters come from?
   • Read all callers to understand input origins
   • Check if data is user-controlled or trusted
   • Consider global state and file/network input

3. Trace Data Transformations

   • How is data processed within the function?
   • Are there validations or sanitization steps?
   • Can data be transformed in unexpected ways?
   • Consider edge cases and error conditions

4. Follow All Code Paths

   • Read all branches (if/else, switch)
   • Understand loop conditions and termination
   • Check error handling paths
   • Consider exceptional conditions

5. Analyze Memory Operations

   • For allocations: understand size calculations
   • For copies: verify bounds checking exists and is correct
   • For frees: check pointer lifecycle
   • Consider threading and concurrency

6. Consider Interactions

   • How do functions interact with each other?
   • Are there shared state or race conditions?
   • Can one function's output affect another's security?
   • Consider the system's threat model

What to Avoid

❌ Don't grep for dangerous APIs and assume vulnerability

• Finding memcpy() doesn't mean there's an overflow
• Read the context to understand if it's safe

❌ Don't analyze code snippets in isolation

• Vulnerabilities exist in context, not in isolated lines
• Read the complete function and its callers

❌ Don't rely on pattern matching

• Every pattern has exceptions
• Context determines if code is vulnerable

❌ Don't skip "boring" code

• Bugs hide in unexpected places
• Error handling and edge cases matter

❌ Don't assume validation exists

• Read the validation code yourself
• Verify it's correct for all cases

What to Do Instead

✅ Read complete functions from start to finish

• Understand the full context
• Consider all code paths

✅ Understand where ALL inputs come from

• Trace back to source
• Check if data is user-controlled

✅ Trace how data flows through the system

• Follow transformations
• Check validation points

✅ Read validation code to verify it's correct

• Don't assume it works
• Test boundary conditions

✅ Consider edge cases and error conditions

• What happens with unusual inputs?
• Are error paths secure?

✅ Understand the system's threat model

• What are the security requirements?
• What could an attacker control?

---

Phase 5: Exploitability Assessment

5.1 Exploitability Criteria

For each potential vulnerability, assess:

┌─────────────────────────────────────────────────────────────┐
│ Factor                    │ Exploitable │ Not Exploitable  │
├─────────────────────────────────────────────────────────────┤
│ Attacker controls input   │ Yes         │ No               │
│ Input size可控可控         │ Yes         │ Fixed size       │
│ No validation             │ Yes         │ Has validation    │
│ Reachable from entry      │ Yes         │ Internal only    │
│ Bypassable mitigations    │ Yes         │ Protected        │
│ Reliable trigger          │ Yes         │ Race/Timing only │
│ Impact > DoS              │ Yes         │ DoS only         │
└─────────────────────────────────────────────────────────────┘

5.2 Impact Classification

CRITICAL (Remote Code Execution)
- Arbitrary code execution on remote system
- Network-triggered memory corruption
- Exploitable format string from network

HIGH (Local Code Execution / Privilege Escalation)
- Local exploit for code execution
- Kernel-mode memory corruption
- Privilege escalation vulnerabilities

MEDIUM (Information Disclosure / DoS)
- Memory leaks (addresses, sensitive data)
- Reliable denial-of-service
- ASLR bypass primitives

LOW (Limited Impact)
- Theoretical issues requiring unrealistic conditions
- DoS with low reliability
- Information disclosure with limited value

---

Phase 6: Exploit Development (Authorized Contexts Only)

⚠️ IMPORTANT: Exploit development is ONLY permitted in:

• CTF competitions and security challenges
• Authorized penetration testing with written permission
• Bug bounty programs with explicit scope
• Isolated research environments with proper disclosure

Prohibited in all other contexts.

Exploit Development Methodology

When authorized to develop exploits:

1. Understand the Vulnerability Completely

   • Read the vulnerable code thoroughly
   • Understand what triggers the vulnerability
   • Identify the exact conditions for exploitation
   • Determine reliability and success rate

2. Analyze Target Mitigations

   • What security mitigations are present?
   • ASLR, DEP/NX, Stack Canaries, SMEP, SMAP?
   • Can they be bypassed?
   • What techniques are applicable?

3. Develop Exploit Strategy

   • Determine exploit primitive (read, write, execute)
   • Plan mitigation bypasses
   • Design reliable trigger mechanism
   • Consider exploit stability

4. Test in Isolated Environment

   • Use isolated test systems
   • Verify exploit works reliably
   • Document success rate
   • Test against different configurations

5. Document Thoroughly

   • Explain vulnerability root cause
   • Document exploitation steps
   • Specify affected versions/configurations
   • Include proof-of-concept for verification

Reporting Requirements

When reporting vulnerabilities:

1. Provide Complete Technical Details

   • Root cause analysis
   • Exploitation steps
   • Proof-of-concept (if authorized)
   • Impact assessment

2. Include Reproduction Steps

   • Clear steps to reproduce
   • Required conditions
   • Expected vs actual behavior

3. Specify Affected Versions

   • Version numbers tested
   • Configuration details
   • Platform/architecture information

4. Propose Remediation

   • Suggested fix or workaround
   • Root cause explanation
   • Verification of fix

Verification Before Reporting

Before claiming a vulnerability:

1. Confirm Novelty (for 0day)

   • Check CVE database
   • Check Exploit-DB
   • Check vendor advisories
   • Search public disclosures

2. Verify Exploitability

   • Test exploit works
   • Check reliability > 50%
   • Verify across configurations
   • Document bypasses

3. Assess Impact Accurately

   • Don't overstate or understate
   • Consider realistic attack scenarios
   • Assess affected user base
   • Calculate appropriate severity

4. Ensure Responsible Disclosure

   • Report to vendor first
   • Allow reasonable patch time
   • Coordinate disclosure
   • Follow responsible disclosure practices

---

Phase 7: 0day Verification (Critical Step)

7.1 Known Vulnerability Database Check

Before claiming 0day, systematically verify novelty:

# CVE Database Check
cve-search -p "software_name" -y 2020-2026

# Exploit-DB Check
searchsploit "software_name version"

# GitHub Security Advisories
gh api /repos/vendor/project/security-advisories

# NVD (National Vulnerability Database)
curl "https://services.nvd.nist.gov/rest/json/cves/2.0?keywordSearch=software"

# Vendor advisories
# Check official security bulletins

# Bug bounty programs (HackerOne, Bugcrowd)
# Search for disclosed reports with similar patterns

7.2 Novelty Assessment

Known Vulnerability Indicators (AVOID - These are likely already disclosed):
┌─────────────────────────────────────────────────────────────┐
│ Type                     │ Example                              │
├─────────────────────────────────────────────────────────────┤
│ Classic stack overflow│ strcpy(user_input) in well-known app │
│ Format string         │ printf(user_input) in old code        │
│ Simple heap overflow  │ malloc(size) + memcpy(unchecked)     │
│ Basic UAF             │ free(); obj->method() pattern        │
│ Integer overflow      │ size = a + b; malloc(size) pattern    │
└─────────────────────────────────────────────────────────────┘

Novel Vulnerability Indicators (PURSUE - These may be 0day):
┌─────────────────────────────────────────────────────────────┐
│ Indicator                 │ Example                          │
├─────────────────────────────────────────────────────────────┤
│ Unique code path          │ Unusual error handling path      │
│ New parser logic          │ Recently added protocol support  │
│ Complex state machine     │ Multi-stage state transitions    │
│ Custom allocator         │ Application-specific memory mgmt  │
│ Rare API combination      │ Unusual function interactions    │
│ Architecture-specific    │ ARM64 MTE bypass, Apple quirks    │
│ Compiler-generated       │ Optimizer-introduced bug          │
└─────────────────────────────────────────────────────────────┘

7.3 0day Verification Checklist

□ Checked CVE database for similar vulnerabilities
□ Checked Exploit-DB for public exploits
□ Checked vendor security advisories
□ Checked GitHub/security advisories
□ Verified vulnerability is NOT in common vulnerability databases
□ Verified pattern is NOT in well-known bug classes
□ Verified exploit works on current version (not patched)
□ Verified no public disclosure exists
□ Verified no similar bug bounty reports disclosed
□ Confirmed vulnerability affects latest release

---

Phase 8: Proof-of-Concept & Reporting

8.1 Professional PoC Template

8.2 Vulnerability Report Template

# 0day Vulnerability Report: [Title]

## Executive Summary

- **Vulnerability**: [Vulnerability Name]
- **Impact**: [Impact Description]
- **Affected Software**: [Software Name]
- **Affected Versions**: [Version Range]
- **Discovery Date**: [Date]
- **Researcher**: [Your Name/Handle]

## Technical Details

### Vulnerability Description

[Detailed description of the vulnerability, including code snippets]

### Root Cause Analysis


The vulnerability occurs because:
1. [Reason 1]
2. [Reason 2]
3. [Reason 3]

### Exploitation

[Step-by-step exploitation explanation]

### Proof of Concept

[PoC code or reference to attached file]

### Impact Assessment

- **Local Impact**: [Description]
- **Remote Impact**: [Description]
- **Privilege Escalation**: [Yes/No + Explanation]
- **Affected Configurations**: [Description]

### Mitigation

[Recommended fix or workaround]

### Timeline

- [Date]: Vulnerability discovered
- [Date]: Report submitted
- [Date]: Vendor response
- [Date]: Patch released
- [Date]: Public disclosure

## References

- [Internal references]
- [Similar vulnerabilities]
- [Relevant documentation]

---

Quick Reference: 0day Discovery Workflow

┌──────────────────────────────────────────────────────────────────┐
│  0day Discovery Flowchart                                        │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  START: Target Selection                                         │
│    ↓                                                             │
│  Pre-Analysis: Check CVE/Exploit-DB for known bugs              │
│    ↓                                                             │
│  Attack Surface: Identify entry points (network/file/user)     │
│    ↓                                                             │
│  Code Analysis: Trace data flow from inputs to dangerous APIs  │
│    ↓                                                             │
│  Pattern Recognition: Match against vulnerability patterns      │
│    ↓                                                             │
│  Exploitability: Assess impact and bypassability                │
│    ↓                                                             │
│  Exploit Dev: Write C PoC to demonstrate exploitation           │
│    ↓                                                             │
│  Novelty Check: Verify NOT in CVE/Exploit-DB/public             │
│    ↓                                                             │
│  CONFIRMED 0day: Report to vendor or bug bounty                 │
│    ↓                                                             │
│  If known: Document learning, move to next target               │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

---

Ethical Guidelines

This skill is designed for authorized security research only:

1. Explicit Permission Required

   • Bug bounty programs with clear scope
   • Authorized penetration testing engagements
   • CTF competitions with isolated targets
   • Security research with responsible disclosure plan

2. Prohibited Actions

   • Unauthorized access to production systems
   • Testing systems without explicit permission
   • Targeting critical infrastructure without authorization
   • Public disclosure without vendor coordination

3. Responsible Disclosure

   • Report vulnerabilities to vendor first
   • Allow reasonable time for patch development (typically 90 days)
   • Coordinate disclosure timeline
   • Provide sufficient technical detail for remediation

4. Legal Compliance

   • Comply with local laws and regulations
   • Respect terms of service
   • Avoid unauthorized data collection
   • Document authorization for all testing

---

Common Pitfalls to Avoid

❌ Don't: Report known vulnerabilities as 0day
✅ Do: Verify novelty against CVE/Exploit-DB before claiming 0day

❌ Don't: Test systems without explicit permission
✅ Do: Get written authorization before any testing

❌ Don't: Assume vulnerability is exploitable without PoC
✅ Do: Demonstrate reliable exploitation with C code

❌ Don't: Focus only on obvious patterns
✅ Do: Look for novel code paths and recent changes

❌ Don't: Ignore mitigations in exploit development
✅ Do: Address ASLR, NX, canaries, and other protections

❌ Don't: Disclose publicly without vendor coordination
✅ Do: Follow responsible disclosure practices

---

Advanced 0day Detection Techniques

Technique 1: Compiler Output Analysis

Analyze compiler-generated assembly for bugs:

# Compile with debug info
gcc -g -O2 -S target.c -o target.s

# Look for:
# - Removed safety checks
# - Reordered operations
# - Optimized-away bounds checks
# - Inline assembly without checks

# Compare optimization levels
gcc -O0 -S target.c -O0.s
gcc -O2 -S target.c -O2.s
diff O0.s O2.s  # Find removed checks

Technique 2: Fuzzing with Structure Awareness

Structure-aware fuzzing:

Technique 3: Symbolic Execution for Novel Paths

Use symbolic execution to find:

# Angr symbolic execution example
import angr

proj = angr.Project("./target_binary")
state = proj.factory.entry_state()

# Symbolic variables
user_size = state.solver.BVS("user_size", 32)

# Constrain to novel paths
# Avoid standard bounds checks
state.solver.add(user_size > 0x1000)  # Large size
state.solver.add(user_size < 0xFFFF)  # But not too large

# Explore paths
simgr = proj.factory.simulation_manager(state)
simgr.explore(find=lambda s: "overflow" in s.posix.dumps(1))

Technique 4: Data Flow Sanitization

Track data flow from inputs to dangerous sinks:

# For each function call:
# 1. Identify arguments
# 2. Trace back to source
# 3. Check transformations
# 4. Identify validation points
# 5. Find bypass opportunities

def analyze_data_flow(function_call):
    for arg in function_call.arguments:
        source = trace_back(arg)
        if is_user_controlled(source):
            validations = find_validations(arg)
            if not validations or can_bypass(validations):
                print(f"VULNERABLE: {function_call.name} arg {arg}")

---

Core 0day Discovery Philosophy

This skill prioritizes NOVEL vulnerability patterns over known ones:

Novel Indicators (PURSUE)

✓ Recent code changes (< 6 months) ✓ Complex parser logic in network handlers ✓ Custom allocator implementations ✓ Compiler optimization-induced bugs ✓ Architecture-specific optimizations ✓ Integration points (old + new code) ✓ Custom memory pool implementations ✓ SIMD/Vector processing code ✓ JIT compilation code paths ✓ Template/metaprogramming code

Known Vulnerability Types (AVOID)

✗ Classic strcpy/gets in old code ✗ Well-documented malloc patterns ✗ Standard format string vulnerabilities ✗ Common integer overflow patterns ✗ Published CVE patterns

Novelty Verification Workflow

1. Pre-Analysis: Check CVE/Exploit-DB for similar patterns
2. Code Age Analysis: Focus on recent changes
3. Code Path Uniqueness: Identify unusual code paths
4. Architecture Specificity: Look for arch-specific bugs
5. Compiler Artifacts: Find optimizer-introduced bugs
6. Custom Logic: Target non-standard implementations
7. Verification: Confirm no public disclosure exists

---

Quick Reference: Novel Overflow Patterns

Pattern	Novelty Indicator	Detection Method
Sign Extension	Modern code with int/uint mix	Look for type conversions
Custom Allocator	Performance-critical code	Search for custom allocators
Bounds Check Bypass	Complex validation logic	Trace comparison types
Compiler-Induced	Optimized builds	Compare O0 vs O2 assembly
Structure Padding	Packed structures	Analyze struct layout
SIMD Overflow	Vector/SIMD code	Look for __m256i, SSE ops
JIT Buffer	Languages with JIT	Analyze JIT compilation
VLA Overflow	C99 code with VLAs	Search for VLA syntax
Template Bug	C++ templates	Analyze template instantiations
GC Overflow	Languages with GC	Analyze GC algorithms
LTO Bugs	Link-time optimization	Check cross-file optimization
PGO Bugs	Profile-guided optimization	Analyze branch prediction

---

0day Verification Checklist

Before claiming 0day, systematically verify:

Novelty Verification

• Checked CVE database (last 10 years)
• Checked Exploit-DB for similar patterns
• Checked GitHub security advisories
• Checked vendor security bulletins
• Searched academic literature
• Checked bug bounty disclosures
• Verified code age (recent changes = higher novelty)

Pattern Analysis

• Confirmed pattern is NOT well-known
• Confirmed pattern is NOT in common vulnerability databases
• Confirmed exploit technique is novel
• Confirmed target code has no public patches

Testing

• Verified exploit works on current version
• Verified exploit reliability (> 50% success rate)
• Verified exploit works across configurations
• Tested mitigations and confirmed bypass

Documentation

• Documented root cause with code
• Documented exploitation path
• Created working PoC
• Calculated CVSS score
• Identified affected versions

---

Notes

• This skill focuses on finding new vulnerabilities, not reproducing known ones
• Exploit development in C ensures maximum control and reliability
• Always verify novelty before claiming 0day discovery
• Exploitation should only be demonstrated in authorized contexts
• Modern mitigations require advanced bypass techniques
• Memory corruption vulnerabilities remain common in C/C++ codebases
• Recent code changes and complex parsers are high-value targets
• Next-generation overflow patterns: Modern compiler/allocator/architecture bugs
• Verification is critical: Always confirm novelty before claiming 0day
• Weaponized exploits: Generate working, reliable PoCs
• Responsible disclosure: Mandatory for all findings