Dymo 550 Thermal Printer DRM Hacking

[js_12345678_55AA]

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.

I already wrote about that (see above).

The tag gets a COUNTER INCREMENT whenever a tag feed is issued. The tag increment command needs the READ-Password to be set (which is 0x179AADEF !!!FOR MY TAG!!!, looks like they read the application note to derive passwords from UID).

Meanwhile I read all the spec and have some more insights:

- the SLIX2 tags used from DYMO do NOT have the NXP factory "Originality Signature" embedded, instead a CUSTOM signature from DYMO is used.
(the signature is just signing the UID of the tag, it is static for every UID. Spoofing of tags is still possible, one just needs to read UID + SIGNATURE from a valid dymo tag)

- it is UNLIKELY that they track used UIDs in firmware of the STM32 main MCU. If they would, there is no reason to implement the counter inside of the tag...

- "magic SLIX" tags do exist (where you can set UID yourself), however magic "SLIX2 tags" are not available YET... for sure they will come soon (Toniebox, Dymo, variuos ticketing systems, ... all use SLIX2)
(in a magic SLIX2 tag you just need to set the UID + SIGNATURE (taken from original tag))

- spoofing the complete RFID reader PCB (simple I2C) seems to be a trivial task. In reality only a handful of commands are used which are sent to the tag:

Code: [Select]

w: 0x36 0x01 0x00 0x00  (INVENTORY)
r: (0x00) 0x01 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 (=> DSFID + UID)

w: 0x22 0x23 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x00 0x03  (READ MULTIPLE BLOCKS: BLOCK = 0x00, LEN = 0x3 BLOCKS +1)
r: (0x00) 0x03 0x0A 0x82 0xED 0x86 0x39 0x61 0xD2 0x03 0x14 0x1E 0x32 0xB6 0xCA 0x00 0x3C

w: 0x22 0xBD 0x04 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0  (READ SIGNATURE)
r: (0x00) 0x33 0x4A 0x63 0x63 0xD0 0x13 0x49 0xDB 0xA0 0x9E 0xEE 0x15 0x1E 0xF8 0xF8 0xF3 0xFA 0x15 0xF5 0x77 0xE4 0x4D 0x75 0x9B 0x78 0x14 0xCA 0xD3 0x7E 0x02 0xEF 0x10

w: 0x22 0x2B 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 (GET SYSTEM INFO)
r: (0x00) 0x0F 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x01 0x3D 0x4F 0x03 0x01

w: 0x22 0x23 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x00 0x03  (READ MULTIPLE BLOCKS: BLOCK = 0x00, LEN = 0x3 BLOCKS +1)
r: (0x00) 0x03 0x0A 0x82 0xED 0x86 0x39 0x61 0xD2 0x03 0x14 0x1E 0x32 0xB6 0xCA 0x00 0x3C

w: 0x22 0x23 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x03 0x0F  (READ MULTIPLE BLOCKS: BLOCK = 0x03, LEN = 0xF BLOCKS +1)
r: (0x00) 0xB6 0xCA 0x00 0x3C 0x36 0x42 0x0C 0x33 0x53 0x30 0x37 0x32 0x32 0x34 0x30 0x30 0x00 0x00 0x00 0x00 0x00 0xFF 0x04 0x01 0x01 0x00 0x00 0x00 0xA3 0x03 0x1E 0x00 0x26 0x00 0x00 0x00 0x00 0x00 0x0F 0x00 0x76 0x03 0x65 0x01 0x00 0x00 0x00 0x00 0x85 0x01 0x34 0x00 0x75 0x09 0x05 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00

w: 0x22 0x23 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x14 0x07  (READ MULTIPLE BLOCKS: BLOCK = 0x14, LEN = 0x7 BLOCKS +1)
r: (0x00) 0xD7 0xFA 0x00 0x1C 0x14 0xC2 0x5D 0xBC 0x00 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x00 0x00 0x00 0x3D 0x3C 0xEA 0x07 0x00 0x00 0x00 0x00 0x00 0x00

w: 0x22 0x23 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x1E 0x0C  (READ MULTIPLE BLOCKS: BLOCK = 0x1E, LEN = 0xC BLOCKS +1)
r: (0x00) 0x32 0x8C 0x00 0x30 0x3E 0x50 0xEC 0x31 0x00 0x00 0x00 0x00 0x2D 0x07 0xA6 0x12 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

