Dymo 550 Thermal Printer DRM Hacking

[EEVblog]

So the new Dymo 550 Turbo and other 500 series models now have DRM via an RFID tag in the roll 

The printer is supposedly identical to the 450 apart from the DRM stuff. And the PC software now does roll ID and label count. So I'd bet the DRM is done in the PC software and that if you spoof the PC into thinking it's a 450 then the software would just print?

[SeanB]

Dymo paper is only good initially, they will quickly devolve to using the cheapest nastiest paper they can get soon enough, because the consumer has no choice any more, use the shyte Dymo sells, or have to change printer ecosystem. You will find many software vendors will not write for any other printers, because Dymo will pay them to write software in that only uses the particular printer.

Soon you will then find that you can only use branded paper for printers as well, and they will not work with other paper other than OEM, yet the exact same paper is sold with different brands on it, and different ID's in the RFID chip, that you will have to put in the printer, which will count off the sheets till it decides the paper is finished.

Incidentally, you can buy labels for under $1 per thousand, which have varying tack levels, and also labels that are designed for removal, or designed for permanence. Just have to buy a Zebra printer instead, which does not care about the label, and does not even care if the label is in the printer, or fed in through the slot in the rear so you can put the roll of 100 000 there and have it churn away 24/7 printing them. Seen them with thousands of kilometres of print on the head, and it is warrantied for a million metres of print.

[EEVblog]

Just have to buy a Zebra printer instead, which does not care about the label, and does not even care if the label is in the printer, or fed in through the slot in the rear so you can put the roll of 100 000 there and have it churn away 24/7 printing them. Seen them with thousands of kilometres of print on the head, and it is warrantied for a million metres of print.

Yeah but that doesn't help people who have already invested in the Dymo ecosystem.

[thm_w]

I don't know about the "450 and 550" are identical part. The 550 claims to be able to read the installed paper type and remaining, the 450 never claims that. So at the very least the 550 should have the additional RFID reading capability. You can see the boards in these photos are totally different (but maybe other models exist):

550: https://fccid.io/RGDLW550/Internal-Photos/Internal-Photos-5092146
450: https://www.ifixit.com/Guide/DYMO+LabelWriter+450+Power+Button+Assembly+Replacement/115376

There may still be a way to use it as a "generic" printer, if the protection is really on the PC side as you say.

This user has re-used the official RFID tag, but, it may run out after a certain amount of prints:
https://www.reddit.com/r/dymo/comments/qhww6m/new_labelwriter_550_turbo_label_hack/

Brady does a similar thing, with the protection is entirely integrated into the printer itself (although the printer is more expensive). They have a sticker with RFID tag deviously glued under it, so if you try to peel the sticker, the RFID IC will separate its connection, and no longer work. They will sell you a "ribbon bypass device" for $30 to get around this..

[EEVblog]

I don't know about the "450 and 550" are identical part. The 550 claims to be able to read the installed paper type and remaining, the 450 never claims that. So at the very least the 550 should have the additional RFID reading capability. You can see the boards in these photos are totally different (but maybe other models exist):

Yes, of course. But they are very likely very compatible from a driver and protocol point of view. The 500 series would just have some extra command capability to send the RFID data back.

[Someone]

Its unlikely to be entirely in the host/driver as some of the devices run standalone, reading the docs about the interface:
https://developers.dymo.com/#/category/1/article/1417

Byte 10
Main bay  status   The status of the main bay.

Type: predefined values
Default value: 0
Range:
0 = bay status unknown
1 = bay open; media presence unknown
2 = no media present
3 = media not inserted properly
4 = media present – media status unknown
5 = media present – empty
6 = media present – critically low
7 = media present – low
8 = media present – ok
9 = media present – jammed
10 = media present – counterfeit media

Byte 28 Byte 27
Label count   Remaining count of inserted consumable
Type: u16 Default value: 0 (empty)

ESC U   Get SKU Information
1B 55

Used to retrieve the inserted LW550 Consumable SKU information from NFC.
The following is the 63-Byte response to ESC U:
[data table]

NFC, possibly writable? given the rich data table from the tag I dont think its simply tracking serial numbers locally.

[EEVblog]

Its unlikely to be entirely in the host/driver as some of the devices run standalone, reading the docs about the interface:
https://developers.dymo.com/#/category/1/article/1417

Byte 10
Main bay  status   The status of the main bay.

Type: predefined values
Default value: 0
Range:
0 = bay status unknown
1 = bay open; media presence unknown
2 = no media present
3 = media not inserted properly
4 = media present – media status unknown
5 = media present – empty
6 = media present – critically low
7 = media present – low
8 = media present – ok
9 = media present – jammed
10 = media present – counterfeit media

