Chipping myself for college - Cloning HID card to xEM with Proxmark3 RDV4

Chipping myself for college


Hi there! I’m making this thread to chronicle my post-implant RFID journey. Here’s my situation. I go to a college (university) which, like many, many colleges in the US, uses HID-branded “OneCards” for building access, dining hall swipes, printing/photocopying, vending machines, etc. My ultimate goal is to be able to have an implanted chip act as my OneCard. This way, it’ll be impossible for me to forget it when leaving my dorm!

So far, I’ve collected a bunch of information and understanding from all over the web about this process to get to where I am now. In an effort to share this, and to clarify and log it for myself, I’ve decided to create this thread. Feel free to add questions and (please!) advice.

Search tags: xEM, Proxmark3 RDV4, HID, clone, clone OneCard

xEM and Implantation

Two weeks ago I got an xEM implant.

I bought this implant before the NExT came out, and kinda forgot about the NExT. Maybe I’ll get one of those too, someday. For now, the xEM will work for me!

The procedure went flawlessly and I’m very happy with the implant location. It’s almost completely healed. It was VERY worth it for me to go to a piercer who was familiar and safe with the procedure than attempt to do it myself.

Testing with the xEM Access Controller

The xEM Access Controller is an all-in-one device sold by Dangerous Things for detecting and authenticating low frequency (LF) RFID tags like the xEM. It has a cylindrical antenna which is wound specifically to couple well with the antenna in the small, cylindrical xEM antenna. I had an xEM Access Controller that came with my xEM chip, so a day after getting the implant I fired up the Access Controller and used it to test my chip.

I didn’t have a 12 volt power-source to power the Access Controller with, so I used a 7–8v one that I found in a drawer. It seems to work fine.

I presented the master tag and then presented my hand with the implant a second after. Sure enough, the chip was registered and after that, presenting my hand lit the red LED. Also, the white signal wire went high to 7v (not 12) which was expected.

With this information, I was confident my chip was working properly, acting as an LF em4100 type tag.

Understanding RFID and the xEM

Here’s my understanding of the xEM implant in the context of RFID technologies. I will present it in bullet-point form.

  • RFID and NFC are similar if not pretty much the same technology.
  • There are different frequencies of RFID/NFC tags/readers: 125kHz (Low Frequency) and 13.56MHz (High Frequency). They’re not cross-compatible.
  • Most readers on my campus are 125kHz (LF), so is the xEM, we’ll discuss be talking about this frequency from now on.
  • LF tags generally don’t support any encryption. Most LF systems just grab the ID of the card and use that to decide to open/not open a door for example. This makes LF systems easy to clone/fake/spoof.
  • Within 125kHz tags, there are different types of tags.
  • The xEM’s hardware (or chipset, the actual chip inside it) is called the Atmel ATA5577 chip, also referred by t5577 or t55xx later in the post.
  • This chip is an emulation chip which, with a bit of configuration, can act as many different types of RFID tags. Note the distinction here between chip (hardware) and tag (protocol).
  • The xEM ships from Dangerous Things in EM41xx (EM4100) mode. This is mode of emulation that the T5577 chip supports. EM41xx seems to be most common for one-off or hobbyist uses. The xEM Access Controller reads EM41xx tags, and the tags it comes with are EM41xx.
  • You can switch the xEM’s T5577 chip from EM41xx emulation mode to HID emulation mode. HID is another of the many tag types the T5577 chip supports.

To achieve my goal I need to read my campus OneCard and take note of the tag ID. Then I need to clone that tag ID to my xEM, in doing so switching my xEM from EM41xx mode to HID mode and writing the ID number to it. Then I should be able to unlock doors with it!

To interface with all these cards and tags, I ordered the Proxmark3 RDV4 from Hacker Warehouse.

Next: I struggle with the Proxmark3, antenna woes and whoas. Stay tuned (haha).


RFID is the underlying technology for everything. Every tag is an RFID tag. When it comes to passive NFC technology, it’s just a narrow sub-specification of RFID that defines specific RFID tag types as “NFC Compliant” and there are several types; type 1, 2, 3, 4, and 5… therefore, all passive NFC tags are also RFID tags, but not all RFID tags are NFC compliant.

