Contactless Systems Research
Reverse-engineering a contactless authorisation scheme with reader hardware I built myself.
Overview
This is security research into how resilient everyday contactless systems really are. Using NFC and RFID reader hardware I built myself, I studied how one contactless product authorises actions, reverse-engineered its scheme, and found a logic flaw in the trust model behind it. It was a proof of concept, disclosed privately to the vendor and never used in the wild. Everything below describes how the work was done and why it stays abstract on this page, not what the target was or how to repeat it.
Why I built the reader
Off-the-shelf readers hide the parts I needed to see. To study a protocol properly I wanted control over the raw exchange between the reader and the tag, so I built my own NFC and RFID reader hardware and worked at the level of the tag protocol itself, including NTAG-class tags. Building the reader meant I could watch the framing and the sequence of messages directly, rather than trusting a finished tool's abstraction of them. That control is the point: the interesting behaviour lives in the exact bytes a product sends and expects back, and a black-box reader would have smoothed those over before I ever saw them.
Reading an undocumented protocol
The product's authorisation scheme was undocumented, so the first job was to make sense of it from observation alone. I captured the exchanges, mapped the message sequence into a rough state machine, and separated the parts that carried real authorisation weight from the parts that were just formatting. From there the question was not whether the cryptography could be broken but whether the system trusted the right things. The flaw sat in the logic: the product treated a piece of state as authoritative when it was actually under the holder's influence, so the intended limits could be bypassed without breaking any crypto. Naming that boundary and reasoning about it cleanly was the actual research.
Why it stays abstract
I have kept this entry deliberately thin on specifics. There is no vendor, no product, no method and no steps to reproduce, because the finding was disclosed privately and publishing a recipe helps no one. What I am comfortable showing is the shape of the work: building instruments to read a protocol nobody handed me, and reasoning about where a real product's trust model breaks. The value is in the analysis and the discipline around it, not in any exploit, and framing it as research rather than a trophy is a deliberate choice.
The hardest problem
The hardest part was reading a protocol that came with no documentation, using hardware I had built myself, and then reasoning clearly about where its security actually broke. Anyone can point a tool at a system and watch bytes go by. The skill was turning those raw exchanges into an accurate mental model: which messages carried authorisation weight, what the product assumed to be trustworthy, and where those assumptions did not hold. It would have been easy to chase the cryptography, which was the wrong thread. The real flaw was a logic one, a case of trusting state that should never have been treated as authoritative, and the difficulty was seeing that distinction and describing it precisely rather than reaching for an exploit. Keeping the work at the level of analysis, and stopping there, was part of the challenge.
Start a project
Want something built like this?
Everything on this page was designed, built and hosted by one person. Tell me what you need and I reply with scope, cost and timeline, usually within two working days.