Android NFC data forensics – More fun with SQLite
The other week I made it out to the NYC4SEC meetup to speak about NFC. It was my first time going, and I found the group to be a very creative bunch. We had a good time speculating on the Google Wallet announcement coming the following day, and I had been reading that a number of the attendees would come from a forensics background. This got me wondering about what NFC data could be recovered from a Nexus S.
To start, both reading an NFC tag or initiating an NFC LLCP connection will cause intent messages (and often some debug messages) to show up in the Android log buffers. However, this information isn’t written to disk and thus will not be persistent if the device is rebooted. It does not appear that there’s a global, system-wide way that NFC information is logged; but that’s not to say some common NFC applications won’t log this data.
Lets look at the default Google “Tags” application, which will handle NFC tags by default (if no other applications have registered intent-filters for them). Stored application data will be in the application’s /data/data/com.google.android.tag directory. In there, the databases directory contains a “tags.db” sqlite3 database. This database has a table named “ndef_msgs” which appears to store a copy of every NDEF message which made it to this application. This appears to go back to the first tag that we ever scanned with the phone (curse you Touch-A-Tag and your write locked ultralights). This table includes a timestamp in the “date” field, a human readable string in the “title” field, and then the full NDEF message in the bytes field. If you view the bytes data in a hex-editor, you’ll see the NDEF headers data structures as defined by the NFC-Forum.
Data in the Tags.db sqlite3 database
One important thing that is not recorded is the UID of the tag which is scanned. The UID is relatively unique and would go a long way to saying a particular physical tag was scanned at the time recorded in the database. Especially when you consider how these tags are envisioned to be used, posted in a static location where you need to be within 2 centimeters away from. If the UID was recorded with the timestamp and data, this might have become yet another database tracking privacy issue. I’ll leave it to the comments section of this post to discuss the current implementation’s privacy concerns but, outside of a factory reset, there doesn’t appear to be GUI option to clear this data.
I also took a quick look at both the NXP TagWriter and Farebot application. Both have similar databases in their application directories with some exceptions. The NXP database (/data/data/com.nxp.nfc.tagwriter/databases/taghistory.db) appears to only recorder the last 10 tags written. This matches up with the “History size” option in the application’s settings menu. The Farebot database file (/data/data/com.codebutler.farebot/databases/cards.db) does appear to record the UID of the tag scanned and an XML encoded version of the full information which was able to be read from the tag (sector data, access rights, etc). There is a “created_at” field, which one would assume is for the time-stamp; however, this does not appeared to be populated in any of the records on my device.
If you’re interested in getting to know more about NFC and security issues, join us for a webcast on June 16th. We’re calling it “NFC for n00bs”, so in that vain, leave the suits and ties at home for this one and expect a few bad football puns and screen shots of hex-editors.
Post a comment or leave a trackback: Trackback URL.
