proxmark3
proxmark3 copied to clipboard
RfidResearchGroup
ISO14443B EMV commands
I got this as strong need. Any insight on how hard the work is needed ? (Besides the actual status of poor reliability I've found regarding B channel commands...)
the 14b lowlevel stuff isn't the best, we would need to start with the "great hf fpga stuff to take from offical" issue (internal) to get better lowlevel. Then much of the current 14b, already supports sending raw commands. which the emv layer could build upon.
some starting points in the top down approach:
Look in emv/cmdemv.c where Hf14443_4aGetCardData is used and add some logic to probe for a TypeA card then a TypeB card (and remember the choice A<>B in some state var) which means adding a Hf14443_4bGetCardData in cmdhf14b.c
then look in emv/emvcore.c where ExchangeAPDU14a is used and add logic to choose between ExchangeAPDU14a and ExchangeAPDU14b depending on stored A<>B which means adding ExchangeAPDU14b in cmdhf14b.c
okay there is much less for isob apdu than what I thought in the code :(
At first duplicate code from client/cmdhf14a.c to client/cmdhf14b.c : SelectCard14443_4 (needs heavy rewrite for B, no ATS there), CmdExchangeAPDU, ExchangeAPDU14b, CmdHF14BAPDU Firmware itself needs to get new CMD_HF_ISO14443B_READER, ISO14B_SEND_CHAINING, ISO14B_NO_DISCONNECT
Once first poc works, factorize code to avoid duplication between typeA and typeB (and pleeeease move iso14a/iso14b/iso15/felica out of include/mifare.h :D)
Yeo that's seems enough and straightforward but we still need the fpga improvement. Who's able ?
I added the hf 14b apdu command. It doesn't do the FWT and framesize yet, but it shouldn't be hard to add.
We got the FPGA from mergehell, the 14b commands has been re-written to work, the apdu is done, I see no reason for EMV 14b to be implemented now
A fix for 14B Shallow mode is pushed to fpga / repo and if we want to add more commands, this is the time :)
I think 14b EMV should work now, since it works with 14b APDU and emrtd via 14b.
Closing