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.

[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.

[sleemanj]

As for alternatives, my Brother 720NW will be prised from my cold dead hands. 

I use it for both shipping and general purpose with continuous label rolls, it has an auto cutter so a 62mm label of any length from about 15mm is printable (need enough to grab hold of).

Of course I do not buy original brother rolls, just knockoffs.

For shipping labels I have a script which detects a new shipping label PDF generated by teh courier's system splits it in two (because the brother is only a 62mm wide printer) and does a bit of massaging before printing.

[hans]

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...

Not all that hard. I've been researching custom (UHF) RFID tags.. all you need is a diode receiver and an antenna switch.

These tags communicate with backscatter (far-field, UHF) or load modulation (inductive, 13.56MHz). The reader>label comunnicates by sending a carrier signal with ASK modulation (the NXP chips says a depth of 20-30%, or optionally 100%). The tag harvests energy from this carrier signal to power up, so 100% won't be used for passive tags. The label>reader communicates by shorting it's antenna or coil connection, which the reader can sense and demodulate the transmitted data.

The bitrate at which this happens is only in the order of kbps. These RFID tags only contain a few dozen bytes, maybe 256 for large tags, so it doesn't take long to read them.
The protocol is probably the tougher issue. I'm not sure what the NXP NFC tags use, or if it's proprietary. For UHF RFID tags most commonly EPCgen2 is used. It's quite an extensive standard, and also not really a mainstream industry to work on the tag side of things.. so probably requires a lot of investment to get a small result on the software part.

If the I2C is unprotected yet the tag is password protected... then the password should be somewhere in the I2C serial stream when a label gets printed.

I wonder what happens if you can get a new tag (or change the existing tag), and use a different password on it. Just write the original memory contents to that tag. If the password is changed, then the Dymo printer won't unlock the tag and can't decrement the remaining labels counter. Not sure if they are smart enough to check if the sent password will unlock the tag (or that the write was successful). If not, that should create a permanent fix, without the need of repeatedly "refreshing" the NFC tag, or diving into custom I2C slaves that emulate a dummy NFC reader.

edit: Oh I see the counter decrements on RD commands, instead. That complicates things a bit.
Still wondering if it's necessary to make a complete NFC clone. Perhaps sniffing for the first 24-bits of the code on the bus, and then corrupting the last few bits (just pull on SDA for a few cycles), is enough to make the RD operation invalid and have it not decrement. Again not sure if Dymo firmware deals with that situation, but the above can probably be done on a 30ct PIC.

[chefkoch84]

Free speech at Amazon (#pay_to_win)

Edit:

tl;dr; Amazon blocks new reviews because of "unusual reviewing activity on this product"

Just have seen the EEVBlog2 Channel Video.
With that it gets even crazier:

They mix in old reviews (before DRM) and do not allow new reviews that would call them out !!!!!!
Does look quite fishy to me...


I might bye it... write the review.. and return it ;-) JUST TO FUCK THEM OVER:
(only the e-waste is a sad aspect of this strategy)

[js_12345678_55AA]

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

VERY interesting...  especially the "Counter Strategy" which is set to 1 on my rolls => 0x01 = Counting up from 0xFFFF – “amount of labels” – “Counter margin” to 0xFFFF.

It also seems that just the CRC32 in front is used to "protect" that data.

And since for some reasons my rolls do NOT report to have a write protection for the data blocks... I will try to set "Counter Strategy" to 0  and check what happens
After updating the NXP Tag Info app it no longer shows the first 32 blocks as writeable (seems was a bug in nxp app before).

Time to "guess" the write password.

Maybe that easy


JS

[Psi]

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.

   wow.  The TV-B-Gone tool has some competition,  DYMOLabel-B-Empty 

DYMO really have opened themselves up to a HUGE disaster if anyone gets the write password and builds a long range label tag writer.
Considering the write password may only be a 4byte number that ain't going to take long.

[AlienRelics]

I gave up on Dymo label printers when they stopped supporting the older serial and USB label printers due to a new Windows version. Funny, the new software for the new printers works just fine in the newer version.

They simply decided you have to buy a new printer by locking you out of the older printers.

As for Amazon, they decided based on no actual evidence that my reviews were "suspicious" and I can no longer post reviews at all.

[AlienRelics]

Remember ESC codes? I could make my dot matrix printer dance. And the ESC codes were printed in the printer manual!

[LightTangent]

Hey Dave,

Thanks for the great YT vid as always!

I noticed they've been doing a similar trick (on Amazon) in the UK, although it's rather interesting when you dig a little deeper.

They're pretty sneaky about it though... For example this listing:
https://www.amazon.co.uk/LabelWriter-Printing-Automatic-Recognition-Shipping/dp/B09DY3YT4Y

Has 3 different "models" - 2 of which are labels (which are what the majority of comments relate to), and 1 is the actual printer.

If you check the price history of the printer, it seems to have been added on Sept 24th (which seems a little early for the 550, but plausible I guess). Originally about £150, now around 100. I'm assuming it's the same printer though.
https://uk.camelcamelcamel.com/product/B09DY3YT4Y

If you check the labels, however, It seems that as expected they've only fairly recently had the DRM added.
https://uk.camelcamelcamel.com/product/B00028XNN6
https://uk.camelcamelcamel.com/product/B000HEZD7E

One label that from about 2019 through Late 2021 was around the 15 quid mark, has since jumped up to 22 quid, a 50% markup. Clearly the "DRM" flavour?
Another from 8 quid since around 2013 until late 2021, and then BOOM! 11 or 12 pounds.

There's around 1,000 (about 93% at 4* and above) reviews and of course the majority have naff-all to do with the 550 label printer.

"I've owned my LabelWriter 450 Turbo for ten years now, "...
"Have used these in my Dymo label printer for many years. Great for Christmas card addresses,"...
 etc.

Tried to send an email to Amazon to complain and got a fairly standard form response back feigning ignorance about what I was suggesting. They suggested if there's a problem with a particular review, to click the "Report" button (well, bugger clicking all of them!), or to get back to them with a specific ASIN number so they can investigate (which bearing in mind I provided 3 or 4 different links they already had!)

Interestingly then it seems that the deviant flaw in the whole system is that you can advertise multiple unrelated products under a single slug and present them as "models", even if that means you're selling completely different things - and the reviews are all aggregated under the same slug rather than each individual ASIN... and clearly Amazon just don't give a rats about it.

Tony

[mistial_dev]

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.

Amazon does have a report seller option.

[js_12345678_55AA]

Just found that the READ password is different per TAG.

Looks like dymo followed the application note from NXP to use "dynamic passwords" derived from UID.

=> Labels in shops are safe. Nobody can invalidate (use) them. Also the "destroy" command has its own password (per tag for sure) which we don't know...

This means full tag emulation or waiting for "magix SLIX2 tags" are the only options.


JS

[mikeselectricstuff]

=> Labels in shops are safe. Nobody can invalidate (use) them. Also the "destroy" command has its own password (per tag for sure) which we don't know...

There are ways to remotely destroy RFID tags without the password, just sayin'..

[js_12345678_55AA]

=> Labels in shops are safe. Nobody can invalidate (use) them. Also the "destroy" command has its own password (per tag for sure) which we don't know...

There are ways to remotely destroy RFID tags without the password, just sayin'..

Sure... microwaves... but this could also be used to destroy the adhesive of non RFID tags (cooking them in the shop), just sayin'...

[js_12345678_55AA]

Finished some more tests.

The counter in SLIX2 tag is capped at 0xFFFF. Any attempt to increment the counter which has 0xFFFF as value gives an error response. Documentation of SLIX2 did not explain this.

JS

[Psi]

Just found that the READ password is different per TAG.
Looks like dymo followed the application note from NXP to use "dynamic passwords" derived from UID.
=> Labels in shops are safe. Nobody can invalidate (use) them. Also the "destroy" command has its own password (per tag for sure) which we don't know...

Ok, so they're not totally stupid then.

I've never really looked into NFC. Out of interest, if they had used the same password for each tag.
What sort of physical distance would you need to zero all the labels in big stack of pallets?
Assuming you had all the right equipment could someone have parked a van outside an amazon warehouse and cleared all the labels inside? Or would you need to get within 10m or so even with the best RF setup possible?

[mikeselectricstuff]

Just found that the READ password is different per TAG.
Looks like dymo followed the application note from NXP to use "dynamic passwords" derived from UID.
=> Labels in shops are safe. Nobody can invalidate (use) them. Also the "destroy" command has its own password (per tag for sure) which we don't know...

Ok, so they're not totally stupid then.

I've never really looked into NFC. Out of interest, if they had used the same password for each tag.
What sort of physical distance would you need to zero all the labels in big stack of pallets?
Assuming you had all the right equipment could someone have parked a van outside an amazon warehouse and cleared all the labels inside? Or would you need to get within 10m or so even with the best RF setup possible?

the inverse square law limits how far you could do anything, even with a lot of tx power - anything over about 1m would be impractical

[mistial_dev]

Finished some more tests.

The counter in SLIX2 tag is capped at 0xFFFF.

Yes, it would be.

Documentation of SLIX2 did not explain this.

It's a 16 bit counter, intended for consumption ("service cycle") tracking and similar.  If it rolled over, it would not be useful for that purpose.

If you read in 9.5.3.21, it describes the available options: read, increased by one, and reset to preset value with write.

If it rolled over from 0xFFFF to 0x0000, it wouldn't be an increment by one.  It would be a decrement by 65535.

There is technically a 3rd byte in the block, where it could continue increasing.  That value is listed as RFU, however, in the documentation.

[js_12345678_55AA]

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

I measured the pitch to be 1.5mm which is identical to "JST ZH 6pin"
Unfortunately this is incorrect. JST ZH is still to big.


JS


BTW: I found the 6th pin meaning. It is "PDOWN" which has a pull up. When PDOWN is connected to GND then the reader IC is starting operation. PDOWN not connected or +3.3V then reader IC is powering down.

I also found a quick way to soft-reset the reader IC (tag connection) to speed up something like trying passwords:
when you
- send 0x00,0x80   (command_reg,power down flag set)
- wait 50 msec
- send 0x00,0x00   (command_reg,power down flag cleared)
then you do not have to send the long reader initialization sequence (programing all registers and protocol selection) and just can transceive the next commands to the tag (get random + set password  for next try).

Still with only 10 tries per second, guessing the 32 bit write password could take some time (>6 years). But for sure this can be speed up a lot... Only caveat, write password is most likely different per tag

[mistial_dev]

I'm not too worried about the password at this point.  It looks like it is handled by the NFC chip, not the MCU, so I think it can largely be ignored if that chip is emulated.

My plan right now is to just have a BLE chip and an app where you can pick the SKU for the inserted media.  Since third party media won't have a RFID chip, that information will have to come from a database of some sort.  USB is simpler to implement, but requires physical modification to the case.

[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...

Not all that hard. I've been researching custom (UHF) RFID tags.. all you need is a diode receiver and an antenna switch.

These tags communicate with backscatter (far-field, UHF) or load modulation (inductive, 13.56MHz). The reader>label comunnicates by sending a carrier signal with ASK modulation (the NXP chips says a depth of 20-30%, or optionally 100%). The tag harvests energy from this carrier signal to power up, so 100% won't be used for passive tags. The label>reader communicates by shorting it's antenna or coil connection, which the reader can sense and demodulate the transmitted data.

The bitrate at which this happens is only in the order of kbps. These RFID tags only contain a few dozen bytes, maybe 256 for large tags, so it doesn't take long to read them.
The protocol is probably the tougher issue. I'm not sure what the NXP NFC tags use, or if it's proprietary. For UHF RFID tags most commonly EPCgen2 is used. It's quite an extensive standard, and also not really a mainstream industry to work on the tag side of things.. so probably requires a lot of investment to get a small result on the software part.

I am reminded of these:

https://hackaday.com/2009/06/27/avr-rfid-tag/

https://hackaday.com/2011/09/26/barebones-pic-rfid-tag/

https://hackaday.com/2018/01/05/attiny-chip-abused-in-rfid-application/

Those are all 125kHz, but here's a 13.56MHz one:

https://hackaday.com/2013/11/14/a-diy-nfc-tag/

The IC used in the Dymo is ISO 15693 protocol, which is different from those above, but I suspect based on the existence of the last one, it should be emulatable.

[mistial_dev]

That would work, too.

I'm ripping out the whole NFC board and replacing it with an NFC IC emulator.  The advantage to that is that you don't actually need a tag at all, and can skip RF entirely.

[js_12345678_55AA]

What IC to use for the I2C emulator...

Looking on availability of ICs and reproducability for others I'm looking at Arduino libraries (even that I don't like them).
There are I2C slave libs available which can be used on almost all platforms (AVR,STM32,ESP32,...)

Suggestions?

[Julius]

Get it working on Arduino and everybody will be able to port to their favorite IC.

[Monkeh]

What IC to use for the I2C emulator...

One you can actually buy.

[EEVblog]

FYI, amazon said on twitter they would do something about it and a few hours later a ton of old reviews have been removed.

[mistial_dev]

What IC to use for the I2C emulator...

Looking on availability of ICs and reproducability for others I'm looking at Arduino libraries (even that I don't like them).
There are I2C slave libs available which can be used on almost all platforms (AVR,STM32,ESP32,...)

