Forum: Offtopic Thermomix Rezeptchips


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von David N. (knochi)


Bewertung
0 lesenswert
nicht lesenswert
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

von David N. (knochi)


Bewertung
0 lesenswert
nicht lesenswert
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

von Sigma P. (sigmapic)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Chris R. (chrisr2710)


Bewertung
0 lesenswert
nicht lesenswert
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

von Chris R. (chrisr2710)


Bewertung
0 lesenswert
nicht lesenswert
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?
------------ Power-cycling USB interface ----------
/etc/rc.d/init.d/usbpower stop
/etc/rc.d/init.d/usbpower start
mkdir -p /tmp/dev/
mknod /tmp/dev/ttyACM0 c 166 0
/usr/sbin/eth stop
settings_cloud.sdb material/photo/150x150/vorwerk_trademark_logo.png
umount -f
losetup -d
rm -f
rmdir
/usr/sbin/eth start
mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ mkfs.ext4
tcsetattr usbTermio /sys/ /idVendor i j q u z rm -f /tmp/dev/ sd /../../../../../../../serial sr s.+(\d+) sd([a-z])\d+
mknod -m 644 /tmp/dev/loop b 7
mknod -m 644 /tmp/dev/ b 11 b 8
mkdir -p
losetup -e aes128 -P /opt/cookey.txt
mount -o ro
mount

von Dirk K. (d-k)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
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?
>
>
> ------------ Power-cycling USB interface ----------
> /etc/rc.d/init.d/usbpower stop
> /etc/rc.d/init.d/usbpower start
> mkdir -p /tmp/dev/
> mknod /tmp/dev/ttyACM0 c 166 0
> /usr/sbin/eth stop
> settings_cloud.sdb material/photo/150x150/vorwerk_trademark_logo.png
> umount -f
> losetup -d
> rm -f
> rmdir
> /usr/sbin/eth start
> mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ 
> mkfs.ext4
> tcsetattr usbTermio /sys/ /idVendor i j q u z rm -f /tmp/dev/ sd 
> /../../../../../../../serial sr s.+(\d+) sd([a-z])\d+
> mknod -m 644 /tmp/dev/loop b 7
> mknod -m 644 /tmp/dev/ b 11 b 8
> mkdir -p
> losetup -e aes128 -P /opt/cookey.txt
> mount -o ro
> mount
> 


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

von Dirk K. (d-k)


Bewertung
0 lesenswert
nicht lesenswert
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.

von David N. (knochi)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Chris R. (chrisr2710)


Bewertung
0 lesenswert
nicht lesenswert
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
mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ mkfs.ext4

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

: Bearbeitet durch User
von Daniel S. (schuballaa)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Ikaro P. (ikaro_p)


Bewertung
4 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Joachim S. (oyo)


Bewertung
1 lesenswert
nicht lesenswert
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":
id|remoteAddress|TCPPort|remotePath|pingAddress
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":
id|mac|ssn|serial|version
1|AABBCCDDEEFF|0123456789ABCDEF|00000000000000000|203801010000

Table "settingsCloudApp" in "settings_empty_en.sdb":
id|remoteAddress|TCPPort|remotePath
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:
(file opt/common.sh)

mc_configure_stty() {
    # configure serial port to similiar values that libntm does, but before GUI is started
    stty -F /dev/ttySP0 -icrnl -ixon -opost -onlcr -isig -icanon -iexten -echo 38400
}

mc_turn_off_shutdown_timer() {
    # set shutdown timer to 15min. (0xFFFF) to
    # prevent shutdown after killing GUI app by force
    echo -e -n "\x55\x03\x10\xFF\xFF\x8C" > /dev/ttySP0
}

mc_keep_alive() {
    # sends heart-beat packet to MC
    echo -ne "\x55\x08\x30\x50\x06\x50\x06\x10\x00\x00\xB8" > /dev/ttySP0
}

mc_reset() {
    # resets the MC
    echo -e -n "\x55\x01\x11\xFD" > /dev/ttySP0
}

von Sigma P. (sigmapic)


Bewertung
3 lesenswert
nicht lesenswert
> 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.

von Moritz M. (mom)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Moritz M. (mom)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
I attach the images right away.

: Bearbeitet durch User
von Joachim S. (oyo)


Angehängte Dateien:
  • tm5.sh (4,07 KB, 250 Downloads)

Bewertung
1 lesenswert
nicht lesenswert
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"

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
> 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 ?

Beitrag #5217033 wurde vom Autor gelöscht.
von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
von Joachim S. (oyo)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Moritz M. (mom)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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! ;)

von Joachim S. (oyo)


Bewertung
1 lesenswert
nicht lesenswert
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...

von Moritz M. (mom)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bimby T. (bimby)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Joachim S. (oyo)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Joachim S. (oyo)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Does someone got a response from opensource@vorwerk.de for Kernel 
sources ?

von Joachim S. (oyo)


Bewertung
0 lesenswert
nicht lesenswert
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:
#!/bin/sh

# Path to the directory with all proxy-related files
proxy_directory="/proxy"

# Log timestamp + called command line to the log file
echo "$(date +%s):" "$0" $@ >> "${proxy_directory}/log.txt"

# Call the proxied command passing all arguments
"${proxy_directory}/commands/$(basename $0)" $@

: Bearbeitet durch User
von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Fabian O. (fabiiian)


Bewertung
0 lesenswert
nicht lesenswert
You are right. It is possible to clone a chip

von Sigma P. (sigmapic)


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

Please, can you share kernel patches from Vorwerk CD.

von Fabian O. (fabiiian)


Bewertung
0 lesenswert
nicht lesenswert
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

