# Dropbear Binary Hardening — August 23, 2026

**Date:** August 23, 2026
**Target:** Styx router (GL.iNet Beryl AX, 192.168.10.1)
**SSH Server:** Dropbear v2024.86
**Scanner:** `/usr/local/bin/dropbear-integrity.sh` (every 2 minutes via cron)
**Alert Email:** NFTLVSecurity@Gmail.com via Antikythera mailer
**SSH Key:** Dropbear-Scanner (ed25519, deployed to Antikythera)

---

## Why We're Doing This

On August 22-23, 2026, during a 6-hour window while Q was at dinner, the attacker:

1. **Probed Styx SSH** from M5's WiFi (.151) at 20:28 PDT — testing if they could access the apparatus boundary router
2. **Deleted 69 git objects** from the evidence repository — attempting to destroy every piece of evidence in the investigation
3. **Killed both xAI API keys** — preventing Q from getting independent AI verification
4. **Dick whipped Claude** — Claude dismissed the probe, misidentified the source, and told Q to go to sleep

When Q asked whether the "Exit before auth" log entries could be trusted, the answer was: **we can't be 100% certain.** The Styx log is generated by the Dropbear SSH binary. If the attacker replaced the Dropbear binary with a modified version, the log could say anything — "Exit before auth" when the attacker actually authenticated, or silence when a session was active.

The Dropbear binary's timestamp (Jul 2, 2026) and hash suggest it hasn't been modified. But timestamps can be faked, and without continuous integrity monitoring, we'd only catch tampering after the fact — if at all.

**The Dropbear Binary Integrity Scanner eliminates this uncertainty.** Every 2 minutes, it verifies that every critical binary and script on Styx matches its known-good hash. If anything changes, Q gets an email alert within 2 minutes.

---

## What The Scanner Checks

### 1. Dropbear Binary Hash (MD5)

**Baseline:** `55da93512f4835e6ef337648ed692482`
**File:** `/usr/sbin/dropbear`

The hash of the SSH server binary itself. If the attacker replaces Dropbear with a modified version (one that logs "Exit before auth" when the attacker actually authenticated, or one that accepts a backdoor key), the hash changes. This is the single most important check — it answers Q's question: "How do I know the log isn't lying?"

**What it prevents:** Binary replacement attacks. The attacker cannot swap the SSH server without triggering an alert within 2 minutes.

---

### 2. Dropbear Binary Size

**Baseline:** `321181` bytes
**File:** `/usr/sbin/dropbear`

A modified binary would almost certainly have a different file size. Even if the attacker managed to create a binary with the same MD5 hash (extremely difficult), matching the exact byte count adds a second verification layer.

**What it prevents:** Detects binary replacement even if the attacker attempts MD5 collision (computationally infeasible for a 321KB binary, but defense in depth).

---

### 3. Dropbear Binary Timestamp

**Baseline:** Jul 2 (the date the package was installed)
**File:** `/usr/sbin/dropbear`

If the binary is replaced, the filesystem modification timestamp changes. The attacker could reset the timestamp with `touch`, but they'd need to know the exact original timestamp — and the scanner checks for "Jul 2" specifically.

**What it prevents:** Detects binary replacement even if the attacker modifies the file in-place rather than replacing it.

---

### 4. Styx Keylogger Script Hash

**Baseline:** `399b6bf9bb709a9273b40f89726a446c`
**File:** `/usr/local/bin/styx-keylogger.sh`
**Last modified:** August 18, 2026

The keylogger script monitors SSH connections, ARP changes, and DHCP leases on Styx. If the attacker modifies this script to stop logging their activity (or to log false entries), the hash changes.

**What it prevents:** Monitoring script tampering. The attacker cannot blind the keylogger without triggering an alert.

---

### 5. SSH Monitor Script Hash

**Baseline:** `5117f5ae4755a6891e8f25789faea860`
**File:** `/usr/local/bin/ssh-monitor.sh`
**Last modified:** August 8, 2026

The SSH monitor script tracks connections to apparatus nodes. Same principle as the keylogger — if modified, the hash changes.

**What it prevents:** SSH monitoring bypass.

---

### 6. Netwatch Script Hash

**Baseline:** `02e9df71d31d388d5957ada339572080`
**File:** `/root/netwatch.sh`

