Closed lvandenb closed 2 years ago
@lvandenb @david-oswald Success at last hacking with the PM3!
The Chameleon firmware is built with debugging options by running make desfire-dev
. Observe that the ISO authentication is now working:
[usb] pm3 --> script run debug.cmd
[+] executing Cmd debug.cmd
[+] args ''
[usb|script] pm3 --> hw dbg -4
[usb|script] pm3 --> prefs set clientdebug --full
[=] client debug........... full
[usb|script] pm3 --> data setdebugmode -2
[=] client debug level... 2 ( verbose debug messages )
[#] Debug log level......... 4 ( extended )
[usb] pm3 --> hf mfdes auth -n 0 -t 3tdea -k 000000000000000000000000000000000000000000000000 -v -c native -a
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] Secure channel: n/a Command set: native Communication mode: plain
[+] Setting ISODEP -> inactive
[+] Setting ISODEP -> NFC-A
[=] AID 000000 is selected
[=] Auth: cmd: 0x1a keynum: 0x00
[+] raw>> 1A 00
[+] raw<< AF EE 91 30 1E E8 F5 84 D6 C7 85 1D 05 65 13 90 A6 C6 D5
[#] encRndB: EE 91 30 1E E8 F5 84 D6
[#] RndB: CA FE BA BE 00 11 22 33
[#] rotRndB: FE BA BE 00 11 22 33 CA FE BA BE 00 11 22 33 CA
[#] Both : 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 FE BA BE 00 11 22 33 CA FE BA BE 00 11 22 33 CA
[+] raw>> AF 30 EB 55 F3 29 39 04 96 77 88 CE EF 33 A3 C8 7B 18 66 1A F1 62 78 A0 28 53 84 67 98 7C BB DB 03
[+] raw<< 00 9B 71 57 8F FB DF 80 A8 F6 EF 33 4A C6 CD F9 7A 7D BE
[=] Session key : 01 02 03 04 CA FE BA BE 07 08 09 10 22 33 CA FE 13 14 15 16 00 11 22 33
[=] Desfire authenticated
[+] PICC selected and authenticated succesfully
[+] Context:
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] Secure channel: ev1 Command set: native Communication mode: plain
[=] Session key [24]: 01 02 03 04 CA FE BA BE 07 08 09 10 22 33 CA FE 13 14 15 16 00 11 22 33
[=] IV [8]: 00 00 00 00 00 00 00 00
[+] Setting ISODEP -> inactive
The plan of attack is to modify the LibNFC testing code in Software/
next and then file a PR to bring all of this in to the main sources. The main changes are to switch the crypto modes from CBC to ECB (as the PM3 software uses), and do some XOR'ing before/after enc/dec as with the PM3, and include a working IV buffer in the auth procedure. This was painful to get working!
Hi @maxieds that sounds great! I will have a play with it next week. Also thanks for the PR - @fptrs who normally does the merges will be away for some time, so I'm not sure if he still has time to review, but otherwise I might've a look as it definitely seems to improve the state of the DESFire impl.
@david-oswald Any luck testing the newest DESFire firmware mods?
Not yet, but I promise I will come to it :)
@maxieds I didn't realize there was an open PR for desfire, I ported my "mfp" hacks to latest master & caught a few more bugs. I didn't see some of them in your PR, but they may have been 'fixed' elsewhere so wanted to check. In particular:
Thanks again for this! My latest MFP code is more isolated from the DESFire command processing to make it less intrusive if people want to expand in the future.
@colinoflynn I incorporated your bug fixes into the code for this pull request. I am slammed right now with work and things to get done. I am also not sure how to adequately test that the bugfixes work. Do you mind compiling the firmware from the most recent commit to my fork/branch and testing? šø
I'll try to give it a check this weekend - I may try to port my changes to that PR as well if I get change, but can at least check it didn't seem to break anything on the base code. Thanks!
@colinoflynn @david-oswald Any updates with testing? Any chance this PR can get merged soon? The Spring 2022 semester at GT is over. This was my RA project for the term. It would be nice to see it in production in case anyone here asks. šŗ
Finally got some time, but I have an issue with the Makefile now git https://github.com/maxieds/ChameleonMini.git DESFire-AuthISO-Patch
$ make desfire ../LUFA/Build/lufa_build.mk:131: The XMEGA device support is currently EXPERIMENTAL (incomplete and/or non-functional), and is included for preview purposes only. Makefile:273: *** recipe commences before first target. Stop.
@lvandenb
I just tried compiling the sources with make desfire
on MacOS with no problems. The trailing lines after the build completes are
[OBJCPY] : Extracting HEX file data from "Chameleon-Mini.elf"
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature --set-section-flags=.flashdata="alloc,load" Chameleon-Mini.elf Chameleon-Mini.hex
[OBJCPY] : Extracting EEP file data from "Chameleon-Mini.elf"
avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 --no-change-warnings Chameleon-Mini.elf Chameleon-Mini.eep || exit 0
[OBJCPY] : Extracting BIN file data from "Chameleon-Mini.elf"
avr-objcopy -O binary -R .eeprom -R .fuse -R .lock -R .signature --set-section-flags=.flashdata="alloc,load" Chameleon-Mini.elf Chameleon-Mini.bin
Chameleon-Mini.elf :
section size addr
.flashdata 0x10000 0x10000
.spmhelper 0x14 0x21fe0
.text 0xe65a 0x0
.data 0x162 0x802000
.bss 0xc6d 0x802162
.eeprom 0x64 0x810000
.comment 0x26 0x0
.note.gnu.avr.deviceinfo 0x40 0x0
.debug_aranges 0x160 0x0
.debug_info 0x29f1 0x0
.debug_abbrev 0x2708 0x0
.debug_line 0x71e 0x0
.debug_str 0x1b33 0x0
Total 0x269b1
text data bss dec hex filename
0xe65a 0x1c6 0xc6d 62605 f48d Chameleon-Mini.elf
AVR Memory Usage
----------------
Device: Unknown
Program: 59324 bytes
(.text + .data + .bootloader)
Data: 3535 bytes
(.data + .bss + .noinit)
EEPROM: 100 bytes
(.eeprom)
The warning from the LUFA make script is normal. It has been printed for years. Looking at line 273
of the Makefile suggests a couple of things. Please fill in more details:
which bash
?A quick fix is to use the binaries I just compiled for testing: current-build.zip
Happy to follow up otherwise.
I finally got around to trying this - I got the same Makefile:273: *** recipe commences before first target. Stop.
error (using WSL). it seems to be the SHELL:=$(shell which bash)
part of the Makefile line 273, I just removed that and it built OK:
check_size: SHELL:=$(shell which bash)
It doesn't look like the SHELL variable was used there and I got the expected size print. On to functional testing...
I ran the test by just compiling with make desfire
and make desfire-dev
(I tried both). The only configuration I did was setting python chamtool.py -p COM4 -c mf_desfire
, and I'd check if it was still responding with python chamtool.py -p COM4 -U
to print the UID in use.
With this configuration, I see:
hf mfdes auth
command without first doing the debug stuff gives me an error - is this a timing issue or just some invalid thing? It looks like the only difference was the debug stuff in pm3 being enabled, it didn't look like any differences in the actual authentication? Here is the output:
[usb] pm3 --> hf mfdes auth -n 0 -t 3tdea -k 000000000000000000000000000000000000000000000000 -v -c native -a
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] Secure channel: n/a Command set: native Communication mode: plain
[+] Setting ISODEP -> inactive
[!!] Desfire AID select error.
[+] Setting ISODEP -> inactive
[-] Select or authentication AID 000000 failed. Result [202] Can't select application by ISO ID.
Trying to use hf mfdes info
causes the ChamelonMini to lock up - it stops responding to my ChamTool requests until I power cycle it. in pm3 I see:
[usb] pm3 --> hf mfdes info
[#] pcb_blocknum 0 == 2
[#] [WCMD <--: : 08/08] 02 90 60 00 00 00 14 98
[#] fukked
[#] switch_off
[!] Command unsuccessful
It looks like it's locking up on GET VERSION
:
[=] downloading tracelog data from device
[+] Recorded activity (trace len = 178 bytes)
[=] start = start of start frame end = end of frame. src = source of transfer
[=] ISO14443A - all times are in carrier periods (1/13.56MHz)
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
0 | 992 | Rdr |52 | | WUPA
2100 | 4468 | Tag |44 03 | |
7040 | 9504 | Rdr |93 20 | | ANTICOLL
10548 | 16436 | Tag |88 08 19 ad 34 | |
19072 | 29600 | Rdr |93 70 88 08 19 ad 34 9a 9d | ok | SELECT_UID
30644 | 34164 | Tag |24 d8 36 | |
35584 | 38048 | Rdr |95 20 | | ANTICOLL-2
39092 | 44916 | Tag |3b 4b ed 57 ca | |
47616 | 58080 | Rdr |95 70 3b 4b ed 57 ca b9 c5 | ok | SELECT_UID-2
59188 | 62772 | Tag |20 fc 70 | |
64512 | 69280 | Rdr |e0 80 31 73 | ok | RATS
70324 | 77364 | Tag |06 75 00 81 02 80 | !crc|
94976 | 104352 | Rdr |02 90 60 00 00 00 14 98 | ok | GET VERSION
[usb] pm3 -->
Anyway the authentication code seems to be working per the instructions & that is great! And still useful for me to build on this for MFP.
@colinoflynn See if the latest commit works for you? An up to date version of the binaries is here: current-build.zip
Hi @maxieds - this seemed to get further, testing shows this result. It does still lock up (stops responding on ChamTool
). For some reason I don't get any useful output with hf mfdes list
(like I did before).
[usb] pm3 --> hf mfdes info
[=] ---------------------------------- Tag Information ----------------------------------
[+] UID: 08 71 98 85 E4 07 E9
[+] Batch number: 00 00 00 00 00
[+] Production date: week 00 / 2000
[=] --- Hardware Information
[=] raw: 63000000000000
[=] Vendor Id: Pragmatic Printing Ltd. UK
[=] Type: 0x00
[=] Subtype: 0x00
[=] Version: 0.0 ( DESFire MF3ICD40 )
[=] Storage size: 0x00 ( 1 bytes )
[=] Protocol: 0x00 ( Unknown )
[=] --- Software Information
[=] raw: C1A0C900000000
[=] Vendor Id: no tag-info available
[=] Type: 0xA0
[=] Subtype: 0xC9
[=] Version: 0.0
[=] Storage size: 0x00 ( 1 bytes )
[=] Protocol: 0x00 ( Unknown )
[=] --------------------------------- Card capabilities ---------------------------------
[#] error DESFIRESendRaw
[#] error DESFIRESendRaw
[#] error DESFIRESendRaw
[#] Card didn't answer to CL1 select all
[!!] APDU: No APDU response
[#] error DESFIRESendApdu Unknown error
[+] ------------------------------------ PICC level -------------------------------------
[+] Applications count: 0 free memory n/a
[+] PICC level auth commands: auth: NO auth iso: NO auth aes: NO auth ev2: NO auth iso native: NO auth lrp: NO
[=] --- Free memory
[+] Card doesn't support 'free mem' cmd
I'll see if I can get better debug output to show what is giving it problems. BTW I forgot you mentioned missing a proxmark at one point, if can help loan one if helpful let me know.
The authentication side seems to work great, so still major improvements overall. Also the build worked OK now for me too from a clean checkout.
@colinoflynn I have some good news to report on progress:
[usb] pm3 --> hf mfdes info
[=] ---------------------------------- Tag Information ----------------------------------
[+] UID: 08 61 44 FE B4 2B F9
[+] Batch number: 00 00 00 00 00
[+] Production date: week 00 / 2000
[=] --- Hardware Information
[=] raw: EC720000000000
[=] Vendor Id: no tag-info available
[=] Type: 0x72
[=] Subtype: 0x00
[=] Version: 0.0 ( DESFire MF3ICD40 )
[=] Storage size: 0x00 ( 1 bytes )
[=] Protocol: 0x00 ( Unknown )
[=] --- Software Information
[=] raw: 91C1ACC7000000
[=] Vendor Id: no tag-info available
[=] Type: 0xC1
[=] Subtype: 0xAC
[=] Version: 199.0
[=] Storage size: 0x00 ( 1 bytes )
[=] Protocol: 0x00 ( Unknown )
[=] --------------------------------- Card capabilities ---------------------------------
[#] Halt error
[#] Card didn't answer to CL1 select all
I introduced a bug somewhere into the auth command:
hf mfdes auth -n 0 -t 3tdea -k 000000000000000000000000000000000000000000000000 -v -c native -a
I did notice earlier today as you pointed out above (before the latest commit with new fixes) that the auth command is buggy without the debugging options getting set by my script. This behavior has now changed to:
[usb] pm3 --> script run test-mfdes-auth.cmd
[+] executing Cmd test-mfdes-auth.cmd
[+] args ''
[usb|script] pm3 --> hf mfdes auth -n 0 -t 3tdea -k 000000000000000000000000000000000000000000000000 -v -c native -a
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] Secure channel: n/a Command set: native Communication mode: plain
[+] Setting ISODEP -> inactive
[+] Setting ISODEP -> NFC-A
[=] AID 000000 is selected
[=] Auth: cmd: 0x1a keynum: 0x00
[+] raw>> 1A 00
[+] raw<< AF EE 91 30 1E E8 F5 84 D6 C7 85 1D 05 65 13 90 A6 C6 D5
[#] encRndB: EE 91 30 1E E8 F5 84 D6
[#] RndB: CA FE BA BE 00 11 22 33
[#] rotRndB: FE BA BE 00 11 22 33 CA FE BA BE 00 11 22 33 CA
[#] Both : 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 FE BA BE 00 11 22 33 CA FE BA BE 00 11 22 33 CA
[+] raw>> AF 30 EB 55 F3 29 39 04 96 77 88 CE EF 33 A3 C8 7B 18 66 1A F1 62 78 A0 28 53 84 67 98 7C BB DB 03
[+] raw<< 7E 4B 16
[!!] šØ Command (af) ERROR: 0x7e
[#] error DESFIRESendRaw Length of command string invalid
[!!] šØ Desfire authenticate error. Result: [7] Sending auth command failed
[+] Setting ISODEP -> inactive
[-] ā Select or authentication AID 000000 failed. Result [7] Sending auth command failed
[usb|script] pm3 --> script run ./debug.cmd
[+] executing Cmd ./debug.cmd
[+] args ''
[usb|script] pm3 --> hw dbg -4
[usb|script] pm3 --> prefs set clientdebug --full
[=] client debug........... full
[usb|script] pm3 --> data setdebugmode -2
[=] client debug level... 2 ( verbose debug messages )
[usb|script] pm3 --> hf mfdes auth -n 0 -t 3tdea -k 000000000000000000000000000000000000000000000000 -v -c native -a
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] Secure channel: n/a Command set: native Communication mode: plain
[+] Setting ISODEP -> inactive
[#] Debug log level......... 4 ( extended )
[#] Card didn't answer to select
[!!] šØ Desfire AID select error.
[+] Setting ISODEP -> inactive
[-] ā Select or authentication AID 000000 failed. Result [202] Can't select application by ISO ID.
I should have some more time to finish up and get the auth command working tonight or tomorrow :)
Anything else I have missed in all of the excellent feedback you gave above?
@colinoflynn
Please check with the latest commit to verify. This is what I get with the PM3 after building with make desfire-dev
:
[usb] pm3 --> script run debug.cmd
[+] executing Cmd debug.cmd
[+] args ''
[usb|script] pm3 --> hw dbg -4
[usb|script] pm3 --> prefs set clientdebug --full
[=] client debug........... full
[usb|script] pm3 --> data setdebugmode -2
[=] client debug level... 2 ( verbose debug messages )
[#] Debug log level......... 4 ( extended )
[usb] pm3 --> hf mfdes info
[#] pcb_blocknum 0 == 2
[#] [WCMD <--: : 08/08] 02 90 60 00 00 00 14 98
[#] pcb_blocknum 1 == 3
[#] [WCMD <--: : 08/08] 03 90 af 00 00 00 1f 15
[#] pcb_blocknum 0 == 2
[#] [WCMD <--: : 08/08] 02 90 af 00 00 00 34 11
[=] ---------------------------------- Tag Information ----------------------------------
[+] UID: 08 4F 8A 44 7D AE 83
[+] Batch number: AE 83 CE E4 A5
[+] Production date: week db / 20f1
[=] --- Hardware Information
[=] raw: 04010100011805
[=] Vendor Id: NXP Semiconductors Germany
[=] Type: 0x01
[=] Subtype: 0x01
[=] Version: 0.1 ( DESFire MF3ICD40 )
[=] Storage size: 0x18 ( 4096 bytes )
[=] Protocol: 0x05 ( ISO 14443-2, 14443-3 )
[=] --- Software Information
[=] raw: 90AF0401010001
[=] Vendor Id: no tag-info available
[=] Type: 0xAF
[=] Subtype: 0x04
[=] Version: 1.1
[=] Storage size: 0x00 ( 1 bytes )
[=] Protocol: 0x01 ( Unknown )
[=] --------------------------------- Card capabilities ---------------------------------
[#] switch_off
[usb] pm3 --> hf mfdes auth -n 0 -t 3tdea -k 000000000000000000000000000000000000000000000000 -v -c native -a
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] Secure channel: n/a Command set: native Communication mode: plain
[+] Setting ISODEP -> inactive
[+] Setting ISODEP -> NFC-A
[=] AID 000000 is selected
[=] Auth: cmd: 0x1a keynum: 0x00
[+] raw>> 1A 00
[+] raw<< AF EE 91 30 1E E8 F5 84 D6 C7 85 1D 05 65 13 90 A6 C6 D5
[#] encRndB: EE 91 30 1E E8 F5 84 D6
[#] RndB: CA FE BA BE 00 11 22 33
[#] rotRndB: FE BA BE 00 11 22 33 CA FE BA BE 00 11 22 33 CA
[#] Both : 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 FE BA BE 00 11 22 33 CA FE BA BE 00 11 22 33 CA
[+] raw>> AF 30 EB 55 F3 29 39 04 96 77 88 CE EF 33 A3 C8 7B 18 66 1A F1 62 78 A0 28 53 84 67 98 7C BB DB 03
[+] raw<< 00 9B 71 57 8F FB DF 80 A8 F6 EF 33 4A C6 CD F9 7A 7D BE
[=] Session key : 01 02 03 04 CA FE BA BE 07 08 09 10 22 33 CA FE 13 14 15 16 00 11 22 33
[=] Desfire authenticated
[+] PICC selected and authenticated succesfully
[+] Context:
[=] Key num: 0 Key algo: 3tdea Key[24]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] Secure channel: ev1 Command set: native Communication mode: plain
[=] Session key [24]: 01 02 03 04 CA FE BA BE 07 08 09 10 22 33 CA FE 13 14 15 16 00 11 22 33
[=] IV [8]: 00 00 00 00 00 00 00 00
[+] Setting ISODEP -> inactive
With both make desfire
and make desfire-dev
I get this error:
BuildScripts/lufa_build_extra.mk:131: The XMEGA device support is currently EXPERIMENTAL (incomplete and/or non-functional), and is included for preview purposes only.
basename: extra operand ā../LUFA/Drivers/USB/Core/DeviceStandardReq.cā
Try 'basename --help' for more information.
make: *** No rule to make target 'Bin/HIDParser.o', needed by 'Chameleon-Mini.elf'. Stop.
There's no line number so not sure (it looks like maybe from an included makefile?), do you know offhand where things were tweaked? I'm building it on Ubuntu (using WSL).
@colinoflynn Please check one more time with the latest commit. If that doesn't work, you can try testing with the binaries I just compiled in this archive: latest-desfire-build.zip.
BTW, thanks for the proxmark offer. My advisor gave me some money from her grant this Spring to buy one :)
Got it! Will test those binaries - the output now fixes the basename problem, but I still get:
make: *** No rule to make target 'Bin/HIDParser.o', needed by 'Chameleon-Mini.elf'. Stop.
How are you building that doesn't trigger the errors?
@colinoflynn
Hmmm. Did you try running make clean
first? If not, I will try to debug with my Arch Linux box later.
Nevermind. It should work now.
It looks like brew
distinguishes the standard system make
with its version called gmake
on MacOS. The Linux make
command is (looks like) equivalent to gmake
on Mac. Now we know...
The make
build problems should now all be resolved. As a bonus, running make desfire
or make desfire-dev
should be quicker on the average: I convinced the Makefile
to not rebuild the LUFA library objects at each fresh compile of the Chameleon sources. Some might also checkout the predefined custom build targets in this build script to start on the idea from #283.
@colinoflynn @lvandenb
I have some technical problems with the code in the latest commit interfacing with the USB/PCSC ACS-122U reader. The PM3 compatibility still works, but the USB reader will not recognize the Chameleon with CONFIG=MF_DESFIRE
like it did several months ago. I can trace the problem down to where the reader/PCD issues the Chameleon a DESELECT (0x2E
) command:
(Updated to include the CMLD screenshot on my phone)
What response should it actuay be sending back? This happens after the anticollision loop and RATS are satisfied. My start to fixing this issue is found here -- all commented out again after failed tests of the code.
Here are current binary builds: latest-desfire-build.zip
I'm travelling for some events - I did throw PM3/CM in my bag in case I've got time, but it's likely I'll be away from this for a couple weeks, will update if I get a chance to try. Unfortunately no other reader with me so on the final problem I can take a look once I've back to office.
If anyone else wants to help out with testing PR #319, it would be nice to add some example DESFire configuration dumps generated with non-default interactions with the Chameleon. Also, posting this request as a follow up on the PR thread.
@david-oswald @fptrs
I think we can close this issue now that PR #319 is merged. I will check the latest DESFire firmware build with my two local PCSC external USB readers later tonight. If there are still problems getting pcsc_scan
to recognize the Chameleon running CONFIG=MF_DESFIRE
, I will start a new issue where we can follow up. šø
Thanks for more updates! I'll still try and test them, my trip got messed up due to COVID/travel complications so I still didn't get around to it... but if I find any problems will work through them on new issue.
module MifareDesfireProcess will not work for real iso - 8716 apdu like
right now, it is only testing "wrapped desfire" or "native". and it fails or the first command...
in this case buffer[2] == 0x04, and some iso-8716 do not have a LE field ...
And it seems simple to do if Buffer[0]==0x90 then wrapped for sure, else if Buffer[0]<0x0a then most likely 8716 else most likely Desfire Native. for native check the first byte as a valid command, otherwise the second..
most of the time, communication starts with file select , like "select the desfire app" (this is optional but recommended) 00 A4 04 00 07 D2 76 00 00 85 01 00
on windows, it will always try 00 a4 04 00 0b a0 00 00 03 97 43 49 44 5f 01 00 9e 32, first, if smartcard services are enabled. ( so windows users using the pc/sc api, will always fail trying native desfire when the smartcard service is active)
for the global communication there should be a flag, like "protocolFraming" = unknown / native / 8716 after the card becomes "state active" , the first command determines the protocol framing. until reset..