MIFARE ULTRALIGHT AND NTAG2x3 EMULATOR
Home Manual Software News How-To's FAQ

Software

Contents

Android Applications

MIFARE++ Ultralight

MIFARE++ Ultralight was originally created from an existing application of Notepad for Android by adding NFC functions and buttons on top of it.

NFC Shell

NFC Shell was created prior to testing firmwares for NTAG213 and EV1, because they have lots of features (commands) other than READ and WRITE. Development of another more convenient application to manage special memory locations of NTAG213 and EV1 (counters, signature, etc.) is planned.

Firmware Development Kit

Purpose and Features

*** New in version 3 *** : added example code for NTAG213 and Ultralight EV1 emulation

The main purpose of the SDK is to open the high-level part of message processing to the user. Now instead of simply being a functional clone of 5 NFC tags, it can be converted by user to a custom ISO 14443-A message processor based on NFC Forum Generic Type 2 Tag protocol. The user is provided with access to the receive buffer and the reply function, where the message processing code can be created from scratch or modified from the provided examples of already implemented NFC tag processing routines. The user can also program own functionality into the hardware lock switch.

About

The SDK has been created following requests of multiple EMUTAG Emulator users and candidates for purchasing. Users wish to make the Emulator more multi-purpose, add data auto-reload capabilities (e.g. to make the Emulator always read the same content as long as the lock switch is in the locked position, while still emulating security features of Ultralight), add custom backdoor commands, and even change the UID length to either 4 or 10 bytes... If you are one of such users, then the SDK is definitely for you!

Limitations

As with any commercial product, there exists a part of code closely related to hardware and which requires careful tuning, as opposed to simple logical routines. This part, a.k.a. the "main" code, implementing the RF modem, has been isolated from the source code, compiled separately, and provided in form of object file "main.o". That way the user does not need to worry if the code compiles correctly and respects critical timing sequences, as all the RF frontend and synchronization firmware is already compiled. The only constraint left to verify is to make sure the overall execution time of the user code fits within the time slot between the request and the response.

Another reason for the lack of the source code for "main.o" in the SDK is in order to make RF testing difficult to anyone wishing to make a commercially sellable clone of MIFARE Ultralight Emulator. The code takes advantage of hidden features/flaws of the CPU that have been tweaked using an oscilloscope to synchronize reply frames down to a single clock cycle of the RF carrier frequency.

Programming Hardware

Whether it's easy or not for electronics gurus to figure out the programming slot pinout, it is provided in the How-To's section.

Copyright © emutag.com emutag.net 2014-2024