von Boe C. (boe_c)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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
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
mkfs.ext3 /dev/mapper/loop0p2
mount /dev/mapper/loop0p2 /mnt/thermomixext3
7. rsync
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.
[ 2780.290452] SQUASHFS error: Unable to read data cache entry [135cd]
[ 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
   umount /mnt/thermomixext3 
   kpartx -d thermomix.raw
10. qemu starten
    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" \
                        -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

von Boe C. (boe_c)


Bewertung
2 lesenswert
nicht lesenswert
Hallo,

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

9b. Differenz-Image thermomix.qcow2
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

: Bearbeitet durch User
von Boe C. (boe_c)


Angehängte Dateien:

Bewertung
7 lesenswert
nicht lesenswert
Hallo,

kleines Update: nachdem ich ein weitere Partition in thermomix.raw 
angelegt habe und
/etr/rc.d/rc.local auf
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

von Stephan M. (Firma: Herr) (assiy2k)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Ed U. (eduardito)


Bewertung
-1 lesenswert
nicht lesenswert
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?

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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

von Schang S. (Firma: keine) (schang)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Moritz M. (mom)


Bewertung
0 lesenswert
nicht lesenswert
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

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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) ?

von Thierry G. (thierry_g) Flattr this


Bewertung
0 lesenswert
nicht lesenswert
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 ?

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thierry G. (thierry_g) Flattr this


Bewertung
0 lesenswert
nicht lesenswert
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

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thierry G. (thierry_g) Flattr this


Bewertung
1 lesenswert
nicht lesenswert
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 ;)

von Bimby T. (bimby)


Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Jörg P. R. (jrgp_r)


Bewertung
-10 lesenswert
nicht lesenswert
Ich dachte das wäre ein deutsches Forum.

Beitrag #5303176 wurde von einem Moderator gelöscht.
von Bimby T. (bimby)


Bewertung
8 lesenswert
nicht lesenswert
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. ;)

: Bearbeitet durch User
von F. K. (firstfacility)


Bewertung
-3 lesenswert
nicht lesenswert
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

von Jörg P. R. (jrgp_r)


Bewertung
-1 lesenswert
nicht lesenswert
Sicher, das sehe ich ein, aber als interessierter mit wenig Englisch 
Kenntnisse ist es halt schwer.

von Thierry G. (thierry_g) Flattr this


Bewertung
0 lesenswert
nicht lesenswert
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 !

von Fabian O. (fabiiian)


Bewertung
1 lesenswert
nicht lesenswert
@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.

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
von Markus H. (markusfooo)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Martin S. (sirnails)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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... :)

von Schang S. (Firma: keine) (schang)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Stephan K. (stylon)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

Beitrag #5329902 wurde vom Autor gelöscht.
von Ikaro P. (ikaro_p)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Ikaro P. (ikaro_p)


Bewertung
0 lesenswert
nicht lesenswert
(and I just doxxed myself, oh... well...)

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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"

: Bearbeitet durch User
Beitrag #5332172 wurde vom Autor gelöscht.
von Ikaro P. (ikaro_p)


Bewertung
5 lesenswert
nicht lesenswert
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...

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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! :)

: Bearbeitet durch User
von Stephan K. (stylon)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Stephan K. (stylon)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Sigma P. (sigmapic)


Bewertung
-1 lesenswert
nicht lesenswert
Ikaro P, how can you help you.
I'm lost in such deep linux world.

I don't how to continue on my side.

von Rui B. (rbarreiros)


Bewertung
0 lesenswert
nicht lesenswert
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,

von Andreas J. (dolar)


Bewertung
0 lesenswert
nicht lesenswert
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

von Gennadij D. (gennadij_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Michael W. (mwulz)


Bewertung
0 lesenswert
nicht lesenswert
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 ;(

von Alexander S. (esko) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@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?

von Hans H. (Firma: kobs-ng) (haschhans)


Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Thomas H. (thomashhh)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Hans H. (Firma: kobs-ng) (haschhans)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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! :)

: Bearbeitet durch User
von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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... ;)

von Schang S. (Firma: keine) (schang)


Bewertung
1 lesenswert
nicht lesenswert
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 ?

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Julian W. (julian-w) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von Moritz M. (mom)


Bewertung
1 lesenswert
nicht lesenswert
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 ;)

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
Would you have the details for downloading from that server ?

von Moritz M. (mom)


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

von Moritz M. (mom)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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... ;)

: Bearbeitet durch User
von Moritz M. (mom)


Bewertung
0 lesenswert
nicht lesenswert
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:
╰─$ sha1sum tm5_2.3.tgz 
797380a69303a49e0267f0ec453395fc55b4c849  tm5_2.3.tgz
╰─$ md5sum tm5_2.3.tgz 
5d15bf2ec5c23e839073e335f90d437d  tm5_2.3.tgz