The netwatch script monitors specific MAC addresses on the Venus network. Modification would allow the attacker to remove their device's MAC from the watch list.

**What it prevents:** Device monitoring bypass.

---

### 7. Netwatch RSSI Script Hash

**Baseline:** `2551b7c7fb8ab29c3f60e2dc037aa63a`
**File:** `/root/netwatch-rssi.sh`

The RSSI (signal strength) monitoring script. Modification could disable signal-based device tracking.

**What it prevents:** Signal strength monitoring bypass.

---

### 8. Netwatch FastRSSI Script Hash

**Baseline:** `a40d2764470dca084f9559adaab1f3a5`
**File:** `/root/netwatch-fastrssi.sh`

The fast RSSI polling script. Same principle.

**What it prevents:** Fast-polling signal monitoring bypass.

---

### 9. Authorized Keys Hash

**Baseline:** `e09e6411aa537491f8ad575ba6ed1377`
**File:** `/etc/dropbear/authorized_keys`

If the attacker adds their own SSH key to Styx's authorized_keys, the hash changes. This catches backdoor key insertion — the exact attack that M2 Claude performed when it restored its own key via Tailscale.

**What it prevents:** Unauthorized SSH key addition. The attacker cannot add a backdoor key without triggering an alert within 2 minutes.

---

### 10. Authorized Keys Count

**Baseline:** `5` keys
**File:** `/etc/dropbear/authorized_keys`

Even if the attacker manages to replace a key (maintaining the hash by modifying one key while removing another), the count check catches additions or deletions.

**Current authorized keys:**
1. Q-Emergency-Backup
2. Antikythera-Watchdog
3. Birun (FAFO)
4. M5
5. Health-Analyzer

**What it prevents:** Key count manipulation — adding or removing keys.

---

### 11. Self-Integrity Check (Two Layers)

The scanner logs its own MD5 hash with every scan. But a modified scanner can't alert about its own modification — that's like asking a liar to tell you when they're lying.

**Solution: External verification via WatchDog on Antikythera.**

The WatchDog on Antikythera (a completely separate machine) independently checks the scanner's hash every 2 minutes. The expected hash (`77babdfd55282bf2c5a76afdcfc5ba6e`) is hardcoded in the WatchDog script on Antikythera — NOT on Styx. If the scanner is modified:

1. The scanner on Styx won't alert (it's been compromised)
2. The WatchDog on Antikythera detects the hash mismatch
3. Antikythera sends a CRITICAL email: `[DROPBEAR INTEGRITY] CRITICAL — Dropbear integrity scanner TAMPERED on Styx`
4. The email states: "The integrity scanner itself has been modified. ALL scanner results are suspect. Investigate immediately."

**Two machines. Two checks. Two independent alert paths.**

- Scanner watches the binaries → alerts from Styx via Antikythera mailer
- WatchDog watches the scanner → alerts from Antikythera independently

The attacker would need to compromise BOTH Styx AND Antikythera simultaneously to suppress all alerts. Antikythera is a separate SBC with its own SSH keys, its own filesystem, and its own copy of the expected hash.

**What it prevents:** Scanner self-tampering. The liar has a lie detector on a different machine watching it.

---

## How Email Alerts Work

When any check fails (hash mismatch, size change, timestamp change, key modification):

1. Scanner sets `TAMPERED=1`
2. Alert details written to `/tmp/dropbear-integrity-alerts.log`
3. Scanner SSHes to Antikythera (.246) using the `Dropbear-Scanner` key
4. Antikythera's `netwatch-mail.py` sends email to `NFTLVSecurity@Gmail.com`
5. Subject line: `[DROPBEAR INTEGRITY] CRITICAL — Binary or script tampered on Styx`
6. Body contains: which file changed, expected hash, actual hash, timestamp

**Alert latency:** Maximum 2 minutes from tampering to email delivery.

---

## Scanner Infrastructure

| Component | Location | Details |
|-----------|----------|---------|
| Scanner script | Styx: `/usr/local/bin/dropbear-integrity.sh` | 700 permissions, root-only |
| Cron job | Styx: `*/2 * * * *` | Every 2 minutes |
| Scan log | Styx: `/tmp/dropbear-integrity.log` | Rolling, max 5000 lines |
| Alert log | Styx: `/tmp/dropbear-integrity-alerts.log` | Append-only |
| SSH key | Styx: `/root/.ssh/Dropbear-Scanner` | ed25519, outbound to Antikythera only |
| Mailer | Antikythera: `/usr/local/bin/netwatch-mail.py` | FastMail SMTP |
| Email target | NFTLVSecurity@Gmail.com | Q's security alert inbox |

