Closed ThorstenEngel closed 9 months ago
Interesting, I never seen a ISO15693 readblock return 8 bytes. Which card is this?
hf 15 info
Dear Iceman,
thank you for replying that quickly! It is a glucose sensor.
[usb] pm3 --> hf 15 info
[+] UID: E0 07 A4 00 0B 3F 72 65
[+] TYPE: Texas Instrument France
[+] Using UID... E0 07 A4 00 0B 3F 72 65
[=] --- Tag Information ---------------------------
[+] TYPE: Texas Instrument France
[+] UID: E0 07 A4 00 0B 3F 72 65
[+] SYSINFO: 00 04 65 72 3F 0B 00 A4 07 E0 FF 07
[+] - DSFID not supported
[+] - AFI not supported
[+] - IC reference not supported
[+] - Tag provides info on memory layout (vendor dependent)
[+] 19 (or 18) bytes/blocks x 90 blocks
hrm.. what is the output from the rdbl command?
hf 15 rdbl
[usb] pm3 -->
[usb] pm3 --> hf 15 rdbl -b 0
[+] UID: E0 07 A4 00 0B 3F 72 65
[+] TYPE: Texas Instrument France
[+] Using UID... E0 07 A4 00 0B 3F 72 65
[=] # 0 |lck| ascii
[=] ------------+---+------
[=] 5C 8E 2A E7 01 07 A1 | 122 | \.*....
[usb] pm3 -->
[usb] pm3 --> hf 15 dump
[+] UID: E0 07 A4 00 0B 3F 72 65
[+] TYPE: Texas Instrument France
[+] Using UID... E0 07 A4 00 0B 3F 72 65
[+] Reading memory from tag UID E0 07 A4 00 0B 3F 72 65
[\]blk 43
[-] Tag returned Error 16: The specified block is not available (doesn't exist).
[=] block# | data |lck| ascii
[=] ---------+--------------+---+----------
[=] 0/0x00 | FF A1 AB A7 | 0 | ....
[=] 1/0x01 | 6A 52 9C 69 | 0 | jR.i
[=] 2/0x02 | 5A A4 FB 57 | 0 | Z..W
[=] 3/0x03 | F8 7D 4C 94 | 0 | .}L.
hm... only seven bytes... odd, what is the trace list?
hf 15 rdbl -b 0
hf 15 list
Here you are (it's another sensor of same type, same odd results):
[usb] pm3 -->
[usb] pm3 --> hf 15 rdbl -b 0
[+] UID: E0 07 A4 00 0B 3F 75 47
[+] TYPE: Texas Instrument France
[+] Using UID... E0 07 A4 00 0B 3F 75 47
[=] # 0 |lck| ascii
[=] ------------+---+------
[=] CD CF 99 B2 8F 95 C3 | 173 | .......
[usb] pm3 -->
[usb] pm3 --> trace list -t 15
[=] downloading tracelog data from device
[+] Recorded activity (trace len = 80 bytes)
[=] start = start of start frame end = end of frame. src = source of transfer
[=] ISO15693 / iCLASS - all times are in carrier periods (1/13.56MHz)
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 22016 | Rdr |26 01 00 f6 0a | ok | INVENTORY
26304 | 79552 | Tag |00 00 47 75 3f 0b 00 a4 07 e0 6d 00 | ok |
320 | 55104 | Rdr |62 20 47 75 3f 0b 00 a4 07 e0 00 83 60 | ok | READBLOCK(0)
59392 | 108544 | Tag |00 ad cd cf 99 b2 8f 95 c3 44 c1 | ok |
[usb] pm3 -->
dump:
[usb] pm3 --> hf 15 dump
[+] UID: E0 07 A4 00 0B 3F 75 47
[+] TYPE: Texas Instrument France
[+] Using UID... E0 07 A4 00 0B 3F 75 47
[+] Reading memory from tag UID E0 07 A4 00 0B 3F 75 47
[-]blk 43
[-] Tag returned Error 16: The specified block is not available (doesn't exist).
[=] block# | data |lck| ascii
[=] ---------+--------------+---+----------
[=] 0/0x00 | AD CD CF 99 | 0 | ....
[=] 1/0x01 | EB 53 22 15 | 0 | .S".
[=] 2/0x02 | A8 C3 87 46 | 0 | ...F
so your tag has one byte flags, no lock info byte and 8 bytes of data.
0 1 2 3 4 5 6 7 8 9 10
00 ad cd cf 99 b2 8f 95 c3 44 c1
-- --
crc
I never seen such. Easier to chat on discord.
Sure, please allow me (borste_52888) to talk to you.
Is the linked PDf relevant? https://www.ti.com/lit/ug/slau603b/slau603b.pdf?ts=1693816505127 in section 4.3 there is reference to a configuration register that allows 4 or 8-byte block types, and custom commands.
@DidierA great find!
What is the output of:
hf 15 rdbl --blk 255
Hi, sorry for the delay. Here is the output:
[usb] pm3 --> hf 15 rdbl --blk 255
[+] UID: E0 07 A4 00 0B 3F 72 65
[+] TYPE: Texas Instrument France
[+] Using UID... E0 07 A4 00 0B 3F 72 65
[!!] iso15693 card returned error 1: The command is not supported
Block 42 is the last block I can read without this error.
By the way: is it normal that when sniffing the communication (there exists a reader hw for this tag) almost always shows 00 00 for the crc?
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 17920 | Rdr |26 01 00 00 | !! | INVENTORY
24288 | 77536 | Tag |00 00 65 72 3f 0b 00 a4 07 e0 ea 7a | ok |
85600 | 103520 | Rdr |02 a1 70 00 | !! | FAST_INVENTORY_READ
108320 | 149280 | Tag |00 c5 09 30 01 f8 01 8f 7b | ok |
154816 | 176832 | Rdr |22 23 94 00 00 | !! | READ_MULTI_BLOCK(0-14)
1050848 | 1165536 | Tag |00 f2 8b 3e 8b 18 67 7e b7 8c e4 9f ba ec 10 18 40 1e | |
| | |54 7f 0e b4 6b f3 bc eb 45 | ok |
1172032 | 1198144 | Rdr |22 23 65 20 00 d0 | !! | READ_MULTI_BLOCK(101-133)
1340000 | 1454688 | Tag |00 48 01 ba b9 95 e6 47 88 8a 60 d7 4a 52 3b ec fc b8 | |
| | |d3 3c e3 0b a4 9a 03 b4 fd | ok |
Warm regards and really thank you for going that deep into this. This is really appreciated!
Try keep to topic. Its hard to follow an issue that goes tangent. Use discord and ask questions on the server. Its why its there for.
When it comes to your 8byte iso15693 card. Do you have picture / more details of the system it belongs to? the document @DidierA linked doesn't seem to be related to your tag.
I can adapt rdbl / dump / wrbl / restore to use 8 bytes, but what we need is a solid way to detect which block length a card uses.
I pushed some changes to handle / detect 4 / 8 byte ..
its more of a work in progress right now, but since I don't have access to this kind of tag it is a bit hard to test/debug.
ping
I guess it's FreeStyle Libre? https://www.ifixit.com/Teardown/FreeStyle+Libre+2+Sensor+Teardown/137719 It says it uses RF430, which is the same chip as @DidierA mentioned in https://github.com/RfidResearchGroup/proxmark3/issues/2101#issuecomment-1704858744
Plus, the related opensource project says it uses ISO15693 https://github.com/JoernL/LimiTTer/blob/de840ba2ad46dd1dbc0731e5fbfa666d392e9d71/LimiTTer.ino#L162
try https://github.com/RfidResearchGroup/proxmark3/commit/8d0b41a911ca308eac990cc6bdb21d3fd073ef1c and see if this works better.
Describe the bug My "hf 15 dump" only contains the first 4 bytes of each block. In the trace I can see the full 8 bytes of the block.
To Reproduce Start pm3 and have an ISO15693 tag ready to scan. I did this on windows with the latest master commit of proxmark 3 (commit 32f892e512d97be402c0abaf6f00675686ed0893).
Unfortunately this is not only a display problem, writing the dump to a file will as well only contain the first 4 bytes per block.
The trace shows all data:
Expected behavior Having all data in the dump.
Desktop (please complete the following information):