ICopy-X: Open-Sourced by Lab401

Previously, we flew to China and told you we needed to talk about the iCopy-X. The device hadn't received a real update in three years. The original team was responsive but couldn't release the source code. 

Six months later, we decided to take matters into our hands - we rebuilt the iCopy-X firmware from scratch : UI, logic, middleware, plugin system - and released it as iCopy-X Open under Lab401 GitHub repository.

Installation is a breeze: place the IPK on your device and install. It comes in two versions, fully open source, compatible with both legacy factory hardware and modern Iceman firmware.

We sat down with Lab401's quantum-x to talk about how it actually got built, what it cost, and - honestly - how many times he thought the project was going to collapse in the last ten metres.

▶ Watch the full release video: 

The quantum-x Interview (audio)

The interview

Sandy: Hi, I'm Sandy from LAB401.com. Today I'm sitting down with quantum-x, the man behind the iCopy-X Open. Who are you, and what are you doing exactly?

quantum-x: I go by the handle quantum-x. I'm a founder and the technical side of LAB401.

Sandy: And what are you doing exactly at LAB401?

quantum-x: Typically I'm handling product development, product manufacturing, and the tech stack of the operations - everything that's back-end, back office, that type of thing.

Sandy: Let's talk about the project - the iCopy-X Open. LAB401 had a plan. It was supposed to be a collaboration with the iCopy-X team. So what happened?

quantum-x: We sat down with the original project owners to understand if it would be possible to open source the original product. Talks were interesting. They wanted to get feedback from the community to understand if it was really something that was important to them, which was why we built up the videos. However, that didn't translate into the code being released, so we explored other options. We discussed opening up a fee to try to sponsor the code being written.

The reality is that there was a confluence of a few factors that came together. I had some spare time. It was becoming clear that the source code wasn't going to be released by the original team, or they weren't able to release the code. Throughout the month of April, Anthropic was running a double context promotion for the Opus 4.6 model. So that was a unique opportunity to throw some new tools at the product and take an entirely new approach - leverage the AI plus our knowledge of the system to build something from scratch.

One fairly intense month. I'd say there's probably about 350 to 400 hours sunk into the project. If you do the math, I was working 10 to 18 hours per day for one month solid.

The decision of how far to push, how much perfection to look for, how ready the product should be before releasing - that's a difficult question to answer. It's always a sliding scale. I wanted to deliver a product that was more than a proof of concept. I wanted users to be able to do something useful. Let's be clear: there have already been proof of concept applications that run on the iCopy-X, but none of them tried to create an open source version or replicate the functionality.

I had some clear goals. I wanted users to be able to install one IPK. I wanted there to be a universal IPK - I didn't want the obligation to download a specifically-built IPK for a given serial number. I wanted it to be a drop-in replacement, so users would be able to continue to use the device. They wouldn't have to find themselves in a situation where they need to go back to stock firmware for the functionality, then come into the open source version, play around with it, but can't do anything useful. I needed and wanted it to be functional. And I wanted it to be stable.

The problem with that is you need extensive testing, and that means you need hundreds of types of badges - which, being on the technical side of LAB401, we do have. However, there are always going to be some gaps. Essentially, the metric for when release was ready was when I could perform all of the installation processes and all of the flows - read, write, auto copy, scanning, diagnosis - over and over without crashes, without bugs. I knew that when we released it, we weren't putting the user's system in danger, and they were going to have an out-of-box experience that was the same or better than the closed source version.

Sandy: So I have a question about what does LAB401 get out of this actually, and what don't they get?

quantum-x: LAB401 has visibility. It has a platform that's important to use for this project. It could have been released anonymously, or under my personal repository. Why was it released under LAB401? I believe that LAB401 has a moral obligation and a professional obligation to the customers of the iCopy-X.

The iCopy-X was sold as a device that would be continuously updated and maintained. We marketed and sold it as a product that would receive maintenance and updates. And so three, four years on, with no more updates, we found ourselves professionally in a strange or awkward situation where we felt the products we'd sold were not living up to the promises we'd made.

