I have no idea hahha… but something intelligent. I honestly thought that a lot of the functions might require multiple scans on a single chip to complete… for example, i wanted to enable a binary editor so you could scan a chip, get a readout similar to how taginfo does it, but then be able to mod blocks manually with either ASCII or hex (depending on where you were typing) and the modded blocks would highlight as changed, and then at the end you could “save” and it would ask you to pop that chip on the reader…
but… the point here is… to do this properly, you’d kinda want some way to indicate “this is the chip we’re talking about right now” and present a menu of options and features that applied to that chip… so almost kind of like a dynamic menu is built when you first scan and analyze your chip…
so like…
then like, you scan and the chip type shows at the top and stays there while we do functions and things on it… and maybe you can tap that and give it a nickname based on the UID cached locally like “left hand xNT” or whatever… if you want… maybe not… but the point is that this will be the chip we’re doing operations on until we back all the way out to “scan your chip” … and if another chip is presented, we can just ignore it… no need for an error, we just ignore it. this saves lots of UI nonsense and error handling for various functions if other tags are presented other than the one we’re wanting to work with. the only down side would be a DESFire chip in private mode which randomizes the UID… so maybe this needs to be thought out some more… but anyways…
maybe after the scan we build a status screen and a data screen and present some buttons based on the status…
So you can see the status area checks the capability container for an NTAG216 which lives in page 03, and checks the static lock bytes to see that it’s locked (we do this because if you fuck up your CC you can’t fix it… page 03 is all OTP bytes)… and it checks that the lock byes are also disabled… checks the auth0 byte to ensure the password function is protecting at least the configuration bytes from pages E2 down… checks to see if the password is factory default or not… and all of these conditions which are red or yellow might prompt buttons to appear at the bottom offering the user a way to fix these issues…
The data section would be the taginfo bit… if you tapped that section to edit the data maybe the buttons on the bottom would change and allow you to save changes or write changed/unchanged data to a new tag of similar memory structure (copy tag contents)… lots and lots of difficulty here for programming case logic… well… maybe not difficulty but tedious … if you know what i mean…
then there’s all the standard stuff like setting passwords to factory default or not… oh and the same thing should apply for password checks… offer the user to enter password data as ascii from the keyboard but also hex… so two fields… side by side… type in one, the other updates… type AmAL in the ASCII field and 41 6D 41 4C pops into the hex field… and vice versa (where possible with ASCII)… it’s stupid to limit the password field to the narrow range of possibilities a mobile keyboard can produce… and let this password be cached for the app session so multiple scans can run the PWDAUTH command where necessary… or maybe offer the option to cache it locally on the phone as an admin setting along with the chip’s other info like nickname…
Of course we will probably also want the ability to chain commands like NFC Shell offers…
Just lots of shit to shove in… you can see why I never got anywhere with it… it’s ambitious to say the least.