Dymo 550 Thermal Printer DRM Hacking

[Darxtek]

I had to take a break yesterday as my wife was giving me the evil stare because I was stuck in one spot too long but today I will definitely give the firmware a try I was able to properly compile it last night and that’s where I went to sleep lol

I’ll have an update in the next few hours

[js_12345678_55AA]

I updated the pre-compiled binaries on the github project.

https://github.com/free-dmo/free-dmo-stm32

Release 1.1.0 has a ZIP with pre compiled firmware(s). It now includes the patch for the new D.mo versions.

=> You still need to short the eeprom pins (=enable write protect)


JS

[Darxtek]

shorted EEPROM (at least i think thats the EEPROM) pin 7/8 and wrote reuploaded bin file but still get , blinking power button, stuck on label 30251 (EMPTY)
DMO 550 turbo Sr# QF3xxxx

[Darxtek]

DMO 550 turbo
Sr# QF3xxx

[Bastelwastl]

Hi all,
great work js and RethoricalCheese, thanks for your research and effort.

I have two Dmos LW 550 (non Turbo) since last week and tried to modify them, they have different Hardwarerevisions, it looks like as if it depends on the Mainboardrevision if the mods are working or not.

Dmo 1:
LW550B_Rev. H,  Date 20220203, Ser. QE2350****B
Rev. E on NFC Board
-> Bluepill + EEPROMmod are nessesary for working

Dmo 2:
LW550B_Rev. K,  Date 20220620, Ser. QE3440****D,
Rev. E on NFC Board
-> Bluepill is not working, the Dmo didn´t detect the original tunneled labels nor the Bluepills fake labels, blinking all the time, maybe data encryption now.
-> EEPROMmod alone is not working, if the EEPROMmod is on, only labels are detected which were put in the Dymo once before the mod. Looks like some kind of "write and verify" of the EEPROM instead of the "stupid" writing and reading the EEPROM like in Rev. H.

Hardware changes between Rev. H and Rev. K which i found:
- Changed "U2" Stepperdriver for the Transportmotor
- Flexconnector for one of the Labelsensors has now three instead five conductors

Maybe others will also share their experience which Revision and Model is working or not.

   

[Darxtek]

Here is a pic of mine….
I have some with serial # QF3xxxx and some QF4xxx and both have this same identifier

[Bastelwastl]

It looks like that the Numbers after the Modelcode (QE=550,QF=550Turbo,QG=5XL) give no hint to the Revision, maybe its the Letter in the End ?

My suggestion:

QExxxxxB = Rev: H
QExxxxxD = Rev: K     

[fantasy2]

Would be great if we could see some i2c raw data from new printers. It would directly clafiry what the issue is. Perhaps the dmo is now doing extra checks and the bluepill does not respond exactly the same way as the original chip. This has happened before.

I cannot imagine that the labels are now suddenly encrypted. They would have to encrypt the label the first time it is inserted.
If someone can make a dump of the label we can also directly see if this is the case.

[Xq1xq1xq1]

I'm new to this but would be happy to get ic2 raw data off the printers I purchased a few months ago.

If someone can send me how to this, I gather and send it in to you.

[js_12345678_55AA]

It looks like that the Numbers after the Modelcode (QE=550,QF=550Turbo,QG=5XL) give no hint to the Revision, maybe its the Letter in the End ?

My suggestion:

QExxxxxB = Rev: H
QExxxxxD = Rev: K     

Thank you so much for this investigation (@Bastelwasti + @Darxtek).

I'm now also a proud onwer of a Rev K printer... 
(serial is in form "QExxxxxD"... so looks like the last letter is the indicator).

My original first printer is a "QExxxxxA" which has a "Rev:E" PCB

@D.mo: Round 3? 

JS


P.S. From your list...
 Rev: E, Date 20200812 => initial version
 Rev: H, Date 20220203 => this date (might be fake) is prior to the discussion in this thread, so they added the eeprom before their problems got discovered? If so it does not contain any direct counter measueres for the bluepill
 Rev: K, Date 20220620 => this date is clearly after they saw (read here) how they screwed up, and most likely they also built a bluepill to test and implement counter measures... (but nothing we should be afraid about...)

 

[Darxtek]

Correct me if I’m wrong but I think yesterday somebody posted some raw data but it looks like it is deleted now. Sadly all my printers are Rev: I

[js_12345678_55AA]

Hi all,
great work js and RethoricalCheese, thanks for your research and effort.

I have two Dmos LW 550 (non Turbo) since last week and tried to modify them, they have different Hardwarerevisions, it looks like as if it depends on the Mainboardrevision if the mods are working or not.

Dmo 1:
LW550B_Rev. H,  Date 20220203, Ser. QE2350****B
Rev. E on NFC Board
-> Bluepill + EEPROMmod are nessesary for working