So what about the files itself:
╰─$ find ./ -type f -exec md5sum {} \;
85a7b3eac41c85f2aa0922cf2aa48105  ./unmodified_packages/GPL_LGPL_licensed_packages/sourceware.org.git.glibc.git.tar.gz
586a39938330516b1089ce2eadaf4749  ./unmodified_packages/GPL_LGPL_licensed_packages/git.yoctoproject.org.opkg-utils.tar.gz
a51bcfeb3da7dd4c623e27207ed43467  ./unmodified_packages/GPL_LGPL_licensed_packages/gcc-5.2.0.tar.bz2
5682890cb0267f6671dd3de6eabd3e69  ./unmodified_packages/GPL_LGPL_licensed_packages/freetype-2.6.tar.bz2
275ca403fa8533cc57bc3c4f86e04505  ./unmodified_packages/GPL_LGPL_licensed_packages/github.com.philb.update-rc.d.git.tar.gz
8507960b09433c5ea568e43d84624153  ./modified_packages/GPL_LGPL_licensed_packages/mtd-utils-1.5.1/infradead.org.mtd-utils.tar.gz
a3a53320bf575147da958655866febf7  ./modified_packages/GPL_LGPL_licensed_packages/mtd-utils-1.5.1/mtd-utils_%.bbappend
9a647bdaeffd8b4c0b0f05e847e86dfb  ./modified_packages/GPL_LGPL_licensed_packages/libm2m-1.0/libm2m.tar.gz
19d2fce401d1dd67425eebdcf8e051f5  ./modified_packages/GPL_LGPL_licensed_packages/libm2m-1.0/libm2m_svn.bb
25f3dbf8019713d02b4b8461f0006509  ./modified_packages/GPL_LGPL_licensed_packages/libwebsockets-1.5/libwebsockets_1.5.bb
2b48aa76f35354fc65160ec116bdd36d  ./modified_packages/GPL_LGPL_licensed_packages/libwebsockets-1.5/libwebsockets-1.5-chrome47-firefox41.tar.gz
6317671467ce1b10ffbf7415b960bb14  ./modified_packages/GPL_LGPL_licensed_packages/libwebsockets-1.5/files/websockets.patch
bc5f5711eac66e8e65ec19828bec79c6  ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/util-linux_%.bbappend
9bdf368c395f1b70325d0eb22c7f48fb  ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/util-linux-2.26.2.tar.xz
9ece1f2589a037f84610e197a72323bf  ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/files/util-linux-2.26-20150310.diff
d9a665645ccdefa1455203cd37548ff1  ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/files/readme.md
df67c8bda9139131d919931da443794d  ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/logrotate-3.8.3.tar.gz
e84b47335ea240f98f9acf972238671f  ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/logrotate_3.8.3.bb
d04640731915ada48dc77fdca6077f9c  ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/files/act-as-mv-when-rotate.patch
2659dd5e88e2f01fb13a748efca60494  ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/files/s-flag.patch
e526950acfca08b16489ec549bf8bcb4  ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/files/disable-check-different-filesystems.patch
7925683d7dd105aabe9b6b618d48cc73  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/busybox-1.23.2.tar.bz2
4932d5f889fcf5ea0efb115d58f3945b  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/busybox_%.bbappend
eeeb3725cd7a599246113f102ecc8c96  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/nslookup_timeout.patch
d4ec40ae5c20a5dd6954bd8c0e27ca3a  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/defconfig
a9c592a93e6500f6b7219957b52b2dbb  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/udhcpc-script
bfdc6b8805ffbdc383b424e669c24608  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/rename_dhcp.patch
6211b045eda898ba5be6bee3f8c68b2e  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/defconfig-debug
b32b9fac3d29e3216706cfabec9540dd  ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/dhclient
127132c24e9ebfc6d579250f56d0afc7  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/linux_vorwerk.tar.gz
3a50affe643811614bfeadeeff0e5d17  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/linux-vorwerk_2.6.35.bb
d2c3bdf62571f54d5e66eb5dea841ed5  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/exec_tid_core_pattern_linux2.6.35.patch
2950a66c8283f29491229bb4f898b68a  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig_netfilter
b0f29654b309d7422f07ceaf7efea91d  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/fix_inotify_gcc5.patch
82cf88cc9d06ed082fae739d51d742cd  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/ubi_upd_flash_after_prep_for_update.patch
75974192ebc65ccd2c28b1e418918089  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig
9a51bedd04525147f58199c8f0de0a0f  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/freebox.patch
279ce6049324bd466123a27b3e466dd4  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/add_gcc5_header.patch
075a555047d06a39c709a830a770281b  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/fix_uninitialized_macro_req.patch
c35c49916b027beb409a56344e1524b6  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/dcp.c
2faadc1b6d1700268ab0aa2432669cc9  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig-rdv
cba19c44122d9e4f25e8459583d9e80a  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/ptrace_coredump_linux2.6.35.patch
19f84f7c3e36ff653abeaa04d37fafb5  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/perl_deprecated_defined.patch
75974192ebc65ccd2c28b1e418918089  ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig-std
1e8ab2cf8392d2303ac151e7b870446d  ./modified_packages/GPL_LGPL_licensed_packages/e2fsprogs-1.42.9/e2fsprogs_%.bbappend
3f8e41e63b432ba114b33f58674563f7  ./modified_packages/GPL_LGPL_licensed_packages/e2fsprogs-1.42.9/e2fsprogs-1.42.9.tar.gz
4eb6fe21874e841e809d5e552f6b93d8  ./modified_packages/GPL_LGPL_licensed_packages/e2fsprogs-1.42.9/files/symlinks.patch
b740702d4bc38a70ce1d3f9b87ea5e80  ./modified_packages/GPL_LGPL_licensed_packages/wireless_tools.30.pre9/wireless-tools_%.bbappend
ca91ba7c7eff9bfff6926b1a34a4697d  ./modified_packages/GPL_LGPL_licensed_packages/wireless_tools.30.pre9/wireless_tools.30.pre9.tar.gz
88d5447da306e56ff6e627ad9c6c6d63  ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/imx-bootlets-vorwerk_10.12.01.bb
f112ea757cbaeb32c96adf7924103daa  ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/cst_tools.tar.gz
d2aa76e57da2a2cdb79b829703cd09a4  ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/otp_tools.tar.gz
a59f177e95453ea7e6d49267eb5b6904  ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/imx-bootlets-src-10.12.01.tar.gz
a3229f9645f400a22e214d7e76218f48  ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/files/makefile.patch
2e3d6bf0e34fb2d0714f2da9ed19eb91  ./modified_packages/GPL_LGPL_licensed_packages/kobsng-10.12.01/kobsng_10.12.01.bb
2c0f4fd363e587eb965317e59f552cb8  ./modified_packages/GPL_LGPL_licensed_packages/kobsng-10.12.01/kobsng.tar.gz
536d048c8e8eeebcd9757d0863ebb0c0  ./modified_packages/GPL_LGPL_licensed_packages/iptables-1.4.21/iptables-1.4.21.tar.bz2
ee07b484eb407486b6bb7d9b7810e872  ./modified_packages/GPL_LGPL_licensed_packages/iptables-1.4.21/iptables_%.bbappend