Byte 28 Byte 27
Label count   Remaining count of inserted consumable
Type: u16 Default value: 0 (empty)

ESC U   Get SKU Information
1B 55

Used to retrieve the inserted LW550 Consumable SKU information from NFC.
The following is the 63-Byte response to ESC U:
[data table]

NFC, possibly writable? given the rich data table from the tag I dont think its simply tracking serial numbers locally.

Yes, seems like it's doing a bunch of stuff locally. Might be impossible to bypass the firmware via just the PC drivers.
If each roll isn't individually serial numbered, and it doesn't keep track of those, then I can't see why you can't just remove a genuine tag and just tape it inside the lid?

[mikeselectricstuff]

Yes, seems like it's doing a bunch of stuff locally. Might be impossible to bypass the firmware via just the PC drivers.
If each roll isn't individually serial numbered, and it doesn't keep track of those, then I can't see why you can't just remove a genuine tag and just tape it inside the lid?

Because the label holds a "labels used" value.
One  avenue for attack might be to prevent it rewriting this value, so genuine tags last forever

[mikeselectricstuff]

Looks like all the RFID stuff is on a seperate PCB, so an approach may be to replace that board  with something that always gives the "right" answers

[NiHaoMike]

Or just replace the whole control board with an open source replacement based on Arduino?

[wraper]

Or just replace the whole control board with an open source replacement based on Arduino?

Be the one who reverse engineers the original board, and designs a new board, writes a firmware needed. FYI you cannot simply stick Arduino instead of a custom board .

[EEVblog]

Looks like all the RFID stuff is on a seperate PCB, so an approach may be to replace that board  with something that always gives the "right" answers

Are there teardown photos?

[thm_w]

Are there teardown photos?

I posted the links above.

[mikeselectricstuff]

Looks like an NXP RFID chip - can't quite make out the number.
SPI interface judging by the number of wires.

[thm_w]

Yeah good eye, NXP, which lead me to their product selection: https://www.nxp.com/products/product-selector:PRODUCT-SELECTOR#/category/c817_c798_c1491/ (wont link but filter QFN32)

61833 something?, anyway they all have various encryption options: "NTAG, NTAG5, ICODE, DESFire, MIFARE frontend"

[EEVblog]

Yeah good eye, NXP, which lead me to their product selection: https://www.nxp.com/products/product-selector:PRODUCT-SELECTOR#/category/c817_c798_c1491/ (wont link but filter QFN32)

61833 something?, anyway they all have various encryption options: "NTAG, NTAG5, ICODE, DESFire, MIFARE frontend"

I doubt the SPI is encrypted. Likely possible to spoof it.
I doubt Dymo would have cared that much about physical hardware attacks, just the cloners making fake tags.

[amyk]

I haven't looked into this in much detail but suspect it isn't too different from the inkjet/toner cartridges with chips, except now they're wireless. It might be a simple matter of capturing the communication to figure out what it's using for commands to read/write the chip. From there, resetters and such should become quite doable.

...that is, unless they've somehow gone for the "deluxe" route and crypto'd everything.

Related long-running thread for a slightly different product: https://www.eevblog.com/forum/projects/lexmark-toner-chip-ti046b1/

[thm_w]

More details here, confirmed NFC transmitter IC is CLRC663:
https://old.reddit.com/r/dymo/comments/t153zc/any_hardware_hackers_want_to_help_dymo_550/
https://old.reddit.com/r/dymo/comments/qhww6m/new_labelwriter_550_turbo_label_hack/
https://imgur.com/a/BjO55ss

semireg7 days ago[-]
It’s worse than anyone thinks.

If you look closely at the official DYMO labels sold in recent years the packaging has changed color. The color was DYMO seeding the RFID stock into the market. Once saturated they launched the 550 with RFID.

The chip inside each roll is a special NFC that identifies the label dimensions and remaining label count. The NFC comes pre-loaded with 0xFFFF-Count in a special register that increments when hit with a non-password protected NFC command emitted by the printer when any label is ejected. So even if you don’t print, you just eject, the labels are depleted. There seems to be a buffer at the end for this kind of “rewind” process or user error … but it’s limited. A roll of 50 labels might have a counter that can be hit 60 times. The command to reset this counter is password protected.

Here is the reported NFC IC:
https://www.nxp.com/docs/en/data-sheet/SL2S2602.pdf?pspll=1

Its basic password protection, so they didn't want to spend the money on encrypted tags.

