Forum: Offtopic Thermomix Rezeptchips

Sigma P. schrieb:
> I successfully emulated the ARM926EJ-S processor (processor from TM5)
> with Qemu.

Hey Sigma,

can you please give us a short introduction how to load the image with 
QEMU?




Thanks
David

Ikaro P. schrieb:
> Looks like this community is stuck, so I have decided to give us all a
> little present.
>
> EiOJeNLiooqwWobaVDVrbJWLCifvQC5oDqNqHfuSYBt3y4vwN3YKq2EsvFK3U4M9
> (AES128)

Findet sich übrigens in /opt/cookey.txt

David N. schrieb:
> Hey Sigma,
>
> can you please give us a short introduction how to load the image with
> QEMU?
>
> Thanks
> David

You need a working install of QEmu.
Then you can download prebuild images (linux + debian squeeze) and you 
run it with the given command line.

Then, access through ssh.

Next step, I will install a gdb server on the emulated system so I will 
be able to debug binaries from my host with any comaptible tool.

Different approach: man-in-the-middle attack with the cookkey to sniff 
the wifi traffic.

- Is this possible with the given certificates under /tmp/certificates 
or the /opt/cookey.txt file?
- Or do we need a certificate from our own Thermomix?
- another idea is to find any code in the image, where the cookey date 
gets processed

Noch ein Ansatz wäre, etwas mit dem Key in der /opt/cookey.txt zu 
entschlüsseln. Dafür habe ich mal in allen Dateien nach "cookey.txt" 
gesucht. In der Datei /usr/sbin/netlink habe ich folgenden Code 
gefunden. Könnte der dafür genutzt werden, um die Daten des USB-Sticks 
der sich im Cookkey befindet zu entschlüsseln?

1

------------ Power-cycling USB interface ----------

2

/etc/rc.d/init.d/usbpower stop

3

/etc/rc.d/init.d/usbpower start

4

mkdir -p /tmp/dev/

5

mknod /tmp/dev/ttyACM0 c 166 0

6

/usr/sbin/eth stop

7

settings_cloud.sdb material/photo/150x150/vorwerk_trademark_logo.png

8

umount -f

9

losetup -d

10

rm -f

11

rmdir

12

/usr/sbin/eth start

13

mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ mkfs.ext4

14

tcsetattr usbTermio /sys/ /idVendor i j q u z rm -f /tmp/dev/ sd /../../../../../../../serial sr s.+(\d+) sd([a-z])\d+

15

mknod -m 644 /tmp/dev/loop b 7

16

mknod -m 644 /tmp/dev/ b 11 b 8

17

mkdir -p

18

losetup -e aes128 -P /opt/cookey.txt

19

mount -o ro

20

mount

Da scheint ja bei vielen Zeilen etwas zu fehlen. Als ob dies der "linke 
Teil" eines Skriptes währe und der "recht Teil" fehlt. (Z.b. "rm -f" 
ohne Argument macht keinen Sinn)

Die relevante Zeile "losetup -e aes128 -P /opt/cookey.txt" ist auch 
nicht komplett. Falls wir annehmen das was dasteht richtig ist und nur 
rechts was fehlt dann währe der /opt/cookey.txt nur ein device 
identifier und nicht der geheime Schlüssel.

Eventuell hast du da einen Textblock gefunden der vom Programm noch 
verändert wird bevor er ausgeführt wird?

Chris R. schrieb:
> Noch ein Ansatz wäre, etwas mit dem Key in der /opt/cookey.txt zu
> entschlüsseln. Dafür habe ich mal in allen Dateien nach "cookey.txt"
> gesucht. In der Datei /usr/sbin/netlink habe ich folgenden Code
> gefunden. Könnte der dafür genutzt werden, um die Daten des USB-Sticks
> der sich im Cookkey befindet zu entschlüsseln?
>
>

1

> ------------ Power-cycling USB interface ----------

2

> /etc/rc.d/init.d/usbpower stop

3

> /etc/rc.d/init.d/usbpower start

4

> mkdir -p /tmp/dev/

5

> mknod /tmp/dev/ttyACM0 c 166 0

6

> /usr/sbin/eth stop

7

> settings_cloud.sdb material/photo/150x150/vorwerk_trademark_logo.png

8

> umount -f

9

> losetup -d

10

> rm -f

11

> rmdir

12

> /usr/sbin/eth start

13

> mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ 

14

> mkfs.ext4

15

> tcsetattr usbTermio /sys/ /idVendor i j q u z rm -f /tmp/dev/ sd 

16

> /../../../../../../../serial sr s.+(\d+) sd([a-z])\d+

17

> mknod -m 644 /tmp/dev/loop b 7

18

> mknod -m 644 /tmp/dev/ b 11 b 8

19

> mkdir -p

20

> losetup -e aes128 -P /opt/cookey.txt

21

> mount -o ro

22

> mount

23

>

netlink is a binary. All these strings are used in the binary.
There may be no link between these strings depending on how they are 
used inside the binary.

A also started to analyse this binay.

I have a lot of difficulties to debug the binary in my qemu system.
So I will continue static analysis.

Note: It would be great if you can speak english

If the static analysis gets too involved it might be an idea to have the 
program do its thing and observe it on the way.

I can think of two things:
- Use strace (with -f) to get the calls the program makes to other 
programs (mentioned as "execve" in the strace output). This would 
require a strace program on the platform. If that is not there one might 
need to get it from a compatible system.
- My tests with strace (on a desktop linux system) showed that the 
subprogram to be called is not invoked directly, but rather through a 
call to /bin/sh. That means one could create a program/script (placed in 
the old location of /bin/sh) that logs the call to a file before the 
(renamed) real /bin/sh is called. (There is a potential for a big 
problem here, if the logging or calling the original sh needs to call 
/bin/sh we just created a recursion. One would need to try this.)

The whole process will probably be a bit involved since the netlink 
binary certainly will check some conditions before the actual losetup 
call is made. One would need to make sure that these are fulfilled one 
by one.

Hi,

I thin we found something very interesting here. It should give us a 
hint how the Chips data is decrypted by the software.

I'm not a Pro when it comes to that things, but the first readable 
String in the binary is "ELF". i know .elf files from AVR-GCC it 
descripes how to link and build things.

From the Wiki article one can further notice that this is definitly an 
elf-File. Magic Number is 0x7F followed by ELF. So we should be able to 
processes and anaylse this file using one of the Tools mentioned in the 
article.

https://en.wikipedia.org/wiki/Executable_and_Linkable_Format

What I found out with a Hex Editor:
data size: 32bit
endiness: little endian
ELF Version: original version of ELF
target System: systemV ?
Version: 0
type: executable
target architecture: ARM
...

the rest is to much for my electricians brain :) need a software guy.

Cu
David

The code I found in /usr/sbin/netlink is of course not usable. But I 
thought to post it, because it reveals details about how to mount the 
encrypted Cook-Key. But I don't have the skill to mount the encrypted 
image. There is a file called "tm5.img" on the Cook-Key as written in

1

mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ mkfs.ext4

But how do I work with it? cryptsetup & mount & ... ?!

Also ich habe übermorgen eine Vertreterin zu besuch - hatte ernsthaftes 
Interesse - bis ich gerade auf das Problem (welches eigentlich keines 
sein dürfte) eigenes Rezept gestoßen bin.

Das naheliegenste (Familien und Lieblingsrezepte) einzuspielen ist nicht 
möglich???? ernsthaft?? warum? gelinggarantie? so what??

Ganz ehrlich, ich würde mir so n Ding zu dem preis (Produktionswert ca 
200€) schon Kaufen, wenn auch überteuert, weil die Qallität sehr gut 
ist, aber das iphone war das letzte Gerät welches mich als Kunde 
Kastriert hat.

Wer Kunden daran hindert das System technisch voll auszunutzen (eigene 
Rezepte/kein root iphone) stattdessen mit Abos / Einschränkungen und 
unverhältnismäßiger Kryptografie Ihre Kunden an die Leine nimmt, den 
werde ich aus Prinzip nicht unterstützen.

Dann hätten die auch n eigenes Betriebssystem schreiben müssen und nicht 
auf freie Software zurückzugreifen (Linux).

Hätte ich nicht schon die Zutaten gekauft, würde ich der Termomix 
Vertreterin Absagen.

Ich hoffe Ihr bekommt das System ent-kastriert, kaufen würde ich ihn mir 
aber auch dann nicht, nicht weil ich gegen Patentrechte verstoßen, 
sondern damit eine Firmenpolitik unterstützen würde, die in meinen Augen 
total in die falsche Richtung läuft.

Chris R. schrieb:
> Ikaro Psi, great work!! Thank you!
>
> How can we get the image from our TM5 ourselves?? This would help the
> most!

I'm sorry but I will not reveal the exploit since that would make the 
vendor issue an firmware update with the fix and most probably close any 
realistic homebrew development of the platform. And even in the case I 
discover a proper "unfixable" rooting method in the future (e.g. 
something like finding the usable firmware signing key), I would still 
need to inform the vendor first.

I have somewhat full root access to the platform but I don't think one 
needs to have that for the work on a homebrew. Vast majority of the 
fiddling can and should be done in an emulator, the platform itself is a 
minefield anyway and one could destroy his TM with just a stupid little 
typo. It might seem a bit protective stand but I will hold it for now.

> Different approach: man-in-the-middle attack with the cookkey to sniff
> the wifi traffic.

> - Is this possible with the given certificates under /tmp/certificates
> or the /opt/cookey.txt file?
> - Or do we need a certificate from our own Thermomix?

Sadly this is not possible for two reasons now:
- the process of registration of the TM to the online system is probably 
the way the per device client certificate is issued and I think that one 
is used most of the time.
- TM strictly enforces the verification of the server certificate. 
Public CA system is not used and the only certificates accepted must 
stem from Vorwerk's internal CA.

I hope we would be able to run the GUI and the netlink parts in the 
emulator with replaced CA certificates so the (not so much now) MitM 
attack would be possible. We could reverse engineer the protocol and 
than develop a custom server using the specificiation created (clean 
room). Since one need to replace the CA certificat on TM for this to 
work and since there is no easy way of doing this, my afford is focused 
in this direction mostly now.

> The whole process will probably be a bit involved since the netlink
> binary certainly will check some conditions before the actual losetup
> call is made.

I'm pretty sure netlink is just inserting the correct device filename 
and all the magic is done either by patched losetup or patched kernel 
itself. I was unable to decrypt any image even by using TM's losetup 
binary in my emulator, it's a big mind=boogle...

I'm looking forward to the static analysis findings... I hoped someone 
here would be able and willing to do it, since I prefer not to touch 
tools like IDA ever again :))

> There are a lot of interesting things but the most important one is the
> binary /user/sbin/checkimg.

That one is used in an update process, since distributed firmware is 
encrypted with a static global key but to flash it one need to encrypt 
it using device specific keys and also since the update package can have 
some preupdate and postupdate payloads and hooks ect.

Sigma P. schrieb:
> David N. schrieb:
>> Hey Sigma,
>>
>> can you please give us a short introduction how to load the image with
>> QEMU?
>>
>> Thanks
>> David
>
> You need a working install of QEmu.
> Then you can download prebuild images (linux + debian squeeze) and you
> run it with the given command line.

Which command line? I'd love to give that QEMU approach a try as well, 
but I've never used QEMU before. Would someone please give more detailed 
instructions on how to access a QEMU environment with this firmware?
I'm sure there's more people who would appreciate this.

I've had a quick first look at the firmware files. Very interesting, 
fantastic job, Ikaro Psi.

Here's a few little things I realized that might be somewhat 
interesting, but that nobody hasn't mentioned yet:
1) There is no password set for the "root" user in /etc/shadow. If one 
would somehow get to a login prompt, the password for the root user 
should be a simple [ENTER]

2) There are a few sqlite3 database files with the file suffix .sdb in 
the opt/Thermomix directory:
contact.sdb
settings_cloud_default.sdb
settings_empty_en.sdb
settings_empty_tw.sdb
subscription_empty.sdb
subscription.sdb

No recipes seem to be stored in these files though. The most interesting 
information I could find in these files were the following tables:
Table "settingsCloudApp" in file "settings_cloud_default.sdb":

1

id|remoteAddress|TCPPort|remotePath|pingAddress

2

1|css.tmecosys.com|443|/ws|l.root-servers.net

which suggests URL https://css.tmecosys.com:443/ws

Table "settingsCloudAppDebug" in file "settings_cloud_default.sdb":

1

id|mac|ssn|serial|version

2

1|AABBCCDDEEFF|0123456789ABCDEF|00000000000000000|203801010000

Table "settingsCloudApp" in "settings_empty_en.sdb":

1

id|remoteAddress|TCPPort|remotePath

2

1|css.tmdesync.com|3080|/ws.ashx

which suggests URL https?://css.tmdesync.com:3080/ws.ashx

Simply entering these URLs in a webbrowser is not successful though; the 
first URL responds with a "403 Forbidden", the second one doesn't seem 
to respond at all.

3) As I get it, the ARM seems to communicate with some microcontroller 
via the serial line /dev/ttySP0 at 38400 bps:

1

(file opt/common.sh)

2

3

mc_configure_stty() {

4

    # configure serial port to similiar values that libntm does, but before GUI is started

5

    stty -F /dev/ttySP0 -icrnl -ixon -opost -onlcr -isig -icanon -iexten -echo 38400

6

}

7

8

mc_turn_off_shutdown_timer() {

9

    # set shutdown timer to 15min. (0xFFFF) to

10

    # prevent shutdown after killing GUI app by force

11

    echo -e -n "\x55\x03\x10\xFF\xFF\x8C" > /dev/ttySP0

12

}

13

14

mc_keep_alive() {

15

    # sends heart-beat packet to MC

16

    echo -ne "\x55\x08\x30\x50\x06\x50\x06\x10\x00\x00\xB8" > /dev/ttySP0

17

}

18

19

mc_reset() {

20

    # resets the MC

21

    echo -e -n "\x55\x01\x11\xFD" > /dev/ttySP0

22

}

> I'm pretty sure netlink is just inserting the correct device filename
> and all the magic is done either by patched losetup or patched kernel
> itself. I was unable to decrypt any image even by using TM's losetup
> binary in my emulator, it's a big mind=boogle...

If it's the case, do you have a idea how to continue.

> since I prefer not to touch tools like IDA ever again :))

Why, IDA Pro is perfect for that.


> Which command line? I'd love to give that QEMU approach a try as well,
> but I've never used QEMU before. Would someone please give more detailed
> instructions on how to access a QEMU environment with this firmware?
> I'm sure there's more people who would appreciate this.

I tested on Ubuntu.
Install Qemu: sudo apt-get install qemu-system

Dwnload the 3 following images on :
debian_squeeze_armel_standard.qcow2
initrd.img-2.6.32-5-versatile
vmlinuz-2.6.32-5-versatile

Run QEmu with command line:
qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile 
-initrd initrd.img-2.6.32-5-versatile -hda 
debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1" -redir 
tcp:2200::22

Then connect through SSH with:
ssh user@localhost -p 2200

User account:   user
User password:  user
(Root password:  root)

You can see VM output by using a VNC viewer (https://www.realvnc.com for 
example) on port 5900 (for me).

You can send binaries you want to execute through SSH (scp command).

Have fun!


Ikaro Psi, what analysis do you suggest to do ?
I'm looking to netlink with IDA Pro but maybe you have some better ideas 
not losing time on IDA Pro.

Joachim S. schrieb:
> 3) As I get it, the ARM seems to communicate with some microcontroller
> via the serial line /dev/ttySP0 at 38400 bps:

Where did you find this information?

As I wrote a bit earlier, there is a STM32F100R8 and a ATxmega16D4 on 
the power board. Some pictures[0][1]. The STM32 has also a 2x10 JTAG 
connector next to it.

I assume that your finding is the thermomix applications way to 
communicate with one or both of them.

[0]: 
https://78.media.tumblr.com/f4770bfb4d43e861ebbe6c4b5c7b1d8b/tumblr_oyjxnyog0s1sk4l6uo8_1280.jpg
[1]: 
https://78.media.tumblr.com/f322fccd257abc3ce32bbd0f469cf363/tumblr_oyjxnyog0s1sk4l6uo3_1280.jpg

Edit: attached pics to post.

I attach the images right away.

Moritz M. schrieb:
> Joachim S. schrieb:
>> 3) As I get it, the ARM seems to communicate with some microcontroller
>> via the serial line /dev/ttySP0 at 38400 bps:
>
> Where did you find this information?

In file /opt/common.sh
But it really only contains the commands I mentioned in my previous 
posting. Apparently, the serial communication with these 
microcontrollers is usually handled by "libntm", and common.sh only 
contains those commands that need to be sent via the serial line while 
libntm is not running.

Moritz M. schrieb:
> As I wrote a bit earlier, there is a STM32F100R8 and a ATxmega16D4 on
> the power board. Some pictures[0][1]. The STM32 has also a 2x10 JTAG
> connector next to it.
>
> I assume that your finding is the thermomix applications way to
> communicate with one or both of them.

Very likely indeed. I remember from another thread on hacking the TM31 
(Beitrag "Thermomix TM31 Modifikation") that the previous model 
used a similar approach:
The main CPU sends commands for the actual actions to perform (e.g. Heat 
to temperature X, Make motor rotate left at speed Y) via a serial line 
to a microcontroller on the power board.
It seems like they kept that architecture in the TM5 model, but changed 
the serial protocol.

Sigma P. schrieb:
> Run QEmu with command line:
> qemu-system-arm [...]

Thanks a lot for the instructions, I had a stupid misunderstanding.

To make the process of setting up a working QEMU environment very easy, 
I created a small Linux shell script named tm5.sh (see attachment) that 
might be useful to others. To use it:

1. Download tm5.sh (attachment of this posting) and make it executable 
(chmod 755 tm5.sh)
2. Download the squashfs firmware file, and place it in the same 
directory as tm5.sh, under filename "tm5_firmware.squashfs"
3. Ensure you have the required software packages installed. qemu-system 
is needed (sudo apt-get install qemu-system), I believe all other 
software is installed on most linux systems by default.
4. Run ./tm5.sh. The script will download and create a few files if 
necessary, then start QEMU.
5. Login (Username: root, password: root).
6. The TM5 filesystem is stored in directory /tm5. To chroot into this 
directory, simply enter "tm5_chroot"

> To make the process of setting up a working QEMU environment very easy,
> I created a small Linux shell script named tm5.sh (see attachment) that
> might be useful to others. To use it:

Well done!

On my side, I'm stuck.
It seems that when netlink is called (because a recipe chip has been 
attached), the stick has already been read and netlink check if tm5.img 
is present in tmp.

Then some checks are done. These strings appear:
- Storage partition found at %s (S/N: %s)
- Partition containing recipe DB is found
- Expecting official recipe chip --> perf
- /opt/ref.sig

ref.sig seems to be a public key (not sure at all).

Do you have some ideas ?

Sigma P. schrieb:
>> To make the process of setting up a working QEMU environment very easy,
>> I created a small Linux shell script named tm5.sh (see attachment) that
>> might be useful to others. To use it:
>
> Well done!
>
> On my side, I'm stuck.
> It seems that when netlink is called (because a recipe chip has been
> attached), the stick has already been read and netlink check if tm5.img
> is present in tmp.
>
> Then some checks are done. These strings appear:
> - Storage partition found at %s (S/N: %s)
> - Partition containing recipe DB is found
> - Expecting official recipe chip --> perf
> - /opt/ref.sig
>
> ref.sig seems to be a public key (not sure at all).
>
> Do you have some ideas ?

