RF-LAB: a web UI for physical pentesting hardware

Most offices still open their doors with a card. You tap a badge on a reader, the reader checks an identifier, and the door unlocks. That small exchange is a radio conversation, and for my BSc thesis at the University of Debrecen I built a tool around it: RF-LAB, a web app UI for hardware-based physical penetration testing tools.

This post walks through the problem, what I built, and what I’d do differently today. The thesis itself is public in the university repository.

The problem with RFID access control

RFID (radio-frequency identification) is everywhere in physical access control: office badges, hotel keys, parking gates. It’s convenient, and that convenience is exactly where the risk sits.

• The card talks to anyone who asks. A reader powers the card over the air and the card answers. A reader in an attacker’s bag can ask the same question.
• Many deployed cards carry little or no real protection. Older low-frequency proximity cards often transmit a fixed identifier. If you can read it, you can usually replay it.
• The privacy side matters too. A badge that answers any reader can also be used to track where its owner goes.

None of this is new to security people. What’s often missing is a way to show an organisation, concretely and safely, what that means for their doors.

Why physical pentesters need a shared tool

A physical penetration test answers a simple question: can someone who shouldn’t be inside get inside? Testers work as a team, and during an engagement they may capture and clone credentials such as badges and cards to prove a point.

That creates a problem of its own. Cloned credentials are sensitive material. If they end up on one person’s laptop, in a chat thread or on an unlabelled card in a jacket pocket, the test itself becomes a risk to the client. The team needs to know:

• which credentials were captured, and where;
• which rooms and doors they were tested against;
• who on the team can use them, and through which device.

RF-LAB’s goal was to give a team one place to share and manage those credentials safely, instead of passing hardware and files around.

The hardware

RF-LAB is a UI for three pieces of hardware that are well known in RFID research:

• Proxmark3 RDV: a general-purpose RFID research tool that can read, analyse and emulate many card types.
• Chameleon Mini: a compact card emulator, handy for testing a captured credential against a reader.
• Raspberry Pi 3 B+: the small computer that connects to the tools and hosts the app.

Each of these tools is powerful on its own, but they’re driven from the command line, one person at a time. That’s fine in a lab. It’s awkward in the middle of an engagement, when several people need the same information.

What I built

RF-LAB is a Flask web app that acts as the interface for the hardware. The main ideas in the app are simple:

• Rooms: the physical places being tested.
• Cards: the credentials the team works with.
• An admin panel: to manage the team’s access to all of the above.

The front end uses Tailwind CSS, and the data lives in SQLite or PostgreSQL.

The design choice that mattered most was putting the web app in front of the hardware. Testers work through a browser, and the sensitive material stays in one managed place instead of on everyone’s devices.

Lessons learned

Looking back a few years later, a few lessons stand out.

Security tools need security too

A tool that manages cloned credentials is a high-value target. Access control, auditing and a clear data lifecycle (what gets deleted when the engagement ends?) matter as much as the RFID features. Today I’d start from that threat model, before writing the first route.

Hardware is the slow part

Web code is quick to change, and hardware isn’t. Firmware versions, drivers and timing all vary, so the boundary between the app and the device needs to be small and well defined. Keeping each tool behind a narrow interface keeps the rest of the app easy to reason about.

Make the risk visible

The most useful output of a physical test isn’t the cloned card; it’s the explanation. A tool that records which doors were tested and what worked makes the report clearer, and that’s what helps the client fix things.

Testing responsibly

Physical penetration testing only happens with written authorisation and an agreed scope. Reading or cloning someone else’s credential without permission is illegal in most places, and it’s not what this work is about. RF-LAB was built for authorised teams, to make their work safer for the people they test.

Read the thesis

The full thesis, RF-LAB (Web App UI for Hardware-based Physical Pen. testing tools), supervised by Dr. Adamkó Attila, is available in the University of Debrecen repository.