Dmo 2:
LW550B_Rev. K,  Date 20220620, Ser. QE3440****D,
Rev. E on NFC Board
-> Bluepill is not working, the Dmo didn´t detect the original tunneled labels nor the Bluepills fake labels, blinking all the time, maybe data encryption now.
-> EEPROMmod alone is not working, if the EEPROMmod is on, only labels are detected which were put in the Dymo once before the mod. Looks like some kind of "write and verify" of the EEPROM instead of the "stupid" writing and reading the EEPROM like in Rev. H.

Hardware changes between Rev. H and Rev. K which i found:
- Changed "U2" Stepperdriver for the Transportmotor
- Flexconnector for one of the Labelsensors has now three instead five conductors

Maybe others will also share their experience which Revision and Model is working or not.

 

I did some initial tests with my revision K:
 * I added the bluepill with latest firmware (see "1.1.0" release on github)
 * no EEPROM write protect for now
 * stuffed in some generic labels (without RFID)
 * turned printer on and it shows a steady ready light
 * hold middle button for some time for deep sleep, press middle button again to wake up ==> still steady light
 * flashed another (label) firmware, restarted ==> also ready light
 * flashed another (tag emu) firmware, restarted ==> also ready light

@Bastelwastl ...
Please make sure you test with the latest 1.1.0 firmware: https://github.com/free-dmo/free-dmo-stm32/releases/tag/v1.1.0
We also could face different firmware inside of the printer's MCU.

Tomorrow I will hook up the logic analyzer and listen to I2C reader and I2C eeprom while doing some "original prints"

JS

[Bastelwastl]

Correct me if I’m wrong but I think yesterday somebody posted some raw data but it looks like it is deleted now.

It was me, after comparing my posted "raw data" to others raw data, i saw it was only bull***t my homebrew "sniffer" spit out. So i decided to delete the confusing posting.

Rev: H, Date 20220203 => this date (might be fake) is prior to the discussion in this thread, so they added the eeprom before their problems got discovered? If so it does not contain any direct counter measueres for the bluepill

"Sherlock JS" you were absolutly right, I desoldered the EEPROMmod now in Rev: H and its also working (i did the EEPROMmod &  Bluepillmod together without crosscheck). Maybe they only changed the Type and Brand of the EEPROM in this Revision.
I will attach an updated list.

@Darxtek, can you post the last Letter in your Dmo Serial?
@RethoricalCheese, can you also post your Dmo Revision and Serial?

[Axis-3790]

I apologize for the delay on my end. I ended up busier than expected last week. I did go ahead and attempt to solder pins 7&8 on the eeprom. Feel free to refer to my picture to make sure I did it right. I also compiled v1.1.0 onto the blue pill. I am using label 30347 but with no success. It did not detect the official dymo branded labels either.

S/N version QF4*********C
Revision I

[Darxtek]

These QF3 and QF4 where both RevI for me

[Bastelwastl]

@JS, I did some short tests with your new release on Rev: K, flashed "freedmo-default-sku-S0722530", Bluepill with labelsize is detected and the labels are count down during printing but no counter reset after powerup, so its defenatly written to the EEPROM. Original labels are not detected / tunneld now.

Then I flashed "freedmo-default-sku-S0904980.bin", Bluepill is working, Dmo has steady light with every label and shows "empty" in the Software but i can print any label and size, whatever I want, no countdown, no labelsize is shown in the software.

But the Bluepill freezes with "freedmo-default-sku-S0904980.bin" after two minutes or so, green LED stays on, Dmo is blinking. After a press on the resetbutton everything is working again in the same matter until next freeze.

[RethoricalCheese]

SN: QE3*********D
Revision K

was the one I was testing on. (hoping I did not get my boards and cases mixed up at one point)

Just to clarify to people trying the short method. If you can't even get the bluepill hack working then shorting gives you nothing but wasted hours. You must first get the bluepill hack working (detecting the label coded in your bluepill) and only after that try shorting.
All shorting does is preventing writing label information to dymo itself.

[js_12345678_55AA]

Then I flashed "freedmo-default-sku-S0904980.bin", Bluepill is working, Dmo has steady light with every label and shows "empty" in the Software but i can print any label and size, whatever I want, no countdown, no labelsize is shown in the software.

This sounds like a JOKER ? I will test this next

JS

[js_12345678_55AA]

@JS, I did some short tests with your new release ... Original labels are not detected / tunneld now.

Found a bug in NXP SYSINFO READ REQUEST, so tunneling labels does not work in 1.1.0

JS

[Bastelwastl]

Then I flashed "freedmo-default-sku-S0904980.bin", Bluepill is working, Dmo has steady light with every label and shows "empty" in the Software but i can print any label and size, whatever I want, no countdown, no labelsize is shown in the software.

This sounds like a JOKER ?