von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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!

von Matthias L. (malo)


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

Thanks!

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
true, I mixed up names :) sorry

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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 !

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Schang S. schrieb:
> true, I mixed up names :) sorry

No problem... :)

: Bearbeitet durch User
von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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 :)

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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... :)

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Matthias L. (malo)


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

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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 ?).

von Hans H. (Firma: kobs-ng) (haschhans)


Bewertung
0 lesenswert
nicht lesenswert
@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.

: Bearbeitet durch User
von Therm0m1x X. (therm0m1x)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Therm0m1x X. (therm0m1x)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Hans H. (Firma: kobs-ng) (haschhans)


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

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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! :)

von Matt C. (thermomatt)


Angehängte Dateien:

Bewertung
9 lesenswert
nicht lesenswert
[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 :)

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
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 ?

von Matt C. (thermomatt)


Bewertung
0 lesenswert
nicht lesenswert
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

von Johannes B. (johannesbehr)


Bewertung
0 lesenswert
nicht lesenswert
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

von Alexander H. (alexander_h390)


Bewertung
0 lesenswert
nicht lesenswert
Holy sh*t, Matt C. you are a genious!

von Matthias L. (malo)


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

von Víctor O. (vctor_o)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
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 ?

von Matt C. (thermomatt)


Bewertung
0 lesenswert
nicht lesenswert

von Xeno 2. (xeno22)


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

von Hans H. (Firma: kobs-ng) (haschhans)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
von Matt C. (thermomatt)


Bewertung
0 lesenswert
nicht lesenswert
The key does not depend on the serial number.  (The signatures do 
however.)

von Hans H. (Firma: kobs-ng) (haschhans)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Matt C. (thermomatt)


Bewertung
0 lesenswert
nicht lesenswert
> 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

von Hans H. (Firma: kobs-ng) (haschhans)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Matt C. (thermomatt)


Bewertung
0 lesenswert
nicht lesenswert
Yes I know that for sure.

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
von Sigma P. (sigmapic)


Bewertung
3 lesenswert
nicht lesenswert
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

von Jaro J. (jarotrn)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Sven L. (sven_rvbg)


Bewertung
1 lesenswert
nicht lesenswert
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!

von Matt C. (thermomatt)


Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
von Jaro J. (jarotrn)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jaro J. (jarotrn)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Schang S. schrieb:
> 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.

Hello Schang ,

May you tell me on what distribution of linux did you do that ?
If you have the repro steps, they are welcome.

von Hans H. (Firma: kobs-ng) (haschhans)


Bewertung
0 lesenswert
nicht lesenswert
Sigma P. schrieb:
> Schang S. schrieb:
>> 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.
>
> Hello Schang ,
>
> May you tell me on what distribution of linux did you do that ?
> If you have the repro steps, they are welcome.

After a quick search I saw that ubuntu 15.10 uses util-linux-2.62.2, but 
I had no time to test applying the patch.

von Schang S. (Firma: keine) (schang)


Bewertung
0 lesenswert
nicht lesenswert
Sigma P. schrieb:
> Schang S. schrieb:
>> 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.
>
> Hello Schang ,
>
> May you tell me on what distribution of linux did you do that ?
> If you have the repro steps, they are welcome.

I did that on a fresh Ubuntu

von Matt C. (thermomatt)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hi all,

The attached program might come in handy - it is a simplified version of 
losetup designed specifically for use with the cryptoloop module.  Make 
sure you modprobe cryptoloop first otherwise strange things may happen 
(kernel bug in some Linux versions).

Detaching, etc., can be done with normal losetup.

Matt

: Bearbeitet durch User
von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Matt C. schrieb:
> Hi all,
>
> The attached program might come in handy - it is a simplified version of
> losetup designed specifically for use with the cryptoloop module.  Make
> sure you modprobe cryptoloop first otherwise strange things may happen
> (kernel bug in some Linux versions).
>
> Detaching, etc., can be done with normal losetup.
>
> Matt

Thank you very much.
Very easy too build :)
I just had to add the following defines because recipes.img is 4GB:
#define _LARGEFILE_SOURCE
#define _FILE_OFFSET_BITS 64

I used aes-cbc for the cipher.

Unfortunetely I get:
mount: wrong fs type, bad option, bad superblock on /dev/loop0

I'm a looser...

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.

I looked a bit more to your hint. It's quite strange, this function 
replaces the input key by another one if the input is equal to a 
reference key, otherwise it keep the input key.

I tried to used these keys, but mount fails.

Do you know why the key in cookey.txt is so long (48 bytes) ?

von Matt C. (thermomatt)


Bewertung
1 lesenswert
nicht lesenswert
> I tried to used these keys, but mount fails.

