A running log.

I’m turning sleepmask into a research write-up. So far, I’ve covered the import-free x64 blob, how I find ntdll and resolve syscall numbers, the masked wait, and what my test harness actually validates. I’m tying each implementation detail to the evidence, including what I have and have not demonstrated. This is the work in progress so far.

Halfway through September now. AutoFTE hit 0.10.0, ProtoLoom went through a full adversarial audit, Silica’s verification got stricter, and a side project ate most of a whole day almost by accident. Having four things moving at once only works because each one’s mature enough now to pick up for a short, focused session instead of needing a running start every time.

Spent most of today making one of my FPGA projects distrust its own claims by default. Any statement it makes about the target chip now has to trace back to actual database records and frame level evidence before it gets accepted. Same pattern CHIMERA’s oracle work set up earlier in the summer: a system’s own success signal isn’t evidence on its own, only something checked independently actually counts.

Tightened up the local Git ingestion on that same project today to match. Trees, objects, subtrees, and topology evidence all have to authenticate now before they count toward a claim. Bringing the Git side up to the same evidence chain standard as the hardware side closed the obvious gap where half the system was rigorous and the other half was still taking things at face value.

Stopped being nice to ProtoLoom’s test inputs today and started treating it like a mildly hostile real world binary would. It found real gaps almost immediately, the kind of edge cases tidy, self written fixtures never produce because you unconsciously avoid the cases you already know are hard. Testing your own tool like it’s out to get you is uncomfortable in a good way.

Found a bug in ProtoLoom today where the recovered schema still compiled totally fine but quietly resolved a dotted type name to the wrong nested type. The scary part isn’t the bug itself, it’s that this kind of resolution error produces output that looks completely valid. Compiling successfully and resolving correctly turned out to be two very different guarantees, and this is exactly the kind of bug only adversarial testing catches.

Tried a multiprocessing speedup for ProtoLoom today. It was noticeably faster, and also wrong often enough that I reverted it within the hour. Benchmarks caught the regression before it got anywhere near a release, which is a pretty clean example of why “faster” and “correct” need to be measured separately instead of assumed to go together.

Kept pushing the ProtoLoom adversarial audit into fuzzing and diffs against real apps today. Cross DEX enums, nested types, AAR packaging, they all turned up their own distinct failure modes. Each one’s a corner of the protobuf recovery problem that synthetic test cases just weren’t shaped to reach. Diffing real apps keeps finding bug categories fuzzing alone doesn’t, which is honestly the whole reason to run both.

Added ten more chaotic systems to the site’s catalog today and made the Lorenz attractor the favicon. Not something the site strictly needed. Still felt right though. A wider catalog means people are way less likely to see the same attractor twice, and the favicon is a small, deliberate nod to what the whole visual system is actually built on.

Pretty release heavy week. AutoFTE hit 0.10.0, Silica got a lot stricter about the claims it’s willing to make, and ProtoLoom’s published artifacts got a real provenance trail. None of these were huge changes on their own, but shipping all three in the same week meant testing all three release processes back to back, which caught a couple of process gaps that testing them one at a time never would have.

Finally wrote the long form case studies for AutoFTE, ProtoLoom, and Silica today instead of letting three READMEs keep standing in for an actual explanation. Writing the full version turned up a few spots where I understood the “how” of a project fine but hadn’t really put the “why” into words. That kind of gap only shows up once you try explaining it to someone who wasn’t there.

Kicked off September making Silica a lot pickier about the evidence it accepts and a lot faster at checking it. Both were overdue. A verification tool that’s too permissive just gives false confidence, and one that’s too slow doesn’t get run often enough to actually matter. Tightened the acceptance criteria first, then optimized the checking against the stricter version instead of the other way around.

August ended up being TraceLoom’s build out, a full site rebuild, ProtoLoom becoming installable, a much better Silica reader, and an AArch64 rabbit hole that wasn’t anywhere on the plan for the month. That unplanned detour was honestly the most useful part of it, even if it wasn’t the most efficient. Chasing that decoder disagreement taught me more about the ISA than any of the scheduled work did.