Suggestions?

CY8CKIT-059 if you want USB.  CY8CKIT-042-BLE-A if you want BLE.

[sleemanj]

FYI, amazon said on twitter they would do something about it and a few hours later a ton of old reviews have been removed.

Probably only from that specific listing you had, where as this was the first one I got when googling for "amazon labelwriter 550" and has 7.4k reviews dating back years.

https://www.amazon.com/DYMO-Label-Printer-LabelWriter-Thermal/dp/B08TLRL392/ref=cm_cr_arp_d_product_top?ie=UTF8&th=1

[GopherT]

Looks like someone was fired over this...
Demo is looking for a new Product Manager/Brand Manager.

https://careers.newellbrands.com/us/en/job/2200802/Product-Manager-Brand-Manager-DYMO

[ygi]

Looks like someone was fired over this...
Demo is looking for a new Product Manager/Brand Manager.

https://careers.newellbrands.com/us/en/job/2200802/Product-Manager-Brand-Manager-DYMO

If someone got fired/quit it had to be because they were the one person in the company opposed to that stupid cash grab. No corporate drone's ever been fired for being too greedy on behalf of their employer.

[DynoDrmBeGone]

Just noticed something and hope it might help in figuring a way to defeat this insane DRM protection...
When I'm printing labels from my MacBook pro M1 it tends to print an empty lable after the original print... However if u unplug the USB cable from my Mac directly after the first lable is done printing, the empty lable isn't generated, but even better if I cancel the print job without the USB cable and reconnect the printer the lable count isn't decremented so you can print without decreasing or incrementing the nfc counter and it will still accept to print the next lable afterwards... I now have an empty roll wit 32 prints left

