How Exploitarium Verifies the Accuracy of Consolidated Repositories: Git Tree Verification Explained

Exploitarium uses automated Git-tree verification to ensure every file in its consolidated repository matches the original standalone repositories byte-for-byte, checking paths, modes, types, and blob IDs with zero tolerance for divergence.

Exploitarium is a curated collection of proof-of-concept (PoC) projects that merges previously standalone security repositories into a single "consolidated" repository. Preserving the exact integrity of these original files is critical for researchers who depend on reproducible exploits. The project achieves this through a rigorous verification process that compares raw Git tree objects rather than relying on superficial filesystem comparisons.

The Git-Tree Verification Methodology

Exploitarium's verification system operates on the fundamental principle that Git's internal object model provides cryptographic guarantees of content identity. Instead of comparing file contents directly, the process leverages Git's native tree and blob abstractions.

Core Verification Steps

The four-step verification pipeline documented in README.md (lines 71-82) executes as follows:

• Fresh clone: Each original standalone repository is cloned anew before any comparison occurs, eliminating any possibility of local corruption or modification.
• HEAD-tree extraction: The complete tree object from HEAD of the cloned repository is serialized using git ls-tree -r HEAD.
• Cross-repository comparison: The same extraction is performed on the corresponding folder in the consolidated repository using git ls-tree -r main:<folder-path>.
• Strict matching criteria: Every tracked entry must match across four dimensions:
  • Same relative path within the repository structure
  • Same Git object type (blob, tree, submodule, etc.)
  • Same tree mode preserving executable bits and file permissions
  • Same blob ID (SHA-1 hash of file contents)

This approach guarantees that even a single flipped bit in any file would produce a different blob ID and trigger a verification failure.

Verification Scale and Results

According to the source documentation, the consolidation process has been validated across 12 source repositories containing 96 tracked entries. All comparisons completed with zero mismatches, confirming that the consolidated repository faithfully preserves every byte of the original PoC projects.

Reproducing the Verification Locally

Researchers and security practitioners can replicate Exploitarium's verification methodology using the following approaches. Both methods implement the identical checks specified in the original repository.

Bash Script for Single-Folder Verification

This script performs a direct comparison of Git tree objects between an original repository and its consolidated counterpart:

#!/usr/bin/env bash

# Usage: ./verify.sh <original-repo-url> <folder-in-consolidated>

# Example: ./verify.sh https://github.com/4D4J/objdump-Out-Of-Bounds-write objdump-dlx-calc-poc

ORIG_REPO=$1
CONS_FOLDER=$2
TMPDIR=$(mktemp -d)

# Clone the original repo (shallow clone for speed)

git clone --depth 1 "$ORIG_REPO" "$TMPDIR/orig"

# Get the tree objects for both repositories

git -C "$TMPDIR/orig" ls-tree -r HEAD > "$TMPDIR/orig.tree"
git ls-tree -r "main:$CONS_FOLDER" > "$TMPDIR/cons.tree"

# Compare paths, modes, types and blob IDs

diff -u "$TMPDIR/orig.tree" "$TMPDIR/cons.tree" || {
    echo "❌ Mismatch found in $CONS_FOLDER"
    exit 1
}
echo "✅ $CONS_FOLDER matches the original repository"
rm -rf "$TMPDIR"

The script relies on git ls-tree -r to recursively list all entries with their modes, types, and object hashes, then uses diff -u to surface any discrepancies.

Python Implementation with GitPython

For programmatic verification workflows, this Python script provides equivalent functionality using the GitPython library:

from git import Repo
import sys
import pathlib

def load_tree(repo_path, ref='HEAD'):
    repo = Repo(repo_path)
    tree = repo.tree(ref)
    entries = {}
    for blob in tree.traverse():
        entries[blob.path] = (blob.mode, blob.type, blob.hexsha)
    return entries

