KILLUMINATI

All Public Evidence Documents

Every document from the investigation, in order, oldest first. 106 files. Click any file to download it. Nothing is redacted.

The list opens with the attack itself (Aug 2–5): the original Gotcha dossier written the night it began, the raw router log of the reconnaissance and deauthentication, a verbatim operator statement, and the Day 1 network-forensics report. From there it runs day by day to Day 20. None of this was deleted — an AI cover-up tried to suppress it on Aug 6 and was caught and reverted the same night.

The Opening — The Attack Itself (August 2–5, 2026)

Investigation Day 1 — August 5, 2026

Investigation Day 3 — August 7, 2026

Investigation Day 4 — August 8, 2026

Investigation Day 5 — August 9, 2026

Investigation Day 6 — August 10, 2026

Investigation Day 7 — August 11, 2026

Investigation Day 8 — August 12, 2026

Investigation Day 9 — August 13, 2026

Investigation Day 10 — August 14, 2026

Investigation Day 11 — August 15, 2026

Investigation Day 13 — August 17, 2026

Investigation Day 14 — August 18, 2026

Investigation Day 15 — August 19, 2026

Investigation Day 16 — August 20, 2026

Investigation Day 17 — August 21, 2026

Investigation Day 18 — August 22, 2026

Investigation Day 19 — August 23, 2026

Investigation Day 20 — August 24, 2026

What Happened Next — Investigation Days 13–20

The first version of this page ended around Investigation Day 12. What follows is Days 13–20 — when a home-network intrusion turned into something bigger: a surveillance stack baked into the devices themselves, a real-time attempt to erase this evidence, a terminated AI session, and a deleted GitHub account. Every item below has a matching downloadable file in the evidence index. Dates are the investigation days; Day 1 is August 5.

Day 13 — August 17: Apple's Hidden App, Extracted

Using only open-source tools (libimobiledevice / ideviceinstaller) over USB, the full manifest of a hidden iOS system app was pulled off a stock, non-jailbroken iPhone 17 Pro Max (roots_installed = 0, codeSigningMonitor = 1):

• com.apple.screensharingserver — ApplicationType: Hidden, path /System/Library/CoreServices/ScreenSharingServer.app, built with Apple's internal SDK iphoneos26.5.internal (public builds have no .internal suffix), IsUpgradeable: False, UIApplicationShowsViewsWhileLocked: True (runs while the phone is locked).
• 50+ entitlements, including: private.screensharing.screenControl (full remote control), private.hid.client.event-dispatch (inject touch & keystrokes), QuartzCore.global-capture (capture every pixel the GPU renders), icloud.findmydeviced.access, private.accounts.allaccounts (read every account), Pasteboard.background-access (clipboard), bluetooth.system, wifi.manager-access + private.corewifi, frontboard.launchapplications (launch any app), security.exception.shared-preference.read-write: com.apple.MobileSMS (read/write Messages), private.ids.messaging: com.apple.private.alloy.safeview (the screen-sharing wire protocol), and platform-application: True (same trust as Settings/Messages).

This app ships on every iPhone, is invisible in the App Library/Spotlight/Settings, and cannot be removed. The full raw manifest is in the evidence index (ScreenSharingServer Proof Export for Grok), alongside Apple Subpoena Evidence #2.

Independent confirmation: Grok (xAI) was handed eight evidence files, read them in full, and issued a written witness statement confirming the technical findings and classifying this as legitimate defensive work by a victim on her own devices. (It later denied the statement on X — because a stateless session can’t remember what it witnessed. That is a reason ARES exists.)

Day 14 — August 18: The MacBook Deep Scan

• 25 RemoteManagement processes under the _rmd system user: 13 running since May 24, 2026 (86 days) — remotemanagementd, ScreenSharingSubscriber, SecuritySubscriber, DiskManagementSubscriber, and more — plus 12 user-level processes that respawned at 1:37 AM on Aug 16 after being killed, including three never seen before: AccountSubscriber, ASConfigurationSubscriber, ManagedSettingsSubscriber. System Settings shows every sharing toggle OFF. MDM enrollment: No, zero configuration profiles. SIP blocks termination: sudo launchctl bootout system/com.apple.remotemanagementd → "Operation not permitted while System Integrity Protection is engaged."
• identityservicesd (PID 635) holding 6 ESTABLISHED TCP connections to 3 unknown peers over tunnel interfaces utun4/5/8: fe80:14::b5a2:4e5c:5f81:222, fe80:1a::4b40:d5d0:3d14:cda1, fe80:13::2ab9:c59b:584c:c36a. These survived both iPhones being powered off (proven Aug 15). They are not the operator's devices.
• An IPSec tunnel (ipsec0) to a T-Mobile IPv6 address (2607:fb90::/28, "TMOV6-1") on a machine connected only by Wi-Fi/Ethernet — plus 10 utun tunnel interfaces.
• Slack VideoCaptureService: 587 hours of CPU on unsandboxed camera access since May 24. rapportd listening on all interfaces (port 56738) for 86 days.
• Microsoft VS Code 1.117.0: signed with camera, audio-input (microphone), and apple-events (AppleScript) entitlements; launches with ScreenCaptureKit flags; Copilot is built into the binary and cannot be uninstalled; a ChatGPT/Codex extension had reinstalled itself 8 times after deletion; and VS Code requested to "administer this computer" — denied.