It was also a somewhat strange situation because we have a really well-built, well-designed, well-executed product. We have to be very clear: the iCopy-X is a really, really nice product in terms of hardware, architecture, and software. The original team did an excellent job. But it was becoming very difficult to justify a sale of this product to pentesters.

Pentesters are not locksmiths. Pentesters are not cloners. Pentesters have specific use cases for this type of product. They need to be able to make a modification. They need to have the latest possible repository or any specific code that they want to run on the device, so it adapts to their daily life - it adapts to the evolving surface of RFID penetration.

It became this very strange situation where in our hands we had a physical device that was a very useful tool for pentesters, but the software was holding it back. What does LAB401 get out of this? By making this software open source, it allows us to finish the transaction that we promised. It's a delivery of the promise that we made when customers put trust in LAB401 to make that purchase.

Sandy: Are there any plans to do the same kind of thing with other products?

quantum-x: To be honest, no, for multiple reasons. But at the same time, we didn't plan - I didn't plan - for this to happen for the iCopy-X either. Until 90% of the way along the product development, I was not sure if we were actually going to be able to deliver it.

Sandy: Okay.

quantum-x: The complexity of this project is that it's actually about six projects in one. The first is the notion of "is a proof of concept possible?" It took multiple hours and multiple iterations to say, "Can we actually install an IPK on this?" Okay, yes, we can install a custom IPK - but we're getting stuck in the jail, so now we have to make a jailbreak. Once we proved that we could make a jailbreak and install our own code onto the system, then it was a question of: okay, can we make a UI? Yes, we can make a UI. Okay.

The real challenge for this product, once all the proof of concept is out of the way, is the logic. This entire machine is basically a gigantic logic tree. If you place a certain type of card and it has a certain type of key or a certain type of behavior, then that goes into a branch. There are literally thousands and thousands of branches and nodes that are possible.

The real challenge was: are we able to get 100% - or as close to 100% - coverage of the original functionality? Let's be clear: the device is not only closed source, it's compiled. Sure, you could decompile, but you're not decompiling to source code - you decompile to machine code, which is essentially useless. I took one or two different approaches at trying to understand how to attack the problem, and each time it felt very much like walking a tightrope - trying to find this line between the start of the task and the end of the task. There were some very tight passages, and at multiple instances I didn't believe the project was actually going to work.

Sandy: So how did you actually set this up? What gear are you running?

quantum-x: The setup is very simple. As I said, I decided I was going to lean on Claude - the Opus 4.6 one million token context model - for some of the heavy lifting. But to be very clear, in a project of this scale, you burn through context very quickly, so you can't rely on the AI system to intuit the project management. I was able to use the 4.6 Claude models for some of the iterative work - like building tests and then building out some of the mechanical code. But the actual project management was very much a human job to get this across the line.

One of the most challenging parts of this project was working out the correct approach to take. You've got this logic tree, and you have to understand how to give full coverage. If you give 50% coverage of the original functionality, it just means the device is going to be broken 50% of the time. For 50% of the badges you put on it, you're going to break them - you're not going to write them properly, or you're not going to detect them. So the challenge is that you need to get 100%, or as close to 100% functionality and coverage as possible.

After iterating multiple times, the logical approach - at least for me - is TDD, or test-driven design. TDD is a programming technique where the most important thing is to build tests first. In standard design, you build code, write tests, ensure that your code matches the tests, then iterate from there. Test-driven design puts your tests at the front. The first thing you write is tests.

The iCopy-X, in terms of a project or a product, has very clearly defined inputs and very clearly defined outputs. If you apply TDD to real-world terms, it's something like: I have one dollar in my hand and I want to buy an egg. The input is that I want to buy an egg and I have one dollar, and the output is going to be me walking away with an egg. If I define my test like this - the input is my desire to have an egg and the fact that I have money, and the output is an egg - I can go into a shop, give the guy a dollar, and ask for an egg. What happens in between is kind of irrelevant. Maybe the guy has a chicken, maybe he has some eggs under the counter, maybe he has to go to a farm, run away, take an hour, come back, and give me an egg. It doesn't really matter as long as the output I've defined is fulfilled. I wanted an egg, now I have an egg. When you refine the definitions more - maybe I want an organic egg - the guy has to go to an organic farm, and at the end, I get an organic egg.

