Hack: store 2 to 3 different EM41xx on a single T5577

Projects
1

I didn’t think this would work, but amazingly it does: you can have more than one EM UID on a single implant. And it works pretty good too!

So, a bit of background: as you may know, my SiRFIDaL RFID login software for Linux can work with two different kinds of readers: repeating (or continuous) readers and one-shot readers. The former send whatever is in the field repeatedly (or can be polled continuously), while the latter only send the UIDs of tags that come into the field once.

Repeating readers are nice, because not only is it possible to match the UIDs against registered users, it’s also possible to determine whether the tag is still present or has left the field for additional functionalities.

For instance, if I “short-present” my implant to the reader, it logs me in, and once I’m logged in, if I “long-present” my implant, it locks my screen. In other words, repeating readers can be used to authenticate the user and also track their presence, something that’s not possible with single-shot readers.

I also have this project of creating a smart chair that logs me in when I sit down and locks my screen when I get up, using an implant in my butt. For that, I need a repeating reader under my chair. Unfortunately, the only readers suitable for this project are long-range LF readers such as the ACM08Y or ACM26C - and those are typically one-shot, dumb (very dumb) serial readers. I’ve searched far and wide for configurable or pollable long-range readers, but sadly to no avail. So my butt implant project has been on hold… until today :slight_smile:

I’ve been wanting to modify the aforementioned readers to turn them into repeating readers. But it’s not very easy because the electronics are potted in a metric ton of epoxy, and I’m sure I’ll destroy them if I try to expose the innards.

But then I thought: those readers only report tags coming into the field once. But they maintain the field while the tag is present. So what they must be doing is receive the tag’s UID continuously, and only report when the UID changes. After all, that’s what EM tags do: as long as they’re powered, they send their UID over and over.

Maybe, just maybe, the readers’ firmware doesn’t actually care that the tag leaves the field, just that the UID is different from the previous one. So if I had a tag that alternated between two UIDs, I could force the reader to report the UID at each change and track when the stream of UIDs stop to know that the tag has left the field.

And then it hit me: the T5577 is capable of doing that! All the chip does is send a sequence of bits stored in part of its memory over and over. I could simply encode a second, different sequence after the first one and configure the chip to send twice as many bits - in effect getting it to send a long, custom sequence composed of two valid EM sequences.

So I hand-programmed my xEM to do that, and sure enough, my readers started spewing out alternating UIDs at high speed continuously. Success!

So here’s the technical explanation on how to do it (note that you need a Proxmark3 for this):

Firstly, a word on EM bit sequence encoding: if you look at this helpful page, you learn that the sequence is composed of 9 start bits, followed by 10 nibbles + parity that encode the 5-byte UID, followed by one parity nibble, followed by 1 stop bit:

image

So let’s say we want the first UID to be 0xDEADBABE01 and the second UID to be 0xDEADBABE02. They get encoded as follows:

  • DEADBABE01:
    Bin: 111111111 1101 1 1110 1 1010 0 1101 1 1011 1 1010 0 1011 1 1110 1 0000 0 0001 1 0001 0
    Hex FFEFB4DDE97E8062

  • DEADBABE02:
    Bin: 111111111 1101 1 1110 1 1010 0 1101 1 1011 1 1010 0 1011 1 1110 1 0000 0 0010 1 0010 0
    Hex: FFEFB4DDE97E80A4

Now then, how to hand-program your T5577 with two UIDs?

Simple: first, program the T5577 as an EM41xx normally with the Proxmark3 with the first UID:

image

This command writes the 64 bit sequence for DEADBABE01 in block 1 and 2, and configures fhe correct bit rate / encoding / mode… in block 0:

image

Crucially, it sets MAXBLK to 2. If you look in the datasheet, it says this:

image
image983×77 14.7 KB

So this is correct: configured as a normal EM, the T5577 will transmit the 32-bit blocks 1 & 2 over and over.

