Proxmark developers community

Research, development and trades concerning the powerful Proxmark3 device!

You are not logged in.

#1 Re: iClass » iClass is coming... » 2014-12-19 16:46:17

I agree with iceman ! Thank you !!

#3 Re: Windows Client » Compiled Windows Client - Download » 2014-12-13 08:01:36

False positive. We should ask gaucho why.

#5 Re: MIFARE Classic » A popular toy, Skylander » 2014-12-08 10:07:32

Yes, you can snoop communication data and try to recover at least 1 key.

#6 Felica » TOPAZ » 2014-12-02 10:17:44

Replies: 0

Amiibos (new N toys) are "made of" TOPAZ.

Amiibo TOPAZ Specs:

Block0 contains the UID, and is locked (not writable)
Blocks from 1to 12 are unlocked (writable)
Block13 is locked (data seem to be always 0x5555AAAA124C0600
Block14 is the lock bits/OTP and it is locked (data seems to be always 0x01E0000000000000)
Block15 is unlocked (writable); (data seems to be always 0x000000000000FFFF)
Blocks from 16 to 63 are unlocked (writable)

ATQA = 0C00
Memory = 512 Bytes
Blocks = 64
Each block = 8 Bytes

The official TOPAZ command set is the following (7bits commands):

REQA       = 26h [0 1 0 0 1 1 0] --> Request Command, type A
WUPA      = 52h [1 0 1 0 0 1 0] --> Wake-up, type A
RID         = 78h [1 1 1 1 0 0 0] --> Read ID – Use to read the metal-mask ROM and UID0-3 from block 0
RALL       = 00h [0 0 0 0 0 0 0] --> Read All (all bytes)
READ      = 01h [0 0 0 0 0 0 1] --> Read (a single byte)
WRITE-E  = 53h [1 0 1 0 0 1 1] --> Write-with-erase (a single byte)
WRITE-NE = 1Ah [0 0 1 1 0 1 0] --> Write-no-erase (a single byte)

The CRC (2 bytes) shall be the 16-bit version as specified under CRC-CCITT – for definition see ISO/IEC 14443-3:2001(E) Annex B: CRC_B.
CRC is NOT used with REQA & WUPA commands.

More info in the datasheet linked in the 1st line.

#7 Re: 125 kHz - Antenna » antenna 125 khz success » 2014-11-30 17:29:11

Great finding Enio !

Can you describe the antenna size and tunrs numbers ? Any picture ?

#8 Re: Software Development » stronglink SL500 - RFID Identifier Project » 2014-11-30 17:24:37

It would be great if you mind to share it with everybody !

#9 Re: MIFARE Classic » A popular toy, Skylander » 2014-11-26 19:35:35

A chip dump will surely be very good and useful ! Anyway the pic "exploit" was succesfully performed (also by some members of this forum) to read HID keys.

#10 Re: Software Development » stronglink SL500 - RFID Identifier Project » 2014-11-26 00:46:04

I do not have any source code examples for you, sorry.

#11 Re: Software Development » stronglink SL500 - RFID Identifier Project » 2014-11-25 20:07:24

I am sorry, I cannot help you with C# or Delphi code. The alternative way is to send commands (apdus) via serial port if you know how to send bytes over a serial port; I can tell you some apdus examples (obtained reversing the commands sent through USB/Serial communication) but you will have to figure out the rest yourself.

#12 Re: Software Development » stronglink SL500 - RFID Identifier Project » 2014-11-25 11:59:55

Yeah, commands must be send without spaces.

To know the available commands you need to study the ISO15693-3 (-3 = part 3) datasheet; 2B is not a mandatory command, it is optional and luckily it is supported by your tag giving you good infos!

#13 Re: Software Development » stronglink SL500 - RFID Identifier Project » 2014-11-25 11:50:55

Try with 02 2B and not with 02 0B.
You can test (with ICTransfer) tags ISO15693 -> I.CODE SLI or Tag_It, they should work with basic commands.

#14 Re: Software Development » stronglink SL500 - RFID Identifier Project » 2014-11-25 10:27:18

As far as I can tell no demo for ISO15693 in Delphi.
You need to send raw commands to talk with standard ISO but unsupported tags (unsupported = no source code or no already-made software available); raw commands are called "pass_through" commands in SL500F manual (page 40 of the included manual) and is managed by the "Transcieve" button in the included software; for example sending 02 2B (Get System Information) will give you a series of infos (bytes) about the tag, including UID (crc is auto-mamanged by the SL500F).

#16 Re: Software Development » Mifare 4K (S70?) SAK and ATAQ » 2014-11-22 23:17:37

They are stored somewhere, 99% in sector0block0. Block0 is called manufacturer block in nxp datasheets. Uid is there so atqa and sak are. Last 2 bytes are manufacturing data (extrapolated by me studying other nxp datasheets). Every bit answered by a tag must be stored in the chip so i suppose those data are taken from block0 which is read only in official tags (as any manufacturer info usually is).

#17 Re: Software Development » Mifare 4K (S70?) SAK and ATAQ » 2014-11-21 22:04:33

... but i think 1 of 2 is not correct wink
I vote for 18 (non-correct)

#18 Re: Software Development » Mifare 4K (S70?) SAK and ATAQ » 2014-11-20 18:54:48

I am not sure about "all 98 are mpcos" because mpcos is more expensive than a real mifare and I found this "98" in very cheap tags (some of them, used for the same exact puropose) were NXP mifare (with specific atqa+sak) and some of them were sak=98; I don't think they used mpcos for such a "cheap" use, I think they are GemEasy8000 tags (real mifare, not mpcos-emulated). Link.

#19 Re: Software Development » Mifare 4K (S70?) SAK and ATAQ » 2014-11-20 15:55:50

I agree with the pm3 test ! Anyway tags (even chinese ones) are structured to answer with SAK after the specific SELECT command and they "answer" the bits contained in byte5 (starting from byte0). In no other part of the chip that value is stored. The only question is how to interpret it but reading datasheets all 8 SAK bits must be considered as "SAK-bits", without leaving out the MSB.

Curiously nfc-tools make the same questioning-interpretation:

From the first block, the manufacturer data, can be determined if you are dealing with a 1KB or a 4KB tag. It can be done using the ATQA part of block0 in bytes 8 and 7 (stored in reverse order). Byte 6 contains the SAK (at least for the last part (4 bits)).

Even here SAK is considered as full byte (98 is specific for a mifare produced by GemPlus, I saw other examples of that manufacturer but unfortunately I don't remember PM3 answer).

I found an interesting thing in ISO14443-3 datasheet I was not aware of:

b8-b5 (1000)b: Additional information available in protocols
b8-b5 (1100)b: Default mode in protocols
b4-b1(0000)b: Other than ISO/IEC 14443-4
b4-b1(0001)b: PICC supports ISO/IEC 14443-4

So we are now sure that SAK must be considered in all its 8 bits and 1000 (b8-b5) = Additional mode in protocols (I still don't know what that means and where that additional info is stored) but with 98 whe have 10011000 so b8-b5 = 1001... maybe a specific GemPlus "mark", nothing more nothing else... but more probably "Additional info+PICC supports ISO/IEC 1443-4".

#20 Re: Questions and Requests » Fuzzying protocols with PM3? » 2014-11-20 14:32:38

By manually "bruteforcing" the tag; the tag gives an answer (usually "not supported" answer).
If I am able to find them out i will post them here.

#21 Re: Software Development » Mifare 4K (S70?) SAK and ATAQ » 2014-11-20 14:31:26

I think that the SAK byte is sotred in that secotr0block0 position and it is this data tht is sent when requesting tha SAK.

If you try to change this byte in a chinese mifare the SAK will change.

#22 Re: Software Development » Mifare 4K (S70?) SAK and ATAQ » 2014-11-20 07:55:55

It seems not to consider the MSB bit to define SAK:
98h = 10011000
18h = _0011000
Anyway, for what i know, in cascade level1 only bit3 is considered and all other bits are non-significant but SAK is always 8bit.

#23 Re: Questions and Requests » Fuzzying protocols with PM3? » 2014-11-19 11:24:39

You can do it with a lua script using raw commands.
I found a couple of "hidden" command in a specific rfid iso14443A card. The hard thing is understanding the command synthax...

Board footer

Powered by FluxBB