Built a small AArch64 reproducer today around parse_record and ASan so yesterday’s decoder disagreement stayed tied to a real binary and a real crash instead of just a description of one. A reproducer anyone can run is worth way more than any amount of careful explaining. It turns “I think these disagree” into something a maintainer can check in thirty seconds.

Started manually picking apart raw AArch64 encodings today after noticing two decoders disagreeing on the same instruction bytes. Neither disagreement seemed like a big deal on its own, but that kind of small inconsistency is worth chasing right away before it gets buried under a hundred other encodings. Spent the whole evening in the ISA manual instead of doing anything I’d actually planned.

Published AutoFTE 0.2.1 to PyPI today and cleaned up the package page to match. There’s a very specific kind of nervousness watching pip install actually work against a package you just pushed for the first time. Small thing, but it’s a real signal the packaging and dependencies all held together outside my own machine.

Turned ProtoLoom from a repo you had to clone and configure into something you just install today. Automated the release path and built standalone artifacts, so using it doesn’t mean reading the source to figure out the setup anymore. The gap between “a tool that works” and “a tool people will actually use” is basically all in this unglamorous distribution stuff.

Set out to add a handful of features to AutoFTE today and somehow ended up shipping dedup, sanitizer parsing, severity scoring, SARIF export, benchmarks, packaging, and CI all in the same pass. Turns out each one needed infrastructure the others also needed, so building them together was actually less work than doing them separately would’ve been. Good reminder that scope estimates are usually wrong in the direction of “these are more connected than they look.”

Rebuilt quandle.xyz today around scroll driven chaotic attractors and finally got the Cloudflare deploy path working end to end. Every earlier version of this site felt like a template with my name slapped on it. This one’s built around a visual system I actually care about, and I understand every part of the build and deploy pipeline now. First time the site has actually felt like mine.

Finally pointed TraceLoom at real data instead of fixtures today. The fixtures had been quietly hiding a bunch of assumptions that didn’t hold up outside a curated test set. Fixed those, then wrote down the actual results and caveats honestly instead of the clean numbers the fixtures kept handing me. Real data doesn’t just test the tool, it tests whether the earlier tests were even testing the right thing.

TraceLoom stopped being a parser today and turned into an actual detection pipeline: seven heuristics, correlation across them, an eval harness, generated reports, and a CLI to run all of it. None of this was the plan going in, each piece just exposed a gap the next piece had to fill. By the end of the day the parser was maybe a tenth of the codebase.

July went mostly to three things running in parallel: CHIMERA’s policy and safety work, SPECTER-FUSE’s search and provenance tooling, and a GCP detection range built from nothing. All three are basically defensive plumbing in different clothes, systems whose whole job is making some other system trustworthy or measurable. Apparently that’s just the kind of problem I end up building for myself when nobody hands me one.

Added an attack path graph, remediation scripts, candidate SQL generation and verification, and scenario metrics to the range today. This is the point where it stopped being a pile of fixtures and turned into something with an actual evaluation loop: generate a candidate, check it against the graph, measure it against the scenarios. That loop is really the whole point. The scenarios were just there to give it something to run against.

Didn’t have a live GCP range to work with today, so I just hand wrote two synthetic BigQuery audit logs, built a normalizer for them, and put together the first attack scenario from scratch. Not having the “real” thing turned out to be useful. Building the normalizer against logs I wrote myself meant actually understanding the format instead of just pointing tooling at something live.

By the end of the same day the range had six attack scenarios plus a benign day fixture to compare against. One synthetic log was enough to prove the pipeline worked, but not enough to know if detections actually generalized. The benign day fixture ended up mattering just as much. Without a clean baseline, “it fired” doesn’t really tell you anything.

