Yes they will be and yes I’ll send you some asap
1 Like
So it loks like the problem mentioned above by @Devilclarke most likely has to do with this:
I was not aware of this problem, as I don’t have an xSIID installed, nor do I have any NTAG i2C devices. After I get a few, I’ll start messing around with the special care that this device needs in order to take full advantage of the 2K bytes of memory it’s got. I’m just about to start with programming up some of the base activities, fragments and utility classes for the DangerousNFC 2.0 application (after I finish mocking up the UI, writing some base logic out, and running it by @amal ). We’ll have plenty of motivation with that project to make sure the xSIID is fully “writable”.
5 Likes
Beautiful!!! Can’t wait to get my hands on one.
After much back and forth with NXP over the issues with the xSIID and accessing all 2k, it appears that android and iOS simply choke on trying to read ndef data that skips over a reserved section… and after reviewing the NFC Type 2 forum specification, there clearly is no provision for handling memory topography like that. The Memory TLV definition simply handles a single reserved section but there is no provision for reading memory beyond it, so basically the phones and reader chips in the phones can easily access that extended memory sector on 2k NTAG I2C chips, and you could also easily write your own mobile applications to do so, in the end the NFC library functions in both phone OSes which read and parse the data simply trip over it and land on their faces.
As such, these cards currently have 2k chips but they have been set up with a CC (capability container) that only addresses the first 1k for NDEF data. New cards, if they are made, will have 1k chips. The same is likely to be true for the next batch of xSIID as well.
3 Likes
2K… Pff… 640 bytes ought to be enough for anybody.
1 Like
If I make a gif that small, can it be scanned to show that by anyone?
I was thinking that when I saw your post the other day. I will give it a shot.
curious what NDEF record type is used for that?
Either NFC forum external type (TNF 4) or unknown (TNF 5) works with Android. When Android sees one of those two types, it grabs the first string in the text record and interprets it as a mime type - in this case, text/vcard, but it can be anything as long as Android can match it to an intent.
This is non-standard though. Pretty much Android-specific behaviour. However, seeing as though Android is a kind of a de-facto standard… 
1 Like
Man, that really sucks.
I don’t suppose we’ll see any way to get access that extra bit of memory then. It looks like Ultralight android APIs allow for specific page indexes when writing raw bytes, but there’s nothing of the sorts that I can see that would work with the i2c where we could maybe skip that reserved section manually. Nothing to extend/modify either that I can find. It doesn’t seem like the code for how android handles read/write operations under the hood is even available, and what is available isn’t granular enough to be able to modify for different results.
1 Like
Yep thats what I got from nxp was talking to them as my work may have an application for the i2c (allowing customers to store settings for our device and update them via ther phone).
The litteral response i got from nxp was “the 2nd sector is not meant for ndef data” when I asked what it was for then I was told “whatever your application wants to write but it can’t be read with a phone”.
1 Like
Just to be perfectly clear, it can be read with a phone perfectly fine… as in your application can read and write to sector 1 no problem… it’s just the OS ndef procedures will fail to properly navigate to it in the process of automatically reading memory sectors during an ndef intent. You could, in theory, write your own code to pull the entire ndef data tlv down and like, force it into the ndef intent for parsing… but pretty sure you’d need root to have the phone accept it and process it.
It’s a nuance that’s irrelevant for most people, but important to understand exactly what the problem is so we can find that one dev responsible at Apple and Google so we can harass and shame them hahah
1 Like
Yeah sorry that wasn’t very clear they said it won’t be able to be seen as 1 contiguous block of ndef data.
2 Likes
I know I could get it to read the payload correctly, albeit with some real manual elbow grease, just from manually parsing the raw payload like you said. I’ll try testing that approach in the new DangerousNFC application soon. However, writing seems to be 100% out of the question. if there was a way to write raw bytes at specified indices of memory on something like the i2c, then it would probably be manually feasible, but I see nothing of the sort on Android.
Yep you absolutely can manually write data to specific memory pages… check the dangerous NFC source… that’s all I’m doing is manually writing stuff But, the ndef library that normally takes your payload data and handles encapsulating it into an ndef message and subrecord and then splits it all up and writes it to contiguous memory pages for you… yeah that also doesn’t work when wanting to automatically write across multiple sectors on an ntag i2c… damn shit works across sectors of a Mifare classic… but that’s it’s own band-aid non-nfc special crap nxp bunged into android codebase.
3 Likes
Hello everyone. I wanted to drop some changenotes on a recent update pushed to BioCom, as well as give a sort of timeline and future plan for features to come. I guess I just felt so damn inadequate in my track record for writing update logs as compared to the wonderful @RyuuzakiJulio that I had to start trying.
BioCom R1.5
Some new features:
-
Markdownsupport is now availible as a data type to choose from when writing records. I added a basic markdown editor toolbar in the edit page that hopefully makes it a bit easier to write some beautiful markdown notes/reminders/whatever. - UI cleanup of the “Record Data Type” selector.
- UI cleanup (Thanks to my wife for the design) and logic rework of the TagInfo page. It’s now actually kind of useful, and looks SO much better. On a related note, if you scan an NFC tag and get “Unknown Tag” as the type on the top of the page, PM me so I can add fingerprinting logic to the app to take care of it:)
Features included in R1.4 that I haven’t mentioned here yet:
- Complete Encryption/Decryption rework. BioCom now takes full advantage of OpenKeychain’s implementation of the OpenPGP API to encrypt/decrypt all without ever leaving BioCom. This honestly makes a huge difference. If you have a tag with even a remotely large-ish amount of storage available, I recommend you give it a try! It’s definitely the easiest way to keep the data housed on your implants safe from rogue scanners or prying smartphones.
Future Plans:
As I mentioned in a thread somewhere else, my plans for the application’s future includes adding support for reading/writing multiple records on a single tag. I would also love to add VCards as a record data type and maybe even use something similar to the compression logic @anon3825968 used for his vcard script to include images with them. I’d love to reach out to you @anon3825968 when I get ready to include this feature and see if we could reuse some of your logic for this, if you’re down of course.
However, before I attempt the inclusion of any of these features into BioCom, I’m wanting to get the DangerousNFC application at least to the point where it can perform it’s existing functions, just with a refreshed UI and extensibility for future features before I make any additions to this project.
I will actually be making a post in the DangerousNFC 2.0 thread really soon detailing some of the progress I’ve made with it, as well as laying out a rough time frame for when to expect specific progress with the rework.
As a final note, I would still like to get BioCom up on fdroid, but I just have not had the time to look into the process more than enough to be surprised by the fact that in order to upload an app to it, you have to pull request it into their main repo… Kind of odd, but alright. I plan on doing this soon though.
6 Likes
Can confirm - works and looks great! Esp. rework of encryption/decryption.
This is amazing. Works amazing. And is beyond helpful! UI is looking pretty snazzy too 
2 Likes