Dangerous NFC app issues

Ok great… to be clear, you entered an ascii value into dtnfc that you probably don’t want to share here… and you got “transceive failed” on this tag, and now your attempts to use NFC Shell to send 1B pwd-auth command with the hex value to the tag result in time-out. If that’s the case, can you please double double check your hex value for the ascii password you’re sending is correct?

Er… I’ve been sharing the ASCII value I entered into DT NFC since the beginning :slight_smile:

I used “ABCD” (ASCII, uppercase) which translates into 0x41424344. I used that value with all the tags I tried, failed or survivors. The survivors authenticated using that value - until they stopped authenticating, that is.

Specifically, with the tag in this Taginfo dump, I got “transceive failed”. It does not authenticate with 0x41424344 or 0xFFFFFFFF or anything else I’ve tried. Or rather, it times out.

I should also mention, for the sake of completeness, that I did try to use lowercase “abcd” (0x61626364) and variations thereof (“Abcd”) and it didn’t work neither.

Ok… I’m going over this in my head and I’m thinking… no way the password got set… and E1 is not the page we protect via AUTH0… so…

  • here’s the code that does the setting…

image

  • here’s the relevant AUTH0 const;

  • therefore… I believe your tag was already altered… it had a non-standard password set already and AUTH0 set to E1 which is a user memory page that makes no sense for us to ever set that way.

  • hence, your “transcieve failed” makes sense because;

  1. we attempt to set dynamic lock bytes which are in E2 and protected (we have not authenticated)

  2. the write attempt fails auth check (password protected)

  3. your password is never set, nor is the pack, nor do we set our own AUTH0 setting to E2

Conclusion - your tags were pre-fucked.

Yes, the app sets E2. Hence my previous comment:

3 prefucked tags from 2 different sources? Unlikely methinks…

The only thing that might have pre-fucked them is that, maybe I did do a read on them using Tagwriter. Maybe… I don’t quite recall. So if Tagwriter immediately sets shit up behind your back, that’s possible.

Or Android itself. Doubtful.

Any idea what source this particular bullseye came from? … also it’s much more likely than the chip being bad… some vendors do crazy shit to their tags.

You :slight_smile:

Haha fuck. Must be really old then. Try dngr or DNGR as the password. I seem to recall I was an idiot all those years ago… page E1 even rings a bell…

Nope.

But I doubt you’d have set it up: they came on a strip. Why would you set a bullseyes on a strip and not the next one?

Also, the same shit is going on with my KSEC-sourced NTAG-216 (E1 in AUTH0, unresponsive PWD_AUTH…)

Hmm now that is interesting… man wtf. Something did something perverted to these ntags… it wasn’t dnfc but I think dnfc is failing on these because they have been preconfigured somehow. I would be surprised tagwriter would do that from pulling a read… but maybe. What’s your version number of tagwriter? I’ll see if it does crazy shit here.

4.8.2

1 Like

And you’re sure you just did a read with tagwriter? No other fun things?

Tagwriter or Taginfo - if I did it at all. I’m not even sure I did. Probably didn’t actually.

I even specifically stopped Tasker (which handles my NFC automations) before doing the DT NFC app thing, just in case it would interfere somehow.

Ok I’ll throw a bunch of shit at it. In the mean time, what other NFC apps you have?

I have the usual suspects installed (Tagwriter, Taginfo, NFC Shell, MCT, NFC Tool, Tasker) but I never use any of them unless I have to. I’m of the generation that uses cellphones to place phone calls. I never go for a cellphone if I have something to do with a NFC tag normally. I only use Tasker to read UIDs and trigger stuff on a regular basis.

Btw, I just read my last remaining bullseyes and it has FF in AUTH0.

1 Like

I just did a back-of-the-envelope calculation: bruteforcing the password would take 267 days. My PM3 will have melted long before that - it gets really hot after 20 minutes with the field on :slight_smile:

Is there a dictionary of known sneaky apps’ passwords somewhere?

Also, it would be helpful if someone somehow knew of an app that sets E1 in AUTH0. It seems rather specific and uncommon.

1 Like

Can your script shorten the timeout period before attempting another auth?

We could make one… I would assume 0000, 1234, abcd, ABCD (which you’ve tried), etc…

TackMax is Ttimeout, so 5 ms. That’s what I used as a basis for my calculation. TackMin is 9 ns, so that would shorten it to 40 days, without any certainty that it didn’t actually authenticate at some point at the end of it.

Incidentally, I do have another bullseye: my doNExT. I just Taginfo’ed it and it too has FF in AUTH0.

Well yeah, trying those sorts of values is obvious. But I was more thinking of apps that are known to do stuff behind people’s back. I am really not a specialist on the subject. You probably are.

In any case, I can’t run the PM3 at full pelt for more than half an hour: bad shit will happen if I do. It smells funny when I leave the field on for too long. The BT extension doesn’t help it cool down neither…