Engineering
iOS, Android, backend APIs, authentication, security analysis, reverse engineering and release reliability.
Explore projectsAbout the person behind ZombieMutex
Jeffrey Monica
Software engineer working across iOS, Android, backend authentication, mobile security and offensive testing.
My professional work spans native mobile apps, security-critical API integrations and production reliability. I write about the implementation details: where authorization lives, how device-integrity claims are checked, and what to test when a client retries, a token expires or a system loses connectivity.
I've built mobile apps, backend services, security controls and integrations for systems used in enterprise environments. I still enjoy getting into the details and working alongside people who care about them. When I'm away from the keyboard, I'm into food, hiking, travel, photography, and other things beyond engineering. This site is my place for both sides of that life, so here we are.
Work, writing, and interests
Writing
Technical notes, experiments, and lessons learned while investigating and building software.
Read the writingLife away from work
Travel, hiking, cooking, photography, reading, and the things worth making time for.
See the photographyProfessional profile / Work and research
Engineering work you can inspect
I work with Demonic Binary on engineering and security. ZombieMutex is my personal research and writing home, with technical case studies, source excerpts and test observations. The sites have different purposes: this one documents my engineering decisions; the company site explains professional engagements.
Engineering background
How I work
I've built native iOS and Android apps, the APIs behind them, and the security boundaries everyone hopes are someone else's problem. That means Swift, Kotlin, authentication and token lifecycles, secure storage, device integrity, backend services, telemetry, and release pipelines. There's usually a network timeout lurking somewhere too.
I'm not big on debugging by vibes. I'd rather reproduce the failure, follow the request from device to server, figure out which system actually owns the decision, and write tests for the cases nobody puts in the demo: expired credentials, concurrent requests, retries, flaky networks, and users who refuse to cooperate with the happy path. Rude of them, really.
Agent systems / Security boundaries
The model proposes. The system authorizes.
I've implemented agent-to-API integrations, webhook verification, adversarial evaluation fixtures and the failure handling around external tool calls. The interesting bugs aren't usually in the chat response. They happen when generated instructions cross into authentication, customer data, network access or a state-changing API.
I keep those decisions out of the model. I bind operations to a verified principal and a specific permission, test cross-tenant and replay paths, and make denials observable without dumping private content into logs. On this site I've also built a deterministic agent policy lab to reproduce the decisions in isolation. It's reference code, not a claim that I've deployed a production agent sandbox or hardened a kernel.
Security implementations / Rust and Go
Reproducing failures at the binary and API boundary
I implemented a Rust ELF binary-hardening analyzer with checked parsing and explicit uncertainty around missing protections. I also built a Go concurrency harness that reproduces broken object-level authorization and repeated mutations, then tests the corrected atomic decision paths. Both are local, inspectable implementations, with tests and source published rather than borrowed claims from production systems.
Inspect Rust & Go projects →I like building things with people.
Some of my favorite work has come from sitting down with someone else, understanding the actual problem, and figuring out where the system needs to change. I'm always interested in trading ideas with other engineers, contributing to open source, and helping with useful community projects. Good questions welcome. Mysterious production incidents too, preferably with logs.
Security / Break it, then fix it
Reproduce the attack. Then try to break the fix.
I start by treating the client as untrusted, because a modified app will happily tell the server whatever it wants to hear. I look for authorization gaps, replayable requests, token rotation mistakes, dodgy device-trust assumptions, and race conditions that turn a clean sequence diagram into modern art.
I reproduce the path, fix the trust boundary that actually failed, then run the attack again. If the whole fix is a disabled button or another check in the client, congratulations: the attacker has a new button to ignore.