[mikeselectricstuff]

If there is a significant delay between it reading and writing the RFID tag, maybe a possible approach is to jam the signal with an external (modulated) 13.56MHz source to block the write.

[DynoDrmBeGone]

Wouldn't it theoretically be possible to create a write locked NFC tag, with the expected Dymo data on to it? Than the printer can do it's roll type detection, thinks it's already used for some prints so it doesn't have to do any initialisation (if it even does that on the first print) and simple can't decremented the counter?

[apelly]

Demo is looking for a new Product Manager/Brand Manager.

https://careers.newellbrands.com/us/en/job/2200802/Product-Manager-Brand-Manager-DYMO

From that page:

Join us and benefit from:

    4Ts Values: Truth, Transparency, Teamwork, Trust
    Corporate Citizenship Philosophies – environmentally sustainable and socially sensitive business practices.

[js_12345678_55AA]

Looks like all those Arduino libraries do not support I2C slave very well 

I tried ESP32, STM32 (we need a 3.3V MCU).

Next best thing would be to use native STM32 for emulation (stm32 blue pill boards seem to be available everywhere, even boards with cloned STM32 should work)

JS

BTW: The mentioned "CY8CKIT" Infineon IC / board is expensive and ICs are not available as far as I can see. Any particular reason why this was suggested?