If you extrapolate this to the iCopy-X, we have very well-defined sequences with the Proxmark. We can sit and look at the data that flows to the Proxmark. We know what the Proxmark source code is, and we also know what output the Proxmark makes. Based on that, and knowing the types of badges that the device supports, I was able to determine fixtures, so we'd be able to provoke every single possible logical path.

Essentially, you're working backwards and forwards at the same time. You're saying, "I know what the outputs are that I want, so in order to provoke those outputs, I'm going to have to generate certain inputs. I can use the Proxmark layer in the middle to build the data sequences that will provoke those outputs."

Once that was done - that was the first major challenge: mapping this out. I had to build the logic tree. Once the logic tree was made, it was a question of applying an open source UI map over the top of the product - still using the original product firmware, but putting my own open source interface on it - and then running that through the testing system. When I was able to prove that the UI was matching the original functionality, I was able to go through and start implementing module by module, flow by flow, the actual middleware functionality. Scanning a tag and iterating against the tests until we came out with a result where it passed.

There were multiple layers to the project. This was just one of them. Once we got to the end of that, there was the other layer of: how do we get compatibility with the Iceman firmware? Can we get the Iceman firmware compiling? Yes, there's built-in community support for that - but there are multiple hardware iterations of the iCopy-X. Are they still compatible? No one knows. No one's looked at it for six or seven years. And then, the small victory: yes, okay, we can compile Iceman source for the iCopy-X. But you've just created another problem, because between the Iceman source and the iCopy-X source there's a five- or six-year gap. So all of the code and everything that was put in place now has to be rewritten to make compatibility between the old and the new.

For this reason, every single step of the way, there was very much a possibility that by making progress, you'd end up in a situation where you couldn't deliver the product.

Fortunately, we're in a situation where the firmware that's been open sourced is compatible with the legacy device - let's say the factory device, or the factory-flashed Proxmark module. It's also compatible with the Iceman up-to-date source code, and you're also able to flash the Proxmark module inside the iCopy-X to bring it up to modern Iceman.

Sandy: That's a little miracle then, that it's there like that.

quantum-x: One of the core pieces of tech for this project was QEMU. The ability to completely emulate and mock the iCopy-X device allowed us to build up comprehensive testing - what I call flows with scenarios, but essentially testing suites. For each flow - scan, read, auto copy, write, that type of flow - there were literally hundreds, up to thousands, of scenarios. For example, for a scan: is it a MIFARE? Is it a MIFARE 1K? Is it a MIFARE 1K 4-byte? For every logic tree, down to the node, I built out testing scenarios that were then emulated against the real device in emulation. Without that, it would have been a case of working on the real device and trying to build it one by one iteratively, which would have been unfeasible or impossible.

In the end, we ended up with thousands of tests in the testing suite. So many that actually executing the test suite was taking a very long time. One of the key pieces of hardware I had to deploy was a 48-core, 96GB server that was just running QEMU tests. It could crunch them in parallel and get the testing suite done within about one hour end-to-end. Without that piece of hardware, it was taking half a day to run a testing suite, which meant it was going to be impossible to iterate quickly enough.

Sandy: How much did it cost? (chuckles) Between the tokens, the hardware, and the time you spent - how much did it cost?

quantum-x: The most costly element - but also the hardest element to define - is time. Again, it was about 350 to 400 hours over about a month. It was a large time sink. In terms of real-world costs, it was maybe 400 euros worth of Claude 20x Max subscriptions. There was the QEMU server, which was expensive - about 400 euros a month. So in terms of money out of pocket, there was probably about 1,000 euros placed into the project.

