Geometric Vulnerability Analysis Research

Geometric Vulnerability Analysis

A unified framework for understanding, discovering, and measuring software vulnerabilities — built from first principles.

Over the last eighteen months, I developed a formal system for vulnerability analysis that combines four frameworks into a single 5-dimensional description of every software exploit. This page is the hub for that research.


The Four Frameworks

VMF Engine — Geometric Code Scanning

Traditional scanners match patterns. VMF projects every finding through six geometric dimensions (AST, data flow, memory layout, error state, exploit chain, thermodynamic stability) and computes a curvature score κ that filters 97% of false positives automatically.

▶ Results: 728 Chrome files scanned in 2 seconds. 1,466 raw findings → 42 real after projection.

VMF reduced my triage burden from 1,466 findings to 42 real ones. That’s a 97% reduction with zero false negatives on verified vulnerabilities.

Read the full VMF Engine Introduction →

Error Principle — Information Debt Quantification

Every unhandled error in a security-critical path creates information debt — a measurable gap between intended and actual security behavior. Dₑ = 1 − Hₑ quantifies this across four factors: detection, handling, audit, and state preservation.

▶ Results: 53 information debt findings in Android AOSP system services. 22 with Dₑ > 0.8 (Maximum Debt).

If the error handling failure rate holds across the entire framework, the Android platform contains hundreds to thousands of similar information debt points.

Read: The Error Principle →
Read: Practical Guide to Measuring Error Debt →

Memory Layer — Exploit Geometry

Every exploit resolves to the same primitive: a controlled value at a memory location being interpreted as a type the system didn’t expect. An 8-factor vector (S, T, D, P, E, K, C, M) characterizes the full memory geometry of any exploit.

Core insight: There are no new bug classes. Only new paths for a controlled value to cross memory layers. Rowhammer, Spectre, and Heartbleed are all the same phenomenon seen through different geometric lenses.

All vulnerabilities reduce to: a controlled value V, at location L, interpreted as type T, when the system expected value V′ at location L′ of type T′.

AttackGraph — Exploit Chain Modeling

Vulnerability findings as directed graph edges connecting security states. Exploit chain discovery becomes a pathfinding problem: shortest path, fastest path, stealthiest path, or most reliable path through the attack surface.

▶ Results: 118 chains found in Chrome Mojo IPC. Bottleneck analysis identified the single finding appearing in 89% of all chains.

AttackGraph doesn’t just tell you where the bugs are. It tells you which bugs matter most to an attacker — the ones that appear in the most paths to system compromise.

Read: AttackGraph →


The Grand Unification

These four frameworks are not separate tools. They are projections of a single underlying object — the vulnerability manifold. Every vulnerability is a 5-tuple (P, L, D, G, κ):

  • P (Pattern) — Which error handling anti-pattern the bug expresses
  • L (Layer) — Eight-factor vector of the memory geometry of the attack
  • D (Debt) — Information debt score Dₑ ∈ [0, 1] quantifying handling failure
  • G (Graph) — Position in the exploit chain lattice (node, edge, pre/post conditions)
  • κ (Curvature) — Geometric curvature Π(κᵉ) from 6 projection dimensions

Two findings with the same (P, L, D, G, κ) tuple are the same vulnerability, regardless of codebase, language, or architecture. A Rust unwrap() and a Java catch(Exception e) can occupy the same point in this space.

Read: The Grand Unification →


Case Study

Android AOSP System Services

Three core files (36,003 lines), 53 findings, 22 with Maximum Debt. Validates the methodology against real production code shipping on 3 billion devices. The most critical finding (Dₑ = 0.95) allows an unprivileged attacker to bypass URI permission enforcement entirely by triggering a BadParcelableException.

If the error handling failure rate observed in this study (~1.5 instances per 1,000 lines) holds across the entire Android framework, the platform contains hundreds to thousands of similar information debt points.

Read: Android Case Study →

What SAST Tools Miss

Automated scanners operate syntactically — they match patterns. The most dangerous bugs are geometric: chains, TOCTOU windows, information debt, cross-boundary state confusion. A scanner that checks syntax but not adversarial context will produce clean reports on vulnerable code.

Read: What SAST Tools Miss →


Practical Application

You don’t need a custom scanner to apply this methodology. A pen, a printout, and 30 minutes per file is enough to measure information debt in any codebase. The methodology uses five patterns (A-E), four scoring factors (α, β, γ, δ), and one unified score (Dₑ).

Read: How to Measure Error Debt in Your Codebase →


About the Author

Independent security researcher focused on first-principles vulnerability analysis. Past work includes Chrome Mojo IPC (728 files, 118 exploit chains), Android AOSP Binder (53 information debt findings), and audits of major consumer Android applications including Instagram, Facebook, WhatsApp, and Amazon Shopping. Findings submitted through Chrome VRP, Android AOSP VRP, Meta VRP, Google Mobile VRP, and Bugcrowd.

Services: Source code security audit, error debt analysis, architecture review for Indian enterprise vendors (network device configs, Android applications, web infrastructure).