Our xEM is based on the T5577 chip… a very versatile 125kHz RFID chip that can be programmed to emulate many different types of common, unsecured 125kHz chip types, including EM, HID 1326 (ProxCard II), Indala, AWIA, etc. and even has password protection functions to block reconfiguration by accident or malicious attack.
At one point we sold a cloning device that could read both EM and HID 1326 tags and clone those into the xEM. The problem was, some people started to report that after trying to clone some cards, their xEM was unresponsive. We soon found that in certain cases, the cloner was leaving people’s xEMs “bricked”. We stopped selling the cloner, and after further investigation, we found out this is a symptom of bad coupling with any T5577 based RFID tag. In short, it was not the cloner’s code or what it was doing that was the problem… the problem was that the antenna coil inside the cloner was designed to work with cards and keyfobs, not small cylindrical tags like the xEM. The cloner was not magnetically coupling well with the xEM, and because passive RFID systems use this magnetic field to send both power and data over the coupling, there was a significant chance that the T5577 chips inside these xEMs were being corrupted. The point here is that any attempt to write to the T5577 chip inside the xEM by any device, cloner, or diagnostic tool could result in a “bricked” state if the antenna is not coupling well with the xEM.
We turned to the defacto standard RFID hacking tool, the Proxmark3, to see if we could not only diagnose the problem, but also recover / restore any of these “bricked” xEMs. The news there was not good either, but mostly because so many people who attempted to use this expensive diagnostic tool quickly found that its standard “factory” 125kHz antenna was also ill suited to the task of talking to the small, cylindrical xEM tag.
Bad inductive coupling
(i.e. It was’t the cloner’s fault)
There are two main problems with bad coupling. The first and most obvious is that data errors could insert themselves into the data stream. This can be due to noise or other factors that flip some 0 bits into 1 bits and vice versa in transit between tag and reader. In some cases, transport checks like CRC or parity checks are done to help identify these errors and reject the data packet, but not in all cases, and especially not within most simple cheap proximity RFID chips.
The other issue is power availability. An RFID chip is a tiny simple computer. It must be able to read data from memory and process that data in such a way that it can then influence the RF analog circuity so said data is communicated to the reader faithfully. Doing that job requires power. As soon as a tag is put into a reader’s field, it will attempt to induct enough power from that field to do its job. Once there is a good enough coupling that can supply enough power and data bandwidth for the tag to power up and communicate its ID number, the tag will do so and you will get a good read. The problem comes when the coupling is just barely good enough to do this job, then we task the RFID chip with writing new data. Writing data to memory requires more power than simply reading it, so while an RFID chip may have enough energy from the coupling to power up and communicate, once you ask it to write, the power requirement surpasses power availability, and you get a chip reset… likely during mid-write. This is called a “tear event”. Because we are dealing with two separate objects exchanging power and data OTA or “over the air”, simple things like moving the tag half a millimeter can also alter the magnetic coupling enough to reduce power and cause a tear event.
Tear protection
A pretty significant quirk with the T5577 is that it does not support “tear protection”. When data is written to memory - any kind of memory - be it a hard drive, a USB stick, or an RFID tag… how do you ensure the data you are writing is complete and correct? What if the power goes out midway through the write process? The data will be not be recorded properly, that’s for sure… but what about your storage medium? What if you are making changes to how the storage medium operates when the write fails? Will you be able to recover and try writing again? Tear protection ensures that data written to a memory block is complete and correct, even if the write fails half-way through. In the case of NXP’s Mifare Ultralight RFID chips, it provides tear protection for certain critical memory pages by using a double-store-compare technique.
As you can imagine, doing this is expensive, so only critical memory pages are “tear protected”. In the case of the T5577 though, none of the memory pages support tear protection. This leaves some very critical memory pages vulnerable to data corruption, which could leave your xEM unresponsive and possibly unrecoverable.
Analog configuration
The ID number that the T5577 reports to a reader is stored in writable memory blocks, so you can put any binary data you want into those memory blocks and it will faithfully spit it out when a reader asks for it… but when it comes to 125kHz proximity cards, there are many different data encoding and analog modulation types which are not compatible with each other. The T5577 is so versatile it can change its analog RF behavior to support a plethora of encodings and modulations. To change its configuration, you must write some data in a specific memory block within the T5577. Because there is no tear protection, writing corrupted data to the analog configuration memory bytes could result in an xEM that is physically incapable of communicating. In this case, the xEM is very likely “bricked” and unrecoverable. The only possibility would be to use a Proxmark3 and fiddle with different analog variants to try to regain communication with your xEM.
Password corruption
Another feature the T5577 supports is password protection, which makes sense if you have a chip that can be written to… you might want to be able to protect the chip against malicious or accidental changes. The problem arises when a tear event happens and corrupted data is written to the password block. Now there is no way to know what the password actually is. This situation would result in a “read only” xEM… not entirely useless, but not ideal. The only possible way to attempt a fix would be to figure out a method to attempt a brute force attack on the xEM and try every combination of every password possibility… not something that is quick or easy, especially if the xEM is implanted.
What do we do now?
It seems that the Proxmark is the tool of choice when it comes to fiddling with RFID tags and systems, and anyone with an implant looking to clone tags to their xEM should probably get familiar with it… so the low hanging fruit at this point is solving the LF antenna design problem. This is a prototype we created that works much better than the factory standard antenna with our xEM.
Production
With a good antenna for the Proxmark3, it may be possible to recover some bricked xEMs. We plan on producing a run of Proxmark3 LF antennas soon and we’ll update this page when they are available.