Reverse Engineering the TMS 220 Miele Payment System

The TMS 220 is a payment system used in Miele washing machines and dryers. It's a simple device that allows users to pay for laundry cycles using so-called "Touch" devices. These devices are essentially iButtons (sold for 40 bucks btw) that can be loaded with credit and used to pay for laundry cycles.

As the payment device is completely independent (not connected via GSM or whatever), I was curious to see how it works and if I could reverse-engineer it. I happened to have just bought a Flipper Zero, which is basically a Swiss Army knife for nerds, and it seemed like the perfect device for the job as it supports iButton reading, writing, and emulation.

Touch Device

The Touch device is a small iButton in a plastic holder. Underneath the plastic, there's a DS1992 iButton, which is a 1-wire device with 1Kb (128 bytes) of NVRAM. The device is powered by the reader, which provides power through the 1-wire interface.

It provides 4 pages of 32 bytes each, with an additional 32 bytes scratchpad (used for checking the data before actually writing it).

There are also 8 bytes of ROM that hold the following information:

The 128 bytes of NVRAM were likely used to store the balance and other information about the user. This was the part I was most interested in, as I wanted to see if I could read and write the balance.

Reverse Engineering

Getting into the actual reverse engineering, I started by reading the iButton with the Flipper Zero. The Flipper Zero has a built-in iButton reader, so it was as simple as putting the iButton on the reader and pressing a button. The Flipper Zero then displayed the contents of the iButton, which I saved on the SD card for later analysis.

The following dump was obtained from the iButton:

┌────────┬─────────────────────┬─────────────────────┬──────────┬──────────┐
│00000000│ 20c3 b108 01c2 8711 ┊ 0f3e 0724 c399 c2bf │  ×ו•×ו ┊ •>•$×××× │
│00000010│ c2b2 23c2 93c3 b8c2 ┊ b551 c3bf 7bc2 8cc2 │ ××#××××× ┊ ×Q××{××× │ 
│00000020│ b84f 001e 1b31 c29d ┊ 7e6e 6f37 c28b 6fc3 │ ×O•••1×× ┊ ~no7××o× │
│00000030│ a213 5e56 1ac2 9803 ┊ c2b9 c38a c3ae 6cc3 │ ו^V•×ו ┊ ××××××l× │
│00000040│ 9923 c2af 1751 c2b5 ┊ c381 c3a2 c3a7 c391 │ ×#×וQ×× ┊ ×××××××× │ 
│00000050│ 32c3 adc2 a073 6359 ┊ c3ae c3b8 0e00 0000 │ 2××××scY ┊ ×××ו••• │ 
│00000060│ 0000 1105 1200 0000 ┊ 454c 4549 4d09 3565 │ •••••••• ┊ ELEIM_5e │ 
│00000070│ c2ac 2b4a 1dc2 b82b ┊ c3ad 0cc3 8b7b 5e6b │ ××+J•××+ ┊ ××_××{^k │ 
│00000080│ 484c 6a26 c389 6ac3 ┊ aac2 adc3 b4c2 9a57 │ HLj&××j× ┊ ×××××××W │ 
│00000090│ c384 54c2 9b05 c2bf ┊ 1800 0000 0000 0000 │ ××T×ו×× ┊ •••••••• │ 
│000000a0│ 0000 0000 0000 0000 ┊ 00                  │ •••••••• ┊ •        │ 
└────────┴─────────────────────┴─────────────────────┴──────────┴──────────┘

We immediately notice the ELEIM string, which is just MIELE reversed. This tells us that the iButton NVRAM is (likely) not encrypted, as the string is stored in plain text.

At the time of this dump, there was no balance on this iButton, so it was near impossible to determine where the balance was stored. We needed another dump with an amount on it to perform a differential analysis.

Getting another dump

TODO