[–]Various_Contact_5672 3 points 3 days ago
The password is written plaintext to the controller IC.

I'm waiting on stock, but will be releasing a hack after I'm able to get my hands on one.

[amyk]

How hard is it to emulate an NFC IC with an MCU? That would be my first idea of making a "self-resetting" tag, but 13.56MHz doesn't sound easy to bitbang...

[mikeselectricstuff]

How hard is it to emulate an NFC IC with an MCU? That would be my first idea of making a "self-resetting" tag, but 13.56MHz doesn't sound easy to bitbang...

You wouldn't need to bitbang at that frequency - that's the carrier. The actual data rate would be significantly lower.
 

[js_12345678_55AA]

Should I .... 

I think the read password (required to increase the counter of the tag) is 0x179AADEF 

The write password (required to reset/set the counter) is most likely NOT part of the dymo firmware since it is required in factory only.

Looking at the very "well" choosen read password I guess it might be something like "0x2348BCEF"


The NFC pcb is connect via I2C (address 0x28) (red wire is SCL, wire next to it is SDA, other pins are GND,IRQ,???,3V3)

=> A simple "proxy" (maybe a 3 cent padauk ) on the I2C bus could filter the counter increment and report an increased counter. When a "new" tag is detected it could reset itself and adapt to current tag counter (so when counter reached maximum, just remove and reinsert roll and continue printing. The tag from an original roll could be removed and attache to the spool holder).


=> BTW: Something I could not find in the manual of the SLIX2 tag is: "what happens if the 16 bit counter is at 0xFFFF and you send another increment?" In case it wraps around then we are golden.


JS

[SilverSolder]

So the new Dymo 550 Turbo and other 500 series models now have DRM via an RFID tag in the roll 

The printer is supposedly identical to the 450 apart from the DRM stuff. And the PC software now does roll ID and label count. So I'd bet the DRM is done in the PC software and that if you spoof the PC into thinking it's a 450 then the software would just print?

Amazon star ratings are no longer just an average of actual customer reviews...   they are modified in some way, "for your benefit" of course.  I think this changed last year, or the year before.

So, you can't trust that those star ratings actually reflects what consumers think...

[amyk]

=> BTW: Something I could not find in the manual of the SLIX2 tag is: "what happens if the 16 bit counter is at 0xFFFF and you send another increment?" In case it wraps around then we are golden.

There is an ominous "destroy" command... who wants to bet that's what gets written by the device at some point?

I also noticed the datasheet says the data on the ICs are digitally signed too; this stuff is getting really creepy.

[EEVblog]

NFC dump from the (pitiful) label roll included with the 550

** TagInfo scan (version 4.25.3) 2022-03-07 14:51:52 **
Report Type: -- IC INFO ------------------------------

# IC manufacturer:
NXP Semiconductors

# IC type:
ICODE SLIX2 (SL2S2602)

# Application type:
Identification

-- NDEF ------------------------------

# No NDEF data storage populated:

-- EXTRA ------------------------------

# Memory size:
320 bytes
* 80 blocks, with 4 bytes per block

# IC information:
Supported read commands:
* Single Block Read
* Multiple Block Read
* Inventory Read
* Fast Inventory Read
* Get System Information
* Get NXP System Information
* Read Signature
AFI supported
DSFID supported
IC reference value: 0x01
Capacitance: 23.5 pF

# NXP system information:
Password protection configuration:
* Block addresses < 0x32: write protected
* Block addresses ≥ 0x32: no access control
Lock status:
* AFI value: locked
* DSFID value: locked
* EAS status: locked
* Password protection configuration: locked
Supported features:
* User memory password protection
* Counter block
* EAS ID
* EAS password protection
* AFI password protection
* Extended mode for Inventory Page Read
* EAS selection in extended mode for Inventory Page Read
* Originality signature
* Persistent quiet state
* Privacy mode
* Destroy command

# Originality Check (asymmetric):
Signature cannot be verified

# TagInfo Version:
Version :4.25.3

# Device Info:
Device Model :HUAWEI ( HMA-L29 )
Android OS Version :10

-- FULL SCAN ------------------------------

# Technologies supported:
ISO/IEC 15693-3 compatible
ISO/IEC 15693-2 compatible

# Android technology information:
Tag description:
* TAG: Tech [android.nfc.tech.NfcV, android.nfc.tech.NdefFormatable]
* Maximum transceive length: 253 bytes


# Detailed protocol information:
ID: E0:04:01:08:3A:72:3E:E2
AFI: 0x3D
DSFID: 0x01