Naturally the keys in the open source code are not the real keys, the 
build script replaces them with secret keys from ${KEYS_PATH} 
(https://github.com/scharri/vorwerk-tm5-oss-sources/blob/master/modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/linux-vorwerk_2.6.35.bb).

> Do you know why the key in cookey.txt is so long (48 bytes) ?

The length of the file doesn't matter, the loop-AES version of losetup 
hashes it to create the key (SHA256(password)[0:15])
- 
https://aur.archlinux.org/cgit/aur.git/tree/util-linux-2.29.2.diff?h=util-linux-aes#n1817 
. You can also search for strace in this thread to see what is passed to 
the kernel.

Matt

von Stephan Z. (thunder242)


Bewertung
0 lesenswert
nicht lesenswert
Matt C. are you able to build a little Programm to implement own recipes 
to the TM5?
I see your picture and you already send an recipe to the TM5.

von Sigma P. (sigmapic)


Bewertung
1 lesenswert
nicht lesenswert
Matt C. schrieb:
>> I tried to used these keys, but mount fails.
>
> Naturally the keys in the open source code are not the real keys, the
> build script replaces them with secret keys from ${KEYS_PATH}
> 
(https://github.com/scharri/vorwerk-tm5-oss-sources/blob/master/modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/linux-vorwerk_2.6.35.bb).

I missed this part in the script. I'm too bad....
But now it's ok, decryption done!!!!
Thanks for your very usefull help.

Next step, find the recipe chip verification bug.

Matt C. schrieb:
> 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.

von Johannes B. (johannesbehr)


Bewertung
0 lesenswert
nicht lesenswert
Hi Sigma,

it is great that you where able reproduce the decryption of the chip! I 
would like to do this too, in order to see how the receipts are 
structured and to prepeare for creating DIYs.
Could you please write a short summary which steps are necessary?

Greetings
Johannes

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Johannes B. schrieb:
> Hi Sigma,
>
> it is great that you where able reproduce the decryption of the chip! I
> would like to do this too, in order to see how the receipts are
> structured and to prepeare for creating DIYs.
> Could you please write a short summary which steps are necessary?
>
> Greetings
> Johannes

I'm sorry, for the same reasons than Matt, we can discuss about open 
source code but not give the decryption steps.

In fact everything is written on the forum. Start looking from Matt 
first post to my last post.

I hope you can understand...

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Sigma P. schrieb:
> Johannes B. schrieb:
>> Hi Sigma,
>>
>> it is great that you where able reproduce the decryption of the chip! I
>> would like to do this too, in order to see how the receipts are
>> structured and to prepeare for creating DIYs.
>> Could you please write a short summary which steps are necessary?
>>
>> Greetings
>> Johannes
>
> I'm sorry, for the same reasons than Matt, we can discuss about open
> source code but not give the decryption steps.
>
> In fact everything is written on the forum. Start looking from Matt
> first post to my last post.
>
> I hope you can understand...

There is something I still do not understand in this thread: why can't 
we discuss about the decryption steps if it is all based on open source 
code released by Vorwerk? I am not talking about decryption keys, that 
is another story.
I see this like the emulation scene: some hardware is emulated based on 
research and info public available, but to run it, you need a 
copyrighted ROM you legally own.
So, discussing the decryption steps should be no problem. Every one 
should get his own decryption keys if they are not published on open 
source code.
Sharing knowledge would lead to a quicker solution for creating own 
guided recipes for the Thermomix.

von Martin S. (sirnails)


Bewertung
0 lesenswert
nicht lesenswert
The reasons are:

- giving the exploit will cause Vorwerk to close the fraud because they 
can simply see the bugs location
- open source is only linux. Code written by Vorwerk is closed source
- There are some fair use rules for hackers to report security issues 
first to the developer instead of publishing them
- it against german laws to negotiate encryption (see hacking paragraph) 
and publishing it is a statutory offence creating a legal basis for 
Vorkwerk to become active and close this thread and moreover to 
complaint against µC.net.

You should not publish any code that is breaking german laws, patents 
and any other that may be covered by copyright.

: Bearbeitet durch User
von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> The reasons are:
>
> - giving the exploit will cause Vorwerk to close the fraud because they
> can simply see the bugs location

Yes, they could close the exploit, but we also can deny updates on our 
Thermomix (updates are only available if you have the Wifi Adapter. Who 
only uses recipe chips will never got an update, or will only have one 
if the Thermomix is repaired). An I was not talking about the exploit to 
create new recipes for a recipe chip, I was just talking about the 
decryption steps of the recipe chips.

> - open source is only linux. Code written by Vorwerk is closed source

Source code that Vorwerk sends to users who asks for it are not closed 
source but open source code. I think the decryption steps to decrypt the 
recipe chips are based on open source code, or did I miss something?

> - There are some fair use rules for hackers to report security issues
> first to the developer instead of publishing them

I would not call it a security issue (it will not compromise the 
security of the machine itself). I would call it a bug... But like I 
already wrote above, I am not talking about the exploit or decryption 
keys, but only from the decryption steps based on open source code 
public available.

> - it against german laws to negotiate encryption (see hacking paragraph)
> and publishing it is a statutory offence creating a legal basis for
> Vorkwerk to become active and close this thread and moreover to
> complaint against µC.net.

Like you told, it is a german law that applies to people living in 
Germany (it is also very difficult to get to someone outside Germany. 
Read at the bottom of the following page what lawyers say about this: 
https://www.internetrecht-rostock.de/hackerparagraf.htm). If we look at 
the complete thread, there are already posts explaining how to clone a 
recipe chip, that could be considered information to do piracy.

>
> You should not publish any code that is breaking german laws, patents
> and any other that may be covered by copyright.

Like already told, if the decryption steps are based only on open source 
code, this is not covered by copyrights and also german laws, because we 
are not distributing hacking tools or proprietary decryption keys, just 
discussing decryption methods like we could discuss the decryption 
methods of SSL/TLS...

I think all this information can be considered as research.

So, if the decryption steps are only based on open source code, then I 
do not see any problems on explaining it here. To explain it we do not 
need to publish real decryption keys (everyone that want to test it 
should get the decryption keys by their own). We also can find online 
the SSL/TLS decryption steps explained with examples without using real 
keys...

: Bearbeitet durch User
von Hans H. (Firma: kobs-ng) (haschhans)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> - giving the exploit will cause Vorwerk to close the fraud because they
> can simply see the bugs location
The recipe sticks are all encrypted with the same key. Even if we write 
a letter to Vorwerk that we know how to decrypt their sticks, they can 
not fix this with an update. The only thing they could do is create a 
new way of encrypting their sticks and block all sticks with the current 
encryption method. Every stick they selled until that day would not work 
anymore if you install the update (We could also just deny the 
installation). They will never do that because some guys that know how 
the decryption works. So I see no reason why we can not talk about the 
encryption(ask me about my github repo).

We could get problems if we talk about how to bypass the recipe 
verification and the bug/feature that makes it possible is fixable 
without the need to block all current recipe sticks(We could still deny 
updates). But since no one except Matt knows how to bypass the 
verification, I think we can talk freely here ;)

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Hello,

Does someone has a solution to debug a linux binary (ARM) from a x86 
platform.
I'm looking from a graphic debugger. Something like Ollydbg.

I tried to emulate an ARM CPU and running a gdbserver, then  on the host 
I tried to used ddd without success.

I also tried to execute the arm binary directly from my host in user 
mode emulation with qemu (qemu-arm). It works fine.
qemu-arm has an option -g allowing to wait a GDB connection.
But than what frontend can I use ?

If someone has an idea ?

von Peter T. (Firma: 420 blaze it) (peterteter420)


Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
Share your funny recipes :D
PS: Thank you Matt and thank you Ikaro.

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Peter T. schrieb:
> Share your funny recipes :D
> PS: Thank you Matt and thank you Ikaro.

Now the challenge is database analysis.
Replacing a picture and a piece of text is not so fun.

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Sigma P. schrieb:
> Peter T. schrieb:
>> Share your funny recipes :D
>> PS: Thank you Matt and thank you Ikaro.
>
> Now the challenge is database analysis.
> Replacing a picture and a piece of text is not so fun.

I already analyzed the databases from the iOS apps (SQL lite), does 
anyone can share in private a database from a cook sticks to see if it 
uses the same structure? On the iOS database there are fields with URLs 
for the pictures, I assume in the cook sticks they use relative paths.
How can we make tests with the database, is the missing method now 
shared privately?
Thanks to everyone who makes all this possible!

Happy New Year for everyone and let 2019 be the year where we can use 
our own recipes on our Thermomix machines! :)

von Peter T. (Firma: 420 blaze it) (peterteter420)


Bewertung
3 lesenswert
nicht lesenswert
Sigma P. schrieb:
> Peter T. schrieb:
>> Share your funny recipes :D
>> PS: Thank you Matt and thank you Ikaro.
>
> Now the challenge is database analysis.
> Replacing a picture and a piece of text is not so fun.

I created this recipe from scratch. If you need I can share my library.
Happy New Year for everyone :)

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Peter T. schrieb:
> Sigma P. schrieb:
>> Peter T. schrieb:
>>> Share your funny recipes :D
>>> PS: Thank you Matt and thank you Ikaro.
>>
>> Now the challenge is database analysis.
>> Replacing a picture and a piece of text is not so fun.
>
> I created this recipe from scratch. If you need I can share my library.
> Happy New Year for everyone :)

