Dymo 550 Thermal Printer DRM Hacking

[Darxtek]

So it looks like I got everything programs correctly and I’m using 4 x 6 labels if I were to want to change label size what would I need to do flash different  .bin or leave it as is?

[czester1994]

Label 1/2"x1" S0722530. Please compile for .bin file. Thanks

[Mhare]

Hi all,

I’m new to programming never done this before. I have soldered all the wires on but I’m stuck with downloading and installing the firmware. Any help would be great thank you

[Iomega0318]

Long story short, I work for a school and we've been using the 450s for years with the software we use and 3rd party labels. However we have had 450s failing frequently and started replacing them with all that is available now the 550s, the software update our provider has pushed out is also no longer going to support the 450s, neither Dymo or the other company will admit to this, so we're being forced onto the 550s. Our 58+ schools that have 2-3 dymos each pay for their own labels hence the 3rd party.

I have successfully soldered and programmed a board with our labels, I'll provide the dumps once I get it fully working, but have run into a weird issue. When you first power on the Dymo it doesn't recognize the board (no RFID) and therfore says no label detected, power it off from the front and back on and it works, power off and on from front no work, power off and on from front again works. It seems to be consistent that it only works ever other power cycle, green light blinks correctly when it's working as well. Any ideas?

[Iomega0318]

Hi all,

I’m new to programming never done this before. I have soldered all the wires on but I’m stuck with downloading and installing the firmware. Any help would be great thank you

Where are you stuck, what have you tried?

[allenlorenz]

 Here is the dump for the dymo 30333 tag

[imintune]

Is there a place or someone I can just ship this 550 to get it done?

[RethoricalCheese]

Hey!

Looks like there has been a modification in firmware which blocks this hack.
Mainboard and NFC reader are exactly the same. Bluepill works on printer with lower serial number and doesn't detect anything on higher SN. Same exact module works on all older printers and none of the newer ones.
Just to be 100% sure that there are no hardware differences, I transferred microprocessors between both printers. The issue transferred aswell so it's 100% firmware difference.


Used a logic analyzer to dump startup on both printers (with original wire and nfc module, no bluepill between them. Same roll on both of em).

Here's the diff between them: https://www.diffchecker.com/5YVaDYkI/

Kindla looks like signature is read twice and expects this:
uint8_t signaturecmd[] = {0x22,0xAB,0x04,uid[0],uid[1],uid[2],uid[3],uid[4],uid[5],uid[6],uid[7]};
and then this:
uint8_t signaturecmd[] = {0x22,0xBD,0x04,uid[0],uid[1],uid[2],uid[3],uid[4],uid[5],uid[6],uid[7]};
but current version of freedmo only transfers the latter.

I might be way off tho..

[js_12345678_55AA]

Hey!

Looks like there has been a modification in firmware which blocks this hack.
Mainboard and NFC reader are exactly the same. Bluepill works on printer with lower serial number and doesn't detect anything on higher SN. Same exact module works on all older printers and none of the newer ones.
Just to be 100% sure that there are no hardware differences, I transferred microprocessors between both printers. The issue transferred aswell so it's 100% firmware difference.


Used a logic analyzer to dump startup on both printers (with original wire and nfc module, no bluepill between them. Same roll on both of em).

Here's the diff between them: https://www.diffchecker.com/5YVaDYkI/

Kindla looks like signature is read twice and expects this:
uint8_t signaturecmd[] = {0x22,0xAB,0x04,uid[0],uid[1],uid[2],uid[3],uid[4],uid[5],uid[6],uid[7]};
and then this:
uint8_t signaturecmd[] = {0x22,0xBD,0x04,uid[0],uid[1],uid[2],uid[3],uid[4],uid[5],uid[6],uid[7]};
but current version of freedmo only transfers the latter.

I might be way off tho..

