FlexDF not working?

Don’t know if it’s a compatibility issue. I have a pixel 2 XL. I installed it on the left most side of my left hand and I can’t seem to get a read off of it. It’s the older one by the way I’ve had it for about 4 months.

All my findings: FlexDF Getting Started Tutorial

Just tried it with my friends iPhone 8 and it still doesn’t seem to be working, It was also installed logo side up if that makes any difference.

I have a xnt installed on my in my left hand and with my new phone I just got today which is the Google pixel 2 XL and letting you know it works fine the top part of the back where the camera on the phone resides is the sweet spot for the vivokey as well as the xnt

1 Like

You are my Lord and savior

Okay just one more thing, when I scan it using the dangerous things app it says “tag was lost” how do I fix this?

I think the Dangerous Things App works only with the xNT and not with the flexDF

1 Like

Thanks guys super super helpful!

The flexDF does not come formatted for NFC. without an NFC application defined for the flexDF the most you will get is maybe an audio cue that it’s being read. You’ll want to first try using taginfo to try and read it. dngr.us/taginfo

Thanks for the recommendation! When I try and write to it though, I’m getting an error saying that it can’t be written to. When I click erase and the erase and format as ndef, it says it can’t be formatted :confused: I’m not really sure what I should do.

hmm… get the TagInfo app linked above and do a full scan, then share that data here.

also what app are you trying to use to write to it?

I was just kind of messing with it and somehow it ended up writing something. I don’t think it really did anything problematic but I figured id stop messing with it until I did some more research. here’s the scan. I was writing to it using the NXP tag writer app (using anything else before its like lock protected sketches me out). the reader app says its formatted even though the writer app says it’s not and it needs to be formatted first. The support app is returning all null values.

** TagInfo scan (version 4.24.4) 2018-10-29 22:21:12 **
Report Type: External

– IC INFO ------------------------------

IC manufacturer:

NXP Semiconductors

IC type:


DESFire Applications:

Type 4 Tag version 2

– NDEF ------------------------------

No NDEF data storage present:

Maximum NDEF storage size after format: 7678 bytes

Capability Container (CC) file content:

Mapping version 2.0
CC length: 15 bytes
Maximum Le value: 59 bytes
Maximum Lc value: 52 bytes
NDEF File Control TLV:

  • Length: 6 bytes
  • NDEF file ID: 0xE104
  • Maximum NDEF data size: 7678 bytes
  • NDEF access: Read & Write
    [00] 00 0F 20 00 3B 00 34 04 06 E1 04 1D FE 00 00 |… .;.4… |

Type 4 Tag File Control Information (FCI):

Type 4 Tag v2 application FCI: [none]
CC file FCI: [none]

– EXTRA ------------------------------

Memory information:

Size: 8 kB
Available: 7.5 kB

IC detailed information:

Capacitance: 70 pF

DESFire App. ID : ISO-FID : ISO DF-Name:

FD5330 : E110 : D2760000850101

Version information:

Vendor ID: NXP
Hardware info:

  • Type/subtype: 0x01/0x02
  • Version: 1.0
  • Storage size: 8192 bytes
  • Protocol: ISO/IEC 14443-2 and -3
    Software info:
  • Type/subtype: 0x01/0x01
  • Version: 1.4
  • Storage size: 8192 bytes
  • Protocol: ISO/IEC 14443-3 and -4
    Batch no: 0xBA6553B520
    Production date: week 53, 2015

Authentication information:

Default PICC master key

– FULL SCAN ------------------------------

Technologies supported:

ISO/IEC 7816-4 compatible
Native DESFire APDU framing
ISO/IEC 14443-4 (Type A) compatible
ISO/IEC 14443-3 (Type A) compatible
ISO/IEC 14443-2 (Type A) compatible

Android technology information:

Tag description:

  • TAG: Tech [android.nfc.tech.IsoDep, android.nfc.tech.NfcA, android.nfc.tech.NdefFormatable]
  • Maximum transceive length: 65279 bytes
  • Default maximum transceive time-out: 618 ms
  • Extended length APDUs supported
  • Maximum transceive length: 253 bytes
  • Default maximum transceive time-out: 618 ms

Detailed protocol information:

ID: 04:31:34:32:C0:4C:80
ATQA: 0x4403
SAK: 0x20
ATS: 0x06757781028000

  • Max. accepted frame size: 64 bytes (FSCI: 5)
  • Supported receive rates:
    • 106, 212, 424, 848 kbit/s (DR: 1, 2, 4, 8)
  • Supported send rates:
    • 106, 212, 424, 848 kbit/s (DS: 1, 2, 4, 8)
  • Different send and receive rates supported
  • SFGT: 604.1 us (SFGI: 1)
  • FWT: 77.33 ms (FWI: 8)
  • NAD not supported
  • CID supported
  • Historical bytes: 0x80 |.|

Memory content:

PICC level (Application ID 0x000000)

  • Default PICC master key
  • PICC key configuration:
    • PICC key changeable
    • PICC key required for:
      ~ directory list access: no
      ~ create/delete applications: no
    • Configuration changeable
    • PICC key version: 0

Application ID 0x3053FD

  • Default master key
  • Key configuration:
    • 2 (3)DES keys

    • Master key changeable

    • Master key required for:
      ~ directory list access: yes
      ~ create/delete files: yes

    • Configuration changeable

    • Master key required for changing a key

    • File ID 0x01: Standard data, 15 bytes
      ~ Communication: plain
      ~ Read key: free access
      ~ Write key: free access
      ~ Read/Write key: free access
      ~ Change key: free access
      ~ Contents:

[0000] 00 0F 20 00 3B 00 34 04 06 E1 04 1D FE 00 00 |… .;.4… |

also what exactly is like the data structure of this thing.i know there’s like a one time writable section and then like a whatever random stuff section but i don’t know exactly what exactly there is. also what does formatting it do exactly?

Unlike typical NFC chips, like say an NTAG216, the DESFire EV1 chip does not have a memory structure exactly. It has memory, but you do not access it in that way… you define “applications” with unique AIDs (application IDs) and those are, more or less, files on the chip. The chip is 8k, so you could define eight individual 1k files, or two 4k files or whatever until you run out of space. Each file can have its own keys and the file “types” have certain commands that can be issued which can manipulate the data. One example would be a “stored value” file type. This will let you issue commands like increment, decrement, balance, etc. and assign permissions to each of those commands to specific keys. This allows, say, a laundry machine to decrement a value for using washing clothes, without giving access to the increment or even balance functions. If the application does not have available stored value for a transaction, the decrement command fails.

If you want to dive into it, definitely check out the data sheet for the DESFire EV1.


WOAH. Wait so your saying this thing basically has like a bunch of little abstract classes on it that I can define however I want, and I can call like certain functions on it using a reader and that reader will receive like the returned value of that function??? that’s like hella dank. Is there any way for me to like write my own applications or “Types” for it, or like an IDE I can use to write and upload these? also like if I’m like doing low level stuff with this, is there any way I could brick it that I should worry about? also like how do I fix mine and make it so I cant lock it before I start doing all of this lol

With the DFEV1 there are master keys. Losing those is about the only way to “brick” it… each application has it’s own keys so you could lose those but then use the master keys to kill that application.

You can’t definitely your own functions, they are built-in and are specific for each file type. Check the data sheet for sure. Google is your friend. No IDE I’m aware of. There might be some apps you could use to investigate…


There are also some GitHub repos for dealing with the DESFire EV1.

Thanks for the help!!! I think I got it now.