Hi there, have you seen that there is a global variable that allows 
pirated cookie?
Just check the file on /etc/rc.d/rc.local, they even call it "pirated 
cookie"! :P

# set global variable RDV, which is then read by netlink
# Possible values: 0 - not RDV version, no support for pirated cookie
(EXT4 formatted cookie).
#                  1 - RDV version, no support for pirated cookie.
export RDV=0
echo "Set Recipe Development Version to $RDV"

So if Ikaro_Psi could develop a way that would allow us to change this
global variable, maybe we could use a "pirated cookie"... :)

Why is there a wireless connection already on the firmware? Please check 
the file /usr/local/routerlist.txt:

dlink1 "dlink-8B91" "zubnw96594"

Can it be that the TM5 enters some service mode when it connects to this 
wireless SSID "dlink-8B91" and password "zubnw96594"? Or is this the 
router data from Ikaro_Psi? :/

I do not own a TM5, so I can not test this...

Bimby T. schrieb:
> Hi there, have you seen that there is a global variable that allows
> pirated cookie?
> Just check the file on /etc/rc.d/rc.local, they even call it "pirated
> cookie"! :P
> [...]
> So if Ikaro_Psi could develop a way that would allow us to change this
> global variable, maybe we could use a "pirated cookie"... :)

I stumbled upon that too. But the problem I see is that none of the 
choices  actually allows that pirated cookie being mentioned:
> # Possible values: 0 - not RDV version, no support for pirated cookie
> (EXT4 formatted cookie).
> #                  1 - RDV version, no support for pirated cookie.

And apart from that: What is a "cookie" in this context anyway? Did they 
just misspell "Cook-Key"? I didn't quite get it, just as I didn't get 
what it has to do with "recipe development".

> Why is there a wireless connection already on the firmware? Please check
> the file /usr/local/routerlist.txt:
>
> dlink1 "dlink-8B91" "zubnw96594"
>
> Can it be that the TM5 enters some service mode when it connects to this
> wireless SSID "dlink-8B91" and password "zubnw96594"? Or is this the
> router data from Ikaro_Psi? :/

It seems unlikely that this is Ikaro Psi's own router data, as the 
.squashfs file we are looking at is a readonly filesystem. None of the 
files should contain any data that belongs to a specific TM5.

It seems like "routerlist.txt" is only being used by 
"/usr/bin/testrouter"; that shell script will try to connect to a 
wireless network with the SSID/PSK you mentioned, and writes to file 
"/mnt/rwfs/data/tech_box/routertests.log" if it was successful.
I assume that this WLAN access point is only being used during the 
manufacturing of the TM5 or the Cook-Key, simply to test if the WLAN 
works correctly.

Joachim S. schrieb:
> I stumbled upon that too. But the problem I see is that none of the
> choices  actually allows that pirated cookie being mentioned:
>> # Possible values: 0 - not RDV version, no support for pirated cookie
>> (EXT4 formatted cookie).
>> #                  1 - RDV version, no support for pirated cookie.

I think the no for the value 1 (RDV version) is a typo, because the 
variable sets the Recipe Development Version active, so the engineers 
can use EXT4 formatted cookie's (I think without encryption).

> And apart from that: What is a "cookie" in this context anyway? Did they
> just misspell "Cook-Key"? I didn't quite get it, just as I didn't get
> what it has to do with "recipe development".

From what I have read, the cookie ist the "read only" recipe chips 
(internal with a USB flash drive detected as a CD-ROM drive) that are 
used on the side of the TM5. The Cook-Key is the wireless adapter with a 
"read/write" USB flash drive. I think if the global variable is set to 
1 as RDV version, we could use a normal USB flash drive with own 
recipes in the same XML format found on the .squashfs file.

Bimby T. schrieb:
> Joachim S. schrieb:
>> I stumbled upon that too. But the problem I see is that none of the
>> choices  actually allows that pirated cookie being mentioned:
>>> # Possible values: 0 - not RDV version, no support for pirated cookie
>>> (EXT4 formatted cookie).
>>> #                  1 - RDV version, no support for pirated cookie.
>
> I think the no for the value 1 (RDV version) is a typo, because the
> variable sets the Recipe Development Version active, so the engineers
> can use EXT4 formatted cookie's (I think without encryption).
>

That could make sense. My thought was that a there was a mechanism which
puts the TM5 in a somehow broken state once he detects somebody is
trying to use a pirated/manipulated cookie (the recipe one). Not that it 
makes sense, but what I've read from vorwerk I would not wonder if they 
dare doing that kind of stuff.

Moritz M. schrieb:
> That could make sense. My thought was that a there was a mechanism which
> puts the TM5 in a somehow broken state once he detects somebody is
> trying to use a pirated/manipulated cookie (the recipe one). Not that it
> makes sense, but what I've read from vorwerk I would not wonder if they
> dare doing that kind of stuff.

I can not test it, first I do not know how to get access to the system 
and second I do not own a TM5. :)
The best way would be to find out how the encrypted cookie works, 
because we could then create a "pirated" cookie with our own recipes 
without messing with the firmware... In my opinion, the Cook-Key 
(wireless adapter) is not worth it because it is only limited to the 
recipes that vorwerk has approved on their portal and asks for a 
subscription to access it.
The TM5 is nothing more than a TM31 with a Raspberry Pi on it. :D
Did anyone know if we can control the TM31 over infrared diagnostic 
port, so I could use a smartphone with IR and develop an app that does 
the same as the TM5, but not limited to their recipes! ;)

Bimby T. schrieb:
> The TM5 is nothing more than a TM31 with a Raspberry Pi on it. :D

Pretty much, yeah.

> Did anyone know if we can control the TM31 over infrared diagnostic
> port, so I could use a smartphone with IR and develop an app that does
> the same as the TM5, but not limited to their recipes! ;)

I didn't quite get that sentence: Was it a question asking if the TM31 
can be controlled over the infrared diagnostic port, or was it a 
statement pointing out that the TM31 can in fact be controlled  over 
that port?

Either way, I actually wonder if it doesn't make sense to simply develop 
an alternative main board for the Thermomix, instead of trying to hack 
the original one. I believe that would have a few advantages:
- The same board could probably be used for both the TM5 and the TM31; 
that way, owners of the TM31 could get the advantages of the TM5, people 
who don't own a Thermomix yet could buy a cheap used TM31 and basically 
turn it  into a TM5
- No dangerous messing around at all with the expensive original board; 
the original board is simply being replaced. In case the Thermomix must 
be sent in for repair, the original, unmodified board is installed 
again, and Vorwerk  cannot detect any modification. And as we are not 
hacking the original TM5 firmware by using some security holes, Vorwerk 
cannot simply close those security holes by shipping an updated firmware
- No legal issues whatsoever, as we are not hacking the original 
system's security

Even if at some point we should find a way to truly hack the TM5, I 
think it would be worth to go that path as an alternative & perfectly 
legal approach. The guy who started this thread:
Beitrag "Thermomix TM31 Modifikation"
already began working on that approach for the TM31...

Just for curiosity, does anybody already got the firmware 201706290000 
2.3 on their TM5. I'm stuck with 2016... 2.2 and pushing the update 
button does only say there is no update.

Joachim S. schrieb:
> Either way, I actually wonder if it doesn't make sense to simply develop
> an alternative main board for the Thermomix, instead of trying to hack
> the original one.

The problem with that is that you would need to open up your Thermomix.
I was asking if someone know if it where possible to control the TM31 
over the diagnostic infrared port, so we did not need to open it up to 
change the original one.
On the TM5 there is no infrared port, so the easiest alternative would 
be hacking the cookie encryption, because they could not change that on 
new firmware, or the TM5 would loose access to the older cookie's 
shipped with the first batch of TM5.
They maybe could do like Sony did with the PS3, new revisions did not 
allowed "jailbreaking" like the older revisions.

Bimby T. schrieb:
> Joachim S. schrieb:
>> Either way, I actually wonder if it doesn't make sense to simply develop
>> an alternative main board for the Thermomix, instead of trying to hack
>> the original one.
>
> The problem with that is that you would need to open up your Thermomix.

Sure. And I agree that this is a major disadvantage of course. But if 
the only alternative were to not be able to "free" the Thermomix at all, 
then this might ultimately still be the best approach.

> I was asking if someone know if it where possible to control the TM31
> over the diagnostic infrared port, so we did not need to open it up to
> change the original one.

I got that, it just wasn't 100% clear to me if your sentence was a 
question or a statement.

> On the TM5 there is no infrared port, so the easiest alternative would
> be hacking the cookie encryption, because they could not change that on
> new firmware, or the TM5 would loose access to the older cookie's
> shipped with the first batch of TM5.
> They maybe could do like Sony did with the PS3, new revisions did not
> allowed "jailbreaking" like the older revisions.

I agree. But let's face it, we will probably never actually be able to 
completely crack the TM5 encryption system.
There's a good chance we will at some point be able to...
- decrypt the recipe chips
- make the TM5 accept custom recipes, using security holes in the 
firmware
- maybe even add some useful features to the TM5

But I just don't see us ever being able to create the kind of proper, 
valid recipe chips that cannot be blocked by firmware updates that you 
are hoping for. We know the patent that describes the TM5 security 
system for recipe chips, and it looks pretty solid to me on first sight. 
Unless we were able to somehow get access the private key that Vorwerk 
uses to digitally sign the recipe chips, we won't be able to create 
custom recipe chips with a valid digital signature. And the developers 
at Vorwerk would have to be extremely stupid if they had placed the 
private key used for signing in the firmware...

Joachim S. schrieb:
> But I just don't see us ever being able to create the kind of proper,
> valid recipe chips that cannot be blocked by firmware updates that you
> are hoping for. We know the patent that describes the TM5 security
> system for recipe chips, and it looks pretty solid to me on first sight.
> Unless we were able to somehow get access the private key that Vorwerk
> uses to digitally sign the recipe chips, we won't be able to create
> custom recipe chips with a valid digital signature. And the developers
> at Vorwerk would have to be extremely stupid if they had placed the
> private key used for signing in the firmware...

There are several possibilities regarding signatures.
A mistake in the signature scheme may allow to easily extract the 
private key (remeber PS3).
Another possibility is to change the public key, then you can use any 
key of your choice.

From my point of view, the most impotant thing is to understand how data 
are stored in the recipe key (cookie).

Sigma P. schrieb:
> There are several possibilities regarding signatures.
> A mistake in the signature scheme may allow to easily extract the
> private key (remeber PS3).

True, if Vorwerk epically failed at properly implementing the 
encryption/signature algorithm, we might be able to extract the private 
key.
That would be jackpot! But while I hope I'm wrong, I currently expect 
the chances of this happening to be rather low... :-(

> Another possibility is to change the public key, then you can use any
> key of your choice.

You mean by changing the public key that is stored in the firmware, and 
that is used for verifying the digital signatures?
If so, I would consider this a rather pointless approach. Because that 
would require altering/hacking the firmware, by means of some security 
hole (which could be fixed with a firmware update), right? And wouldn't 
simply changing the public key mean that original recipe chips would 
then be rejected?
If the hack requires changing the firmware, shouldn't we be able to 
simply bypass the signature verification instead?

> From my point of view, the most impotant thing is to understand how data
> are stored in the recipe key (cookie).

Have you read the patent documents that describe the security system of 
the recipe chips in this posting: 
Beitrag "Re: Thermomix Rezeptchips" 
?
They should be very helpful for this. I don't know if there is an 
english version of those documents available somewhere - so if you need 
any help translating/understanding those documents, we should be able to 
help.

Joachim S. schrieb:
> That would be jackpot! But while I hope I'm wrong, I currently expect
> the chances of this happening to be rather low... :-(

I agree, chance is low.


Joachim S. schrieb:
> You mean by changing the public key that is stored in the firmware, and
> that is used for verifying the digital signatures?
> If so, I would consider this a rather pointless approach. Because that
> would require altering/hacking the firmware, by means of some security
> hole (which could be fixed with a firmware update), right? And wouldn't
> simply changing the public key mean that original recipe chips would
> then be rejected?
> If the hack requires changing the firmware, shouldn't we be able to
> simply bypass the signature verification instead?

Your're right. I mean changing the public used for verifying the digital 
signatures.
It depends on the case.
Yes it can be fixed by Vorwerk, but then it becomes a game.
New update = New exploit to find!!!


Joachim S. schrieb:
> Have you read the patent documents that describe the security system of
> the recipe chips in this posting:
> 
Beitrag "Re: Thermomix Rezeptchips"
> ?
> They should be very helpful for this. I don't know if there is an
> english version of those documents available somewhere - so if you need
> any help translating/understanding those documents, we should be able to
> help.

Yep, I read it.


I don't know how to continue.

What about GPL license ?
If some interesting code is hidden in the kernel, they should publish it 
since it's a GPLv2 license.

In the Kobold manual (Vorwerk), they say that a Linux is used can be 
downloaded here:
https://www.neatorobotics.com/lab/linux/

Neatorobotics seems to be the third party company that developped this 
product for Vorwerk.

I'm sure we shoudld get Thermomix Kernel.

Does someone got a response from opensource@vorwerk.de for Kernel 
sources ?

Sigma P. schrieb:
> What about GPL license ?
> If some interesting code is hidden in the kernel, they should publish it
> since it's a GPLv2 license.

Apparently, if you contact Vorwerk, they will send you a CD with the 
source code of the GPL software. Some guy from this forum did so back in 
2015:
Beitrag "Re: Thermomix Rezeptchips"
Unfortunately he did not publish the source code they sent him, but at 
least he posted a listing of the files on the CD, and it suggests that 
they indeed modified three packages:
- linux kernel v2.6.35.3
- kobs-ng v10.12.01
- logrotate v3.8.3

> I don't know how to continue.

You've got a TM5 and something like root access, allowing you to alter 
the TM5 filesystem, correct?
Here's an idea - perhaps it won't help much, but it shouldn't be too 
much work, so I want to at least mention it:

One could create a small proxy shell script that logs all calls to 
"interesting" commands. It would do about the following:
1. Capture the current timestamp + full command line it was called with 
(program name + all arguments)
2. Append that information to a special log file (for example 
/proxy/log.txt)
3. Call the actual command, passing all the arguments it was called with

Store that shell script on the TM5 (for example named /proxy/proxy.sh)

That shell script could then act as a kind of proxy to commands like 
mount, checksig etc.
For example, to log calls to the command "/usr/sbin/checksig":
1. Copy the program /usr/sbin/checksig to /proxy/commands/checksig
2. Replace /usr/sbin/checksig with a symbolic link that points to the 
proxy shell script, /proxy/proxy.sh

Then if some program on the TM5 calls "checksig", proxy.sh would first 
log timestamp + the command line that the program checksig was called 
with to /proxy/log.txt, then call /proxy/commands/checksig with just the 
arguments it was called with.
That way, one could create a log of all interesting commands that are 
being called in chronological order, for example when attaching a recipe 
chip.

What do you and the others think about this?

EDIT: This is what the script /proxy/proxy.sh might look like:

1

#!/bin/sh

2

3

# Path to the directory with all proxy-related files

4

proxy_directory="/proxy"

5

6

# Log timestamp + called command line to the log file

7

echo "$(date +%s):" "$0" $@ >> "${proxy_directory}/log.txt"

8

9

# Call the proxied command passing all arguments

10

"${proxy_directory}/commands/$(basename $0)" $@

Joachim S. schrieb:
> Apparently, if you contact Vorwerk, they will send you a CD with the
> source code of the GPL software. Some guy from this forum did so back in
> 2015:
> Beitrag "Re: Thermomix Rezeptchips"
> Unfortunately he did not publish the source code they sent him, but at
> least he posted a listing of the files on the CD, and it suggests that
> they indeed modified three packages:
> - linux kernel v2.6.35.3
> - kobs-ng v10.12.01
> - logrotate v3.8.3

So, it would interesting to get linux kernel modification in order to 
check if they do something specific with USB.


Joachim S. schrieb:
> You've got a TM5 and something like root access, allowing you to alter
> the TM5 filesystem, correct?

Sorry but I don't have root access. I just have the root file system 
that have been posted.

David N. schrieb:
> So... es ist soweit.. ich habe mal den USB Protocol Analyzer zwischen
> TM5 und Rezeptchip gehangen.
>
> Bisher habe ich noch nicht viel in den Daten herumgestöbert. Man sieht
> nur einen IN und einen OUT Endpoint "Mass Storage Device".
>
> In den grossen Datenpaketen konnte ich keinen Klartext erkennen. Aber
> wer weiss schon, in welchem Format die Daten vorliegen?
>
> Der Trace ist folgendermassen entstanden:
> 1. recording starten
> 2. chip anschliessen
> 3. nach Erkennung -> Menü -> Rezepte
> 4. "Das Kochbuch"
> 5. "Nach Kategorie"
> 6. "Vorspeisen und Salate"
> 7. "Brokkoli Salat mit Pinienkernen"
> 8. Starten (rechts oben)
> 9. ca. 4 mal "weiter"
>
> Den Trace gibt es hier (14.5Mb):
> https://mega.co.nz/#!2h0QTYZY!UAgvTRrAN7ne1SK7BF6wh8swa_cITtvP7KZvjrY7Qo4
>
> Und die Software gibt es Gratis bei LeCroy:
> 
http://teledynelecroy.com/support/softwaredownload/download.aspx?mseries=0&did=8337
>

Hello Knochi,

Do you have a dump of the cookie (a dump made with dd or somthinhg like 
that).
I would like to compare data exchanged through USB and data dumped with 
dd in order to check dumping like that is correct.

Does somone already success to clone a cookie ?

It's possible to share a cookie between two thermomix, right?
So, it should be possible to clone a cookie.

If I well understand (from what I saw and what is written on this 
thread), it's only a matter of VID, PID and serial number that is 
included in USB descriptor.

I am right?

You are right. It is possible to clone a chip

Fabian O. schrieb:
> You are right. It is possible to clone a chip

Please, can you share kernel patches from Vorwerk CD.

Sigma P. schrieb:
> Fabian O. schrieb:
>> You are right. It is possible to clone a chip
>
> Please, can you share kernel patches from Vorwerk CD.

Send me a PM

Hallo zusammen,

sehr interessante Diskussion hier, bei der ich mich jetzt auch 
beteiligen kann nachdem wir auch einen TM5 haben.

Scheinbar haben die Vorwerk-Ingenieure ihren Job ganz gut gemacht, so 
dass z.Z eigentlich nur ein bisschen Qemu-RootFS-Spielereien (von Ikaro 
Psi) übrig bleiben, um mal zu schauen was so geht.

Das habe ich mal versucht (*zum Nachahmen sollte man wissen was man 
tut*)
1. qemu installieren und Kernel/initrd, der oben erwähnt ist downloaden
2. squashfs unter linux mounten (auf /mnt/thermomix)
3. 128MB - Raw-Harddisk erstellt

1

dd if=/dev/zero of=thermomix.raw bs=1024 count=128k

4. mittels cfdisk thermomix.raw das Image partitioniert
   Ich hab da 2 Partitionen erstellt
   p1) 19MB für Squashfs (hab dann gemerkt das es sinnlos ist)
   p2) 50MB ext3  (hier ist dann das rootfs drin)
5. mit "kpartx -a thermomix.raw" das Image als loop-harddisk 
"registrieren"
   Danach kann p1 und p2 als
   /dev/mapper/loop0p1 und /dev/mapper/loop0p2  (oder loop1..)
   angesprochen werden
6. mkfs vom rootfs und mount

1

mkfs.ext3 /dev/mapper/loop0p2

2

mount /dev/mapper/loop0p2 /mnt/thermomixext3

7. rsync

1

rsync -av /mnt/thermomix/ /mnt/thermomixext3/

