Closed hiviah closed 4 years ago
'-1 octets" means "card timeout", i.e. the card didn't respond in the expected time. PR #890 should fix this.
You seem to have general issues with the communication between reader and card. Do you use a Proxmark RDV4? Then try a bigger distance between card and reader.
Could you please send the result of 'hf list 15' after you have tried 'hf 15 csetuid' ?
It was tested on RDV4 and also on the first generation proxmark (which I think has better antennae than default RDV4 antennae from experience). The card is the magic ISO-15693 card which doesn't have a great antenna, hence the timeouts, compared to "proper" ISO-15693 cards.
Should I try this after applying PR #890?
I flashed your PR #890 and it seems to work with the respective client. The magic card has still bad coupling, but it doesn't segfault anymore (first time the list was empty, then it wasn't):
ondro@sylvan proxmark3-pwpiwi-hf15-fix (fix_15_csetuid*) 00:02 % ./client/proxmark3 /dev/ttyACM0
Prox/RFID mark3 RFID instrument
bootrom: RRG/Iceman/master/ed0bbe4 2019-11-09 22:08:49
os: fix_15_csetuid/v3.1.0-163-gc617e3a-dirty-suspect 2019-12-02 22:57:59
fpga_lf.bit built for 2s30vq100 on 2019/11/13 at 14:26:12
fpga_hf.bit built for 2s30vq100 on 2019/11/13 at 14:52:19
SmartCard Slot: not available
uC: AT91SAM7S256 Rev A
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes. Used: 145443 bytes (55%). Free: 116701 bytes (45%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 256K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory
proxmark3> hf 15 reader
#db# 12 octets read from IDENTIFY request:
#db# NoErr CrcOK
#db# 00 00 ca a5 c1 1e 66 24
#db# 16 e0 4e bc
#db# UID = E01624661EC1A5CA
proxmark3> hf 15 reader
#db# 12 octets read from IDENTIFY request:
#db# NoErr CrcOK
#db# 00 00 ca a5 c1 1e 66 24
#db# 16 e0 4e bc
#db# UID = E01624661EC1A5CA
proxmark3> hf 15 dump
Reading memory from tag
UID: E01624661EC1A5CA
Manufacturer byte: 16, EM Microelectronic-Marin SA Switzerland
Chip ID: 24, EM4233 [IC id = 09] 23,5pF CustomerID-102
Block 00 3F 08 1A 4D ?..M
Block 01 82 18 60 20 ..`
Block 02 00 38 00 30 .8.0
Block 03 1C 48 33 00 .H3.
Block 04 1B 00 00 00 ....
Block 05 00 00 00 00 ....
Block 06 00 00 00 00 ....
Block 07 00 00 00 00 ....
Block 08 00 00 00 00 ....
Block 09 00 00 00 00 ....
Block 0a 00 00 00 00 ....
Block 0b 00 00 00 00 ....
Block 0c 00 00 00 00 ....
Block 0d 00 00 00 00 ....
Block 0e 00 00 00 00 ....
Block 0f 00 00 00 00 ....
Block 10 00 00 00 00 ....
Block 11 00 00 00 00 ....
Block 12 00 00 00 00 ....
Block 13 00 00 00 00 ....
Block 14 00 00 00 00 ....
Block 15 00 00 00 00 ....
Block 16 00 00 00 00 ....
Block 17 00 00 00 00 ....
Block 18 00 00 00 00 ....
Block 19 00 00 00 00 ....
Block 1a 00 00 00 00 ....
Block 1b 00 00 00 00 ....
Tag returned Error 15: Unknown error.
proxmark3> hf 15 csetuid E01624661EC1A5DE
new UID | e0 16 24 66 1e c1 a5 de
Using backdoor Magic tag function
card didn't respond
Sending bytes to proxmark failed
Sending bytes to proxmark failed
Can't get new UID.
proxmark3> hf 15 reader
#db# 12 octets read from IDENTIFY request:
#db# NoErr CrcOK
#db# 00 00 de a5 c1 1e 66 24
#db# 16 e0 e8 f1
#db# UID = E01624661EC1A5DE
proxmark3> hf list 15
Recorded Activity (TraceLen = 0 bytes)
Start = Start of Frame, End = End of Frame. Src = Source of transfer
All times are in carrier periods (1/13.56Mhz)
Start | End | Src | Data (! denotes parity error, ' denotes short bytes) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
proxmark3> hf list 15
Recorded Activity (TraceLen = 593 bytes)
Start = Start of Frame, End = End of Frame. Src = Source of transfer
All times are in carrier periods (1/13.56Mhz)
Start | End | Src | Data (! denotes parity error, ' denotes short bytes) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 53248 | Tag | 00 00 ca a5 c1 1e 66 24 16 e0 4e bc | ok |
0 | 53248 | Tag | 00 00 ca a5 c1 1e 66 24 16 e0 4e bc | ok |
4294967168 | 53120 | Tag | 00 00 ca a5 c1 1e 66 24 16 e0 4e bc | ok |
32960 | 65728 | Tag | 00 3f 08 1a 4d be 06 | ok |
33024 | 65792 | Tag | 00 82 18 60 20 6f dc | ok |
33024 | 65792 | Tag | 00 00 38 00 30 98 be | ok |
32960 | 65728 | Tag | 00 1c 48 33 00 9c c7 | ok |
32960 | 65728 | Tag | 00 1b 00 00 00 c3 cc | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
32960 | 65728 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
32960 | 65728 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
32960 | 65728 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
32960 | 65728 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 cf | ok |
33024 | 65792 | Tag | 00 00 00 00 00 77 00 | !crc|
Haha. Lots of room for improvement. I have ordered some of those magic ISO15693 tags. In the meantime I will try some blind fixing. Hope that you are around for testing... 😃
Yes I will have time for testing in the evenings. The magic ISO-15693 tags in themselves are not so expensive, but once you factor in the postage, VAT and customs taxes, it gets a bit pricey.
I have pushed another commit to PR #890. This brings a longer timeout and better error handling for 'hf 15 csetuid'. The output of 'hf list 15' has improved as well. And as a side effect, 'hf 15 cmd write -o' now reports success and errors as well.
I've tried the latest commit 0046522eaddf040a33dc0da90a8049ba6fa8bf64, but for some reason it seems the hf 15 csetuid
stopped working with the card, the UID stays the same after several attempts (strange that UID read still works):
proxmark3> hf 15 reader
#db# 12 octets read from IDENTIFY request:
#db# NoErr CrcOK
#db# 00 00 91 5f 01 20 66 24
#db# 16 e0 b7 e9
#db# UID = E016246620015F91
proxmark3> hf 15 reader
#db# 12 octets read from IDENTIFY request:
#db# NoErr CrcOK
#db# 00 00 91 5f 01 20 66 24
#db# 16 e0 b7 e9
#db# UID = E016246620015F91
proxmark3> hf 15 csetuid E016246620015F97
Using backdoor Magic tag function
card didn't respond
old UID : E0 16 24 66 20 01 5F 91
new UID : E0 16 24 66 20 01 5F 91
proxmark3> hf 15 csetuid E016246620015F97
Using backdoor Magic tag function
card didn't respond
old UID : E0 16 24 66 20 01 5F 91
new UID : E0 16 24 66 20 01 5F 91
proxmark3> hf 15 csetuid E016246620015F97
Using backdoor Magic tag function
card didn't respond
old UID : E0 16 24 66 20 01 5F 91
new UID : E0 16 24 66 20 01 5F 91
[... repeated ...]
proxmark3> hf list 15
Recorded Activity (TraceLen = 1346 bytes)
Start = Start of Frame, End = End of Frame. Src = Source of transfer
All times are in carrier periods (1/13.56Mhz)
Start | End | Src | Data (! denotes parity error, ' denotes short bytes) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 22016 | Rdr | 26 01 00 f6 0a | ok | INVENTORY
26368 | 79616 | Tag | 00 00 91 5f 01 20 66 24 16 e0 b7 e9 | ok |
0 | 22016 | Rdr | 26 01 00 f6 0a | ok | INVENTORY
26304 | 79552 | Tag | 00 00 91 5f 01 20 66 24 16 e0 b7 e9 | ok |
0 | 22016 | Rdr | 26 01 00 f6 0a | ok | INVENTORY
26368 | 79616 | Tag | 00 00 91 5f 01 20 66 24 16 e0 b7 e9 | ok |
192 | 38592 | Rdr | 02 21 3e 00 00 00 00 e9 8f | ok | WRITEBLOCK
0 | 22016 | Rdr | 26 01 00 f6 0a | ok | INVENTORY
26368 | 79616 | Tag | 00 00 91 5f 01 20 66 24 16 e0 b7 e9 | ok |
0 | 22016 | Rdr | 26 01 00 f6 0a | ok | INVENTORY
[... repeated ...]
The previous tag c617e3a3291b0e885dd81a62f0a07bfa067c71ee works OK:
proxmark3> hf 15 reader
#db# 12 octets read from IDENTIFY request:
#db# NoErr CrcOK
#db# 00 00 8e 5f 01 20 66 24
#db# 16 e0 7d 03
#db# UID = E016246620015F8E
proxmark3> hf 15 csetuid E016246620015F91
new UID | e0 16 24 66 20 01 5f 91
Using backdoor Magic tag function
card didn't respond
Sending bytes to proxmark failed
Sending bytes to proxmark failed
Can't get new UID.
proxmark3> hf 15 csetuid E016246620015F91
new UID | e0 16 24 66 20 01 5f 91
Using backdoor Magic tag function
received 12 octets
00 00 91 5F 01 20 66 24 16 E0 B7 E9
Sending bytes to proxmark failed
Sending bytes to proxmark failed
Can't get new UID.
proxmark3> hf 15 reader
#db# 12 octets read from IDENTIFY request:
#db# NoErr CrcOK
#db# 00 00 91 5f 01 20 66 24
#db# 16 e0 b7 e9
#db# UID = E016246620015F91
OK, I can see from your trace that there is no response from the 1st magic command. Somehow I expected something and aborted when there is no response. Pushed another commit to PR #890 which never aborts the sequence of magic commands.
You also complained about bad coupling. Can you please run 'hf plot' after the 'hf 15 csetuid' and post the graph? It would be interesting to see the signal quality from the card.
This seems to work very nicely. I think I got the UID changed on first try every time.
Link to plot after csetuid (github doesn't seem want to upload it) - https://i.imgur.com/2C5h7oe.png
The signal is pretty strong - no indication of bad coupling from card to reader. How does it change with increased distance?
Can you please provide another 'hf list 15' output after a successful 'hf 15 csetuid'?
These are readings from about 1, 2 and 3 cm distances - https://imgur.com/a/BnlrXse (see the labels, the album seems have been rearranged).
So it likely means that the signal is OK, getting weaker with distance, just maybe the timing of the circuit on the magic card is weird? (since non-magic cards had far less timeouts before these tweaks)
My magic tags arrived. Confirmed that everything now works as expected and stable.
This is tested on latest tag as from now, 00848e096b408a43786ea283d4e77d32189994b9 and tag e938f7101179641c9478e9c914bc1bb3ee171570 few days ago. There is signed/unsigned integer confusion first and also the received count shouldn't be negative:
I'd guess the -1 octets doesn't sit well with sprintf as resp.arg[0] is unsigned long.