Hi Peter,

Happy new year!
Could you please send me a PM with your library?
Thanks and great work!

von Sebastian K. (5phinxx)


Bewertung
0 lesenswert
nicht lesenswert
Peter T. schrieb:
> Sigma P. schrieb:
>> Peter T. schrieb:
>>> Share your funny recipes :D
>>> PS: Thank you Matt and thank you Ikaro.
>>
>> Now the challenge is database analysis.
>> Replacing a picture and a piece of text is not so fun.
>
> I created this recipe from scratch. If you need I can share my library.
> Happy New Year for everyone :)

I also would appreciate to get this library! Happy new year

von Stephan M. (Firma: Herr) (assiy2k)


Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,
The same for me. Can you please share your libaries?

Thanks in advance

von Johannes B. (johannesbehr)


Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

Happy New Year!

I also would like to use your libraries :) !

About the receipts it might be helpfull checking the Format that is used 
on the Vorwerk Website. You can create a free account for 30 days. And 
with the free webanalyser software Fiddler you can see the 
Jason-communication in clear text…

von Matthias L. (malo)


Bewertung
0 lesenswert
nicht lesenswert
I'm trying to mount it, but still failing. This replacement file... 
where does it come from? It's not included in the sources, but where 
else..?

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Johannes B. schrieb:
> Hi Peter,
>
> Happy New Year!
>
> I also would like to use your libraries :) !
>
> About the receipts it might be helpfull checking the Format that is used
> on the Vorwerk Website. You can create a free account for 30 days. And
> with the free webanalyser software Fiddler you can see the
> Jason-communication in clear text…

On the recipe chip, it's a sqlite databse.
What about cookidoo json format ?

von Johannes B. (johannesbehr)


Bewertung
0 lesenswert
nicht lesenswert
Hi Sigma,