w: 0x22 0x23 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x32 0x0B  (READ MULTIPLE BLOCKS: BLOCK = 0x32, LEN = 0xB BLOCKS +1)
r: (0x00) 0x11 0xF3 0x00 0x2C 0xDD 0xC3 0x3E 0x91 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

w: 0x22 0xB2 0x04 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 (GET RANDOM NUMBER)
r: (0x00) 0xEF 0x30 (=0x30EF)

w: 0x22 0xB3 0x04 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x01 0x00 0x9D 0x75 0x27 (SET PASSWORD: READ_PASS)
r: (0x00)

w: 0x22 0x23 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x4F 0x01  (READ MULTIPLE BLOCKS: BLOCK = 0x4F (79), LEN = 0x1 BLOCKS +1)
r: (0x00) 0xC7 0xFF 0x00 0x01

w: 0x22 0x26 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 (RESET TO READY)
r: (0x00)

w: 0x22 0x26 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 (RESET TO READY)
r: (0x00)

...

w: 0x22 0x26 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 (RESET TO READY)
r: (0x00)

w: 0x22 0xB2 0x04 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 (GET RANDOM NUMBER)
r: (0x00) 0xB7 0x38 (=0x38B7)

w: 0x22 0xB3 0x04 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x01 0x58 0x95 0x2D 0x2F (SET PASSWORD: READ_PASS)
r: (0x00)

w: 0x22 0x21 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x4F 0x01 0x00 0x00 0x00 (WRITE BLOCK: BLOCK=0x4F (79), DATA = 0x01 0x00 0x00 0x00 (increment counter))
r: (0x00)

w: 0x22 0x23 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 0x4F 0x01  (READ MULTIPLE BLOCKS: BLOCK = 79, LEN = 0x1 BLOCKS +1)
r: (0x00) 0xC8 0xFF 0x00 0x01

w: 0x22 0x26 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 (RESET TO READY)
r: (0x00)

w: 0x22 0x26 0xBA 0x6C 0x60 0x3D 0x08 0x01 0x04 0xE0 (RESET TO READY)
r: (0x00)

...                     
                     

The "increment counter" is checked immediately after the increment. But nothing else is there or even available to prevent spoofing of ORIGINAL tags.

It is also very unlikely that DYMO ever implements a "blacklist" (theoretically they could, especially in combination with the host pc reading the UID and an online connection), BUT since one can read the tags within the original box in the shop (without purchasing them) this would put DYMO at risk reporting original material as bad just because somebody did a readout of the box before it was pruchased...

The complete "solution" from DYMO is based on the WRONG SECURITY SCHEME.
ICODE SLIX2 is just the wrong tag. ICODE DNA would have been the correct choice... But for sure they needed to save money 


Open questions:

* what happens when the counter is 0xFFFF and it is incremented? (in case it wraps around... if counter is <0xFFFF then you can print)

* can we "find" the write password by guessing (in case it could be found... the counter could be written to any value, the datasheet does not mention a lock after several wrong tries, just a reset of the tag is enough)


JS


References:

https://www.nxp.com/docs/en/data-sheet/SL2S2602.pdf

https://www.nxp.com/docs/en/application-note/AN12366.pdf

  3.5 Reprogrammable originality signature
  NXP offers to either lock the pre-programmed NXP originality signature, or to allow
  customers to re-programm and lock the originality signature.
  Following steps for Originality Signature generating and reprogramming are
  recommended:
  1. Generate a public and private key for the parameters secp128r1
  2. Create and Sign Originality Signature with private key
  3. Verify the Originality Signature with public key
  4. Program the Originality Signature into IC memory
  5. Lock the Originality Signature
 
High res picture of annotated mainboard of DYMO550:

[amyk]

BUT since one can read the tags within the original box in the shop (without purchasing them) this would put DYMO at risk reporting original material as bad just because somebody did a readout of the box before it was pruchased...

Or write the tags too...and that ominous command starting with "D" suddenly becomes even more interesting.

[EEVblog]

FYI, I get nothing out of the UART header regardless of what I do with the boot or reset buttons.
Reset button works and turns off the printer (into standby), but pressing or holding boot under various scenarios does nothing.

[js_12345678_55AA]