[mistial_dev]

BTW: The mentioned "CY8CKIT" Infineon IC / board is expensive and ICs are not available as far as I can see. Any particular reason why this was suggested?

The cy8ckit-059 has apparently had a price increase.

They used to be $10, which was a great value for the chips you get with it.  Looks like infineon has hiked things a bit.

https://www.reddit.com/r/PSoC/comments/360r4p/10_for_cy8ckit059_has_cypress_psoc_5lp_target/

They still have some really nice i2c support, though, and it is very easy to work with.

https://www.infineon.com/dgdl/Infineon-Component_I2C_V3.30-Software+Module+Datasheets-v03_05-EN.pdf?fileId=8ac78c8c7d0d8da4017d0e9599661ff4

The biggest advantage with cypress is that as long as you are doing something that's officially supported, the libraries/tools/etc. you need are all first party, and tend to be fairly top notch.

The disadvantage is when you want to go beyond what's officially supported.  The tooling stops helping you and starts fighting you.

[js_12345678_55AA]

I decided to use a STM32F103 since they are (still) available for reasonable prices from various sources. Anything like a "blue pill" will work.

And..... IT IS WORKING! 

Full emulation of the reader IC + tag as a standard CubeMX project.
Whenever the roll is changed or the printer enters power down mode the counter is "REFRESHED"

