Open cjf12harry opened 4 years ago
I cannot yet confirm this issue. Writing blocks works fine for me. Can you please send the output from hf iclass reader 1
? What type of iClass card do you use?
These are unused tag I got from ebay, nothing special. I tried three of them, but encounter the same write issue.
hf iclass reader 1
CSN: xx xx xx 0c fe ff 12 e0
CC: fe ff ff ff ff ff ff ff
Mode: Application [Locked]
Coding: ISO 14443-2 B/ISO 15693
Crypt: Secured page, keys not locked
RA: Read access not enabled
Mem: 2 KBits/2 App Areas (32 * 8 bytes) [1F]
AA1: blocks 06-12
AA2: blocks 13-1F
AppIA: ff ff ff ff ff ff ff ff
: Possible iClass (legacy tag)
reading the configuration block returns
proxmark3> hf iclass readblk b 01 k 0
CSN: xx xx xx 0c fe ff 12 e0
Authenticating with legacy diversified key: xx xx cd d7 7f 6d ba 50
Block 01: 12 ff ff ff 7f 1f ff 3c
For the hardware, I am using Proxmark 3.0 easy. I didn't install the low frequency antenna, since I am doing only iclass.
proxmark3> hw tune
Measuring antenna characteristics, please wait..........
# LF antenna: 0.00 V @ 125.00 kHz
# LF antenna: 0.00 V @ 134.00 kHz
# LF optimal: 0.00 V @ 12000.00 kHz
# HF antenna: 28.68 V @ 13.56 MHz
# Your LF antenna is unusable.
I cannot see anything special with your tag's config. Both authentication and reading of block 7 are allowed. Same key used to authenticate read and write.
Your antenna is OK - your trace doesn't show any communication issue.
At the moment I can only think of that your card responds exceptionally slow to write commands. Can you please try to increase ICLASS_READER_TIMEOUT_UPDATE
in armsrc/iclass.c? You can see if your modification was successful, when the time between the three Update commands in your trace increases accordingly (or if the card responds).
Start | End | Src | Data (! denotes parity error, ' denotes short bytes) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 5632 | Rdr | 0a | | ACTALL
9344 | 11392 | Tag | <SOF> | |
15488 | 21120 | Rdr | 0c | | IDENTIFY
24832 | 69888 | Tag | xx xx xx c1 ff 5f 02 1c b7 4d | ok |
73984 | 112384 | Rdr | xx xx xx 89 c1 ff 5f 02 1c | | SELECT
116096 | 161152 | Tag | xx xx xx 0c fe ff 12 e0 5e 83 | ok |
789568 | 799296 | Rdr | 88 02 | | READCHECK[Kd](2)
803008 | 839872 | Tag | fe ff ff ff ff ff ff ff | ok |
1398848 | 1437248 | Rdr | 05 00 00 00 00 d9 0a 52 84 | | CHECK
1440960 | 1461440 | Tag | 97 9a d7 78 | ok |
2008704 | 2075776 | Rdr | 87 07 01 02 03 04 05 06 07 08 62 3a e2 11 18 f9 | | UPDATE(7)
3526464 | 3593536 | Rdr | 87 07 01 02 03 04 05 06 07 08 62 3a e2 11 18 f9 | | UPDATE(7)
5044224 | 5111296 | Rdr | 87 07 01 02 03 04 05 06 07 08 62 3a e2 11 18 f9 | | UPDATE(7)
Above is the result of extending the retry delay. The time spacing grows from 16ms to 108ms. Still there is no response from the card.
To see if my hf antenna can write things to a card, I found a Mifare 13.56MHz card and write in some random data. It is working in this case.
proxmark3> hf mf wrbl 51 A FFFFFFFFFFFF FFFFFFFFFFFFFF078069FFFFFFFFFFFF
--block no:51, key type:A, key:ff ff ff ff ff ff
--data: ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff
#db# WRITE BLOCK FINISHED
isOk:01
proxmark3> hf mf wrbl 52 A FFFFFFFFFFFF 00000000000000000000000000000000
--block no:52, key type:A, key:ff ff ff ff ff ff
--data: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#db# WRITE BLOCK FINISHED
isOk:01
In order to rule out antenna issues I did some checks with a Proxmark RDV3 Easy and measured the maximum possible antenna distance for both readblk and writeblk operations. I could do reliable reads and writes at a maximum distance of 6.3 cm. We therefore can even exclude that write operations draw substantially more power than read operations and therefore could cause the issues.
This is at least true for my iClass DP and iClass DL cards. Which type of card do you have under test?
Edited: reading/writing distance is in cm, not mm.
I am using iClass tags, those blue key fob. I don't have more information about these keys than the read info blocks I post above. Do you know how to get lower level debug information than the log trace? I want to see if the tag responded (but not received by proxmark client).
Fobs are usually more tricky than cards because of their smaller antenna size. But coupling seems to be OK - your trace looks good and the communication for writing isn't different from reading (reader sends a command and tag answers in both cases).
For lower level debugging I can think of two options:
hf plot
. With the default setting of ICLASS_READER_TIMEOUT_UPDATE
this would be the signal from approx. 14.2 ms to 16ms after the last Update command has been sent, i.e. you would most probably see nothing if the tag had already responded earlier. By stepwise reducing ICLASS_READER_TIMEOUT_UPDATE
you could piece together the response signal (if there is any). Use hf plot
after a successful hf iclass readblk
to see how a signal could look like and how strong it could be.I have exactly same issue.
Hey, I'm wondering if this is relating to issue #820 ? Do you have a card listed in that page - I still haven't been able to test writing since that fix..
Currently I don't have the iclass 2000, need to order some to continue testing.
There's a description in there of the PicoPass chip being discontinued so the breaking change might be trickling into other lines too.
It would be possible to test this without ordering new cards by reverting to that older version and seeing if that old version breaks read capability too. Having said that - I might be completely wasting your time here. So I'm sorry in advance if that is the case.
@steve-embling:
Fair enough. For point 2 it does seem conceivable there could be subtle accidental changes in timing or behaviour that would break some kind of assumption made by the Proxmark but still maintain backwards compatibility with official readers.
The PR that appeared to fix the referenced issue was quite busy so I've no idea what the change was that got the card I could previously not read to suddenly start reading (it wasn't my own card so I couldn't test anything potentially destructive like writing). But the lack of response on the other post led me to believe that maybe it wasn't a common issue and writing hadn't been tested yet (and potentially why it hasn't been closed). I just stumbled across this issue after checking on the status of the other.
But yes, happy to accept I'm completely wrong here, and apologies.
I couldn't find one of those problematic cards, i.e. up to now I could read all iClass cards even before the respective PRs, although not very reliable. And I didn't receive a conclusive feedback from anyone that issue #820 is fixed. I therefore keep it open until I find a card which shows the issue or someone confirms that a card couldn't be read before and can be read after the fix. If you can confirm that, I will close #820.
Regarding point 2 I would agree with your assumption. The Proxmark showed some weird behaviour with the iClass implementation and I believe that most iClass operations succeeded only by chance and because of many retries. I cannot really prove this statement because at this time there had not been a usable iClass tracing as well.
There is also the possibility that those problematic cards have ISO15693 disabled and communicate using ISO14443B only. Proxmark doesn't support those iClass cards yet.
Same issue here. Unable to write.
Edit: These cards can't be ISO14443B-only because according to HID paper they are non-ISO14443B. So they don't even support it. Upd: Probably a preprogrammed readonly card...?
I can read block from iclass card, but couldn't write it.
The following is the trace
Looks like the card didn't response to the update command.
Here is the firware and hardware infor