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