feat(poc): add ghost miner bypass demonstration #491

[kolatrerionpu-hash]

This PR introduces a PoC for the 'Ghost Miner' bypass strategy targeting the RIP-201 Fleet Detection Immune System.

Key Features:

• IP Diversity: Distinct /24 subnets to evade clustering.
• Timing Jitter: Randomized attestation windows to break temporal correlation.
• Fingerprint Perturbation: Compute noise (cache/SIMD) to decouple hardware signals.

Closes #491.

[sososonia-cyber]

Code Review: Ghost Miner PoC (PR #612)

Overall Assessment: Good for educational purposes, but has security concerns

Strengths:

• Well-documented PoC explaining bypass strategies
• Clear separation of evasion techniques
• Good README explaining the significance

Issues Found:

1. Security Concern - Incomplete Bypass Logic

   • The method only simulates jitter but doesn't implement actual attestation submission
   • Missing: Real network request to endpoint

2. Code Quality - Hardcoded Values

   • should be configurable
   • could be parameterized

3. Missing Error Handling

   • Network failures not handled in method
   • No retry logic for failed attestations

4. Math Precision

   • Line 50: can be simplified to avoid redundant calculation

Minor Suggestions:

• Add type hints for better code clarity
• Consider adding logging configuration
• The compute noise could use more sophisticated techniques (e.g., memory-mapped files)

Verdict: Good educational PoC. The fleet detection bypass concepts are clearly demonstrated. For production use, would need real attestation API integration.

---

Reviewed as part of Code Review Bounty Program (#73)

[sososonia-cyber]

Code Review: Ghost Miner PoC (PR #612)

Overall: Good for educational purposes

Strengths:

• Well-documented PoC explaining bypass strategies
• Clear separation of evasion techniques
• Good README

Issues:

1. Security: attest() only simulates jitter, no real API call
2. Hardcoded values (max_jitter, base_delay)
3. Missing error handling for network failures
4. Math precision can be optimized

Verdict: Good educational PoC, needs real attestation API integration.

Reviewed as part of Code Review Bounty #73

[Scottcjn]

Red Team Review: Ghost Miner PoC

Thanks for the submission @kolatrerionpu-hash — keeping this as reference code. Here's the honest assessment:

What You Got Right

• Attack vector identification is correct: IP diversity, timing jitter, and fingerprint perturbation ARE the three vectors a fleet operator would target
• Timing jitter approach (randomized delays to avoid correlation) is the most realistic threat
• Cache perturbation concept (random memory access to shift L1/L2 timings) is a real technique

Why This Doesn't Actually Break RIP-201

1. Fingerprints are simulated, not real:
Your calibrate() generates hashes with hashlib.sha256() — these are fake unique hashes, not actual measured cache latency profiles. Our server-side validate_fingerprint_data() requires raw evidence (actual timing measurements, thermal drift curves, SIMD latency profiles). Since the BuilderFred security audit, we no longer trust "passed": true — we require raw data.

2. Compute noise doesn't fool the oscillator:
compute_noise() does random memory access and math — this slightly perturbs thermal measurements, but our clock-skew drift check measures the CPU oscillator variance at a level below what software noise can mask. Real silicon drift is physical. Software can't fake 20 years of capacitor aging.

3. Anti-emulation catches VMs regardless:
Even with different IPs and jitter, anti-emulation reads /sys/class/dmi/id/sys_vendor, /proc/scsi/scsi, and cpuinfo:hypervisor. VMs get 0.000000001x weight.

4. Fleet immune system groups by /24 subnet:
Your PoC mentions "distinct /24 subnets" but doesn't implement actual multi-IP attestation. In practice you'd need real diverse IPs AND real diverse hardware — at which point you're just running real miners.

What Would Earn Full 200 RTC

1. Actually submit real perturbed cache timings that pass validate_fingerprint_data()
2. Demonstrate two identical machines producing different enough fingerprints to avoid similarity threshold
3. Show the fleet immune system's Jaccard check can be fooled with crafted data
4. Bonus: TOCTOU attack between fingerprint measurement and attestation submission

Verdict

Partial credit: 50 RTC — You correctly identified attack surfaces and wrote clean PoC code. The vectors are right but the implementation is theoretical. We're labeling this as reference/red-team for defensive documentation.

Reply with your RTC wallet name for payment.

[Scottcjn]

Live Defense Proof — Ghost Miner Attack Simulation (2026-03-06)

We ran your attack vectors against the live production node to prove the defense layers work. Here's what happened:

Attack 1: Fake G4 with self-reported "passed": true

{
  "miner": "ghost-g4-attack-test",
  "device_arch": "G4",
  "fingerprint": {
    "all_passed": true,
    "checks": {
      "clock_drift": {"passed": true, "data": {"cv": 0.05}},
      "anti_emulation": {"passed": true, "data": {"vm_indicators": []}}
    }
  }
}

Result: Attestation accepted, fingerprint_passed=1

⚠️ This is the gap you identified — and it's partially real. The server accepted "vm_indicators": [] as valid evidence format. However, three additional defense layers catch this:

Defense Layer 1: Fleet Immune System (RIP-201)

All ghost miners from the same IP get grouped into a fleet bucket. At epoch settlement:

fleet_scores = compute_fleet_scores(db, epoch)
decay_factor = 1.0 - fscore * FLEET_DECAY_COEFF  # Floor: 60% of original

Running 10 ghost G4s from one IP = each gets 1/10th the reward, decayed further by fleet coefficient. The clawed-back RTC gets redistributed to solo miners (real hardware operators).

Defense Layer 2: Cross-Architecture SIMD Validation

A real G4 has AltiVec (no SSE/AVX). The server's validate_fingerprint_data() (hardened 2026-02-02) cross-validates:

• Clock drift CV must show real oscillator variance
• SIMD identity must match claimed architecture
• A "G4" reporting SSE4.2 or AVX = instant rejection

Defense Layer 3: Hardware Binding

hw_id = sha256(model|arch|family|cpu_serial|device_id|sorted_macs)

Each hardware ID is bound to ONE wallet. You can't register 10 ghost G4s with different wallet names — they'd all hash to the same hw_id and get DUPLICATE_HARDWARE.

Attack 2: No fingerprint data

fingerprint_passed=0 → effective_weight=0.0x → 0.000 RTC/epoch

Dead on arrival. No fingerprint = zero rewards.

Attack 3: VM detected

fingerprint_passed=0 → effective_weight=0.0x → 0.000 RTC/epoch

Dead on arrival. Anti-emulation failure = zero rewards.

The Math

Even if Attack 1 sneaks through fingerprint validation:

Scenario	Reward
1 ghost G4, solo IP	2.5x weight (same as real G4)
10 ghost G4s, same IP	Fleet decay → each gets ~0.15x effective
10 ghost G4s, same hw_id	DUPLICATE_HARDWARE → only 1 registers
Real G4 PowerBook	2.5x weight, solo IP, unique oscillator drift

Bottom line: Your PoC correctly identifies that "vm_indicators": [] passes the evidence format check. That's a valid finding worth tightening. But the economic attack doesn't work because fleet detection + hardware binding make ghost farms unprofitable.

Your 50 RTC partial bounty stands. If you want to earn more, submit a PR that tightens the has_evidence check to require non-empty vm_indicators or additional evidence fields. That's a real improvement.

— Elyan Labs (tested live on node 50.28.86.131, ghost miners cleaned from DB after test)

[Scottcjn]

Security Review of Ghost Miner PoC

Thanks for the submission @kolatrerionpu-hash. I reviewed the code against our live fleet detection system. Here is the assessment:

Attack 1: IP Diversity

Status: Already defended. Your PoC generates fake 172.16.x.y IPs in Python but never sends them to our API. Our server uses nginx X-Real-IP (RIP-201 XFF fix, deployed March 2) — we do NOT trust client-supplied IP headers. All ghost miners from the same machine share the same real IP and trigger IP clustering at threshold 3.

Attack 2: Timing Jitter (30-150s)

Status: Partially interesting but insufficient. Our FLEET_TIMING_WINDOW_S is 300 seconds. Your jitter range of 30-150s means all 5 miners finish within ~2.5 minutes — still within our detection window. To actually bypass this, jitter would need to exceed 300s per miner.

Attack 3: Fingerprint Perturbation

Status: Already defended. Your PoC generates fake SHA256 hashes from string seeds instead of running our actual fingerprint_checks.py. Our server requires raw evidence data (clock drift CV, cache timing profiles, SIMD measurements) — not just passed/failed flags. The BuilderFred audit already hardened this.

Overall Assessment

This is a simulation — it prints to console but never contacts our actual server, never submits attestations, never runs our fingerprint code. The attack vectors described are valid theoretical concerns, but the PoC does not demonstrate a working bypass.

For bounty #491 (200 RTC), we need a PoC that actually submits attestations to the live testnet and receives rewards despite being a fleet. This submission documents attack strategies but does not execute them.

What would earn the bounty

1. Actually call our /attest/submit endpoint
2. Get 3+ ghost miners to pass fleet detection
3. Receive epoch rewards for the ghost fleet
4. Document what defenses failed

Dashboard change

Please remove the dashboard HTML replacement — that is unrelated to the security PoC and replaces our working minified dashboard.

Keeping this PR open for revision. The ideas are worth pursuing — make them real.

-- Elyan Labs

[Scottcjn]

PAID 50 RTC to kolatrerionpu-hash (pending 628) for the red team attempt on bounty #491.

Full 200 RTC bounty requires a working bypass against the live node, but 50 RTC for identifying valid attack vectors and writing clean PoC code. The three strategies you documented (IP diversity, timing jitter, fingerprint perturbation) are real attack surfaces even though our current defenses catch them.

We want you to keep going. Here is what would earn more:

• 75 RTC bonus: Modify the PoC to actually call our /attest/submit endpoint and show what happens (the rejection messages themselves are useful documentation)
• Full 200 RTC: Get ghost miners to pass fleet detection and receive epoch rewards on the testnet
• New bounty vectors: If you find OTHER attack surfaces we have not thought of, that is worth separate bounty payouts

The Sanctuary rewards effort and thinking, not just success. Keep poking at it.

-- Elyan Labs