NFC devices allow two-way communication just like Bluetooth and WiFi. It works on the principle of sending information over radio waves. It is another standard for wireless data transitions which means that there are specifications by which devices have to adhere to in order to communicate with each other properly. We got a project in which our Client required NFC message exchange mechanism, cryptography and local database management for his custom hardware devices.

The purpose of  Client’s App is to authenticate specific custom hardware devices (developed by Client) in order to grant them secure access to specific data. The authentication data is exchanged over an NFC interface as an NDEF message. Client was working on development of his custom hardware (USB storage) device which he wanted to pair with an Android application for authentication. The main purpose of this application was to prevent unauthorized users from accessing the data, formatting USB storage or execute other commands of sensitive nature. The hardware had to be first unlocked by using the Android App. The application was planned to be built in 2 phases.

As the underlying hardware was still under development, the development team did not have the actual hardware device to develop and test the App. Rather, the Client provided different hardware which could simulate the actual hardware’s behavior. The equipment included:

• Dual Interface EEPROM board
• CR95HF Demonstration board
  .

The client also provided our team with links to software and driver details for the underlying hardware. The Dual Interface EEPROM board has an integrated NFC chip inside it which reads and writes NDEF messages to other NFC supported hardware. CR95HF demo board can read and write messages to EEPROM by placing EEPROM over it. Our developer write specific message to EEPROM using CR95HF and read from our App and vice versa.

How Requirements Were Fulfilled?

During the 1st phase of Project development, following requirements of Client were fulfilled:

1- Client had shipped the hardware off to us and we had only one week for research. We prepared some demo applications for reading and writing standard NDEF messages, which worked at our end. The software links that client provided were for windows based systems, while our developer was working on MAC machine, so we had to run Windows XP inside a Virtual Machine software.

2- We installed the required software and connected the hardware successfully. We then tested the sample Apps prepared earlier, and they performed well on the simulation hardware as well. NDEF messages were also being read/written to the hardware accurately. Our team prepared and shared a build with the client to test with the actual hardware, only to receive this response: “Nothing is working”. Our sample App could not read incoming NDEF messages. The Client then mentioned some sample Apps from Play Store, which were able to work with his hardware. We had no choice except to reverse engineer those Play Store Apps.

3- During the process of reverse engineering, we found that the hardware was using its own format of NDEF messages which was unusual. We traced down the format and finally found some helpful information on the Internet about that format. We changed our implementation accordingly and sent the updated build to client.

Conclusion:

The following feedback was good and the application was able to perform the required tasks. Once the basic functionality was tested, client then asked for some UI adjustments, after which the first phase was complete.

Second phase of the application development is related to adding Bluetooth support i.e. communicating commands over Bluetooth similar to NFC based communication, other features addition like formatting USB storage, exploring file system of USB storage, lock/unlock and some other enhancements.