def verify(original_url: str, consolidated_path: str):
    import tempfile, shutil, subprocess
    tmp = tempfile.mkdtemp()
    # Clone original repo shallow

    subprocess.check_call(['git', 'clone', '--depth', '1', original_url,
                           pathlib.Path(tmp) / 'orig'])
    orig_entries = load_tree(pathlib.Path(tmp) / 'orig')
    cons_repo = Repo('.')
    cons_entries = {}
    for blob in cons_repo.tree('main:' + consolidated_path).traverse():
        cons_entries[blob.path] = (blob.mode, blob.type, blob.hexsha)

    mismatches = [p for p in orig_entries if orig_entries[p] != cons_entries.get(p)]
    if mismatches:
        print(f'❌ Mismatches: {mismatches}')
        sys.exit(1)
    print('✅ All entries match')
    shutil.rmtree(tmp)

if __name__ == '__main__':
    verify(sys.argv[1], sys.argv[2])

Both implementations enforce the same four-dimensional matching (path, mode, type, blob ID) that Exploitarium's own verification process requires.

What Verification Preserves and What It Cannot

Understanding the boundaries of Exploitarium's verification is essential for researchers working with the consolidated repository.

Guaranteed Preservation

• Exact file contents via blob ID matching
• Directory structure via relative path matching
• File permissions via tree mode matching
• Object types ensuring directories remain directories and symlinks are preserved as symlinks

Intentionally Excluded Metadata

The verification process explicitly does not preserve Git-level metadata that exists outside of tree objects:

• Commit history and chronological development narrative
• Issue trackers and discussion threads
• Star counts and social metrics
• Separate branch structures from original repositories

These elements remain accessible only by visiting the original standalone repositories before their potential removal.

Source Reference Files

File	Purpose	Location
README.md (lines 71-82)	Official documentation of consolidation verification methodology	bikini/exploitarium root
objdump-dlx-calc-poc/README.md	Example verified PoC folder demonstrating retained structure	objdump-dlx-calc-poc/
7zip-rar5-motw-chain-poc/README.md	Second verified example for cross-reference validation	7zip-rar5-motw-chain-poc/

Summary

• Exploitarium's Git-tree verification compares raw tree objects rather than file contents, leveraging Git's cryptographic integrity guarantees.
• The four matching criteria (path, mode, type, blob ID) ensure byte-for-byte equivalence between original and consolidated repositories.
• 12 source repositories with 96 tracked entries have been verified with zero mismatches as documented in README.md.
• The blob ID comparison makes the verification immutable to timestamp changes, permission modifications outside Git's tracked modes, or superficial metadata differences.
• Both Bash and Python tools are available to reproduce the exact verification process locally for any entry in the consolidated repository.

Frequently Asked Questions

Why does Exploitarium use Git tree objects instead of simple file comparison?

Git tree objects provide cryptographically verifiable identities for file contents through blob IDs (SHA-1 hashes). This approach is immune to filesystem-level variations like timestamps, compression artifacts, or encoding differences. According to the bikini/exploitarium source, tree comparison also preserves executable bits and exact directory structure in ways that diff -r cannot guarantee across platforms.

Can I verify that a specific PoC in Exploitarium matches its original repository?

Yes. Use either the provided Bash script or Python helper with the original repository URL and the folder name within Exploitarium. Both tools perform the identical checks: they clone the original, extract tree objects from HEAD, and compare path, mode, type, and blob ID against the consolidated folder at main:<folder-path>.

What happens if a verification check fails?

The documented verification process has never encountered a mismatch across 12 repositories and 96 entries. If a failure occurred, the diff output would identify the specific path, mode, type, or blob ID discrepancy. The consolidated repository would require manual reconciliation to ensure byte-for-byte accuracy before accepting the entry.

Does consolidation preserve the Git commit history of the original repositories?

No. Exploitarium's verification intentionally preserves only tree state (file contents and structure), not commit history. The README.md explicitly notes that metadata including stars, issues, and separate Git history remain only in the original repositories. Researchers requiring full provenance must consult the standalone sources before their removal.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}