Da ist mir aufgefallen, dass das squashfs GENAU bei der /bin/busybox 
einen io-Fehler hat und rsync nur diese Datei nicht kopiert.

1

[ 2780.290452] SQUASHFS error: Unable to read data cache entry [135cd]

2

[ 2780.290456] SQUASHFS error: Unable to read page, block 135cd, size 14359

Die Datei ist für das Funktionieren des Images aber nötig.

8. Debian busybox-static nach /mnt/thermomixext3/bin/busybox kopieren
   und zwar die Version von 
https://packages.debian.org/wheezy/busybox-static
   die hat keine glibc-Abhängigkeiten, die sonst - bei falscher Version 
- das
   Booten verhindern
9. unmount/usw

1

   umount /mnt/thermomixext3 

2

   kpartx -d thermomix.raw

10. qemu starten

1

    qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile \

2

                        -initrd initrd.img-2.6.32-5-versatile \

3

                        -hda thermomix.qcow2 \

4

                        -append "root=/dev/sda2" \

5

                        -redir tcp:2200::22

Ergebnis siehe Bild.
Das System bootet, aber bricht natürlich ab, da ich noch keine 
Anpassungen (bis auf busybox) gemacht habe.

Es sollte aber kein Problem sein, einige Sachen zu simulieren (z.B. 
Data-Partition), in dem man die Skripte anpasst.

Vg

boecko

Hallo,

einen Schritt am Schluss (vor 10) habe ich vergessen:

9b. Differenz-Image thermomix.qcow2

1

qemu-img create -b thermomix.raw -f qcow2 thermomix.qcow2

- Das erzeugt das Differenz-Image thermomix.qcow2, das nur die 
Änderungen im laufenden Betrieb beinhaltet.
-  thermomix.raw bleibt dabei unangetastet
- den Schritt muss man wahrscheinlich wiederholen, wenn man an 
thermomix.raw rumschraubt, da das FS sonst inkonsistent ist (evtl bei 
ro-mount nicht noetig)

vg

Hallo,

kleines Update: nachdem ich ein weitere Partition in thermomix.raw 
angelegt habe und
/etr/rc.d/rc.local auf

1

mount -t ext3 /dev/sda3 /mnt/rwfs/data

geändert habe, kommt man zumindest soweit wie im Bild

/mnt/rwfs/data/tech_box/session_0/gui_0.log zeigt auch einige Einträge 
der GUI

Einen guten Rutsch an alle

boecko

Moin Boecko,

Das sieht ja schon nicht schlecht aus. Auf den ersten Blick würde ich 
sagen, das er einen Bite Test an den Touchscreen macht, oder?

Frohes Neues Jahr!

Hallo an alle,

This thread is starting to get too long with pieces of information 
scattered everywhere. Maybe we should start a subreddit with a proper 
wiki. Something like /r/ps3homebrew (and its wiki at 
https://www.reddit.com/r/ps3homebrew/wiki).

Maybe /r/ThermomixHomebrew?

Hi,

Could someone share a dump of the data contained in the memory stick 
located on the wifi cook key board ?

Has anyone managed to mount the recipe.img using the password in 
cookey.txt ?

I've tried using losetup (with an older version that - like the one in 
the firmware - support "-e aes128"), with cryptsetup and aespipe... 
without luck.

Thanks

I've played around with qemu, the TM5 rootfs that was provided here, and 
kernel/initrd from https://people.debian.org/~aurel32/qemu/armel/

I've also commented lines in /etc/rc.d/rc.local to enable telnet.

Telnet listens to the sole available interface (loopback) which is 
useless when using the -redir option to have the host forward to the 
guest's telnet. So, an ethernet interface needs to be created.

My understanding is that /boot must be on another partition (that we do 
not have access to) and there is no /lib/modules either.

So to load the default NIC from qemu (don't try the e1000 as it 
segfaults), I have added mii.ko and smc91x.ko that I have extracted from 
the rootfs at above URL and put them in the data disk (the one mounted 
as sda3 and where TM5 logs are written).

I have modified a boot script to load those modules with insmod and then 
run dhclient eth0).

At that point, it is possible to telnet the guest (root, no password).


The whole purpose of that was to have a proper shell and try 
understanding how the TM5 decrypts the recipe device/image before 
mounting it.

We already known/assume that the password to decrypt the image is in 
/opt/cookey.txt.

grep -ra cookey.txt on the whole rootfs returns only one file ( binary: 
/usr/sbin/netlink (as descrbed in previous posts) with this:
losetup -e aes128 -P /opt/cookey.txt

Someone here mentioned that these options do not really make any sense. 
Indeed, the image to decrypt is missing but also -e aes128 is no longer 
supported in recent versions of losetup.

Well, the losetup found in the rootfs does not effectively not support 
the "-e aes128" option so I don't really see how the decryption process 
is happening.


No really, related but I noticed the following kobs configuration file:
root@tm41 ~$ cat .kobs
#
# The sample configuration file for kobs
#
chip_0_device_path=/dev/mtd0

search_exponent = 3
data_setup_time = 40
data_hold_time = 40
address_setup_time = 40
data_sample_time = 6
row_address_size = 3
column_address_size = 2

ncb_version = 3

## not used anyway
##boot_stream_1_address = 0
##boot_stream_2_address = 0x1500000


where /dev/mtd0 is usually referred too as a flash drive.


Again, if the person who did open his wifi chip could share a copy of 
the content of the sd card connected to it, I'd be happy to see what can 
be done with it.

Schang S. schrieb:
>
> Again, if the person who did open his wifi chip could share a copy of
> the content of the sd card connected to it, I'd be happy to see what can
> be done with it.

There at least two facebook groups[0][1] where they claim they dumped 
the image. In the first one there is a dead dropbox link. But maybe it 
is worth asking there.

[0]: https://www.facebook.com/BIMBYTM5HACK/
[1]: https://www.facebook.com/tm5modding

Thanks. I have seen those groups but - unless I missed something - the 
dump they offer is from a recipe key while I am seeking from the wifi 
dongle.

Have you seen them talking about that (because I've been through all 
published content several times and could not see anything like that) ?

You can see all specification of the cooki-key on fcc-id

https://fccid.io/2AGELCK1

For the moment i just want dump a cook-key , how can i do ?

Thanks. The FCC assessment only cares about radio.
To dump, after opening the cook-ket (which is what I would rather avoid 
doing), I'am assuming the putting the sd card in your pc should do the 
trick

Any idea how the recipe key is being encrypted ? Cryptsetup does not 
recognize the file:

# cryptsetup luksDump recipes.img
Device recipes.img is not a valid LUKS device.

Hallo,
I had opened my cook-key (normal and not wifi).
Impossible to read it on:
- Windows 10
- virtual box Windows XP
- virtual box Linux (Lubuntu)
How can i do ?

Have you tried this  product ?
FORNORM Magnetic Charging Cable USB 2.0 Male to 4 Pin Pogo Magnetic 
Charger Cable Cord For Smart Watch GT88 G3 KW18 Y3 KW88 GT68
 http://s.aliexpress.com/veAbmUVZ?fromSns=Nouveau message

Hi,

No sure what you are trying to achieve but you should not expect being 
able to open the key like any regular usb memory stick.

Using e.g., Linux you should be able to create a copy using dd but then 
you'll end up (as discussed in previous posts) with an image of the key 
that is encrypted.

Hi guys,
Under windows 10 i have made an image.dd renamed image.img of my chip 
with a nice tool.

https://www.cgsecurity.org/wiki/TestDisk_DE

Read this before but i used default at each time...
https://korben.info/realiser-limage-dun-disque-dur-testdisk.html
(sorry it's in french but google translation is your friend)

Next step...
Write this image.img on a stick ;)

Thierry G. schrieb:
> Hi guys,
> Under windows 10 i have made an image.dd renamed image.img of my chip
> with a nice tool.
>
> https://www.cgsecurity.org/wiki/TestDisk_DE
>
> Read this before but i used default at each time...
> https://korben.info/realiser-limage-dun-disque-dur-testdisk.html
> (sorry it's in french but google translation is your friend)
>
> Next step...
> Write this image.img on a stick ;)

Hi Thierry,

why don't you try with a simple tool called Win32 Disk Imager. It makes 
RAW images from the stick and can write it to another stick... ;)
https://sourceforge.net/projects/win32diskimager/

Can you test compressing the resulting image (ZIP, 7Z or RAR)? Can you 
share the resulting file? It would be nice to compare two extracted 
images from two identical (same book but two different serial numbers) 
chips to see if there is any change. Probably only the serial number 
from the chip. If not, then the serial number of the chip is probably 
used for the partition encryption.

Ich dachte das wäre ein deutsches Forum.

Jörg P. R. schrieb:
> Ich dachte das wäre ein deutsches Forum.

Ich denke dass jeder der mit der Recherche mithelfen möchte, deutscher 
oder nicht, ist hier im Forum herzlich wilkommen. Und Englisch ist 
heutzutage eine universelle Sprache. ;)

Hallo Forum,
wäre es nicht möglich einen FTP Server zu starten ? Damit hätte man die 
Möglichkeit eigene Rezepte auf den TM zu schieben. Haltet ihr das für 
möglich ?
Gruß
firstfacility

Sicher, das sehe ich ein, aber als interessierter mit wenig Englisch 
Kenntnisse ist es halt schwer.

Bimby T. schrieb:
> why don't you try with a simple tool called Win32 Disk Imager. It makes
> RAW images from the stick and can write it to another stick... ;)

Hi Bimby T.
Win32DiskImager don't work it can't see the false CD drive.

> Can you test compressing the resulting image ? Can you
> share the resulting file? It would be nice to compare two extracted
> images from two identical

it's a great idea !

@last posts:

Please read the COMPLETE thread! I know, its long, but: imaging and 
cloneing already works. We found already the tools and settings, because 
the drive serialnumber is very importend.

Fabian O. schrieb:
> @last posts:
>
> Please read the COMPLETE thread! I know, its long, but: imaging and
> cloneing already works. We found already the tools and settings, because
> the drive serialnumber is very importend.

Hi Fabian,

Sorry, I overlooked the post 
(Beitrag "Re: Thermomix Rezeptchips").
But we do not want to clone a chip, just make a chip with our own 
recipes...

Hey Bimby,

I have to agree with @Fabians response: please read the complete thread, 
this is especially true for "making own recipes".

That topic has already been covered and to be honest (in my opinion), 
the most recent posts in this thread clearly show lacking deeper 
understanding of the underlying technologies. Currently a bunch of 
fundamentals are still missing, which should be definitely solved before 
setting up any FTP servers, tools or whatever.

Markus H. schrieb:
> Currently a bunch of
> fundamentals are still missing, which should be definitely solved before
> setting up any FTP servers, tools or whatever.

I'd guess: If anyone here is capable or able or whatever to gain access 
to the device and is able to break the encryption - what's the way he'd 
go? Sharing his knowledge within a minor forum or sell the knowledge and 
thus the security issue to Vorwerk?

Such a comprehensive hack would be worth a whole load of money! I'd 
offer it for at least 5 Million Euro. I bet Vorwerk will pay!

Martin S. schrieb:
> Markus H. schrieb:
>> Currently a bunch of
>> fundamentals are still missing, which should be definitely solved before
>> setting up any FTP servers, tools or whatever.
>
> I'd guess: If anyone here is capable or able or whatever to gain access
> to the device and is able to break the encryption - what's the way he'd
> go? Sharing his knowledge within a minor forum or sell the knowledge and
> thus the security issue to Vorwerk?
>
> Such a comprehensive hack would be worth a whole load of money! I'd
> offer it for at least 5 Million Euro. I bet Vorwerk will pay!

I think one possible guy wo would crack it would be Ikaro Psi (ikaro_p). 
It was the only one that had root access to the TM5 system... :)

Bimby T. schrieb:
> Martin S. schrieb:
>> Markus H. schrieb:
>>> Currently a bunch of
>>> fundamentals are still missing, which should be definitely solved before
>>> setting up any FTP servers, tools or whatever.
>>
>> I'd guess: If anyone here is capable or able or whatever to gain access
>> to the device and is able to break the encryption - what's the way he'd
>> go? Sharing his knowledge within a minor forum or sell the knowledge and
>> thus the security issue to Vorwerk?
>>
>> Such a comprehensive hack would be worth a whole load of money! I'd
>> offer it for at least 5 Million Euro. I bet Vorwerk will pay!
>
> I think one possible guy wo would crack it would be Ikaro Psi (ikaro_p).
> It was the only one that had root access to the TM5 system... :)

You don't know if he did. He was able to obtain the rootfs of the 
thermomix (excluding the /boot partition where the kernel and initrd, if 
any, is located) but that may also have been done through the update 
mechanism.

I have been provided with the content of the cook-key by a member of 
this forum - that he did not want to disclose publicly as it may contain 
identifiers such as a serial number that could link him to the leakage - 
and was able to play a bit with the content. So, this could alo be a way 
of figuring out how the upgrade process is happening and potentially to 
fet a firmware upgrade.

I haven't shared the output of what I was able to see so far so here it 
is in a quick dirty way:
fdisk -l thermomix-cookkey-drive-d
Disk thermomix-cookkey-drive-d: 7.5 GiB, 8053063680 bytes, 15728640 
sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x84d46198

Device                     Boot  Start     End Sectors  Size Id Type
thermomix-cookkey-drive-d1        2048  526335  524288  256M 83 Linux
thermomix-cookkey-drive-d2      526336 7854079 7327744  3.5G 83 Linux

#boot sector from 1 to 2048. d1 is from 2048 to

dd if=thermomix-cookkey-drive-d of=d1 skip=2048 bs=512 count=524288 
status=progress
524288+0 records in
524288+0 records out
268435456 bytes (268 MB, 256 MiB) copied, 0.853545 s, 314 MB/s

file d1
d1: Linux rev 1.0 ext4 filesystem data, 
UUID=4f0f6d2e-504f-41dd-8a06-8fc85eacdf66, volume name "usbdrive1" 
(extents) (large files) (huge files)

#dump second partition
dd if=thermomix-cookkey-drive-d of=d2 skip=526336 bs=512 count=7327744 
status=progress
3652907520 bytes (3.7 GB, 3.4 GiB) copied, 9 s, 406 MB/s
7327744+0 records in
7327744+0 records out
3751804928 bytes (3.8 GB, 3.5 GiB) copied, 12.6379 s, 297 MB/s

file d2
d2: Linux rev 1.0 ext4 filesystem data, 
UUID=37c9eec0-8e8f-4ea2-977e-e8d0c5b18b93, volume name "usbdrive2" 
(needs journal recovery) (extents) (large files) (huge files)

dd if=thermomix-cookkey-drive-d of=d3 skip=7854079 bs=512 
status=progress
3727178752 bytes (3.7 GB, 3.5 GiB) copied, 9 s, 414 MB/s
7874561+0 records in
7874561+0 records out
4031775232 bytes (4.0 GB, 3.8 GiB) copied, 9.71618 s, 415 MB/s

file d3
d3: data



mkdir /tmp/d1
mkdir /tmp/d2

sudo mount -t ext4 d1 /tmp/d1
ls /tmp/d1
cs.tar
sudo mount -t ext4 d2 /tmp/d2
ls /tmp/d2
15272373012203516.ell  ext.sdb  ext.sdb-wal  material 
settings_cloud.sdb  tm5.img

#make copy of the content from the mounted volumes to leave these 
volumes untouched
mkdir /tmp/extract
cd /tmp/extract
cp -r /tmp/d1 /tmp/d2 .

cd d1
tar xf cs.tar
ls
cs.tar  ext.sdb  material  settings_cloud.sdb  tm5.img

ls material/
binary  photo

cd material/binary/
ls
47857.bin  47874.bin  47891.bin  47907.bin  47923.bin[....]

ls |wc -l
206

ls -l |head
total 824
-rw------- 1 besnard besnard 1488 Jun  9  2016 47857.bin
-rw------- 1 besnard besnard 1712 Jun  9  2016 47858.bin
-rw------- 1 besnard besnard  736 Jun  9  2016 47859.bin
-rw------- 1 besnard besnard  976 Jun  9  2016 47860.bin
-rw------- 1 besnard besnard  896 Jun  9  2016 47861.bin
-rw------- 1 besnard besnard 1408 Jun  9  2016 47862.bin
-rw------- 1 besnard besnard 1536 Jun  9  2016 47863.bin
-rw------- 1 besnard besnard 1984 Jun  9  2016 47864.bin
-rw------- 1 besnard besnard 2224 Jun  9  2016 47865.bin