FYI, I get nothing out of the UART header regardless of what I do with the boot or reset buttons.
Reset button works and turns off the printer (into standby), but pressing or holding boot under various scenarios does nothing.

This is "normal" ... since the STM32F072 is in RDP Level 2 (Readout Protection Level2 = all debug interfaces disabled, bootloader will not start).

JS

Here a pointer to "attack" STM32F0 RDP protection. Looks like level2 only can be attacked via decapping and selective UV light.
https://www.aisec.fraunhofer.de/en/FirmwareProtection.html

[EEVblog]

Photos of the 550

Dymo 550 LabelWriter Label Printer PCB by Dave Jones, on Flickr

[EEVblog]

[js_12345678_55AA]

Great video.

I will continue to create a simple tag emulator which plugs in to the I2C interface.

The good part: The printer will accept the standard non dymo rolls I use and I will have a nice NFC I2C adapter for other projects

JS

[mikeselectricstuff]

If it uses the RFID to identify the label type, presumably there is no way to manually tell it the label size in the software.
So presumably an emulator would need a way to provide that functionality as well.

[js_12345678_55AA]

If it uses the RFID to identify the label type, presumably there is no way to manually tell it the label size in the software.
So presumably an emulator would need a way to provide that functionality as well.

Sure it is used. But I only use one type of label all the time.
A more sophisticated emulator could be a man in the middle filtering the I2C commands to read/ increment the counter and only emulate them. All the other reads are forwarded to the reader/tag of the inserted roll.

JS

[SmokelessCPU]

An interesting thing could be trying dumping the firmware, maybe the STM32 IC that they have onboard has still the ST vulnerable BOOTLOADER, maybe a voltage glitch to downgrade from RDP 2 to RDP 1 is still required to access the BOOTLOADER interface...

Once dumped the firmware Appling a patch (or getting the NFC password) will not be that difficult, and maybe that mod could be even pushed through USB (if support DFU mode)..


https://prog.world/read-secure-firmware-from-stm32f1xx-flash-using-chipwhisperer/
https://blog.zapb.de/stm32f1-exceptional-failure/

[Refrigerator]

What does it do when it advances the paper but fails to write to the tag?
Does the printer advance the paper before or after it writes to the tag?

Also looks like it pulls the interrupt line high anytime it detects a roll, so what if the NFC board is disconnected and a pullup to the interrupt line is added?

[tszaboo]

We are using these label printers in our production, to ID and serialize our product. Not the cheap paper one, the higher end one. We even went ahead, and designed in a recess in the enclosure for a selected Dymo label. And guess what, it is nowhere to be found in that size anymore. They just obsoleted a size of a label, which we have the perfect size recess designed into an injection mold.
So, we ordered third party labels that were custom made for us. Luckily we don't have this abomination of vendor lock-in printers. They can go to hell.
mod: Or maybe it was Zebra. They can both go to hell.

[mistial_dev]

Going through the software side of things, they also have some nasty region locking that isn't happening yet.  If you put in the wrong region media, it will pretend it doesn't exist.

The tags themselves largely correlate to the info from the developer documentation, though.

https://webcache.googleusercontent.com/search?q=cache:AoemJ-ugkRIJ:https://developers.dymo.com/+&cd=1&hl=en&ct=clnk&gl=ca

The blog is down, so that's a webcache version.  I've attached a dump from a proxmark3 of a virgin tag if anyone wants one to work from.

The DRM seems to be tied to the SKU, so I'm working on a modchip to emulate the NFC functionality, with BLE functionality so an app can use it.  The whole thing is going to be open source and open hardware, I won't be selling them.

I'm going to use a PSOC 4 BLE as a base.  They are cheap, easy enough to support and build on, and natively do 1.71v-5v, which will simplify the hardware.

[mistial_dev]

If it uses the RFID to identify the label type, presumably there is no way to manually tell it the label size in the software.
So presumably an emulator would need a way to provide that functionality as well.

The label has its dimensions encoded into the label.  I haven't seen any firmware update functionality so far, so it's much easier to update the label to support new sizes than to firmware update the printer.

If one has a tag writer or emulator, you can provide those values.  You are still stuck to "authorized" SKUs for a region in terms of the software, which has code to pretend no label is inserted if it doesn't like what you provide.  A software patch may be necessary there as well.