So what we need to do now is program the sequence for the second UID (DEADBABE02) into block 3 and 4, and bump up MAXBLK to 4, so that the T5577 will transmit blocks 1, 2, 3 and 4 over and over.

Of course, there is no provision in the Proxmark3 client to do this. So we need to do it by hand.

Firstly, programming block 3 and 4: split the DEADBABE02 sequence into 2 32-bit words: FFEFB4DD and E97E80A4.

Then program blocks 3 & 4 with the Proxmark3 client manually:

image

image

Finally, adjust MAXBLK in block 0: if we look in the T5577 datasheet again, here’s the bitfield in block 0:

image
image1038×563 71.2 KB

So we see MAXBLK is encoded in bits 25, 26 & 27.

We already have the current value of block 0 from the lf t55xx info command above. The MAXBLK bits are in bold:

…
Raw Data - Page 0
Block 0 : 0x00148040 00000000000101001000000001000000
…

So we need to change the binary value of block 0 to:

00000000000101001000000010000000

which is 0x00148080.

To do this, program that value in block 0:

image

Confirm that the new value has been programmed correctly

image

Note that this time, lf t55xx info does not report the tag as a valid EM anymore. However, lf search still does (but only interprets the first UID because it doesn’t expect anything beyond the first sequence:

image
image642×570 45.8 KB

And now, if you present the tag to a dumb reader, it’ll spew out the two UIDs alternatively at high speed:

...
DEADBABE01
DEADBABE02
DEADBABE01
DEADBABE02
DEADBABE01
DEADBABE02
...

It even works with 3 UIDs: there are 7 data blocks in a T5577, so you can also use block 5 and 6 to encode a third UID, and adjust MAXBLK to 6. But I noticed some of my readers get a bit iffy with 3 UIDs. 2 work fine though.

Basically, it’s exactly like the reader was in The Matrix and Neo was presenting his 2 implants one after the other alternatively at super-high speed. So it’s not even an invalid sequence of UIDs! But some readers might cause trouble, either because the firmware decides to do something then wait until the field clears after reading a UID, or because the link to the computer is too slow (keyboard wedges for instance). After all, they were never created to read Neo’s implants at the speeds Neo is capable of :slight_smile:

But on the readers I’ve tried this on, it works dandy. Those are:

How useful is this likely to be “in the wild”?

Well, provided the reader you want this to work on doesn’t choke on the rate of UID change, it should work on any reader. You can even accommodate difficult readers: say one of them (your home’s front door reader) works fine with either the first or the second UID, but another (the door reader at your workplace perhaps) only triggers on the first UID but not on the second one because it pauses after reading an invalid UID, then simply reorder the UIDs on the T5577 so they get presented in the right order.

Anyway, it’s a fun hack to try, and it’s a cheap way to extend the usability of your xEM or flexEM. I hope you’ll enjoy playing with this :slight_smile:

27 Likes
2

Sorry for the mess with the threads, Discourse always creates problems when you post code and things it thinks looks like code injection or something. This one has the interesting bits as images instead of copy/pastable text sadly, so Discourse doesn’t throw a wobbler.

2 Likes
3

Amazing work as usual Rosco, that’s one of the reasons it’s great to have you around.

You have just unlocked [pun] additional functionality (at least I wasn’t aware of…)

Thanks for sharing and taking the time to write it up.

:vault_boy_finger_pistols:

2 Likes
4

Also, I forgot to mention: in SiRFIDaL, the dual-EM T5577 will be interpreted as two distinct RFID tags present at the same time.

This means you can configure PAM to only log you in when the two UIDs are authenticated simultaneously, which - working only with unencrypted UIDs and no public key cryptography or one-time pads - is greatly improved security.

I mean cloning an implanted EM is unlikely enough as it is. But cloning a custom-programmed dual-EM (without knowing it’s custom-programmed) and logging into a computer with only one reader? That’s downright impossible.

4 Likes
5

Wow that’s a lot to unpack that I dont fully understand…

I get the concept though and that’s friggin awesome

Soo, because I always want the next step too,

Do you think it would be possible to have uid 1 be EM, and uid 2 be hid?

I only understood a fraction of the coding you explained… so forgive me if I should have understood from what you already said

1 Like
6

Well Pilgrim, looks like you’re not the only one interested in this :slight_smile:

There are two issues with mixing different formats:

1/ If the T5577 frontend and encoding settings are strictly identical between tag type A and tag type B (i.e. if only the format of the bit sequence changes) AND both sequences fit in the T5577’s memory, then yes, you can encode both on the T5577

2/ BUT! The big issue is: will the reader for which the second sequence is intended be forgiving enough to ignore the first sequence if doesn’t undertand it, and will it manage to correctly latch onto the beginning of the second one?

The tests I conducted to assess the viability of the hack show that at least all of my EM readers are highly intolerant of stuff they don’t understand coming through: they all want the transmission to start with 9 preamble bits exactly, either when something enters the field for the first time, or following a valid previous transmission. Any spurrious byte inserted anywhere in the sequence renders the readers silent. In short: they detect something is off and refuse to interpret the rest of the sequence.

So the reply is… it depends. If you’re lucky and the target reader for the second UID is very forgiving (and probably quite smart too, to sort out garbage from a valid transmission with only a few bytes from a weakly protected protocol), then yes. Most likely, you won’t be lucky. But it doesn’t kill to try it.

The EM-with-EM UIDs trick works because EM tags were designed to send the same sequence back-to-back from the get-go, and all EM readers expect this. But EM readers never expect two different tags with different protocols to talk politely one right after the other in sequence. That never happens in real-life.

2 Likes
7

Definitely not, really Rosco this is amazing, thank you.
This is definetely something I will deep dive into some weekend.

I feel like there might be some out there, just from a programmers perspective you might just take this stream of data and read it continously and not care what happened before, so it shouldn’t be too unlikely right?

This is so cool. You’re exploiting a parser differential to hide your 2nd ID, people that wanna clone your tag get an error or only the first ID, your reader gets the second one :smiley:

I have to try this. I always thought LF chips are boring, you’ve shown me they aren’t! Thank you!

1 Like
8

We are talking about fitting the transmission of a whole new protocol after the ID of the EM protocol right? Is there even enough space for that? Aren’t these protocols like a back and forth kinda thing? So wouldn’t you need this part of the ID to be valid in different stages of communication while also ignoring the rest?

If so, then I was wrong when I said “it shouldn’t be too unlikely right?” because of

I think I understand the issue now. I wonder if there are similar things in other LF protocols…

9

Old low tech is highly hackable. That’s why all my implants are simple storage thingies :slight_smile:

1 Like
10

Assuming the two different physical layers are the same (e.g. EM is Manchester encoding, 64 carrier periods per bit… that sort of thing) then stuffing two different protocol frames is like me speaking a sentence in English immediately followed by a sentence in Spanish, then English again, then Spanish:

HelloHowAreYouHolaQuéTalHelloHowAreYou…

If you’re obtuse of not very bright, like them serial LF readers, you’re just going to dismiss all I say as gobbledygook and ignore me altogether.

One way to sidestep the issue is to put punctuations or silences between the English and Spanish sentences, so you have a chance to realize you should ignore one of the two sentences you don’t understand. Unfortunately, you can’t encode spaces in the bit sequence “played” by the T5577.

In essence, that’s the problem. If you have a reader that speaks both English and Spanish and isn’t too strict on protocol, you might have a chance to have it work. But it’s unlikely.

11

This is getting even more interesting, I will steal your polyglot analogy btw, it’s very good.

Now I wanna look at some reader implementations and search for the same hack or create a polyglot xEM. I wonder if people over at the iceman channel knew about this… I asked.

12

Hehe. Glad I got someone’s week-end booked with something to do :slight_smile:

1 Like
13

Amazing work of course. I might be missing something but isn’t this the same concept as presenting a 64bit LF tag to a reader expecting only 32bits and splitting it, or is there something more going on?

Suggestion for readers that choke on this… move ID 2 over to blocks 5 and 6 and leave blocks 3 and 4 set to 00 as a kind of quiescence… hard to tell how certain firmwares behave but a full 32 bits of data 00 might trip a bit counter into flushing.

Also I’m curious what actual LF reader chips are inside those readers because most LF readers not based on Chinese 8 bit uprocs doing shoddy bitbanging include their own demodulators and spit out the data stream without so much as a crc check… which is why you can get badly coupled tags to output variations on IDs… kinda like a fuzzing attack might produce.

Anyway it’s all very awesome! I can’t wait to try it out with a sequence of HID chip IDs… I’ve got a few 3rd party HID secured locations to try.

2 Likes
14

That’s pretty crazy. I can see this being useful for a ton of different applications!

15

Not quite. It’s sending 9 start bits and then the first UID, parity, a stop bit and then another 9 start bits and the second UID, parity and a second stop bit.

As long as the bits are encoded the same way, and there is enough room in the T5577 for the RFID streams then you could put as many tokens, in different formats as you wish. The other issue is how the reader deals with a stream of IDs. If it recognizes them as individual cards and accepts or rejects them individually you are good. If it only looks at the first part and that is the right key, you are good. Otherwise it might ignore the entire stream.

1 Like
16

Haha, great minds think alike :slight_smile: I tried this of course - more in an effort to give the readers a break and slow down the transmission over the serial line a bit. But it doesn’t work:

1/ It’s Manchester-encoded, so the “quiescence” periods are going to be a bunch of bit flipping, whether it’s 0x00000000 or 0xFFFFFFFF.

2/ Even if it’s 0xFFFFFFFF, then you might think it’s just going to be a lot of 1’s before the 9 1’s of the preamble, and so the reader won’t care until it hits the first zero. But no: the readers want exactly 64 bit, properly formed sequences back to back, otherwise they stop talking.

And it makes sense after all: that’s what EMs do in the field: they send their 64-bit sequences over and over without a pause. That’s what readers expect. If they see anything else going on, even a single extra byte, they lose sync and dismiss the - now offset - rest of the transmission. Which is also why I’m not too hopeful about mixing sequence types. At least not mixing EM sequences with something else.

No. Like Yeka explained, it’s two independent sequences each with its own set of “utility bits” (header, trailer and parities), not one sequence that’s twice the payload length but with only one set of utility bits.

1 Like
17

Yes, and no. A lot of the time they are “when powered on, I send this sequence, and keep sending it…”. Sometimes they are “get a sequence and send some form of response”

Most of the access control systems are just “what UID do I see” though.

18

Yes. This is old tech. So simple you can do amazing hacks, like this fabulous DIY AVR-based soft-RFID emulator:

This is level 11 on the cleverness scale.

3 Likes
19

Did you recreate it on a reader though? If yes, what reader was it? People over at the iceman Discord could only reproduce the 2 ID trick.

20

Yes, the ACM08Y and the ACM26C (they’re the same thing really) report all 3, but they’re not in exact sequence (as lin 01 → 02 → 03 → 01 → 02 → 03… as it should be, but rather something like 01 → 02 → 01 → 02 → 03 → 01 → 03 → 02…) so I know they’re choking a bit on that.

The Sycreader R60D kind of does the same thing but worse - mostly due to the slowness of the “typing”, since it’s a keyboard wedge.

As for the Elatech Multitech TWN4, it works perfectly for a few seconds, then it falls into a coma for 10/15 seconds before it regains consciousness and sends the 3 UIDs again, only to fall into a coma again after a few more seconds.

I think the issue is that all the developers who made the readers’ various firmwares all assumed a continuous stream of EM sequences could only come from a single tag, and therefore could only yield a single ID. As a result, they paid no special attention to following fast UID transitions without “falling behind”, so-to-speak. It works more or less well on this or that reader depending on how gracefully the firmware happens to handle this totally unexpected situation

1 Like