Proxmark developers community

Research, development and trades concerning the powerful Proxmark3 device!

You are not logged in.

#1 Re: MIFARE Classic » A popular toy, Skylander » Today 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.

#2 Re: Software Development » stronglink SL500 - RFID Identifier Project » Today 00:46:04

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

#3 Re: Software Development » stronglink SL500 - RFID Identifier Project » Yesterday 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.

#4 Re: Software Development » stronglink SL500 - RFID Identifier Project » Yesterday 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!

#5 Re: Software Development » stronglink SL500 - RFID Identifier Project » Yesterday 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.

#6 Re: Software Development » stronglink SL500 - RFID Identifier Project » Yesterday 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).

#8 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).

#9 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)

#10 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.

#11 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".

#12 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.

#13 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.

#14 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.

#15 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...

#18 Re: Questions and Requests » HF EPA , not working with a european passport » 2014-11-17 09:22:34

Well in that case a sniffing is needed to better understand. Anyway this is strange... the only reason can be that your country does not follow ICAO standard... but it seems not to be.

#19 Re: Questions and Requests » HF EPA , not working with a european passport » 2014-11-16 19:33:45

EPA in pm3 is really not compatible with all epas. It needs to be developed MUCH more !

#20 Re: MIFARE Classic » nested auth key recovery » 2014-11-13 19:57:09

Thank you for your contribution. I hope this will be added to the main trunk soon !

#21 Re: MIFARE Classic » A popular toy, Skylander » 2014-11-13 19:54:58

Great work man ! So the decrypted data are "correct" (readable) ?

#22 Re: MIFARE Classic » MCT - An Android NFC-App for reading/writing/analysing/etc. MF Classic » 2014-11-10 23:54:42

If you want to support external USB devices you must be sure that the Android mobile phone you will use has the right .ko kernel modules; those modules must support usb->serial conversion chip or direct serial communication (like in proxdroid); here is a list of the most common (thanks to jonor)

cdc-acm.ko     ---> Serial module
cp210x.ko     ---> Prolific USB->Serial module
cypress_m8.ko  ---> Cypress USB->Serial module
ftdi_sio.ko    ---> FTDI USB->Serial module

Each module must be compiled for the kernel in use in the mobile phone. They are not all necessary, you need to find which chip is inside the ACR122U (a picture of ACR122U internals is needed).

If needed I can provide an I9300 modified kernel (Siyah 1.9.0-MOD) with the above mentioned kernel-specific modules (always thanks to jonor).

The second step will be understanding how to send the correct commands through USB via ACR122U APDUs (here you can find a detailed datasheet); for example at page 13 you can see how to use mifare auth. Remember that hardware clones can use different undocumented APDUs to send commands to the tag!
The best way will be sniffing an USB communication to see which commands are sent by the official software to the reader you want to talk with.


In that way you can also support the SL500F device!

#23 Re: Various Tools and Utilities » New algo discovered » 2014-11-03 10:14:55

Man can I contact you via mail or some social media ?

#25 Re: Questions and Requests » Introduction 5321/iclass copy » 2014-11-02 10:38:50

HID Official Drivers and software.

Omnikey 5321v2 is an officially discontinued product.

Unfortunately I doubt you will get support for your 5321v2 device here because this forum is about proxmark3 and not Omnikey.

Board footer

Powered by FluxBB