Looks like they added another command "0xAB" to also read the "NXP_SYSTEM_INFORMATION" (see https://www.nxp.com/docs/en/data-sheet/SL2S2602.pdf  "9.5.3.18 GET NXP SYSTEM INFOMATION", page 33)

The content from this request will be static for all tags so a simple emulation should do the trick.

As soon as I find some time I will try to add it.
But testing needs to be done by you since I do not have (and do not plan to buy) an "updated" DMO550.

JS

[RethoricalCheese]

Ofcourse, happy to test.

[js_12345678_55AA]

Ofcourse, happy to test.

Here we go. Since you made such a nice diff (SERIOUSLY REALLY HELPFUL!), I assume you know how to check out a branch and compile the firmware yourself.

See: https://github.com/free-dmo/free-dmo-stm32/tree/feature/nxp_system_infomation  (the missing "r" in information was adpoted from original NXP document  )

If this works, I will merge this as well as some long-standing pull requests 

JS

[RethoricalCheese]

Good new and bad news.

It works on older SN models.

It kinda works on newer SN models. It does detect emulated roll now.
But the issue is that it remembers. Number of labels decrease and do not reset after a power cycle. Not even when testing on another PC.

But wait, there is more. Just turning it off and on, it is unable to connect to PC. Only after capacitor discharge, it is able to connect again. But this issue is not because of freedmo. It's acting like this in stock aswell.

Tested on 2 devices.

[js_12345678_55AA]

It kinda works on newer SN models. It does detect emulated roll now.
But the issue is that it remembers. Number of labels decrease and do not reset after a power cycle. Not even when testing on another PC.

It sounds like they might use internal memory on the STM32 now to store the counter of a roll UID...
But I'm pretty sure they do not have unlimited memory for this and as a wild guess I would say they only remember that last <10 UID.

In the source project we already have several UIDs which we can use to alternate and switch between.
Can you make the following test please:
* setup roll in emulation, do some decrements, switch off, switch on ==> counter in emulation resets and the printer should be in your reported "blocked state"
* now change firmware and select different UID for emulation. In main.c source file change the line:
    #define SLIX2_TAG_EMU 1  // 1-12
   and use a different value (e.g.  2 )
* check if printer works again, decrement some, switch off, ==> counter in emulation resets and the printer should be in your reported "blocked state"
* now... change in firmware back to emulation of tag 1
  => check if printer works again
    + if it works, they only remember the last tag ... easy fix
    + if it does not work, they might remember multiple tags... but we have more good tags for emulation.
       Unfortunately the only way to find out is to try them all one by one and always checking if emulation of tag 1 is coming back to live

In case we can find that they only can remeber a limited number of tags, we could add cycling through our known good tags to defeat this.

JS
   

[RethoricalCheese]

Tested all 12 of em. All of them are still in memory.

Btw, there are 2 typos in slix2_tag_emu 11. Missing a couple commas. Not that it matters to this case.

[js_12345678_55AA]

Tested all 12 of em. All of them are still in memory.

Btw, there are 2 typos in slix2_tag_emu 11. Missing a couple commas. Not that it matters to this case.

WOW... for sure you been busy...

So 12 tried means <10 was not the case. I still have some more tag readouts to try. Hopefully something like 16 or 32 is the magic number they implemented.

Since they need to "steal" the flash from firmware space and USB stack and the normal printer code needs some space... for sure they only reserved something like 1k - 4k for it.
As an absolut minimum they need 4 bytes for the UID and 1 byte fpr the counter which means they could store 200 - 819  UID / counter pairs

Worst case... still doable since the bluepill MCU has a lot of empty flash...But it would require a LOT of readouts.


Question to all: Is there a firmware "update" available so testing would be easier?

JS

[oztek]

Hi Everyone,
We have a Dymo 550 Turbo we purchased as a replacement to a dead older Dymo.
It's used as a workshop label printer, as we have a large supply of generic 30252 address labels with removable adhesive, the dymo equivalent are permanent adhesive.

Initially we kept using our labels by ripping off the RFID sticker from a genuine roll until the count ran out.

I've tried very hard to get this bluepill solution to work and I'm not having any luck. I wondered if I had perhaps bought a counterfeit bluepill board so I bought some more from one of the amazon links posted on this forum to try again.

As we are only going to be using 1 label type, the RFID board is not attached.

I've used an ST-LINK V2 to flash on the pre-compiled freedmo-default-sku-30252.bin.
The process appeared to work successfully, I saw the memory contents change to match the file, and I've tested reconnecting and reading it to confirm it updated.

RFID board is removed from the printer and the bluepill plugged in it's place - printer is detected in windows, but when trying to print we still get an unknown label detected error.

Can anyone please help, or spot something I've done wrong? 

Thanks

[js_12345678_55AA]

@oztek

The IC printing "STM32..." looks genuine... But who knows ;-)

