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

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

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

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

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.

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.


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.

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

I really should stress one thing: like I explained in my original post, my goal was to turn my one-shot long-range Chinese-made readers into repeating readers. Reprogramming my foot implant with 2 UIDs did exactly that for $0. So as far as I’m concerned, job done.

Now I can go ahead with my butt implant project, and order a couple more of them readers to stick in my chair and in my sofa (which, incidentally, I scored the last two RS232 versions of available anywhere in Europe this afternoon. Yeah!)

I only tested with other readers for the sake of completeness before posting the hack. It works - at least with my readers - but it wasn’t my original purpose, so YMMV.

Oh yeah I didn’t want to downplay your work, 2 IDs in one xEM, crazy shit, 3 with luck, even better!

I’m just interested in this because they all imolement the same protocol but are SO different.

Cant wait for the butt implant thread xD


When you push the envelope of anything, even when you stay entirely within the specs, interesting things invariably happen. That’s the fun of hacking :slight_smile: it reveals the assumptions whoever coded the other end applied to their technical implementations.


Fun fact: dual-EMs crash the white cloner so hard you gotta take the batteries out to get it to reboot :slight_smile:

Pity it didn’t kill the hateful thing outright…

1 Like

Have you tried your blue cloner with dual+ UID’s yet?

Yeah it reads - whatever it reads - and doesn’t crash apparently. I don’t know what it would clone though, and I’m not about to find out, as I have no intention of spending time repairing a perfectly okay T5577 card for the sake of finding out what a cloner I never use does when I never clone a tag.

But… For Science!?


Yeah… no.

1 Like

Alright I tried it: it clones the first EM. Boring…

This is a 3-beep (HID-capable) blue cloner. Dunno if the 2-beep one works the same. Probably.


Turns out 7 hours will do a lot for the pursuit of science! Thank you for your service good sir, awesome discoveries here for sure.


Some science: if you’re have a dual EM, you have a Proxmark3 and you’re knowledgeable enough to hand-program a T5577 with it. So why on God’s green Earth would you use a blue cloner to copy it? :slight_smile:



Science doesn’t have to have an application! We do lots of things we don’t really need to do just to see what happens on this forum!