This label normally is for the Dmo XL Version, maybe its not present in the Firmware or EEPROM of the Dmo 550 and therefore it behaves like this. I flashed "freedmo-default-sku-S0904980.bin" from Release 1.1.0 again, and the freezing issue is gone.
Printed 75 aftermarket labels (no NFC) with EEPROM write protect on and 50 labels with EEPROM write protect off (i put a Switch between pin 7 & 8 ) without a problem.


Does the bluepillhack with release 1.1.0 actually work for one of the 550 Turbo owners with Rev: I ?

[Axis-3790]

550 Turbo w/ rev I here. I have two of them to be specific. I have one with the eeprom pins 7 & 8 soldered together and the other is normal. I downloaded the v1.1.0 again today and compiled the software again. Both 550 turbo's did not recognize the official dymo labels. Both started flashing after booting.

[js_12345678_55AA]

Here comes a small I2C christmas story 

BL24C128A = I2C eeprom with 256 pages a 64 bytes + 1 extra id page ==> https://www.belling.com.cn/media/file_object/bel_product/datasheet/BL24C128A.pdf
D.MO pcb pulls all address lines to GND which make I2C address of the eeprom 0x50
In order to read from a specific address an incomplete write (just sending the address and then stop) needs to be performed.

At startup D.MO printer reads in 8 byte blocks starting at page 1 (address 0x0040).
write to 0x50 ack data: 0x00 0x40
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF
read to 0x50 ack data: 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

==> Factory default is empty (everything is 0xFF)

At the moment a new spool is inserted into the printer the following WRITE happens:

write to 0x50 ack data: 0x00 0x40 0xFF 0x01 0x16 0x7B 0x77 0x55 0xC6 0xFF
write to 0x50 nak
write to 0x50 nak
write to 0x50 ack data: 0x00 0x00
read to 0x50 ack data: 0xFF

Translation:
- write to I2C device 0x50, to address 0x0040
- try to start a new write => NAK (polling to find if eeprom is still busy with the write)
- try to start a new write => NAK (polling to find if eeprom is still busy with the write)
- try to start a new write @0x0000 => ACK (polling found out eeprom is not busy with write anymore)
- read (from 0x0000) ==> 0xFF (makes no sense... but maybe this was the "easy" way to cancel the previous write)

Let's have a look at the written data (8 bytes):

0xFF 0x01 0x16 0x7B 0x77 0x55 0xC6 0xFF
FIX? FIX? UID  UID  UID  UID  CNTR CNTR


So it looks like the 8 bytes are composed as follows:
 0xFF 0x01  fixed (same for all records, I added more later)
 0x16 0x7B 0x77 0x55  UID (lower 4 bytes of the slix2 tag UID)
 0xC6 0xFF  counter (last seen counter value for this slix2 tag UID)

!AFTER THE EEPROM WRITE THERE IS NO READ / VERIFY OF THE JUST WRITTEN DATA!
==> hardware write protect will work 100%

And just in case there is a check, we could solder 2 wires from resistors next to I2C eeprom to the bluepill and...
 a) whenever bluepill starts up we could ERASE the eeprom (to factory defaults)
 b) emulate the eeprom completely


Whenever printer is turned on / comes back from standby / spool is changed, a read starting from address 0x0040 is initiated...
... as soon as the UID from the currently inserted tag is found the read stops
... it also stops after reading several? empty entries (8 times 0xFF) - looks like it stops as soon as the first eeprom page is read which starts with 8x 0xFF


I will now "clean up" my eeprom, add the "solder blob write protect" and then focus on making everything work again ;-)


JS


So for testing you should:

- make eeprom write protect FIRST

- then pick a never used SLIX2 TAG EMU (e.g. 17) and compile firmware with it (this ensures that your eeprom does not have UID from tag emulation stored with a low or locked counter)
 #define SLIX2_TAG_EMU 17

(tag pass through does not work yet, will be fixed soon).

[js_12345678_55AA]

I never paid attention to this detail...

but now that I looked closer. It seems my REV. E board also has a I2C eeprom (U5:  ATH102... might be ATMEL part).

I wonder if the feature was there all along and some sloppy developer just forgot to enable it in the older firmware?

JS

[Bastelwastl]

The ATxyz EEPROM from Rev: E has imho only 2Kbit instead of the 128Kbit from Rev. H & Rev. K.

https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/AT24C01D-AT24C02D-I2C-Compatible-Two-Wire-Serial-EEPROM-1Kbit-2Kbit-20006100A.pdf

[js_12345678_55AA]

The ATxyz EEPROM from Rev: E has imho only 2Kbit instead of the 128Kbit from Rev. H & Rev. K.

https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/AT24C01D-AT24C02D-I2C-Compatible-Two-Wire-Serial-EEPROM-1Kbit-2Kbit-20006100A.pdf

I will have a look later... maybe used for serial number WTF... there is *ALWAYS* enough space inside of the STM32 to store 2kBit = 256 BYTE !!!.

JS