[INFO] Some info on cloning these stickers

[IAmOrion]

'bamzero' directed me here from Discord after finding an old post of mine (maybe from reddit) regarding niimbot printers and their label tags.

I uploaded 2 of them here: https://github.com/IAmOrion/FlipperZeroStuff/tree/main/nfc
and have another to add when I get around to it.

Now, I think the signature is the key and the hurdle here. When I was cloning the NFC tags using all sorts of magic tags / magic chines tags / magic nfc / magic cuid --- whatever name they're known to you by - I could changed everything including the UID EXCEPT the signature. I tried a few PM3 scripts and despite the scripts saying complete, the tag signature had actually NOT changed.

The signature on the niimbot labels is the UID repeated 3 or 4 times (it's been a while, so I forget)

I think, possibly, IF the signature could be forced, then a clone tag would work - I've just not yet been able to manipulate the signature of even the magic nfc tags

[bamzero]

Searched the RFID Hacking discord and the only results for Niimbot were from you ;)

Anyway, as far as these tags go like I mentioned on Discord have managed to write working tags however I think in the long run it's going to be pointless. Have since discovered that the rolls are serialised and they are keeping track on their servers. The software is pretty reliant on connecting to their servers for label sizes and template layouts etc so blocking connection outright probably isn't going to work either.

For example, https://print.niimbot.com/api/rfid/getRfid/v2?serialNumbers[]=881d08abb28a0000
materialUsed increments regardless whether using an old copy of the tag and I suspect once it hits the allowedNum (seems they allow 20% overhead on the number of labels) that tag is going to become useless.

Also a fair bit of analytics, might want to block niimbot-pro.cn-hangzhou.log.aliyuncs.com

I'll probably end up getting rid of the Niimbot and get another brand of printer that doesn't cripple the output instead.

[bamzero]

Actually not as bad as I first thought. The serial number they are tracking is just the UID of the tag, so when you write a new tag and have a new UID it logs as a new roll.

---

Nope, scratch that. While the serial is the UID, it's encoded in the data. Testing with a newly written tag it's still reporting the serial number/UID of the original tag. Replacing the serial number in the URL with the new one from my tag doesn't return any data.

[enzosimon1987]

Hello.
A little information about how I cloned the tag onto regular NTAG 213 144bytes. I used PROXMARK3. I did a little research on the communication between the printer and the original NTAG tag. As I found out, it is not necessary to use the original UID. The main thing is the key in lines 43 and 44.
First I wrote the dump into a tag:
hf mfu restore -f TAG.bin -k FFFFFFFF
Rewrote the lines:
hf mfu wrbl -b 43 -d 12345678 -k FFFFFFFF
hf mfu wrbl -b 44 -d 55550000 -k 12345678 (I use the changed key).
The printer now accepts the tag.
I have various tagless labels for which I want to make RFID tags. Now I have few dumps of original coils. It would be great to collect different dumps and compare them. For example, through the android program mifare++.
Now we need to understand the structure of dumps. But lines 5 and 6 are the number of stickers printed. And these lines can be changed.

[bamzero]

Yeh, as I mentioned above was able to write working keys but unless we can decode the data structure I don't think it will be a long term solution. Really the printers need some firmware hacking to modify it at the source rather than trying to mess with NFC tags, but given how tied these things are to online servers I'm not sure how much functionality would be affected anyway.

#5 does hold the number used but changing doesn't affect the value recorded by niimbot on their servers, and while the UID is used as the serial number it is encoded in the data and not used directly when logging so a copied tag still has the serial number of the original and the usage count on their server increases no matter what you set #5 to.

I haven't tested what happens once the usage count exceeds the max value for the roll though, but given how anal niimbot is with everything else I wouldn't be surprised if it refused to print or at the very least nags you on every print.

In the end I gave up on niimbot and sold my printer. Nice unit but too restrictive on consumables (and way too much activity logging)

[derBroBro]

I also tried my luck.
Interestingly, as described by @enzosimon1987 , it seems like page 5+6 are the only touched ones after pringing some labels. So the state should persisted there.
Unfortunlaty I could also not figure out how this is encoded (xor + bit-shifting did not help).

Also intressting: If I emulate an older version of the same tag, the printer still detects the latest (higher) number of printed labels. Expectation was that it reads the lower number from the label.
As I used https://github.com/MultiMote/niimblue I dont think this was fetched from the internet.
Only way I could imagine is that the printer persists the state in an internal memory...

[MultiMote]

Only way I could imagine is that the printer persists the state in an internal memory...

@derBroBro Seems like it's true. See my comment here: AndBondStyle/niimprint#34 (comment)

As I used https://github.com/MultiMote/niimblue I dont think this was fetched from the internet

Yea, it send requests to external API (Labelary) only when importing ZPL labels.

[derBroBro]

Another note here, for me changing line 5+6 on indivdual bytes cause the labels not to be readable anymore. The same for any other bytes in the data.
For me this means it is not just an kind of flat encoding (XOR, Bitshifting) or similar as this would result in slightly change UID etc. so it seems there is more going on.

Another test was to write the data to another label. As I had just a NTAG217, I used this and suprisingly it worked. In addition the print count does not go up. Assumption would be that the printer can read but has some kind of an issue on writing NTAG217.