NEFS - A rudimentary filesystem for NFC devices

Dear community,

I’m excited to share my latest project with all of you today. NEFS (NFC Exchange Filesystem) is a rudimentary filesystem for NFC devices. The filesystem is based on the NDEF (NFC Data Exchange Format) standard and uses the NDEF message format as a foundation for it’s entry based filesystem structure. This allows the NEFS filesystem to be compatible with every NFC device that supports the NDEF standard. Meaning, that you can now store your files on any NDEF compatible NFC device. The only limitation is the storage size of your NFC tag. But if you’ve got an Apex with the 32kb NFC Share applet installed, you can store all kinds of files on it! If you wanna know more about the technicalities, you can find the documentation for NEFS here: NEFS_Documentation.pdf

NEFSplorer - https://fosa.lu/NEFSplorer

Of course, a filesystem is useless if you don’t have a piece of software to read and write from, and to it. This is where NEFSplorer comes in. NEFSplorer is similar to your usual file explorer suspects, but to make access as easy as possible, it runs inside of your browser. Currently, NEFSplorer is supported on all Android devices with an NFC antenna and an up-to-date version of Google Chrome. Hardware and software support could be extended in the future if Web NFC support becomes more widespread. NEFSplorer is not only a website, it is a PWA (Progressive Web App). Meaning, that it can be installed as an app from inside of Google Chrome as shown below:



Different file types are natively supported, making it easy to view these files directly within NEFSplorer. If a file type is not natively supported, it will be automatically downloaded to your phone when you try to view it. Here is a list of the natively supported file types:

  • JPG (JPEG)
  • PNG
  • GIF
  • MP3
  • WAV
  • OGG
  • TXT

Below, you’ll find a short video showing the basic functions of NEFSplorer:



By now you may be wondering “But, if NEFSplorer runs inside of a browser, how can I be sure that it doesn’t steal and upload my files and data to some remote server somewhere?”. Well, I’m telling you that NEFSplorer does NOT upload ANY user data to anywhere other than your NFC device. But we all know, you should NEVER trust a stranger on the internet, that’s one of the reasons why I chose to release NEFS and NEFSplorer under the X11 MIT license, making it fully open source and giving the community “the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software” as stated inside the source code of NEFSplorer and the NEFS documentation. The source code is available here: NEFSplorer_source.zip

If you got any ideas for improvements or new features, drop them right below this post and maybe I’ll add them. Same for questions, if you got any, drop them below.
I hope you’ll enjoy storing files on your implants and other NFC devices!

Cheers,
Sam

9 Likes

Wow nice! Can you explain some more about how files are managed? When we get to 32kB or larger (in the works), file directories might help save time if you can map file starts to memory blocks. In fact, do you deal with dynamic memory access at all or are you reading and writing the entire memory?

1 Like

Thanks :grin:

Sure, files are managed as 2 different NDEF messages. The first one is a filename entry which contains a flag byte “f” followed by the filename. The second NDEF message follows right after the first one and is a data entry. It contains the file’s data as either a data URI or simple text. I think you could store the data as a MIME object too, but I was unable to figure out how. The Web NFC documentation seems to be incomplete.

Nope, I’m not. I’m reading the whole thing, convert the filesystem to a multidimensional array, do the file operations in there, convert it back to the filesystem as NDEF messages and then write the whole thing to the tag.
I’m not sure if dynamic memory access would even be useful for implants. :sweat_smile: You would have to keep your implant and phone perfectly coupled while you use the filesystem. With the way I do it, you scan it, do your changes and write the changes to “disk” when your done.

3 Likes

Sweet! I could implement this in Zinc! :zinc:

4 Likes

Are these two actual NDEF messages or is it one message with two NDEF records inside?

I would cast my vote for this being the most important thing to address long term. I’m not sure if it’s possible to control block level reads and writes via Web NFC but being able to reduce wait time and memory block wear on writes would be a good goal. A 64kB container is possible and coming to Apex, and I would find it quire useful actually to be able to store and interact with discreet files, but do so in a quick and efficient manner.

Another thing that would be interesting would be URL / URI hooks to specific files on chip. That way I could effectively “bookmark” the file on my phone, then tap to retrieve it. I’m not exactly sure what the utility would be here, other than not keeping the file itself on my phone (just the quick access bookmark).

2 Likes

Sure man, that’s why it’s open source :ok_hand:
You could either reuse code from NEFSplorer or you build your own Fileexplorer implementation around NEFS itself. Could be cool to have multiple tools that can use the same standardized filesystem :grin:

3 Likes

I was going to do something like that at some point anyway so this is going to be very helpful!

Yes we should absolutely follow the same standards!

3 Likes

Ups sorry I meant records. They are two NDEF records within a single message.

Hmm yeah now that I think about it that way, you’re right. But I don’t think it is possible to only read and write from/to a specific NDEF record, especially when using Web NFC :thinking:

I could implement something similar, but you would unfortunately still need to read the whole NDEF message when accessing the file’s data.

1 Like

If you need help with anything or if you have any questions when implementing, just DM me :ok_hand:

That’s the spirit!

2 Likes