This Project created from split thread, to reinvigorate DangerousNFC 2.0
Absolutely. I’d love to make some of these more device specific features more accessible. Let’s do it.
5 Likes
4 Likes
what’s your github username?
iotarex
2 Likes
I wanna help in some way. Maybe even for iOS?
5 Likes
ok I’m getting a bunch of blank ntag i2c chips that have not been pre-formatted by our manufacturing process… i am going to do a bunch of tests and push the info here… should be a couple weeks for delivery etc. but the main thing is figuring out what the hell TagWriter is getting so wrong, and why it’s borking the transition from sector 0 to sector 1.
2 Likes
Sounds good. I’ll dig through the existing DangerousNFC application this week and get an idea of the flow. I’m curious to see what you find digging through those tags.
3 Likes
you can see we had some big ideas that never got anywhere… the xposed framework stuff was one of those ideas… but really we just need an app to properly support all the DT products. I would eventually like to also merge in MCT for brute forcing mifare keys and writing to magic mifare gen2 chips but with a way way better user interface… and also a smarter approach to writing to the UID sector 0… the crappy MCT tool writes sector 0 first which changes the UID and breaks the ISO14443A session with the chip, so you have to write twice… so dumb. Anyway… progress!
5 Likes
Nice! It’ll be fun to revive the old project. I looked through it a little yesterday, and I’ll have a bunch more time this weekend to finish looking through things.
Sounds awesome to add in bruteforcing! Let’s fill this thing up with a bunch of specific features like that. Maybe even some DesFire specific stuff, I haven’t had the chance to mess around with all the bells and whistles of those little things.
Do you have ideas over how you’d like the interface to be laid out for DangerousNFC 2.0?
Bruteforcing might not pass for the play store.
1 Like
Lol, fair point. Maybe we’ll call it something else and hope they don’t know enough about it to flag it:P
Since it’s open source, why not just put it on f-droid? Should be no problem there, and I’d rather prefer it anyways… touching the play store only with a ten-foot-stick…
1 Like
I believe the topic is shifting from OP
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.
3 Likes
I’ve had the same idea for a while now! I wanted to have a raw byte editor with real time “translated” values in a split-screen type layout. I don’t think it would be too hard to do. I actually planned on having that very thing as a separate fragment off of the TagInfo activity of BioCom.
I like your idea about having a local database for “cached” previously scanned implants. Maybe we can have a simple set of “tests” formatted through something like an interface that will let us verify that the chip we are altering is the one selected, so we could have special test cases for chips like the DesFire family. I’ve got a lot of experience with a local database system for mobile apps that I think would be perfect for this type of approach.
I understand that completely. I feel like the specific and narrowed down nature of these devices makes it particularly difficult to program dynamically for them, given that some tags respond to certain commands while others don’t, etc. as well as the fact that they can be difficult to even identify programatically in the first place
I’d like to put together some Adobe XD mockup’s of what I’ve kind of got in my head based on what you said here soon.
4 Likes
I’ve been tinkering with Figma… a very capable mock-up platform and so far, free for what I use it for… does interactions, menus, drop downs, etc. all almost like a live app… anyway i’ve not seen XD but looking forward to the mocks!
3 Likes