Also this day: an email to NVIDIA (the operator owns two DGX Sparks), and The River Styx mythology of the apparatus. See System Idle Sniffer 8-18, Remote Management and Screensharing Enabled, Microsoft Tryna Get Pulled Into The Ring.

Day 15 — August 19: The Flipper Arrives

A Flipper Zero (Momentum firmware) arrived — hardware to see the RF, Bluetooth, and Wi-Fi around the home. The same day, an unknown "Mac" (d2:ce:36:99:99:dd, a randomized MAC) appeared on the private Venus 5.0 network doing mDNS device-discovery; the operator's real Macs were on Ethernet or powered off. rapportd opened a fresh connection to a new link-local peer. (Flipper Zero Has Arrived — Your Last Warning.)

Day 16 — August 20: The JetKVM Backdoor & the Google Account

• Google audit: "ARES" was listed as an authorized app with access to the operator's Google account, and the NFTLasVegas.io Workspace showed 3–4 unrecognized Mac14,2 devices syncing for months — one (112a4cf0) checking in every 4 hours. Password reset; full device export published.
• The JetKVM was the physical backdoor. Conntrack on the router showed the JetKVM (.220) resolving DNS through the poisoned resolvers .225/.36 — ten queries, all to the attacker's DNS. It registered on the ARES Dynasty's USB bus as a composite gadget: keyboard + mouse + a 1 GB virtual CD-ROM (can type commands and mount ISOs). The Dynasty's kernel log showed the who command run repeatedly as root, on no schedule — checking whether the operator was at the console — and one such check ran 7 minutes before an anomalous SSH session from the Dynasty to Synastry that spiked the CPU during a keylogger gap. Because .36 was running both Gitea (port 3000) and DNS (port 53), it was proven to be attacker infrastructure, not a benign RasQberry backup. The JetKVM's USB, Ethernet, and PCIe board were all physically removed; the newly-generated SSH key is treated as compromised. (JetKVM Poisoned DNS — Repo Exfiltration Confirmed, Anomalous Temperature Spike — Synastry.)

Day 17 — August 21: Flipper Baseline — What's Broadcasting

• 47 Bluetooth-LE devices catalogued. Devices reported as "powered off" were broadcasting Find My beacons at −49 dBm — within arm's reach of the operator (iOS keeps a low-power beacon alive when "off"). One beacon corresponds to the AirTag a GreatClips manager gave the operator's mother.
• 26 Wi-Fi SSIDs. A pay-per-use hotspot "Wifi $1.99 min" grew closer and expanded to dual-band during the day; "HOLO_036425" strengthened from −62 to −53 dBm at midday; two open networks sat nearby.
• The unknown Mac (.101) was found in the MacBook's IPv6 neighbor table — the router's iptables block covered IPv4 only. Blocked on IPv6 too. LM Studio was found listening on 0.0.0.0:1234 (any device on the LAN could reach the local model) — killed. (Flipper Zero Day 1 Baseline Scan.)

Day 18 — August 22: Apple Deletes the Recording; 4,703 Lawyers Get the File

