Need help to troubleshoot

Support
1

Hi,

Any help to troubleshoot greatly appreciated.
I can read tags, but seems that I cannot write on them.
The pm3 easy has the latest iceman firmware.
I am try to change the UID (CN) of a tag.
lf search finds an EM4105 ID:
[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...
  [=]
  [+] EM 410x ID 000096B43F
  [+] EM410x ( RF/64 )
  [=] -------- Possible de-scramble patterns ---------
  [+] Unique TAG ID      : 0000692DFC
  [=] HoneyWell IdentKey
  [+]     DEZ 8          : 09876543
  [+]     DEZ 10         : 0009876543
  [+]     DEZ 5.5        : 00150.46143
  [+]     DEZ 3.5A       : 000.46143
  [+]     DEZ 3.5B       : 000.46143
  [+]     DEZ 3.5C       : 150.46143
  [+]     DEZ 14/IK2     : 00000009876543
  [+]     DEZ 15/IK3     : 000000006893052
  [+]     DEZ 20/ZK      : 00000000060902131512
  [=]
  [+] Other              : 46143_150_09876543
  [+] Pattern Paxton     : 11203135 [0xAAF23F]
  [+] Pattern 1          : 6913596 [0x697E3C]
  [+] Pattern Sebury     : 46143 22 1487935  [0xB43F 0x16 0x16B43F]
  [=] ------------------------------------------------
  
  [+] Valid EM410x ID found!
  
  [+] Chipset detection: T55xx
  [?] Hint: try `lf t55xx` commands

lf em 410x clone does not give an error
[usb] pm3 → lf em 410x clone --id 11111111 --em
[+] Preparing to clone EM4102 to EM4305/4469 tag with EM Tag ID 0011111111 (RF/64)
[#] Clock rate: 64
[#] Tag EM4x05 written with 0xff800318c6318c60
However no info on the card has changed:
[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...
  [=]
  [+] EM 410x ID 000096B43F
  [+] EM410x ( RF/64 )
  [=] -------- Possible de-scramble patterns ---------
  [+] Unique TAG ID      : 0000692DFC
  [=] HoneyWell IdentKey
  [+]     DEZ 8          : 09876543
  [+]     DEZ 10         : 0009876543
  [+]     DEZ 5.5        : 00150.46143
  [+]     DEZ 3.5A       : 000.46143
  [+]     DEZ 3.5B       : 000.46143
  [+]     DEZ 3.5C       : 150.46143
  [+]     DEZ 14/IK2     : 00000009876543
  [+]     DEZ 15/IK3     : 000000006893052
  [+]     DEZ 20/ZK      : 00000000060902131512
  [=]
  [+] Other              : 46143_150_09876543
  [+] Pattern Paxton     : 11203135 [0xAAF23F]
  [+] Pattern 1          : 6913596 [0x697E3C]
  [+] Pattern Sebury     : 46143 22 1487935  [0xB43F 0x16 0x16B43F]
  [=] ------------------------------------------------
  
  [+] Valid EM410x ID found!
  
  [+] Chipset detection: T55xx
  [?] Hint: try `lf t55xx` commands

I tried “lf t55xx wipe” but it did not help.

Any help appreciated!

Thanks,
Alex

2

All digital media from magnetic tapes to burning CDs to writing to disks or USB flash drives… pretty much everything that writes data to something in some way… only writes. That is to say that there is no way to know if the data was actually written unless you read it back and compare. Some systems will do this check, but most do not… most just assume it was written successfully and move on. In much the same way, the proxmark3 is spewing the write data commands out into the ether… hoping the tag is hearing them and performing the proper write commands… but there is no way for the proxmark3 to know that this has happened successfully or not. The only way to tell for sure is to try to read it, which you are doing and finding that in fact, the data has not been written.

My guess is that one of the following is true;

  1. you do not have a writable target tag.

  2. you do not have a good enough coupling with your tag to perform the write command, which consumes much more power than a read command.

  3. the target tag is password protected against writes.

  4. your command is wrong.

After reviewing again your command, I see that option 4 was the culprit. Your command is wrong;

lf em 410x clone --id 11111111 --em

You are specifying --em at the end of your command. This is incorrect. You can see from the end of your lf search result that the chipset detected is a T55xx.

When you specify --em in your clone command, you are telling the proxmark3 to attempt to send write commands to an EM4305 chip, not a T55xx chip.

image

Just omit the --em from the end of your clone command and it should work.

lf em 410x clone --id 11111111

Also… you are only specifying 4 bytes there in that ID… not 5… just fyi.

3

Hi Amal,

Thank you for your quick reply.
I tried 4) as you suggested but still does not work.
I can simulate the tag with “lf em 410x sim --id 000096B43F” and I get 0009876543 as a card number, same as I see when reading it with an xCopy-100 or shown by “lf search”.
I tried different tags, some new (read that sometimes the chinese cloners put a password), tried to wipe the tag with “lf t55xx wipe” but still does not help.

lf tune shows a voltage of ~24V without a card, and when I put the card ~7V.

When I start the client I see:
[ Proxmark3 RFID instrument ]

MCU....... AT91SAM7S512 Rev A
Memory.... 512 Kb ( 59% used )

Client.... Iceman/master/v4.15864-11-g97263ab3b 2022-11-02 15:17:37
Bootrom... Iceman/master/v4.15864-11-g97263ab3b 2022-11-02 15:19:12
OS........ Iceman/master/v4.15864-11-g97263ab3b 2022-11-02 15:19:43
Target.... PM3 GENERIC

"hw version gives
[usb] pm3 → hw version

[ Proxmark3 RFID instrument ]

[ CLIENT ]
Iceman/master/v4.15864-11-g97263ab3b 2022-11-02 15:17:37 294e3bfa7
compiled with… MinGW-w64 10.3.0
platform… Windows (64b) / x86_64
Readline support… present
QT GUI support… present
native BT support… absent
Python script support… present
Lua SWIG support… present
Python SWIG support… present

[ PROXMARK3 ]
firmware… PM3 GENERIC

[ ARM ]
bootrom: Iceman/master/v4.15864-11-g97263ab3b 2022-11-02 15:19:12 294e3bfa7
os: Iceman/master/v4.15864-11-g97263ab3b 2022-11-02 15:19:43 294e3bfa7
compiled with GCC 10.1.0

[ FPGA ]
LF image 2s30vq100 2022-03-23 17:21:05
HF image 2s30vq100 2022-03-23 17:21:16
HF FeliCa image 2s30vq100 2022-03-23 17:21:27
HF 15 image 2s30vq100 2022-03-23 17:21:38

[ Hardware ]
–= uC: AT91SAM7S512 Rev A
–= Embedded Processor: ARM7TDMI
–= Internal SRAM size: 64K bytes
–= Architecture identifier: AT91SAM7Sxx Series
–= Embedded flash memory 512K bytes ( 59% used )

I see that the client, bootrom and OS are at the same version (v4.15864-11-g97263ab3b 2022-11-02) but the FPGA runs the 2s30vq100 2022-03-23 image. is this OK?

With best regards, and thank you again,

Alex

4

Hi Alex,

This is confusing for two reasons. First, what do you mean you “get 0009876543 as a card number”? I have no idea what you’re doing here. Are you scanning the proxmark3 while it is emulating a card ID with something? If so, what are you scanning the proxmark3 in sim mode with? The second reason this is confusing is the term “card number” … all digital data is binary in nature… but you can express this binary value in many ways… binary, decimal numbers, hexadecimal numbers, etc. So when you say “card number”… do you mean hexadecimal or decimal? Because if you mean decimal, then you for sure will get a different looking value when that binary data is expressed as a hexadecimal number, like is used in the proxmark sim command, and what that same binary data value might look like when displayed as a decimal number. Also, you will need to define bit and byte boundaries for how those “numbers” are defined, and if there is any MSB / LSB stuff going on too.

Always be verbose when asking for support because we can’t read minds :slight_smile:

… so do you mean you see 000096B43F or 0009876543? … if you are talking about lf search here, do you have two proxmark3 units and you are using the sim command on one to emulate 000096B43F but on your second proxmark3 you are getting 0009876543 when you put the two proxmark3 units together and run lf search ? Somehow I doubt you have two proxmark3 units… but I can’t assume that, and I don’t want to have to expend the mental energy to decipher what you could possibly mean by putting on my Sherlock Holmes hat every time I read a new post. It quickly exhausts energy and I usually charge consulting fees for such efforts :slight_smile:

See what I mean about reading minds? Clarity is key.

that’s a very good indication your coupling is ok… but funny enough, it might be too good actually. You might be stomping on the card’s ability to “talk back”… try separating the card from the proxmark3 by about half and inch or so and try that.

yes this should be ok

At this point I am thinking it might be a good idea to get some more clarity on your source and target card types. Can you post lf search data for both source and target cards? Clearly mark the outputs, and we’ll go from there.

5

Hi Amal,

Thanks again for your help.
I am running on the proxmak3 the “lf em 410x sim --id 000096B43F” command and read the proxmark with an access card reader which outputs in decimal. 0009876543 is the decimal value of the hex value 000096B43F. 000096B43F is the EM card ID shown by lf search and 0009876543 is the DEZ10 value in lf search

1 Like
6

I see both in lf search one is the EM ID in hex, the other same number in decimal
…
[=] Checking for known tags…
[=]
[+] EM 410x ID 000096B43F
[+] EM410x ( RF/64 )
[=] -------- Possible de-scramble patterns ---------
[+] Unique TAG ID : 0000692DFC
[=] HoneyWell IdentKey
[+] DEZ 8 : 09876543
[+] DEZ 10 : 0009876543
…

7

I do not have 2 proxmark units. I have only one with which I can read almost any card, a xCopy-100 and an access card reader. I can write on cards (EM) with the xCopy-100.
I noticed the issue when I tried to copy an AWID card which is read only by proxmark3. To eliminate a possible issue with AWID cards, I tried to copy a 125k card onto another, the source and destination are identical, identified with EM tags and T55xx chipset. The EM 410x ID is different on the source and destination.

8

With best regards,
Alex

9

Tried and is the same. I cannot write on the card with the proxmark3. Using the xCopy-100 I can duplicate the cards.
I need to be able to use the proxmark because I need to copy cards identified as AWID and iClass which are not read by xCopy.

Thanks,
Alex

10

I think this might be the issue. For a time the xcopy was trying to “lock people in”, forcing them to buy xcopy subscriptions, buy cloning credits (pay per clone), and other various methods… I would bet that it has set a password on the target cards and this is why your proxmark cannot change them but the xcopy can.

You might be able to use your proxmark3 to sniff the communication between xcopy and card to get the password actually… dunno but maybe.

11

Sorry for being a grumpy guss… sometimes I get cranky haha. Happy to help though.

12

Hi Amal,

Thank you again for your help and for your patience!

I was thinking that my proxmark3 is defected and considered to return it.
But finally I made it work!

There were the cards I was trying to use!

Some could be written by the xCopy but not by proxmark3. I tried a t5577 card from another source and I can clone to it either EM IDs or AWID IDs using the proxmark3. And I can confirm that after cloning with xCopy I cannot write them anymore with the proxmark. I cloned the AWID card I needed. As long as I do not use the cloned card on the xCopy-100 I can change it to an EM card and back to AWID.
BTW, probably some of the cards I have are write protected and the xCopy puts a password on them. Do you have any pointers on how can I remove the protection?

Thank you again and all the best,

Alex

13

Hi,

I figured it out.

lf search → Chipset detection: T55xx
lf t55xx chk - found valid password: [ 19920427 ]
lf t55xx wipe -p 19920427
Now I can clone on the card
lf em 410x clone --id 10101010aa

Seems that my xCopy-100 puts 19920427 as a password.

Regards,
Alex

3 Likes
14

Yay!