New NFC Implant Toolkit Application

I think if you have a reader writer app open it should overtake anything else

The application does overtake all NFC intents, and since URL records fall under the same NFC action that text records do, it is natively handled by BioCom, However, from my own intended functionality for URLs, once it discoveres that an ACTION_NDEF_DISCOVERED action (the one text and URLs fall under) contains a URL, it creates a new intent for it to find an appropriate application to open it, essentially following what the default NFC dispatch system would do in this case. Like I said though, I think I will add a settings toggle for those that want to see the URL in BioCom before opening it in browser.

Yes, the application currently does not support reading or writing more than one record, but I do plan on adding that as part of the next major iteration. It’s just a major pain in the ass, so it’s been put off a bit.

2 Likes

Yeah, I only looked into reading multiple records for the briefest of moments when I was trying to do something, I get it’s gonna be a second before it’s a feature

2 Likes

So I just tried popping a jpeg on my ssid and I messed with the memory (its unreadable using normal apps) heres the tag info dump, pic was compressed down to just over 1k 04-73-08-3A-94-51-80_2020-08-09 20-41-18_taginfo_scan.txt (16.1 KB)

Did you try doing an erase through the application?

Yes, “could not read nfc tag” been playing with it was working fine wrote something a bit bigger now nothing.

Do you have the image you tried to write?

20200809_203911

5 Likes

Was it larger than 873 bytes?

Yes, I’ve been playing with a test card and it did write to sector 2

Is that the exact image, cause that one is 67,212 bytes

Yeah, in the biocom app you can compress

Hmmmm, so it wrote fine for me onto a flexDF, but failed to write on my flexNT (due to size). The smallest compression I can get through BioCom with this image is 2052 bytes. Is that the size you attempted to write?

no it was just over 1000, 1498 to be precise

This is the max I’m able to compress

That’s odd for sure. So when you try and use the Erase Tag Contents option, it says “Could not read NFC tag”?

yes, but that appears to be the os message.

I can read pages using nfc shell but the CHK seems to have been changed
After BioCom

[0E2] . 00 00 FF 73 (LOCK2-LOCK4, CHK)
[0E3] . 00 00 00 E2 (RFU-RFU, AUTH0)
[0E4] . 00 00 00 00 (ACCESS, RFU-RFU)
[0E5] . 00 00 00 00 (PWD)
[0E6] . 00 00 00 00 (PACK,PACK,RFU,RFU)
[0E7] . 00 00 00 00 (PT_I2C, RFU-RFU)

Before BioCom

[0E2] . 00 00 FF 00 (LOCK2-LOCK4, CHK)
[0E3] . 00 00 00 E2 (RFU-RFU, AUTH0)
[0E4] . 00 00 00 00 (ACCESS, RFU-RFU)
[0E5] . 00 00 00 00 (PWD)
[0E6] . 00 00 00 00 (PACK,PACK,RFU,RFU)
[0E7] . 00 00 00 00 (PT_I2C, RFU-RFU)

So smashing shit out of it didn’t work.

But managed to get tagwriter to format tag which corrected the TLV and also the CHK. No idea why all the other programs i tried didnt work and niether do i know why NFC Shell failed to work either.

That’s so strange. There’s nothing that happens in the write process that isn’t just standard method calls from the Ndef class. Nothing that I would think would alter those bytes.