Checkmarx Announces New GitHub Action

NFCdrip - NFC Data Exfiltration

NFC Data Exfiltration Research

This NFC research focused on stealthy data exfiltration through NFC radio abuse and signal detection. Although the research started as a way to take advantage of an unprotected component on Android (versions < 7.0) devices, the overall topic is valid for any device that is NFC enabled, regardless of its operating system. This includes smartphones, laptops, USB terminals, printers and other devices that have a NFC radio chip that can be programmatically controlled.

About NFC

NFC stands for “Near Field Communication” and, as the name implies, it enables short range communication between compatible devices. Short range means a distance that is less than 10 centimetres. This requires at least one transmitting device and another device to receive the signal. NFC technology enables wireless interaction between consumer electronics, mobile devices, personal computers, electrical appliances, and NFC-compatible tags.

NFC-enabled devices are unique in that they can support three modes of operation: card emulation, peer-to-peer, and reader/writer. The NFC Forum technical specifications unlock the full capabilities of NFC technology for the different operating modes and are based on the ISO/IEC 18092 NFC IP-1, JIS X 6319-4 and ISO/IEC 14443 contactless smart card standards (referred to as NFC-A, NFC-B and NFC-F in NFC Forum specifications).

NFC is compatible with hundreds of millions of contactless cards and readers already deployed worldwide in an ample range of hardware.

About Air Gaps

When implementing strong security measures on critical computer systems or networks, a technique called air-gapping is often used. Air-gapping is a measure or set of measures to ensure a secure computer is physically isolated from unsecured networks, such as the public Internet or an unsecured local area network. Although sometimes it means just ensuring a device is off the Internet, it may also mean completely isolating the device to reduce potential exfiltration channel supports: removing WiFi cards, cameras, microphones, speakers, CD-ROM drives, USB ports, or whatever can be used to exchange data. NFC is often disregarded as a data exfiltration channel since it is assumed to work only at a very short range.

Use Cases and Attack Scenarios

In this research the main focus is to implement a stealthy, out-of-band data exfiltration covert channel by abusing NFC on a compromised device.

Let’s imagine the following scenario:

Scenario A

  1. A NFC enabled device has been compromised by malware that steals bitcoin wallets.
  2. Either the malware wants to leak the information to an attacker and must be completely stealthy or there is an air-gap in effect, disabling “normal” transmissions (WiFi, Ethernet, Bluetooth, GSM/GPRS), so it uses this NFC exfiltration technique to transmit data back to the attacker.
    Scenario A use case & attack scenario
  3. The attacker receives the bitcoin wallet across the street using a normal inconspicuous AM radio connected to his smartphone, which will decode the received data.

Scenario B

  1.  A high security building, a military facility for example, implements several air-gapping measures for fear of data being stolen from the existing computers. The computers there have no WiFi card, no Bluetooth, and there is only an Ethernet port connected to a local network. Access control to the building is via NFC cards and login into the computers are also via the NFC reader that the computer has.
  2. A compromised employee installs malware on a computer to steal users’ credentials in “real-time.”
  3. For each employee that logs in, the malware uses the same NFC reader used to read the access card, but abuses it and makes it transmit the credentials back to an attacker.
  4. The attacker receives the credentials across the street using a normal inconspicuous AM radio connected to his smartphone, which will decode the received data.

Technical Details

The transmitter and receiver were designed so that anyone without technical electronic skills would be able to produce the same results. The main idea is to use software and off the shelf components to implement both the transmitter and receiver.

Transmitter Implementation

Our research team created two different implementations, one using the Android standard APIs for smartphones and another using libnfc. They both rely on the same basic principle, to turn on and off the poll process on the NFC chipset of the device in order to generate an easily detectable emission on the 13.56Mhz radio band.

There are three main operating modes for NFC:

  1. Card emulation mode (passive mode): the NFC device behaves like an existing contactless card conforming to one of the legacy standards
  2. Peer-to-peer mode: two NFC devices exchange information. The initiator device (polling device) requires less power compared to the reader/writer mode because the target (listener) uses its own power supply.
  3. Reader/writer mode (active mode): the NFC device is active and reads or writes to a passive legacy RFID tag.

In order to transmit data, we are configuring the NFC device in reader/writer mode. Generally speaking, in this operating mode the reader device sends a frequent signal to poll for nearby tags. Since most tags are passive, i.e. they have no power source of their own, these probes are needed for tag detection. The tags work via coil induction between the reader and tag antennas. When a tag is close enough to the reader, it will use the energy from the incoming poll signal to activate itself and respond back to the reader. The read range is limited by the transmitted power density necessary to achieve sufficient voltage for the tag chip to activate.