[mistial_dev]

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

FYI you cannot simply stick Arduino instead of a custom board .

A CY8CKIT-059, on the other hand, would get the job done nicely 

Like an Arduino, but the PSoC has some nice IO and programmable logic.  I use them for all kinds of interface projects.  If you don't mind putting an extra USB port on the side of your dymo, they could indeed be a drop in replacement.

[apelly]

Or maybe it was Zebra. They can both go to hell.

I've never heard of anyone using anything other than zebra in a commercial/production environment. This dymo brand seems to be for office users.

I was impressed with the number of brands I have to avoid now though...
https://www.newellbrands.com/our-brands

[WilliamT]

Dear EEVBlog,

Thanks for your latest video and I hope you will consider my humble suggestion.

@21:38 in your video you recommend throwing out the labeller, I would like to suggest returning it for a refund under the Australia Consumer Guarantee.

Everything Australian consumer needs to know about this topic can be found by searching "ACCC Repair, replace, refund" and then following up with a search for "Consumer Affairs" in their state government for any state specific procedures and I recommend following these procedures to the letter.

If I was in this position, I would argue that the Dymo Labeller (and any labels I felt I had been forced to purchase) had a "Major Defect" because "it has a problem that would have stopped someone from buying it if they’d known about it".

As I imagine you purchased the device with the intent of being able to use your existing label stock or 3rd party labels, you could argue that you were not informed by the device packaging, the sales person assisting you or the website from which you purchased the device that the device uses DRM to enforce the use of original DYMO labels and that the use of old label stock and 3rd party labels will deactivate the device. If you had know this you would not have purchased it.

We have all seen the warnings "Use original parts only" etc. etc before where 3rd party / aftermarket parts work just fine. I would claim that the warnings on the DYMO packaging are of the same vein and do not inform the user that the device will be immediately deactivated if old stock or 3rd party labels are installed.

I have had the unfortunate experience to go through this process twice in recent months and would be happy to post further on my experiences, if people are interested.

Best of Luck,


W

One final word, Store policies are for employees only. They have no bearing on you as a customer.

[mistial_dev]

WilliamT raises a very good point.  There may be many similar laws around the world.

I am not an expert in EU laws, for example, but I was under the impression that the EU has specific regulation for tying the purchase of one product to another. It’s good advice to take advantage of local consumer protection laws, as well as merchant guarantees.

As one of the original keurig 2.0 hardware hackers, I can tell you that Wal-Mart Keurig 2.0 devices in the US quickly removed DRM, even as the box said it still had it.  I suspect that Wal-Mart got tired of returns.

[EEVblog]

@21:38 in your video you recommend throwing out the labeller, I would like to suggest returning it for a refund under the Australia Consumer Guarantee.

Sure, if you can do that, do it.
And be sure to leave a negative review.

[EEVblog]

FYI
Dymo have replaced all their old Amazon 450 listing with the 550 meaning that the old (good) reviews stay in place. The sheer balls on them!
https://www.amazon.com/dp/B08TMG88RP/

You can see the old reviews are dated before the 550 was released. All the new reviews are all 1 star obviously, but because there are near 1000 old reviews, it still shows as 4.5 star rating.

[thm_w]

You can sort by review date: https://www.amazon.com/DYMO-Label-Printer-LabelWriter-Thermal/product-reviews/B08TMG88RP/ref=cm_cr_getr_d_paging_btm_next_4?ie=UTF8&reviewerType=all_reviews&sortBy=recent&pageNumber=11

It was actually a prior listing for Dymo small multipurpose labels, not for a 450 printer itself.. super scammy.
About 90 of the written reviews are for the 550, the remaining ~160 are for labels.

https://blog.bobsledmarketing.com/blog/the-challenges-of-rebranding-on-amazon unclear what the rules are or if they are enforced.

[mistial_dev]

It can be either a countdown or a countup.  It's described in the developer link I posted.

[EEVblog]

[mistial_dev]

Anyone recognize that wire to board connector on the NFC PCB?  I don’t think it’s JST.  Molex maybe?

[sleemanj]

Amazon shouldn't even allow you to do a sneaky product swap like that, a major failing of the system and gives them (Amazon) a bad name.  Surely there must be something in the T&C that prevents it at least if not a technical solution.