Ran CHIMERA’s full calibration study today: 1,248 runs across 26 variants, four capabilities, four adaptation conditions. This is the study that turns “I think this helps” into an actual number with a confidence interval attached. Some of the conditions did exactly what I expected going in. At least one didn’t, and that was honestly the more useful result of the two.

Spent the day actively trying to break CHIMERA on purpose. Adversarial LLM proposals, forced emergency stops, ground truth isolation checks, injected rollback faults, all of it. The goal wasn’t to prove it’s safe, it was to find where it isn’t while I still control the fix. A few of the emergency stop paths held up under stuff the happy path tests never would’ve hit. A couple rollback edge cases didn’t, so those got fixed on the spot.

Got all four CHIMERA capabilities running through the full integration path today, including effect, restore, and recovering from service drift. Each one had already passed on its own, but running them together back to back under real drift turned up a few interaction bugs that isolated tests never would’ve caught. Good reminder that isolated and integration tests really do catch different things.

Spent today building out CHIMERA’s stats side: confidence intervals, paired tests, mutation importance, adaptation gain, brittleness, rollback fidelity, all of it. None of this changes what CHIMERA actually does, it just means I can back up a claim about how well it does it. Without this, “seems to work better” isn’t a result, it’s a vibe.

Added CHIMERA’s adaptation ladder today. It tries deterministic fixes first, falls back to approved templates, and only as a last resort lets a local Ollama model propose something inside a fixed schema. The model never gets to freestyle, its output has to fit the schema and pass the same checks as everything else. Keeping it as the last, most boxed in option instead of the default felt important.

Built CHIMERA’s own independent oracle today so a clean exit code stops counting as proof on its own. Now the target state, the artifact hash, and the restore state all have to agree before a run counts as a success. Came out of watching a run “succeed” while quietly leaving things in the wrong state. Good reminder that a process returning 0 and a system actually being correct are two different things.

Added a deny by default policy layer to CHIMERA today. Anything the adaptive part wants to do now has to prove it belongs there before it’s allowed to run. Flips the whole thing from permissive unless blocked to blocked unless justified, which felt like the right posture for something that proposes its own changes. Getting this in before the adaptive logic existed made everything after it way easier to reason about.

Gave SPECTER-FUSE a real CLI today, plus a prepare day data path and some automated quality reports. Up until now using it meant reading the source just to figure out how to call it. It’s a small thing but it’s the difference between a research tool and something other people, or future me, can actually pick up and run.

Added Pareto filtering to SPECTER-FUSE today so it keeps the useful tradeoffs instead of every single trial it’s ever run. This basically fixed yesterday’s problem. Instead of a giant pile of results, it only keeps what’s actually informative now. Small change, but it made the whole thing feel way more usable.

Built out the search space for SPECTER-FUSE today and ran a full factorial search over it. The search worked fine on the first real try. The problem was scale, the experiment count blew up the moment I plugged in real parameters. Lesson learned: think about how fast the search space grows before building the search.

Started dumping SPECTER-FUSE’s run output into DuckDB instead of digging through folders by hand. That manual approach was fine at ten runs and fell apart way before a hundred. Once it was all queryable, patterns across runs that were basically invisible before just showed up.

Built the experiment runner for SPECTER-FUSE today. Every run now carries commit and image info, saves its artifacts, and always leaves a result behind whether it worked or not. Before this a bad run would just vanish. Now there’s a trail back to exactly what code and setup produced it.

Got SPECTER-FUSE split into five services running on its own Docker network today: sensors, an effect proxy, fusion, mission control, and evidence storage. Splitting it up like this forced me to actually define how the pieces talk to each other instead of letting state leak everywhere. By the end of the day it stopped feeling like a script and started feeling like an actual system.

Turned in the final GLeNN2.0 capstone today. Basically it takes a raw FPGA bitstream, breaks it down into FASM, pulls LUT clues into a graph database, then runs a solver over that graph to get the actual logic back out. The hard part wasn’t any one step, it was getting all three to actually agree with each other. Technically a school project, but honestly the first real reverse engineering pipeline I built start to finish on my own.