Since we are not using the NFC radio in the traditional way, let’s first analyse what happens in the air waves on normal operation mode.

Normal Operation

If we visualise a normal device using NFC with the help of a spectrum analyser we can verify that a polling process looks similar to this:

Spectrum Analyzer

The recurring red spikes have usually an interval between 0.5 to 3 seconds and a pattern that is specific to the operating mode, which can be NFC-A (ISO/IEC 14443 A based), NFC-B (ISO/IEC 14443 B based) and NFC-F (FeliCa based). The following table shows the main differences between those modes:

NFC Technical Standards

Modified Operation

In our modified operation, we are trying to control the polling process interval in order to encode information in the polling signal itself. This can be achieved, for example, by making the device poll on and off very fast.

This will result in a fast NFC radio burst that can be controlled and is also easy to detect:

Fast NFC radio burst

In Android, the exact timing between each emission can be hard to control, since we are not working in real time and the execution of the enableReaderMode function is dependent on the OS scheduler. Nevertheless, we can be reasonably sure that it will execute in a certain time frame, so we can use the existence of a burst during a time frame to encode information. We chose this particular function because the operating system we analysed was Android 6.0 and at that time no permissions were needed to call this function.

Based on these bursts, we can implement a simple On-off keying (OOK) transmission scheme. OOK is the simplest form of amplitude-shift keying (ASK) modulation, which represents digital data at the presence or absence of a carrier wave. The presence of a carrier for a specific duration represents a binary one, while its absence for the same duration represents a binary zero.

OOK encoding looks similar to the following diagram:

OOK encoding

In practice, there will actually be several bursts encoding a binary “1” since we cannot accurately control the NFC radio (in this version) and it actually increases the chances of reception in a normal AM/SW radio.

In order to add more resilience to errors in the transmission, Hamming(7,4) we added correction codes for each nibble to the data to be sent. A transmission packet is thus implemented as the following diagram:

Transmission Packet

To transmit N bytes, the sender transmits a preamble, each individual bytes split into 2 nibbles with the error correction code added, and a trailer. Hamming(7,4) algorithm can correct any single-bit error, or detect all single-bit and two-bit errors and adds a cost of 3 bit for each 4 transmitted. To make the transmission more bit efficient other ECC can be employed, such as Turbo codes.

You could implement a simple Android version to send one bit of information with the following function (after proper initialization of relevant variables):

