I’ve had my xEM implanted for several months now, and haven’t actually done anything with it till now. I’ve been able to read it ok all this time (it reads with a Halo scanner), it has the serial number that I assume was programmed when it was tested at DT prior to packaging.
I’m finally starting to work with my Proxmark3 and I’m getting some really strange results with the xEM. It won’t respond to the wipe command, I’ve tried following TomHarkness’s directions for resetting it and that doesn’t work either, and I’m just basically confused what’s going on.
Running the proxmark lf search finds it consistantly and displays the same Tag Id that I get when reading it with the Halo. But the lf t5xx detect command shows a strange config blog, trace doesn’t work at all, and dump just repeats a lot of the same data over and over. And the info command says that password mode is set but I’ve never written to this chip before trying the wipe command today.
Here’s the results from the proxmark3 search, detect, trace, info, dump:
pm3 --> lf search
Reading 30000 bytes from device memory
Data fetched
Samples @ 8 bits/smpl, decimation 1:1
NOTE: some demods output possible binary
if it finds something that looks like a tag
False Positives ARE possible
Checking for known tags:
EM410x pattern found:
EM TAG ID : 2015061049
Unique TAG ID : 04A8600892
Possible de-scramble patterns
HoneyWell IdentKey {
DEZ 8 : 00397385
DEZ 10 : 0352718921
DEZ 5.5 : 05382.04169
DEZ 3.5A : 032.04169
DEZ 3.5B : 021.04169
DEZ 3.5C : 006.04169
DEZ 14/IK2 : 00137791672393
DEZ 15/IK3 : 000020004735122
DEZ 20/ZK : 00041008060000080902
}
Other : 04169_006_00397385
Pattern Paxton : 538594889 [0x201A4E49]
Pattern 1 : 608000 [0x94700]
Pattern Sebury : 4169 6 397385 [0x1049 0x6 0x61049]
Valid EM410x ID Found!
pm3 --> lf t5 detect
Chip Type : T55x7
Modulation : BIPHASEa - (CDP)
Bit Rate : 5 - RF/64
Inverted : Yes
Offset : 60
Seq. Term. : No
Block0 : 0x201780BE
pm3 --> lf t5 trace
The modulation is most likely wrong since the ACL is not 0xE0.
pm3 --> lf t5 info
Offset+32 ==92
DemodLen == 118
-- T55x7 Configuration & Tag Information --------------------
-------------------------------------------------------------
Safer key : 2
reserved : 0
Data bit rate : 5 - RF/64
eXtended mode : Yes - Warning
Modulation : 24 - Biphase a - AKA Conditional Dephase Encoding(CDP)
PSK clock frequency : 0
AOR - Answer on Request : No
OTP - One Time Pad : No
Max block : 5
Password mode : Yes
Sequence Start Terminator : Yes
Fast Write : Yes
Inverse data : Yes
POR-Delay : No
-------------------------------------------------------------
Raw Data - Page 0
Block 0 : 0x201780BE 00100000000101111000000010111110
-------------------------------------------------------------
pm3 --> lf t5 dump
Reading Page 0:
blk | hex data | binary | ascii
----+----------+----------------------------------+-------
00 | 201780BE | 00100000000101111000000010111110 | ...
01 | 201780BE | 00100000000101111000000010111110 | ...
02 | 201780BE | 00100000000101111000000010111110 | ...
03 | 4805E02F | 01001000000001011110000000101111 | H../
04 | 201780BE | 00100000000101111000000010111110 | ...
05 | 4805E02F | 01001000000001011110000000101111 | H../
06 | 4805E02F | 01001000000001011110000000101111 | H../
07 | 4805E02F | 01001000000001011110000000101111 | H../
Reading Page 1:
blk | hex data | binary | ascii
----+----------+----------------------------------+-------
00 | 201780BE | 00100000000101111000000010111110 | ...
01 | 4805E02F | 01001000000001011110000000101111 | H../
02 | 4805E02F | 01001000000001011110000000101111 | H../
03 | 4805E02F | 01001000000001011110000000101111 | H../
pm3 -->
Is it possible that a password was set at DT when they set the chip to EM mode? If anyone can give me some advice on how to proceed with this, I’d appreciate it.
FWIW the T5577 card that came with the Proxmark3 behaves normally, I’ve written that to EM mode and the Halo scans it fine, then I’ve used the wipe command to set it back to blank and everything performs normally as expected with that card. It’s just the xEM in my hand that is not happy.
LOL well I think I bricked my xEM. I couldn’t leave it alone and was messing around trying to figure it out, reading forum posts here and on the proxmark forum, and everything seemed to point to there being a password set. Like the various t55xx commands giving bad/wierd results, all that apparently happens if there’s a password and you’re not using it.
So I tried the lf t55xx bruteforce command with the list of known passwords, and after that, the xEM does not work at all. lf search, lf t55xx detect, and the Halo reader all come up with nothing.
Oops We do not set passwords on the chip… and yes you can brick the T5577 in so many ways it’s scary. One of those ways is by actually using password commands when there is no password set… oddly enough.
The problems you were having were very likely due to the crap coupling the factory Proxmark3 antennas have with the xEM. @TomHarkness is working on antenna designs that work much better for x-series tags. He may also be able to help you unbrick your xEM using the undocumented “test mode” feature of the T5577… but I don’t know enough about that to know if it could help or not.
Oh dear You seem to have over worked your poor little xEM with that brute force attack. Not to worry, I think we may be able to fix this. Can you PM me sometime? I will do my best to help.
Also Note: IF “lf t5 trace” was returning data, this means that your xEM was NOT locked with a password. If it was protected and locked you would not be able to read that data.
lf t5 trace wasn’t giving me data though it just gave me that error message that the modulcation was wrong? And the lf t5 info reported that password mode was enabled.
That and the consistently ‘wierd’ config block made me think it had somehow gotten corrupted and password protected.
I’ve copied my reply here as I think it’s best that we keep this public so that it can help others.
A few things. Make sure you are running the latest proxmark client and have flashed the latest firmware. Mismatched client / firmware will cause issues. So have you tried to issue something like:
lf hid clone 2004840534
?
Try that and let me know if it writes an ID. If not you can give this a try.
lf t55xx write b 0 d 00107071 p 11111111 t
lf hid clone 2004840534
lf search
Make sure to have the “t” flag at the end of the t55 write command. This somehow magically recovers bricked xEM’s. I may have some more info on testmode commands soon - the struggle trying to find anything is very real.
Let me know how you go. I have tried all of the above on test xEM’s and my own implanted xEM - none of this can brick or damage anything.
I had been running the Iceman version but I downloaded and compiled the regular master version this morning and flashed that to the card. It’s a Proxmark3 Easy (Elechouse) by the way. And FWIW i have the xLED and know the best position on the coil, and my xEM is kinda ‘perfectly’ positioned ih my hand so its pretty easy for me to get the alignment right.
Having said all that… I followed your examples (there should be a p before the 11111111 shouldn’t there?) and for the t55xx write command the response was: #db# TestMODE
Then for the hid clone command the response was: #db# DONE!
For the lf search though it is not finding anything:
No Data Found! - maybe not an LF tag?
Maybe I need to do something with lf t55xx config first? It’s at the default settings, which might be hindering the write and clone commands?
The block of binary has this repeating pattern… 0000000000000000110101111111100101011111110011111001111110110011010011100000011000100001001000011
(Assuming I clipped it at the right spot. The 16 zeros seemed like a good place to pick as the start?)
I’m still poking at this now and then when I get some spare time, and that repeating binary pattern is consistent. I’ve tried just about every combination I can think of with the lf t5 config command… turning inverted on and off, experimenting with bitrates and tried all the FSK variations.
The chip is trying to talk, sending out that pattern in my previous post, but it’s obviously garbled somehow and I don’t know how to decypher it.
I think your getting bad coupling is what might be causing this unfortunately. I think the couple is OK enough to get a read of some data but its just not writing cleanly.
So I need to come up with a better LF antenna then. I’ve been reading and trying to understand that side of things but it’s a lot more murky.
It’s wierd tho that (before it got utterly borked) it was always consitently and correctly reading the EM410x data, but the T5xx data was always coming up wrong. I have some other LF glass tags (not implanted) that it reads fine as well. They’re RO though so I can’t test writing to them.
Anyways, I’ll start messing around with LF antennas and see what I can do.
My pleasure. I’ve actually been working on antenna prototypes for about a year and have just recently begun working with the proxgrind team to come up with some hardware that will work for us in the implanting community, hopefully much better than anything else available. I’m working crazy hard at this to get something released ASAP so if you can hold out just a bit there may be an easier option.
The initial release will be for the rdv4 hardware but I’m hoping we can make something that users can retrofit to the pm3-easy also.
In a former life I was into radio stuff and worked a bit with RF electronics & antennas. Unfortunately most of our actual knowledge/experience has been lost, but some of it floats up to the surface now and then. And I found a spool of magnet wire and an LC meter in one of my junk boxes.
First try was 15mm dia x ~20mm long coil antenna, approx 200 (sloppy) turns, approx 580 uH. It works great if you can fit the tag inside the coil but not so hot for anything else. Mind you it did detect my xEM was a T5577 but that’s all it did.
I’ve seen a small rectangle design that is supposed to work so going to wind one of those next. 42mm x 18mm x about 3mm high, so going to try that next.
The LF antenna on my PM3Easy is 34mm diameter and measures about 500uH on the meter.
I’ve wound a small rectangular antenna that (according to hw tune) is giving me better performance than the stock PM3Easy antenna does. It can read a glass EM410x tag from about 1cm away, and when I keep it pressed on my hand so it’s directly against the xEM in the correct orientation, lf search u finds an ‘unknown FSK tag’ every time, and says it’s a t55xx.
The t55xx p1detect command also returns that it’s found a t55xx chip.
But none of the write commands are working, and if I manually set the modulation to FSK and read the chip, I just read the same nonsense. But it’s consistent nonsense.
Fiddling with bitrate, inverted, modulation, offset settings will change the result but nothing I’ve tried results in anything I can decypher, and I can’t get those write commands to work on it.
Nice work on making the coils! I’ve actually somehow managed to get one of my test xEM’s into this same state! It returns an ID, but Int for the life of me change it or write to any blocks. Hmm this is a start I guess? I mean… I can at least try and come up with a solution now that its it’s in this state lol.
This happened using the latest iceman fork / RRG fork - I didn’t realise until chatting with other devs late last night that the t55 write timing is a bit broken in that fork!
Try and download / compile the latest original fork if you can? I tried writing to a t55 implant with iceman / RRG fork last night and it just wouldn’t - even with some crazy good coils. As soon as I used / flashed the original fork I could write just fine. This may be part of the problem!
@amal We need a warning post sticky for this if possible please please please. People should only be using the original fork:
For anything t55 related. HF it’s better to use the latest iceman / RRG. This is frustrating I know!! I’ve communicated that we need this fixed asap to the right people.
Actually. My complaining may have done the trick, this is only the very beginning of some very large fixes but try with the latest pull. This was committed last night after a conversation I had with iceman.
Aaah I was definitely using the iceman fork when the whole thing went bad, but I switched back to the main version yesterday morning, or maybe it was the day before…
I’m still getting the same results, its frustrating. The chip sends ‘something’ but I guess with its config block scrambled, it’s a complete guess as to what the correct settings are. And I don’t know if it got into a password mode or if it got locked, so I don’t know if it’s failing to write because my lf t5xx config is wrong, or if it’s failing to write because it’s locked or protected.
Can you clarify something in this command please? Should there be a ‘p’ before the 11111111 or not? I’m trying to understand what this is actually doing, and from the help files it seems that the eight 1’s are a password? but there’s no p flag?
Ahh sorry that you are having such a painful time! As I said I’ve managed to get one of my test xEM’s into the same, or at least a very similar state so will do what I can to help figure this out.
We do not set passwords on the chip… and yes you can brick the T5577 in so many ways it’s scary. One of those ways is by actually using password commands when there is no password set… oddly enough.
You seem to have over worked your poor little xEM with that brute force attack. Not to worry, I think we may be able to fix this. Can you PM me sometime? I will do my best to help.
Mind you it did detect my xEM was a T5577 but that’s all it did.