NeXT - GoToTags & TagWriter

Good afternoon,
I’m testin my first implant NeXT using GoToTags in PC with a NFC reader (ACR122) and TagWriter in mobile and have a lot of doubts.
I can read and write the NeXT with TagWriter but with GoToTags only can read, it show the message “NFC is read-only”. This is with a plain text or web site. How I can change the read-only?
Other test is writting my WiFi with TagWriter. In this case reading with GoToTags it show the message “Unable to parse the NDEF message” Is it normal?
With NFTag, if I have my WiFi in NeXT and I want to add plain text, when writing I save the new and the previous content is lost. How can write several things?
Thank you very much!!!

Hello! Let me explain… basically the NTAG216 has lock bytes in certain memory pages called “configuration bytes”. Each bit of the lock bytes is set to 0 by default, and if changed to a 1, will lock specific memory pages in user memory. Therefore, flipping specific bits in the lock bytes will lock different memory pages. These bits are OTP or one-time-programmable, meaning once the bit is changed from 0 (memory page not locked) to 1 (memory page locked), the bit cannot be changed back to 0. This means that if you lock any user memory pages by flipping the corresponding responsible bit from 0 to 1, that user memory page is forever locked as read-only.

Because of this, we disable the lock bytes so you can never accidentally forever lock the user memory of your NExT. Each of the lock bytes contain a specific bit which will lock the specific memory page that contains the lock bytes themselves, so by flipping that one bit to lock the memory page that the lock bytes reside in, we are effectively locking the lock bytes so the remaining bits can never be changed from 0 to 1. Make sense?

Now, you can search this forum for “programmers are lazy” (and you should) to see my complaints with laziness when it comes to doing things the right way vs being a lazy asshole. Sadly, GoToTags programmers are lazy. Basically what’s happening is, they read the memory pages containing the lock bytes, see that some of the bits have been flipped from 0 to 1, and throw up their hands with the error “TAG IS LOCKED!” … when the correct and right thing to do is to parse those lock bits to discover WHICH memory pages are locked, and THEN see if it is still possible to write the NDEF data you want to write to user memory pages that are not locked… but they aren’t doing that… they are being lazy assholes.

The issue with the NDEF message not being parsable has to do with TagWriter and their programmer laziness coupled with Android’s programmer laziness (go team!). Basically Android OS offers a library to handle NDEF data writing to the tag. See, tags come in a variety of memory configurations, page lengths, minimum write lengths, and NDEF data starting addresses… so… rather than every single app needing do to its own work to sort all that out AND ALSO do the work of splitting up the NDEF message so it can be written across a number of different memory pages and blocks for that tag (which may be different for another type of tag), apps just happily hand that off to Android to do. Unfortunately the Android library looks at the tag for an existing NDEF message and basically uses that as a tag structure detection mechanism rather than try to figure it all out from scratch. What it doesn’t handle well at all is broken NDEF messages… it just gives up… so, if your NDEF data is corrupted or incomplete or otherwise not up to spec, you will see this error.

Luckily it’s easy to fix… just use TagWriter to “erase” the tag… if that fails try to “format” the tag… if that fails use the Dangerous Things Support Tool and write a blank NDEF record to it.


I’ll add this to Amal’s long and detailed explanation: stay clear the hell away from GoToTags if you use it to program a Mifare Classic, because it sets its own key and you won’t be able to write to it again with any other application afterwards - unless it’s a magic M1k gen1a of course.

That stupid program caused me no ends of headaches because of that.

Security on the 1k is completely cracked at least so given enough time you should be able to determine the the key. I think there’s even a link to the modified version of Mifare Classic Tool for Android that does the crack auto-magically on the forum somewhere.

Yeah, but have you tried to hold your hand in front of a Proxmark3 for 20 minutes without moving, waiting for it to recover the key? GoToTags is a fucking nuisance.

whaaa? no way… update your proxmark3 to the RRG fork (iceman) and use autopwn … keys typically nabbed in less than a minute.

1 Like

That’s what I run. But yeah I didn’t try autopwn.

Having said that, one of my magic M1ks (the one from IAmRobot) typically takes seconds, while the other literally takes 20 minutes. Dunno why. I have a bunch of magic M1k cards from Lab401 that take forever too. I guess not all magic Chinese chips are the same. Of course, I was doing tests, I didn’t use the magic command, which is just easier.

Could be whether it is ‘weak’ or ‘hardened’

If i recall correctly from when i looked into this, when the nested attack (which is really fast) came out, NXP revised the chips to ‘harden’ their security. It got broken quickly i believe, and the hard nested attack came out. No more secure, but takes more time.

An improvement in the Pseudo Random Number Generator i believe