public void sendBit(int bit) {
 long start;
  try {
   start = System.currentTimeMillis();
    if (bit != 0) {
      while (System.currentTimeMillis() - start < TRANSMIT_MS) {
        nfcAdapter.enableReaderMode(parentActivity, null,                        
                                    NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK, null);
        nfcAdapter.enableReaderMode(parentActivity, null,
                                    NfcAdapter.FLAG_READER_NFC_A, null);
    else {
      nfcAdapter.enableReaderMode(parentActivity, null,
                                  NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK, null);
      while (System.currentTimeMillis() - start < TRANSMIT_MS) {
  catch (Exception e) {

This will turn the NFC radio on and off by cycling the reader mode between two modes, NfcAdapter.FLAG_READER_SKIP_NDEF_CHECK and  NfcAdapter.FLAG_READER_NFC_A for a specific amount of time TRANSMIT_MS, in order to generate the detectable bursts.

In the implemented Android application, we can see the bytes being transmitted in the image below, with a preamble every three bytes; each thinner black bar represents a 100ms burst that encodes a binary ‘1’ and the absence of one means a binary ‘0’.

NFCdrip data

You can achieve similar behaviour with libnfc, with slightly different code (after proper initialization of relevant variables):

int sendBit(int bit, int durationms) {
  int duration_us = durationms*1000;
  long int usdiff = 0;
  gettimeofday(&tvBegin, NULL);

  while (usdiff < duration_us) {
   if (bit != 0) {
    nfc_initiator_poll_target(pnd, nmModulations, szModulations, 1, 1, &nt);
   gettimeofday(&tvEnd, NULL);
   usdiff = ((tvEnd.tv_usec + 1000000 * tvEnd.tv_sec) -
             (tvBegin.tv_usec + 1000000 * tvBegin.tv_sec));

This is the general operation of our modified NFC working mode for data transmission. This transmission scheme has two aspects we used a basis for our research: the first is that no permissions were needed on Android (at the date 6.0) to use this method, and the second is that we wanted to use an off-the-shelf, low cost, AM/SW radio. If not for these two self-imposed limitations, we could use a more low-level approach to control the NFC radio, which would most likely achieve an even greater range. That’s a subject for another research project.

Receiver Implementation

As we stated before, the receiver consists in a standard AM/SW radio connected to an Android phone via the mic jack running a custom application. This application samples the input and processes the signal to extract the encoded bytes.


We needed to tackle several challenges to achieve this. To start with, cheap radio are, well, cheap. It is hard to tune a radio to the exact frequency if they are manual dial, and digital ones always have some skew. In addition, the typical bandwidth that normal SW reception has tends to add a lot of unwanted noise. During development it was clear that custom hardware or an RTL-SDR dongle would be much more sensitive to the transmitted signal and hence more precise in the decoding.

Nevertheless, the fact that anyone can access this ubiquitous technology that is an AM/SW radio led us to develop the proof of concept (PoC) using this method. It’s a way that allows pretty much anyone to test and expand on our research. But we recognise a lot of improvements both in the emitter and receiver would make the transmission much more effective.

Design Approach

To support multiple radio models and the uncertainty in the signal coming from the microphone jack, we took a not so obvious approach. For DSP,  we assumed that a simple FFT analysis would not perform very well given that different radios end up outputting different frequencies to be “locked on” and we wanted to make sure the PoC would work on a wide range of devices and sample rates. This also includes different NFC radios as emitters. Since we could not test all combinations, we focused on what changed when a transmission was being made, and that was the existence of static.

Regardless of the AM/SW radio model for the receiver, one thing is certain: we can easily notice the difference between listening to static or some recurring signal, independent of its frequencies. So what the receiver implements, in a nutshell, is a static (or random/white noise noise) detector.

The receiver thread, which translates the actual signal to binary data, works as follows:

  1. It samples the microphone for some time-frame.
  2. It auto-correlates the sampled signal.
  3. If the auto-correlation is low (i.e. noise) add a binary ‘0’ to the incoming bit pool, else adds a ‘1.’
  4. Go to step 1.

After we have the binary data, a set of filtering and error correction codes are applied for preamble detection and data extraction. Using this method, you just have to worry about the existence of a signal or static, and not the particularities of the signal itself.

NFCdrip: raw signal and auto-correlated value

In the image above you can see the raw signal in the upper graph and the autocorrelated value in the bottom part, with the corresponding decoded bit.

Of course, it has caveats, the most obvious being if any signal at all exists in the tuned band, it renders the algorithm useless as it will always output ‘1.’ Still, it works pretty well in the lab and in environments with some signal ‘noise’ as long as the ‘noise’ signal power is not so strong that competes with the transmission signal. It is one approach. There are better ones. In the image above you can see the raw signal in the upper graph and the autocorrelated value in the bottom part, with the corresponding decoded bit.


Some important limitations about the tested equipment are worth mentioning.

  • Only a small range of devices were tested: A USB NFC dongle (ST-Ericsson NFC device PN533 based),a Samsung S6, a Samsung S7, a Samsung S8, a Huawei G7, a Huawei P8 Lite 2017, a Nexus 4 and a Nexus 7.
  • On all tested smartphones, the NFC radio is off when the device is locked, meaning that this attack can only take place while the user is interacting with the device. Since this function is app specific it means that the user has to be using the malicious app (e.g., a game with a malicious library).
  • On tested Android versions, only on versions 7.0 and above, NFC permissions were necessary to use the enableReaderMode. This makes the attack completely stealthy on versions prior to 7.0 because the malicious application does not have to request any permissions to use the NFC radio. Later models and OS versions should be investigated to understand, for example, why it works without permissions on Lineage OS 7.1 and not on Android 7.0. It might also be vendor specific.
  • On some Huawei and Samsung models, interestingly enough, the NFC radio works even in Airplane Mode. In the Nexus 7 and 4, Airplane Mode turns off NFC capabilities.
  • The range of emission changes with the smartphone.
  • The NFC signal is highly directional, most likely because of the usual format of the NFC antenna coils: a square loop antenna.
  • The USB dongle tested exhibits a much higher transmission power and range than most smartphones


NFC is traditionally considered a very short range communications protocol. In this research, we show that NFC can be abused to transmit information at a much longer range than expected, that can reach as far as 100 meters line of sight. This brings a new problem to the field of air-gapping. If this is possible with off the shelf equipment, how far can state level actors develop this technology, if they haven’t done so yet? And how can we properly detect these kinds of information leaks? Can we develop effective countermeasures?

This early research raises more questions than it answers. We are hoping to bring attention to the subject so that the community can improve on the research done and work on answers to prevent this kind of abuse on a broadly deployed technology. Although we don’t predict that this method could affect every day users, as in all air-gap  research, the high profile targets should be aware of the risks presented in this document.

In its essence, despite the caveats and when properly implemented, this is effectively a new, long range, air-gap covert channel, data exfiltration method, using NFC radio bursts.

Read more from our research team.