Please attach a screen shot of the STLink Utility program after you programed the IC (to have a look at base address, ...)

JS

[RethoricalCheese]

Use S0722370 instead of 30252. Both are same size, right?

I found that those short model number variants did not work for me but those starting with S do work.

[js_12345678_55AA]

Tested all 12 of em. All of them are still in memory.

Btw, there are 2 typos in slix2_tag_emu 11. Missing a couple commas. Not that it matters to this case.

I have added 5 more SLIX2 UIDs and their signatures for testing.
If we're lucky, DMO will only remember the last 16.

@RethoricalCheese: Could you please test them as well?


In case DMO remembers more than 16, well, then...

*W*E*L*C*O*M*E* *T*O* *R*O*U*N*D* *2*

Challenge accepted DMO!

I just read a very nice write up the other day about breaking STM32 RDP level 2 and level 1 protection:

https://sec-consult.com/blog/detail/secglitcher-part-1-reproducible-voltage-glitching-on-stm32-microcontrollers/

As luck would have it, I have a ChipWhisperer lying around 

So stay tuned.

JS

[oztek]

Here's the screenshot from ST Link Utility.


I also note the suggestion of trying label S0722370 instead, but I don't see a .bin for that in the package.

[darkspr1te]

this is a good read,
https://offzone.moscow/upload/iblock/0a5/nad1d86e3ah3ayx38ue56vxbh2j07kd4.pdf

[RethoricalCheese]

Sadly even 17 is not enough to roll over.

Btw, size should be 2 bytes because some rolls exceed 255 stickers.

[Zucca]

Because I know Dymo is reading this.

Dear Dymo, why don't you understand you can't win this battle? Stop fighting against your customers who keep your company alive!
How is your income doing after you released your DRM dirty trick?

Since I know you Dymo will not change soon your "design" strategy, I will make sure my friends and the people I know in my business will not touch any new Dymo product.

CEO Sandy Lee don't you think it's time to save your company from an embarrassing end?

Hope it will be not too late when you will realize what you have done.

[js_12345678_55AA]

Sadly even 17 is not enough to roll over.

Was worth a try, thanks for all your testing.

Btw, size should be 2 bytes because some rolls exceed 255 stickers.

This is exactly how round 2 will be done... after having a look we will learn how to calculate the unsecured CRC for the data section of the tag.
Then we will be able to create tag emulation with 65534 tags on a single spool. Which means the already known 17 UID+signatures could last >1 million prints ;-)
We also can remember which UID reported which counter the last time....


JS

[BaronPils]

Does anybody know the sequence of the serial numbers, that we know at least which one the old hack works and for which one the new hack is needed.

Maybe for me to start

I have a 5XL bought last year which is working: QG1450022xxxA
I have a 5XL this year (bought in April) which is not working: QG2350146xxxA

I don't share the full serial number, never now who's reading it .

Maybe a strange thought, but can we not find a way to flash the firmware of the older 5XL's to the new ones?