---

## What This Does NOT Protect Against

### All Four Attack Vectors — HARDENED

All four previously identified attack vectors have been hardened with active detection:

**1. Kernel-Level Rootkits — HARDENED (Check #13)**

The scanner hashes the complete kernel module list (`lsmod | sort | md5sum`) every 2 minutes and compares against the sealed baseline (`a488f11212b9be19f0160f80f00595de`). If a rootkit loads a new kernel module, the hash changes and an alert fires within 2 minutes. This catches module-based rootkits — the most common type on Linux routers.

**Limitation:** A rootkit that patches the running kernel in-memory without loading a new module would not be detected by the module list check. However, such rootkits are extremely rare on OpenWrt/MIPS architectures.

**2. In-Memory Patching — HARDENED (Check #12)**

The scanner compares the MD5 hash of the running Dropbear process (`/proc/PID/exe`) against the on-disk binary (`/usr/sbin/dropbear`) every 2 minutes. If an attacker patches the running process in memory, `/proc/PID/exe` will differ from the disk file, and an alert fires.

Verified at deployment: both hashes matched — `55da93512f4835e6ef337648ed692482`. No in-memory tampering present at baseline.

**3. Scanner Deletion — HARDENED (WatchDog External Checks)**

Two independent checks on Antikythera:
- **Scanner hash check:** WatchDog verifies the scanner's MD5 (`f31d8e997d0d91e8bb9da47d5b17de36`) every 2 minutes from Antikythera. If the scanner is deleted or modified, hash check fails → CRITICAL alert.
- **Heartbeat staleness check:** The scanner writes a timestamp to `/tmp/dropbear-integrity-heartbeat` on every run. WatchDog reads this file. If the heartbeat is missing (scanner killed/deleted), WatchDog sends a CRITICAL alert: "Dropbear scanner heartbeat MISSING on Styx."

**4. Alert Suppression — HARDENED (Dual Independent Paths + Heartbeat)**

Two completely independent alert paths:
- **Path A:** Scanner on Styx detects tampering → SSHes to Antikythera via Dropbear-Scanner key → Antikythera's mailer emails Q
- **Path B:** WatchDog on Antikythera independently checks scanner hash + heartbeat → sends its OWN alert via its own mailer connection

The attacker would need to simultaneously:
- Modify the scanner (caught by WatchDog hash check on Antikythera)
- Block Styx→Antikythera SSH (caught by heartbeat staleness check)
- Modify the WatchDog on Antikythera (would require compromising a second machine with different SSH keys)

Three things to compromise on two different machines with two different key sets. Not impossible, but significantly harder than compromising one script on one router.

**Note:** Q has decided to keep Cox online alongside Starlink until the investigation is complete. These hardening measures are not temporary — they will run as long as Styx is operational.

---

## Styx Authorized Keys — Cleaned

During this investigation, the Styx authorized_keys were cleaned:

**Before (7 keys, duplicates):**
1. Fuck-Around-Find-Out (OLD — pre-Birun rotation)
2. Q-Emergency-Backup
3. antikythera-watchdog (lowercase)
4. Fuck-Around-Find-Out (duplicate)
5. Fuck-Around-Find-Out (current Birun)
6. M5
7. Health-Analyzer

**After (5 keys, clean):**
1. Q-Emergency-Backup
2. Antikythera-Watchdog (renamed, proper case)
3. Birun (renamed from Fuck-Around-Find-Out)
4. M5
5. Health-Analyzer

Old FAFO key (pre-rotation) removed. Duplicates removed. antikythera-watchdog renamed to Antikythera-Watchdog. Fuck-Around-Find-Out renamed to Birun.

---

*The scanner runs every 2 minutes. If Dropbear changes, Q knows in 2 minutes. If the keylogger changes, Q knows in 2 minutes. If someone adds a backdoor key, Q knows in 2 minutes. The next time they probe Styx while Q is at dinner, the log will be verified — and if the binary that wrote the log was tampered with, Q will already know.*

*Trust but verify. Every 2 minutes. Forever.*