Correct… and furthermore, frequency does not denote compatibility either… so two 13.56MHz tags might be completely incompatible… for example, ISO14443 and ISO15693 are both 13.56MHz passive RFID tag technologies, but they are not compatible. Diving in a little deeper, two ISO14443 tags might not even be compatible because the frequency and standards are all about how to move data and power, not what the application data actually is, what it means, how it’s stored, what the chip features are, or what commands the chip supports are. Think of an ISO14443 tag like a vehicle… that vehicle could have different storage capacity (is it a truck or a moped), might carry 2 people or 7, or might be small enough to drive through the back streets of London or be an 12 foot wide M1A1 Abrams tank that will tear down buildings as it tries to drive those same streets… and often application developers and software engineers care only about their application… so if their applications only require a small car they will build roads and buildings around that small car and your Abrams tank won’t work… even though it’s a vehicle all the same as that car and they both run on gasoline… they are not anything alike when it comes to capabilities or how an application might be able to use those capabilities.

In short, “compatibility” is almost never a given.

Well, yes and no… the tags rarely do in the wild, but there are entire families of LF tags that do including automotive key tags, the HITAG 2048 S that I had in my right hand for a few years back in the day… capabilities has nothing to do with frequency or tag types and everything to do with the market and why people are buying the chips they are… in fact, most of the time, popularity of chip types and the rise and fall of various features is all about cost. Encryption costs more. That’s why it’s hardly used for access control where tons of cards are made and lost and bought every year… but when you toss in policy and legal requirements for security, suddenly you start seeing more and more of that pop up in the types of chips being purchased.

The only legit reason LF chips with encryption are not as popular as HF chips is bandwidth. The lower the frequency, the slower the data transmission… and once you make security a requirement for someone, they are gonna want to start expanding the utility of the chip they are being forced to buy, and that usually means storing more data… and that means pushing more data back and forth over the air… so you want that process to be fast… because people hate waiting for their technology.

You can remove the frequency part… “there are different types of tags.” is accurate for any family grouping methodology.


The term “emulation” is my word for it… but it’s a bit of a cheat. An actual “emulator” is usually a general purpose computing device that is running software that alters the analog front end performance and dynamically changes the way things work… the T5577 is a very simple “emulator” that doesn’t dynamically decide to do things on its own, but can be configured to behave a certain way, within specific parameters.


Yep… but these “modes” are just names I’ve given certain configurations of the analog front end of the chip and data encoding schemes. It’s like saying HID cars are blue and run on gasoline and EM cars are red and run on diesel fuel… and the T5577 is this kind of amorphous blob that you paint blue and dump gas into and it’s now an HID car… or you can paint it red and put diesel fuel into it and now it’s an EM car… and there are a lot of different cars out there that the T5577 can look and smell like… but it will never be an Abrams tank.


continued from above

“The Proxmark is Here”

On Monday the Proxmark3 RDV4 I ordered arrived. It’s a beauty of a device, even comes in a sleek plastic case.

Setting it up wasn’t easy, just like the proxmark3 repository warns:

It should be pointed out quite early that the proxmark3 is not really for beginners. If you are not already fairly familiar with electronics, embedded programming, some RF design and ISO standards, this device will probably bring you more frustration than anything else ! Users that do not understand the basic principles behind RFID may have difficulty using the device.

While I’m not specifically familiar with RF designs and ISO standards, I’m savvy and persistent, which I hope will do the trick.

I chose to use the Iceman fork (from the RfidResearchGroup GitHub organization, also called the RRG repo) of the Proxmark3 software, since it’s designed specifically for the RDV4 version of the Proxmark3 device (the latest hardware release, smaller and more powerful). Since the Proxmark3 is open source, there are many forks of its software. I use macOS and Homebrew so the first step was to follow these instructions. The brew install proxmark3

command gave me an error saying there wasn’t a installable stable version, so I had to use brew install --HEAD proxmark3 which successfully installed the most up-to-date version, which is perhaps unstable.