it is just an idea. As I do not have the knowledege nor the equipment to 
decode/read my tm5 chips yet, I do not know how the data in the 
SQLite-db looks like. But maybe comparing it with the structure Vorwerk 
uses to transmit the receipts to the cookidoo webclient (in json) might 
give clues how the receipt are structured and which elements are 
supported. Anyway it is nice to see the clear text of the receipts :-) 
...

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Peter T. schrieb:
> Sigma P. schrieb:
>> Peter T. schrieb:
>>> Share your funny recipes :D
>>> PS: Thank you Matt and thank you Ikaro.
>>
>> Now the challenge is database analysis.
>> Replacing a picture and a piece of text is not so fun.
>
> I created this recipe from scratch. If you need I can share my library.
> Happy New Year for everyone :)

Hi everyone,

did anybody here got the library from Peter T. that can share it in 
private?
I would like to make some tests with the SQL Lite database... :)

von Sebastian K. (5phinxx)


Bewertung
0 lesenswert
nicht lesenswert
Bimby T. schrieb:
> Hi everyone,
>
> did anybody here got the library from Peter T. that can share it in
> private?
> I would like to make some tests with the SQL Lite database... :)

No, I did not get the lib either... Maybe Peter is a bit busy this days 
?

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
What I can say for the moment about database:

Database contains the same data than the book or cookidoo website as : 
ingredients, recipe steps, price, difficulty...

In addition there are some data  regarding guided steps:
temperature, scale, speed...

All these data are scattered over almost 200 tables.
Some data are dupplicated in several tables.
There are a lot of indirections as well.

It's a database...

So, it takes time to understand the whole structure.
I finished to reverse the database structure.
Now I'm writting a library with user firendly API that allow to add new 
recipe to the DB.

Please, be patient.

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Sigma P. schrieb:
> What I can say for the moment about database:
>
> Database contains the same data than the book or cookidoo website as :
> ingredients, recipe steps, price, difficulty...
>
> In addition there are some data  regarding guided steps:
> temperature, scale, speed...
>
> All these data are scattered over almost 200 tables.
> Some data are dupplicated in several tables.

Hi Sigma, it seems that the database is the same used on the iOS app. 
Did you already succeed on using your own recipes on the Thermomix 
again?

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Bimby T. schrieb:
> Sigma P. schrieb:
>> What I can say for the moment about database:
>>
>> Database contains the same data than the book or cookidoo website as :
>> ingredients, recipe steps, price, difficulty...
>>
>> In addition there are some data  regarding guided steps:
>> temperature, scale, speed...
>>
>> All these data are scattered over almost 200 tables.
>> Some data are dupplicated in several tables.
>
> Hi Sigma, it seems that the database is the same used on the iOS app.
> Did you already succeed on using your own recipes on the Thermomix
> again?

No yet tried.
Work in progress.

I don't have an iPhone, but I can borrow one to check the db format.
Is is easy to extract the db for the app ?
No jailbreak needed ?

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Sigma P. schrieb:
> No yet tried.
> Work in progress.
>
> I don't have an iPhone, but I can borrow one to check the db format.
> Is is easy to extract the db for the app ?
> No jailbreak needed ?

Yes, you need a jailbroken iPhone to get the database from the app, this 
is why Vorwerk never released an android app... :P

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Bimby T. schrieb:
> Yes, you need a jailbroken iPhone to get the database from the app, this
> is why Vorwerk never released an android app... :P

How does it work ?
All recipes are integarted in the app ? because app is ~250MB
All recipes are in the same db or db is created with recipes you select 
?

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Bimby T. schrieb:
> Yes, you need a jailbroken iPhone to get the database from the app, this
> is why Vorwerk never released an android app... :P

Is it possible to download the ipa file and extract the db from the ipa 
?

von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Sigma P. schrieb:
> Bimby T. schrieb:
>> Yes, you need a jailbroken iPhone to get the database from the app, this
>> is why Vorwerk never released an android app... :P
>
> Is it possible to download the ipa file and extract the db from the ipa
> ?

Yes it is.
I just did it.

Bimby T. schrieb:
> I already analyzed the databases from the iOS apps (SQL lite), does
> anyone can share in private a database from a cook sticks to see if it
> uses the same structure? On the iOS database there are fields with URLs
> for the pictures, I assume in the cook sticks they use relative paths.

The db from ios app contains at set of tables that start with Z, for 
example ZRECIPEMODEL...

Is it right?
You analysed this db ?

This db is quite different than the one from recipe chip.

von Matthias L. (malo)


Bewertung
0 lesenswert
nicht lesenswert
Hey,

it's great for you that you can now discuss about data formats etc... I 
would really appreciate participating here, but do not have any 
chance... I'm still struggling with decrypting the chip.. some more 
hints please?

Best regards
Matthias

von Eric E. (eric_e665)


Bewertung
0 lesenswert
nicht lesenswert
I have a jailbroken iPad.
Just let me know if I can help providing files :-)

BR

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Sigma P. schrieb:
> The db from ios app contains at set of tables that start with Z, for
> example ZRECIPEMODEL...
>
> Is it right?
> You analysed this db ?
>
> This db is quite different than the one from recipe chip.

For each country you select in the app you will reset and fill the 
database with recipes from this country (you need to select to download 
all recipes on the app settings. It will take some time until all 
recipes are downloaded.). Yes, almost all fields start with Z but the 
structure seems to be almost the same that you mentioned for the cook 
stick. I have studied the database some time ago and also the XML from 
the recipes provided by the server, but have to look if I still have my 
notes about it.

von Xeno 2. (xeno22)


Bewertung
0 lesenswert
nicht lesenswert
Sigma P. schrieb:
> Bimby T. schrieb:
>> Yes, you need a jailbroken iPhone to get the database from the app, this
>> is why Vorwerk never released an android app... :P
>
> How does it work ?
> All recipes are integarted in the app ? because app is ~250MB