That's a lot of money in one regard, but if you compare that to a traditional software development process of four or five years ago, pre-AI, getting a development team to do this project would have cost a lot more than 1,000 euros. So it's an interesting exercise to see how AI today can be used - and its shortcomings, because there are definitely shortcomings. On some days, I was burning through the weekly allowance in two hours, which is why we needed to have multiple accounts. Even in some complicated flows, like a read flow or a scan flow, you'd saturate the million token context very quickly, so you'd have to hand off to multiple agents multiple times over one flow. Every time, there's this sort of loss and you end up going round and round in circles.

I would say that this type of task would have been impossible - or improbable, and therefore no one would do it, so impossible - pre-AI, and even maybe pre-six months ago, when we had smaller context windows.

Sandy: What's the single hardest bug you fixed during those 350, 400 hours?

quantum-x: There were two or three times I got stuck on really difficult bugs, and to be honest, I think I have a sense of trauma over this product, so I've already been trying to forget them.

One of the things I did was keep a chronicle of the entire build process from start to finish. It's an AI-written document. It's hundreds and hundreds of pages, but I thought it was really important to keep a highly technical document of all the techniques we used. If some of the viewers are interested, it's in the repo - go into the docs directory and open up the chronicle document, and you'll see there are two or three days where they're spent just going round and round in circles on what should be a very simple problem but was very, very difficult.

Sandy: Okay, let's talk about Doom. So - Doom, on the iCopy-X.

quantum-x: As everybody who's a geek understands, getting Doom on a product is a sign that you've jailbroken it, or you've got a working jailbreak, or that it's open source. But Doom on this device - it's a Linux device, and everybody knows you can run Doom on Linux. Anyone can SSH into this device and run Doom. That wasn't the challenge.

The reason I wanted to install Doom on this device was because I wanted to have a plugin architecture. The iCopy-X software is really, really complicated, and often complicated software means it's harder for developers to either make contributions or make the modifications they need for themselves. One of the things I wanted to address with the open source version was to have a very clearly-defined UI system, and an easy-to-use plugin framework. The UI is all defined in JSON, so you can quite easily go in and modify the flows and the UI via JSON. Likewise, the plugin system is based on JSON.

I wanted users to be able to quickly build two or three types of plugins: a plugin where you can speak with the system, a plugin where you can speak with the Proxmark module easily and iterate off the replies from the Proxmark, and a plugin architecture that allows you to run full-screen native binaries.

The obvious choice for that was Doom. It's a fairly complex flow - you're using FGL, you're using full screen - but at the same time, you have to run that in the safe environment of the iCopy-X. So some things like buttons need to be mapped to Doom, but also mapped back to the iCopy-X. I figured Doom was a really interesting plugin to include on the product. And at the same time, it's Doom. You can't make an open source product without having Doom in it.

Sandy: Another thing that's really amazing: the graphics you've implemented with the credits.

quantum-x: Well, don't go and spoil everything. It's a very poorly hidden Easter egg.

To be fair, I assigned myself side quests while building the device to keep sane - because running hundreds and hundreds and thousands of tests was not only difficult but also quite boring. To keep up motivation, I tried to define a couple of side quests. Doom was one of the milestones I wanted to hit. I wanted to have Doom running in a specific situation. I also wanted to have some type of love letter to the community and to the geeks.

If you grew up in the era of the demo scene and scrollers, you'll recognize this format instantly. You'll recognize this notion of old-school keygens and cracks where you'd have greets. These things would be fascinating to watch, but they'd also mean nothing to you, because they're just listing random names. Because this is what I would consider an almost personal device to the community - everyone in the pentesting community knows this device - I wanted to give a little bit of something back. So there are some greets and thanks to people who were important to this project, who helped bring it across the line.

There's an acknowledgement to the original team, because without them this product wouldn't exist. The work the original team did - in terms of hardware, software, product management, and belief in a project to invest enough to make it happen - it can't be overstated.

And obviously, there are all of the Proxmark co-contributors, whether they've made one contribution or 11,000 contributions, as Iceman has made. It's really important to give recognition to everyone involved.

Sandy: Before I leave you - anything you want to add?

quantum-x: I think it's important to discuss what the future of this project is going to be. My goal was to deliver an end-to-end functional, reliable, open source system for the iCopy-X, and I believe that's done. However, I don't have plans to maintain and update this project. That's out of scope for us. I don't have any experience in running and maintaining open source projects, and that's a real skill.

