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.
Finally I got time and focus to start getting some Desfire commands into the PM3 client.
At least, it is a start.
pm3 --> hf 14a read
ATQA : 44 03
UID : 04 77 29 5a 86 34 80
SAK : 20 [1]
TYPE : NXP MIFARE DESFire 4k | DESFire EV1 2k/4k/8k | Plus 2k/4k SL3 | JCOP 31/41
ATS : 06 75 77 81 02 80 02 f0
- TL : length is 6 bytes
- T0 : TA1 is present, TB1 is present, TC1 is present, FSCI is 5
- TA1 : different divisors are supported, DR: [2, 4, 8], DS: [2, 4, 8]
- TB1 : SFGI = 0, FWI = 8
- TC1 : NAD is NOT supported, CID is supported
- HB : 80
pm3 --> hf mfdes info
isOk:01
---Desfire GetInformation, by Iceman------------------------
-------------------------------------------------------------
UID :04 77 29 5a 86 34 80
Batch number :00 00 00 00 00
Production date :week 0, 200
-------------------------------------------------------------
Hardware Information
Vendor Id : 0x04 (NPX)
Type : 0x01
Subtype : 0x01
Version : 1.0
Storage size : 0x16 (2048 bytes)
Protocol : 0x05
-------------------------------------------------------------
Software Information
Vendor Id : 0x04 (NPX)
Type : 0x01
Subtype : 0x01
Version : 1.4
storage size : 0x16 (2048 bytes)
Protocol : 0x05
-------------------------------------------------------------
Master Key settings
0x08 configureation changeable;
0x08 configureation changeable;
0x02 Free directory list access without PICC Master Key;
0x01 Allow changing the Master Key;
-------------------------------------------------------------
RX :04 77 29 5a 86 34 80 04 01 01 01 00 16 05 04 01 01 01 04 16 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00
pm3 -->
Offline
Cool. I don't mean to pick but isn't the chip mfg 0x04 NXP not npx.
Offline
You are right, both in picking and the spelling
Offline
I have a minor issue with the only desfire-card I've got. It's an oystercard from Transport for London. It is not quite follow the documentet way when it comes to the "Get_Information" command ( 0x60 )
In the snippet you'll see that it answer both the inital request, and the first of supposingly two additional_frames (0xaf). Why doesn't it answer the last one? Some ideas?
81280 | 85984 | Rdr | 02 60 16 4e
88244 | 101044 | Tag | 02 af 04 01 01 01 00 16 05 98 23
102400 | 107104 | Rdr | 03 af 35 69
108724 | 121524 | Tag | 03 af 04 01 01 01 04 16 05 04 0d
123008 | 127712 | Rdr | 04 af 3d 24
Another minor issue with the same tag is auth- commands. The oyster should run on AES crypto,
so the first AUTHENTICATE (0x0a) response is correct with a "AUTHENTICATION_ERROR" (0xAE).
the second AUTHENTICATE_ISO (0x1a) response is correct with a "AUTHENTICATION_ERROR" (0xAE)
the third AUTHENTICATE_AES (0xAA) is not correct. There should be a challenge back from the tag but all I get is a silence.
any ideas on this one?
399744 | 405600 | Rdr | 02 0a 00 dc ed
411956 | 416692 | Tag | 02 ae 64 61
144129664 | 144135520 | Rdr | 03 1a 00 91 22
144143156 | 144147828 | Tag | 03 ae bc 78
144452736 | 144458656 | Rdr | 04 aa 00 fa 94
Offline
the first answer:
have you try:
90 60 00 00 00 00
90 af 00 00 00 00
90 af 00 00 00 00
Two times 90 AF.....???
The second answer:
the authetification error means that is not the crypto method that the card used so your card is right: no des no 3 des you have to use aes
90 AA 00 00 01 00 02
90 AF 00 00 08 00 + data......
Last edited by thefkboss (2014-09-02 06:46:15)
Offline
It doesn't matter if I use native wrapped command style or not. The tag doesnt give me a respond to the last sent 0xaf command.
Look at the reader sent bytes and you see that what you suggested is what I send.
for the second answer, same as above.
The card is correct with the authentication metod answers.. but what I miss is the tag answering back with a nonce.
Offline
so you have a reader (not the proxmark) and you send that apdu and with the reader works??
and with proxmark dosen´t?
Offline
Sadly no, I don't have a extra reader to see if it works.
and neither do I've other desfire cards to play with.
Offline
pm3 --> hf mfdes info
isOk:01
---Desfire Information---------------------------------------
-------------------------------------------------------------
UID :04 77 29 5a 86 34 80
Batch number :00 00 00 00 00
Production date :week 0, 200
-------------------------------------------------------------
Hardware Information
Vendor Id : 0x04 (NXP)
Type : 0x01
Subtype : 0x01
Version : 1.0
Storage size : 0x16 (2048 bytes)
Protocol : 0x05 (ISO 14443-3, 14443-4)
-------------------------------------------------------------
Software Information
Vendor Id : 0x04 (NXP)
Type : 0x01
Subtype : 0x01
Version : 1.4
storage size : 0x16 (2048 bytes)
Protocol : 0x05 (ISO 14443-3, 14443-4)
-------------------------------------------------------------
Master Key settings
0x08 Configuration changeable;
0x04 PICC Master Key required for create / delete;
0x02 Free directory list access without PICC Master Key;
0x01 Allow changing the Master Key;
Max number of keys: 1
-------------------------------------------------------------
RX :04 77 29 5a 86 34 80 04 01 01 01 00 16 05 04 01 01 01 04 16 05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0b 01
Well, it looking better but still no response from the tag and the second 0xaf for the 0x60 command..
Offline
I guess that the Oyster card, kind of locked down with AES and create/delete applications. The firmware version is newer then another dump I saw on internet. (1.3 -> 1.4) so they seem to update it. Might be versions out there with errors then.
Offline
i think the problem is the proxmark.
tell me what apdus do you want to try and i will try with my reader and one oyster (from last year) that i have..
i will write the results...
Offline
Actually, just try the 0xaa Authenticate_Des with key 0x00...
Offline
I tried the card on my other pm3 with another antenna, and the Authenticate 0xaa command responds.
Might be a bad antenna..
Offline
but still the second 0xaf in 0x60 doesn't work. strange...
Offline
i will try when I arrived home
Offline
here are the results
oyster and reader (xxxx is sensitive data.....you know )
Send => 906000000000 (1-1)
0401010100160591AF
Send => 90AF00000000 (1-1)
Receive <= 0401XXXXXXXXXX91AF
Send => 90AF00000000 (1-1)
Receive <= 042BXXXXXXXXXXXXXXXXXXXXXXXX9100
des auth
Send => 900A0000010000 (1-1)
Receive <= 91AE
3des auth
Send => 901A0000010000 (1-1)
Receive <= 91AE
AES AUTH
AUTH with key 0000000000000000
Send => 90AA0000010000 (1-1)
Receive <= AD6C11F74E91B356B8AC863DA7EB0B0891AF (1-2)
Explanations :
(1-1)
"01" = Number of Data(HEX based)
"00" = Key
(1-2)
"AD6C11F74E91B356B8AC863DA7EB0B08" = Encrypted RNDB with Key 00(Created by PICC)
'Step 2
"74740B34687FFDB50ED0D739CB04AD31" = Decrypted RNDB with software
"740B34687FFDB50ED0D739CB04AD3174" = RNDB'
"97824AAF7F5296C9747334F076E52269" = RNDA'(Random Number which generated by software)
Send & Receive Command :
Send => 90AF000020F11A80D8BE6F5AD1A13626F6FFB59417078EF1C1569AA39288C14C2D58DD71CD00 (1-3)
Receive <= 91AF
if you need more, ask me
Last edited by thefkboss (2014-09-02 20:40:18)
Offline
Thank you, thefkboss!
I think my hf antenna which have been working fine with other cards (classic ones) doesn't cut it for the oyster card.
With another antenna I got the 0xaa - response.
The auth seqence reminds me about ultralight-c..
Still not getting an 2nd answer from the 0x60 command.
First I thought it was a timing issue, so I took the patch for the "hf 14a raw" command from Jonor to be able to send a timout "-t" parameter. But that didn't help.
I'll figure it out sooner or later.
Offline
if you want i could try your modifications,
send me an email with the source i will compile it on linux and try with my prox and oyster if you want
Offline
You got mail.
But be warned, that my version of the pm3 code includes lots merged code of different repositories.. You might not get it to work.
Offline
Question: When sending commands to the Desfire what is the purpose of the first byte in the apdu packet for Desfire Native?
Desfire command (Getinformation): 0x60
APDU: 0x60 crc1 crc2
but when I send it with the proxmark, I need to add 0x02 first, then the rest, otherwize the tag will not respond.
IE: 0x02 0x60 0x16 0x4e
What is purpose of this 0x02 byte? It feels like I'm missing something out.
Offline
I found what I was looking for...
http://www.libnfc.org/community/topic/8 … r-desfire/
And its working!
Offline
I think my hf antenna which have been working fine with other cards (classic ones) doesn't cut it for the oyster card
Hi iceman I did have problem with desfire card and maybe this will help
http://www.proxmark.org/forum/viewtopic.php?id=2106
Offline
Could you please share the code in Git Hub, Couldn't you?
Offline
I forked the PM3 and you should be able to reach it on GitHub.
Offline
With the fixes for large adpu frames in PM3, I can now start digging into this code again. It's been dorment for awhile.
Offline
Can someone confirm this please:
If a DESfire card has the random UID function is use, then whenever I select the card, I should be getting a different UID?
--
Offline
I don't know the inner workings of the randon uid function but basically yes. If the random uid is in use, it should be random everytime you select it. (I don't know how "random" this is, if it is time based or voltage, or.. the prng should spit out randomness)
Offline
Hi - maybe it's the wrong place but...
I started with a new (and blank?) NXP DESFire Ev1 and tried to use the "hf 14a raw" command to get at least the version information correctly.
proxmark3> hf 14a raw -c -s -p 0260
received 7 octets
04 5D 0D E9 BD 22 80
received 11 octets
02 AF 04 01 01 01 00 1A 05 38 8A
proxmark3> hf 14a raw -c -s 02af
received 138 octets
02 AF 04 01 01 01 00 1A 05 38 8A 44 03 20 08 06 75 77 81 02 80 02 F0 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0
0 00 00 00 00
received 0 octets
proxmark3> hf list 14a
Recorded Activity (TraceLen = 23 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transf
er
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
171136 | 175904 | Rdr | 02 af ed 70
| | ?
proxmark3>
It seems to me like a similar tag but I don't understand the huge block of data. I expected the same answer as after first command (02 AF 04 01 01 01 00 1A 05 38 8A).
I tried without "-s"/"-p" option but this is the only working result. PCB=0x02 for "I(nformation)-block".
Any hint what went wrong?
best regards
Offline
In my fork, (if you manage to compile it) there is some Desfire commands,,, like the "hf mfdes info"..
Offline
it's awesome! I didn't manage to auth but the frame wrapping is way better than using raw format and I understand more things now. Thank you very much.
The reading and writing is missing - are you actually / still developing or is it paused?
Offline
I never got a desfire tag where I had read/write access..
I had a oyster card, to test on, which is locked down.
But plenty of it des/3des code was done for "Mifare Ultralight" "hf mfu" commands, which also the Desfire use. But AES and the rest is not in order...
You wanna contribute?
Offline
andalso, when I started there was an issue with bigger ISO frames and their parity. The excellent work from @pwpiwi solved it around last christmas. So the original reasons for this work not being finished is clear..
Then of course is the issue with bringing small and efficient crypto implementations into the PM3 device side... DES|3DES is done, but AES no...
I'd go for implementating it on client side first.
Offline
do you need (little) help?
how can i contribute?
Offline
If you are good with understanding Desfire protocol and crypto.. sure, take a look
Offline
I m to noob for this , i can just test your work and test for confirm
Offline
In my fork, (if you manage to compile it) there is some Desfire commands,,, like the "hf mfdes info"..
How long have u come with your work on DESfire? What are the cmd´s in your fork for Desfire? Besides "hf mfdes info"
Offline
I haven't touched it for a long time now. So I guess what you see is what you get
Offline
Ok, so their is no way to get key´s accept sniffing/snooping?
Offline
You cant get the defires keys either way. There is no known flaw to exploit, neither is the keys sent of the air.
If you get your hands on the master keys, set by the specific system you are trying to figure out, you can do stuff.
As it stands for now, the Mifare Desfire is a secure system
Offline
Ok, then my new bankcard (mastercard) which uses nfc to pay is secure
thanx for the info
Offline
Mastercard runs the EMV?!... And that has some issues, there is the user Peter Fillmore https://github.com/peterfillmore/proxmark3 who impl the EMV standard in the PM3 source. If you read his presentations you might change your opinion about your new bankcard
Offline
ah! thanx, will check his git out.
Offline
btw, see that u are swedish as well as i am?, the card im talking about is the new card from "icabanken"
Offline
Cool, I saw the commercial of it in the mail last week. Were thinking of getting it, just to be able to check peter filmore's changes
Offline
Nice i will compile his git and check it out. hehe
Offline
Compiling it now.. do you know the cmd´s to use? or just "hf 14a read" will do it?
Offline
I wouldn't know, since I haven't test that fork.
Offline
OK, cant get it to compile
[== Undefined ==]
gcc -std=c99 -I. -I../include -I../common -I/opt/local/include -I../liblua -Wall -g -O4 -DHAVE_GUI -c -o obj/proxmark3.o proxmark3.c
In file included from proxmark3.h:16:0,
from proxmark3.c:20:
/usr/include/inttypes.h:290:8: error: unknown type name ‘intmax_t’
extern intmax_t imaxabs (intmax_t __n) __THROW __attribute__ ((__const__));
^
/usr/include/inttypes.h:290:26: error: unknown type name ‘intmax_t’
extern intmax_t imaxabs (intmax_t __n) __THROW __attribute__ ((__const__));
^
/usr/include/inttypes.h:293:27: error: unknown type name ‘intmax_t’
extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)
^
/usr/include/inttypes.h:293:45: error: unknown type name ‘intmax_t’
extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)
^
/usr/include/inttypes.h:297:8: error: unknown type name ‘intmax_t’
extern intmax_t strtoimax (const char *__restrict __nptr,
^
/usr/include/inttypes.h:301:8: error: unknown type name ‘uintmax_t’
extern uintmax_t strtoumax (const char *__restrict __nptr,
^
/usr/include/inttypes.h:305:8: error: unknown type name ‘intmax_t’
extern intmax_t wcstoimax (const __gwchar_t *__restrict __nptr,
^
/usr/include/inttypes.h:310:8: error: unknown type name ‘uintmax_t’
extern uintmax_t wcstoumax (const __gwchar_t *__restrict __nptr,
^
In file included from /usr/include/features.h:374:0,
from /usr/include/stdio.h:27,
from proxmark3.c:12:
/usr/include/inttypes.h:324:1: error: expected ‘,’ or ‘;’ before ‘strtoimax’
__NTH (strtoimax (const char *__restrict nptr, char **__restrict endptr,
^
/usr/include/inttypes.h:336:1: error: expected ‘,’ or ‘;’ before ‘strtoumax’
__NTH (strtoumax (const char *__restrict nptr, char **__restrict endptr,
^
/usr/include/inttypes.h:348:1: error: expected ‘,’ or ‘;’ before ‘wcstoimax’
__NTH (wcstoimax (const __gwchar_t *__restrict nptr,
^
/usr/include/inttypes.h:362:1: error: expected ‘,’ or ‘;’ before ‘wcstoumax’
__NTH (wcstoumax (const __gwchar_t *__restrict nptr,
^
In file included from uart.h:52:0,
from proxmark3.c:23:
/usr/include/x86_64-linux-gnu/sys/types.h:197:1: error: conflicting types for ‘int64_t’
__intN_t (64, __DI__);
^
In file included from /usr/include/inttypes.h:27:0,
from proxmark3.h:16,
from proxmark3.c:20:
../include/stdint.h:17:25: note: previous declaration of ‘int64_t’ was here
typedef long long int int64_t;
^
Makefile:134: receptet för målet ”obj/proxmark3.o” misslyckades
Any clues?
Offline
btw, do you have latest binarys from your fork? I only get error when trying to compile it.
fatal error: QApplication: No such file or directory
#include <QApplication>
Offline
have you installed Qt dev on your linux machine?
Offline