Best regards
]]>pm3 --> hf topaz reader
ATQA : 0c 00
HR0 : 12 (a Topaz tag (capable of carrying a NDEF message), dynamic memory map)
HR1 : 4c
UID : 25 10 00 00 21 f4 d2
UID[6] (Manufacturer Byte) = 25, Manufacturer: Innovision Research and Technology Plc UK
Static Data blocks 00 to 0c:
block# | offset | Data | Locked?
0x00 | 0x00 | d2 f4 21 00 00 10 25 00 | yes
0x01 | 0x08 | e1 11 3f 00 01 03 f2 30 | no
0x02 | 0x10 | 33 02 03 f0 02 03 03 ff | no
0x03 | 0x18 | 01 4e c5 00 00 00 01 48 | no
0x04 | 0x20 | 47 40 a8 ea 3a ff d6 6e | no
0x05 | 0x28 | 3b e7 ae e9 a3 8d a6 31 | no
0x06 | 0x30 | 1b 13 7a 6d f4 4e cf 28 | no
0x07 | 0x38 | f1 8a 6e 35 48 d9 a4 80 | no
0x08 | 0x40 | 4e 4f 46 54 01 00 00 00 | no
0x09 | 0x48 | fd 34 53 69 b4 86 13 18 | no
0x0a | 0x50 | 31 49 ca 22 4c e4 dd ee | no
0x0b | 0x58 | a7 67 dd b3 64 99 30 b4 | no
0x0c | 0x60 | 25 96 6a 4f 34 8d e0 1a | no
Static Reserved block 0d:
0x0d | 0x68 | 55 55 aa aa 12 4c 06 00 | n/a
Static Lockbits and OTP Bytes:
0x0e | 0x70 | 01 e0 00 00 00 00 00 00 | n/a
Capability Container: e1 11 3f 00
e1: NDEF Magic Number
11: version 1.1 supported by tag
3f: Physical Memory Size of this tag: 512 bytes
00: Read access granted without any security / Write access granted without any security
Lock Area of 48 bits at byte offset 0x7a. Each Lock Bit locks 8 bytes.
Reserved Memory of 2 bytes at byte offset 0x78.
I have also successfully used
raw -T
to perform READ-8 and WRITE-8.
]]>pm3 --> hf topaz reader
Error: couldn't receive ATQA
pm3 --> hf list topaz
Recorded Activity (TraceLen = 10 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 992 | Rdr |52 | | WUPA
pm3 --> hf 14a raw -a -p -T 26
received 0 octets
pm3 --> hf list topaz
Recorded Activity (TraceLen = 10 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 1056 | Rdr |26 | | REQA
pm3 --> hf 14a raw -p -c -T 00 00 00 d2 f4 21 00
received 0 octets
pm3 --> hf list topaz
Recorded Activity (TraceLen = 100 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 1056 | Rdr |26 | | REQA
162938240 | 162995680 | Rdr |00 00 00 d2 f4 21 00 c0 98 | ok | RALL
Could something have broken it? Should I try a build from piwi's fork from April or May? Or am I just missing something else?
]]>I just pulled down piwi's topaz branch, compiled it, flashed the bootrom and OS, but it's not giving me the same results you were seeing:
proxmark3> hf topaz reader
Error: couldn't receive ATQA
proxmark3> hf list topaz
Recorded Activity (TraceLen = 10 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 992 | Rdr | 52 | | WUPA
proxmark3> hf 14a raw -a -p -T 26
received 0 octets
proxmark3> hf list topaz
Recorded Activity (TraceLen = 10 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 1056 | Rdr | 26 | | REQA
proxmark3> hf 14a raw -p -c -T 00 00 00 d2 f4 21 00
received 0 octets
proxmark3> hf list topaz
Recorded Activity (TraceLen = 100 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iso14443a - All times are in carrier periods (1/13.56Mhz)
iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation |
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 1056 | Rdr | 26 | | REQA
-1782418048 | -1782360608 | Rdr | 00 00 00 d2 f4 21 00 c0 98 | ok | RALL
What am I missing?
]]>I also think to have an explanation for the 1st 4 "reserved" bytes... iceman ?
]]>(I suppose the topaz content can be decrypted the same way as the ntag content - not tested).
Not tested.
I'm putting together some dumps for testing, and if you have any figures, they would be helpful. It's not the same memory size or data layout as the NTAG215 figures, so a naive decryption attempt with amiitool doesn't work.
]]>The Jewel/Topaz toys are pre-Amiibo NFC toys used for the 2013 Wii U game Pokemon Rumble U / Pokemon Scramble U.
Official site: http://www.pokemonrumble.com/RumbleU/en/nfc/
Full list of figures: http://www.serebii.net/rumbleu/figures/figures.shtml
As asper noted, some blocks seem consistent between figures:
Block 0 is the UID (4 bytes), I've seen the next two bytes be 0010 or 0002, and then consistently 2500
Block 1 always seems to be e1113f00 0103f230
Block 2 always seems to be 330203f0 020303ff, except in asper's post, where the last byte is 00.
Block 3 always seems to be 014ec500 00000148, except in asper's post, where it's all 00.
Block 13 always seems to be 5555aaaa 124c0600
Block 14 always seems to be 01e00000 00000000, except in asper's post, where the last two bytes were 50af, which I'm not sure how it's possible if it's always locked
Block 15 always seems to be 00000000 0000ffff), except in asper's post, where the last two bytes were 0000
I have data on two figures that are the same, but there don't seem to be any bytes that are the same between them, but different between other figures, to identify a figure model number. I don't have a Wii U, so I can't try emulating it and flipping bits.
asper, what figures do you have, and can I get dumps of them?
]]>The reply to GET_VERSION matches that of the NTAG215 as per this datasheet:
https://dangerousthings.com/wp-content/uploads/2013/12/NTAG213_215_216.pdf
proxmark3> hf 14a raw -s -c 60
received 7 octets
04 1A 9B 82 C2 3E 80
received 10 octets
00 04 04 02 01 00 11 03 01 9E