Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
There is some talk about remaking the 14B command in the client, so I thought I start a thread about it here.
With some fixes from @pwpivi, it seems like "raw" is back up online.
@Marshmellow is thinking about a "info" command.
So what kind of commands do the community want to see remade or new?
REF: https://github.com/Proxmark/proxmark3/issues/103
Last edited by iceman (2015-06-03 09:37:13)
Offline
Is there a common read and write command for this protocol, or do you have a list of commands? It appears, as usual, different tags have different command sets. Is there a most common chip?
Offline
That is a typical question to @asper ...
He has lists with all different commands and stuff...
Offline
Unfortunately ISO14443B is really non-standard about commands; the only standard layer3 (ISO14443B-3) commands are:
REQB: that is 05, followed by the Application Family Identifier (AFI), that usually is 00 in AFI is not set inside the tag (different from 00 it is set); those 2 bytes are then followed by 1byte parameter and 2bytes ISO14443B CRC.
HALT: 50+2bytes ISO14443BCRC
SLOT-MARKER: must be coded looking at bits (par. 7.8.1 ISO14443B-3 datasheet)
ATTRIB: must be coded looking at bits (par. 7.10 ISO14443B-3 datasheet)
Again, unfortunately, I only saw ST Microelectronics tags and they DO NOT FOLLOW the ISO14443B-3 standard; the REQB (INITIATE) command is 06 00 in ST 14B products as you can read below:
INITIATE: 06 00 + 2 bytes ISO14443B CRC - answer is 1 byte-Chip ID + 2 bytes CRC
SELECT: 0E + Chip ID + 2 bytes ISO14443B CRC (it needs the 1 byte-Chip ID from the previous command) - answer is 1 byte-Chip ID+2 bytes ISO14443B CRC
GET UID: 0B + 2 bytes ISO14443B CRC- answer is 8 bytes UID + 2 bytes CRC
READ BLOCK: 08 + block number + 2 bytes CRC - answer is 4 bytes + 2 bytes CRC
WRTIE BLOCK: 09 + block number + 4 bytes of data to be written + 2 bytes CRC - no answer for this one
first 3 commands must be sent in sequence to obtain tag read/write access.
there also are other 2 TI commands:
RESET TO INVENTORY: 0C - no answers
COMPLETION: 0F - no answers
Here is a copy/paste of a previous working client version:
proxmark3> hf 14b sri512read
proxmark3>
proxmark3> #db# Randomly generated UID from tag (+ 2 byte CRC): 63 e5 a1
proxmark3> #db# Now SELECT tag:
proxmark3> #db# Tag UID (64 bits): D002182478917429
proxmark3> #db# Tag memory dump, block 0 to 15
proxmark3> #db# Address=0, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=1, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=2, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=3, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=4, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=5, Contents=1b808c01, CRC=b46b
proxmark3> #db# Address=6, Contents=ffffffff, CRC=470f
proxmark3> #db# Address=7, Contents=3420001, CRC=28a7
proxmark3> #db# Address=8, Contents=5a5e0a09, CRC=ffc2
proxmark3> #db# Address=9, Contents=15, CRC=2851
proxmark3> #db# Expected 6 bytes from tag, got less...
to obtain tag information you need to read the UID:
D002182478917429 = UID
D0 = ISO14443B Magic Byte? (like E0 in ISO15693 but I don't think so, no mention in datasheets)
02 = Manufacturer (ST Mircorlrctronics)
model code = transofrm 18 in binary and take 1st 6 MSb --> 00011000 (look table below for correspondancies)
Here is a list of all ISO14443B tags I was able to identify studying datasheets, buying tags and reading web examples/sources:
02,000000 = usually SRIX4K (special manufacturer version)
02,000010 = SR176
02,000011 = SRIX4K
02,000100 = SRIX512
02,000110 = SRI512
02,000111 = SRI4K
02,001100 = SRT512
If no ISO14443B tag is present pm3 answered that way (when client was working):
proxmark3> hf 14b read
proxmark3>
proxmark3> #db# No response from tag
Last edited by asper (2015-06-03 15:51:38)
Offline
(edit: wrong thread)
Last edited by asper (2015-06-03 15:52:13)
Offline
I thought I could hook up two pm3 with one sim and the other with read. But that doesn't quite seem to work.
Offline
@asper, thanks for the info.
can you try your st tags with hf search from my 14b_tests branch at: https://github.com/marshmellow42/proxma … /14b_tests?
(also the hf 14b reader command)
Offline
It seems not to be working:
proxmark3> hf 14b read
no 14443B tag found
proxmark3>
proxmark3> hf search
no known/supported 13.56 MHz tags found
proxmark3>
In both cases the "list 14b" command is empty.
Raw commands work.
Last edited by asper (2015-06-15 08:39:58)
Offline
ok, should see some sort of output now... turned verbose mode on. let me know where it halts.
i'm looking into why there is no list.
for the raw commands, can you run them in sequence to get the UID, leaving power on for the first two raw commands? or does it require special timing between commands?
Offline
No idea what is happening:
proxmark3> hf search
proxmark3>
proxmark3> hf list 14b
Recorded Activity (TraceLen = 60 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 |
-----------|-----------|-----|-----------------------------------------------------------------|-----|--------------------|
proxmark3>
proxmark3> hf 14b read
proxmark3>
About hte raw commands I can send the commands in sequence without any timing between commands but with this last build from you raw commands don't work anymore !
proxmark3> hf 14b raw -c -p 06 00
Sending bytes to proxmark failed
timeout while waiting for reply.
proxmark3>
Last edited by asper (2015-06-15 15:08:49)
Offline
interesting. i have noticed it is EXTREMELY sensitive to card position. i just figured it was my antenna... i can get the raw commands working (if i work at it)
did you flash the firmware?
between the two versions nothing should have affected the raw commands...
i think it is just still very unstable communications.
Offline
Probably I did some kind of mistake (maybe I flashed the wrong branched .bin); now the test seems to give answers:
proxmark3> hf search
received 3 octets
b6 c5 20
CRC OK
received 3 octets
b6 c5 20
CRC OK
received 0 octets
no known/supported 13.56 MHz tags found
proxmark3>
proxmark3> hf list 14b
Recorded Activity (TraceLen = 62 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 | 0 | Rdr | 06 00 [97 5b] | ok | INITIATE
0 | 0 | Tag | b6 [c5 20] | ok |
0 | 0 | Rdr | 0e b6 [ea 45] | ok | SELECT(182)
0 | 0 | Tag | b6 [c5 20] | ok |
0 | 0 | Rdr | 0b [ab 4e] | ok | GET UID
proxmark3>
proxmark3> hf 14b read
received 3 octets
f0 f7 07
CRC OK
received 3 octets
f0 f7 07
CRC OK
received 0 octets
no 14443B tag found
proxmark3>
proxmark3> hf list 14b
Recorded Activity (TraceLen = 62 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 | 0 | Rdr | 06 00 [97 5b] | ok | INITIATE
0 | 0 | Tag | f0 [f7 07] | ok |
0 | 0 | Rdr | 0e f0 [d8 62] | ok | SELECT(240)
0 | 0 | Tag | f0 [f7 07] | ok |
0 | 0 | Rdr | 0b [ab 4e] | ok | GET UID
proxmark3>
Sorry for making it confusing
By the way it seems not to send GET UID correctly, the correct raw command sequence is:
proxmark3> hf 14b raw -c -p 06 00
received 3 octets
31 72 d0
CRC OK
proxmark3>
proxmark3> hf 14b raw -c -p 0E 31
received 3 octets
31 72 d0
CRC OK
proxmark3>
proxmark3> hf 14b raw -c -p 0B
received 10 octets
29 74 91 78 24 18 02 d0 85 b0
CRC OK
proxmark3>
Looking at pm3 behaviour (the red led turn off at a certain point) it seems you turn off the field after the 0E command while it should be turned on.
Last edited by asper (2015-06-16 09:29:57)
Offline
it seems it is sending the commands in the correct order, it just didn't get a response from the 0B command. i leave the power on until i send the 0B command, which should work, but i'll change it to turn off the power with a extra final command after i have the UID to see if it helps.
i pushed a few changes i was working on as well as the adjustments to the power on/off to my fork, it might fix it.
i haven't tested the code thoroughly yet though.
Offline
It works now !
The strange thing is that "list" seems not to list anything...
proxmark3> hf search
received 3 octets
53 66 90
CRC OK
received 3 octets
53 66 90
CRC OK
received 10 octets
29 74 91 78 24 18 02 d0 85 b0
CRC OK
14443-3b ST tag found:
UID: 29 74 91 78 24 18 02 d0
MFG: 74, no tag-info available
Chip: 24, Unknown
Valid ISO14443B Tag Found - Quiting Search
proxmark3>
proxmark3> hf list 14b
Recorded Activity (TraceLen = 165 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 |
-----------|-----------|-----|-----------------------------------------------------------------|-----|--------------------|
proxmark3>
proxmark3> hf 14b read
received 3 octets
9c 9d ae
CRC OK
received 3 octets
9c 9d ae
CRC OK
received 10 octets
29 74 91 78 24 18 02 d0 85 b0
CRC OK
14443-3b ST tag found:
UID: 29 74 91 78 24 18 02 d0
MFG: 74, no tag-info available
Chip: 24, Unknown
proxmark3>
proxmark3> hf list 14b
Recorded Activity (TraceLen = 270 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 |
-----------|-----------|-----|-----------------------------------------------------------------|-----|--------------------|
proxmark3>
I also think that UID must be read in reverse: D0 02 18....
Last edited by asper (2015-06-17 08:21:20)
Offline
Perfect. I didn't know how the tag output. (Which endian). Now I do ..
I'm still toying with the trace. I can force it on now but would rather not clear it, but if I don't clear it I could get garbage. So I guess I will just have to force it on and clear it with the first command I send.
Offline
It is a little strange though, as i expected the trace to be on by default. do you get a trace when you run the raw commands? (As that is basically all I'm doing.)
Offline
Yes:
proxmark3> hf 14b raw -c -p 06 00
received 3 octets
53 66 90
CRC OK
proxmark3>
proxmark3> hf 14b raw -c -p 0E 53
received 3 octets
53 66 90
CRC OK
proxmark3>
proxmark3> hf 14b raw -c -p 0B
received 10 octets
29 74 91 78 24 18 02 d0 85 b0
CRC OK
proxmark3>
proxmark3> hf list 14b
Recorded Activity (TraceLen = 82 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 | 0 | Rdr | 06 00 [97 5b] | ok | INITIATE
0 | 0 | Tag | 53 [66 90] | ok |
0 | 0 | Rdr | 0e 53 [49 f5] | ok | SELECT(83)
0 | 0 | Tag | 53 [66 90] | ok |
0 | 0 | Rdr | 0b [ab 4e] | ok | GET UID
0 | 0 | Tag | 29 74 91 78 24 18 02 d0 [85 b0] | ok |
proxmark3>
Offline
That was with the latest code changes? Hmmm. Strange
Offline
Yes, with te same your latest 14b_tests changes.
Last edited by asper (2015-06-17 13:31:43)
Offline
ok now i've included piwi's latest fixes which makes the 14b raw command fly and read from any distance! (within reason).
(really amazing difference with my tags/antenna at least).
and i fixed the endianness of the uid ( i think ).
you should get the correct manufacturer and chip now.
Offline
also the trace should be back to normal now. i found in my playing the 15693 reader command breaks the trace memory for 14b raw. i was calling that before the 14b reader in the hf search. so it was breaking the tracing.
i moved the 14b reader in front of the 15693 command in hf search, but it is still possible if no tag is found for it to kill the 14b tracing.
i found a 14a reader command restores tracing to normal.
hf 14b reader doesn't suffer the same issue as it wouldn't ever call the 15693 reader command (hf 15 reader)
i think ultimately we need to fix the 15 reader commands...
Offline
GOOD !
proxmark3> hf search
14443-3b ST tag found:
UID: d0 02 18 24 78 91 74 29
MFG: 02, ST Microelectronics SA France
Chip: 06, SRI512
Valid ISO14443B Tag Found - Quiting Search
proxmark3>
proxmark3> hf list 14b
Recorded Activity (TraceLen = 115 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 | | ?
-6993 | -6993 | Rdr | 05 00 08 [39 73] | ok | REQB
-6993 | -6993 | Rdr | 06 00 [97 5b] | ok | INITIATE
-6993 | -6993 | Tag | 33 [60 f3] | ok |
-6993 | -6993 | Rdr | 0e 33 [4f 96] | ok | SELECT(51)
-6993 | -6993 | Tag | 33 [60 f3] | ok |
-6993 | -6993 | Rdr | 0b [ab 4e] | ok | GET UID
-6993 | -6993 | Tag | 29 74 91 78 24 18 02 d0 [85 b0] | ok |
-6993 | -6993 | Rdr | <empty trace - possible error> | | ?
proxmark3>
proxmark3> hf 14b read
14443-3b ST tag found:
UID: d0 02 18 24 78 91 74 29
MFG: 02, ST Microelectronics SA France
Chip: 06, SRI512
proxmark3>
proxmark3> hf list 14b
Recorded Activity (TraceLen = 220 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 | | ?
-6993 | -6993 | Rdr | 05 00 08 [39 73] | ok | REQB
-6993 | -6993 | Rdr | 06 00 [97 5b] | ok | INITIATE
-6993 | -6993 | Tag | 33 [60 f3] | ok |
-6993 | -6993 | Rdr | 0e 33 [4f 96] | ok | SELECT(51)
-6993 | -6993 | Tag | 33 [60 f3] | ok |
-6993 | -6993 | Rdr | 0b [ab 4e] | ok | GET UID
-6993 | -6993 | Tag | 29 74 91 78 24 18 02 d0 [85 b0] | ok |
-6993 | -6993 | Rdr | <empty trace - possible error> | | ?
-6993 | -6993 | Rdr | 05 00 08 [39 73] | ok | REQB
-6993 | -6993 | Rdr | 06 00 [97 5b] | ok | INITIATE
-6993 | -6993 | Tag | 5a [a7 0d] | ok |
-6993 | -6993 | Rdr | 0e 5a [88 68] | ok | SELECT(90)
-6993 | -6993 | Tag | 5a [a7 0d] | ok |
-6993 | -6993 | Rdr | 0b [ab 4e] | ok | GET UID
-6993 | -6993 | Tag | 29 74 91 78 24 18 02 d0 [85 b0] | ok |
-6993 | -6993 | Rdr | <empty trace - possible error> | | ?
proxmark3>
What is "<empty trace - possible error> " ?
I tested with another tag:
proxmark3> hf search
14443-3b ST tag found:
UID: d0 02 02 50 1a 45 32 f9
MFG: 02, ST Microelectronics SA France
Chip: 00, SRIX4K (Special)
Valid ISO14443B Tag Found - Quiting Search
proxmark3>
proxmark3> hf 14b read
no 14443B tag found
proxmark3>
proxmark3> hf 14b read
14443-3b ST tag found:
UID: d0 02 02 50 1a 45 32 f9
MFG: 02, ST Microelectronics SA France
Chip: 00, SRIX4K (Special)
proxmark3>
And it works GREAT !
I will add the reading of block FF to see which blocks are locked, this will be a good info to know ! If you have time to add you can follow this scheme (be careful with the 176 chip, it has a special command!):
SR176 has a special command to read lock data:
Last edited by asper (2015-06-18 14:12:58)
Offline
First PM3 - simulating 14b
pm3 --> hf 14b sim
#db# new cmd from reader: len=4, cmdsRecvd=1
#db# CRC passes
pm3 -->
Second PM3 - info
pm3 --> hf 14b info
no 14443B tag found
pm3 -->
The good thing is that 14b sim gets something.. but the 14b info doesn't recoqnise it.
Both pm3 gives this output... hm.. strange...
pm3 --> hf list 14b
Recorded Activity (TraceLen = 13 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 | 0 | Rdr |06 00 97 5b | ok | INITIATE
Last edited by iceman (2015-06-24 20:10:20)
Offline
what does the trace look like?
Offline
nevermind. it is just because the sim is looking for a different version of the REQB command.
Offline
the sim needs to be taught more commands to respond to to be useful.
Offline
the sim should respond to any 0x05 0x00 0xXX [crc] command with the ATQB. but it only will take 05,00,00 or 05,00,08
Last edited by marshmellow (2015-06-24 20:19:31)
Offline
i'm trying
hf 14b raw -c -p 05 00 08
hf 14b raw -c -p 05 00 00
but nothing...
Offline
nothing in the trace? of either PM3?
Last edited by marshmellow (2015-06-24 20:18:35)
Offline
nada
Offline
it looks like it only picked up the second command sent by the hf 14b info... (the command for SRI tags)
and with the raw command directly you get nothing...
you flashed?
Offline
I sure did flash...
Offline
The PM3 which sims, picks up something..
but the other one doesn't pick up the answer..
pm3 --> hf 14b sim
#db# button pressed, received 2 commands
pm3 --> hf li 14b
Recorded Activity (TraceLen = 76 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 | 0 | Rdr |05 00 08 39 73 | ok | REQB
0 | 0 | Tag |50 82 0d e1 74 20 38 19 22 00 21 85 5e d7 | ok |
0 | 0 | Rdr |05 00 00 71 ff | ok | REQB
0 | 0 | Tag |50 82 0d e1 74 20 38 19 22 00 21 85 5e d7 | ok |
Offline
here is a sim from pm3 to 3rd party 14b reader:
proxmark3> hf 14b sim
#db# new cmd from reader: len=11, cmdsRecvd=1
#db# CRC passes
proxmark3> hf list 14b
Recorded Activity (TraceLen = 59 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 | 0 | Rdr | 05 00 08 [39 73] | ok | REQB
0 | 0 | Tag | 50 82 0d e1 74 20 38 19 22 00 21 85 [5e d7] | ok |
0 | 0 | Rdr | 1d 82 0d e1 74 00 08 01 00 [a2 cc] | ok | ATTRIB
proxmark3>
and the reader outputs the UID of 820DE174
Offline
i don't have my second pm3 ready for the new firmware yet, so i can't try pm3 to pm3 till at least tomorrow.
Offline
EDIT: could the simulating PM3 respond too quickly for the raw command on the second pm3 to switch back to read mode after transmit?
Last edited by marshmellow (2015-06-24 20:58:50)
Offline
its the "hf 14b raw" that is not picking up the response..
"hf 14b sim" seems to be doing what it should
Offline
see modification above
Offline
could very well be that, since 14a sim has some timers to make sure and 14b sim doesnt..
Offline
and after some changes it works...
pm3 --> hf 14b raw -c -p 05 00 08
received 14 octets
50 82 0D E1 74 20 38 19 22 00 21 85 5E D7
CRC OK
pm3 --> hf 14b raw -c -p 05 00 00
received 14 octets
50 82 0D E1 74 20 38 19 22 00 21 85 5E D7
CRC OK
Offline
too fast?
Offline
I basically looked at how the "hf 14a sim" works, and the "hf 14b sim" doesn't have some of it.
When I took some of that "wait/clearing" code, I got my setup with two pm3 to work everytime.
If this works with one pm3 simulating and a geniue 14b reader, I can't test. If someone wants to check it that would be great.
Offline
@asper, my fork (master branch) now has an attempt to include the lock bit details for the SRx chips in the `hf 14b info` command
if you could test and let me know if i missed something that'd be great.
Last edited by marshmellow (2015-06-29 05:38:04)
Offline
It works with SRI512 (see below) but the client crashes analyzing a SRIX4k (solid red led); I have to unplug pm3 and replug it.
proxmark3> hf 14b info
14443-3b ST tag found:
UID: d0 02 18 24 78 91 74 29
MFG: 02, ST Microelectronics SA France
Chip: 06, SRI512
Chip Write Protection Bits:
raw: 11111011010101000000001110011110111110110101110000000011100111101111101101011100000000000000000000000011101010111111111111111111
00: not locked
01: not locked
02: not locked
03: not locked
04: not locked
05: not locked
06: not locked
07: not locked
08: not locked
09: not locked
10: not locked
11: not locked
12: not locked
13: not locked
14: not locked
15: not locked
Offline
i think i found the bug and fixed it. the `raw: ` printBits was trying to print too many bits...
Offline
It still crashes with SRIX4K. It works with SRI512 as shown above.
Last edited by asper (2015-06-30 10:16:58)
Offline
Thanks for the details. I missed a simple one. should be ok now.
Offline
Full working !
proxmark3> hf 14b info
14443-3b ST tag found:
UID: *
MFG: 02, ST Microelectronics SA France
Chip: 03, SRIX4K
Chip Write Protection Bits:
raw: 11111111
07/08: not locked
09: not locked
10: not locked
11: not locked
12: not locked
13: not locked
14: not locked
15: not locked
proxmark3>
proxmark3> hf 14b info
14443-3b ST tag found:
UID: *
MFG: 02, ST Microelectronics SA France
Chip: 00, SRIX4K (Special)
Chip Write Protection Bits:
raw: 11111110
07/08: locked
09: not locked
10: not locked
11: not locked
12: not locked
13: not locked
14: not locked
15: not locked
proxmark3>
Offline
Pages: 1