Proxmark3 community

Research, development and trades concerning the powerful Proxmark3 device.

Remember; sharing is caring. Bring something back to the community.


"Learn the tools of the trade the hard way." +Fravia

  • Logged in as ikarus
  • Last visit: Today 11:22:42

Announcement

Time changes and with it the technology
Proxmark3 @ discord

Users of this forum, please be aware that information stored on this site is not private.

#1 2021-11-09 19:02:28

biebepc
Contributor
Registered: 2021-11-09
Posts: 2

Dymo LabelWriter 550 Requires Chipped OEM Labels, Need Help

Hi everyone,

Very, very new to the RFID world, so please keep that in mind as you read this.

I recently bought a new Dymo label printer to replace my old 450. Turns out, the new 550 is only compatible with Dymo's expensive OEM labels that have RFID chips in them. They aren't even compatible with the hundreds of dollars' worth of OEM Dymo labels I have from before they introduced the chips last month. This is shockingly anti-consumer and I have had enough. I bought myself a Proxmark 3 Easy that came in yesterday in order to help. Got the client loaded on Windows, and seem good to go in that realm.

When printing, the printer reads how many labels are left on the roll, based upon what the roll chip has to say. Then, the printer lets the roll chip know that it printed 1 label, and the roll chip quantity decreases accordingly. This is definitely stored on the chip, because if you print some labels, then move the roll to a different Dymo printer, it will still have the accurate quantity. Once the counter reaches 0 labels, it won't let you print any more labels using that RFID chipped roll, even if there are actual physical labels left.

My preliminary information came from this reddit post. The chip on the roll is ISO 15693 ICODE SLIX2. In testing (and learning about Proxmark 3 and RFID in general), I noticed that the last the first two of the last line of eight characters on the .eml/.json dump (I did "hf 15 dump") changed to determine how many labels are left. For example, when 103 labels were left, it said "8BFF0001", and when 102 labels were left, it said "8CFF0001". There's obviously some hexadecimal stuff going on here, but I'm starting to see a pattern.

Rather than letting Dymo win, I want to figure out how to trick the printer into thinking it's using OEM labels when it's not. What I'm hoping to do is to rewrite (or just get a new chip, must be flexible and low-profile though) the chip to say it has 999999999 (etc.) labels so it'll never run out, then put the chip in the printer, which will fool the authentication and allow me to use old or third party labels. I hope that makes sense. Other approaches to trick the printer are welcome as well, of course--that was just my first thought. I will need to implement this on dozens of Dymo printers managed by other people, so this fix will preferably be one that is scalable and low-maintenance after the initial hurdle.

Does anyone have any input for a newbie who's in a pickle but eager to learn? What other kind of information will you need from me?

Any help will be truly, enormously appreciated. Thank you for reading this!

Last edited by biebepc (2021-11-09 19:10:56)

Offline

#2 2021-11-11 06:52:26

nock
Contributor
Registered: 2019-12-11
Posts: 15

Re: Dymo LabelWriter 550 Requires Chipped OEM Labels, Need Help

It's very interesting. Good initial research.

Offline

#3 2022-02-19 23:20:49

woolfie
Contributor
Registered: 2022-02-17
Posts: 2

Re: Dymo LabelWriter 550 Requires Chipped OEM Labels, Need Help

I came over here by the same topic. I have big Dymo address labels (36 x 89 mm) and did one print. I red the storage of the ISO 15396 ICODE SLIX2 NFC tag before and after and compared. The only difference was the first byte of the last block (sector 4F) which changed from E3 hex (= 227 dec) with 258 labels left to E4 hex (= 228 dec) with 257 labels left. So after each print the counter byte raises by one.

Maybe also interesting in this context is the fact, that the second byte in the last block differs between FF (biebepc) and FE (me).

The full storage shows like this:

[ 03:0A:82:ED ] Sektor 00 : DATA
[ 86:39:61:D2 ] Sektor 01 : DATA
[ 03:14:1E:32 ] Sektor 02 : DATA
[ B6:CA:00:3C ] Sektor 03 : DATA
[ EA:29:2E:82 ] Sektor 04 : DATA
[ 53:30:37:32 ] Sektor 05 : DATA
[ 32:34:30:30 ] Sektor 06 : DATA
[ 00:00:00:00 ] Sektor 07 : DATA
[ 00:FF:04:01 ] Sektor 08 : DATA
[ 01:00:00:00 ] Sektor 09 : DATA
[ A3:03:1E:00 ] Sektor 0A : DATA
[ 26:00:00:00 ] Sektor 0B : DATA
[ 00:00:0F:00 ] Sektor 0C : DATA
[ 76:03:65:01 ] Sektor 0D : DATA
[ 00:00:00:00 ] Sektor 0E : DATA
[ 85:01:04:01 ] Sektor 0F : DATA
[ 4B:2F:1A:00 ] Sektor 10 : DATA
[ 01:00:00:00 ] Sektor 11 : DATA
[ 00:00:00:00 ] Sektor 12 : DATA
[ 00:00:00:00 ] Sektor 13 : DATA
[ D7:FA:00:1C ] Sektor 14 : DATA
[ 34:BE:C5:62 ] Sektor 15 : DATA
[ 00:30:30:30 ] Sektor 16 : DATA
[ 30:30:30:30 ] Sektor 17 : DATA
[ 30:30:30:00 ] Sektor 18 : DATA
[ 00:00:89:72 ] Sektor 19 : DATA
[ 00:06:00:00 ] Sektor 1A : DATA
[ 00:00:00:00 ] Sektor 1B : DATA
[ 00:00:00:00 ] Sektor 1C : DATA
[ 00:00:00:00 ] Sektor 1D : DATA
[ 32:8C:00:30 ] Sektor 1E : DATA
[ 7E:90:91:8D ] Sektor 1F : DATA
[ 00:00:00:00 ] Sektor 20 : DATA
[ 35:62:8A:19 ] Sektor 21 : DATA
[ 00:00:00:00 ] Sektor 22 : DATA
[ 00:00:00:00 ] Sektor 23 : DATA
[ 00:00:00:00 ] Sektor 24 : DATA
[ 00:00:00:00 ] Sektor 25 : DATA
[ 00:00:00:00 ] Sektor 26 : DATA
[ 00:00:00:00 ] Sektor 27 : DATA
[ 00:00:00:00 ] Sektor 28 : DATA
[ 00:00:00:00 ] Sektor 29 : DATA
[ 00:00:00:00 ] Sektor 2A : DATA
[ 00:00:00:00 ] Sektor 2B : DATA
[ 00:00:00:00 ] Sektor 2C : DATA
[ 00:00:00:00 ] Sektor 2D : DATA
[ 00:00:00:00 ] Sektor 2E : DATA
[ 00:00:00:00 ] Sektor 2F : DATA
[ 00:00:00:00 ] Sektor 30 : DATA
[ 00:00:00:00 ] Sektor 31 : DATA
[ 11:F3:00:2C ] Sektor 32 : DATA
[ DD:C3:3E:91 ] Sektor 33 : DATA
[ 00:00:00:00 ] Sektor 34 : DATA
[ 00:00:00:00 ] Sektor 35 : DATA
[ 00:00:00:00 ] Sektor 36 : DATA
[ 00:00:00:00 ] Sektor 37 : DATA
[ 00:00:00:00 ] Sektor 38 : DATA
[ 00:00:00:00 ] Sektor 39 : DATA
[ 00:00:00:00 ] Sektor 3A : DATA
[ 00:00:00:00 ] Sektor 3B : DATA
[ 00:00:00:00 ] Sektor 3C : DATA
[ 00:00:00:00 ] Sektor 3D : DATA
[ 00:00:00:00 ] Sektor 3E : DATA
[ 00:00:00:00 ] Sektor 3F : DATA
[ 00:00:00:00 ] Sektor 40 : DATA
[ 00:00:00:00 ] Sektor 41 : DATA
[ 00:00:00:00 ] Sektor 42 : DATA
[ 00:00:00:00 ] Sektor 43 : DATA
[ 00:00:00:00 ] Sektor 44 : DATA
[ 00:00:00:00 ] Sektor 45 : DATA
[ 00:00:00:00 ] Sektor 46 : DATA
[ 00:00:00:00 ] Sektor 47 : DATA
[ 00:00:00:00 ] Sektor 48 : DATA
[ 00:00:00:00 ] Sektor 49 : DATA
[ 00:00:00:00 ] Sektor 4A : DATA
[ 00:00:00:00 ] Sektor 4B : DATA
[ 00:00:00:00 ] Sektor 4C : DATA
[ 00:00:00:00 ] Sektor 4D : DATA
[ 00:00:00:00 ] Sektor 4E : DATA
[ E4:FE:00:01 ] Sektor 4F : DATA

The tag info shows the following:

Tag Type: ISO 15693 NXP - ICODE SLIX2
Technology available: NfcV, NdefFormatable
Serial Number: 8 bytes long
DSFID: 0x01
Storage Information: 320 bytes, 80 blocks (with 4 bytes per block)

At this time I sadly don't own any proxmark device to test but it would be interesting if it is possible to make a working copy (clone) of these Dymo NFC tags (especially when the print counter is low ;-) ) or if it is possible to change the counter byte by oneself. What do the experts think?

Best regards,
woolfie

Last edited by woolfie (2022-02-22 00:44:56)

Offline

Quick reply

Write your message and submit

Board footer

Powered by FluxBB