It really is important to flash the latest software to the board, mine wouldn’t successfully connect to my computer without the latest software:

██████╗ ███╗   ███╗ ████╗      ...iceman fork
██╔══██╗████╗ ████║   ══█║       ...dedicated to RDV40 
██████╔╝██╔████╔██║ ████╔╝ 
██╔═══╝ ██║╚██╔╝██║   ══█║
██║     ██║ ╚═╝ ██║ ████╔╝
╚═╝     ╚═╝     ╚═╝ ╚═══╝  pre-release v4.0

Support iceman on patreon -
                 on paypal -

[=] Using UART port /dev/tty.usbmodemiceman1 
[!!] ERROR: cannot communicate with the Proxmark

[+] About to use the following files:
[+]     /usr/local/Cellar/proxmark3/HEAD-960d8c4/bin/../share/proxmark3/firmware/bootrom.elf
[+]     /usr/local/Cellar/proxmark3/HEAD-960d8c4/bin/../share/proxmark3/firmware/fullimage.elf
[+] Waiting for Proxmark3 to appear on /dev/tty.usbmodemiceman1 
[+] Entering bootloader... 
[+] (Press and release the button only to abort )
[+] Waiting for Proxmark3 to appear on /dev/tty.usbmodemiceman1 
[!!] ====================== OBS ! =========================================== 
[!!] Note: Your bootloader does not understand the new CMD_BL_VERSION command  
[!!] It is recommended that you first update your bootloader alone,  
[!!] reboot the Proxmark3 then only update the main firmware 

[=] Available memory on this board: UNKNOWN 

[!!] ====================== OBS ! ====================================== 
[!!] Note: Your bootloader does not understand the new CHIP_INFO command  
[!!] It is recommended that you first update your bootloader alone,  
[!!] reboot the Proxmark3 then only update the main firmware 

[=] Permitted flash range: 0x00100000-0x00140000
[+] Loading ELF file /usr/local/Cellar/proxmark3/HEAD-960d8c4/bin/../share/proxmark3/firmware/bootrom.elf 
[+] Loading usable ELF segments:
[+]    0 : V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
[+]    1 : V 0x00200000 P 0x00100200 (0x00000e30->0x00000e30) [R X] @0x298

[+] Loading ELF file /usr/local/Cellar/proxmark3/HEAD-960d8c4/bin/../share/proxmark3/firmware/fullimage.elf 
[+] Loading usable ELF segments:
[+]    0 : V 0x00102000 P 0x00102000 (0x00040068->0x00040068) [R X] @0x94
[!!] Error: PHDR is not contained in Flash
[+] All done. 

Have a nice day!

I followed the instructions from the main proxmark3 repo Wiki to upgrade the bootloader. I ended up having to do the Upgrading Proxmark3 from HID to CDC step and there was some trouble finding where the client and proxmark3 directories were (maybe because of Homebrew installation?). Now as I’m writing this, I figure out what the issue was. I think things I needed ended up being in usr/local/something (In retrospect probably /usr/local/Cellar/proxmark3/HEAD-960d8c4/share/proxmark3/firmware/bootrom.elf and fullimage.elf like the pm3 software told me. Or maybe just /usr/local/share/proxmark3? there’s some weird symlinking stuff going on that I don’t understand.) Anyway once I found the right files and flashed everything it worked great, went really fast:

██████╗ ███╗   ███╗ ████╗      ...iceman fork
██╔══██╗████╗ ████║   ══█║       ...dedicated to RDV40 
██████╔╝██╔████╔██║ ████╔╝ 
██╔═══╝ ██║╚██╔╝██║   ══█║
██║     ██║ ╚═╝ ██║ ████╔╝
╚═╝     ╚═╝     ╚═╝ ╚═══╝  pre-release v4.0

Support iceman on patreon -
                 on paypal -

