Intro

During the last quarantine days, I sent a new commit to RFID Research Proxmark repository. It was my first standalone mode called hf_msdsal. This standalone module will be able to read or emulate ISO-14443A cards automatically if needed it.

Before this standalone, it was possible to communicate with ISO-14443A cards using different methods, hf 14a commands, APDU or EMV functions. The emulation part was limited to simulate a card UID without establishing a complete APDU emulation process.

The idea is to replay or behave as a Visa MSD transaction. Why? because is the Hello World in NFC transactions, and of course, it is useful in many different ways to test new technologies.

When I mentioned reading, I did not refer to read physical cards only. This mode is capable to read Visa data from digital wallets and with long PDOL generation challenges, plus emulate them as well.

The mode

To run this standalone mode is necessary to compiled and upload the firmware to the Proxmark with STANDALONE parameter:

make clean && make -j8 STANDALONE=HF_MSDSAL

./pm3-flash-all

The code follows two modes: reading and emulating:

// States for standalone #define STATE_READ 0 #define STATE_EMU 1

Normally, the hf_msdsal mode initialized in reading mode, but the user can change that behavior setting couple values: token and chktoken.

char token[19] = {0x00}; bool chktoken = false;

This will force the standalone mode to go directly to the emulation process, but the user could switch back to reading mode by pressing the button. Interesting feature if someone needs to emulate something quickly:

The reading process is very straightforward using the Proxmark documented functions. First, set up reading mode.

iso14443a_setup(FPGA_HF_ISO14443A_READER_MOD);

and then, try to select the card:

if (iso14443a_select_card(NULL, &card_a_info, NULL, true, 0, false)) {

If this condition is true, the mode is ready to start reading the card. For that stage, it is necessary to implement APDU commands. To learn more about APDUs, you can learn more from my previous posts.

//Specific for Visa cards: select ppse, select Visa AID, GET PROCESSING, SFI uint8_t ppse[20] = {0x00, 0xA4, 0x04, 0x00, 0x0e, 0x32, 0x50, 0x41, 0x59, 0x2e, 0x53, 0x59, 0x53, 0x2e, 0x44, 0x44, 0x46, 0x30, 0x31, 0x00}; uint8_t visa[13] = {0x00, 0xA4, 0x04, 0x00, 0x07, 0xa0, 0x00, 0x00, 0x00, 0x03, 0x10, 0x10, 0x00}; uint8_t processing [8] = {0x80, 0xA8, 0x00, 0x00, 0x02, 0x83, 0x00, 0x00}; uint8_t sfi[5] = {0x00, 0xb2, 0x01, 0x0c, 0x00};

Those commands are the most common for Visa cards. This does not mean that some Visa cards might need other/different commands to extract data. For this reading purpose, the mode implements a cycle for all the commands to find responses. It is a communication where the Proxmark will answer depending on the previous response, to actually have a flow in the communication.

Here, the key is to find a PDOL if there is any. To be able to extract the track 2. Which will be used to be emulated it later. The EMV tag for PDOL is 9F38.

... if (apdubuffer[u] == 0x9F && apdubuffer[u + 1] == 0x38) { //Check PDOL for (uint8_t e = 0; e <= apdubuffer[u + 2]; e++) pdol[e] = apdubuffer[u + e + 2]; ...

The function treatPDOL is in charge to generate the challenge depending on the PDOL with fine precision to have a correct card answer in the next command.

db# ---- db# [ Challenge generated ] db# 80 a8 00 00 12 83 10 f6 db# 20 c0 00 00 00 00 00 00 db# 00 9f 37 9f 37 5f 2a 00 db# [ Proxmark command ] db# 80 a8 00 00 12 83 10 f6 db# 20 c0 00 00 00 00 00 00 db# 00 9f 37 9f 37 5f 2a 00 db# [ Card answer ] db# 77 4e 9f 10 07 06 01 11 db# 03 a0 00 00 5f 20 0f 43 db# 41 52 44 48 4f 4c 44 45 db# 52 2f 56 49 53 41 57 13 db# 44 65 42 45 05 78 45 97 db# d1 71 12 01 00 10 04 90 db# 99 99 1f 5f 34 01 01 82 db# 02 00 00 9f 36 02 04 00 db# 9f 26 08 fe 50 6e 51 d1 db# fd 4d 98 9f 6c 02 30 00 db# 90 00 db# ----

After reading the card, the standalone will switch to emulation mode automatically.

The most important part in the emulation initialization is the order in how the Proxmark responds to the card reader. Normally, it has to follow this order:

db# +Received a HALT db# +WAKEUP Received db# +Request for UID C1 db# +Request for SELECT S1 db# +Request for RATS db# [Card reader command ]

To debug this challenge, I had to use the NFC Copy Cat tool from Electronic Cats company. Very useful PN532 device and full Adafruit PN532 library support; it accelerated dramatically the debugging process.

https://twitter.com/Netxing/status/1252401466335039489

It is possible to switch back and forth between read and emulate modes. However, it is not possible to go from reading to emulation mode if the Proxmark did not read a track 2 before (solid LED C). Because it needs something to emulate.

Finally, testing in the real world. It will be possible to make a real transaction with the Proxmark? First try, first Proxmark transaction!

Test #1: first time making a payment with Proxmark! pic.twitter.com/hVHGzPVCtR — Salvador Mendoza (@Netxing) April 23, 2020

Yes, that type of replay attack is very well known for many years, and it could be implemented even with Android phones, a PN532 o many other inexpensive hardware. Also, that kind of transaction will work in specific countries only. This attack has limitations, so why bothered to design something like that? what is the big picture in all of this?

MSDSal is a futuristic example to knock the emulation door in the process of 14443A technologies path, and how it could be implemented. Payment cards is just a small branch. Making accessible and available to different researchers will benefit the community, and we will see new and amazing attacks in a near future using these methodologies.

#StayHome & hack!