Blog
Welcome to the Blog.
State Machines That Survive Noise
2026-02-22
A lot of embedded bugs are not algorithm failures. They are state-management failures under imperfect signals. Inputs bounce, clocks drift, interrupts cluster, and peripherals report transitional nonsense. Firmware that assumes clean edges and ideal timing eventually fails in the field where noise is normal.
Robust systems treat noise as a design input, not a test surprise. ... continue
SPI Signals That Lie
2026-02-22
SPI looks simple on paper: clock, data out, data in, chip select. Four wires, deterministic timing, done. In real projects, SPI failures often appear as “sometimes wrong bytes,” “first transfer fails,” or “only breaks on production boards.” These are the kind of bugs that waste days because the bus seems healthy at first glance.
The core lesson is that SPI integrity is not just protocol correctness. It is electrical timing, firmware sequencing, and peripheral state management combined. ... continue
Security Findings as Design Feedback
2026-02-22
Security reports are often treated as defect inventories: patch issue, close ticket, move on. That workflow is necessary, but it is incomplete. Many findings are not isolated mistakes; they are design feedback about how a system creates, hides, or amplifies risk. Teams that only chase individual fixes improve slowly. Teams that read findings as architecture signals improve compoundingly.
A useful reframing is to ask, for each vulnerability: what design decision made this class of bug easy to introduce and hard to detect? The answer is frequently broader than the code diff. Weak trust boundaries, inconsistent authorization checks, ambiguous ownership of validation, and hidden data flows are structural causes. Fixing one endpoint without changing those structures guarantees recurrence. ... continue
ROP Under Pressure
2026-02-22
Return-oriented programming feels elegant in writeups and messy in real targets. In controlled examples, gadgets line up, stack state is stable, and side effects are manageable. In live binaries, you are usually balancing fragile constraints: limited write primitives, partial leaks, constrained input channels, and mitigation combinations that punish assumptions.
Working “under pressure” means building payloads that survive imperfect conditions, not just proving theoretical code execution. ... continue
Recon Pipeline with Unix Tools
2026-02-22
Recon tooling has exploded, but many workflows are still stronger when built from composable Unix primitives instead of a single monolithic scanner. The reason is control: you can tune each step, inspect intermediate data, and adapt quickly when targets or scope constraints change.
A practical recon pipeline is not about running every tool. It is about building trustworthy data flow: ... continue