[=] Using UART port /dev/tty.usbmodemiceman1 
[+] About to use the following files:
[+]     /usr/local/share/proxmark3/firmware/bootrom.elf
[+]     /usr/local/share/proxmark3/firmware/fullimage.elf
[+] Waiting for Proxmark3 to appear on /dev/tty.usbmodemiceman1 
[+] Entering bootloader... 
[+] (Press and release the button only to abort )
[+] Waiting for Proxmark3 to appear on /dev/tty.usbmodemiceman1 
[=] Available memory on this board: 512K bytes

[=] Permitted flash range: 0x00100000-0x00180000
[+] Loading ELF file /usr/local/share/proxmark3/firmware/bootrom.elf 
[+] Loading usable ELF segments:
[+]    0 : V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
[+]    1 : V 0x00200000 P 0x00100200 (0x00000e30->0x00000e30) [R X] @0x298

[+] Loading ELF file /usr/local/share/proxmark3/firmware/fullimage.elf 
[+] Loading usable ELF segments:
[+]    0 : V 0x00102000 P 0x00102000 (0x00040068->0x00040068) [R X] @0x94
[+]    1 : V 0x00200000 P 0x00142068 (0x00001540->0x00001540) [RW ] @0x400fc
[=] Note: Extending previous segment from 0x40068 to 0x415a8 bytes

[+] Flashing... 

[+] Writing segments for file: /usr/local/share/proxmark3/firmware/bootrom.elf
[+]  0x00100000..0x001001ff [0x200 / 1 blocks]
[+]  0x00100200..0x0010102f [0xe30 / 8 blocks]

[+] Writing segments for file: /usr/local/share/proxmark3/firmware/fullimage.elf
[+]  0x00102000..0x001435a7 [0x415a8 / 523 blocks]

[+] All done. 

Have a nice day!

Then I could plug in the Proxmark3, fire up my terminal and type pm3 and it would be auto-detected and connect. Here’s what that looked like:

██████╗ ███╗   ███╗ ████╗      ...iceman fork
██╔══██╗████╗ ████║   ══█║       ...dedicated to RDV40 
██████╔╝██╔████╔██║ ████╔╝ 
██╔═══╝ ██║╚██╔╝██║   ══█║
██║     ██║ ╚═╝ ██║ ████╔╝
╚═╝     ╚═╝     ╚═╝ ╚═══╝  pre-release v4.0

Support iceman on patreon -
                 on paypal -

[=] Using UART port /dev/tty.usbmodemiceman1 
[=] Communicating with PM3 over USB-CDC 

 [ Proxmark3 RFID instrument ] 

  client: RRG/Iceman
  compiled with Clang/LLVM 4.2.1 Compatible Apple LLVM 10.0.1 (clang-1001.0.46.4) OS:OSX ARCH:x86_64

  external flash:                  present 
  smartcard reader:                present 

 [ PROXMARK RDV4 Extras ]
  FPC USART for BT add-on support: absent 

 [ ARM ]
  bootrom: RRG/Iceman/master/960d8c4 2019-09-15 00:42:55
       os: RRG/Iceman/master/960d8c4 2019-09-15 00:43:06
  compiled with GCC 5.4.1 20160919 (release) [ARM/embedded-5-branch revision 240496]

 [ FPGA ]
  LF image built for 2s30vq100 on 2019-07-31 at 15:57:16
  HF image built for 2s30vq100 on 2018-09-03 at 21:40:23

 [ Hardware ] 
  --= uC: AT91SAM7S512 Rev A
  --= Embedded Processor: ARM7TDMI
  --= Nonvolatile Program Memory Size: 512K bytes, Used: 275878 bytes (53%) Free: 248410 bytes (47%)
  --= Second Nonvolatile Program Memory Size: None
  --= Internal SRAM Size: 64K bytes
  --= Architecture Identifier: AT91SAM7Sxx Series
  --= Nonvolatile Program Memory Type: Embedded Flash Memory

[usb] pm3 --> 

Hooray! I now ran through the suggested setup steps found on the RRG wiki.

Now I had a functional Proxmark3 RDV4 which I could put to use snooping, reading, and cloning tags.

