PROBLEM: The current cloner sucks. It corrupts xEM tags if the coupling isn’t perfect and the only way to recover them is to use a proxmark iii and issue command;
lf t55xx write b 0 d 00148041 p 51243648
The “p 51243648” specifies the password set by the cloner. If the xEM was never properly written to by the cloner, then this password will not be set and won’t be necessary to communicate.
SOLUTION: Make our own reader/writer/cloner that doesn’t eff up your xEM tag and allows you much greater control over your ATA5577 chip based xEM tag. It can function as a standalone cloner as well as a connected reader/writer and “tag manager” device. Perhaps store multiple tag IDs and select them via pushbutton to write those IDs to the xEM at will. Emulation is not an intended goal for this project.
MVP
Scope : Read/Write data to/from ATA5577 chip.
Use : Early developer access.
Hardware : Prefab, little to no EE required.
Software : Core library with one spec/device specific module.
v1
Scope : Full data and feature management of ATA5577 chip (read/write/clone)
Use : Arduino shield design / Retail board
Hardware : Ideally MVP compatible, no EE required.
Software : Stable library + full suite of spec/device modules.
Nate, Malcolm, and I worked on recovering a corrupted ATA5577 implant chip this weekend.
Before corrupting another ATA5577 implant chip, we decided to perform a good clone with the xEM cloner, then write a new ID with the Proxmark III using the xEM cloner password. We were able to rewrite a cloned keyfob using block level 5577 writes, but were unable to use the same procedure to rewrite an ATA5577 implant chip.
I will post a more detailed write-up of our session in the next day along with the command output from the Proxmark III.
Hmm, not cool. There is a possibility that the cloner attempts to re-write the password as well (very likely) and if bit corruption occurs during writing of these blocks, then the password may be different on the chip than it’s supposed to be. I don’t think the ATA5577 has tear protection, so a bit error in transit or loss of power during write could produce this behavior. I know others have been able to recover corrupted xEM implants with the PMIII but it may have been because their tags did not have password corruption.
So if the password is possibly corrupted by bit error, maybe it would make sense to do a quick test of write with passwords generated by flipping one bit at a time in the bit pattern of 51243648? It’s only 32 attempts.
Agreed… that’d be interesting. I think the first challenge is to get working hardware. You could try it manually with a proxmark iii i suppose, but - ick -
I’ve forked proxmark3 on github and added a command to do the bitflipping so there’s no need to do it by hand Then again, I don’t have a corrupt chip and I’m not too keen on breaking the one I have to test this…
Speaking of trying password permutations, while testing the code on my proxmark3, it was sitting on top of a stack of cards that presumably were not ATA5577, yet I got a password hit for the cloner password with one bit flipped. Turns out a HID Prox II card I presumed genuine was a T5577 inside, pretending to be HID, matching markings on the outside. Hooray for code working, I guess?
Proxmark3 non-withstanding, here are a few place this project can start @ http://www.proxclone.com/T55x7.html - reader/writer circuit and some other useful bits related to cloning RFID tags
I looked inside of the Chinese cloner you sell and it looks like it has a C8051F300 microcontroller inside - that could be a good starting point as well - devkit is fairly cheap - https://www.silabs.com/products/mcu/Pages/C8051F300DK.aspx - and could probably be used to dump the contents of the cloner and reverse engineer it.
As it stands, the EM4100 cloner is good enough for most types of tags. However, the current coil layout is not very good for smaller tags or implants. I am also not terribly sure what is involved with xEM communication. I do know that the PIC on there may be a little anemic for some operations. The schematic as it is should be able to do both read and write operations, but it is only set up to read and replay a tag, rather than write to them. I do have some code that I wrote previously to communicate with an EM4150 read/write tag, but it was never implemented for the final product.
The most pain in the ass part is the analog front end. If your project is only using read/write, and not having to replay as a tag, then you can probably find something off the shelf with minimal external passives required. If you want to make it a single PCB like the cloner I put together, then you would want a 4, or even more layer board to get more turns of the coil to impart more energy. If you are putting it in a case, then I would suggest using an off the shelf pre-made coil spool as you would probably get a better Q out of that and therefore more energy imparted.
The ATA5577 chip is programmed by an odd trick of signal timing. If there are bit errors due to poor field coupling, then it could corrupt any part of the programming sequence performed by the cloner. I don’t think the ATA5577 has any CRC or page tear protection, so these bit errors are just transcribed to the chip which could leave it in an unusable state.
There seems to be a problem with the multiple ways the cloner can “corrupt” the xEM. The ATA5577 chip can be configured to change its analog modulation as well as the digital data it contains. If the cloner accidentally corrupts the analog configuration or the password setting, then the approach to fix it will be different… if it is still at all possible to fix.
This is why we need people working on the problem.
Does anyone know if this is an issue only affecting the hand-held reader/writers or is this an inherent issue with the concept of errors (i.e. due to range/drop-out) occurring during the write leading to bit errors in the password and hence no further access allowed since the password won’t match?
I’m about to get a xEM implant in the UK and really want to clone the ID from a tag I already have. I was looking at getting a read/write device (again Chinese, but slightly more expensive than the hand-helds) for example http://amzn.eu/5eY87fl
Related I just watched a webinar about NFC tags which implies there is a ‘clean’ function effectively doing a low-level format, which can recover corrupted tags where the comms dropped mid-write. I assume there’s nothing similar with the XEM 125kHz tags.
It’s not completely understood just yet, but there are similar issues with multiple cloner models on many types of ATA5577 chip based cards. I’m fairly certain though that the problem has to do with the lack of “tearing protection” in the ATA5577. This means if programming memory pages is interrupted for any reason, the result will be corrupted. In the case of using the handheld cloner with the xEM, the coupling is not that good and writing data requires spikes in power, so if data is being written and the power requirement of the write operation exceeds that being supplied by the field, a reset will occur and the state of those memory blocks being written will be left in an unknown/unconfirmed state.
Other chips, particularly NXP’s like of Mifare and NTAG chips, do support tearing protection on critical memory blocks… not all blocks, like user memory blocks, but critical blocks like OTP, lock byte, and configuration blocks.
There is no “clean” command or any way to “low level” format a chip. That is a figment of Android app developers. If you bork lock bytes or config blocks on an NFC chip, it’s bricked for life. That’s why we developed the Dangerous NFC app to disable lock bytes and protect config blocks from accidental (or malicious) attack.
I have an xEM that is apparently bricked. From reading posts here I’m guessing I’ll have to purchase this Proxmark3 device and learn how to use it or just walk around with a useless piece of glass in my hand. I did a search and found a few devices using that name. Will any of them suffice? I saw several from China, do you know if these are reliable? Is there software involved? Any help would be appreciated.
Then again, I don’t have a corrupt chip and I’m not too keen on breaking the one I have to test this…