Next step... I additionally interface the original reader so change of paper types is easy (just hold a tag of the paper type you want to use to the side of the printer and the emulator will "LEARN" it).


JS

[mistial_dev]

That’s smarter than what I was planning.

If you are planning on releasing, I’ll stop working on mine.

[mikeselectricstuff]

Next step... I additionally interface the original reader so change of paper types is easy (just hold a tag of the paper type you want to use to the side of the printer and the emulator will "LEARN" it).

...but that assumes you've already bought some of the original expensive labels...

[mistial_dev]

Or have cloned the tag to a card.

[Bud]

That’s smarter than what I was planning.

If you are planning on releasing, I’ll stop working on mine.

Please do not, we need diversity. 

[EEVblog]

I decided to use a STM32F103 since they are (still) available for reasonable prices from various sources. Anything like a "blue pill" will work.

And..... IT IS WORKING! 

Full emulation of the reader IC + tag as a standard CubeMX project.
Whenever the roll is changed or the printer enters power down mode the counter is "REFRESHED"

Next step... I additionally interface the original reader so change of paper types is easy (just hold a tag of the paper type you want to use to the side of the printer and the emulator will "LEARN" it).

 

A DIP switch maybe?
Most people stick with the same roll in the sme machine all the time, and there are mostly only a coulple of major label sizes people use.

[js_12345678_55AA]

Thanks for the suggestions...

The emulation contains "learned" labels already, and if you use it like I do (multiple rolls per day all of the same type) then this is just enough.

Switching between rolls can be done using either another original roll (which is then learned) or by using a simple of the shelf NDEF Tag where you just write the SKU of the roll (e.g. "S0722430") inside (like you do with business card information, any phone can do this nowadays).
So by presenting either an original roll the complete data is learned, or by presenting a normal RFID NDEF tag with the SKU inside to choose from the pre installed tags is enough to switch between rolls.
This makes it possible to modify the printer once and then no need to open again in order to switch roll types.

Meanwhile I also created a small Android app which can be used to dump the complete SLIX2 tag (including the "signature" data).

