Yes there should be a p before that sorry! totally missed that ! Just edited!
its also worth trying 00000000 for the password instead of 11111111 - however it shouldn’t really matter when using the t flag.
I’ve tried both and no luck. 
I keep thinking, if I could get the config right then I should be able to read the trace info in page 1, but I’ve tried and tried and it never finds anything but gibberish.
And I also think back to before, before I tried writing anything in the first place, it was just spouting gibberish too, which is waht made me think it was corrupted or something in the first place… writing to it just made the problem worse lol.
Thanks again for your help on this! Sorry you’ve got one of your tags into the same situation.
Config is:
Modulation: Ask
Bitrate: 64
Offset: 32
Inverted: NO
Sequence term: NO
No need to be sorry about the xEM - it’s what I have spares for!
That’s the desired config… the config my chip is in, is a mystery. 
It’s definitely FSK but that’s all I’m sure of. Looking at the data plot I can see there’s 10.5 cycles in a 0 and 6.5 cycles in a 1. That’s pretty close to the RF/8 & RF/5 ratio for FSK1a in the datasheet.
And the lf search u says it’s finding something in FSK1a at clock 50, so I’m going with a config of FSK1a and RF/50 but that leaves the offset and seq. term unknown.
I just realized though, this might all be pointless if the chip is actually scrambled lol.
Interesting!
I don’t think any of this is pointless as I’m sure there is a way that this can be fixed.
I’m getting more and more certain that the iceman fork caused this. Currently trying to brute force the xEM that I managed to get in to the same state. I wonder how long until the t55 just dies all together from too many successive writes lol.
In the meantime don’t go crazy trying things with your xEM in vivo. I’ll do my best to figure out a fix for this!
Thanks Tom. I’ve ordered a handful of T5577 keytags to play around with, so I’ll have some spares to ‘break’ and try fixing.
That’s a shame about the iceman fork. I only ended up using that as my PM3Easy was originally messed up and I couldn’t get the normal firmware to flash, but the iceman fork flashed onto it ok. Subsequently it worked to flash it back to the normal one.
Pleasure! Good place to start - try and get them into the same state then recover.
It’s a bit frustrating that there are so many differences between forks that are nigh on impossible to spot unless you have been following the development cycle or digging deep in to the code. Hiopoefully we can get some consistency soon, more and more people are getting on board to improve, clean and build on the existing code base. What we really need are people that can write hardcore FPGA code / Verilog code so that we can port the FPGA code to a newer / more flexible and powerful FPGA. If you know anyone with those skills and that is willing let me know… 
Unfortunately the boot-loader can go ‘funny’ sometimes - not corrupt but funny lol.
You found one fix by changing fork which changes the usb device ID in firmware. The ‘proper’ way to fix this (not really documented well) is to hold the pm3 button down while plugging in the USB lead and keep it held while flashing the bootloader.elf followed by fullimage.elf. Not releasing the button until all of the above is complete.
~TH
Ah, I know we’ve never touched FPGA stuff before. Used to play around with coding for embedded devices many years back. But that knowledge has all gotten lost along with the RF stuff, due to ‘brain issues’. Sorta like, the info is all in there somewhere, but the indexes got wiped. 
That’s good to know about fixing the flash problem by just holding the button down till the process is over.
I should have thought to order spare T5577’s before, tbh. For the HF stuff, we have dozens of spare NTAG and Mifare tags to experiment with. On the LF side though, just some old EM4xxx tags.
So before risking doing anything bad to the xNT or xM1+ we trial it on a spare tag. The xEM, not so much. 
I just installed a replacement xEM this evening (thanks @mdanger!) and I’m not going to try writing to it until I’m positive I’m getting good reads / good antenna coupling.
I see something in the t5577 detect / info / dump data which is unexpected, though it is consistent. It’s showing the ‘master key’ / ‘safer key’ is set, with a 6. According to the data sheet that disables test mode? Here’s the info from the Proxmark:
lf t5577 detect
Chip Type : T55x7
Modulation : ASK
Bit Rate : 5 - RF/64
Inverted : No
Offset : 33
Seq. Term. : No
Block0 : 0x60148040
lf t5577 dump
Reading Page 0:
blk | hex data | binary
----+----------+---------------------------------
0 | 60148040 | 01100000000101001000000001000000
1 | FF940350 | 11111111100101000000001101010000
2 | 18054930 | 00011000000001010100100100110000
3 | FCEF6F3F | 11111100111011110110111100111111
4 | DFEFF7FE | 11011111111011111111011111111110
5 | 00000000 | 00000000000000000000000000000000
6 | 00000000 | 00000000000000000000000000000000
7 | 00000000 | 00000000000000000000000000000000
Reading Page 1:
blk | hex data | binary
----+----------+---------------------------------
0 | 60148040 | 01100000000101001000000001000000
1 | E0150158 | 11100000000101010000000101011000
2 | 700512AE | 01110000000001010001001010101110
3 | 00000000 | 00000000000000000000000000000000
lft5577 info
-- T55x7 Configuration & Tag Information --------------------
-------------------------------------------------------------
Safer key : 6 - passwd
reserved : 0
Data bit rate : 5 - RF/64
eXtended mode : No
Modulation : 8 - Manchester
PSK clock frequency : 0
AOR - Answer on Request : No
OTP - One Time Pad : No
Max block : 2
Password mode : No
Sequence Start Terminator : No
Fast Write : No
Inverse data : No
POR-Delay : No
-------------------------------------------------------------
Raw Data - Page 0
Block 0 : 0x60148040 01100000000101001000000001000000
-------------------------------------------------------------
lf t5577 trace
-- T55x7 Trace Information ----------------------------------
-------------------------------------------------------------
ACL Allocation class (ISO/IEC 15963-1) : 0xE0 (224)
MFC Manufacturer ID (ISO/IEC 7816-6) : 0x15 (21) - ATMEL France
CID : 0x00 (0) -
ICR IC Revision : 1
Manufactured
Year/Quarter : 2015/2
Lot ID : 1792
Wafer number : 10
Die Number : 4782
-------------------------------------------------------------
Raw Data - Page 1
Block 1 : 0xE0150158 11100000000101010000000101011000
Block 2 : 0x700512AE 01110000000001010001001010101110
-------------------------------------------------------------
So I think I’m getting a good read on the chip, and I can visually decode blocks 1 and 2 to read the EM41xx serial number on the chip (2015060594).
I’m just wondering if I need to worry about the master key / safer key being set to a 6 instead of the expected 0?
Also not sure if I should be worried about the data in blocks 3 and 4? Maxblock is set to 2, so it shouldn’t be sending anything for those blocks I think? (My PM3Easy is updated on the latest firmware and latest client, of the standard repository.)
FWIW I do not know what the original xEM setting was for this, as I never got a clean / sane read of it using the t5577 commands, though it did read properly as an EM41xx chip both with my Proxmark and my Halo reader. If it had the master key set to a 6 though, that might explain why the test mode command isn’t working? The 6 key disables test mode…
-
Nice! What a legend!
-
That’s fine, simply issuing the Lf hid clone or em clone commands should work at this point and they’ll set the correct config bits. EDIT: looking over that dump you are definitely only just coupling enough to sometimes cleanly read - bits from that dump are flipped. I’ll post a dump from a fresh xEM ASAP for you to compare against.
2.1 The data in blocks 3 & 4 is fine, that’s actually where the data that makes up the tag ID is stored. For reference - you can even write random data to 5,6 & 7 without effecting ID reads. I.e. I have block 6 of my xEM set to my birthday in Hex.
-
I UNBRICKED the xEM that I managed to get in to the same state two days ago. It requires custom coils with extremely good coupling. I expect you are getting just a good enough couple to read but are flipping bits when writing your tag.
-
Thanks to the work that’s gone in to #3 over the years you’ll likely be able to buy a custom antenna that will help you soon!
~TH
Thanks Tom! I’ll hold off trying to write to the new xEM for now, and keep an eye out for the improved antenna coils!
Re. blocks 3 and 4, the EM tag data is in blocks 1 and 2, according to the notes I’ve seen. and I can decode them by looking at it. After the first nine 1’s, every 4 bits are a number followed by one bit parity. And maxblock is set to 2. Blocks 3 and 4 just look like random noise to me.
I’m wondering if my Proxmark 3 easy has a problem with low power, but maybe it’s just really iffy coupling to the small LF tags.
I’d love to get an rdv 4 but I’m in Canada, and after adding the international shipping, customs / duties / taxes, and the currency conversion, it’ll be like $500 and I just can’t justify that. I got the PM3Easy from a local reseller so I didn’t have to deal with currency and duties etc.
No worries!
Interesting.
Hmm - do you know if its a genuine or fake version? If you paid under $200 USD for it - it’s likely fake and potentially part of whats causing the problem.
Hoping that we will have something sorted regarding RDV4.0 pricing and distribution for the implant community soon
Also hoping that I can maybe get a few batches of retrofit-able antennas for rdv2 - “easy” and rdv3 boards for those that can’t get an RDv4.0
~TH
Thought I’d already responded to this but apparently not. Memory problems lol.
Unfortunately my PM3Easy may well be a fake. I got it from a local distributor and the price was about half what you mention.
If I knew then what I know now… 
(Actually if I knew then what I know now, I’d have got in on the RDV4 kickstarter lol.)
My Easy does work quite well on HF, and to be fair the LF has worked just fine for everything but the xEM. It’s been fine for larger T5577 tags, and it reads small EM4x glass tags quite well, and can it even read my xBT correctly when I’m able to get the antenna in the right spot.
(I honestly can’t remember exactly where my xBT is, so it’s always a search to try and locate it with a smaller antenna. The Halo has great range tho so it doesn’t matter so much.)
The nice thing with the Easy having the LF antenna attached by screws, is it’s so easy to swap out antennas. My own coils, I just leave a few inches of magnet wire hanging off, and use the screws to secure them.
So even without a ‘special built’ Easy antenna, it probably wouldn’t be too hard to hook another shape / style antenna on. Even if it was a temporary bodge, with a couple wire leads.
I did order the xEM access controller, so when it gets here I’ll try using the antenna from that and see how it goes.
Cheers!
1 Like
The fakes can be hit and miss, I have seen some good, some bad and some terrible. Yours sounds to be in the good range as both HF and LF work reasonably by the sounds of it.
After modifying a few pm3-easy boards for people I’ve actually got some spare LF antenna pcb parts for the easy board! 
If you have no luck with the coil from the xEM access kit I will try and work something out for you! That coil is particularly nice so should hopefully do the job.
1 Like
Another little observation re. my bricked xEM versus the new one…
Setting the lf t55 config to FSK1a and bit rate to 50 (to match what ‘lf search u’ finds for the dead one), then issuing the ‘lf t55 dump’ command a few times in a row, and comparing the results, the results vary line by line, shifting left and right by one bit here and there.
With the new xEM, using ‘lf t5 detect’ then a few ‘lf t5 dump’ commands, the output from that is absolutely identical over and over.
That feels like some kind of timing issue between the proxmark and the bricked implant. Like as it’s reading the dump, it’s randomly adding or losing a bit between each block.
On the other hand, using ‘lf search u’ on the briked xEM over and over, produces an identical binary dump ‘unknown tag’ result.
I don’t know what to make of this info, tho… Still not gonna try writing anything till I have the access kit’s antenna and done some tests with it.
I think it’s about time to give up on my bricked xEM.
Our latest package of goodies from DT came today and I dove in and got at the xEM access kit antenna. Even with the coax cut to a 5" length it was pretty abysmal on the Proxmark 3 Easy. And it was saying the resonant frequency was way too low, like 100kHz. My LC meter showed 770 uH, or about 50% more inductance than the PM3Easy wanted.
So, I liberated the coil from the potting goop and the coax, and pulled a bunch of turns off it. Got the resonant frequency up almost to 125kHz and the Easy was giving the highest LF voltage I’d seen in hw tune. It lights up the xLED like crazy and can read a glass EM4x tag from 1 or 2 cm away.
Even with all that, I can’t get the bricked xEM to respond to writes and unbrick attempts.
On the other hand, the replacement xEM is in our other hand and last night we decided that we were getting good enough coupling with the homemade coil, so went ahead and tried writing to it. And it worked. So we’re all set with the xEM in our right hand. The dead one on the left, I guess we’ll extract it at some point.
It’s not hurting anything in there for now, so there’s no rush to dig it out.
FWIW here’s a pic of the coil out of the xEM access kit, alongside our homemade rectangular coil.
In hw tune, the homemade one gives a little over 24v at 125kHz. The commercial one is about 26.5v at 125kHz (after we removed a bunch of turns.)
Thanks again for all your help @TomHarkness and thanks to @mdanger for getting us the replacement xEM.
Cheers! 
1 Like
You are most welcome kiddo
mdanger
Can you sell China?