hf_mfu_magicwrite.lua script trace
hf_mfu_magicwrite.lua.txt (20.4 KB)
What should i try next?
First of all, why do you need NTAG216F (type 13) vs NTAG216 (type 7)? The magic chip does not actually have a field detect pin in hardware. Are you attempting to clone / copy an existing NTAG216F and want to make it as legit as possible?
Regardless, I would try NTAG216 first just to ensure it can be set up correctly. So, I would;
script run hf_mfu_magicwrite -w
script run hf_mfu_magicwrite -t7
script run hf_mfu_magicwrite -u 01020304050607
script run hf_mfu_magicwrite -o E1106D00
script run hf_mfu_magicwrite -v 0004040201001303
Basically the first thing you do is wipe the chip, then set the type which should set up the memory pages correctly for an NTAG216. After that setting the UID, OTP bytes, and version info… that should be enough that when you scan with taginfo on android it should scan properly and return memory contents.
If you are trying to clone a chip and want to set the signature then you will have to read the signature from your source chip and write it with the -s command so it will match/verify properly.
You can verify after by running the read command;
script run hf_mfu_magicwrite -c
Post the results to ensure the tag has been set up properly as NTAG216, then once you are sure you can go about writing to memory pages. The first page of user writable memory is page 04 and each page is 4 bytes long, written 4 bytes or one page at a time.
1 Like
I don’t need F version, NTAG216 is enough.
Wipe was failed.
Btw, the flipper now says that this chip is mifare ultralight 11. Before that there was NTAG216, if I’m not confused.
Ok let’s just try to read with the -c command
ok interesting… so the type was set… what if you now try to set uid, otp, and version;
script run hf_mfu_magicwrite -u 01020304050607
script run hf_mfu_magicwrite -o E1106D00
script run hf_mfu_magicwrite -v 0004040201001303
Feels like some kind of password issue. Can you get a full scan again and try to get to the lower pages like E2?
Also the magic ntag chip is notoriously sensitive to field issues… the chip is not stable overall … one reason we don’t make the flexMN anymore
The last full scan looks the same as the first. How can I try to scan below [83]?
Could this issue be related to the fact that the password was set via the DT NFC app?
Possibly password related… I believe the script has a password parameter option… try adding that and do the wipe and type set again?
Wipe with 00000000 password is success. Next i impersonated NTAG216 and tried to set uid, otp and version.
Writing a tag to the TagWriter now reports that the store failed, but shows 868 bytes available. NFC tools say tag is read-only.
In flipper tag detected as NTAG216.
04-11-22-33-44-55-66_2023-02-09 15-27-09_taginfo_scan.txt (7.9 KB)
04-11-22-33-44-55-66_2023-02-09 15-27-09_taginfo_scan.xml.txt (25.7 KB)
since its not possible to not have a password… the password must always have a value, the question is whether or not its the factory default value or not… i would try setting uid and otp with the password option and use the factory default password of FFFFFFFF (4 bytes all FF)
also the taginfo scan looks correct now… it has all the memory pages and settings look correct… the OTP bytes are not correct though, which carry the NFC capability container (CC) so try to get those set first then try writing.
I edited the script and installed OTP successfully. The result is below. NFC tools are still in read-only mode, and TagWriter writes that store failed.
04-11-22-33-44-55-66_2023-02-10 12-37-44_taginfo_scan.txt (7.9 KB)
04-11-22-33-44-55-66_2023-02-10 12-37-44_taginfo_scan.xml.txt (25.7 KB)
If i try to set uid, otp and version after impersonate, then i got error write error as above.
Pages 04 and 05 look to have some sort of malformed data in them.
At this point you might consider using NFC shell to send raw write commands for those pages and just set them to null (00)
Did I do right? Looks like nothing has changed
A2 04 000000
A2 05 000000
you didn’t put enough bytes 
there are only 3 sets of 00 when there should be 4…
A20400000000
A20500000000
Yeah, I was tried this too, but same result
Are you sure? Did you get back NAK?
Ye
TX: A20400000000
RX: NAK
TX: A20500000000
RX: NAK
TX:
RX: NAK
TX: 3004
RX: 0103A00C340300FE0000000000000000
TX: 3005
RX: 340300FE000000000000000000000000
Hmm… Well shoot. Now I’m confused. It should write