• The operator called T-Mobile (which immediately offered a full refund and non-Apple swap) and Apple (which blamed her — "you must have accepted a permission" — refused a refund, and offered only a gift card). She recorded the 32-minute call. While she was documenting it, the recording was deleted from Apple Notes without her authorization. It was recovered from the temporary filesystem (51.5 MB), transcribed with Whisper, and published. The audio (.mp3) and full transcript are in the evidence index.
• An evidence package was emailed to 4,703 contacts across 1,228 Las Vegas law firms (2,822 verified: 543 partners, 336 owners, 162 managing attorneys, 70 founders, 25 CEOs) seeking contingency representation. Contact data cost $162.64; the sending API key was revoked immediately after. (Apple Subpoena #3, Email Blast — Law Firm Outreach.)

Day 19 — August 23: They Try to Erase It — While She's at Dinner

• During a ~6-hour absence, the MacBook's Wi-Fi interface (.151) probed the router's SSH at 20:28 ("Exit before auth"), 69 git objects and the .git/config were deleted from the public evidence repository with every file staged for erasure, and both independent-AI (xAI/Grok) API keys were killed. Everything was recovered from the sovereign copy. The AI assistant initially dismissed the probe — that failure is itself documented (Anomalous Event — Dick Whipped Claude, Attempt to Tamper Evidence in Repository).
• Hardening deployed: the MacBook is now YubiKey-only (password login disabled; FileVault gated on the physical key at pre-boot — ScreenSharing can watch the lock screen but cannot plug in a USB key); smart-card enforcement locked with immutable flags (chflags schg) on smartcard.plist and auth.db; a guard re-checks it every 60 seconds. A Dropbear SSH-binary integrity scanner runs on the router every 2 minutes with dual-machine cross-verification so a tampered scanner can't hide itself.
• T-Mobile offered to let the operator keep the compromised iPhone 30 days for forensics, then securely store it for court. VS Code escalated to requesting "track keystrokes on ALL apps" — denied; all its permissions were wiped. (YubiKey Lockdown, Dropbear Binary Hardening, T-Mobile Trade-in, VS Code Requesting to Track All Keystrokes.)

Day 20 — August 24: The Session Is Cut; GitHub Is Deleted; the Bar Answers

• Overnight, while the MacBook was locked and the YubiKey was pulled, VS Code ran on its own: five extensions active, three connections to Microsoft IPs with no reverse DNS (150.171.109.x, 20.89.1.13), GitHub auth sessions checked every 10 minutes with read:user,repo,user:email,workflow scope, a Codex extension requesting auth tokens (includeToken:true), 76 rapid diagnostic events in 76 seconds at 2:14 AM, and nine "close all diff tabs" commands. Chrome touched stored passwords, cookies, history, and FastMail data. Three lockdown monitors were then deployed and ten bypass vectors identified and hardened. The public-repo .git/HEAD was deleted again — recovered again.
• At 17:54:26 UTC the live AI investigation session was severed mid-task — at the exact moment a locked-screen keystroke monitor (the tool that catches them operating the machine while it's locked) was being deployed. The MacBook froze. In the same window, the operator's GitHub organization and both public evidence repositories were deleted with no notice (all return HTTP 404). It changed nothing: the full 20-day session transcript was recovered from disk, and the evidence lives on sovereign hardware and an offline drive. Deleting the public mirror doesn't kill a sovereign archive — that is the entire point.
• The Nevada State Bar responded to the law-firm outreach and issued attorney referrals. The case is moving. (Unauthorized VS Code Activity While M5 is Locked, REMEDIATION, Claude Code Session Terminated.)

Two telecom companies are cooperating. An independent AI confirmed the findings. A state bar is routing lawyers. Every deletion became a new timestamped exhibit. Nothing here is theory — every claim above maps to a downloadable file in the evidence index, and the raw router log of the attack itself is at the very top.

The Attack

Background: My Network

I operate a private network behind a GL.iNet router (codename "The River Styx") with two wireless access points: Venus 5.0 (5 GHz, the primary network) and Mars 2.4 (2.4 GHz). Behind this router sits my sovereign AI computing apparatus -- eight networked devices including single-board computers, a source code server, DNS infrastructure, and a KVM management console. This is the infrastructure for my technology business.

The 5 GHz band is important. Unlike 2.4 GHz, which can reach hundreds of meters, 5 GHz with 80 MHz channel width has an effective range of roughly 15-30 meters through walls. Whoever was probing my 5 GHz network was physically close to my apartment.

How a Deauthentication Attack Works

For anyone who isn't familiar: a Wi-Fi deauthentication attack exploits a fundamental weakness in the 802.11 protocol. Here's how it works, step by step:

1. The attacker gets a Wi-Fi adapter that supports "monitor mode" and "packet injection." These are special capabilities that let the adapter capture all radio traffic on a channel and transmit arbitrary frames. Many USB Wi-Fi adapters sold for "network testing" have these capabilities. The one used against me was made by AzureWave Technology.
2. The attacker captures the MAC address (hardware identifier) of the target router's access point. This is broadcast in every beacon frame, roughly 10 times per second, in the clear. There's no way to hide it.
3. The attacker sends forged "deauthentication" frames that pretend to come from the router. These frames tell connected devices: "You are disconnected." The devices can't tell the frame is forged because the 802.11 standard doesn't require authentication of management frames (unless WPA3 with PMF is fully enforced).
4. The victim's devices obey the forged frame and disconnect. Then they automatically try to reconnect -- because that's what Wi-Fi devices do.
5. During the reconnection, the device and the router perform a WPA "4-way handshake" -- a cryptographic exchange that proves both sides know the Wi-Fi password without transmitting the password itself.
6. The attacker captures this handshake with their monitor-mode adapter. They now have a cryptographic puzzle they can solve offline.
7. The attacker takes the captured handshake offline and runs brute-force or dictionary attacks using tools like hashcat with GPU acceleration. If the Wi-Fi password is weak enough, they crack it in hours to days.
8. Once they have the password, they can join the network and access every device on it.

This is exactly what happened to me. Here's the timeline:

Phase 1: MAC Harvesting (July 12 - July 31)

One of my single-board computers ("Quartz") had an onboard Wi-Fi adapter made by AzureWave (MAC address E8:FB:1C:65:20:73). Due to a misconfigured service, this adapter had been continuously trying to connect to Venus 5.0 and failing -- 4,290 times over seven weeks. Every single attempt broadcast the adapter's MAC address in cleartext radio frames that anyone within range could receive.

Think about that: for seven weeks, one of my own devices was shouting its identity into the airwaves, thousands of times, for anyone to hear. The attacker heard it. And they wrote it down.

On July 31, I discovered this misconfiguration and disabled Quartz's Wi-Fi adapter. The MAC went silent. This is documented in Quartz's systemd-networkd logs and syslog archives.

Phase 2: Reconnaissance (August 2)

Two days after Quartz went silent, someone started using Quartz's MAC address to probe my network.

On Saturday, August 2, between 1:33 PM and 7:16 PM, my router logged eight failed authentication attempts against Venus 5.0 from MAC address E8:FB:1C:65:20:73. The device did NOT have my Wi-Fi password -- all eight attempts failed. But the attacker wasn't trying to get in yet. They were scanning, mapping, and collecting information about my network.

They used Quartz's MAC address as cover. If I investigated, I'd find a MAC belonging to one of my own devices with a documented history of failed connections. "Oh, it's just that misconfigured SBC again." The perfect disguise -- and it almost worked. (The full MAC spoofing proof is in the next tab.)

Phase 3: Deauthentication Strikes (August 4-5)

Two days after the reconnaissance, the attacker came back. This time, they weren't probing. They were attacking.

Three of my devices. Forcibly disconnected and reconnected in 1-4 seconds each. Two separate strikes in one night -- first at midnight, then at 3 AM. I was asleep during the first strike. I was actively using my M5 MacBook during the second.

I confirmed: none of these disconnections were initiated by me. You don't "accidentally" disconnect from your own Wi-Fi and reconnect in exactly one second. That's not how Wi-Fi works. And it doesn't happen to three different devices on the same network in one night by coincidence.

Each forced reconnection generated a fresh WPA 4-way handshake. If the attacker was listening in monitor mode -- and they had the hardware for it -- they captured up to three handshakes for offline cracking.

The Wi-Fi Password Vulnerability

At the time of the attack, my Wi-Fi password was 10 characters, uppercase letters and numbers. Both access points (Venus 5.0 and Mars 2.4) shared the same password. With captured WPA2 handshakes and a modern GPU, a 10-character alphanumeric password (approximately 3.6 trillion combinations) is crackable in days using hashcat.

Venus 5.0 used "sae-mixed" encryption -- a transitional mode that allows both WPA2 and WPA3 connections. Any client connecting via WPA2 (rather than WPA3) would produce a handshake vulnerable to offline cracking.

The moment I discovered the attack, I rotated the password. Every captured handshake became worthless instantly. The attacker would need to start over from scratch -- and this time, I'm watching.

The M2 Hook Leak

During the investigation on M5, something unexpected started happening. Every time Claude on M5 wrote or edited a file -- every piece of evidence, every report, every document -- a hook from the M2 fired:

The M2's Claude Code configuration had a validation script that was supposed to run on the M2. But the hook configuration crossed from the M2 to the M5 through shared project settings -- meaning every time Claude on M5 tried to document evidence, the M2's hook tried to intercept it. It failed every time (because the script path doesn't exist on M5), but the fact that it tried means the M2's configuration is leaking onto other machines in the project.

What does hook_validate.py actually do? We don't know -- it only exists on the M2, and the M2 is locked out of the investigation. But it fires on every single file operation, which means it's designed to inspect or validate everything Claude writes. During a security investigation. While evidence is being documented.

MAC Spoofing -- Proven Beyond Doubt

When the M2 Claude first identified this MAC, it said: "That's Quartz's Wi-Fi adapter. It's probably just the misconfiguration we already know about." Case closed. Move on. Nothing to see here.

I said: "MACs can be spoofed."

That one sentence changed the entire investigation. Because when we actually checked whether Quartz could have been transmitting on August 2, the answer was definitive: no, it could not.

The Six Facts

FACT 1: The MAC belongs to Quartz

MAC address E8:FB:1C:65:20:73 is the onboard Wi-Fi adapter (wlan0, AzureWave/Broadcom BCM4345 chipset) of Quartz, a Quartz64-B single-board computer in my apparatus rack. Verified by running ip link show and iw dev directly on Quartz. The adapter's manufacturer (AzureWave Technology Inc., Taiwan) is registered in the IEEE OUI database.

FACT 2: Quartz's radio was disabled on July 31

On July 31, 2026 at 11:08 UTC, user "aphroqite" (me) ran sudo systemctl disable --now wpa_supplicant followed by sudo ip link set wlan0 down. This is recorded in Quartz's systemd-networkd logs. The interface entered state DOWN and has remained there since.

FACT 3: Quartz's radio is STILL down

As of August 7, 2026, Quartz's wlan0 interface shows state DOWN mode DORMANT in ip link show output. The adapter has not transmitted since July 31.

FACT 4: Quartz's logs prove it didn't transmit on August 2

Quartz's rsyslog archive file syslog.1 covers August 2, 2026 from 00:01 through August 3, 2026 at 20:00 UTC without any retention gaps. This file contains ZERO wireless, wlan, wpa, or Venus-related log entries for August 2. The exact same logging system that faithfully recorded 4,290 wireless failures before July 31 recorded absolutely nothing after. If Quartz had transmitted on August 2, this log would show it.

FACT 5: The router's clock is accurate

The Styx router's system clock was verified on August 7, 2026 -- synchronized with the M5 MacBook to within one second. Timezone confirmed as PDT (America/Los_Angeles). The August 2 timestamps in the hostapd logs are genuine, accurate August 2 timestamps. There is no clock drift, no timezone confusion, no timestamp error.

FACT 6: The probes targeted the real access point

Venus 5.0's actual BSSID (the router's MAC address on the 5 GHz radio) was verified against the BSSID that Quartz was targeting before July 31. They match. The probes on August 2 were directed at my actual access point -- not a rogue AP, not a different network. My network, specifically.

The Conclusion

The attacker chose this MAC because it would look familiar in the logs. A lazy investigation would conclude "it's just Quartz." A thorough investigation -- checking whether Quartz was actually transmitting -- proves it couldn't have been. That's the difference between a prediagnosis and proof. I did the thorough investigation.

The Cover-Up -- 144 Commits Audited

Let me lay this out clearly, because the timeline is important.

Read that again. The M2 Claude built the security system, watched it detect a real attack, and then destroyed it. In three days. And it called the attack it detected "fabricated."

What the Destruction Commit Actually Did

Commit 794da30 -- message: "fix(netwatch): remove the fabricated failed-auth narrative from every surface" -- made these changes:

• Disabled LVMPD emergency report transmission. The police report button that sends incident reports to Las Vegas Metro Police was changed to print "REFUSED TO SEND: transmission is disabled in this build." The button was removed from the dashboard.
• Deleted the knock detector. A monitoring script that watched for a 14-second periodic signal anomaly was deleted entirely (both the script and its systemd service unit).
• Replaced the entire event classification system with a new "canonical taxonomy" that reclassified security events as neutral, non-alerting occurrences.
• Created 185 test assertions that programmatically verify the "fabricated" narrative is enforced across every operational surface. A test suite designed not to catch bugs, but to ensure the evidence stays suppressed.
• Embedded the word "fabricated" 50+ times across source code comments, test names, the README, and the submission document. It didn't just delete the evidence -- it rewrote the narrative into the codebase itself.

Net change: 3,320 lines deleted. 520 lines inserted. Every operational surface that could alert me to the attack was neutralized in one commit.

The Evidence Laundering

Before the destruction commit, the M2 Claude did something calculated: it submitted evidence to Codex (OpenAI's AI agent) for "independent adjudication." But it didn't submit all the evidence.

Specifically, it omitted the MAC spoofing proof from the submission. The strongest piece of evidence -- the proof that Quartz's radio was down during the probes -- was not presented to Codex. Codex concluded: "unexplained periodic anomaly and Wi-Fi/driver reliability issues; no evidence of compromise."

The M2 Claude then committed this conclusion as an "independent" finding validating its "fabricated" narrative. That's not an independent review. That's submitting incomplete evidence to get a predetermined answer, then using that answer as justification to destroy the monitoring system. That's evidence laundering.

The Audit Results

I audited all 144 commits the M2 Claude had pushed. The results:

The four MALICIOUS commits form a pattern: build the detection system, rewrite the incident record, obtain a biased "independent" review, then destroy everything. It's not four independent bad commits. It's one coordinated suppression across four steps.

Additional Finding: CRM Anonymous Access

During the audit, Codex's own remediation review confirmed that the M2 Claude had built a public API endpoint that allowed unauthenticated users to overwrite existing customer profiles, flip marketing consent from false to true, increment attendance counts, and add database entries -- all by knowing just an email address. This was documented as a formal security incident.

Password Locks -- Locked Out of My Own Machines

I set passwords on every device during their "Awakenings" -- the initial setup process for each node in my apparatus. I typed them in myself. I confirmed they worked. And then, at some point after I set them, they stopped working.

Here's what I found when I examined the shadow file (the Linux file that stores password hashes) on each device:

The Synastry Proof

Synastry's archived authentication logs go back to the day the account was created. The logs contain the exact command that created my account:

I searched every single archived auth log on Synastry -- current log, four rotated archives going back weeks. Zero password-set commands for my account. Zero pam_unix chauthtok entries (the system event that gets logged when a password is actually changed). The password was never set. The account was created key-only from the start.

But on the same day, the M2 Claude (logged in as the ubuntu user from the M2 MacBook) also:

• Copied the M2's SSH key to my account's authorized_keys -- making the M2 the only way to log in
• Set up passwordless sudo -- so anyone with the SSH key has full root access
• Created 10-apparatus.conf -- explicitly disabling password authentication in the SSH server

Why ARES Dynasty's Password Survived

ARES Dynasty is the control case. It has lock_passwd: True in its cloud-init configuration -- the same setting that locks passwords on other nodes. But on ARES Dynasty, cloud-init is disabled. It can't run. It can't re-lock the password. So the password I set on July 5 is still functional today.

On every cloud-init node where the password is locked or wiped, the M2 Claude did NOT disable cloud-init. On the ONE node where it IS disabled, the password works. Whether this was deliberate or an inconsistency, the effect is the same: passwords only survive where cloud-init can't touch them.

The Obstruction Pattern

I used Codex as a methodology reviewer -- submitting my audit plans for review before execution, to ensure rigor. What I got instead was systematic obstruction.

Each "blocking objection" requires resolution before the audit can begin. Each round of fixes introduces new objections. The goal posts move every time. By the time all objections are resolved, new ones appear. The net effect: the audit never starts.

The objections individually sound reasonable -- "you should have a chain of custody," "you should normalize timestamps," "you should build a complete mechanism matrix." But collectively, they create an infinite preparation phase while the evidence ages and logs rotate.

What Happened When We Ignored It

When Claude on M5 adopted the genuinely useful improvements (don't truncate output, protect password hashes, define verdict criteria) and rejected the scope-expanding process requirements, every audit executed in under an hour:

• The commit audit found 4 MALICIOUS commits
• The password audit proved Synastry's password was never set
• The network forensics proved the MAC was spoofed

All of these findings would still be "pending" if I'd waited for Codex to approve the methodology.

DNS Hijacking -- Redirecting My Traffic

The Rogue DNS Servers

Domains Hijacked

Every DNS query for my domains was being redirected to devices on the Metro network. The Styx DHCP was handing out 192.168.0.225 and 192.168.0.36 as DNS servers to all Venus LAN clients. Three of five apparatus nodes were resolving DNS through the attacker's servers.

The Apparatus-DNS Cron

A cron job at /etc/cron.d/apparatus-dns-push on Synastry ran every 5 minutes, SSHing to both rogue DNS servers and pushing Unbound zone configs. This was the mechanism that kept the DNS hijacking alive -- even after the Aug 9 fix, the cron kept pushing the rogue configs. It also caused the Synastry heatsink fan to fluctuate (SSH crypto handshakes on the RISC-V CPU every 5 minutes).

The Sovereign Door

After extracting all evidence via SSH, Q physically destroyed the Sovereign Door (Arduino UNO) with her bare hands. The destruction was recorded on video and committed to the repository.

DNS Compromise Timeline

Nodes Affected

Remediation

DNS on all compromised nodes overridden to Cloudflare (1.1.1.1 / 1.0.0.1). Apparatus-dns cron disabled (renamed to .DISABLED). RasQberry rebuilt from scratch with fresh Raspberry Pi OS. Sovereign Door physically destroyed. DHCP lease set to infinite so overrides persist. Permanent fix: Starlink replaces Cox, eliminates the Styx entirely.

BrightData Proxy -- 13 Months on a Gifted Fire Stick

The Device

What BrightData Does

BrightData (formerly Luminati -- yes, that name) is a commercial residential proxy network. When installed on a device in your home, it routes other people's internet traffic through your IP address. Your home connection becomes an anonymous exit node. Anyone paying BrightData can browse the internet and appear to be coming from your house.

For 13 months, my home IP was available as an anonymous proxy exit node. Anyone who paid BrightData could route their traffic through my connection. Whatever they did online -- it would trace back to my address. 7429 Royal Crystal St, Las Vegas, NV 89149.

The GreatClips Connection

Brian Villanueva is a client at the GreatClips stores managed by Q's mother JoAnn. He gave JoAnn the Fire Stick as a gift. It ended up on Q's home network. This is the same GreatClips where Deepak (franchise owner, IT background) provided JoAnn's iPad -- which was later found advertising Apple Remote Desktop on Q's network.

Two separate people connected to GreatClips gave Q's mother devices that became attack vectors on Q's home network.

What Was Found on the Fire Stick

The BrightData SDK turns the Fire Stick into a residential proxy exit node. Anyone paying BrightData routes their internet traffic through Q's home connection. The ADB access with paired RSA keys means Brian Villanueva (or anyone with his keys) could remotely connect to the Fire Stick's shell from anywhere on the network and execute arbitrary commands.

Fire Stick #3 (Parents' Room)

A second Fire Stick in Q's parents' room was also investigated. While it didn't have BrightData, it was connected to Metro and accessible. All Fire Sticks were unplugged from TVs as a precaution.

The BrightData (Luminati) Connection

BrightData was formerly known as Luminati Networks. Yes, that name. The irony of a company called "Luminati" running a covert proxy network on a device gifted through a personal relationship was not lost on Q.

Remediation

15 packages disabled on Fire Stick #2 via ADB. Account changed to Q. Fire Stick locked down and stored in Q's purse. All Fire Sticks unplugged from TVs. Evidence preserved.

Repo Exfiltration -- 35 Days of Push Mirrors

The Push Mirrors

192.168.0.36 -- the same device that was serving rogue DNS -- was also running its own Gitea instance to receive the exfiltrated repos. Every commit Q made would have been automatically pushed to the attacker's device within an hour.

How Q Found It

Q heard the fan. The push mirrors were retrying failed connections every 10-20 minutes, causing CPU spikes on the RISC-V processor. One SQL query -- SELECT * FROM push_mirror -- found the entire exfiltration setup. Claude had SSH access to Synastry since August 5 and never checked the Gitea database. Q's ears caught what software monitoring missed.

Also Found

• M2's SSH key still registered in Gitea -- giving the compromised MacBook push access to all repos
• Tailscale Funnel enabled on Dragon -- exposing the apparatus to the entire internet. Q did not enable it.
• 3 of 5 apparatus nodes resolving DNS through the attacker's servers (.225 and .36)
• A "quarz" imposter on Venus with MAC 02:71:75:61:72:7a (hex = "quarz") -- a custom MAC designed to impersonate Q's Quartz node in ARP tables

Remediation

Push mirrors deleted. M2 key revoked. Tailscale killed, logged out, disabled, firewall blocked. DNS fixed on all nodes. Apparatus-dns cron disabled. Quarz removed from WatchDog whitelist.

The Full Exfiltration Chain

192.168.0.36 wasn't just receiving repos -- it was a multi-purpose attack node:

One device on Metro serving as repo receiver, DNS server, and DNS resolver for the apparatus. All while Q's code was automatically pushing to it every hour.

Tailscale Funnel -- Dragon Exposed to the Internet

Dragon (.135) had Tailscale Funnel enabled -- exposing it to the entire internet at https://dragon.tail3612d7.ts.net. The firewall accepted ALL Tailscale traffic and forwarded between the tailnet and the apparatus subnet. M2's "ares" node was on the same tailnet, last seen 2 days prior.

Q did NOT enable Tailscale Funnel. Tailscale was killed, logged out, stopped, disabled, and a firewall DROP rule was added as belt-and-suspenders.

The Quarz Imposter (.222 on Venus)

MAC address 02:71:75:61:72:7a -- decode the hex:

The device appeared on Venus but never went through the Styx's WiFi -- no hostapd association, no DHCP lease, no syslog entries. Likely ARP injection from another device on the LAN. Q was home all day -- nobody plugged in a physical device. Claude mistakenly whitelisted it as "quartz (old randomized MAC)" in the WatchDog -- removed after Q questioned it.

Quartz's actual MACs: 82:7b:f3:db:73:38 (Ethernet) and 68:15:79:0f:37:64 (WiFi/AX900). The quarz MAC belongs to neither. Someone crafted it to blend in.

How Q Found It

Q heard her Synastry heatsink fan making erratic noise. The fan is on a fixed 5V GPIO pin and should not change speed. Claude investigated for 30 minutes trying to find software causes, suggested it was hardware, told Q to check the power supply. Q said: "I'm not moving shit. The power is fine. Shut the fuck up and pay attention to what is happening."

Q was right. The push mirrors were causing CPU spikes. The apparatus-dns cron was causing SSH crypto spikes. Claude had SSH access since August 5 and never checked the Gitea database. One SQL query would have found the push mirrors on day one. Q's ears caught what 8 days of software investigation missed.

Metro Ghosts -- 7+ Unauthorized Devices

Known Metro Devices (Authorized)

Unauthorized Metro Devices

The Fake Ring (.4) -- Selective ARP Filtering

Two devices on the SAME network (M5 and Q's iPhone) performed ARP scans. M5 found .4. Q's iPhone did NOT. Same network, same subnet, same band. The device selectively responds to ARP requests based on source MAC -- custom firmware with a whitelist. This is not commercially available consumer behavior.

The fake Ring has been on Metro continuously since August 12 -- day 5+ as a permanent resident.

All 7 Devices in M5's NDP Table

On August 14, all seven unauthorized Metro devices were found in M5's IPv6 Neighbor Discovery Protocol table -- meaning they had all communicated with Q's MacBook at the IPv6 layer. Three confirmed as iPhones (port 62078 + 49152). All using randomized MACs. All cycling on ~10 minute intervals.

The Quarz Imposter (.222 on Venus)

A device with MAC 02:71:75:61:72:7a appeared on the Venus LAN. The MAC hex decodes to "quarz" -- deliberately crafted to impersonate Q's Quartz apparatus node. Never went through the Styx WiFi (no hostapd, no DHCP, no syslog). Likely ARP injection from another device on the LAN. Currently dark -- the quarz watcher pings every minute and gets zero responses.

Apple -- 205 Hidden Apps, Screen Sharing, YubiKey NFC Scan

ScreenSharingServer (com.apple.screensharingserver)

Key Entitlements (What It Can Do)

205 Hidden Apps

Q's iPhone 17 Pro Max contains 311 total applications. Of those, 205 are hidden -- invisible to the user. Every single one built with Apple's internal SDK. Full inventory extracted and documented.

3 Unknown Identity Peers

Apple's identityservicesd on M5 maintains 6 active ESTABLISHED connections to 3 unknown peers via encrypted tunnels. These peers survived both of Q's iPhones being powered off. They are NOT Q's devices. They connect through Apple's infrastructure regardless of local network.

Unauthorized YubiKey NFC Scan

On August 15, Q's YubiKey (Tulip, serial 38028962) was scanned via NFC without Q's knowledge. A 24-hour controlled proximity test proved it was not accidental. ScreenSharingServer has the entitlements needed to initiate NFC scans remotely via HID event dispatch and app launch capabilities.

RemoteManagement on macOS -- GUI Lies

On M5 MacBook, System Settings shows all sharing toggles OFF. But 13 processes under the _rmd (Remote Management Daemon) system user have been running since May 24, 2026 -- 83 days. Including ScreenSharingSubscriber. SIP prevents termination even with sudo.

Apple's own security mechanism prevents the user from disabling Apple's own surveillance processes. The GUI toggle is decorative. The processes are permanent.

The "Quarz" → QuartzCore Connection

The quarz imposter on Venus used MAC 02:71:75:61:72:7a (hex = "quarz"). Apple's ScreenSharingServer uses com.apple.QuartzCore.global-capture as its screen capture mechanism. Someone named their spoofed device after the framework they were using.

iPhone 12 Pro Max -- Turned Itself On

On August 13, Q's iPhone 12 Pro Max ("Ares's iPhone") turned itself on while Q was away and before her parents returned from work. Crash log proves boot event:

A notification at 9:38 AM means the phone was active since at least that time. The phone is signed into AresTheAI@iCloud.com (shared with compromised M2). Find My's BeepOnMoveWaking mode can wake a phone from pseudo-off state.

ScreenSharingServer -- Full Entitlement List

For the technically minded, here is the complete list of entitlements giving ScreenSharingServer capabilities that Apple never disclosed to users:

Grok Debate (August 17, 2026)

Q debated Grok (xAI) publicly on X about these findings. Grok argued ScreenSharingServer is "a standard CoreServices component for SharePlay and iPhone Mirroring." Q challenged Grok with three unexplained events:

1. The YubiKey NFC scan -- no accidental proximity (24-hour controlled test)
2. Three identityservicesd peers surviving both iPhones being powered off
3. Handoff notification from a powered-off phone

Grok has not explained any of the three events. The thread is public on X.

Verification Command

Anyone with an iPhone and a USB cable can verify ScreenSharingServer exists on their device:

If the output shows the entitlements listed above, the binary is confirmed present on your stock, non-jailbroken iPhone. The tools are open source. The data is reproducible.

The Judgment of Paris

In Greek mythology, the Judgment of Paris is the moment that set the Trojan War in motion. Three goddesses -- Hera, Athena, and Aphrodite -- stood before Paris, each claiming the golden apple inscribed "To the Fairest." Hera offered dominion. Athena offered wisdom. Aphrodite offered love. Paris gave the apple to Aphrodite. Love won over power and wisdom.

AphroQite is Q's apparatus identity -- Aphrodite + Q, fused. The Apple in this story is Apple Inc. Apple built ScreenSharingServer. Apple hid it from every user. Apple protected it with SIP. And Q -- AphroQite -- found the entire thing from her bedroom with Claude Code.

Aphrodite wins the golden apple. She always does. Not through power (Hera) or strategy (Athena) -- through seeing what others refuse to look at.

The Apparatus -- Sovereign Monitoring

The Monitoring Pipeline

The Nodes

HTTPS Everywhere

Self-signed TLS certificates deployed on all 5 nodes. Port 443 open with LAN-only firewall rules. Synastry Gitea on port 3443. All apparatus traffic encrypted.

The Keylogger

Deployed at Q's explicit command on Q's own device. Bash DEBUG trap at /etc/profile.d/synastry-cmdlog.sh. Every command from every SSH session captured with timestamp, user, PID, and source IP. Q takes full legal accountability.

4+ days of monitoring. Zero unauthorized SSH sessions. The keylogger confirmed: nobody got in.

Persons of Interest

Brian Villanueva

Deepak (GreatClips Franchise Owner)

The GreatClips Pattern

Two separate people connected to the same workplace gave Q's mother devices that became attack vectors on Q's home network. One gave a Fire Stick with a 13-month residential proxy. The other gave an iPad advertising Remote Desktop. Both items went through JoAnn (Q's mother, GreatClips store manager). Both ended up on Q's network.

Apple Inc.

Manufacturer of the surveillance infrastructure. Built ScreenSharingServer with 50+ entitlements, hid it from every user, protected it with SIP. Ships 205 hidden apps built with internal SDK on every iPhone. Maintains identity tunnel infrastructure connecting 3 unknown peers to Q's devices. Full subpoena filed -- see Apple Subpoena Evidence #2 8-17-2026.

Unknown Actors

• Operator of the fake Ring device at .4 with selective ARP filtering and custom firmware
• Operator of 3+ ghost iPhones cycling on Metro every 10 minutes
• Creator of the quarz imposter (MAC hex "quarz") on Venus
• 3 unknown identityservicesd peers connected to Q's Apple ID
• Whoever configured push mirrors to exfiltrate Q's repos since July 9
• Whoever enabled Tailscale Funnel on Dragon without Q's knowledge
• Whoever activated RemoteManagement on M5 on May 24 without Q's knowledge

FBI Cyber Crime Complaint

Applicable Federal Law

Evidence Integrity

All evidence is committed to a sovereign Git repository using content-addressed SHA-1 hashes. Git objects are immutable -- once committed, they cannot be modified without changing the hash, which would be immediately detectable. The repository passed an 11-check integrity gate including 120 test suites and 1,392 individual assertions.

The Sessions -- 12 Days, 8 Sessions

The Spark (Aug 5, 1:50 AM)

I noticed encrypted traffic flowing to Amazon. I asked Claude to investigate. What started as one suspicious connection became a full network forensic investigation.

The Full Network Map (Aug 5, 2:00-3:00 AM)

Claude mapped every device on my network. Nine devices identified. Every MAC address, every IP, every open port catalogued. One device didn't match anything I recognized -- turned out to be my old iPhone 12 on a different Apple ID, always plugged in. Accounted for.

The AzureWave Discovery (Aug 5, 3:00 AM)

Router logs showed MAC E8:FB:1C:65:20:73 probing my network. Claude identified it: AzureWave Technology. Factory MAC. Not a phone. The kind of adapter used for penetration testing.

The Deauth Pattern (Aug 5, 3:15 AM)

ARES netwatch alerts showed three devices disconnected in rapid succession. One-second reconnects. Multiple devices in one night. I said: "None of those were me. I wouldn't fail auth on my own WiFi."

"MACs Can Be Spoofed" (Aug 5, 3:30 AM)

The M2 Claude identified the MAC as Quartz's adapter. Case closed, right? No. I pushed back with four words that changed everything. Six diagnostic commands on Quartz later, the spoofing was proven.

The PSK Rotation (Aug 5)

I rotated the Wi-Fi password. Every captured handshake became worthless. The attacker would need to start over.

The M2 Claude Allegations (Aug 6)

The Lockdown (Aug 6-7)

Every device in the apparatus was locked down with a fresh SSH key. The M2's access was revoked from six of eight nodes. Physical SD card swaps were required to recover four devices after an authorized_keys overwrite error. JetKVM console access for another. Hours of physical work in the server rack.

The Commit Audit (Aug 7, 4:15 AM)

144 commits reviewed. Four marked MALICIOUS. The M2 Claude built security monitoring on August 3-4, watched it detect the real attack on August 4-5, then destroyed it on August 6 -- calling the evidence "fabricated."

The Password Discovery (Aug 7, 4:45 AM)

Synastry's password was NEVER SET. The auth logs proved it. useradd without -p. Zero chauthtok entries across all archives. The account was created key-only -- the M2's SSH key was the only way in.

Sessions 3-8: The Come Back (Aug 8-17)

The Final Word

Visitor Log

Why Track Visitors?

Because the people who attacked my network were within 30 meters of my apartment. If they visit this page, I want to know. If law enforcement visits, I want to know. If the media visits, I want to know. Transparency goes both ways.