I've spoken to some of the usual suspects in the community, and hopefully we'll see some of these guys coming on board and becoming administrators on the project. What's really important - and what I'd really hope for - is that if people see value in this project, they consider cloning it, installing it, contributing, and maintaining or assisting to maintain this code base.

Sandy: Well, thank you for doing this. I'm Sandy from LAB401.com. Take care, and see you next time.

Before vs after: what actually changes for your iCopy-X

Before iCopy-X Open

The iCopy-X you bought between 2021 and March 2026 was a closed-source device frozen at its 2022 firmware. You had:

• A solid auto-copy flow for the vast majority of LF and HF tags
• An embedded Proxmark client you could drop into via USB-C for advanced work
• LUA scripting - the last feature added, via a 2022 Lab401/iCopy-X collab
• No plugin system - if you wanted to add a flow, fork an attack, or integrate a new tag type, the answer was "no"
• DRM: Blanks had DRM - you were forced to use iCopy-X blanks
• No way to update the Proxmark firmware inside the device to modern Iceman
• No compatibility with six years of upstream Proxmark improvements: newer nested/hardnested implementations, FM11RF08S static-encrypted-nonce attacks, updated standalone modes, the current Iceman CLI The hardware was fine. The hardware is still fine. The software was the bottleneck.

After iCopy-X Open

• One universal IPK - drop-in install, no serial-number-specific build required, no flashing risk
• Full source code on GitHub under the LAB401 repo - UI, flows, middleware, plugin framework
• No DRM - use whichever blanks you want. 
• JSON-driven UI - change labels, flows, or navigation without recompiling anything
• JSON-driven plugin system - three plugin types out of the box: talk to the system, talk to the Proxmark, or run a full-screen native binary
• Modern Iceman proxmark firmware - the iCopy-X gets the last six years of RFID research dropped into its chest cavity
• Easy install / uninstall - still fully compatible with factory firmware and factory-flashed Proxmark, so you're not committing to anything permanent
• Community-maintainable - if the community picks it up (and that's the hope), bugs get fixed and features get added by the people who actually use the device And yes, Doom runs on it. As it should.

How does this compare to a Proxmark 3 RDV4?

This is the question most of you will actually be asking, so let's answer it directly.

The Proxmark 3 RDV4 is the reference - the Iceman-maintained, tethered, bare-metal RFID research platform. It's what every serious RFID researcher has on their desk. The tradeoff has always been:

The practical version: for a comparable investment, you're now getting a Proxmark 3 with EZ-mode auto-copy, an integrated screen and battery, AND the Iceman fork - in a single field-ready device. That combination didn't exist a month ago.

If you already own an iCopy-X, iCopy-X Open turns it into that device for free.

If you're choosing between platforms today: the RDV4 is still the better choice if you live in the CLI and want maximum flexibility on your desk. The iCopy-X with Open firmware is the better choice if you need to work in the field, want the screen and auto-copy flow, and don't want to give up modern Iceman features to get them.

For most pentesters doing client site work, that second option is the one you've been waiting for.

What's next

To be clear about scope: our goal was to open-source  the iCopy-X, not to be the permanent guardians of the project. The iCopy-X is a very complex product; it needs real open source maintainers.

Today, will we consider it to be feature complete, there are definitely bugs and definitely improvements to make.

If you see value in this project:

• Clone it. The repo is on https://github.com/lab-401/icopy-x
• Install it on your iCopy-X. Drop-in, reversible, no risk to your existing firmware.
• Contribute. Badge compatibility, new flows, plugin examples - the framework is there.
• Help maintain it. If you've run an open source project before and this is a device you use, get in touch. Huge shoutout to the original iCopy-X team for building the hardware this is running on, and to Iceman and the RRG/Proxmark contributors whose work we're now able to bring onto the device directly. Without either, there's no iCopy-X Open.

Get the iCopy-X

• iCopy-XS - €375 and up
• iCopy-X Tag Packs