# Memory content:
[00] .r= 03 0A 82 ED |....|
[01] .r= 86 39 61 D2 |.9a.|
[02] .r= 03 14 1E 32 |...2|
[03] .r= B6 CA 00 3C |...<|
[04] .r= 36 42 0C 33 |6B.3|
[05] .r= 53 30 37 32 |S072|
[06] .r= 32 34 30 30 |2400|
[07] .r= 00 00 00 00 |....|
[08] .r= 00 FF 04 01 |....|
[09] .r= 01 00 00 00 |....|
[0A] .r= A3 03 1E 00 |....|
[0B] .r= 26 00 00 00 |&...|
[0C] .r= 00 00 0F 00 |....|
[0D] .r= 76 03 65 01 |v.e.|
[0E] .r= 00 00 00 00 |....|
[0F] .r= 85 01 34 00 |..4.|
[10] .r= 75 09 05 00 |u...|
[11] .r= 01 00 00 00 |....|
[12] .r= 00 00 00 00 |....|
[13] .r= 00 00 00 00 |....|
[14] .r= D7 FA 00 1C |....|
[15] .r= F5 6F 95 96 |.o..|
[16] .r= 00 30 30 30 |.000|
[17] .r= 30 30 30 30 |0000|
[18] .r= 30 30 30 00 |000.|
[19] .r= 00 00 49 08 |..I.|
[1A] .r= 57 06 00 00 |W...|
[1B] .r= 00 00 00 00 |....|
[1C] .r= 00 00 00 00 |....|
[1D] .r= 00 00 00 00 |....|
[1E] .r= 32 8C 00 30 |2..0|
[1F] .r= -- -- -- --
[20] .r= 00 00 00 00 |....|
[21] .r= D7 DC 0F 25 |...%|
[22] .r= 00 00 00 00 |....|
[23] .r= 00 00 00 00 |....|
[24] .r= 00 00 00 00 |....|
[25] .r= 00 00 00 00 |....|
[26] .r= 00 00 00 00 |....|
[27] .r= 00 00 00 00 |....|
[28] .r= 00 00 00 00 |....|
[29] .r= 00 00 00 00 |....|
[2A] .r= 00 00 00 00 |....|
[2B] .r= 00 00 00 00 |....|
[2C] .r= 00 00 00 00 |....|
[2D] .r= 00 00 00 00 |....|
[2E] .r= 00 00 00 00 |....|
[2F] .r= 00 00 00 00 |....|
[30] .r= 00 00 00 00 |....|
[31] .r= 00 00 00 00 |....|
[32] .rw 11 F3 00 2C |...,|
[33] .rw DD C3 3E 91 |..>.|
[34] .rw 00 00 00 00 |....|
[35] .rw 00 00 00 00 |....|
[36] .rw 00 00 00 00 |....|
[37] .rw 00 00 00 00 |....|
[38] .rw 00 00 00 00 |....|
[39] .rw 00 00 00 00 |....|
[3A] .rw 00 00 00 00 |....|
[3B] .rw 00 00 00 00 |....|
[3C] .rw 00 00 00 00 |....|
[3D] .rw 00 00 00 00 |....|
[3E] .rw 00 00 00 00 |....|
[3F] .rw 00 00 00 00 |....|
[40] .rw 00 00 00 00 |....|
[41] .rw 00 00 00 00 |....|
[42] .rw 00 00 00 00 |....|
[43] .rw 00 00 00 00 |....|
[44] .rw 00 00 00 00 |....|
[45] .rw 00 00 00 00 |....|
[46] .rw 00 00 00 00 |....|
[47] .rw 00 00 00 00 |....|
[48] .rw 00 00 00 00 |....|
[49] .rw 00 00 00 00 |....|
[4A] .rw 00 00 00 00 |....|
[4B] .rw 00 00 00 00 |....|
[4C] .rw 00 00 00 00 |....|
[4D] .rw 00 00 00 00 |....|
[4E] .rw 00 00 00 00 |....|
[4F] .rw C6 FF 00 01 (C0-C1 value: 50943, PROT)

  r:readable, w:writeable, -/=:password protected,
.:unlocked, x:locked

--------------------------------------

[EEVblog]

Confirmed, the value gets written to the C0 and C1 protected bits in the RFID tag when the label is printed or a blank label advanced which is what I just tried.
When I advnaced the label by one (not having printed anything)  the C0 value changed from C6h to C7h at the end of memory.

So there is no doubt that if you try and simply peel off the label and reuse it, that won't work. As it will presumably count down to zero and won't let you use it any more.