The Nintendo NFC adapter, formally Nintendo NFC Reader/Writer and codenamed Fangate, is an external device which adds NFC capabilities for amiibos to old Nintendo 3DS and Nintendo 2DS consoles, using the infrared port on the back of the console.

It launched simultaneously with Animal Crossing Happy Home Designer, with which it’s optionally bundled; it can also be bought standalone at a nominal price of 21 €.

Based on analysis of the fangate_updater.bin file, which is part of the old Nintendo 3DS operating system since 9.3.0-21 and contains the firmware running on the external adapter; and analysis of the NFC Services running on old 3DS.

• SOC inside the adapter: Broadcom BCM20791B1 or ST proprietary “MCU-FGT/rev.A/GH24S VQ”
• CPU: ARM Cortex M0
• Communications: infrared, with ir:USER running on the console. Uses obfuscated payloads. Baud rate is 115200 bps.

Memory map:

Packets are sent using IrDA-SIR (using ir:USER), with a 8N1 encoding (eight data bits, one stop bit, without parity). Each one is formed by a 2-byte header, a varint with the payload size, an obfuscated payload, and trailing error detection byte.

Frames are encoded using two different yet very simmilar formats, depending on how large the payload to be transmitted is:

• For payloads with less than 64 bytes, the third byte represents the payload size.
• For packets with up to 16383 bytes, the size is split in two bytes, with the third byte being the upper 6 bits of the payload size, OR’d with 0x40, and the fourth being the lower eight bits of the payload size

IR framing format - short frame

IR framing format - long frame

The packet header is fixed and consists in a synchronization byte (0xA5), followed by a unused (possibly RFU) zero byte. After these two hardcoded bytes, there’s a varint representing the payload size, which may use one byte or two, depending on the how big the payload is.

In C:

uint8_t * setPacketHeader(uint8_t * buffer, size_t payloadSize) {
    assert(payloadSize < 16384);
``
    buffer[0] = 0xA5;
    buffer[1] = 0x00;
``
    if (payloadSize < 64) {
        buffer[2] = payloadSize;
        buffer += 3;
    } else {
        buffer[2] = 0x40 | (payloadSize >> 8);
        buffer[3] = payloadSize;
        buffer += 4;
    }
``
    return buffer;
}

The payload is obfuscated using a XOR-based encryption. In C:

void payloadObfuscate(const void * voidplain, void * voidcipher, size_t size) {
    uint16_t * plain = (uint16_t *) voidplain;
    uint16_t * cipher = (uint16_t *) voidcipher;
    size_t halfCount = size >> 1; // Divide by 2 rounding towards zero
``
    uint16_t xorval = htobe16(0xE963);
    size_t i;
``
    for (i = 0; i < halfCount; i++) {
        xorval ^= plain[i];
        cipher[i] = xorval;
    }
}
``
void payloadDeobfuscate(const void * voidcipher, void * voidplain, size_t size) {
    uint16_t * cipher = (uint16_t *) voidcipher;
    uint16_t * plain = (uint16_t *) voidplain;
    size_t halfCount = size >> 1; // Divide by 2 rounding towards zero
``
    uint16_t xorval = htobe16(0xE963);
    size_t i;
``
    for (i = 0; i < halfCount; i++) {
        uint16_t word = plain[i];
        cipher[i] = xorval ^ word;
        xorval = word;
    }
}

The trailing error detection byte is calculated using CRC-8-CCITT over the whole packet (both the header and the payload)

ircom is a simple stateful point-to-point master-slave communication protocol built on top of IR layer 1.

• Random values are generated using a Mersenne Twister whose seed is based off the NFC adapter system tick counter. It is therefore random, and the 3DS won’t attempt to validate them by any means. Its purpose is to make every encrypted packet look completely different to the previous one. This makes a replay attack impossible without knowing the encryption algorithm.
• NFC adapter will ignore packets whose protocol version is not 1. It will not even reply.
• Connection identifier is a random byte the 3DS assigns to identify the connection should there be several connections in range at once. Slave devices must save this value from the initial handshake packet and use it for replies. The 3DS will also save the connection identifier byte of the slave which is also random. The 3DS must also ignore packets whose connection ID does not match.

Layer 3 is the payload of layer 2. A lot is unknown of this layer and thus a lot of assumptions were made in the following tables.

Layer 3 contains the following data:

• Request identifier nibble is incremented by 0x1 at every new request by the master, the same value for this byte is also sent by the slave in response to the request of the master
• Slave/master identifier byte is 0x1 for a message from the master and 0x10 for a message from the slave

Acknowledgement message always send by slave. Payload always contains

0x000000AA

Payload contains firmware version and battery level of NFC adapter. Payload has a size of 6 bytes.

• NFC reader LED already turns red when the battery level byte is 0x2, this will also trigger a low battery level warning on the 3DS

The purpose of this request by the master is unknown. Slave always responds with ACK. Payload of this request is always 0x0003E8AA

Payload contains data regarding NFC communication. The first byte of the payload means the following:

• After the tag is written by the master and dumped again, the first few dumps start with 0x03, this changes to 0x05 after a few dumps. The reason for this is unknown

Request from master to start NFC communication. Payload always contains 19 0x0 padding bytes, followed by 0xC80300393A737486000001 and another 26 0x0 padding bytes.

Request from master to write to NFC tag. The request packet already contains the desired data to be written to the tag. Payload start with two 0x00 padding bytes followed by the 7 ID bytes of the tag. These ID bytes are used by the NFC adapter to check if same Amiibo is placed on the NFC adapter again.

NFC handshake beacons:

• 🔗 BCM2079x brief on Broadcom’s website
• 🔗 Python scripts to sniff and spoof IR communication between the NFC reader and 3DS using an IRda adapter