App documents data with all (german) recipes is ~662MiB.

von Tobias C. (toco)


Bewertung
0 lesenswert
nicht lesenswert
Xeno 2. schrieb:
> Sigma P. schrieb:
>> Bimby T. schrieb:
>>> Yes, you need a jailbroken iPhone to get the database from the app, this
>>> is why Vorwerk never released an android app... :P
>>
>> How does it work ?
>> All recipes are integarted in the app ? because app is ~250MB
>
> App documents data with all (german) recipes is ~662MiB.

The Z table prefix is a strong indicator that the SQLite is the backing 
store for CoreData. https://developer.apple.com/documentation/coredata
In that case the iOS app and and TM 5 are definitely not sharing any 
database code, though they might still use a similar layout.

I don’t think reverse engineering the SQLite format of the iOS app will 
help.
I’d focus on the actual recipe chip DB layout and not waste time on the 
iOS app.

von Bimby T. (bimby)


Bewertung
1 lesenswert
nicht lesenswert
Tobias C. schrieb:

> I’d focus on the actual recipe chip DB layout and not waste time on the
> iOS app.

The problem is that from what I have seen here, only 2 people figured 
out how to test the changed database on the Thermomix. If we have the 
luck that the iOS app database is the same from the recipe chips, then 
we could test changes on the iOS app.

I have found this today on another site https://pastebin.com/9F4hFy3n 
but do not know if this is the correct database layout. Can anyone here, 
that already decrypted a recipe chip, confirm if this is the correct 
database layout?

: Bearbeitet durch User
von Sigma P. (sigmapic)


Bewertung
0 lesenswert
nicht lesenswert
Bimby T. schrieb:
> Tobias C. schrieb:
>
>> I’d focus on the actual recipe chip DB layout and not waste time on the
>> iOS app.
>
> The problem is that from what I have seen here, only 2 people figured
> out how to test the changed database on the Thermomix. If we have the
> luck that the iOS app database is the same from the recipe chips, then
> we could test changes on the iOS app.
>
> I have found this today on another site https://pastebin.com/9F4hFy3n
> but do not know if this is the correct database layout. Can anyone here,
> that already decrypted a recipe chip, confirm if this is the correct
> database layout?

Yes it is. :)
On what website did you find it ?

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Sigma P. schrieb:

> Yes it is. :)

Cool, so anyone that wants to contribute with the database analysis can 
now use this layout... :)

> On what website did you find it ?

It was posted on git, but I have now seen that the account is not 
available anymore... But the shared Pastebin link is still working... :)

von Xeno 2. (xeno22)


Bewertung
0 lesenswert
nicht lesenswert
So, does anybody still need the iOS DB?

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Xeno 2. schrieb:
> So, does anybody still need the iOS DB?

I think it will not harm if you post the database layout from iOS... I 
think Vorwerk would not change too much the layout of both databases so 
maybe it will help the analysis of the recipe chip database...

von Hans H. (Firma: kobs-ng) (haschhans)


Bewertung
0 lesenswert
nicht lesenswert
Bimby T. schrieb:
> Xeno 2. schrieb:
>> So, does anybody still need the iOS DB?
>
> I think it will not harm if you post the database layout from iOS... I
> think Vorwerk would not change too much the layout of both databases so
> maybe it will help the analysis of the recipe chip database...

Posting dbs shouldnt be a problem, old db layout will always work 
because of compability. What I worry about is the way we baypass the 
signature verification. They can easily fix that via ota. I will look 
for a way to check what they want to update via the ota.

von Xeno 2. (xeno22)


Bewertung
1 lesenswert
nicht lesenswert
This is the layout of the initial DB file (v16  de  28.11.2018) - if 
anybody needs the contents, just throw a PM:
https://pastebin.com/H2tC9gJ9

von Karibrusa B. (karibrusa)


Bewertung
0 lesenswert
nicht lesenswert
Is the last post the layout from the receipe chip?
How is the DB stored on the chip?
USB is clear - But how can I access the dabase , which filesystem, 
encryption or hidden partion is used? I did see that some people were 
able to access, but I did not see how they did .

Beitrag #5688330 wurde vom Autor gelöscht.
von Xeno 2. (xeno22)


Bewertung
0 lesenswert
nicht lesenswert
No, this DB layout is from the iOS App.

von Ikaro P. (ikaro_p)


Bewertung
0 lesenswert
nicht lesenswert
(I know I'm late... more comming soon, I promiss)

2faf 32c6 f26b 5cc0 21c1 8988 019a f3a5

von Bimby T. (bimby)


Bewertung
0 lesenswert
nicht lesenswert
Ikaro P. schrieb:
> (I know I'm late... more comming soon, I promiss)
>
> 2faf 32c6 f26b 5cc0 21c1 8988 019a f3a5

Hi Ikaro P.,

it is never late for sharing your findings. :)
Is this the encryption key for the cook key or the piece of code where 
the signature of the key is checked?

Thanks and keep the great work! :)

von Hans H. (Firma: kobs-ng) (haschhans)


Bewertung
0 lesenswert
nicht lesenswert
Bimby T. schrieb:
> Ikaro P. schrieb:
>> (I know I'm late... more comming soon, I promiss)
>>
>> 2faf 32c6 f26b 5cc0 21c1 8988 019a f3a5
>
> Hi Ikaro P.,
>
> it is never late for sharing your findings. :)
> Is this the encryption key for the cook key or the piece of code where
> the signature of the key is checked?
>
> Thanks and keep the great work! :)

Its the actual encryption key for the cookey. You can extract it from 
matts kernel dump.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.