Logistical Note: The Proxmark3 RDV4 was USD$310. I don’t feel that the one thing I need the proxmark for justifies the entire purchase of the device, and I’d love to see how I can share its value with the community. (Once this whole ordeal is over) direct message me if you’re in the US and need access to a Proxmark3 and maybe we can figure out a way to ship it around and share the value.

Next time: Testing the Proxmark3 on known tags.
Then: Troubles writing to the xEM and a T5577 card

Next steps -> figure out how to write to the T5577 card included with the pm3, build cylindrical antenna out of xEM Access Controller while waiting for DT xEM antennae to be released :slight_smile:


continued from above

Testing the Proxmark3 on known tags

Now I had a working Proxmark3. It was time to try and read some tags. Always use the help commands to figure out possible parameters! There’s a opaque tree of categories and commands in the pm3 software and there’s a help text at each branch and leaf.

I was able to read my xEM using lf search:

(I’ve replaced a bunch of numbers with N or n in these outputs to obfuscate data. No idea if that’s important but butter safe than sorry.)

[usb] pm3 --> lf search
[=] 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      : 0410NNNNNN 

Possible de-scramble patterns

Unique TAG ID  : 2008NNNNNN
HoneyWell IdentKey {
DEZ 8          : 04NNNNNN
DEZ 10         : 0272NNNNNN
DEZ 5.5        : 0415N.NNNNNN
DEZ 3.5A       : 00N.NNNNN
DEZ 3.5B       : 01N.NNNNN
DEZ 3.5C       : 06N.NNNNN
DEZ 14/IK2     : 00017452NNNNNN
DEZ 15/IK3     : 000137581NNNNNN
DEZ 20/ZK      : 02000008071211NNNNNN
Other          : 03350_062_04NNNNNN
Pattern Paxton : 72NNNNNN [0x4NNNNNN]
Pattern 1      : NNNNNN [0xNNNNNN]
Pattern Sebury : 3350 62 4NNNNNN  [0xNNN 0xNN 0xNNNNN]

[+] Valid EM410x ID found!

I could also read one of the tags that comes with the xEM Access Controller (configured the same way as the xEM):

[usb] pm3 --> lf em 410x_read
[+] EM410x pattern found


Possible de-scramble patterns

blah blah

Using lf search I could also read my HID OneCard:

[usb] pm3 --> lf search
[=] NOTE: some demods output possible binary
[=] if it finds something that looks like a tag
[=] False Positives ARE possible
[=] Checking for known tags...

[+] HID Prox TAG ID: 2c3fNNnNnn (NNN03) - Format Len: 35bit - OEM: 000 - FC: 5NN - Card: NNN03

[+] Valid HID Prox ID found!

This was great! I now knew a vital piece of information: 2c3fNNnNnn, the 40-bit ID for my OneCard. Soon (I thought) I would be able to use the command lf hid clone 2c3fNNnNnn to simply clone my HID OneCard’s data to my xEM!

Help page for lf hid clone:

Clone HID to T55x7.  Tag must be on antenna. 

Usage:  lf hid clone [h] [l] ID
       h   - This help
       l   - 84bit ID
       ID  - HID id
      lf hid clone 2006ec0c86
      lf hid clone l 2006ec0c86

A quirk of this command is that when running it the output is as follows:

[usb] pm3 --> lf hid clone 2c3fNNnNnn
[=] Preparing to clone HID tag with ID 2c3fNNnNnn

whether or not the command succeeded. Even if no tag is on the antenna, the output is the same. This makes it hard to tell whether the clone succeeded. To test, an lf hid read command must be issued to check if the tag now reads as the correct HID tag.

At this point, I started testing on the test T5577 card that came with the Proxmark3:

This is where I ran into trouble. Most of the commands in the pm3 software act automatically. lf read automatically reads on the low frequencies and tries to automatically parse the results and print them out. If it can do this, you have a strong signal and a valid tag and everything is good, it just prints the data! Everything is amazing and your life is perfect. However, if you’ve a bad tag, or a small, hard-to-read coil (*ahem* xEM) or something else going on, this automatic mode won’t work for you and you’ve gotta use the more manual tools in the pm3 software. These manual tools came first and are more powerful than the automatic functionalities, but they’re harder to learn. Here’s a good overview I read to start to understand interacting with an LF card without the automatic tools:

My sub-goal at this point is to clone my OneCard onto this test T5577 card. If I can do this, it’s the same process as cloning the OneCard to my xEM, but without all the issues caused by bad coupling between the xEM and scanner that have been common for people in the past. If I can do this, I’ll have cracked half of the puzzle: mastering the parts of the pm3 software that I need for my main goal (OneCard on xEM). The other half of the puzzle is getting the Proxmark3 to couple with the xEM, a challenge we’ll discuss later.

But something strange was happening with the T5577 card and the auto tools weren’t working as I expected them. lf t55xx info with the card on the reader gave no result. lf t5 dump gave no data. I decided I would have to use the manual tools, gathering the data, plotting, and demoding it in order to figure out what was up. I haven’t done this yet, so this log is up-to-date with regard to this software half of the puzzle.

In the next few days I’ll be experimenting with the T5577 card and Proxmark3 to find a consistent way to have the two interact. If you have advice about this, please tell me!

Another meta-hint: in the ~/.proxmark3 directory there’s log files with all your pm3 sessions. That’s what I’m using to go back and find out the commands I used and the results I got to write up this report!

Trouble writing to the xEM

In my initial floundering with the Proxmark3, I also played with scanning and writing to my xEM. It didn’t brick it, thank goodness. To my surprise, the xEM was able to be read really easily with the built-in antennae. No sweat whatsoever, just somewhat careful positioning. But not even that careful. (See above for the successful output from that).

However, I wasn’t able to write ANY data whatsoever to the tag. This is a KNOWN ISSUE and wasn’t unexpected to me.

In the past, @TomHarkness has talked about using the lf t55xx trace command to test whether the coupling was good enough to write data, but this command errored with the message: [-] The modulation is most likely wrong since the ACL is not 0xE0., so I couldn’t use that. Anyway, every attempt to lf hid clone 2c3fNNnNnn caused no change to subsequent scans of the xEM.

To isolate variables, I’m testing this with the T5577 card I have first to make sure I have the software process correct before assuming that the coupling between the xEM and Proxmark3 is bad. However, based on reports from others, it’s safe to assume that writing to the xEM won’t work without a non-default antenna.

Required reading:

  • Here’s the story about the xEM and writing data: Quirks of the T5577 & cloning tags to the xEM
    In short, many people were using these Chinese gun-shaped tag reader-writers. You had to get the positioning just right and they were causing xEMs to “soft-brick” (wouldn’t read or write but maybe salvageable with a Proxmark3). Dangerous Things stopped selling them because of this.
  • But GOOD NEWS! @TomHarkness has heard our cries and has designed a new antenna specifically made for the Proxmark3 RDV4 and specifically made to couple flawlessly with the xEM (and other implantable RFID tags). It’s not out yet, but there should be a pre-order soon. Here’s the thread with that whole story: Proxmark LF Antennas

So I’m waiting on Dangerous Things to sell these magic antennae, and in the mean time, I might try to make one that works out of my xEM Access Controller. But that’s for another time. Now this log is up-to-date with my efforts to solve the antenna part of the puzzle.

Next time: I don’t know yet! Let’s hope it’s something like “Writing to T5577 worked like a charm, no problem whatsoever”. We’ll see :slight_smile:

From now on, I’ll post here in near-realtime as I make new discoveries and units of progress.


Oh, and here’s a Medium post which basically shows the Ideal Success Case for what I’m doing, using very slightly different equipment:

Cloning a HID card onto an xEM RFID chip using the Proxmark3 Easy3.0

Those are all the pm3 messages I’d love to see.

1 Like

Nice write up! Quick reply as I’m short on time right now.

Just FYI - don’t use the xem access controller antenna on the rdv4.0. This proxmark version contains the tuning components for the antenna on the actual antenna pcb rather than built in to the rdv4 head unit. This is why the antenna connector is 3 pins, not 2. You now have ground, raw and power pins and you need to add the required and properly tuned LC circuit to tune, limit and adjust the power for any given antenna. This keeps things much more modular but means that those three pins, are direct connections to the LF front end IC / driver.

If you happen to get the tuning way out of whack or connect anything wrongly , you can easily blow that IC or cause it to become degraded due to the sheer power output capabilities of the rdv4.0 - I can get over 120v on the antenna if tuned for it. That same 120v hooked up wrongly will break your LF front end.


Great to know, thanks! This makes my life simpler as I’ll now just work on mastering the pm3 software while waiting for when I can buy special antennas :smiley_cat:

The antennas are close, real close :wink:


Just read this beautiful post by @TomHarkness on the T5577 chip and cloning/scanning. Great info in here.

Also read the T5557 protocol description:

This info will become useful as I try to debug my current inability to write to any T55xx tag (including standard card that came with the Proxmark3 RDV4).

1 Like

Ordered the ProxLF antenna!

1 Like

@TomHarkness Do you have any advice for interacting with T5577 chipset tags with the Proxmark? Should it just work with the t55 commands or is there a trick to using t5577 config to get it to work with the specific tag?

Right now I can’t get anything from the test card that came with my Proxmark.

Updating the Proxmark

I noticed in the past few days Iceman has made a bunch of commits related to cloning and t55. In the interest of having the most up-to-date version of the pm3 software, I decided to update. This turned out to be really easy, following the instructions here:

Even though I already had everything I ran:

  1. brew tap RfidResearchGroup/proxmark3
  2. brew install --HEAD proxmark3

then I got an error saying I already had it installed, so I ran:

  • brew reinstall proxmark3

And then once that succeeded (took 1.5 mins) ran pm3-flash-all with the proxmark connected in bootloader mode.

Everything automatically connected and flashed real quick and I was able to start the software with pm3 as usual.


I saw somewhere to run hw tune every time you start up the Proxmark. I’m going to start doing that now.

1 Like

ProxLF antenna arrives on Monday… Stay tuned!


Cloning success!

So a friend of mine got interested in RFID also and ordered a Chinese blue scanner. Along with it came a few t5577 cards. He gave me one and I tried cloning to it, dead simply: power up Proxmark 3, lf hid clone command with the ID I got from reading a OneCard. Boom, done. Worked perfectly.

[usb] pm3 --> lf hid clone NNNnNNnnnn
[=] Preparing to clone HID tag with ID NNNnNNnnnn
[usb] pm3 -->

I think the t5577 card that came from Hacker Warehouse with the Proxmark 3 must be either faulty or configured in a way I can’t write to. I emailed them about it, asking if they send them out configured a certain way, but haven’t heard back yet.

Let’s hope the ProxLF allows things to be that easy for cloning to my xEM itself!


At last…

I’ve succeeded in my original goal!

My ultimate goal is to be able to have an implanted chip act as my OneCard. This way, it’ll be impossible for me to forget it when leaving my dorm!

I received the ProxLF antenna a few weeks ago. I attached it to the Proxmark 3, ran hw tune, and tried reading my xEM chip and immediately got much clearer readings. The Proxmark could now detect the chipset of my chip, not just its ID. Using lf hid clone as in my previous post worked flawlessly. That’s it! Done!

I can now open doors on my campus using my hand:

My advice to anyone reading: For writing, the correct antenna to couple with your chip! It literally solved all of my problems.

It was great to dive headfirst into the world of RFID and learn a lot about the tech and tools, but in the end I only needed the right equipment and the most basic functions of the Proxmark 3 to achieve my goal.


Great success ! Congratulations.

1 Like

This is a great writeup but there is a point that threw me for a while. When you tell homebrew to tap and install proxmark3, you have to specify RfidResearchGroup/Proxmark3/Proxmark3. If you just put Proxmark3 you will get something else and it won’t be compatible with the iceman firmware. This may seem obvious now but I didn’t see it in any of the linked how to’s.

@Locutus, I haven’t seen @identity for a while. could you please do me a favour.
could you screen shot and indicate where that should be input, I will edit his post and insert

I think at this point:

It should instead have these 2 commands:
Screen Shot 2020-06-03 at 7.50.43 PM