I just loaded to stock because App Library sounded cool… pretty just I just went from like v50 to v99 lol
I’ve been in a bit of hibernation on the rfid stuff
I see now that stock doesn’t currently support multi tag
1 Like
what were you on?
1 Like
If needed, I can make a lua script that will read 2 or 3 Em4102 and write them to T5577 
2 Likes
for a while i had 2 T5577 in the same location, both with the same programing. It had awesome reads … wondering if storing teh same code back to back would increase the read success too 
I need to try it one of these days …
1 Like
Probably not. A lot of readers require specific amounts of zero bits between ID reads. Basically most of these LF chips are “chip talks first” encoding systems that are simply repeating their IDs over and over based on a start sequence and zero bit time padding. Stuffing in multiple IDs in the memory so they spit out in rapid succession can actually confuse many readers. That’s why this hack doesn’t work with every reader. The amount of time it takes to transmit these zero bit “pauses” in the data stream is imperceptible really, but if you double up or triple up the same ID, it only has a chance of making things worse not better.
2 Likes
If someone confirms that a T5577 created this way will work as 2 or 3 EM4102, then I will create a script that will read EM4102 and copy the appropriate blocks.
It’s been confirmed by a prior forum user Rosco who has since opted out of forum discussion. A script would be cool beans!
To be clear, the T5577 won’t work like 2 or 3 EM4102 tags really… how the EM4102 works is that it powers up and repeatedly spits out the ID programmed into memory. With this configuration, the T5577 will power up and do the same, but the memory contents is longer so it just spits out what’s in memory… it just so happens that some readers will consider a successive bit 0 value to be “the end” of one ID and resume listening for the next transmission. Other readers require a full field decouple before they resume listening for more IDs. It just depends on how the reader was made and how the firmware was implemented.
Sorry for the constant editing… it’s just how I work as I consider things more and come back to update haha… but if a script is in consideration let’s see if we can make this work better / more efficiently.
So to transmit an ID of 12345678AB, the EM4102 has a frame structure like this;
[Preamble] 10101010101
[Header] 1
[Data + Parity] 0001 0010 1 | 0010 0011 1 | 0100 0101 0 | 0110 0111 0 | 1000 1010 1
[Stop Bits] 00
Sometimes the header is 11 (two bits vs one), and sometimes not… but as long as the preamble is 9+ bits long and ends with a 1 bit, then the next 1 bit header value should be sufficient in most cases.
… hmm… after re-reading the first page of this post it appears Rosco was putting no bits between IDs in the T5577 configuration. This means it’s completely up to the application layer’s data processing to “split” the IDs based purely on byte length… if the reader firmware can handle detecting and outputting IDs longer than 5 bytes (40 bits). Since some LF IDs can be up to 128 bits long some readers should have no problem with this, but I can definitely see others having issues.
Basically there are 3 parts or layers in play that will determine if this hack will work or not;
- reader hardware - the chip that detects the raw data stream and converts magnetic field wiggles into hard 1s and 0s
- reader firmware - how does this incoming stream of data from the demod circuit get verified and chopped up to be passed out of the reader chip
- application layer - how does the data coming from the reader chip get parsed and acted upon
With the above solution it appears that the IDs are just crammed together side by side, so after the preamble and header bits get the reader hardware (1) locked on, the ID data will just stream out. This means it’s up to the firmware (2) and application layer (3) to be able to handle and properly parse the data for this to work. The firmware will need to accommodate data streams longer than 40 bits, and the application layer will need to assume 40 bits are the max length of the IDs and then also assume that any additional bits streaming in are new IDs and basically chop / parse the data stream into a series of 40 bit IDs before checking them or passing them on to the authentication process.
What would be interesting would be to see if we can set up the programming of the T5577 such that it does not perform a preamble, header, parity or stop bits for us, and instead just sends the memory contents. Then we could perform our own preamble, header, ID1, parity, stop, preamble, header, ID2, parity, stop, etc.
3 Likes
Apparently, according to paid chatGPT, this is possible if we use raw mode for the T5577.
I start by asking some establishing questions to ensure the thread has the right context… but eventually we get down to it… and this is what chatGPT came up with;
Key Concepts for Full Custom Encoding
To manually encode an EM4100/EM4102 tag structure on a T5577, you’ll need to understand the typical EM4100 data format and how to map it into T5577’s memory blocks.
EM4100 Data Structure
An EM4100 Manchester-encoded transmission typically follows this structure:
[Preamble] [Header] [Data] [Parity] [Stop Bit]
| Element | Description | Typical Length |
|---|---|---|
| Preamble | Sequence of alternating bits (e.g., 1010...) to synchronize timing |
9 bits |
| Header | Fixed binary value (00000001) |
8 bits |
| Data | Unique 40-bit ID data | 40 bits |
| Parity | 4-bit odd parity (1 bit per 8-bit data chunk) | 4 bits |
| Stop Bit | End bit to mark termination | 1 bit |
Step 1: Calculate the Full Manchester Bitstream
You’ll need to construct a full 64-bit Manchester-encoded sequence to match EM4100 structure.
Manchester encoding rules:
- Each logical
1→ Encodes as10 - Each logical
0→ Encodes as01
For example:
- Binary data
1010→ Manchester encoded as10011001
Step 2: Compose the Full Bitstream
You’ll encode each element in binary and convert it into the T5577’s memory blocks.
Example EM4100 40-bit ID: 04001F1234
Binary representation: 0000 0100 0000 0000 0001 1111 0001 0010 0011 0100
Manchester encoded: (each bit encoded with alternating 10 or 01 pairs)
PREAMBLE 101010101 (9 bits)
HEADER 00000001 (8 bits)
DATA 00000100 00000000 00011111 00010010 00110100 (40 bits)
PARITY 1 0 1 1 (4 bits - odd parity on each byte)
STOP BIT 1
Total: 64 bits
Step 3: Program the T5577 Memory Blocks
The T5577 uses 32-bit memory blocks, so you must carefully distribute your encoded data across multiple blocks.
Example T5577 Data Block Layout (Direct Data Mode)
Block 0: 0x00148041 ; Config: Direct data mode + Manchester encoding
Block 1: 0xAAAAAAA5 ; Preamble + Start of Header
Block 2: 0x010001FF ; Header + Start of Data
Block 3: 0x1234F579 ; Remaining Data + Parity
Block 4: 0x80000000 ; Stop Bit (with appropriate padding)
Step 4: Proxmark3 Command Example
Using Proxmark3, you can write the data directly with commands like:
lf t55xx write -b 0 -d 0x00148041 # Configuration block (Direct Data Mode + Manchester)
lf t55xx write -b 1 -d 0xAAAAAAA5 # Encoded preamble & header
lf t55xx write -b 2 -d 0x010001FF # Encoded data + parity start
lf t55xx write -b 3 -d 0x1234F579 # Remaining data
lf t55xx write -b 4 -d 0x80000000 # Stop bit with padding
Step 5: Configure T5577 for Direct Data Mode
Direct Data Mode requires specific settings in Block 0:
| Configuration Bit | Description |
|---|---|
| Bit 5 | Direct Data Mode Enable (set to 1) |
| Bit 4 | Manchester Encoding Enable (set to 1) |
| Bit 0-3 | Bit rate control (set to match reader’s RF clock) |
Example Block 0 Config for Direct Data Mode + Manchester Encoding:
lf t55xx write -b 0 -d 0x00148041
Step 6: Testing
After writing the data:
- Use
lf searchorlf em 410x readto verify your encoded data. - Test your T5577 with an EM4100-compatible RFID reader to confirm successful emulation.
1 Like
Next I continued the conversation asking to encode two separate IDs into the memory space;
If you want to encode two consecutive EM4100 IDs into the T5577 memory, with each having its own preamble, header, data, parity, and stop bit, this is achievable by carefully formatting the T5577’s data blocks in Direct Data Mode with precise timing control.
Key Challenge: Emulating Consecutive IDs
The T5577 chip doesn’t natively support multiple RFID payloads in a cycle. However, using Direct Data Mode allows you to manually encode two full EM4100 sequences in a continuous data stream.
Goal:
- ID 1:
0102030405 - ID 2:
060708090A
Both IDs will require their own:
- Preamble (
101010101) - Header (
00000001) - 40-bit ID Data
- 4-bit Parity
- Stop Bit
Step 1: Calculate Manchester-Encoded Bitstream
We’ll convert each ID into the full Manchester-encoded sequence.
ID 1 → 0102030405
Binary Representation (40-bit ID Data)
0000 0001 0000 0010 0000 0011 0000 0100 0000 0101
Manchester Encoding
PREAMBLE 101010101
HEADER 00000001
DATA 00000001 00000010 00000011 00000100 00000101
PARITY 1 1 1 1
STOP BIT 1
ID 2 → 060708090A
Binary Representation (40-bit ID Data)
0000 0110 0000 0111 0000 1000 0000 1001 0000 1010
Manchester Encoding
PREAMBLE 101010101
HEADER 00000001
DATA 00000110 00000111 00001000 00001001 00001010
PARITY 1 1 1 1
STOP BIT 1
Step 2: Memory Block Layout
Each T5577 block stores 32 bits. We will split the encoded data across multiple blocks to fit both sequences.
Encoded Data Layout
| Block | Data | Content |
|---|---|---|
| Block 0 | 0x00148041 |
Config: Direct Data Mode + Manchester Encoding |
| Block 1 | 0xAAAAAAA5 |
Preamble + Header (ID 1) |
| Block 2 | 0x01020304 |
ID 1 Data (Partial) |
| Block 3 | 0x05F00000 |
ID 1 Data + Parity + Stop Bit |
| Block 4 | 0xAAAAAAA5 |
Preamble + Header (ID 2) |
| Block 5 | 0x06070809 |
ID 2 Data (Partial) |
| Block 6 | 0x0AF00000 |
ID 2 Data + Parity + Stop Bit |
Step 3: Programming the T5577
Using Proxmark3, you can write these blocks as follows:
lf t55xx write -b 0 -d 0x00148041 # Config: Direct Data Mode + Manchester
lf t55xx write -b 1 -d 0xAAAAAAA5 # Preamble + Header (ID 1)
lf t55xx write -b 2 -d 0x01020304 # Data for ID 1
lf t55xx write -b 3 -d 0x05F00000 # Data for ID 1 + Parity/Stop Bit
lf t55xx write -b 4 -d 0xAAAAAAA5 # Preamble + Header (ID 2)
lf t55xx write -b 5 -d 0x06070809 # Data for ID 2
lf t55xx write -b 6 -d 0x0AF00000 # Data for ID 2 + Parity/Stop Bit
Step 4: Tuning Configuration for Dual ID Transmission
Since T5577 cannot naturally break the encoded data into two distinct transmissions, we can use gap control by adjusting the clock divider or inserting a small delay pattern between the two IDs.
For example:
- Insert a block with
0x00000000or0xFFFFFFFFas padding between the two IDs. - Adjust Block 0 timing settings for optimal performance.
Example Timing Adjustment (with padding):
lf t55xx write -b 0 -d 0x00148051
The 0x51 value modifies the clock divider to create a small delay that behaves like a transmission gap.
Step 5: Testing and Verification
- Use
lf t55xx detectto confirm the T5577’s mode and configuration. - Use
lf searchto verify that both IDs are being transmitted correctly. - Adjust the gain or timing parameters if the reader struggles to detect both sequences reliably.
1 Like
Would anyone like to verify this against any hallucinations? I’m swamped 
If it’s not clear, the hope is that with this approach the multi-ID method will be compatible with far more readers because it properly splits up the communication of IDs as if multiple EM4xxx cards had been presented in rapid succession.
I think we have 3 “modes” now for trying this;
- back to back IDs - the original method where the T5577 is performing preamble, header, parity, and stop bit transmission.
- Partial separation - raw mode where preamble is put at the beginning, then header, data, parity, and stop bits are configured for each successive ID, but the preamble is only sent once as this is only necessary for the hardware demod to lock on to the carrier byte stream.
- Full separation - raw mode where the preamble is included for each successive ID.
Options 2 and 3 are all about the preamble because success depends on how the hardware demod and byte stream parser handles the data stream. The preamble may only be looked for once per field coupling by the demod so option 2 would be the way to go, but it may drop carrier lock after a successful stop bit is received so option 3 would be needed for those readers.
1 Like
Is it knows how this code works? Does it just pack the IDs side by side in memory (option 1 above)?
1 Like
If the application allows saving up to 3 keys and there are 6 blocks available, then blocks 1 and 2 correspond to the first ID, 3 and 4 to the second ID, and 5 and 6 to the third ID.
Block 0 should look like this:00148040-1 KEY, 00148080-2 KEYS, 001480C0-3 KEYS. It probably works only with readers connected to a computer via USB. I will make a script.
1 Like
Ah right so 6 blocks means we could only do 2 IDs in raw mode with the extra bits… ok.
2 Likes
Perhaps it’s a waste of time to develop a script that will only work with USB readers. I’ll create a script based on post number 1. Option one – manual entry of EM IDs (2 or 3 IDs), or option two – reading EM4102 IDs through Proxmark3: the first fob, the second fob, and optionally the third fob. Then, writing the blocks to T5577: blocks 1 and 2 for the first EM4102, blocks 3 and 4 for the second EM4102, and optionally the third or none. Any suggestions?
This might be useful. Block zero configures the entire reading process as EM4102. Perhaps someone will find this helpful in a Windows or Linux application for private use.
I am ready to create any Lua script that facilitates work with Proxmark3.
1 Like
yeah any script to improve usability is a good idea i think
1 Like
Tomorrow I will upload the script. It is 90% ready. 
Small graphic adjustments and a few errors to fix. It works as I wanted. It can read the first fob or manually input the ID…second…third…That means writing one, two, or three EM4102 to T5577.
5 Likes
v1.01
lf_t55xx_multiwriter.lua (6.7 KB)
Added option to enter the number engraved on the fob in decimal form.
4 Likes
1.03
lf_t55xx_multiwriter.lua (7.1 KB)
3 Likes
If a specific script needs to be created, I’m open to suggestions. I might take it up in my free time. My building burned down—Spectrum Building in Chadwell Heath—and I’m slowly rebuilding electronic tools and key fobs. In reality, my flat survived, as did many others. However, it was looted by everyone who had access to the building after the fire. We were forbidden from entering to retrieve our belongings. Even pots from flats disappeared, and bank cards were used for public transport. Personally, the value of my electronic equipment and various programmers adds up to around 15,000 pounds. It’s a sad fact that one can be robbed with the permission of the state
4 Likes
Omg this is insane to me. This is one of those situations where property owners properly armed make the difference. Thieves and looters get shot on sight. Can’t enter? No problem. I’ll just stand here with my neighbors and shoot anyone entering.
(I really hate thieves)
3 Likes