I will setup a github project in the next few days with all the sources.
(As soon as github outtage is over: https://www.githubstatus.com )


On the other hand I learned about a very beautiful (and available) NXP IC today. A friend suggested to have a look at the NHS3100 IC.
https://www.nxp.com/docs/en/data-sheet/NHS3100.pdf

Ignore the "temperature logging" in the title... and have a look at chapter "8.10 RFID/NFC communication unit"
This IC is a CortexM0 which can speak the correct NFC protocol...
This makes it possible to completely emulate a SLIX2 tag with a "magic counter":

The IC is (including inflated pricing) $4:
https://www.digikey.com/en/products/detail/nxp-usa-inc/NHS3100-A1Z/6578221

A completely working development board (which should be usable as magic tag) is availbale for $60 (Will pay itself after using only 4 off-brand rolls )
https://www.digikey.com/en/products/detail/nxp-usa-inc/NHS3100TEMODBUL/6578223

And I really like the idea to fight NXP with NXP 

Looks like the UID is fixed so this can not be used 

JS

[js_12345678_55AA]

The first release is an Android utility application which can be used to dump the complete content of SLIX2 tags:

https://github.com/free-dmo/free-dmo-tag-dump

You just start the app, hold it near the paper roll to scan it and it will show the complete dump.
It also will create a text file per dump in the "Downloads" folder.

It comes with full source code but also contains a pre compiled APK for "lazy" people (BUT: You really should NEVER EVER download APKs from somewhere and install them to your main Android device... Go the extra mile and check the source then compile it yourself!).

@ALL: It would be nice if you could use the app to scan some of your rolls (doesn't matter if consumed or fresh). Please copy/paste the content of the text file and post them here.


The difference of the raw dump compared to the output of other NFC apps is that it contains extra information like the Originality Signature from SLIX2 tags (which we need for a complete emulation).

JS

Attached are my 2 rolls. One is the small roll which comes with the printer the other one is SKU "S0722430" (54mm x 101mm |  2 1/8 x 4 inch)

EDIT: One more roll attached.

Anybody else please?

[js_12345678_55AA]

It's done...

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

- full emulation for "endless" printing
- optional pass through of original RFID tag data (only the counter will be emulated)

JS

[mistial_dev]

Please do not, we need diversity. 

Plenty of things to hack out there.  I can do something else

[mistial_dev]

Here ya go.  4x6 inch, or 104x159mm.  Standard shipping size.

[SkullKill]

#FREEDMO GETS RID OF DYMO LABEL PRINTER DRM

https://hackaday.com/2022/03/30/freedmo-gets-rid-of-dymo-label-printer-drm/

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

[tooki]

#FREEDMO GETS RID OF DYMO LABEL PRINTER DRM

https://hackaday.com/2022/03/30/freedmo-gets-rid-of-dymo-label-printer-drm/

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

Yyyyyeah, we know, since the developer of that is a forum member and documented his progress in this thread.

[SaltyDog]

Can someone please dump a 1x1" tag? I will dump mine, when it comes in, and if no one posts.

[EEVblog]

Louis did a follow-up, and I agree. The hack, whilst  worthy isn't going to make a difference I'm afraid.
Those that have the motiviation/ability to do the hardware hack are those who have the motivation never to use Dymo again for this. Almost all business customers will just continue to buy the genuine Dymo labels.
We need to hit Dymo hard now or every other manufacturer will see that they succeeded and they will try the same thing. We do this buy having an active anti-Dymo campaign and refusing to use their products and buying their competitors (I recommend Zebra). Keeping on top of the fake Amazon reviews and the like etc and help grow the new organic 1 star reviews. Eventually it has to hit Dymo where it hurts.

[EEVblog]

And for those that want an alternative to the Dymo label software, and have support for countless printers including the old Dymos, I've been talking to the author of this software:
https://label.live/
He's also close to releasing his own printer as well.

[tooki]

And for those that want an alternative to the Dymo label software, and have support for countless printers including the old Dymos, I've been talking to the author of this software:
https://label.live/
He's also close to releasing his own printer as well.

Looks like a nice app! Do you know whether it will support thermal transfer printers? For durability (both against abrasion as well as against fading in long-term storage or staining due to chemical exposure) they’re practically mandatory.

I’d also love to see it support laminated labels like the Brother p-touch.

[mistial_dev]

And here's 2.25 in x4 in.

[okdc]

I attempted this with the compiled firmware from github and can't seem to get it to work on my 5XL. Any pointers? I appreciate any and all help. I've never worked with a stm32, really only ever toyed with arduino. I flashed the stm32 with a uart and with st-link. Same results. I'm on windows, so compiling isn't as simple as it should be, was trying to avoid making this any more difficult than it already is. Do I need to flash this with linux? I've double checked my solder job and I was actually quite pleased with my work, so I really don't think it's that. The color order was different, but I made sure they all matched up.

The dymo software detects the label properly for about a second and then it returns to unknown label detected.  I've also tried using the reader with the rfid off the roll that came with printer. No change.

The printer power light just flashes like it can't detect anything.

[wraper]

What are those parts with black blobs? Do not look like usual resistors which are needed. Look more like thermistors.

[js_12345678_55AA]

@okdc:

In the pictures it looks like the 2 yellow BOOT jumpers are still both at the "1" position.
This will let the device always enter it's bootloader and the firmware is never run.

=> After flashing the firmware put the boot jumper back to the normal "0" position.

Have a look here:

https://circuitdigest.com/sites/default/files/inlineimages/u/STM32-Operating-and-Programming-Mode.jpg

JS

[okdc]

Thanks for the replies, yes it's a thermistor, it's what I had on hand. I've ordered standard resistors and they'll arrive tomorrow.

Here is what I'm experiencing. I went in programming mode and flashed the pre-compiled firmware using the STM32CubeProgrammer application. I put it back into operating mode and then gave it a go.

Here is a video of the results.
https://photos.app.goo.gl/PuknEDYjVevKyaZ18

Should I remove the reader just to rule that out? Your help is greatly appreciated!

[js_12345678_55AA]

Here is what I'm experiencing. I went in programming mode and flashed the pre-compiled firmware using the STM32CubeProgrammer application. I put it back into operating mode and then gave it a go.
Here is a video of the results.https://photos.app.goo.gl/PuknEDYjVevKyaZ18

The video shows that the printer did not communicate with the STM32 properly. You should observe the same behaviour when you unplug the STM32 completely.

Should I remove the reader just to rule that out? Your help is greatly appreciated!

You can remove the RFID board connection for troubleshooting. The emulation works without RFID board attached.

The emulation will set SKU S0722430  (54 mm x 101 mm / 2.125 in x 4 in / 220 pcs). The PC software should show this.

Questions:

There is a second LED on the blue pill pcb (labeled PC13) which should blink whenever the printer sends something to the STM32.
=> Do you see this LED blinking at all (should blink several times after printer is started / woken up from power save)?

[okdc]

I removed the reader and sured up my solder job. There wasn't any change, also no blinky.  Reflashed it, still no change. I feel like I'm missing something simple here. I've ensured the STM32 is in operating mode.

Update:

Just for the heck of it, I tried a new STM32 and a new Dymo 5XL. Same results. I only ever get a solid power LED, even when the printer isn't "on" and the printer is in sleep mode.

[SaltyDog]

I am having the same issue with the 550... Just a solid red light.

[SaltyDog]

Could it be because I used a STM32F103C6T6? Are you using more than one i2c port?

[js_12345678_55AA]

Could it be because I used a STM32F103C6T6? Are you using more than one i2c port?

The STM32F103C6T6 is a different MCU which only has half of the RAM, half of FLASH and most problematic, only ONE I2C port (the project uses two).
==> This CAN NOT WORK.

However, the complete source and .ioc file is available in the github repo, so you can change the MCU in ST's "STM32CubeMX" software, generate the code, *REMOVE* the second I2C (which is used to connect to the original RFID board) and just create a custom version for your MCU with emulation only.

JS

@OKDC: Could you check the MCU soldered to your blue pill? Maybe it is not a "STM32F103C8Tx"

[okdc]

Ughh, seems to be the potential problem. Good catch!

I should have known better than to trust Amazon. This is what was ordered https://www.amazon.com/dp/B09MLHTHRC (Do not buy)
All text in description, title, etc. says STM32F103C8T6 but the photos show what I received (STM32F103C6T6)

Which is a good thing, I guess. I was losing my mind trying to figure out what I did wrong. I had even ordered a Label Writer 550 just to make sure. It'll be here soon.

[js_12345678_55AA]

Hi,

SaltyDog was spotting the C6T6 problem. I just asked you to check if by chance you have the same issue.

Anyway, I added a warning to the github readme to check for correct STM32F103C8T6.

JS

[SaltyDog]

I can confirm that the new boards I ordered, the correct ones worked straight away, without issue Thank you!

[okdc]

Mind linking where you purchased? My new ones don't arrive until sometime next week.

[SaltyDog]

I am sure you will find them cheaper elsewhere, but I wanted them right away.

https://www.amazon.com/HiLetgo-STM32F103C8T6-Minimum-Development-Learning/dp/B07VKSVM21/ref=sr_1_1_sspa?crid=10ECKNKM29581&keywords=stm32f103c8t6&qid=1649905956&sprefix=STM32F103C%2Caps%2C76&sr=8-1-spons&spLa=ZW5jcnlwdGVkUXVhbGlmaWVyPUEzNENXSkMxTTk0UUVIJmVuY3J5cHRlZElkPUEwODkwMTU2MUZaRFlOMTlIUU1WTCZlbmNyeXB0ZWRBZElkPUEwMTE1NTI4M1ZPU1YwU0cySTY4WSZ3aWRnZXROYW1lPXNwX2F0ZiZhY3Rpb249Y2xpY2tSZWRpcmVjdCZkb05vdExvZ0NsaWNrPXRydWU&th=1

[SaltyDog]

I would also like to note that there is no need to mess with the jumper blocks, when you program via STLink.

I prefer this utility. https://www.st.com/en/development-tools/stsw-link004.html

[okdc]

Got it all working when I got the correct blue pill. Thanks so much for everything.

Attached is the FreeDmo TagDump of a 2 5/16 x 4 in (59mm x 104mm) 300 count spool.

Fun fact, I was able to scan the tag without opening the box. Do what you will with that information.

[SirOsis]

Thanks for all your work on this. Ordered my stuff today should have it Friday and hopefully a working printer on Monday!

Would it be possible to disable the capability of the RFID board to write updated values by introducing an open on the voltage line or is that the same voltage that is used to read. Hope that makes sense.

[johnny32]

Pirate Ship supports all LabelWriter 450 models. The Dymo 450 is not as great as the Munbyn thermal labels printer; you can definitely use it with Pirate Ship! Head to Settings > General Settings and change your Label Size to 2x7".

[jonpaul]

We use 450/450 turbo, 450 twin.
Bought some for $5 ea at fleas.

Indeed Zebra printers are the best, but Dymo has adress label correction and USPS barcode

Jon

[jonpaul]

The older model Turbo/450/twin have no DRM or RFID and work fine with clone labels as long as the registration hole is good.

We find these at garage sales, fleas, etc for $5,,25,

550 is hardly worth the effort!

j

[abefroman]

How is everyone mounting the blue pill when everything is programmed correctly? 

[Darxtek]

OK I’m not the biggest programmer or flasher, but I’m stuck at this part I can’t seem to get the matching pins , and my colors are off lol.
Can anyone help.


Soooo close!

[js_12345678_55AA]

OK I’m not the biggest programmer or flasher, but I’m stuck at this part I can’t seem to get the matching pins , and my colors are off lol.
Can anyone help.

What are you trying to do? All the definitions and code is available for STM32F103C8 already. The Pinout definition would only be needed if you want to port it to another STM32 variant.
There are even pre compiled binaries of the firmware available which you just need to flash:

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

Scroll down and read the instrcutions, look at "Firmware" => use "option 3" and download a pre compiled firmware, then follow the steps outlined under "Download the firmware to the STM32F103 bluepill board"

JS

[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.