# How Exploitarium Uses Git Operations to Ensure Bit-for-Bit Accuracy During Consolidation

> Learn how Exploitarium ensures bit-for-bit accuracy during consolidation by comparing Git tree data, blob SHA-1 hashes, and more, avoiding filesystem diffs for robust integrity.

- Repository: [bikini/exploitarium](https://github.com/bikini/exploitarium)
- Tags: internals
- Published: 2026-09-06

---

**Exploitarium verifies bit-for-bit integrity by comparing Git tree data between original repositories and consolidated folders, checking relative paths, object types, tree modes, and blob SHA-1 hashes rather than relying on filesystem diffs.**

The `bikini/exploitarium` repository consolidates standalone proof-of-concept repositories while guaranteeing that every imported file remains **identical byte-by-byte** to its original source. According to the source code documentation in [`README.md`](https://github.com/bikini/exploitarium/blob/main/README.md) (lines 73-82), this is achieved through **git-level verification** that operates on Git's internal object model rather than surface-level file comparisons.

## Git Tree Comparison: The Core Verification Method

The consolidation verification relies on Git's immutable object database. Each tracked file is identified by its **blob SHA-1 hash**—a cryptographically strong content identifier that changes if even a single bit differs. By comparing these hashes across repositories, Exploitarium achieves mathematically provable accuracy.

The verification validates four properties for every tracked entry:

- **Relative path**: The file's location within the repository tree structure
- **Git object type**: Whether the entry is a blob, tree, or other Git object type
- **Tree mode**: File permissions including executable bits
- **Git blob SHA-1**: The content hash guaranteeing identical bytes

As documented in the source: "The check compared each former standalone repo's `HEAD` tree against the matching folder here **using Git tree data rather than a loose filesystem diff**."

## The Five Git Operations Used for Verification

### 1. Fresh Repository Cloning

The process begins with a pristine clone to eliminate any local modifications:

```bash
git clone <original-repo-url> /tmp/old-repo

```

This guarantees the verification starts from a clean, authoritative state.

### 2. Original Tree Extraction

Inside the cloned repository, the full tree structure is extracted:

```bash
git ls-tree -r HEAD

```

This command outputs a four-column format: `mode type sha1 path` for every tracked object. The `-r` flag recursively traverses subtrees.

### 3. Consolidated Tree Extraction

The same command runs against the corresponding subfolder within Exploitarium:

```bash
git ls-tree -r HEAD

```

Executed from within the consolidated subfolder (e.g., `./ffmpeg-rasc-dlta-calc-poc`), this produces a comparable listing.

### 4. Cross-Repository Comparison

The two tree listings are compared using standard diff:

```bash
diff <(git -C /tmp/old-repo ls-tree -r HEAD) <(git -C <exploitarium-subdir> ls-tree -r HEAD)

```

Any output indicates a mismatch in path, mode, type, or blob ID.

### 5. Blob Content Inspection (Optional)

If discrepancies appear, raw content can be examined:

```bash
git cat-file -p <blob-sha>

```

This decodes and displays the actual file bytes associated with a specific hash.

## Complete Verification Example

The following script demonstrates the full workflow for verifying a consolidated PoC folder:

```bash
#!/bin/bash

# Verify bit-for-bit accuracy for ffmpeg-rasc-dlta-calc-poc consolidation

ORIG_REPO="https://github.com/ffmpeg/ffmpeg.git"
TMP_DIR=$(mktemp -d)
trap "rm -rf $TMP_DIR" EXIT

# Step 1: Clone original repository

git clone --depth 1 "$ORIG_REPO" "$TMP_DIR/ffmpeg"

# Step 2: Extract tree listings

git -C "$TMP_DIR/ffmpeg" ls-tree -r HEAD > /tmp/orig-tree.txt
git -C "./ffmpeg-rasc-dlta-calc-poc" ls-tree -r HEAD > /tmp/cons-tree.txt

# Step 3: Compare and report

if diff -u /tmp/orig-tree.txt /tmp/cons-tree.txt > /tmp/diff.txt 2>&1; then
    echo "✅ Bit-for-bit match – consolidation is exact."
    echo "Verified $(wc -l < /tmp/orig-tree.txt) tracked objects."
else
    echo "❌ Mismatch detected:"
    cat /tmp/diff.txt
    exit 1
fi

```

## Verification Results from the Source Code

According to [`README.md`](https://github.com/bikini/exploitarium/blob/main/README.md) lines 75-82, this procedure validated **96 tracked entries across 12 repositories** with **zero mismatches**. The complete verification table in the source documents each consolidated PoC and its original source location.

## Why Git Tree Data Beats Filesystem Comparison

| Approach | Limitations | Git Tree Method Advantages |
|----------|-------------|---------------------------|
| `diff -r` (recursive filesystem) | Sensitive to timestamps, line-ending conversions, permission changes | Ignores metadata noise; tests content identity only |
| `sha256sum` rolling hashes | Requires explicit file enumeration; misses empty directories | Handles entire tree structure atomically |
| File size comparison | Collision-prone; misses content alterations | Cryptographically strong SHA-1 guarantees |

The Git tree approach eliminates risks of **silent file corruption**, **line-ending conversion** (CRLF/LF), and **permission changes** that could compromise reproducibility.

## Summary

- **Git operations enable bit-for-bit verification** by comparing object hashes rather than file surfaces
- **`git ls-tree -r HEAD`** extracts complete tree metadata including mode, type, and blob SHA-1 for every tracked object
- **Four properties are validated**: relative path, object type, tree mode, and blob hash
- **Fresh clones ensure clean state** before any comparison begins
- **Zero mismatches across 96 entries** in the verified consolidation validates the methodology

## Frequently Asked Questions

### What makes Git tree comparison more reliable than standard diff?

Git tree comparison operates on **content-addressed storage**—every file's SHA-1 hash acts as a cryptographic fingerprint. Standard `diff` compares file bytes directly and can be fooled by identical content with different timestamps, while Git tree comparison ignores timestamps entirely and detects any content alteration, however minor. The method also captures **tree structure** and **executable permissions** that byte-level diffs might miss.

### Does this verification method require keeping full Git history?

No. The [`README.md`](https://github.com/bikini/exploitarium/blob/main/README.md) documentation shows that **`--depth 1` shallow clones** suffice for verification. Only the `HEAD` tree is compared, so historical commits are irrelevant. This keeps temporary storage minimal while maintaining verification integrity—the blob hashes for current files remain valid regardless of repository depth.

### Can this approach detect corruption in Git's own storage?

The method assumes Git's object database is internally consistent, which is enforced by hash chaining. If a blob were corrupted, its SHA-1 would change and fail verification. However, **the comparison does cross-validate between two independent repositories** (original clone vs. consolidated folder), so storage corruption in one would surface as a mismatch against the other.

### What happens if a verification check fails?

The `diff` output pinpoints the exact nature of any mismatch: path changes appear as line additions/deletions, mode changes as altered leading octal numbers, and content changes as differing SHA-1 hashes. The optional **`git cat-file -p`** command can then retrieve the actual bytes for manual inspection. According to the source documentation, the consolidation process was repeated until all 96 entries achieved perfect alignment.