hexdump -C 47857.bin|head ; echo;hexdump -C 47858.bin|head
00000000  b7 31 5f 40 9c 57 42 89  c5 db 8e 5b 79 a2 f4 7f 
|.1_@.WB....[y...|
00000010  0f 97 ba 54 3b a3 18 39  2b eb a8 99 0e 5f 60 52 
|...T;..9+...._`R|
00000020  b8 80 1b 78 99 46 0d 2d  bf 1d 0a b5 a9 70 d0 95 
|...x.F.-.....p..|
00000030  7c 4e 37 9a b5 15 30 3c  4d 70 9a 87 cf 02 34 07 
||N7...0<Mp....4.|
00000040  aa 6c 73 11 52 b5 63 bb  2e 14 2b 0a eb 07 2a d0 
|.ls.R.c...+...*.|
00000050  f0 e5 e6 ce 42 b3 f0 58  e5 2a b8 5d 07 75 93 8a 
|....B..X.*.].u..|
00000060  76 da ce 51 a0 33 82 3a  c5 66 15 60 c1 02 02 61 
|v..Q.3.:.f.`...a|
00000070  d5 57 05 f6 73 b1 87 dd  48 1a bd 31 e1 68 dc 23 
|.W..s...H..1.h.#|
00000080  25 b6 36 bc af ed ff 9b  67 94 79 9d 0a ee 98 a1 
|%.6.....g.y.....|
00000090  b2 81 07 8f 6f 20 55 87  2d 6d 43 3c 10 75 28 6b  |....o 
U.-mC<.u(k|

00000000  27 8c d3 bc c3 2e 7e 95  f3 e2 d4 40 37 0f 91 82 
|'.....~....@7...|
00000010  59 ea de 65 26 e2 f7 df  ce b0 b7 1d db 23 0a cf 
|Y..e&........#..|
00000020  24 41 94 ef cb 59 72 50  3d 0d e4 38 cb 08 30 ed 
|$A...YrP=..8..0.|
00000030  09 bf 2a cc 44 91 09 b3  18 d0 58 fe 67 a8 16 ac 
|..*.D.....X.g...|
00000040  1d 09 ec d5 39 63 21 b3  30 c4 25 4c 33 60 56 fc 
|....9c!.0.%L3`V.|
00000050  f2 82 93 69 3b 0e 9e 76  ea 03 f3 a6 b5 b9 e9 da 
|...i;..v........|
00000060  46 55 a9 6d 32 84 3f d8  b9 3b f4 64 08 3f 1d 68 
|FU.m2.?..;.d.?.h|
00000070  c7 b8 24 14 b5 48 89 71  cf 5e 0d a7 4c d0 88 46 
|..$..H.q.^..L..F|
00000080  3a bb da 9a 67 09 39 1b  fb f2 fa 12 e8 bb bf 66 
|:...g.9........f|
00000090  1a b0 46 1b 58 4c f8 eb  41 4d 48 98 11 04 41 68 
|..F.XL..AMH...Ah|

---> I tried to bindiff the various files but there is nothing in common 
so no way of determining the structure (e.g., headers, etc.) of the 
file.


the image directory contains the pics of the recipes so it's rather 
useless.

cd /tmp/extract/d1
sqlite3 ext.sdb
SQLite version 3.11.0 2016-02-15 17:29:24
Enter ".help" for usage hints.
sqlite> .tables
categoryBin        collectionBin      material           recipeBin
categoryBinMap     collectionBinMap   materialSignature  recipeNote
categoryLang       dataExt            metadata           recipeSignature

sqlite> .dump categoryBin
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE categoryBin (
    categoryId UNSIGNED BIGINT NOT NULL PRIMARY KEY,
    typeId INTEGER NOT NULL,
    materialId UNSIGNED BIGINT DEFAULT 0 NOT NULL
);
INSERT INTO "categoryBin" VALUES(2,1,118);
INSERT INTO "categoryBin" VALUES(6,1,111);
INSERT INTO "categoryBin" VALUES(12,1,102);
INSERT INTO "categoryBin" VALUES(5,1,109);
INSERT INTO "categoryBin" VALUES(8,1,116);
INSERT INTO "categoryBin" VALUES(11,1,107);
INSERT INTO "categoryBin" VALUES(13,1,103);
INSERT INTO "categoryBin" VALUES(14,1,105);
INSERT INTO "categoryBin" VALUES(4,1,110);
INSERT INTO "categoryBin" VALUES(9,1,114);
INSERT INTO "categoryBin" VALUES(16,1,104);
INSERT INTO "categoryBin" VALUES(15,1,108);
INSERT INTO "categoryBin" VALUES(1,1,119);
INSERT INTO "categoryBin" VALUES(266,1,115);
INSERT INTO "categoryBin" VALUES(17,1,101);
COMMIT;
sqlite> .dump collectionBin
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE collectionBin (
    collectionId UNSIGNED BIGINT NOT NULL PRIMARY KEY,
    title VARCHAR NOT NULL,
    sortKey VARCHAR NOT NULL,
    materialId UNSIGNED BIGINT REFERENCES material ON DELETE NO ACTION 
ON UPDATE NO ACTION,
    nofRecipesPlanned INTEGER NOT NULL,
    localeId INTEGER NOT NULL,
    typeId INTEGER NOT NULL,
    hash VARCHAR NOT NULL);
INSERT INTO "collectionBin" VALUES(1,'Das Kochbuch','-''K;C+5)O+5▒▒▒
                                                                    ',888,206,2,5,'1a06cc2bbc54b3REDACTEDREDACVTED');

sqlite> .dump material
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE material (
    materialId UNSIGNED BIGINT NOT NULL PRIMARY KEY,
    fullName VARCHAR NOT NULL,
    hash VARCHAR NOT NULL);
INSERT INTO "material" 
VALUES(100510,'./material/photo/150x150/mdb-72456-47857-1.jpg','2dd3a107 
7dadc6274e2ade20828c5012F');
INSERT INTO "material" 
VALUES(100610,'./material/photo/150x150/mdb-72473-47858-0.jpg','d40a868a 
32999aac8ea9c4643a53a16dF');
INSERT INTO "material" 
VALUES(100710,'./material/photo/150x150/mdb-72889-47859-0.jpg','6cb97314 
0cf27883e63dddcaab6d9a2fF');
INSERT INTO "material" 
VALUES(100810,'./material/photo/150x150/mdb-72794-47860-0.jpg','51fad5f5 
216cc62444e90a1ab460246cF');
INSERT INTO "material" 
VALUES(100910,'./material/photo/150x150/mdb-72763-47861-0.jpg','8465c2d4 
9c899ef282ed21e4ab6d141cF');
INSERT INTO "material" 
VALUES(101010,'./material/photo/150x150/mdb-72569-47862-0.jpg','42aa494a 
08fc037fb046b66446d789a2F');
[...]

sqlite> .dump recipeBin
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE recipeBin (
    recipeId UNSIGNED BIGINT NOT NULL PRIMARY KEY REFERENCES recipeNote 
ON DELETE CASCADE ON UPDATE NO ACTION,
    title VARCHAR NOT NULL,
    sortKey VARCHAR NOT NULL,
    version DECIMAL(8.2) NOT NULL,
    localeId INTEGER NOT NULL,
    materialId UNSIGNED BIGINT REFERENCES material ON DELETE NO ACTION 
ON UPDATE NO ACTION,
    hash VARCHAR NOT NULL);
INSERT INTO "recipeBin" VALUES(47857,'Crêpes','+I/E/K▒▒▒
',1,2,100510,'230e331008ae48541608101a23197cffF|1');
INSERT INTO "recipeBin" VALUES(47858,'Nudelteig, 
frisch','AO-/=M/731I7K+5▒',1,2,100610,'230e331008ae48541608101a23197cffF 
|1');
',1,2,100710,'230e331008ae48541608101a23197cffF|1');'')''3=7CA/▒
INSERT INTO "recipeBin" 
VALUES(47860,'Tomatensauce','MC?''M/AK''O+/▒',1,2,100810,'230e331008ae48 
541608101a23197cffF|1');
INSERT INTO "recipeBin" 
VALUES(47861,'Basilikumpesto',')''K7=7;O?E/KMC▒',1,2,100910,'230e331008a 
e48541608101a23197cffF|1');
',1,2,101010,'230e331008ae48541608101a23197cffF|1');7A/KMICA/▒
▒NSERT INTO "recipeBin" VALUES(47863,'Reissalat','I/7KK''=''M
',1,2,101110,'230e331008ae48541608101a23197cffF|1');
INSERT INTO "recipeBin" VALUES(47864,'Nudelsalat mit Forelle und 
Gemüse','AO-/=K''=''M?7M1CI/==/OA-3/?OK/h▒▒x▒{▒
[...]

sqlite> .dump categoryBinMap
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE categoryBinMap (
    categoryId UNSIGNED BIGINT NOT NULL REFERENCES categoryBin ON DELETE 
CASCADE ON UPDATE CASCADE,
    recipeId UNSIGNED BIGINT NOT NULL REFERENCES recipeBin ON DELETE 
CASCADE ON UPDATE CASCADE,
    PRIMARY KEY (categoryId, recipeId)
);
INSERT INTO "categoryBinMap" VALUES(16,47857);
INSERT INTO "categoryBinMap" VALUES(16,47858);
INSERT INTO "categoryBinMap" VALUES(11,47859);
INSERT INTO "categoryBinMap" VALUES(9,47860);
INSERT INTO "categoryBinMap" VALUES(9,47861);
INSERT INTO "categoryBinMap" VALUES(2,47862);
[...]

.dump collectionBinMap
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE collectionBinMap (
    collectionId UNSIGNED BIGINT NOT NULL REFERENCES collectionBin ON 
DELETE CASCADE ON UPDATE CASCADE,
    recipeId UNSIGNED BIGINT NOT NULL,
    PRIMARY KEY (collectionId, recipeId)
);
INSERT INTO "collectionBinMap" VALUES(1,47857);
INSERT INTO "collectionBinMap" VALUES(1,47858);
INSERT INTO "collectionBinMap" VALUES(1,47859);
[...]

.dump materialSignature
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE materialSignature (
    materialId UNSIGNED BIGINT NOT NULL REFERENCES material ON DELETE 
CASCADE ON UPDATE NO ACTION,
    typeId INTEGER NOT NULL,
    signature VARCHAR NOT NULL,
    PRIMARY KEY (materialId, typeId)
);
INSERT INTO "materialSignature" 
VALUES(100510,101,'71a594493ea7f5ee383bbfbaa873d3331591f34cf3c95c7c77527 
ea7ed87220759a501e96837a0c34c52c2c45509135ce9a1bd71da8556daf391a715bb2cf 
e43bbc965a117d0220eec70ca37a1183963e58bf7dad2e3c088462ef4973ca2fefd542bc 
899d13ee5f64fc14a9c88642ece76a72068179e7bad8f0992cc234e380eaa87df3b6b509 
16dbe0286cf0a5e71249e0f4893b090701f8a796de54b2a16eef067613c6760d711404ca 
d49971eed6514bc3fc109f9dead035f7497c1ce4961843a3e2106ccefc6886567ea3e1b9 
06f5feb9497449249182d7e19855d595c83595ffba4f3719a7af9254be032930cd946e19 
bdc42c2c250f48d42223a87a547');
INSERT INTO "materialSignature" 
VALUES(100610,101,'3dbda21a11b7b5cac81014ad8fbf129ed90530ba1834d9ce6f17f 
fa79e7344ed8fb28343f411c55c223b053cdd1bc71415be8aa1fcc977ff1172c86d1aa90 
6af590f37ed04e131927b3aecc62ef54efee7cc22fc0ad9ec39f3e51dde6d7957dca85f8 
914d40cf1b1912cfdd6ed513e21472363371f6a08b31f9b6d03792f0a1817f3ea52df742 
3f6e26c6aa6647d37668eaaa2d59783a5a3d5c904ef60496338f68ac4ce7e63f1832737b 
3bb4499d2eb33247f8bd87f075b2ae37c2bb63b7c1fe289543f33dd8dfbfb0425a3238c3 
c5d563d8c4f0c4a92a08666f1891f7a198c3db6ea07624af41ea42e0fb9bee47c18f7e71 
e1d39eb2913d54ef650de7eb8b8');
[...]

.dump recipeNote
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE recipeNote (
    recipeId UNSIGNED BIGINT NOT NULL PRIMARY KEY,
    noteText VARCHAR NOT NULL,
    hash VARCHAR NOT NULL
);
COMMIT;

.dump categoryLang
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE categoryLang (
    categoryId UNSIGNED BIGINT NOT NULL REFERENCES categoryBin ON DELETE 
CASCADE ON UPDATE CASCADE,
    localeId INTEGER NOT NULL,
    title VARCHAR NOT NULL,
    sortKey VARCHAR NOT NULL,
    PRIMARY KEY (categoryId, localeId)
);
INSERT INTO "categoryLang" VALUES(2,1,'Soups','KCOEK    ');
INSERT INTO "categoryLang" VALUES(2,2,'Suppen','KOEE/A
▒       ');
INSERT INTO "categoryLang" VALUES(2,3,'Soupes','KCOE/K
▒       ');
INSERT INTO "categoryLang" VALUES(2,4,'Sopas','KCE''K   ');
INSERT INTO "categoryLang" VALUES(2,5,'Zuppe, passati e 
minestre','YOEE/E''KK''M7/?7A/KMI/▒');
INSERT INTO "categoryLang" VALUES(2,6,'Sopas','KCE''K   ');
INSERT INTO "categoryLang" VALUES(2,7,'Zupy','YOE▒');
[...]

.dump dataExt
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE dataExt (
    dataExtType_id INTEGER NOT NULL PRIMARY KEY,
    value VARCHAR NOT NULL
);
INSERT INTO "dataExt" VALUES(1,'2.0.2');
INSERT INTO "dataExt" VALUES(2,'2016-06-09 15:03:58');
INSERT INTO "dataExt" VALUES(3,'0');
COMMIT;

.dump metadata
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE metadata (
    typeId UNSIGNED BIGINT NOT NULL PRIMARY KEY,
    value VARCHAR);
INSERT INTO "metadata" VALUES(1,NULL);
INSERT INTO "metadata" VALUES(4,NULL);
INSERT INTO "metadata" VALUES(5,NULL);
INSERT INTO "metadata" VALUES(6,NULL);
INSERT INTO "metadata" VALUES(7,NULL);
INSERT INTO "metadata" VALUES(10,NULL);
INSERT INTO "metadata" VALUES(3,'6');
INSERT INTO "metadata" VALUES(2,'2');
INSERT INTO "metadata" VALUES(8,'3');
COMMIT;


.dump recipeSignature
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE recipeSignature (
    recipeId UNSIGNED BIGINT NOT NULL REFERENCES recipeBin ON DELETE 
CASCADE ON UPDATE CASCADE,
    typeId INTEGER NOT NULL,
    signature VARCHAR NOT NULL,
    PRIMARY KEY (recipeId, typeId)
);
INSERT INTO "recipeSignature" 
VALUES(47857,101,'6af76679f19201dbb287016da4ef78aff06218b7430f40bdbe8afb 
e794804ec119d2289f6285393ca57dff8d99327507fa6f17d47b403be6d68a5694f3f3f2 
944137b31d2f02132af03e3be18bb6ac45eebfb0afd17d36c9b28fde1d61b687d83576c0 
7e1e2d3581da553bd5f712f1ecc07ad81ea687d457b1640042122fc68ea58d5128d21045 
99b1a269b4019df14c2ab1db0adf403c639fe933a24b81f638b705bd202342be476abad6 
e6413698d2f064347b6b4b391e0a469e28e31c99da545efeac36dae1304644953eda2ce7 
3cfeb499f9f900b8bd99340dfc799c4b0fd54f1c3f67a3cd39e15aa925659c752b2804ce 
83c6a6a8f739b3579a5a53c573');
[...]



sqlite3 settings_cloud.sdb
SQLite version 3.11.0 2016-02-15 17:29:24
Enter ".help" for usage hints.
sqlite> .tables
dataCloud              settingsCloudApp       vendorMapping
dataCloudType          settingsCloudAppDebug

.dump dataCloud
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE dataCloud (
    dataCloudType_id INTEGER NOT NULL PRIMARY KEY REFERENCES 
dataCloudType ON DELETE CASCADE ON UPDATE RESTRICT,
    value VARCHAR NOT NULL
);
INSERT INTO "dataCloud" VALUES(1,'1.0.2');
INSERT INTO "dataCloud" VALUES(2,'2014-10-24 11:32:44');
COMMIT;

 .dump dataCloudType
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE dataCloudType (
    id INTEGER NOT NULL PRIMARY KEY,
    type VARCHAR NOT NULL
);
INSERT INTO "dataCloudType" VALUES(1,'cloudSettingsDbVersion');
INSERT INTO "dataCloudType" VALUES(2,'cloudSettingsDbDate');

sqlite> .dump settingsCloudApp
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE "settingsCloudApp" ("id" INTEGER PRIMARY KEY  NOT NULL 
,"remoteAddress" CLOB NOT NULL ,"TCPPort" INTEGER NOT NULL ,"remotePath" 
CLOB NOT NULL ,"pingAddress" CLOB NOT NULL );
INSERT INTO "settingsCloudApp" 
VALUES(1,'css.tmecosys.com',443,'/ws','l.root-servers.net');

sqlite> .dump settingsCloudAppDebug
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE "settingsCloudAppDebug" ("id" INTEGER PRIMARY KEY  NOT NULL 
,"mac" STRING NOT NULL ,"ssn" STRING NOT NULL );
INSERT INTO "settingsCloudAppDebug" 
VALUES(1,'AABBCCDDEEFF','0123456789ABCDEF');
COMMIT;

sqlite> .dump vendorMapping
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE "vendorMapping" ("id" INTEGER PRIMARY KEY  NOT NULL 
,"vendor_id" VARCHAR NOT NULL ,"vendor_char" VARCHAR NOT NULL );
INSERT INTO "vendorMapping" VALUES(1,'001343','A');
COMMIT;

The tm5.img can not be mounted (using e.g., losetup in aes128 mode with 
the password in the cookey.txt file). Cryptsetup does not recognize it 
as a LUKS volume:
cryptsetup luksDump tm5.img
Device tm5.img is not a valid LUKS device.

so that's it for partition 1. Moving to partition 2:
cd ../d2
ls
15272373012203516.ell  ext.sdb  ext.sdb-wal  material 
settings_cloud.sdb  tm5.img


the only new item is 15272373012203516.ell which seems purely random 
(according to strings/hexdump output and analysis with binwalk).


The one thing that bothers me is that we seem to know where updates are 
being downloaded from but Ican't figure a way to build the exact URL to 
attempt retrieving e.g., the latest firmware.

I've inspected the main executable /opt/Thermomix/Thermomix a bit and 
found the class KeyStoreDevice which seems to handle loading encryption 
keys from /dev/ks via an ioctl. Do we have access to the kernel source 
code?

Hi,

We don't have access to the kernel as we are missing the /boot volume in 
the dump that was provided.

Getting kernel out is going to be bit harder as it seems to be stored as 
a raw bootstream on the first flash chip. There are some hints on using 
OTP keys for security, but they seems to be set to 0s for now. My root 
access is still "tethered" but I might be getting closer to a perma-root 
soon.

# dmesg
[    0.000000] Linux version 2.6.35.14-571-gcca29a0 
(jenkins@tm5dev-VirtualBox) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #1 
PREEMPT Mon May 23 11:22:20 CEST 2016
[    0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), 
cr=00053177
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: Freescale MX28EVK board
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] On node 0 totalpages: 32768
[    0.000000] free_area_init_node: node 0, pgdat c0401f8c, node_mem_map 
c0432000
[    0.000000]   DMA zone: 32 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 4064 pages, LIFO batch:0
[    0.000000]   Normal zone: 224 pages used for memmap
[    0.000000]   Normal zone: 28448 pages, LIFO batch:7
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on. 
Total pages: 32512
[    0.000000] Kernel command line: -e console= ro gpmi ubi.mtd=1 
rootfstype=squashfs root=254:0 lpj=1130496 vt.global_cursor_default=0 
quiet
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 
bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 
bytes)
[    0.000000] Memory: 128MB = 128MB total
[    0.000000] Memory: 125652k/125652k available, 5420k reserved, 0K 
highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     DMA     : 0xfde00000 - 0xffe00000   (  32 MB)
[    0.000000]     vmalloc : 0xc8800000 - 0xf0000000   ( 632 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .init : 0xc0008000 - 0xc0040000   ( 224 kB)
[    0.000000]       .text : 0xc0040000 - 0xc03dd000   (3700 kB)
[    0.000000]       .data : 0xc03de000 - 0xc0402980   ( 147 kB)
[    0.000000] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, 
CPUs=1, Nodes=1
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU-based detection of stalled CPUs is disabled.
[    0.000000]  Verbose stalled-CPUs detection is disabled.
[    0.000000] NR_IRQS:288
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Calibrating delay loop (skipped) preset value.. 226.09 
BogoMIPS (lpj=1130496)
[    0.000000] pid_max: default: 4096 minimum: 301
[    0.000000] Mount-cache hash table entries: 512
[    0.000000] CPU: Testing write buffer coherency: ok
[    0.000000] regulator: core version 0.5
[    0.000000] NET: Registered protocol family 16
[    0.000000] regulator: vddd: 800 <--> 1575 mV at 1500 mV fast normal
[    0.000000] regulator: vdddbo: 800 <--> 1575 mV fast normal
[    0.000000] regulator: vdda: 1500 <--> 2275 mV at 1800 mV fast normal
[    0.000000] vddio = 3380000, val=10
[    0.010000] regulator: vddio: 2880 <--> 3680 mV at 3380 mV fast 
normal
[    0.010000] regulator: overall_current: fast normal
[    0.010000] regulator: vbus5v:
[    0.010000] regulator: mxs-duart-1: fast normal
[    0.010000] regulator: mxs-bl-1: fast normal
[    0.010000] regulator: mxs-i2c-1: fast normal
[    0.010000] regulator: mmc_ssp-1: fast normal
[    0.010000] regulator: mmc_ssp-2: fast normal
[    0.010000] regulator: charger-1: fast normal
[    0.010000] regulator: power-test-1: fast normal
[    0.010000] regulator: cpufreq-1: fast normal
[    0.010000] i.MX IRAM pool: 120 KB@0xc8820000
[    0.010000] Initializing GPMI pins
[    0.020000] bio: create slab <bio-0> at 0
[    0.020000] SCSI subsystem initialized
[    0.020000] usbcore: registered new interface driver usbfs
[    0.020000] usbcore: registered new interface driver hub
[    0.030000] usbcore: registered new device driver usb
[    0.030000] Advanced Linux Sound Architecture Driver Version 1.0.23.
[    0.030000] cfg80211: Calling CRDA to update world regulatory domain
[    0.030000] Switching to clocksource mxs clock source
[    0.040000] NET: Registered protocol family 2
[    0.040000] IP route cache hash table entries: 1024 (order: 0, 4096 
bytes)
[    0.040000] TCP established hash table entries: 4096 (order: 3, 32768 
bytes)
[    0.040000] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[    0.040000] TCP: Hash tables configured (established 4096 bind 4096)
[    0.040000] TCP reno registered
[    0.040000] NET: Registered protocol family 1
[    0.040000] Bus freq driver module loaded
[    0.040000] IMX usb wakeup probe
[    0.050000] the wakeup pdata is 0xc03e5b34
[    0.050000] usb h1 wakeup device is registered
[    0.050000] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.050000] msgmni has been set to 245
[    0.050000] cryptodev: driver loaded.
[    0.050000] Block layer SCSI generic (bsg) driver version 0.4 loaded 
(major 254)
[    0.050000] io scheduler noop registered
[    0.050000] io scheduler deadline registered
[    0.050000] io scheduler cfq registered (default)
[    0.070000] Programming PFD=20,DIV=48 ref_pix=432MHz PIXCLK=9MHz 
cycle=222.222ns
[    0.080000] Console: switching to colour frame buffer device 60x34
[    0.090000] mxs-duart.0: ttyAM0 at MMIO 0x80074000 (irq = 47) is a 
DebugUART
[    0.090000] mxs-auart.0: ttySP0 at MMIO 0x8006a000 (irq = 112) is a 
mxs-auart.0
[    0.090000] Found APPUART 3.1.0
[    0.090000] mxs-auart.1: ttySP1 at MMIO 0x8006c000 (irq = 113) is a 
mxs-auart.1
[    0.090000] Found APPUART 3.1.0
[    0.100000] loop: module loaded
[    0.100000] i.MX GPMI NFC
[    0.100000] NFC: Version 1, 8-chip GPMI and BCH
[    0.100000] Boot ROM: Version 1, Single-chip boot area, block mark 
swapping supported
[    0.100000] Scanning for NAND Flash chips...
[    0.100000] NAND device: Manufacturer ID: 0xc2, Chip ID: 0xf1 
(Macronix NAND 128MiB 3,3V 8-bit)
[    0.140000] -----------------------------
[    0.140000] NAND Flash Device Information
[    0.140000] -----------------------------
[    0.140000] Manufacturer      : Macronix (0xc2)
[    0.140000] Device Code       : 0xf1
[    0.140000] Cell Technology   : SLC
[    0.140000] Chip Size         : 128 MiB
[    0.140000] Pages per Block   : 64
[    0.140000] Page Geometry     : 2048+64
[    0.140000] ECC Strength      : 1 bits
[    0.140000] ECC Size          : 512 B
[    0.140000] Data Setup Time   : 5 ns
[    0.140000] Data Hold Time    : 5 ns
[    0.140000] Address Setup Time: 15 ns
[    0.140000] GPMI Sample Delay : 6 ns
[    0.140000] tREA              : 20 ns
[    0.140000] tRLOH             : 4294967295 ns
[    0.140000] tRHOH             : 4294967295 ns
[    0.140000] Description       : MX30LF1G08AA
[    0.140000] -----------------
[    0.140000] Physical Geometry
[    0.140000] -----------------
[    0.140000] Chip Count             : 1
[    0.140000] Page Data Size in Bytes: 2048 (0x800)
[    0.140000] Page OOB Size in Bytes : 64
[    0.140000] Block Size in Bytes    : 131072 (0x20000)
[    0.140000] Block Size in Pages    : 64 (0x40)
[    0.140000] Chip Size in Bytes     : 134217728 (0x8000000)
[    0.140000] Chip Size in Pages     : 65536 (0x10000)
[    0.140000] Chip Size in Blocks    : 1024 (0x400)
[    0.140000] Medium Size in Bytes   : 134217728 (0x8000000)
[    0.140000] ------------
[    0.140000] NFC Geometry
[    0.140000] ------------
[    0.140000] ECC Algorithm          : BCH
[    0.140000] ECC Strength           : 8
[    0.140000] Page Size in Bytes     : 2112
[    0.140000] Metadata Size in Bytes : 10
[    0.140000] ECC Chunk Size in Bytes: 512
[    0.140000] ECC Chunk Count        : 4
[    0.140000] Payload Size in Bytes  : 2048
[    0.140000] Auxiliary Size in Bytes: 16
[    0.140000] Auxiliary Status Offset: 12
[    0.140000] Block Mark Byte Offset : 1999
[    0.140000] Block Mark Bit Offset  : 0
[    0.140000] -----------------
[    0.140000] Boot ROM Geometry
[    0.140000] -----------------
[    0.140000] Boot Area Count            : 1
[    0.140000] Boot Area Size in Bytes    : 13107200 (0xc80000)
[    0.140000] Stride Size in Pages       : 64
[    0.140000] Search Area Stride Exponent: 3
[    0.140000] Scanning device for bad blocks
[    0.140000] Bad eraseblock REDACTED at 0xREDACTED
[    0.170000] Bad eraseblock REDACTED at 0xREDACTED
[    0.180000] Bad eraseblock REDACTED at 0xREDACTED
[    0.200000] Bad eraseblock REDACTED at 0xREDACTED
[    0.220000] Bad eraseblock REDACTED at 0xREDACTED
[    0.230000] -----------------------------
[    0.230000] NAND Flash Device Information
[    0.230000] -----------------------------
[    0.230000] Manufacturer      : Macronix (0xc2)
[    0.230000] Device Code       : 0xf1
[    0.230000] Cell Technology   : SLC
[    0.230000] Chip Size         : 128 MiB
[    0.230000] Pages per Block   : 64
[    0.230000] Page Geometry     : 2048+64
[    0.230000] ECC Strength      : 1 bits
[    0.230000] ECC Size          : 512 B
[    0.230000] Data Setup Time   : 5 ns
[    0.230000] Data Hold Time    : 5 ns
[    0.230000] Address Setup Time: 15 ns
[    0.230000] GPMI Sample Delay : 6 ns
[    0.230000] tREA              : 20 ns
[    0.230000] tRLOH             : 4294967295 ns
[    0.230000] tRHOH             : 4294967295 ns
[    0.230000] Description       : MX30LF1G08AA
[    0.230000] ------------
[    0.230000] NFC Geometry
[    0.230000] ------------
[    0.230000] ECC Algorithm          : BCH
[    0.230000] ECC Strength           : 8
[    0.230000] Page Size in Bytes     : 2112
[    0.230000] Metadata Size in Bytes : 10
[    0.230000] ECC Chunk Size in Bytes: 512
[    0.230000] ECC Chunk Count        : 4
[    0.230000] Payload Size in Bytes  : 2048
[    0.230000] Auxiliary Size in Bytes: 16
[    0.230000] Auxiliary Status Offset: 12
[    0.230000] Block Mark Byte Offset : 1999
[    0.230000] Block Mark Bit Offset  : 0
[    0.230000] Boot area protection is enabled.
[    0.230000] Creating 2 MTD partitions on "gpmi-nfc-main":
[    0.230000] 0x000000000000-0x000000c80000 : "gpmi-nfc-0-boot"
[    0.230000] 0x000000c80000-0x000008000000 : "gpmi-nfc-general-use"
[    0.230000] UBI: attaching mtd1 to ubi0
[    0.230000] UBI: physical eraseblock size:   131072 bytes (128 KiB)
[    0.230000] UBI: logical eraseblock size:    126976 bytes
[    0.230000] UBI: smallest flash I/O unit:    2048
[    0.230000] UBI: VID header offset:          2048 (aligned 2048)
[    0.230000] UBI: data offset:                4096
[    0.790000] UBI: attached mtd1 to ubi0
[    0.790000] UBI: MTD device name:            "gpmi-nfc-general-use"
[    0.790000] UBI: MTD device size:            115 MiB
[    0.790000] UBI: number of good PEBs:        920
[    0.790000] UBI: number of bad PEBs:         4
[    0.790000] UBI: max. allowed volumes:       128
[    0.790000] UBI: wear-leveling threshold:    4096
[    0.790000] UBI: number of internal volumes: 1
[    0.790000] UBI: number of user volumes:     3
[    0.790000] UBI: available PEBs:             0
[    0.790000] UBI: total number of reserved PEBs: 920
[    0.790000] UBI: number of PEBs reserved for bad PEB handling: 27
[    0.790000] UBI: max/mean erase counter: 39/16
[    0.790000] UBI: image sequence number: 1768905211
[    0.790000] UBI: background thread "ubi_bgt1d" started, PID 18
[    0.790000]  ubiblka:
[    0.790000] UBI: background thread "ubi_bgt0d" started, PID 17
[    0.790000]  unknown partition table
[    0.790000]  ubiblkb: unknown partition table
[    0.800000]  ubiblkc: unknown partition table
[    0.800000] PPP generic driver version 2.4.2
[    0.800000] PPP Deflate Compression module registered
[    0.800000] usbcore: registered new interface driver usb8xxx
[    0.800000] usbcore: registered new interface driver cdc_acm
[    0.800000] cdc_acm: v0.26:USB Abstract Control Model driver for USB 
modems and ISDN adapters
[    0.800000] Probing ALPMXS driver
[    0.800000] input: alpmxs-rotary-encoder as 
/devices/platform/alpmxs-rotary-encoder.0/input/input0
[    0.800000] mxs watchdog: initialized, heartbeat 19 sec
[    0.800000] dcp dcp.0: DCP crypto enabled.!
[    0.800000] key_store: driver loaded
[    0.820000] sgtl5000-i2c 0-000a: SGTL5000 revision 17
[    0.820000] No device for DAI mxs-saif
[    0.820000] asoc: SGTL5000 <-> mxs-saif mapping ok
[    0.860000] Failed to add route LINE_OUT->Ext Spk
[    0.860000] ALSA device list:
[    0.860000]   #0: mxs-evk (SGTL5000)
[    0.860000] TCP cubic registered
[    0.860000] NET: Registered protocol family 17
[    0.860000] Touchscreen driver init called.
[    0.860000] Touchscreen driver probe called.
[    0.860000] nt1103-ts 0-0001: Install touch driver.
[    1.030000] nt1103-ts 0-0001: 
test_data[1]=187,test_data[2]=245,test_data[3]=190,test_data[4]=242,test 
_data[5]=0
[    1.030000] nt1103-ts 0-0001: Configuration read: 0C F3 12 0A 04 40 
02 40 0A 02 04 00 00 01 04
[    1.030000] nt1103-ts 0-0001: ts->x_num = 18
[    1.030000] nt1103-ts 0-0001: ts->y_num = 10
[    1.030000] nt1103-ts 0-0001: ts->abs_x_max = 1088
[    1.030000] nt1103-ts 0-0001: ts->abs_y_max = 576
[    1.030000] nt1103-ts 0-0001: ts->max_touch_num = 2
[    1.030000] nt1103-ts 0-0001: ts->max_button_num = 4
[    1.030000] nt1103-ts 0-0001: ts->int_trigger_type = 0
[    1.030000] nt1103-ts 0-0001: ts->fwVersion = V243
[    1.030000] nt1103-ts 0-0001: ts->chipID = 4
[    1.030000] nt1103-ts 0-0001: Touchscreen works in IIC wake-up green 
mode
[    1.070000] nt1103-ts 0-0001: Date code read: 32 32 32 32 32 30 30 30 
30 30 30 2D 30 30 30 30
[    1.070000] nt1103-ts 0-0001: Date code signature check failed! (2)
[    1.090000] input: Nt11003 Capacitive TouchScreen as 
/devices/virtual/input/input1
[    1.090000] nt1103-ts 0-0001: FW version = 243
[    1.110000] NT11004 IOCTL: successfully initialized
[    1.130000] nt1103-ts 0-0001: Reques EIRQ 264 succesd on GPIO:136
[    1.130000] nt1103-ts 0-0001: Start Nt11003 Capacitive TouchScreen in 
interrupt mode
[    1.130000] Warning: unable to open an initial console.
[    1.130000] VFS: Mounted root (squashfs filesystem) readonly on 
device 254:0.
[    1.970000] UBIFS: mounted UBI device 0, volume 2, name "data"
[    1.970000] UBIFS: file system size:   71868416 bytes (70184 KiB, 68 
MiB, 566 LEBs)
[    1.970000] UBIFS: journal size:       9023488 bytes (8812 KiB, 8 
MiB, 72 LEBs)
[    1.970000] UBIFS: media format:       w4/r0 (latest is w4/r0)
[    1.970000] UBIFS: default compressor: zlib
[    1.970000] UBIFS: reserved for root:  0 bytes (0 KiB)
[   11.350000] Running do_deferred_initcalls()
[   11.350000] usbcore: registered new interface driver asix
[   11.350000] usbcore: registered new interface driver ax88179_178a
[   11.350000] usbcore: registered new interface driver MOSCHIP 
usb-ethernet driver
[   11.350000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) 
Driver
[   11.360000] fsl-ehci fsl-ehci: Freescale On-Chip EHCI Host Controller
[   11.360000] fsl-ehci fsl-ehci: new USB bus registered, assigned bus 
number 1
[   11.390000] fsl-ehci fsl-ehci: irq 92, io base 0x80090000
[   11.410000] fsl-ehci fsl-ehci: USB 2.0 started, EHCI 1.00
[   11.410000] hub 1-0:1.0: USB hub found
[   11.410000] hub 1-0:1.0: 1 port detected
[   11.410000] Initializing USB Mass Storage driver...
[   11.410000] usbcore: registered new interface driver usb-storage
[   11.410000] USB Mass Storage support registered.
[   11.410000] Freeing init memory: 224K
... REDACTED


# cat /proc/devices
cat /proc/devices
Character devices:
  1 mem
  4 /dev/vc/0
  4 tty
  5 /dev/tty
  5 /dev/console
  5 /dev/ptmx
  7 vcs
 10 misc
 13 input
 14 sound
 29 fb
 90 mtd
100 nt1104-ioctl
108 ppp
116 alsa
128 ptm
136 pts
166 ttyACM
180 usb
189 usb_device
204 ttyAM
242 ttySP
253 ubi0
254 bsg

Block devices:
259 blkext
  7 loop
  8 sd
 11 sr
 65 sd
 66 sd
 67 sd
 68 sd
 69 sd
 70 sd
 71 sd
128 sd
129 sd
130 sd
131 sd
132 sd
133 sd
134 sd
135 sd
254 ubiblk
/usr/sbin # ls /dev/ubiblk
ls /dev/ubiblk
ls: /dev/ubiblk: No such file or directory
/usr/sbin # ls -l /dev/ubi*
ls -l /dev/ubi*
crw-rw-rw-    1 root     root     253,   1 May 23  2016 /dev/ubi0_0
crw-rw-rw-    1 root     root     253,   2 May 23  2016 /dev/ubi0_1
crw-rw-rw-    1 root     root     253,   3 May 23  2016 /dev/ubi0_2
/usr/sbin # mount
mount
rootfs on / type rootfs (rw)
/dev/root on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
sys on /sys type sysfs (rw,relatime)
rwfs on /mnt/rwfs type tmpfs (rw,relatime,size=512k)
rwfs on /tmp type tmpfs (rw,relatime,size=512k)
rwfs on /var type tmpfs (rw,relatime,size=512k)
rwfs on /etc type tmpfs (rw,relatime,size=512k)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
ubi0:data on /mnt/rwfs/data type ubifs (rw,noexec,relatime,compr=zlib)
/tmp/dev/sda1 on /tmp/sda1 type ext2 
(ro,relatime,barrier=1,stripe=128,data=ordered)
/tmp/dev/sda2 on /tmp/sda2 type ext4 
(rw,noatime,commit=2,barrier=1,nodelalloc,data=journal)

# kobs-ng dump -v
kobs-ng dump -v
MTD CONFIG:
  chip_0_device_path = "/dev/mtd0"
  chip_1_device_path = "(null)"
  search_exponent = 3
  data_setup_time = 40
  data_hold_time = 40
  address_setup_time = 40
  data_sample_time = 6
  row_address_size = 3
  column_address_size = 2
  read_command_code1 = 0
  read_command_code2 = 48
  boot_stream_major_version = 1
  boot_stream_minor_version = 0
  boot_stream_sub_version = 0
  ncb_version = 3
  boot_stream_1_address = 0
  boot_stream_2_address = 0
mtd: opening: "/dev/mtd0"
mtd: '/dev/mtd0' bad block @ REDACTED (MTD)
NFC Geometry
  ECC Algorithm          : BCH
  ECC Strength           : 8
  Page Size in Bytes     : 2112
  Metadata Size in Bytes : 10
  ECC Chunk Size in Bytes: 512
  ECC Chunk Count        : 4
  Payload Size in Bytes  : 2048
  Auxiliary Size in Bytes: 16
  Auxiliary Status Offset: 12
  Block Mark Byte Offset : 1999
  Block Mark Bit Offset  : 0
mtd: opened '/dev/mtd0' - '(null)'
mtd: partition #0
  type = 4
  flags = 1024
  size = 13107200
  erasesize = 131072
  writesize = 2048
  oobsize = 64
  blocks = 100
  BAD: REDACTED
mtd: valid FCB found @0:0x0
mtd: valid DBBT found @0:0x100000
  m_u32Checksum = -3280
  m_u32FingerPrint = 541213510
  m_u32Version = 16777216
FCB
  m_NANDTiming.m_u8DataSetup = 40
  m_NANDTiming.m_u8DataHold = 40
  m_NANDTiming.m_u8AddressSetup = 40
  m_NANDTiming.m_u8DSAMPLE_TIME = 6
  m_u32DataPageSize = 2048
  m_u32TotalPageSize = 2112
  m_u32SectorsPerBlock = 64
  m_u32NumberOfNANDs = 0
  m_u32TotalInternalDie = 0
  m_u32CellType = 0
  m_u32EccBlockNEccType = 4
  m_u32EccBlock0Size = 512
  m_u32EccBlockNSize = 512
  m_u32EccBlock0EccType = 4
  m_u32MetadataBytes = 10
  m_u32NumEccBlocksPerPage = 3
  m_u32EccBlockNEccLevelSDK = 0
  m_u32EccBlock0SizeSDK = 0
  m_u32EccBlockNSizeSDK = 0
  m_u32EccBlock0EccLevelSDK = 0
  m_u32NumEccBlocksPerPageSDK = 0
  m_u32MetadataBytesSDK = 0
  m_u32EraseThreshold = 0
  m_u32BootPatch = 0
  m_u32PatchSectors = 0
  m_u32Firmware1_startingSector = 1024
  m_u32Firmware2_startingSector = 3712
  m_u32SectorsInFirmware1 = 1101
  m_u32SectorsInFirmware2 = 1101
  m_u32DBBTSearchAreaStartAddress = 512
  m_u32BadBlockMarkerByte = 1999
  m_u32BadBlockMarkerStartBit = 0
  m_u32BBMarkerPhysicalOffset = 2048
  m_u32NumberBB = 1
  m_u32Number2KPagesBB = 1
Firmware: image #0 @ 0x200000 size 0x226800 - available 0x540000
Firmware: image #1 @ 0x740000 size 0x226800 - available 0x540000
TM41
  m_u32UpdateStatus = 0
BBTN
  uNAND = 0
  uNumberBB = 1
  BADBLOCKS:
     REDACTED
/ # kobs-ng extract -v -z -0 /tmp/sda2/bootstream0
kobs-ng extract -v -z -0 /tmp/sda2/bootstream0
MTD CONFIG:
  chip_0_device_path = "/dev/mtd0"
  chip_1_device_path = "(null)"
  search_exponent = 3
  data_setup_time = 40
  data_hold_time = 40
  address_setup_time = 40
  data_sample_time = 6
  row_address_size = 3
  column_address_size = 2
  read_command_code1 = 0
  read_command_code2 = 48
  boot_stream_major_version = 1
  boot_stream_minor_version = 0
  boot_stream_sub_version = 0
  ncb_version = 3
  boot_stream_1_address = 0
  boot_stream_2_address = 0
mtd: opening: "/dev/mtd0"
mtd: '/dev/mtd0' bad block @ REDACTED (MTD)
NFC Geometry
  ECC Algorithm          : BCH
  ECC Strength           : 8
  Page Size in Bytes     : 2112
  Metadata Size in Bytes : 10
  ECC Chunk Size in Bytes: 512
  ECC Chunk Count        : 4
  Payload Size in Bytes  : 2048
  Auxiliary Size in Bytes: 16
  Auxiliary Status Offset: 12
  Block Mark Byte Offset : 1999
  Block Mark Bit Offset  : 0
mtd: opened '/dev/mtd0' - '(null)'
mtd: partition #0
  type = 4
  flags = 1024
  size = 13107200
  erasesize = 131072
  writesize = 2048
  oobsize = 64
  blocks = 100
  BAD: REDACTED
mtd: valid FCB found @0:0x0
mtd: valid DBBT found @0:0x100000
startpage=1024, size=1101
/tmp/sda2/bootstream0: verifying using key 
'00000000000000000000000000000000'
boot image header:
  m_digest = f7c2ca53f8334064b88a0b73ecbf6407ac831b16
  m_signature = STMP
  m_majorVersion = 1
  m_minorVersion = 1
  m_flags = ROM_DISPLAY_PROGRESS (1)
  m_imageBlocks = 140814
  m_firstBootTagBlock = 9
  m_firstBootableSectionID = 0
  m_keyCount = 1
  m_keyDictionaryBlock = 7
  m_headerBlocks = 6
  m_sectionCount = 1
  m_sectionHeaderSize = 1
  m_timestamp = REDACTED
  m_productVersion.m_major = 0x9909
  m_productVersion.m_minor = 0x9909
  m_productVersion.m_revision = 0x9909
  m_componentVersion.m_major = 0x9909
  m_componentVersion.m_minor = 0x9909
  m_componentVersion.m_revision = 0x9909
  m_driveTag = 0
* Using user supplied key='00000000000000000000000000000000'
section header #0:
  m_identifier = 0
  m_offset = 10
  m_length = 140802
  m_flags = ROM_SECTION_BOOTABLE (0x1)
* calculated-mac = 8004eef4307572cdb125ab3af9d3e7d3
dek dictionary entry #0:
  m_mac = ca8e70ddf85c07801206b40f3397459f
  m_dek = f9b7c852a484a430f7d5eba2855b231e
Unable to find a matching key dictionary
/tmp/sda2/bootstream0: is a valid bootstream for key 
'00000000000000000000000000000000'

/ # ls -l /tmp/sda2/bootstream0
-rw-r--r--    1 root     root       118124 Jan  1 00:49 bootstream0

This is obviously too small for a kernel, so the bootstream needs to be 
decoded first which would yield a pagelist to be loaded from the NAND.

(and I just doxxed myself, oh... well...)

Ikaro P. schrieb:
> Getting kernel out is going to be bit harder as it seems to be stored as
> a raw bootstream on the first flash chip. There are some hints on using
> OTP keys for security, but they seems to be set to 0s for now. My root
> access is still "tethered" but I might be getting closer to a perma-root
> soon.

Great work Ikaro! I knew and know you can hack this "little" beast so we 
can build our own chips with our own recipes! :D

Have you or could you test if it would be possible to used unencrypted 
chips with the variable RDV at /etc/rc.d/rc.local changed to 1 (the "no 
support" is a probably a typo, as it activates the "Recipe Development 
Version"):

# set global variable RDV, which is then read by netlink
# Possible values: 0 - not RDV version, no support for pirated cookie
(EXT4 formatted cookie).
#                  1 - RDV version, no support for pirated cookie.
export RDV=0
echo "Set Recipe Development Version to $RDV"

Update on cooksticks encryption:

I managed to get GUI running in an emulator with a debugging mode
enabled so I can actually see what is the netlink trying to do when
cookstick is inserted.

NETLINK-INFO: 0h8m13s348ms: virtual void
KernelListener::processEvent(size_t) adding event
NL_ADD_STORAGE_PARTITION
[FSM] NETLINK-DEBUG: 0h8m13s349ms: [EVT-R] NL_ADD_STORAGE_PARTITION :
[/devices/pci0000:00/0000:00:0c.0/usb1/1-2/1-2:1.0/host1/target1:0:0/1:0
:0:0/block/sr1,  sr1]
NETLINK-DEBUG: 0h8m13s349ms: MAIN LOOP: started processing event:
NL_ADD_STORAGE_PARTITION
[/devices/pci0000:00/0000:00:0c.0/usb1/1-2/1-2:1.0/host1/target1:0:0/1:0
:0:0/block/sr1,  sr1]
NETLINK-DEBUG: 0h8m13s349ms: virtual void
GenericDeviceHandlingState::handleAddDevice(KernelEvent::DeviceType,
std::string, std::string)
NETLINK-DEBUG: 0h8m13s350ms: int ExecuteSystemCommand(std::string&) : rm
-f /tmp/dev/sr1
NETLINK-DEBUG: 0h8m13s450ms: int ExecuteSystemCommand(std::string&) :
mkdir -p /tmp/dev/
NETLINK-DEBUG: 0h8m13s469ms: int ExecuteSystemCommand(std::string&) :
mknod -m 644 /tmp/dev/loop1 b 7 1
NETLINK-DEBUG: 0h8m13s481ms: int ExecuteSystemCommand(std::string&) :
mknod -m 644 /tmp/dev/sr1 b 11 1
NETLINK-DEBUG: 0h8m13s496ms: int ExecuteSystemCommand(std::string&) :
mkdir -p /tmp/sr1
NETLINK-DEBUG: 0h8m13s516ms: int ExecuteSystemCommand(std::string&) :
losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1
NETLINK-ERROR: 0h8m13s937ms: System command losetup -e aes128 -P
/opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 returned 1
NETLINK-DEBUG: 0h8m13s938ms: int ExecuteSystemCommand(std::string&) :
mount -o ro /tmp/dev/loop1 /tmp/sr1
NETLINK-ERROR: 0h8m14s93ms: System command mount -o ro /tmp/dev/loop1
/tmp/sr1 returned 255
NETLINK-INFO: 0h8m14s126ms: Storage partition found at /tmp/sr1/ (S/N:
REDACTED
)
NETLINK-ERROR: 0h8m14s127ms: No valid cookstick recognized

But as you can see this fails:
$ losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1
ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length
(128 bits) not supported by kernel

Running losetup through strace shows us the culprit:
[pid 30043] ioctl(4, LOOP_GET_STATUS64, {lo_offset=0, lo_number=1,
lo_flags=LO_FLAGS_READ_ONLY, lo_file_name="", ...}) = 0
[pid 30043] ioctl(4, LOOP_SET_STATUS64, {lo_offset=0, lo_number=0,
lo_encrypt_type=0x10 /* LO_CRYPT_??? */, lo_encrypt_key_size=16,
lo_flags=0, lo_file_name="/dev/sr1", lo_crypt_name="",
lo_encrypt_key="#7\245\221f\271N,\373\360\317]S\273\276X", ...}) = -1
EINVAL (Invalid argument)
[pid 30043] ioctl(4, LOOP_SET_STATUS, {lo_number=0, lo_offset=0,
lo_encrypt_type=0x10 /* LO_CRYPT_??? */, lo_encrypt_key_size=16,
lo_flags=0, lo_name="/dev/sr1",
lo_encrypt_key="#7\245\221f\271N,\373\360\317]S\273\276X", ...}) = -1
EINVAL (Invalid argument)
[pid 30043] ioctl(4, LOOP_GET_STATUS64, {lo_offset=0, lo_number=1,
lo_flags=LO_FLAGS_READ_ONLY, lo_file_name="", ...}) = 0
[pid 30043] ioctl(4, LOOP_SET_STATUS64, {lo_offset=0, lo_number=0,
lo_encrypt_type=LO_CRYPT_CRYPTOAPI, lo_encrypt_key_size=16, lo_flags=0,
lo_file_name="/dev/sr1", lo_crypt_name="aes-cbc",
lo_encrypt_key="#7\245\221f\271N,\373\360\317]S\273\276X", ...}) = -1
EINVAL (Invalid argument)
[pid 30043] ioctl(4, LOOP_SET_STATUS, {lo_number=0, lo_offset=0,
lo_encrypt_type=LO_CRYPT_CRYPTOAPI, lo_encrypt_key_size=16, lo_flags=0,
lo_name="aes-cbc",
lo_encrypt_key="#7\245\221f\271N,\373\360\317]S\273\276X", ...}) = -1
EINVAL (Invalid argument)
[pid 30043] openat(AT_FDCWD,
"/usr/share/locale/en_US/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1
ENOENT (No such file or directory)
[pid 30043] openat(AT_FDCWD,
"/usr/share/locale/en/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT
(No such file or directory)
[pid 30043] openat(AT_FDCWD,
"/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No
such file or directory)
[pid 30043] openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libc.mo",
O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30043] write(2, "ioctl: LOOP_SET_STATUS: Invalid "..., 108ioctl:
LOOP_SET_STATUS: Invalid argument, requested cipher or key length (128
bits) not supported by kernel

The losetup binary is IFAIK not a vanilla one as it is trying to use
lo_encrypt_type=0x10 which is nowhere to be found on the internet. This
means we won't be able to decrypt cooksticks anywhere besides the
machine until we (I mean... until I :D) manage to extract the kernel and
revers-engineer the handler. Or maybe someone else here might get lucky
with the passed
lo_encrypt_key="#7\245\221f\271N,\373\360\317]S\273\276X" now?

I must once more commend Vorwerk for their job, as I've said before I do
security for living and as of now have never seen anything remotely good
as this. Well played Vorwerk, well played.

P.S. Comming soon might be a guide on running the GUI in an emulator,
for now it's not usable as the emulated touchscreen driver is sending
coordinated in 0-32768 range but the GUI needs them in screen pixels.
Clicking blindly in the left upper corner is just pain in the ass...

Ikaro P. schrieb:
> Update on cooksticks encryption:
>
> I managed to get GUI running in an emulator with a debugging mode
> enabled so I can actually see what is the netlink trying to do when
> cookstick is inserted.

Ikaro, you are doing a great work, you are the men! I would be happy if 
I would have a little percentage of your knowledge... :)
If you could publish a guide for setting up the GUI on a emulator where 
we can then attach an image from the cooksticks (or the real ones) to 
test them out would be awesome...
Regarding the "losetup" binary, if it was changed by Vorwerk with some 
custom encryption type, then there should be the source code for this, 
as it should be open source, right? Should be ask for it at 
opensource@vorwerk.de?

Thanks for all your current and future work on this! :)

Good so see more activity here :-)

Ikaro P. schrieb:
> Getting kernel out is going to be bit harder as it seems to be stored as
> a raw bootstream on the first flash chip. There are some hints on using
> OTP keys for security, but they seems to be set to 0s for now. My root
> access is still "tethered" but I might be getting closer to a perma-root
> soon.

Indeed, I also suspect them to be stored in the OTP bits of the MX28. 
What I can see from the code is that the driver must support at least 2 
ioctls. Both take an index (0..9) and one returns the length of the key 
and the other copies the key into a buffer to which you pass a pointer.

I also inspected the 'checkimg' executable and although it contains a 
lot of crypto functions statically linked in, it neither contains a 
single ioctl nor does it reference any external library. I'm sure that 
the firmware update key is statically linked into that executable.

> [    0.800000] key_store: driver loaded

That's the driver that handles the OTP crypto keys. To my surprise your 
kernel doesn't list the device under /proc/devices lateron explicitly. 
But it has major ID 10 (see /dev folder of your root filesystem) which 
is misc officially anyway and that is listed.

Ikaro P. schrieb:
> I managed to get GUI running in an emulator with a debugging mode
> enabled so I can actually see what is the netlink trying to do when
> cookstick is inserted.

Is it possible to share that emulator setup?

Ikaro P, how can you help you.
I'm lost in such deep linux world.

I don't how to continue on my side.

Ikaro, are you able to access the contents of the /mnt/rwfs ?
Any chance of sharing the uboot and kernel to boot the squashfs on qemu 
?

Best regards,

moin mädels,
wie damals angekündigt habe ich an einem html/js editor gebastelt. 
wollte ja eigentlich auf die endgültige struktur der datenbank warten 
bevor ich da weiter mache, aber ich habe hier so viele von "meinen" 
rezepten auf zetteln rumfliegen...
Sobald wir alle nötigen Daten haben um einen Export auf den Chip 
realisieren zu können (und der Editor dafür in Betracht kommt) steht 
einem gitProjekt nix im Wege. Ist alles unter GPL also kann jeder damit 
machen was er will.
Ich denke es ist immer leichter etwas zu verändern als von 0 zu starten 
also ab mit dem Teil in den upload...

hi girls,
i have uploaded a basic html/js editor for recipes that is waiting for 
more details about "the chip" to be usefull.
its very easy to implement another language so i hope that it could be 
used some day as our default editor to fill "the chip".

https://uploadfiles.io/euabu

Warum braucht Ihr den Chip zu hacken?
Man kann doch die URL Adresse von Cookidoe Server abhören und durch DNS 
auf eigenen Server umleiten. Der Server wird dann die ganze Rezepte 
bereitstellen.
So ähnlich wurden die Apple TV Boxen gehackt.

Gennadij D. schrieb:
> Warum braucht Ihr den Chip zu hacken?
> Man kann doch die URL Adresse von Cookidoe Server abhören und durch DNS
> auf eigenen Server umleiten. Der Server wird dann die ganze Rezepte
> bereitstellen.
> So ähnlich wurden die Apple TV Boxen gehackt.

Eben nicht!
Das ist alles SSL Verschlüsselt, da kannst nix mithören ;(

@Gennadij Degterjow: Interessante Idee.

Michael W. schrieb:
> Das ist alles SSL Verschlüsselt, da kannst nix mithören ;(

Auf welche Domain wird denn zugegriffen?
Wird das Zertifikat ausreichend auf Korrektheit geprüft?
Reicht ein selbstsigniertes Zertifikat?

Big thanks for your work, Ikaro P, we would not have any chance with 
that if we did not have 
you.(https://media3.giphy.com/media/3oEdva9BUHPIs2SkGk/giphy.gif) It 
seems like everyone else except you is stuck and because nobody seems to 
read the whole thread here, I think we should move to a subreddit with 
wiki to display all information orderly, like someone mentioned before. 
I will do that if I find any old reddit account of mine, I can not start 
a new subreddit with a just created account.

Ikaro P. schrieb:
> Sadly this is not possible for two reasons now:
> - the process of registration of the TM to the online system is probably
> the way the per device client certificate is issued and I think that one
> is used most of the time.
> - TM strictly enforces the verification of the server certificate.
> Public CA system is not used and the only certificates accepted must
> stem from Vorwerk's internal CA.
Did you ever notice that the per device certificate is used ? I dont got 
a TM5 by now, but there is a private cert key in your fw dump in 
/tmp/certificates/. Did someone ever really tried to fake the cookidoo 
website the TM5 is communicating with, or sniff some of the 
communication ?
This will be the first thing I will try when I got the TM5, as we could 
load our own recipes this way without any hardware modification. If the 
per device cert is really such important, could you register your TM to 
the online system and dump the fw again so we could look for the per 
device cert ?

Can anyone who sniffed the encrypted traffic share the capture here so I 
could try to decrypt the parts where the cert is used for that we 
already got the private key?

One other interesting thing would be to try to encrypt the offline 
recipes chip with the AES key found by you. I do not have any chip or 
the hardware to connect to it, but as I read here, some people allready 
got a working clone of the offline chip, and the problem with changing 
data on the chip is the verification with chip serial + AES key. We got 
that key now thanks to you. We should be able to change data on the 
stick now and that could also be a way to get our own recipes on the 
TM5.


Ikaro P. schrieb:
> P.S. Comming soon might be a guide on running the GUI in an emulator,
How did you emulate the touch screen ? I did not get further than "C530. 
Touch device not working.".

Thanks again for your great work, if there is anything you cannot say 
here please contact me at haschhans@emailn.de.

Hans H. schrieb:
> Did you ever notice that the per device certificate is used ? I dont got
> a TM5 by now, but there is a private cert key in your fw dump in
> /tmp/certificates/. Did someone ever really tried to fake the cookidoo
> website the TM5 is communicating with, or sniff some of the
> communication ?

I sniffed the communication some time ago when the Cookidoo chip entered 
the market, and yes, they use client cert authentication aggressively. I 
don't have the capture at hand, but AFAIR the key only communicates with 
a single HTTPS endpoint that expects the client cert. The only exception 
would be a first unencrypted request to synchronize the device's time 
(think NTP over HTTP).

Thomas H. schrieb:
> Hans H. schrieb:
>> Did you ever notice that the per device certificate is used ? I dont got
>> a TM5 by now, but there is a private cert key in your fw dump in
>> /tmp/certificates/. Did someone ever really tried to fake the cookidoo
>> website the TM5 is communicating with, or sniff some of the
>> communication ?
>
> I sniffed the communication some time ago when the Cookidoo chip entered
> the market, and yes, they use client cert authentication aggressively. I
> don't have the capture at hand, but AFAIR the key only communicates with
> a single HTTPS endpoint that expects the client cert. The only exception
> would be a first unencrypted request to synchronize the device's time
> (think NTP over HTTP).

Can you maybe do the sniff again if you don't have the capture ? I don't 
have the Cookidoo by now.

Ikaro P. schrieb:

> NETLINK-DEBUG: 0h8m13s516ms: int ExecuteSystemCommand(std::string&) :
> losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1
> NETLINK-ERROR: 0h8m13s937ms: System command losetup -e aes128 -P
> /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 returned 1
>
> But as you can see this fails:
> $ losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1
> ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length
> (128 bits) not supported by kernel
>
> The losetup binary is IFAIK not a vanilla one as it is trying to use
> lo_encrypt_type=0x10 which is nowhere to be found on the internet.

Hi Ikaro P.! I have found the source code for losetup that uses this 
encryption type: https://sourceforge.net/projects/loop-aes/

If we look at the samples 
(http://loop-aes.sourceforge.net/ciphers.README) we can see the 
following command:

losetup -p 0 -e AES128 /dev/loop0 /dev/hda666

This command is similar to the command used by the Thermomix:

losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1

Is it right? :)

I am not a programmer, but I think this is the needed part that will 
help complete the decryption method of the cookstick.

> P.S. Comming soon might be a guide on running the GUI in an emulator,
> for now it's not usable as the emulated touchscreen driver is sending
> coordinated in 0-32768 range but the GUI needs them in screen pixels.
> Clicking blindly in the left upper corner is just pain in the ass...

Can you please release the guide for running the Thermomix GUI even if 
the touchscreen driver is not fixed? Please? :)
Thanks!

Would be nice to see some update from you soon... Let's keep this 
project alive guys! :)

This losetup option (notably -e aes128) correspond to an old version of 
losetup. The losetup binary inside the Thermomix does not have those 
options (which you'll be able to appreciate if you run it in qemu. I've 
also tried putting the old version that had those options inside the 
qemu image and that did not help deciphering the data).

Schang S. schrieb:
> This losetup option (notably -e aes128) correspond to an old version of
> losetup. The losetup binary inside the Thermomix does not have those
> options (which you'll be able to appreciate if you run it in qemu. I've
> also tried putting the old version that had those options inside the
> qemu image and that did not help deciphering the data).

Hi Schang S.,
you need to apply this package 
(https://sourceforge.net/projects/loop-aes/) and compile the losetup 
binary with it (on the project page we can see: "Works with 4.x, 3.x, 
2.6, 2.4, 2.2 and 2.0 kernels", so the old losetup binary you talked 
about does not use the same encryption methods).

The losetup you see on the QEMU is NOT the kernel of the Thermomix, but 
a generic linux kernel for the Freescale processor. Like Ikaro P. wrote, 
nobody until now got access to the real Thermomix kernel.

I can assure you that the "loop-aes" is used on the Thermomix kernel and 
anyone that already asked Vorwerk for the Thermomix kernel source code 
can confirm this... :)

I am not a programmer so I can not test it myself.
Did you managed to have a working GUI like Ikaro P.? Can you share how 
you set it up? Thanks!

Indeed, what I'm saying is that the losetup stuff with -aes128 give a 
wrong direction. I did effectively try with the old versions of losetup 
that supported these option and that did not help.

Schang S. schrieb:
> Indeed, what I'm saying is that the losetup stuff with -aes128 give a
> wrong direction. I did effectively try with the old versions of losetup
> that supported these option and that did not help.

Did the old losetup implement the "loop-aes" methods?
Having the same syntax does not mean that the methods are the same... ;)

As you can see on the work of Ikaro P., the closed source tool from 
Vorwerk NETLINK shows what it tries to do and fail on losetup because 
the encryption method is unknown (because the losetup on the generic 
kernel does not have it, and the old losetup does not implement the same 
encryption methods):

NETLINK-DEBUG: 0h8m13s516ms: int ExecuteSystemCommand(std::string&): 
losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1
NETLINK-ERROR: 0h8m13s937ms: System command losetup -e aes128 -P 
/opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 returned 1

Like I have said, on the kernel source code from Vorwerk, they have two 
folders, one with unmodified source, and one with modified source. On 
the modified source is the losetup source code and on the readme file is 
written that it needs the loop-aes package... ;)

I perfectly understood all that.
Did you request and obtain the source code ? (given your comment I would 
assume you did). If so, would you care sharing it ? and if we have the 
code of the kernel (that would contain any proprietary encryption 
routines they could have developed) then what are we missing to 
successfully decrypt ?

Schang S. schrieb:
> I perfectly understood all that.
> Did you request and obtain the source code ? (given your comment I would
> assume you did). If so, would you care sharing it ?

Yes, I have requested the source code. I do not know if I can share it, 
because I had to give all my personal data and Thermomix serial number 
to receive a CD with the source code at home (so maybe the source code 
is signaled with my data). If you have a Thermomix you could ask for the 
source code too, you just need to write them an email at 
opensource@vorwerk.de, tell them your address and Thermomix serial 
number.
The source code should be about ~300MB...

> and if we have the
> code of the kernel (that would contain any proprietary encryption
> routines they could have developed) then what are we missing to
> successfully decrypt ?

The problem here is that I am not a programmer. I just asked the source 
code to look around and possibly help the community with the research. 
This part of the losetup is on the kernel utilities "modified" source 
code...

I just sent an e-mail with my serial number. How long did it take to 
receive the CD ?

I'm not sure that they would go through the trouble of watermarking the 
code. Especially since according to GPL they are supposed to provide 
modified open source code to anyone (regardless of the fact that you own 
a TM5 or not).

Schang S. schrieb:
> I'm not sure that they would go through the trouble of watermarking the
> code.

We could simply test it: if two people have the sourcecode, just 
generate the SHA256 Hashsum and compare them. If the reults are equal, 
it is safe that there is no watermark ;)

Schang S. schrieb:
> I just sent an e-mail with my serial number. How long did it take to
> receive the CD ?

Nowadays they give you access to an fileserver to download the sources.
In my case it took 3 month to finally download the sources.

But maybe they are faster now ;)

Would you have the details for downloading from that server ?

You get an personalized account from Vorwerk and somebody will put the 
sources there later.

Julian W. schrieb:

> We could simply test it: if two people have the sourcecode, just
> generate the SHA256 Hashsum and compare them. If the reults are equal,
> it is safe that there is no watermark ;)

I would be in.

I does anybody have the version 2.3 of the sources to compare?

Schang S. schrieb:
> I just sent an e-mail with my serial number. How long did it take to
> receive the CD ?
>
> I'm not sure that they would go through the trouble of watermarking the
> code. Especially since according to GPL they are supposed to provide
> modified open source code to anyone (regardless of the fact that you own
> a TM5 or not).

I have got it some weeks later I think (do not know now, I have got it 
sometime ago).
I also asked for a download link, but Vorwerk told me back then that 
they do not provide download links of the source code. They only send it 
as a physical medium (CD-Rom). Maybe they use this method to have a 
record of personal data (address and serial number) from persons that 
asked for the source code...

Moritz M. schrieb:
> Julian W. schrieb:
>
>> We could simply test it: if two people have the sourcecode, just
>> generate the SHA256 Hashsum and compare them. If the reults are equal,
>> it is safe that there is no watermark ;)
>
> I would be in.
>
> I does anybody have the version 2.3 of the sources to compare?

There you go:

  File: Thermomix_TM5_GPL_v2.3.tgz
CRC-32: b1e3209b
   MD4: aa57ab0c2913b5744941b0241a5fbfa2
   MD5: c42146a26bcd7f7f84327957a07a3c49
 SHA-1: 599a257f88e38801ede4e7e1ec37bcc66d43f573

Used HashCheck (https://github.com/gurnec/HashCheck) for that... ;)

Bimby T. schrieb:
> Moritz M. schrieb:
>> Julian W. schrieb:
>>
>>> We could simply test it: if two people have the sourcecode, just
>>> generate the SHA256 Hashsum and compare them. If the reults are equal,
>>> it is safe that there is no watermark ;)
>>
>> I would be in.
>>
>> I does anybody have the version 2.3 of the sources to compare?
>
> There you go:
>
>   File: Thermomix_TM5_GPL_v2.3.tgz
> CRC-32: b1e3209b
>    MD4: aa57ab0c2913b5744941b0241a5fbfa2
>    MD5: c42146a26bcd7f7f84327957a07a3c49
>  SHA-1: 599a257f88e38801ede4e7e1ec37bcc66d43f573
>
> ;)

Nope, seems to be different:

1

╰─$ sha1sum tm5_2.3.tgz 

2

797380a69303a49e0267f0ec453395fc55b4c849  tm5_2.3.tgz

3

╰─$ md5sum tm5_2.3.tgz 

4

5d15bf2ec5c23e839073e335f90d437d  tm5_2.3.tgz

So what about the files itself:

1

╰─$ find ./ -type f -exec md5sum {} \;

2

85a7b3eac41c85f2aa0922cf2aa48105  ./unmodified_packages/GPL_LGPL_licensed_packages/sourceware.org.git.glibc.git.tar.gz

3

586a39938330516b1089ce2eadaf4749  ./unmodified_packages/GPL_LGPL_licensed_packages/git.yoctoproject.org.opkg-utils.tar.gz

4

a51bcfeb3da7dd4c623e27207ed43467  ./unmodified_packages/GPL_LGPL_licensed_packages/gcc-5.2.0.tar.bz2

5

5682890cb0267f6671dd3de6eabd3e69  ./unmodified_packages/GPL_LGPL_licensed_packages/freetype-2.6.tar.bz2

6

275ca403fa8533cc57bc3c4f86e04505  ./unmodified_packages/GPL_LGPL_licensed_packages/github.com.philb.update-rc.d.git.tar.gz

7

8507960b09433c5ea568e43d84624153  ./modified_packages/GPL_LGPL_licensed_packages/mtd-utils-1.5.1/infradead.org.mtd-utils.tar.gz

8

a3a53320bf575147da958655866febf7  ./modified_packages/GPL_LGPL_licensed_packages/mtd-utils-1.5.1/mtd-utils_%.bbappend

9

9a647bdaeffd8b4c0b0f05e847e86dfb  ./modified_packages/GPL_LGPL_licensed_packages/libm2m-1.0/libm2m.tar.gz

10

19d2fce401d1dd67425eebdcf8e051f5  ./modified_packages/GPL_LGPL_licensed_packages/libm2m-1.0/libm2m_svn.bb

11

25f3dbf8019713d02b4b8461f0006509  ./modified_packages/GPL_LGPL_licensed_packages/libwebsockets-1.5/libwebsockets_1.5.bb

12

2b48aa76f35354fc65160ec116bdd36d  ./modified_packages/GPL_LGPL_licensed_packages/libwebsockets-1.5/libwebsockets-1.5-chrome47-firefox41.tar.gz

13

6317671467ce1b10ffbf7415b960bb14  ./modified_packages/GPL_LGPL_licensed_packages/libwebsockets-1.5/files/websockets.patch

14

bc5f5711eac66e8e65ec19828bec79c6  ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/util-linux_%.bbappend

15

9bdf368c395f1b70325d0eb22c7f48fb  ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/util-linux-2.26.2.tar.xz

16

9ece1f2589a037f84610e197a72323bf  ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/files/util-linux-2.26-20150310.diff

17

d9a665645ccdefa1455203cd37548ff1  ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/files/readme.md

18

df67c8bda9139131d919931da443794d  ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/logrotate-3.8.3.tar.gz

19

e84b47335ea240f98f9acf972238671f  ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/logrotate_3.8.3.bb

20

d04640731915ada48dc77fdca6077f9c  ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/files/act-as-mv-when-rotate.patch

21

2659dd5e88e2f01fb13a748efca60494  ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/files/s-flag.patch

22

e526950acfca08b16489ec549bf8bcb4  ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/files/disable-check-different-filesystems.patch

23

7925683d7dd105aabe9b6b618d48cc73  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/busybox-1.23.2.tar.bz2

24

4932d5f889fcf5ea0efb115d58f3945b  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/busybox_%.bbappend

25

eeeb3725cd7a599246113f102ecc8c96  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/nslookup_timeout.patch

26

d4ec40ae5c20a5dd6954bd8c0e27ca3a  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/defconfig

27

a9c592a93e6500f6b7219957b52b2dbb  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/udhcpc-script

28

bfdc6b8805ffbdc383b424e669c24608  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/rename_dhcp.patch

29

6211b045eda898ba5be6bee3f8c68b2e  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/defconfig-debug

30

b32b9fac3d29e3216706cfabec9540dd  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/dhclient

31

127132c24e9ebfc6d579250f56d0afc7  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/linux_vorwerk.tar.gz

32

3a50affe643811614bfeadeeff0e5d17  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/linux-vorwerk_2.6.35.bb

33

d2c3bdf62571f54d5e66eb5dea841ed5  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/exec_tid_core_pattern_linux2.6.35.patch

34

2950a66c8283f29491229bb4f898b68a  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig_netfilter

35

b0f29654b309d7422f07ceaf7efea91d  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/fix_inotify_gcc5.patch

36

82cf88cc9d06ed082fae739d51d742cd  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/ubi_upd_flash_after_prep_for_update.patch

37

75974192ebc65ccd2c28b1e418918089  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig

38

9a51bedd04525147f58199c8f0de0a0f  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/freebox.patch

39

279ce6049324bd466123a27b3e466dd4  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/add_gcc5_header.patch

40

075a555047d06a39c709a830a770281b  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/fix_uninitialized_macro_req.patch

41

c35c49916b027beb409a56344e1524b6  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/dcp.c

42

2faadc1b6d1700268ab0aa2432669cc9  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig-rdv

43

cba19c44122d9e4f25e8459583d9e80a  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/ptrace_coredump_linux2.6.35.patch

44

19f84f7c3e36ff653abeaa04d37fafb5  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/perl_deprecated_defined.patch

45

75974192ebc65ccd2c28b1e418918089  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig-std

46

1e8ab2cf8392d2303ac151e7b870446d  ./modified_packages/GPL_LGPL_licensed_packages/e2fsprogs-1.42.9/e2fsprogs_%.bbappend

47

3f8e41e63b432ba114b33f58674563f7  ./modified_packages/GPL_LGPL_licensed_packages/e2fsprogs-1.42.9/e2fsprogs-1.42.9.tar.gz

48

4eb6fe21874e841e809d5e552f6b93d8  ./modified_packages/GPL_LGPL_licensed_packages/e2fsprogs-1.42.9/files/symlinks.patch

49

b740702d4bc38a70ce1d3f9b87ea5e80  ./modified_packages/GPL_LGPL_licensed_packages/wireless_tools.30.pre9/wireless-tools_%.bbappend

50

ca91ba7c7eff9bfff6926b1a34a4697d  ./modified_packages/GPL_LGPL_licensed_packages/wireless_tools.30.pre9/wireless_tools.30.pre9.tar.gz

51

88d5447da306e56ff6e627ad9c6c6d63  ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/imx-bootlets-vorwerk_10.12.01.bb

52

f112ea757cbaeb32c96adf7924103daa  ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/cst_tools.tar.gz

53

d2aa76e57da2a2cdb79b829703cd09a4  ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/otp_tools.tar.gz

54

a59f177e95453ea7e6d49267eb5b6904  ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/imx-bootlets-src-10.12.01.tar.gz

55

a3229f9645f400a22e214d7e76218f48  ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/files/makefile.patch

56

2e3d6bf0e34fb2d0714f2da9ed19eb91  ./modified_packages/GPL_LGPL_licensed_packages/kobsng-10.12.01/kobsng_10.12.01.bb

57

2c0f4fd363e587eb965317e59f552cb8  ./modified_packages/GPL_LGPL_licensed_packages/kobsng-10.12.01/kobsng.tar.gz

58

536d048c8e8eeebcd9757d0863ebb0c0  ./modified_packages/GPL_LGPL_licensed_packages/iptables-1.4.21/iptables-1.4.21.tar.bz2

59

ee07b484eb407486b6bb7d9b7810e872  ./modified_packages/GPL_LGPL_licensed_packages/iptables-1.4.21/iptables_%.bbappend

Bimby has provided me with his source code and I am getting the exact 
same checksums when running on each individual files. So, definitely no 
watermark there :)

Moritz M. schrieb:

>
> So what about the files itself:
>

Well, I have checked and the MD5 checksum from the files that I have got 
from Vorwerk are all equal, BUT, on my tar file it is missing the 
following folder:

<code>
./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/
</code>

So it seems that the source code is not "signed" with any personal data.
Can you share the source code (because yours is more complete) on a 
online sharing host like mega.co.nz or similar (where it does no expire 
and do not have download limits)...

@Schang S.: Can you share how you setup the QEMU with a working GUI?

Thanks!

Since Vorkwerk is ignoring my request... would be really great if 
someone could share the code.

Thanks!

Schang S. schrieb:
> Bimby has provided me with his source code and I am getting the exact
> same checksums when running on each individual files. So, definitely no
> watermark there :)

With Bimby you mean me or Vorwerk? I did not share any source code to 
you...

true, I mixed up names :) sorry

And as for running qemu. My folder with all my files is a big mess and 
I'm not sure of all the history of changes I made so let me know if that 
works for you:

Grab kernel image and initrd here:
https://people.debian.org/~aurel32/qemu/armel/

If you wish to mount the disk image in order to make changes
sudo kpartx -a thermomix.raw && sudo mount /dev/mapper/loop0p2 
thermomixext3/

And then to unmount it
sudo umount thermomixext3 && sudo kpartx -d thermomix.raw

You then need to convert the image to qcow2 format (to be done each time 
you modify the raw image that can be mounted as described just before)

qemu-img create -b thermomix.raw -f qcow2 thermomix.qcow2

And then run qemu

qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile 
-initrd initrd.img-2.6.32-5-versatile -hda thermomix.qcow2 -append 
"root=/dev/sda2"

You'll get the GUI screen at some point (with the error message). To get 
your shell just hit enter which will mke the GUI image disappear.

I believe that this setup did not fully work in the first place and I 
had to make a few modifications to the disk image but I have not 
documented anything at that time ...


Good luck !

Schang S. schrieb:
> true, I mixed up names :) sorry

No problem... :)

Schang S. schrieb:
> And as for running qemu. My folder with all my files is a big mess and
> I'm not sure of all the history of changes I made so let me know if that
> works for you:
>

Thanks, so you did not have the GUI working without errors like Ikaro 
P., or am I wrong?

Regarding the source code you got from Vorwerk, did you got a public 
link or you need to authenticate with username and password?

No I did not get it to work but I am not too concerned by that as I 
would prefer being able to decrypt the cook stick and then determine if 
recipes can be changed.

As for the source code, Moritz kindly sent me a link earlier today :)

Schang S. schrieb:
> No I did not get it to work but I am not too concerned by that as I
> would prefer being able to decrypt the cook stick and then determine if
> recipes can be changed.
>
> As for the source code, Moritz kindly sent me a link earlier today :)

Ok, so if you find something now with the kernel source code, please 
share... :)

The source code helped figure out what is being done with losetup (they 
applied a patch that is publicly available).
So I've been able to use it with the key provided in cookey.txt but the 
loop device can not be mounted and does not look like a file system that 
can be mounted so I'm a bit stuck right now.

So, the TM5 is using a modified version of losetup which is basically 
util-linux-2.26.2 with patch util-linux-2.26-20150310.diff

I've downloaded that version on computer, applied the patch and 
compiled.

From there, I had to to modprobe cryptoloop otherwise you'll get the 
following error:
ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length 
(128 bits) not supported by kernel

So, I'm assuming that Ikario's initrd image did not contain that module. 
Again, I've been doing these tests from my computer (not the VM in qemu) 
so this was easy to fix.

Then, I could run
losetup -e aes128 -P /tmp/cookey.txt /dev/loop0 recipes.img

which brings a loopback device at /dev/loop0 that is waiting to be 
mounted.
sudo ./losetup -a
/dev/loop0: [fc00]:177473618 (recipes.img) encryption=CryptoAPI/aes-cbc

Interesting to see here that when running the original losetup of my 
computer (so not the patched version), it says type=18, which is not 
0x10 or 16).
sudo losetup  -a
/dev/loop0: [64512]:177473618 (/home/[REDACTED]/thermomix/recipes.img), 
encryption aes-cbc (type 18)

The problem here is that the loopback device does not look like a file 
system. The mount command does not want to mount it. And in fact, when 
you check with binwalk, it does not identify anything but random data:
sudo binwalk /dev/loop0

DECIMAL       HEXADECIMAL     DESCRIPTION
------------------------------------------------------------------------ 
--------
<nothing>


As I also have access to a dump of the cook key, I've also tried to run 
losetup on it and had the same behavior.



What is sort of annoying here is that losetup will not tell you that 
your password is right or wrong, it will just use it as a key. Anf if 
the key is wrong, then the deciphered data are just junk.

I was thinking that maybe the cook stick content has not been extracted 
correctly but I doubt it because at least for the cook key (wifi) I have 
2 partitions that were just fine so no reason for the third partition 
(encrypted on) to not have been extracted correctly.

As for the encryption key/password found in cookey.txt, I trust Ikario 
did not make that one up :)

So, for short, I'm stuck again. I've had a quick look at modified open 
source code but there does not seem to by anything related to encryption 
(aside from the linux utils patch that was already publicly known).

Again, could anybody please share the source code? (PM also welcome). 
Would really like to take part in this ;)

Matthias L. schrieb:
> Again, could anybody please share the source code? (PM also welcome).
> Would really like to take part in this ;)

Now that we know that the source code is not "signed" with personal 
data, I could share the source code, but my source code is missing a 
folder, so I would suggest that Schang S. oder Moritz M. share the 
complete source code...

As Moritz provided me with the source I can not decide on his behalf to 
share it, even though it is GPL and I don't even understood why Vorwerk 
is not simply releasing it to the public without requiring people to ask 
for it (BTW I did request the code 2 or 3 days ago and never got a 
reply).

After making no progress using the patched version of losetup, I started 
looking at the modified/added source code corresponding to the linux 
kernel.

From what I understand, Vorwerk is using a module called DCP to handle 
encryption (not sure encryption of what exactly). This does not seem to 
be something they developed as traces of it can be found on the Internet 
but this module seems to have been discarded from official kernel at 
some point (or was never included in it). There is another module called 
Vorwerk key-store that has a submodule referred to as cloud key or 
something.

There is bitbake (.bb) file that provides all changes made to vanilla 
2.6.35 linux source code. After applying all those changes, I was able 
to run the kernel compilation which failed because some Vorwerk header 
files (.h) are missing from the source code. The .bb file also explains 
that when compiled with gcc5, the kernel won't boot for unknown reasons 
so they recommend compiling with gcc4.4.
After excluding the Vorwerk key-store module (the one that is missing 
headers and made the compilation fail) I was able to have the linux 
image compiled (including the DCP part which could be the one handling 
decryption of AES loop). Using that kernel image in qemu failed (no 
surprise because Vorwerk documented that it would not work when compiled 
with gcc5 and I did not have a gcc4.4 at hand).

Another interesting point - but maybe concerning too - I found in the 
.bb file is that they have a series of sed commands to inject (that's 
what comments say in the .bb) hard-coded AES128 keys inside the code of 
the DPC driver. If that's the case, then things will get more 
complicated because the keys have not been released in the 300MB archive 
of course.

I'll try to install and old debian with kernel 2.6 and old gcc to 
compile the kernel in the same conditions as Vorwerk.

The one thing that I find strange is why would they have hard-coded keys 
and still be sing the cookey.txt file with losetup.
Also, I am wondering if the recipes.img that was share here has been 
extracted properly. I can't recall who extracted the image but I'd like 
to know what tools have been used and how they were used (dd ?).

@ikaro hope you read this:
As I checked the certs of your dump today, I noticed that there are some 
certs and two root certs listed in /tmp/certificates, but there is only 
one valid private key for one cert that expired in 2017. If this private 
key got any use, there must be a new valid cert & private key in the 
last Firmware Updates. We could decrypt the traffic if we got the new 
cert.

Hi all,

finally there is a GitLab repository which hosts all the v2.3 GPL/LGPL 
source code:

https://gitlab.com/therm0m1x/tm5-sources

I somebody wants to contribute just fork the project and afterwards 
create a merge request.

As there is also a wiki included I plan to sum up all the knowledge 
collected so far. Any help doing this is highly appreciated.

Cheers.

I forgot to mention somebody already published the sources already on 
github:

https://github.com/scharri/vorwerk-tm5-oss-sources

If somebody could ask Vorwerk (opensource@vorwerk.de) for the recent 
sources (should be 2.4 now) and contribute these sources. That would be 
nice.

If you are interested in breaking the cookido comnunication you can 
contact me. We wont publish anything until everything works perfect.

Hans H. schrieb:
> If you are interested in breaking the cookido comnunication you can
> contact me. We wont publish anything until everything works perfect.

Hi Hans, can you please share some info about this privately? Thanks! :)

[Auf Deutsch unten]

I've read all your posts with great interest.  I've repaired a lot of 
devices before, but this device is a fortress!  Everything is secured 
and protected with cryptography and 2048-bit signatures.

1. CN601 may be a serial port, however nothing is output to it (checked 
with oscilloscope).  Probably it was used during board bring-up only. 
The footprint fits 4-pin JST connector BM04B-SRSS-TB.  The pinout is 
1:GND 2:OUT 3:IN 4:3.3V.

2. Attaching a USB keyboard/mouse does nothing (no drivers?).

3. If you attach a USB Ethernet dongle with AX88772/72A/72B chipset, the 
device enters service mode and you can connect to it at 192.168.76.1. 
Unfortunately, the service protocol requires authentication with 2048 
bit RSA before executing any commands.  So it is very hard to get in 
this way.

4. I did get into the device in the end.  As Ikaro_P says, the 
developers are only human.

5. Here is a copy of the Linux kernel from the device.  I believe I am 
entitled to share this under GPL (section 3c). 
https://mega.nz/#!PqhyTIiY!70HDBcwl6Lb-DhgPQ6xk0LIvXCcl4vxZY5F_C6egb-E

6. As others have found, the encryption key for the recipe chip is not 
the one posted earlier, they have done something devious.  (I will not 
share the real key on the Internet to avoid wrath from Vorwerk.)

7. Having the encryption key is not enough to create your own recipe 
chip.  All files on the recipe chip are signed with 2048 bit RSA 
signatures.

8. Fortunately, despite all the layers of paranoia, there is a 
bug/feature in the implementation of recipe chip verification that makes 
DIY recipe chips possible without having to break the RSA key.  I will 
not say any more for now.

Happy hacking :)

---

[Entschuldigung für Fehler in meinem Deutsch.]

Ich habe alles Ihrer Posts mit großem Interesse gelesen.  Ich habe viele 
andere Geräte repariert, aber dieses Maschine is eine Festung!  Alles 
ist gesichert und geschützt mit Kryptographie und 2048-Bit-Signaturen.

1. CN601 ist möglicherweise eine serielle Schnittstelle, aber es wird 
nichts ausgegeben.  Wahrscheinlich wurde es nur während des Entwicklung 
verwendet.  Der Fußabdruck passt für 4-poligen JST-Stecker 
BM04B-SRSS-TB.  Die Pinbelegung ist 1:GND 2:OUT 3:IN 4:3,3V.

2. Das Anschließen einer USB-Tastatur/Maus führt zu nichts (keine 
Treiber?).

3. Wenn Sie einen USB-Ethernet-Dongle mit AX88772/72A/72B-Chipsatz 
anschließen, das Gerät wechselt in den Service-Modus und Sie können eine 
Verbindung zu 192.168.76.1 herstellen. Bedauerlicherweise, das 
Serviceprotokoll erfordert das Authentifizierung mit 2048 Bit RSA. Es 
ist also sehr schwer, auf diese Weise zu kommen.

4. Letztendlich bin ich in das Gerät eingebrochen.  Wie Ikaro_P sagt, 
sind die Entwickler nur menschlich.

5. Hier ist eine Kopie des Linux-Kernels vom Gerät.  Ich glaube, ich bin 
berechtigt, dies unter der GPL zu teilen (Abschnitt 3c). 
https://mega.nz/#!PqhyTIiY!70HDBcwl6Lb-DhgPQ6xk0LIvXCcl4vxZY5F_C6egb-E

6. Wie andere gefunden haben, ist der Schlüssel für die Rezeptsticks 
nicht der, der zuvor hier veröffentlicht wurde.  (Ich werde den echten 
Schlüssel nicht im Internet teilen.)

7. Der Schlüssel reicht nicht aus, um eigene Rezeptchips zu erstellen. 
Alle Dateien auf den Rezeptchips sind mit 2048 Bit RSA-Signaturen 
gesichert.

8. Zum Glück, trotz all den Schichten der Paranoia, gibt es ein Fehler 
in der Implementierung der Rezeptstick-prüfung.  Deswegen ist es 
möglich, die eigene Rezeptsticks erstellen.  Ich werde vorerst nichts 
mehr sagen.

Happy hacking :)

Hi,

Great work !

The kernel image that you have posted does not seem to load in qemu.
Running 'file' on the image returns "data".

Were you able to successfully run it in qemu ?

Hi Schang,

I have not tried it in qemu.  The file I shared before is the 
uncompressed kernel (loaded in memory at address 0xc0008000).  Here is 
the zImage format version which might work better: 
https://mega.nz/#!z7xRUQgB!DYFHi3t1uAPBvGyTe-jZ4dp9gM7zakHOx76q631dNtw

Matt

Hi Matt C,

sehr sehr gute Arbeit!

Kannst du uns verraten wie du es geschafft hast, einen eigenen 
Rezeptchip zu generieren? Ich denke die ganze Community wartet schon 
voller Spannung auf diese Infos :)

----------------------------------------------------------------

very very great work!

Could you please share some more information on how to generate custom 
cooking book sticks? I guess the entire community is waiting full of 
expectation on this Information :)


Viele Grüße
Johannes

Holy sh*t, Matt C. you are a genious!

Unfortunately, it won't do us any good if he doesn't tell us how.

Share your achivements with us Matt C, please.
I have been testing your kernel file, but it's too complex for me.
Thank you very much for your time and dedication.

Hello everybody,

Winter is comming, I will have time to look at TM5 again.
Great job everybody!

This is my understanding.
Can you tell me if I taking the good way?

1. We have access to the last source code: 
https://gitlab.com/therm0m1x/tm5-sources

2. When a cook stick is inserted, we know that netlink call the 
following command:
losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1

4. Schang S tried to compile losetup with Vorkerk patch 
(util-linux-2.26-20150310.diff that is a public patch) but the resulting 
loopback device is not mountable:

Schang S. schrieb:
> The problem here is that the loopback device does not look like a file
> system. The mount command does not want to mount it. And in fact, when
> you check with binwalk, it does not identify anything but random data:
> sudo binwalk /dev/loop0

According to Matt C., encryption key is not correct (they have done 
something devious):

Matt C. schrieb:
> 6. As others have found, the encryption key for the recipe chip is not
> the one posted earlier, they have done something devious.  (I will not
> share the real key on the Internet to avoid wrath from Vorwerk.)


So, according to my understanding, there are 3 possibilities:
1. losetup command is not correct:
losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1

2. cookey.txt doesn't contain the good key:
The given key is not correct 
(EiOJeNLiooqwWobaVDVrbJWLCifvQC5oDqNqHfuSYBt3y4vwN3YKq2EsvFK3U4M9)
Or the file is preprocessed first and key is deviated from this one

3. The real kernel make something with the key that is not present in 
the patch util-linux-2.26-20150310.diff

Can you tell me if my understanding is good ?

Hi Sigma P.,

See the dcp_aes_setkey_blk function in 
https://github.com/scharri/vorwerk-tm5-oss-sources/blob/master/modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/dcp.c 
for a clue.

Matt

So the actual key is in the driver itself and set if the compare key is 
used...?!

Matt C. schrieb:
> See the dcp_aes_setkey_blk function in
> 
https://github.com/scharri/vorwerk-tm5-oss-sources/blob/master/modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/dcp.c
> for a clue.
Thanks for the clue matt. I will look into this.

Sigma P. schrieb:
> According to Matt C., encryption key is not correct (they have done
> something devious):
>
> Matt C. schrieb:
>> 6. As others have found, the encryption key for the recipe chip is not
>> the one posted earlier, they have done something devious.  (I will not
>> share the real key on the Internet to avoid wrath from Vorwerk.)
>
>
> So, according to my understanding, there are 3 possibilities:
> 1. losetup command is not correct:
> losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1
>
> 2. cookey.txt doesn't contain the good key:
> The given key is not correct
> (EiOJeNLiooqwWobaVDVrbJWLCifvQC5oDqNqHfuSYBt3y4vwN3YKq2EsvFK3U4M9)
> Or the file is preprocessed first and key is deviated from this one
>
> 3. The real kernel make something with the key that is not present in
> the patch util-linux-2.26-20150310.diff
>
> Can you tell me if my understanding is good ?

Even if the dcp_aes_setkey_blk function does something devious with the 
key, it is important that everyone looks in the patents again! As seen 
in my screenshot(search for "patent" in this page for the full patent), 
the key to decrypt the data partition of the recipe chip depends on the 
hardware serial of the recipe stick and some key of a keyring that is 
referred in the first partition of the recipe stick. Because Vorwerk 
registered a patent for this actions, they will use it for the recipe 
stick, maybe for the wifi stick too.
So keep in mind that no matter what the kernel does with ikaros AES key 
before something is decrypted with it, you can only decrypt a recipe 
chip with it, that has the same serial number as ikaros AND the same key 
is referred on the recipe chip. Since ikaro talked a lot about the wifi 
stick verification, I think the last thing his tm decrypted before he 
dumped the fw was the wifi stick he used. So things to find out:

1. What was the last thing ikaros tm decrypted with the given AES key? 
Its unlikely that we can decrypt anything else with it.

2. Is the encryption/decryption action mentioned in the patents used for 
the wifi stick too?

3. Since we know that every recipe chip with the same recipes on it has 
the same serial(we know that, right?), the question is if the referred 
key is also the same. We should collect hashsums/content of the first 
partition of some recipe chips with the same recipes on it and check 
that. I ordered one "Das Kochbuch" chip today and will share this if it 
arrived. Does someone else got the "Das Kochbuch" chip and could do this 
too?

4. As the content on all wifi sticks is the same, does a wifi stick has 
any serial or referred key that is unique, other than the vendor_id 
stored in the db? We need hashsums of the files to find that out.If all 
wifi sticks are the same, we find out what devious the kernel does to 
the key and ikaros key was really used for his wifi stick, we should be 
able to decrypt our wifi sticks content. Unfortunately I got no wifi 
stick to dump at the time.

5. We did not talked a lot about the recipe signature thing. As you can 
see in some post of Schang S.(search for "cs.tar"), there is a signature 
stored for every recipe in the db. Even if we could decrypt every stick 
and the whole tm fw, if the RSA private key is not stored on the 
tm(which would be really dumb), we can not change or add any recipe. We 
have to know what matt knows about the recipe verification. I will start 
to look into the /opt/Thermomix/Thermomix executable again because I 
think the verification is done in there, but I really dont know how to 
start. We have to work structured on this so we dont do the same work.

The key does not depend on the serial number.  (The signatures do 
however.)

Matt C. schrieb:
> The key does not depend on the serial number.  (The signatures do
> however.)
Does it only depends on the referred key of the keyring stored in the 
tm?
The patent is not clear about it. Or is the keyring never used? For what 
did they made a patent then?

> For what did they made a patent then?

I don't know, the patent scheme might have been used in a prototype 
machine?  Or be intended to misdirect people? :)

> As the content on all wifi sticks is the same, does a wifi stick has
> any serial or referred key that is unique, other than the vendor_id
> stored in the db?

The WiFi stick has a unique ID that is printed on the bottom, and this 
can be queried from the microcontroller on the stick.  I think the files 
are the same on each stick though.  The security scheme for these is 
quite different from read-only recipe sticks (and I think harder to 
attack).

Matt

Matt C. schrieb:
>> For what did they made a patent then?
>
> I don't know, the patent scheme might have been used in a prototype
> machine?  Or be intended to misdirect people? :)
Do you know that for sure? Did you decrypt a recipe stick without 
anything from the maybe non-existent key-ring?

Yes I know that for sure.

Hi everyone, so if the files on recipe chip are signed with 2048 bit RSA 
signatures we could not change the recipe chip, right?
What about the development recipe chips I mentioned earlier?
Can it be that this kind of chip uses an ID that the TM5 recognizes an 
read it without encryption?
Have anyone tried to check if non development TM5 do can read 
development recipe chips?
Thanks Matt C. for your findings and tips. Do you also have a database 
scheme used in the recipe chip and a list of files found inside one?

Matt C. schrieb:
> See the dcp_aes_setkey_blk function in
> 
https://github.com/scharri/vorwerk-tm5-oss-sources/blob/master/modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/dcp.c
> for a clue.

Wow, I just look quickly on my phone because I was away all the day.
I really will check what this function do because it seems to replace 
the key by a static one.
I'll check that.
Thanks

Hans H. schrieb:
> 5. We did not talked a lot about the recipe signature thing. As you can
> see in some post of Schang S.(search for "cs.tar"), there is a signature
> stored for every recipe in the db. Even if we could decrypt every stick
> and the whole tm fw, if the RSA private key is not stored on the
> tm(which would be really dumb), we can not change or add any recipe

As Matt C. said, code is written by human (not anymore for a long time, 
thanks AI) but here it's the case. If you have an exploit in the check 
function, no need have the private key. And in some cases you even 
deduce it.


Bimby T. schrieb:
> Hi everyone, so if the files on recipe chip are signed with 2048 bit RSA
> signatures we could not change the recipe chip, right?

Extacly the same than my previous answer.

Hans H. schrieb:
> Even if the dcp_aes_setkey_blk function does something devious with the
> key, it is important that everyone looks in the patents again

Matt C. schrieb:
>> For what did they made a patent then?
>
> I don't know, the patent scheme might have been used in a prototype
> machine?  Or be intended to misdirect people? :)

+1, totally agree with you

Guten Abend alle,

sorry but I will write in English.

My wife had problem with TM5 weight, is shows wrong, random values, 
everything other was fine. We send TM5 to authorized service and they 
said that they replaced mainboard and send thermomix back to us. The 
question is if they really replaced whole mainboard or not. We put our 
cook-key (which we didn't send them) and it didn't ask us to provide 
wlan ssid and password to our wifi network. Don't you know that ssid and 
password is stored in the TM5 or cook-key?

Thanks for reply!

Jaro

Jaro J. schrieb:
> My wife had problem with TM5 weight, is shows wrong, random values,
> everything other was fine. We send TM5 to authorized service and they
> said that they replaced mainboard and send thermomix back to us. The
> question is if they really replaced whole mainboard or not. We put our
> cook-key (which we didn't send them) and it didn't ask us to provide
> wlan ssid and password to our wifi network. Don't you know that ssid and
> password is stored in the TM5 or cook-key?

I think this is not the right place for TM5-support. Pls. open your own 
thread, because this is offtopic.

But if you thing there is an securityproblem simply change SSID and key 
in your router!

Hi Jaro,

The WiFi details are stored in the TM5, however not on the mainboard - 
the processor is on a separate board behind the LCD screen.  So it's 
possible that they could have replaced the mainboard, I'm not sure how 
you would tell for sure.

I had a similar problem with the TM5 scales which was my original reason 
for needing to get into the Thermomix, in my case they were fluctuating 
between 0 and MAX (seems like a common problem).  The problem went away 
after:

* unplugging and replugging the three connectors from the mainboard to 
the scale (labelled WAAGE), and
* unscrewing and re-tightening the three screws that go down through the 
mainboard into the feet.

I'm not sure which of these made the difference.  It's possible that in 
your case a mainboard replacement was actually required.  The ADC for 
the scale is on the mainboard.

Matt

Sven L. schrieb:
> Jaro J. schrieb:
>> My wife had problem with TM5 weight, is shows wrong, random values,
>> everything other was fine. We send TM5 to authorized service and they
>> said that they replaced mainboard and send thermomix back to us. The
>> question is if they really replaced whole mainboard or not. We put our
>> cook-key (which we didn't send them) and it didn't ask us to provide
>> wlan ssid and password to our wifi network. Don't you know that ssid and
>> password is stored in the TM5 or cook-key?
>
> I think this is not the right place for TM5-support. Pls. open your own
> thread, because this is offtopic.
>
> But if you thing there is an securityproblem simply change SSID and key
> in your router!
Thank you for answer,
Maybe it wasn't needed to write the whole story - I'm sorry. Since you 
guys are getting into electronic and reverse engineering of TM5 I just 
asked because you probably already know where are ssid and password 
stored? In TM5 or cook-key?

Matt C. schrieb:
> Hi Jaro,
>
> The WiFi details are stored in the TM5, however not on the mainboard -
> the processor is on a separate board behind the LCD screen.  So it's
> possible that they could have replaced the mainboard, I'm not sure how
> you would tell for sure.
>
> Matt
Matt, thank you very much for reply and for the comprehensive answer! It 
is what I needed.