Sigma P. schrieb: > I successfully emulated the ARM926EJ-S processor (processor from TM5) > with Qemu. Hey Sigma, can you please give us a short introduction how to load the image with QEMU? Thanks David
Ikaro P. schrieb: > Looks like this community is stuck, so I have decided to give us all a > little present. > > EiOJeNLiooqwWobaVDVrbJWLCifvQC5oDqNqHfuSYBt3y4vwN3YKq2EsvFK3U4M9 > (AES128) Findet sich übrigens in /opt/cookey.txt
David N. schrieb: > Hey Sigma, > > can you please give us a short introduction how to load the image with > QEMU? > > Thanks > David You need a working install of QEmu. Then you can download prebuild images (linux + debian squeeze) and you run it with the given command line. Then, access through ssh. Next step, I will install a gdb server on the emulated system so I will be able to debug binaries from my host with any comaptible tool.
Different approach: man-in-the-middle attack with the cookkey to sniff the wifi traffic. - Is this possible with the given certificates under /tmp/certificates or the /opt/cookey.txt file? - Or do we need a certificate from our own Thermomix? - another idea is to find any code in the image, where the cookey date gets processed
Noch ein Ansatz wäre, etwas mit dem Key in der /opt/cookey.txt zu entschlüsseln. Dafür habe ich mal in allen Dateien nach "cookey.txt" gesucht. In der Datei /usr/sbin/netlink habe ich folgenden Code gefunden. Könnte der dafür genutzt werden, um die Daten des USB-Sticks der sich im Cookkey befindet zu entschlüsseln?
1 | ------------ Power-cycling USB interface ---------- |
2 | /etc/rc.d/init.d/usbpower stop |
3 | /etc/rc.d/init.d/usbpower start |
4 | mkdir -p /tmp/dev/ |
5 | mknod /tmp/dev/ttyACM0 c 166 0 |
6 | /usr/sbin/eth stop |
7 | settings_cloud.sdb material/photo/150x150/vorwerk_trademark_logo.png |
8 | umount -f |
9 | losetup -d |
10 | rm -f |
11 | rmdir |
12 | /usr/sbin/eth start |
13 | mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ mkfs.ext4 |
14 | tcsetattr usbTermio /sys/ /idVendor i j q u z rm -f /tmp/dev/ sd /../../../../../../../serial sr s.+(\d+) sd([a-z])\d+ |
15 | mknod -m 644 /tmp/dev/loop b 7 |
16 | mknod -m 644 /tmp/dev/ b 11 b 8 |
17 | mkdir -p |
18 | losetup -e aes128 -P /opt/cookey.txt |
19 | mount -o ro |
20 | mount |
Da scheint ja bei vielen Zeilen etwas zu fehlen. Als ob dies der "linke Teil" eines Skriptes währe und der "recht Teil" fehlt. (Z.b. "rm -f" ohne Argument macht keinen Sinn) Die relevante Zeile "losetup -e aes128 -P /opt/cookey.txt" ist auch nicht komplett. Falls wir annehmen das was dasteht richtig ist und nur rechts was fehlt dann währe der /opt/cookey.txt nur ein device identifier und nicht der geheime Schlüssel. Eventuell hast du da einen Textblock gefunden der vom Programm noch verändert wird bevor er ausgeführt wird?
Chris R. schrieb: > Noch ein Ansatz wäre, etwas mit dem Key in der /opt/cookey.txt zu > entschlüsseln. Dafür habe ich mal in allen Dateien nach "cookey.txt" > gesucht. In der Datei /usr/sbin/netlink habe ich folgenden Code > gefunden. Könnte der dafür genutzt werden, um die Daten des USB-Sticks > der sich im Cookkey befindet zu entschlüsseln? > >
1 | > ------------ Power-cycling USB interface ---------- |
2 | > /etc/rc.d/init.d/usbpower stop |
3 | > /etc/rc.d/init.d/usbpower start |
4 | > mkdir -p /tmp/dev/ |
5 | > mknod /tmp/dev/ttyACM0 c 166 0 |
6 | > /usr/sbin/eth stop |
7 | > settings_cloud.sdb material/photo/150x150/vorwerk_trademark_logo.png |
8 | > umount -f |
9 | > losetup -d |
10 | > rm -f |
11 | > rmdir |
12 | > /usr/sbin/eth start |
13 | > mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ |
14 | > mkfs.ext4 |
15 | > tcsetattr usbTermio /sys/ /idVendor i j q u z rm -f /tmp/dev/ sd |
16 | > /../../../../../../../serial sr s.+(\d+) sd([a-z])\d+ |
17 | > mknod -m 644 /tmp/dev/loop b 7 |
18 | > mknod -m 644 /tmp/dev/ b 11 b 8 |
19 | > mkdir -p |
20 | > losetup -e aes128 -P /opt/cookey.txt |
21 | > mount -o ro |
22 | > mount |
23 | > |
netlink is a binary. All these strings are used in the binary. There may be no link between these strings depending on how they are used inside the binary. A also started to analyse this binay. I have a lot of difficulties to debug the binary in my qemu system. So I will continue static analysis. Note: It would be great if you can speak english
If the static analysis gets too involved it might be an idea to have the program do its thing and observe it on the way. I can think of two things: - Use strace (with -f) to get the calls the program makes to other programs (mentioned as "execve" in the strace output). This would require a strace program on the platform. If that is not there one might need to get it from a compatible system. - My tests with strace (on a desktop linux system) showed that the subprogram to be called is not invoked directly, but rather through a call to /bin/sh. That means one could create a program/script (placed in the old location of /bin/sh) that logs the call to a file before the (renamed) real /bin/sh is called. (There is a potential for a big problem here, if the logging or calling the original sh needs to call /bin/sh we just created a recursion. One would need to try this.) The whole process will probably be a bit involved since the netlink binary certainly will check some conditions before the actual losetup call is made. One would need to make sure that these are fulfilled one by one.
Hi, I thin we found something very interesting here. It should give us a hint how the Chips data is decrypted by the software. I'm not a Pro when it comes to that things, but the first readable String in the binary is "ELF". i know .elf files from AVR-GCC it descripes how to link and build things. From the Wiki article one can further notice that this is definitly an elf-File. Magic Number is 0x7F followed by ELF. So we should be able to processes and anaylse this file using one of the Tools mentioned in the article. https://en.wikipedia.org/wiki/Executable_and_Linkable_Format What I found out with a Hex Editor: data size: 32bit endiness: little endian ELF Version: original version of ELF target System: systemV ? Version: 0 type: executable target architecture: ARM ... the rest is to much for my electricians brain :) need a software guy. Cu David
The code I found in /usr/sbin/netlink is of course not usable. But I thought to post it, because it reveals details about how to mount the encrypted Cook-Key. But I don't have the skill to mount the encrypted image. There is a file called "tm5.img" on the Cook-Key as written in
1 | mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ mkfs.ext4 |
But how do I work with it? cryptsetup & mount & ... ?!
:
Bearbeitet durch User
Also ich habe übermorgen eine Vertreterin zu besuch - hatte ernsthaftes Interesse - bis ich gerade auf das Problem (welches eigentlich keines sein dürfte) eigenes Rezept gestoßen bin. Das naheliegenste (Familien und Lieblingsrezepte) einzuspielen ist nicht möglich???? ernsthaft?? warum? gelinggarantie? so what?? Ganz ehrlich, ich würde mir so n Ding zu dem preis (Produktionswert ca 200€) schon Kaufen, wenn auch überteuert, weil die Qallität sehr gut ist, aber das iphone war das letzte Gerät welches mich als Kunde Kastriert hat. Wer Kunden daran hindert das System technisch voll auszunutzen (eigene Rezepte/kein root iphone) stattdessen mit Abos / Einschränkungen und unverhältnismäßiger Kryptografie Ihre Kunden an die Leine nimmt, den werde ich aus Prinzip nicht unterstützen. Dann hätten die auch n eigenes Betriebssystem schreiben müssen und nicht auf freie Software zurückzugreifen (Linux). Hätte ich nicht schon die Zutaten gekauft, würde ich der Termomix Vertreterin Absagen. Ich hoffe Ihr bekommt das System ent-kastriert, kaufen würde ich ihn mir aber auch dann nicht, nicht weil ich gegen Patentrechte verstoßen, sondern damit eine Firmenpolitik unterstützen würde, die in meinen Augen total in die falsche Richtung läuft.
Chris R. schrieb: > Ikaro Psi, great work!! Thank you! > > How can we get the image from our TM5 ourselves?? This would help the > most! I'm sorry but I will not reveal the exploit since that would make the vendor issue an firmware update with the fix and most probably close any realistic homebrew development of the platform. And even in the case I discover a proper "unfixable" rooting method in the future (e.g. something like finding the usable firmware signing key), I would still need to inform the vendor first. I have somewhat full root access to the platform but I don't think one needs to have that for the work on a homebrew. Vast majority of the fiddling can and should be done in an emulator, the platform itself is a minefield anyway and one could destroy his TM with just a stupid little typo. It might seem a bit protective stand but I will hold it for now. > Different approach: man-in-the-middle attack with the cookkey to sniff > the wifi traffic. > - Is this possible with the given certificates under /tmp/certificates > or the /opt/cookey.txt file? > - Or do we need a certificate from our own Thermomix? Sadly this is not possible for two reasons now: - the process of registration of the TM to the online system is probably the way the per device client certificate is issued and I think that one is used most of the time. - TM strictly enforces the verification of the server certificate. Public CA system is not used and the only certificates accepted must stem from Vorwerk's internal CA. I hope we would be able to run the GUI and the netlink parts in the emulator with replaced CA certificates so the (not so much now) MitM attack would be possible. We could reverse engineer the protocol and than develop a custom server using the specificiation created (clean room). Since one need to replace the CA certificat on TM for this to work and since there is no easy way of doing this, my afford is focused in this direction mostly now. > The whole process will probably be a bit involved since the netlink > binary certainly will check some conditions before the actual losetup > call is made. I'm pretty sure netlink is just inserting the correct device filename and all the magic is done either by patched losetup or patched kernel itself. I was unable to decrypt any image even by using TM's losetup binary in my emulator, it's a big mind=boogle... I'm looking forward to the static analysis findings... I hoped someone here would be able and willing to do it, since I prefer not to touch tools like IDA ever again :)) > There are a lot of interesting things but the most important one is the > binary /user/sbin/checkimg. That one is used in an update process, since distributed firmware is encrypted with a static global key but to flash it one need to encrypt it using device specific keys and also since the update package can have some preupdate and postupdate payloads and hooks ect.
:
Bearbeitet durch User
Sigma P. schrieb: > David N. schrieb: >> Hey Sigma, >> >> can you please give us a short introduction how to load the image with >> QEMU? >> >> Thanks >> David > > You need a working install of QEmu. > Then you can download prebuild images (linux + debian squeeze) and you > run it with the given command line. Which command line? I'd love to give that QEMU approach a try as well, but I've never used QEMU before. Would someone please give more detailed instructions on how to access a QEMU environment with this firmware? I'm sure there's more people who would appreciate this. I've had a quick first look at the firmware files. Very interesting, fantastic job, Ikaro Psi. Here's a few little things I realized that might be somewhat interesting, but that nobody hasn't mentioned yet: 1) There is no password set for the "root" user in /etc/shadow. If one would somehow get to a login prompt, the password for the root user should be a simple [ENTER] 2) There are a few sqlite3 database files with the file suffix .sdb in the opt/Thermomix directory: contact.sdb settings_cloud_default.sdb settings_empty_en.sdb settings_empty_tw.sdb subscription_empty.sdb subscription.sdb No recipes seem to be stored in these files though. The most interesting information I could find in these files were the following tables: Table "settingsCloudApp" in file "settings_cloud_default.sdb":
1 | id|remoteAddress|TCPPort|remotePath|pingAddress |
2 | 1|css.tmecosys.com|443|/ws|l.root-servers.net |
which suggests URL https://css.tmecosys.com:443/ws Table "settingsCloudAppDebug" in file "settings_cloud_default.sdb":
1 | id|mac|ssn|serial|version |
2 | 1|AABBCCDDEEFF|0123456789ABCDEF|00000000000000000|203801010000 |
Table "settingsCloudApp" in "settings_empty_en.sdb":
1 | id|remoteAddress|TCPPort|remotePath |
2 | 1|css.tmdesync.com|3080|/ws.ashx |
which suggests URL https?://css.tmdesync.com:3080/ws.ashx Simply entering these URLs in a webbrowser is not successful though; the first URL responds with a "403 Forbidden", the second one doesn't seem to respond at all. 3) As I get it, the ARM seems to communicate with some microcontroller via the serial line /dev/ttySP0 at 38400 bps:
1 | (file opt/common.sh) |
2 | |
3 | mc_configure_stty() { |
4 | # configure serial port to similiar values that libntm does, but before GUI is started |
5 | stty -F /dev/ttySP0 -icrnl -ixon -opost -onlcr -isig -icanon -iexten -echo 38400 |
6 | } |
7 | |
8 | mc_turn_off_shutdown_timer() { |
9 | # set shutdown timer to 15min. (0xFFFF) to |
10 | # prevent shutdown after killing GUI app by force |
11 | echo -e -n "\x55\x03\x10\xFF\xFF\x8C" > /dev/ttySP0 |
12 | } |
13 | |
14 | mc_keep_alive() { |
15 | # sends heart-beat packet to MC |
16 | echo -ne "\x55\x08\x30\x50\x06\x50\x06\x10\x00\x00\xB8" > /dev/ttySP0 |
17 | } |
18 | |
19 | mc_reset() { |
20 | # resets the MC |
21 | echo -e -n "\x55\x01\x11\xFD" > /dev/ttySP0 |
22 | } |
> I'm pretty sure netlink is just inserting the correct device filename > and all the magic is done either by patched losetup or patched kernel > itself. I was unable to decrypt any image even by using TM's losetup > binary in my emulator, it's a big mind=boogle... If it's the case, do you have a idea how to continue. > since I prefer not to touch tools like IDA ever again :)) Why, IDA Pro is perfect for that. > Which command line? I'd love to give that QEMU approach a try as well, > but I've never used QEMU before. Would someone please give more detailed > instructions on how to access a QEMU environment with this firmware? > I'm sure there's more people who would appreciate this. I tested on Ubuntu. Install Qemu: sudo apt-get install qemu-system Dwnload the 3 following images on : debian_squeeze_armel_standard.qcow2 initrd.img-2.6.32-5-versatile vmlinuz-2.6.32-5-versatile Run QEmu with command line: qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1" -redir tcp:2200::22 Then connect through SSH with: ssh user@localhost -p 2200 User account: user User password: user (Root password: root) You can see VM output by using a VNC viewer (https://www.realvnc.com for example) on port 5900 (for me). You can send binaries you want to execute through SSH (scp command). Have fun! Ikaro Psi, what analysis do you suggest to do ? I'm looking to netlink with IDA Pro but maybe you have some better ideas not losing time on IDA Pro.
Joachim S. schrieb: > 3) As I get it, the ARM seems to communicate with some microcontroller > via the serial line /dev/ttySP0 at 38400 bps: Where did you find this information? As I wrote a bit earlier, there is a STM32F100R8 and a ATxmega16D4 on the power board. Some pictures[0][1]. The STM32 has also a 2x10 JTAG connector next to it. I assume that your finding is the thermomix applications way to communicate with one or both of them. [0]: https://78.media.tumblr.com/f4770bfb4d43e861ebbe6c4b5c7b1d8b/tumblr_oyjxnyog0s1sk4l6uo8_1280.jpg [1]: https://78.media.tumblr.com/f322fccd257abc3ce32bbd0f469cf363/tumblr_oyjxnyog0s1sk4l6uo3_1280.jpg Edit: attached pics to post.
:
Bearbeitet durch User
Moritz M. schrieb: > Joachim S. schrieb: >> 3) As I get it, the ARM seems to communicate with some microcontroller >> via the serial line /dev/ttySP0 at 38400 bps: > > Where did you find this information? In file /opt/common.sh But it really only contains the commands I mentioned in my previous posting. Apparently, the serial communication with these microcontrollers is usually handled by "libntm", and common.sh only contains those commands that need to be sent via the serial line while libntm is not running. Moritz M. schrieb: > As I wrote a bit earlier, there is a STM32F100R8 and a ATxmega16D4 on > the power board. Some pictures[0][1]. The STM32 has also a 2x10 JTAG > connector next to it. > > I assume that your finding is the thermomix applications way to > communicate with one or both of them. Very likely indeed. I remember from another thread on hacking the TM31 (Beitrag "Thermomix TM31 Modifikation") that the previous model used a similar approach: The main CPU sends commands for the actual actions to perform (e.g. Heat to temperature X, Make motor rotate left at speed Y) via a serial line to a microcontroller on the power board. It seems like they kept that architecture in the TM5 model, but changed the serial protocol. Sigma P. schrieb: > Run QEmu with command line: > qemu-system-arm [...] Thanks a lot for the instructions, I had a stupid misunderstanding. To make the process of setting up a working QEMU environment very easy, I created a small Linux shell script named tm5.sh (see attachment) that might be useful to others. To use it: 1. Download tm5.sh (attachment of this posting) and make it executable (chmod 755 tm5.sh) 2. Download the squashfs firmware file, and place it in the same directory as tm5.sh, under filename "tm5_firmware.squashfs" 3. Ensure you have the required software packages installed. qemu-system is needed (sudo apt-get install qemu-system), I believe all other software is installed on most linux systems by default. 4. Run ./tm5.sh. The script will download and create a few files if necessary, then start QEMU. 5. Login (Username: root, password: root). 6. The TM5 filesystem is stored in directory /tm5. To chroot into this directory, simply enter "tm5_chroot"
> To make the process of setting up a working QEMU environment very easy, > I created a small Linux shell script named tm5.sh (see attachment) that > might be useful to others. To use it: Well done! On my side, I'm stuck. It seems that when netlink is called (because a recipe chip has been attached), the stick has already been read and netlink check if tm5.img is present in tmp. Then some checks are done. These strings appear: - Storage partition found at %s (S/N: %s) - Partition containing recipe DB is found - Expecting official recipe chip --> perf - /opt/ref.sig ref.sig seems to be a public key (not sure at all). Do you have some ideas ?
Beitrag #5217033 wurde vom Autor gelöscht.
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
Bimby T. schrieb: > Hi there, have you seen that there is a global variable that allows > pirated cookie? > Just check the file on /etc/rc.d/rc.local, they even call it "pirated > cookie"! :P > [...] > So if Ikaro_Psi could develop a way that would allow us to change this > global variable, maybe we could use a "pirated cookie"... :) I stumbled upon that too. But the problem I see is that none of the choices actually allows that pirated cookie being mentioned: > # Possible values: 0 - not RDV version, no support for pirated cookie > (EXT4 formatted cookie). > # 1 - RDV version, no support for pirated cookie. And apart from that: What is a "cookie" in this context anyway? Did they just misspell "Cook-Key"? I didn't quite get it, just as I didn't get what it has to do with "recipe development". > Why is there a wireless connection already on the firmware? Please check > the file /usr/local/routerlist.txt: > > dlink1 "dlink-8B91" "zubnw96594" > > Can it be that the TM5 enters some service mode when it connects to this > wireless SSID "dlink-8B91" and password "zubnw96594"? Or is this the > router data from Ikaro_Psi? :/ It seems unlikely that this is Ikaro Psi's own router data, as the .squashfs file we are looking at is a readonly filesystem. None of the files should contain any data that belongs to a specific TM5. It seems like "routerlist.txt" is only being used by "/usr/bin/testrouter"; that shell script will try to connect to a wireless network with the SSID/PSK you mentioned, and writes to file "/mnt/rwfs/data/tech_box/routertests.log" if it was successful. I assume that this WLAN access point is only being used during the manufacturing of the TM5 or the Cook-Key, simply to test if the WLAN works correctly.
Joachim S. schrieb: > I stumbled upon that too. But the problem I see is that none of the > choices actually allows that pirated cookie being mentioned: >> # Possible values: 0 - not RDV version, no support for pirated cookie >> (EXT4 formatted cookie). >> # 1 - RDV version, no support for pirated cookie. I think the no for the value 1 (RDV version) is a typo, because the variable sets the Recipe Development Version active, so the engineers can use EXT4 formatted cookie's (I think without encryption). > And apart from that: What is a "cookie" in this context anyway? Did they > just misspell "Cook-Key"? I didn't quite get it, just as I didn't get > what it has to do with "recipe development". From what I have read, the cookie ist the "read only" recipe chips (internal with a USB flash drive detected as a CD-ROM drive) that are used on the side of the TM5. The Cook-Key is the wireless adapter with a "read/write" USB flash drive. I think if the global variable is set to 1 as RDV version, we could use a normal USB flash drive with own recipes in the same XML format found on the .squashfs file.
:
Bearbeitet durch User
Bimby T. schrieb: > Joachim S. schrieb: >> I stumbled upon that too. But the problem I see is that none of the >> choices actually allows that pirated cookie being mentioned: >>> # Possible values: 0 - not RDV version, no support for pirated cookie >>> (EXT4 formatted cookie). >>> # 1 - RDV version, no support for pirated cookie. > > I think the no for the value 1 (RDV version) is a typo, because the > variable sets the Recipe Development Version active, so the engineers > can use EXT4 formatted cookie's (I think without encryption). > That could make sense. My thought was that a there was a mechanism which puts the TM5 in a somehow broken state once he detects somebody is trying to use a pirated/manipulated cookie (the recipe one). Not that it makes sense, but what I've read from vorwerk I would not wonder if they dare doing that kind of stuff.
Moritz M. schrieb: > That could make sense. My thought was that a there was a mechanism which > puts the TM5 in a somehow broken state once he detects somebody is > trying to use a pirated/manipulated cookie (the recipe one). Not that it > makes sense, but what I've read from vorwerk I would not wonder if they > dare doing that kind of stuff. I can not test it, first I do not know how to get access to the system and second I do not own a TM5. :) The best way would be to find out how the encrypted cookie works, because we could then create a "pirated" cookie with our own recipes without messing with the firmware... In my opinion, the Cook-Key (wireless adapter) is not worth it because it is only limited to the recipes that vorwerk has approved on their portal and asks for a subscription to access it. The TM5 is nothing more than a TM31 with a Raspberry Pi on it. :D Did anyone know if we can control the TM31 over infrared diagnostic port, so I could use a smartphone with IR and develop an app that does the same as the TM5, but not limited to their recipes! ;)
Bimby T. schrieb: > The TM5 is nothing more than a TM31 with a Raspberry Pi on it. :D Pretty much, yeah. > Did anyone know if we can control the TM31 over infrared diagnostic > port, so I could use a smartphone with IR and develop an app that does > the same as the TM5, but not limited to their recipes! ;) I didn't quite get that sentence: Was it a question asking if the TM31 can be controlled over the infrared diagnostic port, or was it a statement pointing out that the TM31 can in fact be controlled over that port? Either way, I actually wonder if it doesn't make sense to simply develop an alternative main board for the Thermomix, instead of trying to hack the original one. I believe that would have a few advantages: - The same board could probably be used for both the TM5 and the TM31; that way, owners of the TM31 could get the advantages of the TM5, people who don't own a Thermomix yet could buy a cheap used TM31 and basically turn it into a TM5 - No dangerous messing around at all with the expensive original board; the original board is simply being replaced. In case the Thermomix must be sent in for repair, the original, unmodified board is installed again, and Vorwerk cannot detect any modification. And as we are not hacking the original TM5 firmware by using some security holes, Vorwerk cannot simply close those security holes by shipping an updated firmware - No legal issues whatsoever, as we are not hacking the original system's security Even if at some point we should find a way to truly hack the TM5, I think it would be worth to go that path as an alternative & perfectly legal approach. The guy who started this thread: Beitrag "Thermomix TM31 Modifikation" already began working on that approach for the TM31...
Just for curiosity, does anybody already got the firmware 201706290000 2.3 on their TM5. I'm stuck with 2016... 2.2 and pushing the update button does only say there is no update.
Joachim S. schrieb: > Either way, I actually wonder if it doesn't make sense to simply develop > an alternative main board for the Thermomix, instead of trying to hack > the original one. The problem with that is that you would need to open up your Thermomix. I was asking if someone know if it where possible to control the TM31 over the diagnostic infrared port, so we did not need to open it up to change the original one. On the TM5 there is no infrared port, so the easiest alternative would be hacking the cookie encryption, because they could not change that on new firmware, or the TM5 would loose access to the older cookie's shipped with the first batch of TM5. They maybe could do like Sony did with the PS3, new revisions did not allowed "jailbreaking" like the older revisions.
Bimby T. schrieb: > Joachim S. schrieb: >> Either way, I actually wonder if it doesn't make sense to simply develop >> an alternative main board for the Thermomix, instead of trying to hack >> the original one. > > The problem with that is that you would need to open up your Thermomix. Sure. And I agree that this is a major disadvantage of course. But if the only alternative were to not be able to "free" the Thermomix at all, then this might ultimately still be the best approach. > I was asking if someone know if it where possible to control the TM31 > over the diagnostic infrared port, so we did not need to open it up to > change the original one. I got that, it just wasn't 100% clear to me if your sentence was a question or a statement. > On the TM5 there is no infrared port, so the easiest alternative would > be hacking the cookie encryption, because they could not change that on > new firmware, or the TM5 would loose access to the older cookie's > shipped with the first batch of TM5. > They maybe could do like Sony did with the PS3, new revisions did not > allowed "jailbreaking" like the older revisions. I agree. But let's face it, we will probably never actually be able to completely crack the TM5 encryption system. There's a good chance we will at some point be able to... - decrypt the recipe chips - make the TM5 accept custom recipes, using security holes in the firmware - maybe even add some useful features to the TM5 But I just don't see us ever being able to create the kind of proper, valid recipe chips that cannot be blocked by firmware updates that you are hoping for. We know the patent that describes the TM5 security system for recipe chips, and it looks pretty solid to me on first sight. Unless we were able to somehow get access the private key that Vorwerk uses to digitally sign the recipe chips, we won't be able to create custom recipe chips with a valid digital signature. And the developers at Vorwerk would have to be extremely stupid if they had placed the private key used for signing in the firmware...
Joachim S. schrieb: > But I just don't see us ever being able to create the kind of proper, > valid recipe chips that cannot be blocked by firmware updates that you > are hoping for. We know the patent that describes the TM5 security > system for recipe chips, and it looks pretty solid to me on first sight. > Unless we were able to somehow get access the private key that Vorwerk > uses to digitally sign the recipe chips, we won't be able to create > custom recipe chips with a valid digital signature. And the developers > at Vorwerk would have to be extremely stupid if they had placed the > private key used for signing in the firmware... There are several possibilities regarding signatures. A mistake in the signature scheme may allow to easily extract the private key (remeber PS3). Another possibility is to change the public key, then you can use any key of your choice. From my point of view, the most impotant thing is to understand how data are stored in the recipe key (cookie).
Sigma P. schrieb: > There are several possibilities regarding signatures. > A mistake in the signature scheme may allow to easily extract the > private key (remeber PS3). True, if Vorwerk epically failed at properly implementing the encryption/signature algorithm, we might be able to extract the private key. That would be jackpot! But while I hope I'm wrong, I currently expect the chances of this happening to be rather low... :-( > Another possibility is to change the public key, then you can use any > key of your choice. You mean by changing the public key that is stored in the firmware, and that is used for verifying the digital signatures? If so, I would consider this a rather pointless approach. Because that would require altering/hacking the firmware, by means of some security hole (which could be fixed with a firmware update), right? And wouldn't simply changing the public key mean that original recipe chips would then be rejected? If the hack requires changing the firmware, shouldn't we be able to simply bypass the signature verification instead? > From my point of view, the most impotant thing is to understand how data > are stored in the recipe key (cookie). Have you read the patent documents that describe the security system of the recipe chips in this posting: Beitrag "Re: Thermomix Rezeptchips" ? They should be very helpful for this. I don't know if there is an english version of those documents available somewhere - so if you need any help translating/understanding those documents, we should be able to help.
Joachim S. schrieb: > That would be jackpot! But while I hope I'm wrong, I currently expect > the chances of this happening to be rather low... :-( I agree, chance is low. Joachim S. schrieb: > You mean by changing the public key that is stored in the firmware, and > that is used for verifying the digital signatures? > If so, I would consider this a rather pointless approach. Because that > would require altering/hacking the firmware, by means of some security > hole (which could be fixed with a firmware update), right? And wouldn't > simply changing the public key mean that original recipe chips would > then be rejected? > If the hack requires changing the firmware, shouldn't we be able to > simply bypass the signature verification instead? Your're right. I mean changing the public used for verifying the digital signatures. It depends on the case. Yes it can be fixed by Vorwerk, but then it becomes a game. New update = New exploit to find!!! Joachim S. schrieb: > Have you read the patent documents that describe the security system of > the recipe chips in this posting: > Beitrag "Re: Thermomix Rezeptchips" > ? > They should be very helpful for this. I don't know if there is an > english version of those documents available somewhere - so if you need > any help translating/understanding those documents, we should be able to > help. Yep, I read it. I don't know how to continue. What about GPL license ? If some interesting code is hidden in the kernel, they should publish it since it's a GPLv2 license.
In the Kobold manual (Vorwerk), they say that a Linux is used can be downloaded here: https://www.neatorobotics.com/lab/linux/ Neatorobotics seems to be the third party company that developped this product for Vorwerk. I'm sure we shoudld get Thermomix Kernel.
Does someone got a response from opensource@vorwerk.de for Kernel sources ?
Sigma P. schrieb: > What about GPL license ? > If some interesting code is hidden in the kernel, they should publish it > since it's a GPLv2 license. Apparently, if you contact Vorwerk, they will send you a CD with the source code of the GPL software. Some guy from this forum did so back in 2015: Beitrag "Re: Thermomix Rezeptchips" Unfortunately he did not publish the source code they sent him, but at least he posted a listing of the files on the CD, and it suggests that they indeed modified three packages: - linux kernel v2.6.35.3 - kobs-ng v10.12.01 - logrotate v3.8.3 > I don't know how to continue. You've got a TM5 and something like root access, allowing you to alter the TM5 filesystem, correct? Here's an idea - perhaps it won't help much, but it shouldn't be too much work, so I want to at least mention it: One could create a small proxy shell script that logs all calls to "interesting" commands. It would do about the following: 1. Capture the current timestamp + full command line it was called with (program name + all arguments) 2. Append that information to a special log file (for example /proxy/log.txt) 3. Call the actual command, passing all the arguments it was called with Store that shell script on the TM5 (for example named /proxy/proxy.sh) That shell script could then act as a kind of proxy to commands like mount, checksig etc. For example, to log calls to the command "/usr/sbin/checksig": 1. Copy the program /usr/sbin/checksig to /proxy/commands/checksig 2. Replace /usr/sbin/checksig with a symbolic link that points to the proxy shell script, /proxy/proxy.sh Then if some program on the TM5 calls "checksig", proxy.sh would first log timestamp + the command line that the program checksig was called with to /proxy/log.txt, then call /proxy/commands/checksig with just the arguments it was called with. That way, one could create a log of all interesting commands that are being called in chronological order, for example when attaching a recipe chip. What do you and the others think about this? EDIT: This is what the script /proxy/proxy.sh might look like:
1 | #!/bin/sh
|
2 | |
3 | # Path to the directory with all proxy-related files
|
4 | proxy_directory="/proxy" |
5 | |
6 | # Log timestamp + called command line to the log file
|
7 | echo "$(date +%s):" "$0" $@ >> "${proxy_directory}/log.txt" |
8 | |
9 | # Call the proxied command passing all arguments
|
10 | "${proxy_directory}/commands/$(basename $0)" $@ |
:
Bearbeitet durch User
Joachim S. schrieb: > Apparently, if you contact Vorwerk, they will send you a CD with the > source code of the GPL software. Some guy from this forum did so back in > 2015: > Beitrag "Re: Thermomix Rezeptchips" > Unfortunately he did not publish the source code they sent him, but at > least he posted a listing of the files on the CD, and it suggests that > they indeed modified three packages: > - linux kernel v2.6.35.3 > - kobs-ng v10.12.01 > - logrotate v3.8.3 So, it would interesting to get linux kernel modification in order to check if they do something specific with USB. Joachim S. schrieb: > You've got a TM5 and something like root access, allowing you to alter > the TM5 filesystem, correct? Sorry but I don't have root access. I just have the root file system that have been posted.
David N. schrieb: > So... es ist soweit.. ich habe mal den USB Protocol Analyzer zwischen > TM5 und Rezeptchip gehangen. > > Bisher habe ich noch nicht viel in den Daten herumgestöbert. Man sieht > nur einen IN und einen OUT Endpoint "Mass Storage Device". > > In den grossen Datenpaketen konnte ich keinen Klartext erkennen. Aber > wer weiss schon, in welchem Format die Daten vorliegen? > > Der Trace ist folgendermassen entstanden: > 1. recording starten > 2. chip anschliessen > 3. nach Erkennung -> Menü -> Rezepte > 4. "Das Kochbuch" > 5. "Nach Kategorie" > 6. "Vorspeisen und Salate" > 7. "Brokkoli Salat mit Pinienkernen" > 8. Starten (rechts oben) > 9. ca. 4 mal "weiter" > > Den Trace gibt es hier (14.5Mb): > https://mega.co.nz/#!2h0QTYZY!UAgvTRrAN7ne1SK7BF6wh8swa_cITtvP7KZvjrY7Qo4 > > Und die Software gibt es Gratis bei LeCroy: > http://teledynelecroy.com/support/softwaredownload/download.aspx?mseries=0&did=8337 > Hello Knochi, Do you have a dump of the cookie (a dump made with dd or somthinhg like that). I would like to compare data exchanged through USB and data dumped with dd in order to check dumping like that is correct.
Does somone already success to clone a cookie ? It's possible to share a cookie between two thermomix, right? So, it should be possible to clone a cookie. If I well understand (from what I saw and what is written on this thread), it's only a matter of VID, PID and serial number that is included in USB descriptor. I am right?
Fabian O. schrieb: > You are right. It is possible to clone a chip Please, can you share kernel patches from Vorwerk CD.
Sigma P. schrieb: > Fabian O. schrieb: >> You are right. It is possible to clone a chip > > Please, can you share kernel patches from Vorwerk CD. Send me a PM
Hallo zusammen, sehr interessante Diskussion hier, bei der ich mich jetzt auch beteiligen kann nachdem wir auch einen TM5 haben. Scheinbar haben die Vorwerk-Ingenieure ihren Job ganz gut gemacht, so dass z.Z eigentlich nur ein bisschen Qemu-RootFS-Spielereien (von Ikaro Psi) übrig bleiben, um mal zu schauen was so geht. Das habe ich mal versucht (*zum Nachahmen sollte man wissen was man tut*) 1. qemu installieren und Kernel/initrd, der oben erwähnt ist downloaden 2. squashfs unter linux mounten (auf /mnt/thermomix) 3. 128MB - Raw-Harddisk erstellt
1 | dd if=/dev/zero of=thermomix.raw bs=1024 count=128k |
4. mittels cfdisk thermomix.raw das Image partitioniert Ich hab da 2 Partitionen erstellt p1) 19MB für Squashfs (hab dann gemerkt das es sinnlos ist) p2) 50MB ext3 (hier ist dann das rootfs drin) 5. mit "kpartx -a thermomix.raw" das Image als loop-harddisk "registrieren" Danach kann p1 und p2 als /dev/mapper/loop0p1 und /dev/mapper/loop0p2 (oder loop1..) angesprochen werden 6. mkfs vom rootfs und mount
1 | mkfs.ext3 /dev/mapper/loop0p2 |
2 | mount /dev/mapper/loop0p2 /mnt/thermomixext3 |
7. rsync
1 | rsync -av /mnt/thermomix/ /mnt/thermomixext3/ |
Da ist mir aufgefallen, dass das squashfs GENAU bei der /bin/busybox einen io-Fehler hat und rsync nur diese Datei nicht kopiert.
1 | [ 2780.290452] SQUASHFS error: Unable to read data cache entry [135cd] |
2 | [ 2780.290456] SQUASHFS error: Unable to read page, block 135cd, size 14359 |
Die Datei ist für das Funktionieren des Images aber nötig. 8. Debian busybox-static nach /mnt/thermomixext3/bin/busybox kopieren und zwar die Version von https://packages.debian.org/wheezy/busybox-static die hat keine glibc-Abhängigkeiten, die sonst - bei falscher Version - das Booten verhindern 9. unmount/usw
1 | umount /mnt/thermomixext3 |
2 | kpartx -d thermomix.raw |
10. qemu starten
1 | qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile \ |
2 | -initrd initrd.img-2.6.32-5-versatile \ |
3 | -hda thermomix.qcow2 \ |
4 | -append "root=/dev/sda2" \ |
5 | -redir tcp:2200::22 |
Ergebnis siehe Bild. Das System bootet, aber bricht natürlich ab, da ich noch keine Anpassungen (bis auf busybox) gemacht habe. Es sollte aber kein Problem sein, einige Sachen zu simulieren (z.B. Data-Partition), in dem man die Skripte anpasst. Vg boecko
Hallo, einen Schritt am Schluss (vor 10) habe ich vergessen: 9b. Differenz-Image thermomix.qcow2
1 | qemu-img create -b thermomix.raw -f qcow2 thermomix.qcow2 |
- Das erzeugt das Differenz-Image thermomix.qcow2, das nur die Änderungen im laufenden Betrieb beinhaltet. - thermomix.raw bleibt dabei unangetastet - den Schritt muss man wahrscheinlich wiederholen, wenn man an thermomix.raw rumschraubt, da das FS sonst inkonsistent ist (evtl bei ro-mount nicht noetig) vg
:
Bearbeitet durch User
Hallo, kleines Update: nachdem ich ein weitere Partition in thermomix.raw angelegt habe und /etr/rc.d/rc.local auf
1 | mount -t ext3 /dev/sda3 /mnt/rwfs/data |
geändert habe, kommt man zumindest soweit wie im Bild /mnt/rwfs/data/tech_box/session_0/gui_0.log zeigt auch einige Einträge der GUI Einen guten Rutsch an alle boecko
Moin Boecko, Das sieht ja schon nicht schlecht aus. Auf den ersten Blick würde ich sagen, das er einen Bite Test an den Touchscreen macht, oder? Frohes Neues Jahr!
Hallo an alle, This thread is starting to get too long with pieces of information scattered everywhere. Maybe we should start a subreddit with a proper wiki. Something like /r/ps3homebrew (and its wiki at https://www.reddit.com/r/ps3homebrew/wiki). Maybe /r/ThermomixHomebrew?
Hi, Could someone share a dump of the data contained in the memory stick located on the wifi cook key board ? Has anyone managed to mount the recipe.img using the password in cookey.txt ? I've tried using losetup (with an older version that - like the one in the firmware - support "-e aes128"), with cryptsetup and aespipe... without luck. Thanks
I've played around with qemu, the TM5 rootfs that was provided here, and kernel/initrd from https://people.debian.org/~aurel32/qemu/armel/ I've also commented lines in /etc/rc.d/rc.local to enable telnet. Telnet listens to the sole available interface (loopback) which is useless when using the -redir option to have the host forward to the guest's telnet. So, an ethernet interface needs to be created. My understanding is that /boot must be on another partition (that we do not have access to) and there is no /lib/modules either. So to load the default NIC from qemu (don't try the e1000 as it segfaults), I have added mii.ko and smc91x.ko that I have extracted from the rootfs at above URL and put them in the data disk (the one mounted as sda3 and where TM5 logs are written). I have modified a boot script to load those modules with insmod and then run dhclient eth0). At that point, it is possible to telnet the guest (root, no password). The whole purpose of that was to have a proper shell and try understanding how the TM5 decrypts the recipe device/image before mounting it. We already known/assume that the password to decrypt the image is in /opt/cookey.txt. grep -ra cookey.txt on the whole rootfs returns only one file ( binary: /usr/sbin/netlink (as descrbed in previous posts) with this: losetup -e aes128 -P /opt/cookey.txt Someone here mentioned that these options do not really make any sense. Indeed, the image to decrypt is missing but also -e aes128 is no longer supported in recent versions of losetup. Well, the losetup found in the rootfs does not effectively not support the "-e aes128" option so I don't really see how the decryption process is happening. No really, related but I noticed the following kobs configuration file: root@tm41 ~$ cat .kobs # # The sample configuration file for kobs # chip_0_device_path=/dev/mtd0 search_exponent = 3 data_setup_time = 40 data_hold_time = 40 address_setup_time = 40 data_sample_time = 6 row_address_size = 3 column_address_size = 2 ncb_version = 3 ## not used anyway ##boot_stream_1_address = 0 ##boot_stream_2_address = 0x1500000 where /dev/mtd0 is usually referred too as a flash drive. Again, if the person who did open his wifi chip could share a copy of the content of the sd card connected to it, I'd be happy to see what can be done with it.
Schang S. schrieb: > > Again, if the person who did open his wifi chip could share a copy of > the content of the sd card connected to it, I'd be happy to see what can > be done with it. There at least two facebook groups[0][1] where they claim they dumped the image. In the first one there is a dead dropbox link. But maybe it is worth asking there. [0]: https://www.facebook.com/BIMBYTM5HACK/ [1]: https://www.facebook.com/tm5modding
Thanks. I have seen those groups but - unless I missed something - the dump they offer is from a recipe key while I am seeking from the wifi dongle. Have you seen them talking about that (because I've been through all published content several times and could not see anything like that) ?
You can see all specification of the cooki-key on fcc-id https://fccid.io/2AGELCK1 For the moment i just want dump a cook-key , how can i do ?
Thanks. The FCC assessment only cares about radio. To dump, after opening the cook-ket (which is what I would rather avoid doing), I'am assuming the putting the sd card in your pc should do the trick
Any idea how the recipe key is being encrypted ? Cryptsetup does not recognize the file: # cryptsetup luksDump recipes.img Device recipes.img is not a valid LUKS device.
Hallo, I had opened my cook-key (normal and not wifi). Impossible to read it on: - Windows 10 - virtual box Windows XP - virtual box Linux (Lubuntu) How can i do ? Have you tried this product ? FORNORM Magnetic Charging Cable USB 2.0 Male to 4 Pin Pogo Magnetic Charger Cable Cord For Smart Watch GT88 G3 KW18 Y3 KW88 GT68 http://s.aliexpress.com/veAbmUVZ?fromSns=Nouveau message
Hi, No sure what you are trying to achieve but you should not expect being able to open the key like any regular usb memory stick. Using e.g., Linux you should be able to create a copy using dd but then you'll end up (as discussed in previous posts) with an image of the key that is encrypted.
Hi guys, Under windows 10 i have made an image.dd renamed image.img of my chip with a nice tool. https://www.cgsecurity.org/wiki/TestDisk_DE Read this before but i used default at each time... https://korben.info/realiser-limage-dun-disque-dur-testdisk.html (sorry it's in french but google translation is your friend) Next step... Write this image.img on a stick ;)
Thierry G. schrieb: > Hi guys, > Under windows 10 i have made an image.dd renamed image.img of my chip > with a nice tool. > > https://www.cgsecurity.org/wiki/TestDisk_DE > > Read this before but i used default at each time... > https://korben.info/realiser-limage-dun-disque-dur-testdisk.html > (sorry it's in french but google translation is your friend) > > Next step... > Write this image.img on a stick ;) Hi Thierry, why don't you try with a simple tool called Win32 Disk Imager. It makes RAW images from the stick and can write it to another stick... ;) https://sourceforge.net/projects/win32diskimager/ Can you test compressing the resulting image (ZIP, 7Z or RAR)? Can you share the resulting file? It would be nice to compare two extracted images from two identical (same book but two different serial numbers) chips to see if there is any change. Probably only the serial number from the chip. If not, then the serial number of the chip is probably used for the partition encryption.
:
Bearbeitet durch User
Beitrag #5303176 wurde von einem Moderator gelöscht.
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
Hallo Forum, wäre es nicht möglich einen FTP Server zu starten ? Damit hätte man die Möglichkeit eigene Rezepte auf den TM zu schieben. Haltet ihr das für möglich ? Gruß firstfacility
Sicher, das sehe ich ein, aber als interessierter mit wenig Englisch Kenntnisse ist es halt schwer.
Bimby T. schrieb: > why don't you try with a simple tool called Win32 Disk Imager. It makes > RAW images from the stick and can write it to another stick... ;) Hi Bimby T. Win32DiskImager don't work it can't see the false CD drive. > Can you test compressing the resulting image ? Can you > share the resulting file? It would be nice to compare two extracted > images from two identical it's a great idea !
@last posts: Please read the COMPLETE thread! I know, its long, but: imaging and cloneing already works. We found already the tools and settings, because the drive serialnumber is very importend.
Fabian O. schrieb: > @last posts: > > Please read the COMPLETE thread! I know, its long, but: imaging and > cloneing already works. We found already the tools and settings, because > the drive serialnumber is very importend. Hi Fabian, Sorry, I overlooked the post (Beitrag "Re: Thermomix Rezeptchips"). But we do not want to clone a chip, just make a chip with our own recipes...
:
Bearbeitet durch User
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
Markus H. schrieb: > Currently a bunch of > fundamentals are still missing, which should be definitely solved before > setting up any FTP servers, tools or whatever. I'd guess: If anyone here is capable or able or whatever to gain access to the device and is able to break the encryption - what's the way he'd go? Sharing his knowledge within a minor forum or sell the knowledge and thus the security issue to Vorwerk? Such a comprehensive hack would be worth a whole load of money! I'd offer it for at least 5 Million Euro. I bet Vorwerk will pay!
Martin S. schrieb: > Markus H. schrieb: >> Currently a bunch of >> fundamentals are still missing, which should be definitely solved before >> setting up any FTP servers, tools or whatever. > > I'd guess: If anyone here is capable or able or whatever to gain access > to the device and is able to break the encryption - what's the way he'd > go? Sharing his knowledge within a minor forum or sell the knowledge and > thus the security issue to Vorwerk? > > Such a comprehensive hack would be worth a whole load of money! I'd > offer it for at least 5 Million Euro. I bet Vorwerk will pay! I think one possible guy wo would crack it would be Ikaro Psi (ikaro_p). It was the only one that had root access to the TM5 system... :)
Bimby T. schrieb: > Martin S. schrieb: >> Markus H. schrieb: >>> Currently a bunch of >>> fundamentals are still missing, which should be definitely solved before >>> setting up any FTP servers, tools or whatever. >> >> I'd guess: If anyone here is capable or able or whatever to gain access >> to the device and is able to break the encryption - what's the way he'd >> go? Sharing his knowledge within a minor forum or sell the knowledge and >> thus the security issue to Vorwerk? >> >> Such a comprehensive hack would be worth a whole load of money! I'd >> offer it for at least 5 Million Euro. I bet Vorwerk will pay! > > I think one possible guy wo would crack it would be Ikaro Psi (ikaro_p). > It was the only one that had root access to the TM5 system... :) You don't know if he did. He was able to obtain the rootfs of the thermomix (excluding the /boot partition where the kernel and initrd, if any, is located) but that may also have been done through the update mechanism. I have been provided with the content of the cook-key by a member of this forum - that he did not want to disclose publicly as it may contain identifiers such as a serial number that could link him to the leakage - and was able to play a bit with the content. So, this could alo be a way of figuring out how the upgrade process is happening and potentially to fet a firmware upgrade. I haven't shared the output of what I was able to see so far so here it is in a quick dirty way: fdisk -l thermomix-cookkey-drive-d Disk thermomix-cookkey-drive-d: 7.5 GiB, 8053063680 bytes, 15728640 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x84d46198 Device Boot Start End Sectors Size Id Type thermomix-cookkey-drive-d1 2048 526335 524288 256M 83 Linux thermomix-cookkey-drive-d2 526336 7854079 7327744 3.5G 83 Linux #boot sector from 1 to 2048. d1 is from 2048 to dd if=thermomix-cookkey-drive-d of=d1 skip=2048 bs=512 count=524288 status=progress 524288+0 records in 524288+0 records out 268435456 bytes (268 MB, 256 MiB) copied, 0.853545 s, 314 MB/s file d1 d1: Linux rev 1.0 ext4 filesystem data, UUID=4f0f6d2e-504f-41dd-8a06-8fc85eacdf66, volume name "usbdrive1" (extents) (large files) (huge files) #dump second partition dd if=thermomix-cookkey-drive-d of=d2 skip=526336 bs=512 count=7327744 status=progress 3652907520 bytes (3.7 GB, 3.4 GiB) copied, 9 s, 406 MB/s 7327744+0 records in 7327744+0 records out 3751804928 bytes (3.8 GB, 3.5 GiB) copied, 12.6379 s, 297 MB/s file d2 d2: Linux rev 1.0 ext4 filesystem data, UUID=37c9eec0-8e8f-4ea2-977e-e8d0c5b18b93, volume name "usbdrive2" (needs journal recovery) (extents) (large files) (huge files) dd if=thermomix-cookkey-drive-d of=d3 skip=7854079 bs=512 status=progress 3727178752 bytes (3.7 GB, 3.5 GiB) copied, 9 s, 414 MB/s 7874561+0 records in 7874561+0 records out 4031775232 bytes (4.0 GB, 3.8 GiB) copied, 9.71618 s, 415 MB/s file d3 d3: data mkdir /tmp/d1 mkdir /tmp/d2 sudo mount -t ext4 d1 /tmp/d1 ls /tmp/d1 cs.tar sudo mount -t ext4 d2 /tmp/d2 ls /tmp/d2 15272373012203516.ell ext.sdb ext.sdb-wal material settings_cloud.sdb tm5.img #make copy of the content from the mounted volumes to leave these volumes untouched mkdir /tmp/extract cd /tmp/extract cp -r /tmp/d1 /tmp/d2 . cd d1 tar xf cs.tar ls cs.tar ext.sdb material settings_cloud.sdb tm5.img ls material/ binary photo cd material/binary/ ls 47857.bin 47874.bin 47891.bin 47907.bin 47923.bin[....] ls |wc -l 206 ls -l |head total 824 -rw------- 1 besnard besnard 1488 Jun 9 2016 47857.bin -rw------- 1 besnard besnard 1712 Jun 9 2016 47858.bin -rw------- 1 besnard besnard 736 Jun 9 2016 47859.bin -rw------- 1 besnard besnard 976 Jun 9 2016 47860.bin -rw------- 1 besnard besnard 896 Jun 9 2016 47861.bin -rw------- 1 besnard besnard 1408 Jun 9 2016 47862.bin -rw------- 1 besnard besnard 1536 Jun 9 2016 47863.bin -rw------- 1 besnard besnard 1984 Jun 9 2016 47864.bin -rw------- 1 besnard besnard 2224 Jun 9 2016 47865.bin hexdump -C 47857.bin|head ; echo;hexdump -C 47858.bin|head 00000000 b7 31 5f 40 9c 57 42 89 c5 db 8e 5b 79 a2 f4 7f |.1_@.WB....[y...| 00000010 0f 97 ba 54 3b a3 18 39 2b eb a8 99 0e 5f 60 52 |...T;..9+...._`R| 00000020 b8 80 1b 78 99 46 0d 2d bf 1d 0a b5 a9 70 d0 95 |...x.F.-.....p..| 00000030 7c 4e 37 9a b5 15 30 3c 4d 70 9a 87 cf 02 34 07 ||N7...0<Mp....4.| 00000040 aa 6c 73 11 52 b5 63 bb 2e 14 2b 0a eb 07 2a d0 |.ls.R.c...+...*.| 00000050 f0 e5 e6 ce 42 b3 f0 58 e5 2a b8 5d 07 75 93 8a |....B..X.*.].u..| 00000060 76 da ce 51 a0 33 82 3a c5 66 15 60 c1 02 02 61 |v..Q.3.:.f.`...a| 00000070 d5 57 05 f6 73 b1 87 dd 48 1a bd 31 e1 68 dc 23 |.W..s...H..1.h.#| 00000080 25 b6 36 bc af ed ff 9b 67 94 79 9d 0a ee 98 a1 |%.6.....g.y.....| 00000090 b2 81 07 8f 6f 20 55 87 2d 6d 43 3c 10 75 28 6b |....o U.-mC<.u(k| 00000000 27 8c d3 bc c3 2e 7e 95 f3 e2 d4 40 37 0f 91 82 |'.....~....@7...| 00000010 59 ea de 65 26 e2 f7 df ce b0 b7 1d db 23 0a cf |Y..e&........#..| 00000020 24 41 94 ef cb 59 72 50 3d 0d e4 38 cb 08 30 ed |$A...YrP=..8..0.| 00000030 09 bf 2a cc 44 91 09 b3 18 d0 58 fe 67 a8 16 ac |..*.D.....X.g...| 00000040 1d 09 ec d5 39 63 21 b3 30 c4 25 4c 33 60 56 fc |....9c!.0.%L3`V.| 00000050 f2 82 93 69 3b 0e 9e 76 ea 03 f3 a6 b5 b9 e9 da |...i;..v........| 00000060 46 55 a9 6d 32 84 3f d8 b9 3b f4 64 08 3f 1d 68 |FU.m2.?..;.d.?.h| 00000070 c7 b8 24 14 b5 48 89 71 cf 5e 0d a7 4c d0 88 46 |..$..H.q.^..L..F| 00000080 3a bb da 9a 67 09 39 1b fb f2 fa 12 e8 bb bf 66 |:...g.9........f| 00000090 1a b0 46 1b 58 4c f8 eb 41 4d 48 98 11 04 41 68 |..F.XL..AMH...Ah| ---> I tried to bindiff the various files but there is nothing in common so no way of determining the structure (e.g., headers, etc.) of the file. the image directory contains the pics of the recipes so it's rather useless. cd /tmp/extract/d1 sqlite3 ext.sdb SQLite version 3.11.0 2016-02-15 17:29:24 Enter ".help" for usage hints. sqlite> .tables categoryBin collectionBin material recipeBin categoryBinMap collectionBinMap materialSignature recipeNote categoryLang dataExt metadata recipeSignature sqlite> .dump categoryBin PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE categoryBin ( categoryId UNSIGNED BIGINT NOT NULL PRIMARY KEY, typeId INTEGER NOT NULL, materialId UNSIGNED BIGINT DEFAULT 0 NOT NULL ); INSERT INTO "categoryBin" VALUES(2,1,118); INSERT INTO "categoryBin" VALUES(6,1,111); INSERT INTO "categoryBin" VALUES(12,1,102); INSERT INTO "categoryBin" VALUES(5,1,109); INSERT INTO "categoryBin" VALUES(8,1,116); INSERT INTO "categoryBin" VALUES(11,1,107); INSERT INTO "categoryBin" VALUES(13,1,103); INSERT INTO "categoryBin" VALUES(14,1,105); INSERT INTO "categoryBin" VALUES(4,1,110); INSERT INTO "categoryBin" VALUES(9,1,114); INSERT INTO "categoryBin" VALUES(16,1,104); INSERT INTO "categoryBin" VALUES(15,1,108); INSERT INTO "categoryBin" VALUES(1,1,119); INSERT INTO "categoryBin" VALUES(266,1,115); INSERT INTO "categoryBin" VALUES(17,1,101); COMMIT; sqlite> .dump collectionBin PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE collectionBin ( collectionId UNSIGNED BIGINT NOT NULL PRIMARY KEY, title VARCHAR NOT NULL, sortKey VARCHAR NOT NULL, materialId UNSIGNED BIGINT REFERENCES material ON DELETE NO ACTION ON UPDATE NO ACTION, nofRecipesPlanned INTEGER NOT NULL, localeId INTEGER NOT NULL, typeId INTEGER NOT NULL, hash VARCHAR NOT NULL); INSERT INTO "collectionBin" VALUES(1,'Das Kochbuch','-''K;C+5)O+5▒▒▒ ',888,206,2,5,'1a06cc2bbc54b3REDACTEDREDACVTED'); sqlite> .dump material PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE material ( materialId UNSIGNED BIGINT NOT NULL PRIMARY KEY, fullName VARCHAR NOT NULL, hash VARCHAR NOT NULL); INSERT INTO "material" VALUES(100510,'./material/photo/150x150/mdb-72456-47857-1.jpg','2dd3a107 7dadc6274e2ade20828c5012F'); INSERT INTO "material" VALUES(100610,'./material/photo/150x150/mdb-72473-47858-0.jpg','d40a868a 32999aac8ea9c4643a53a16dF'); INSERT INTO "material" VALUES(100710,'./material/photo/150x150/mdb-72889-47859-0.jpg','6cb97314 0cf27883e63dddcaab6d9a2fF'); INSERT INTO "material" VALUES(100810,'./material/photo/150x150/mdb-72794-47860-0.jpg','51fad5f5 216cc62444e90a1ab460246cF'); INSERT INTO "material" VALUES(100910,'./material/photo/150x150/mdb-72763-47861-0.jpg','8465c2d4 9c899ef282ed21e4ab6d141cF'); INSERT INTO "material" VALUES(101010,'./material/photo/150x150/mdb-72569-47862-0.jpg','42aa494a 08fc037fb046b66446d789a2F'); [...] sqlite> .dump recipeBin PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE recipeBin ( recipeId UNSIGNED BIGINT NOT NULL PRIMARY KEY REFERENCES recipeNote ON DELETE CASCADE ON UPDATE NO ACTION, title VARCHAR NOT NULL, sortKey VARCHAR NOT NULL, version DECIMAL(8.2) NOT NULL, localeId INTEGER NOT NULL, materialId UNSIGNED BIGINT REFERENCES material ON DELETE NO ACTION ON UPDATE NO ACTION, hash VARCHAR NOT NULL); INSERT INTO "recipeBin" VALUES(47857,'Crêpes','+I/E/K▒▒▒ ',1,2,100510,'230e331008ae48541608101a23197cffF|1'); INSERT INTO "recipeBin" VALUES(47858,'Nudelteig, frisch','AO-/=M/731I7K+5▒',1,2,100610,'230e331008ae48541608101a23197cffF |1'); ',1,2,100710,'230e331008ae48541608101a23197cffF|1');'')''3=7CA/▒ INSERT INTO "recipeBin" VALUES(47860,'Tomatensauce','MC?''M/AK''O+/▒',1,2,100810,'230e331008ae48 541608101a23197cffF|1'); INSERT INTO "recipeBin" VALUES(47861,'Basilikumpesto',')''K7=7;O?E/KMC▒',1,2,100910,'230e331008a e48541608101a23197cffF|1'); ',1,2,101010,'230e331008ae48541608101a23197cffF|1');7A/KMICA/▒ ▒NSERT INTO "recipeBin" VALUES(47863,'Reissalat','I/7KK''=''M ',1,2,101110,'230e331008ae48541608101a23197cffF|1'); INSERT INTO "recipeBin" VALUES(47864,'Nudelsalat mit Forelle und Gemüse','AO-/=K''=''M?7M1CI/==/OA-3/?OK/h▒▒x▒{▒ [...] sqlite> .dump categoryBinMap PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE categoryBinMap ( categoryId UNSIGNED BIGINT NOT NULL REFERENCES categoryBin ON DELETE CASCADE ON UPDATE CASCADE, recipeId UNSIGNED BIGINT NOT NULL REFERENCES recipeBin ON DELETE CASCADE ON UPDATE CASCADE, PRIMARY KEY (categoryId, recipeId) ); INSERT INTO "categoryBinMap" VALUES(16,47857); INSERT INTO "categoryBinMap" VALUES(16,47858); INSERT INTO "categoryBinMap" VALUES(11,47859); INSERT INTO "categoryBinMap" VALUES(9,47860); INSERT INTO "categoryBinMap" VALUES(9,47861); INSERT INTO "categoryBinMap" VALUES(2,47862); [...] .dump collectionBinMap PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE collectionBinMap ( collectionId UNSIGNED BIGINT NOT NULL REFERENCES collectionBin ON DELETE CASCADE ON UPDATE CASCADE, recipeId UNSIGNED BIGINT NOT NULL, PRIMARY KEY (collectionId, recipeId) ); INSERT INTO "collectionBinMap" VALUES(1,47857); INSERT INTO "collectionBinMap" VALUES(1,47858); INSERT INTO "collectionBinMap" VALUES(1,47859); [...] .dump materialSignature PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE materialSignature ( materialId UNSIGNED BIGINT NOT NULL REFERENCES material ON DELETE CASCADE ON UPDATE NO ACTION, typeId INTEGER NOT NULL, signature VARCHAR NOT NULL, PRIMARY KEY (materialId, typeId) ); INSERT INTO "materialSignature" VALUES(100510,101,'71a594493ea7f5ee383bbfbaa873d3331591f34cf3c95c7c77527 ea7ed87220759a501e96837a0c34c52c2c45509135ce9a1bd71da8556daf391a715bb2cf e43bbc965a117d0220eec70ca37a1183963e58bf7dad2e3c088462ef4973ca2fefd542bc 899d13ee5f64fc14a9c88642ece76a72068179e7bad8f0992cc234e380eaa87df3b6b509 16dbe0286cf0a5e71249e0f4893b090701f8a796de54b2a16eef067613c6760d711404ca d49971eed6514bc3fc109f9dead035f7497c1ce4961843a3e2106ccefc6886567ea3e1b9 06f5feb9497449249182d7e19855d595c83595ffba4f3719a7af9254be032930cd946e19 bdc42c2c250f48d42223a87a547'); INSERT INTO "materialSignature" VALUES(100610,101,'3dbda21a11b7b5cac81014ad8fbf129ed90530ba1834d9ce6f17f fa79e7344ed8fb28343f411c55c223b053cdd1bc71415be8aa1fcc977ff1172c86d1aa90 6af590f37ed04e131927b3aecc62ef54efee7cc22fc0ad9ec39f3e51dde6d7957dca85f8 914d40cf1b1912cfdd6ed513e21472363371f6a08b31f9b6d03792f0a1817f3ea52df742 3f6e26c6aa6647d37668eaaa2d59783a5a3d5c904ef60496338f68ac4ce7e63f1832737b 3bb4499d2eb33247f8bd87f075b2ae37c2bb63b7c1fe289543f33dd8dfbfb0425a3238c3 c5d563d8c4f0c4a92a08666f1891f7a198c3db6ea07624af41ea42e0fb9bee47c18f7e71 e1d39eb2913d54ef650de7eb8b8'); [...] .dump recipeNote PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE recipeNote ( recipeId UNSIGNED BIGINT NOT NULL PRIMARY KEY, noteText VARCHAR NOT NULL, hash VARCHAR NOT NULL ); COMMIT; .dump categoryLang PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE categoryLang ( categoryId UNSIGNED BIGINT NOT NULL REFERENCES categoryBin ON DELETE CASCADE ON UPDATE CASCADE, localeId INTEGER NOT NULL, title VARCHAR NOT NULL, sortKey VARCHAR NOT NULL, PRIMARY KEY (categoryId, localeId) ); INSERT INTO "categoryLang" VALUES(2,1,'Soups','KCOEK '); INSERT INTO "categoryLang" VALUES(2,2,'Suppen','KOEE/A ▒ '); INSERT INTO "categoryLang" VALUES(2,3,'Soupes','KCOE/K ▒ '); INSERT INTO "categoryLang" VALUES(2,4,'Sopas','KCE''K '); INSERT INTO "categoryLang" VALUES(2,5,'Zuppe, passati e minestre','YOEE/E''KK''M7/?7A/KMI/▒'); INSERT INTO "categoryLang" VALUES(2,6,'Sopas','KCE''K '); INSERT INTO "categoryLang" VALUES(2,7,'Zupy','YOE▒'); [...] .dump dataExt PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE dataExt ( dataExtType_id INTEGER NOT NULL PRIMARY KEY, value VARCHAR NOT NULL ); INSERT INTO "dataExt" VALUES(1,'2.0.2'); INSERT INTO "dataExt" VALUES(2,'2016-06-09 15:03:58'); INSERT INTO "dataExt" VALUES(3,'0'); COMMIT; .dump metadata PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE metadata ( typeId UNSIGNED BIGINT NOT NULL PRIMARY KEY, value VARCHAR); INSERT INTO "metadata" VALUES(1,NULL); INSERT INTO "metadata" VALUES(4,NULL); INSERT INTO "metadata" VALUES(5,NULL); INSERT INTO "metadata" VALUES(6,NULL); INSERT INTO "metadata" VALUES(7,NULL); INSERT INTO "metadata" VALUES(10,NULL); INSERT INTO "metadata" VALUES(3,'6'); INSERT INTO "metadata" VALUES(2,'2'); INSERT INTO "metadata" VALUES(8,'3'); COMMIT; .dump recipeSignature PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE recipeSignature ( recipeId UNSIGNED BIGINT NOT NULL REFERENCES recipeBin ON DELETE CASCADE ON UPDATE CASCADE, typeId INTEGER NOT NULL, signature VARCHAR NOT NULL, PRIMARY KEY (recipeId, typeId) ); INSERT INTO "recipeSignature" VALUES(47857,101,'6af76679f19201dbb287016da4ef78aff06218b7430f40bdbe8afb e794804ec119d2289f6285393ca57dff8d99327507fa6f17d47b403be6d68a5694f3f3f2 944137b31d2f02132af03e3be18bb6ac45eebfb0afd17d36c9b28fde1d61b687d83576c0 7e1e2d3581da553bd5f712f1ecc07ad81ea687d457b1640042122fc68ea58d5128d21045 99b1a269b4019df14c2ab1db0adf403c639fe933a24b81f638b705bd202342be476abad6 e6413698d2f064347b6b4b391e0a469e28e31c99da545efeac36dae1304644953eda2ce7 3cfeb499f9f900b8bd99340dfc799c4b0fd54f1c3f67a3cd39e15aa925659c752b2804ce 83c6a6a8f739b3579a5a53c573'); [...] sqlite3 settings_cloud.sdb SQLite version 3.11.0 2016-02-15 17:29:24 Enter ".help" for usage hints. sqlite> .tables dataCloud settingsCloudApp vendorMapping dataCloudType settingsCloudAppDebug .dump dataCloud PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE dataCloud ( dataCloudType_id INTEGER NOT NULL PRIMARY KEY REFERENCES dataCloudType ON DELETE CASCADE ON UPDATE RESTRICT, value VARCHAR NOT NULL ); INSERT INTO "dataCloud" VALUES(1,'1.0.2'); INSERT INTO "dataCloud" VALUES(2,'2014-10-24 11:32:44'); COMMIT; .dump dataCloudType PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE dataCloudType ( id INTEGER NOT NULL PRIMARY KEY, type VARCHAR NOT NULL ); INSERT INTO "dataCloudType" VALUES(1,'cloudSettingsDbVersion'); INSERT INTO "dataCloudType" VALUES(2,'cloudSettingsDbDate'); sqlite> .dump settingsCloudApp PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE "settingsCloudApp" ("id" INTEGER PRIMARY KEY NOT NULL ,"remoteAddress" CLOB NOT NULL ,"TCPPort" INTEGER NOT NULL ,"remotePath" CLOB NOT NULL ,"pingAddress" CLOB NOT NULL ); INSERT INTO "settingsCloudApp" VALUES(1,'css.tmecosys.com',443,'/ws','l.root-servers.net'); sqlite> .dump settingsCloudAppDebug PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE "settingsCloudAppDebug" ("id" INTEGER PRIMARY KEY NOT NULL ,"mac" STRING NOT NULL ,"ssn" STRING NOT NULL ); INSERT INTO "settingsCloudAppDebug" VALUES(1,'AABBCCDDEEFF','0123456789ABCDEF'); COMMIT; sqlite> .dump vendorMapping PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE "vendorMapping" ("id" INTEGER PRIMARY KEY NOT NULL ,"vendor_id" VARCHAR NOT NULL ,"vendor_char" VARCHAR NOT NULL ); INSERT INTO "vendorMapping" VALUES(1,'001343','A'); COMMIT; The tm5.img can not be mounted (using e.g., losetup in aes128 mode with the password in the cookey.txt file). Cryptsetup does not recognize it as a LUKS volume: cryptsetup luksDump tm5.img Device tm5.img is not a valid LUKS device. so that's it for partition 1. Moving to partition 2: cd ../d2 ls 15272373012203516.ell ext.sdb ext.sdb-wal material settings_cloud.sdb tm5.img the only new item is 15272373012203516.ell which seems purely random (according to strings/hexdump output and analysis with binwalk). The one thing that bothers me is that we seem to know where updates are being downloaded from but Ican't figure a way to build the exact URL to attempt retrieving e.g., the latest firmware.
I've inspected the main executable /opt/Thermomix/Thermomix a bit and found the class KeyStoreDevice which seems to handle loading encryption keys from /dev/ks via an ioctl. Do we have access to the kernel source code?
Hi, We don't have access to the kernel as we are missing the /boot volume in the dump that was provided.
Beitrag #5329902 wurde vom Autor gelöscht.
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.
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.
Update on cooksticks encryption: I managed to get GUI running in an emulator with a debugging mode enabled so I can actually see what is the netlink trying to do when cookstick is inserted. NETLINK-INFO: 0h8m13s348ms: virtual void KernelListener::processEvent(size_t) adding event NL_ADD_STORAGE_PARTITION [FSM] NETLINK-DEBUG: 0h8m13s349ms: [EVT-R] NL_ADD_STORAGE_PARTITION : [/devices/pci0000:00/0000:00:0c.0/usb1/1-2/1-2:1.0/host1/target1:0:0/1:0 :0:0/block/sr1, sr1] NETLINK-DEBUG: 0h8m13s349ms: MAIN LOOP: started processing event: NL_ADD_STORAGE_PARTITION [/devices/pci0000:00/0000:00:0c.0/usb1/1-2/1-2:1.0/host1/target1:0:0/1:0 :0:0/block/sr1, sr1] NETLINK-DEBUG: 0h8m13s349ms: virtual void GenericDeviceHandlingState::handleAddDevice(KernelEvent::DeviceType, std::string, std::string) NETLINK-DEBUG: 0h8m13s350ms: int ExecuteSystemCommand(std::string&) : rm -f /tmp/dev/sr1 NETLINK-DEBUG: 0h8m13s450ms: int ExecuteSystemCommand(std::string&) : mkdir -p /tmp/dev/ NETLINK-DEBUG: 0h8m13s469ms: int ExecuteSystemCommand(std::string&) : mknod -m 644 /tmp/dev/loop1 b 7 1 NETLINK-DEBUG: 0h8m13s481ms: int ExecuteSystemCommand(std::string&) : mknod -m 644 /tmp/dev/sr1 b 11 1 NETLINK-DEBUG: 0h8m13s496ms: int ExecuteSystemCommand(std::string&) : mkdir -p /tmp/sr1 NETLINK-DEBUG: 0h8m13s516ms: int ExecuteSystemCommand(std::string&) : losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 NETLINK-ERROR: 0h8m13s937ms: System command losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 returned 1 NETLINK-DEBUG: 0h8m13s938ms: int ExecuteSystemCommand(std::string&) : mount -o ro /tmp/dev/loop1 /tmp/sr1 NETLINK-ERROR: 0h8m14s93ms: System command mount -o ro /tmp/dev/loop1 /tmp/sr1 returned 255 NETLINK-INFO: 0h8m14s126ms: Storage partition found at /tmp/sr1/ (S/N: REDACTED ) NETLINK-ERROR: 0h8m14s127ms: No valid cookstick recognized But as you can see this fails: $ losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length (128 bits) not supported by kernel Running losetup through strace shows us the culprit: [pid 30043] ioctl(4, LOOP_GET_STATUS64, {lo_offset=0, lo_number=1, lo_flags=LO_FLAGS_READ_ONLY, lo_file_name="", ...}) = 0 [pid 30043] ioctl(4, LOOP_SET_STATUS64, {lo_offset=0, lo_number=0, lo_encrypt_type=0x10 /* LO_CRYPT_??? */, lo_encrypt_key_size=16, lo_flags=0, lo_file_name="/dev/sr1", lo_crypt_name="", lo_encrypt_key="#7\245\221f\271N,\373\360\317]S\273\276X", ...}) = -1 EINVAL (Invalid argument) [pid 30043] ioctl(4, LOOP_SET_STATUS, {lo_number=0, lo_offset=0, lo_encrypt_type=0x10 /* LO_CRYPT_??? */, lo_encrypt_key_size=16, lo_flags=0, lo_name="/dev/sr1", lo_encrypt_key="#7\245\221f\271N,\373\360\317]S\273\276X", ...}) = -1 EINVAL (Invalid argument) [pid 30043] ioctl(4, LOOP_GET_STATUS64, {lo_offset=0, lo_number=1, lo_flags=LO_FLAGS_READ_ONLY, lo_file_name="", ...}) = 0 [pid 30043] ioctl(4, LOOP_SET_STATUS64, {lo_offset=0, lo_number=0, lo_encrypt_type=LO_CRYPT_CRYPTOAPI, lo_encrypt_key_size=16, lo_flags=0, lo_file_name="/dev/sr1", lo_crypt_name="aes-cbc", lo_encrypt_key="#7\245\221f\271N,\373\360\317]S\273\276X", ...}) = -1 EINVAL (Invalid argument) [pid 30043] ioctl(4, LOOP_SET_STATUS, {lo_number=0, lo_offset=0, lo_encrypt_type=LO_CRYPT_CRYPTOAPI, lo_encrypt_key_size=16, lo_flags=0, lo_name="aes-cbc", lo_encrypt_key="#7\245\221f\271N,\373\360\317]S\273\276X", ...}) = -1 EINVAL (Invalid argument) [pid 30043] openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30043] openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30043] openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30043] openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 30043] write(2, "ioctl: LOOP_SET_STATUS: Invalid "..., 108ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length (128 bits) not supported by kernel The losetup binary is IFAIK not a vanilla one as it is trying to use lo_encrypt_type=0x10 which is nowhere to be found on the internet. This means we won't be able to decrypt cooksticks anywhere besides the machine until we (I mean... until I :D) manage to extract the kernel and revers-engineer the handler. Or maybe someone else here might get lucky with the passed lo_encrypt_key="#7\245\221f\271N,\373\360\317]S\273\276X" now? I must once more commend Vorwerk for their job, as I've said before I do security for living and as of now have never seen anything remotely good as this. Well played Vorwerk, well played. P.S. Comming soon might be a guide on running the GUI in an emulator, for now it's not usable as the emulated touchscreen driver is sending coordinated in 0-32768 range but the GUI needs them in screen pixels. Clicking blindly in the left upper corner is just pain in the ass...
Ikaro P. schrieb: > Update on cooksticks encryption: > > I managed to get GUI running in an emulator with a debugging mode > enabled so I can actually see what is the netlink trying to do when > cookstick is inserted. Ikaro, you are doing a great work, you are the men! I would be happy if I would have a little percentage of your knowledge... :) If you could publish a guide for setting up the GUI on a emulator where we can then attach an image from the cooksticks (or the real ones) to test them out would be awesome... Regarding the "losetup" binary, if it was changed by Vorwerk with some custom encryption type, then there should be the source code for this, as it should be open source, right? Should be ask for it at opensource@vorwerk.de? Thanks for all your current and future work on this! :)
:
Bearbeitet durch User
Good so see more activity here :-) Ikaro P. schrieb: > Getting kernel out is going to be bit harder as it seems to be stored as > a raw bootstream on the first flash chip. There are some hints on using > OTP keys for security, but they seems to be set to 0s for now. My root > access is still "tethered" but I might be getting closer to a perma-root > soon. Indeed, I also suspect them to be stored in the OTP bits of the MX28. What I can see from the code is that the driver must support at least 2 ioctls. Both take an index (0..9) and one returns the length of the key and the other copies the key into a buffer to which you pass a pointer. I also inspected the 'checkimg' executable and although it contains a lot of crypto functions statically linked in, it neither contains a single ioctl nor does it reference any external library. I'm sure that the firmware update key is statically linked into that executable. > [ 0.800000] key_store: driver loaded That's the driver that handles the OTP crypto keys. To my surprise your kernel doesn't list the device under /proc/devices lateron explicitly. But it has major ID 10 (see /dev folder of your root filesystem) which is misc officially anyway and that is listed.
Ikaro P. schrieb: > I managed to get GUI running in an emulator with a debugging mode > enabled so I can actually see what is the netlink trying to do when > cookstick is inserted. Is it possible to share that emulator setup?
Ikaro P, how can you help you. I'm lost in such deep linux world. I don't how to continue on my side.
Ikaro, are you able to access the contents of the /mnt/rwfs ? Any chance of sharing the uboot and kernel to boot the squashfs on qemu ? Best regards,
moin mädels, wie damals angekündigt habe ich an einem html/js editor gebastelt. wollte ja eigentlich auf die endgültige struktur der datenbank warten bevor ich da weiter mache, aber ich habe hier so viele von "meinen" rezepten auf zetteln rumfliegen... Sobald wir alle nötigen Daten haben um einen Export auf den Chip realisieren zu können (und der Editor dafür in Betracht kommt) steht einem gitProjekt nix im Wege. Ist alles unter GPL also kann jeder damit machen was er will. Ich denke es ist immer leichter etwas zu verändern als von 0 zu starten also ab mit dem Teil in den upload... hi girls, i have uploaded a basic html/js editor for recipes that is waiting for more details about "the chip" to be usefull. its very easy to implement another language so i hope that it could be used some day as our default editor to fill "the chip". https://uploadfiles.io/euabu
Warum braucht Ihr den Chip zu hacken? Man kann doch die URL Adresse von Cookidoe Server abhören und durch DNS auf eigenen Server umleiten. Der Server wird dann die ganze Rezepte bereitstellen. So ähnlich wurden die Apple TV Boxen gehackt.
Gennadij D. schrieb: > Warum braucht Ihr den Chip zu hacken? > Man kann doch die URL Adresse von Cookidoe Server abhören und durch DNS > auf eigenen Server umleiten. Der Server wird dann die ganze Rezepte > bereitstellen. > So ähnlich wurden die Apple TV Boxen gehackt. Eben nicht! Das ist alles SSL Verschlüsselt, da kannst nix mithören ;(
@Gennadij Degterjow: Interessante Idee. Michael W. schrieb: > Das ist alles SSL Verschlüsselt, da kannst nix mithören ;( Auf welche Domain wird denn zugegriffen? Wird das Zertifikat ausreichend auf Korrektheit geprüft? Reicht ein selbstsigniertes Zertifikat?
Big thanks for your work, Ikaro P, we would not have any chance with that if we did not have you.(https://media3.giphy.com/media/3oEdva9BUHPIs2SkGk/giphy.gif) It seems like everyone else except you is stuck and because nobody seems to read the whole thread here, I think we should move to a subreddit with wiki to display all information orderly, like someone mentioned before. I will do that if I find any old reddit account of mine, I can not start a new subreddit with a just created account. Ikaro P. schrieb: > Sadly this is not possible for two reasons now: > - the process of registration of the TM to the online system is probably > the way the per device client certificate is issued and I think that one > is used most of the time. > - TM strictly enforces the verification of the server certificate. > Public CA system is not used and the only certificates accepted must > stem from Vorwerk's internal CA. Did you ever notice that the per device certificate is used ? I dont got a TM5 by now, but there is a private cert key in your fw dump in /tmp/certificates/. Did someone ever really tried to fake the cookidoo website the TM5 is communicating with, or sniff some of the communication ? This will be the first thing I will try when I got the TM5, as we could load our own recipes this way without any hardware modification. If the per device cert is really such important, could you register your TM to the online system and dump the fw again so we could look for the per device cert ? Can anyone who sniffed the encrypted traffic share the capture here so I could try to decrypt the parts where the cert is used for that we already got the private key? One other interesting thing would be to try to encrypt the offline recipes chip with the AES key found by you. I do not have any chip or the hardware to connect to it, but as I read here, some people allready got a working clone of the offline chip, and the problem with changing data on the chip is the verification with chip serial + AES key. We got that key now thanks to you. We should be able to change data on the stick now and that could also be a way to get our own recipes on the TM5. Ikaro P. schrieb: > P.S. Comming soon might be a guide on running the GUI in an emulator, How did you emulate the touch screen ? I did not get further than "C530. Touch device not working.". Thanks again for your great work, if there is anything you cannot say here please contact me at haschhans@emailn.de.
:
Bearbeitet durch User
Hans H. schrieb: > Did you ever notice that the per device certificate is used ? I dont got > a TM5 by now, but there is a private cert key in your fw dump in > /tmp/certificates/. Did someone ever really tried to fake the cookidoo > website the TM5 is communicating with, or sniff some of the > communication ? I sniffed the communication some time ago when the Cookidoo chip entered the market, and yes, they use client cert authentication aggressively. I don't have the capture at hand, but AFAIR the key only communicates with a single HTTPS endpoint that expects the client cert. The only exception would be a first unencrypted request to synchronize the device's time (think NTP over HTTP).
Thomas H. schrieb: > Hans H. schrieb: >> Did you ever notice that the per device certificate is used ? I dont got >> a TM5 by now, but there is a private cert key in your fw dump in >> /tmp/certificates/. Did someone ever really tried to fake the cookidoo >> website the TM5 is communicating with, or sniff some of the >> communication ? > > I sniffed the communication some time ago when the Cookidoo chip entered > the market, and yes, they use client cert authentication aggressively. I > don't have the capture at hand, but AFAIR the key only communicates with > a single HTTPS endpoint that expects the client cert. The only exception > would be a first unencrypted request to synchronize the device's time > (think NTP over HTTP). Can you maybe do the sniff again if you don't have the capture ? I don't have the Cookidoo by now.
Ikaro P. schrieb: > NETLINK-DEBUG: 0h8m13s516ms: int ExecuteSystemCommand(std::string&) : > losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 > NETLINK-ERROR: 0h8m13s937ms: System command losetup -e aes128 -P > /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 returned 1 > > But as you can see this fails: > $ losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 > ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length > (128 bits) not supported by kernel > > The losetup binary is IFAIK not a vanilla one as it is trying to use > lo_encrypt_type=0x10 which is nowhere to be found on the internet. Hi Ikaro P.! I have found the source code for losetup that uses this encryption type: https://sourceforge.net/projects/loop-aes/ If we look at the samples (http://loop-aes.sourceforge.net/ciphers.README) we can see the following command: losetup -p 0 -e AES128 /dev/loop0 /dev/hda666 This command is similar to the command used by the Thermomix: losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 Is it right? :) I am not a programmer, but I think this is the needed part that will help complete the decryption method of the cookstick. > P.S. Comming soon might be a guide on running the GUI in an emulator, > for now it's not usable as the emulated touchscreen driver is sending > coordinated in 0-32768 range but the GUI needs them in screen pixels. > Clicking blindly in the left upper corner is just pain in the ass... Can you please release the guide for running the Thermomix GUI even if the touchscreen driver is not fixed? Please? :) Thanks! Would be nice to see some update from you soon... Let's keep this project alive guys! :)
:
Bearbeitet durch User
This losetup option (notably -e aes128) correspond to an old version of losetup. The losetup binary inside the Thermomix does not have those options (which you'll be able to appreciate if you run it in qemu. I've also tried putting the old version that had those options inside the qemu image and that did not help deciphering the data).
Schang S. schrieb: > This losetup option (notably -e aes128) correspond to an old version of > losetup. The losetup binary inside the Thermomix does not have those > options (which you'll be able to appreciate if you run it in qemu. I've > also tried putting the old version that had those options inside the > qemu image and that did not help deciphering the data). Hi Schang S., you need to apply this package (https://sourceforge.net/projects/loop-aes/) and compile the losetup binary with it (on the project page we can see: "Works with 4.x, 3.x, 2.6, 2.4, 2.2 and 2.0 kernels", so the old losetup binary you talked about does not use the same encryption methods). The losetup you see on the QEMU is NOT the kernel of the Thermomix, but a generic linux kernel for the Freescale processor. Like Ikaro P. wrote, nobody until now got access to the real Thermomix kernel. I can assure you that the "loop-aes" is used on the Thermomix kernel and anyone that already asked Vorwerk for the Thermomix kernel source code can confirm this... :) I am not a programmer so I can not test it myself. Did you managed to have a working GUI like Ikaro P.? Can you share how you set it up? Thanks!
:
Bearbeitet durch User
Indeed, what I'm saying is that the losetup stuff with -aes128 give a wrong direction. I did effectively try with the old versions of losetup that supported these option and that did not help.
Schang S. schrieb: > Indeed, what I'm saying is that the losetup stuff with -aes128 give a > wrong direction. I did effectively try with the old versions of losetup > that supported these option and that did not help. Did the old losetup implement the "loop-aes" methods? Having the same syntax does not mean that the methods are the same... ;) As you can see on the work of Ikaro P., the closed source tool from Vorwerk NETLINK shows what it tries to do and fail on losetup because the encryption method is unknown (because the losetup on the generic kernel does not have it, and the old losetup does not implement the same encryption methods): NETLINK-DEBUG: 0h8m13s516ms: int ExecuteSystemCommand(std::string&): losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 NETLINK-ERROR: 0h8m13s937ms: System command losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 returned 1 Like I have said, on the kernel source code from Vorwerk, they have two folders, one with unmodified source, and one with modified source. On the modified source is the losetup source code and on the readme file is written that it needs the loop-aes package... ;)
I perfectly understood all that. Did you request and obtain the source code ? (given your comment I would assume you did). If so, would you care sharing it ? and if we have the code of the kernel (that would contain any proprietary encryption routines they could have developed) then what are we missing to successfully decrypt ?
Schang S. schrieb: > I perfectly understood all that. > Did you request and obtain the source code ? (given your comment I would > assume you did). If so, would you care sharing it ? Yes, I have requested the source code. I do not know if I can share it, because I had to give all my personal data and Thermomix serial number to receive a CD with the source code at home (so maybe the source code is signaled with my data). If you have a Thermomix you could ask for the source code too, you just need to write them an email at opensource@vorwerk.de, tell them your address and Thermomix serial number. The source code should be about ~300MB... > and if we have the > code of the kernel (that would contain any proprietary encryption > routines they could have developed) then what are we missing to > successfully decrypt ? The problem here is that I am not a programmer. I just asked the source code to look around and possibly help the community with the research. This part of the losetup is on the kernel utilities "modified" source code...
:
Bearbeitet durch User
I just sent an e-mail with my serial number. How long did it take to receive the CD ? I'm not sure that they would go through the trouble of watermarking the code. Especially since according to GPL they are supposed to provide modified open source code to anyone (regardless of the fact that you own a TM5 or not).
Schang S. schrieb: > I'm not sure that they would go through the trouble of watermarking the > code. We could simply test it: if two people have the sourcecode, just generate the SHA256 Hashsum and compare them. If the reults are equal, it is safe that there is no watermark ;)
Schang S. schrieb: > I just sent an e-mail with my serial number. How long did it take to > receive the CD ? Nowadays they give you access to an fileserver to download the sources. In my case it took 3 month to finally download the sources. But maybe they are faster now ;)
You get an personalized account from Vorwerk and somebody will put the sources there later.
Julian W. schrieb: > We could simply test it: if two people have the sourcecode, just > generate the SHA256 Hashsum and compare them. If the reults are equal, > it is safe that there is no watermark ;) I would be in. I does anybody have the version 2.3 of the sources to compare?
Schang S. schrieb: > I just sent an e-mail with my serial number. How long did it take to > receive the CD ? > > I'm not sure that they would go through the trouble of watermarking the > code. Especially since according to GPL they are supposed to provide > modified open source code to anyone (regardless of the fact that you own > a TM5 or not). I have got it some weeks later I think (do not know now, I have got it sometime ago). I also asked for a download link, but Vorwerk told me back then that they do not provide download links of the source code. They only send it as a physical medium (CD-Rom). Maybe they use this method to have a record of personal data (address and serial number) from persons that asked for the source code...
Moritz M. schrieb: > Julian W. schrieb: > >> We could simply test it: if two people have the sourcecode, just >> generate the SHA256 Hashsum and compare them. If the reults are equal, >> it is safe that there is no watermark ;) > > I would be in. > > I does anybody have the version 2.3 of the sources to compare? There you go: File: Thermomix_TM5_GPL_v2.3.tgz CRC-32: b1e3209b MD4: aa57ab0c2913b5744941b0241a5fbfa2 MD5: c42146a26bcd7f7f84327957a07a3c49 SHA-1: 599a257f88e38801ede4e7e1ec37bcc66d43f573 Used HashCheck (https://github.com/gurnec/HashCheck) for that... ;)
:
Bearbeitet durch User
Bimby T. schrieb: > Moritz M. schrieb: >> Julian W. schrieb: >> >>> We could simply test it: if two people have the sourcecode, just >>> generate the SHA256 Hashsum and compare them. If the reults are equal, >>> it is safe that there is no watermark ;) >> >> I would be in. >> >> I does anybody have the version 2.3 of the sources to compare? > > There you go: > > File: Thermomix_TM5_GPL_v2.3.tgz > CRC-32: b1e3209b > MD4: aa57ab0c2913b5744941b0241a5fbfa2 > MD5: c42146a26bcd7f7f84327957a07a3c49 > SHA-1: 599a257f88e38801ede4e7e1ec37bcc66d43f573 > > ;) Nope, seems to be different:
1 | ╰─$ sha1sum tm5_2.3.tgz |
2 | 797380a69303a49e0267f0ec453395fc55b4c849 tm5_2.3.tgz |
3 | ╰─$ md5sum tm5_2.3.tgz |
4 | 5d15bf2ec5c23e839073e335f90d437d tm5_2.3.tgz |
So what about the files itself:
1 | ╰─$ find ./ -type f -exec md5sum {} \; |
2 | 85a7b3eac41c85f2aa0922cf2aa48105 ./unmodified_packages/GPL_LGPL_licensed_packages/sourceware.org.git.glibc.git.tar.gz |
3 | 586a39938330516b1089ce2eadaf4749 ./unmodified_packages/GPL_LGPL_licensed_packages/git.yoctoproject.org.opkg-utils.tar.gz |
4 | a51bcfeb3da7dd4c623e27207ed43467 ./unmodified_packages/GPL_LGPL_licensed_packages/gcc-5.2.0.tar.bz2 |
5 | 5682890cb0267f6671dd3de6eabd3e69 ./unmodified_packages/GPL_LGPL_licensed_packages/freetype-2.6.tar.bz2 |
6 | 275ca403fa8533cc57bc3c4f86e04505 ./unmodified_packages/GPL_LGPL_licensed_packages/github.com.philb.update-rc.d.git.tar.gz |
7 | 8507960b09433c5ea568e43d84624153 ./modified_packages/GPL_LGPL_licensed_packages/mtd-utils-1.5.1/infradead.org.mtd-utils.tar.gz |
8 | a3a53320bf575147da958655866febf7 ./modified_packages/GPL_LGPL_licensed_packages/mtd-utils-1.5.1/mtd-utils_%.bbappend |
9 | 9a647bdaeffd8b4c0b0f05e847e86dfb ./modified_packages/GPL_LGPL_licensed_packages/libm2m-1.0/libm2m.tar.gz |
10 | 19d2fce401d1dd67425eebdcf8e051f5 ./modified_packages/GPL_LGPL_licensed_packages/libm2m-1.0/libm2m_svn.bb |
11 | 25f3dbf8019713d02b4b8461f0006509 ./modified_packages/GPL_LGPL_licensed_packages/libwebsockets-1.5/libwebsockets_1.5.bb |
12 | 2b48aa76f35354fc65160ec116bdd36d ./modified_packages/GPL_LGPL_licensed_packages/libwebsockets-1.5/libwebsockets-1.5-chrome47-firefox41.tar.gz |
13 | 6317671467ce1b10ffbf7415b960bb14 ./modified_packages/GPL_LGPL_licensed_packages/libwebsockets-1.5/files/websockets.patch |
14 | bc5f5711eac66e8e65ec19828bec79c6 ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/util-linux_%.bbappend |
15 | 9bdf368c395f1b70325d0eb22c7f48fb ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/util-linux-2.26.2.tar.xz |
16 | 9ece1f2589a037f84610e197a72323bf ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/files/util-linux-2.26-20150310.diff |
17 | d9a665645ccdefa1455203cd37548ff1 ./modified_packages/GPL_LGPL_licensed_packages/util-linux-2.26.2/files/readme.md |
18 | df67c8bda9139131d919931da443794d ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/logrotate-3.8.3.tar.gz |
19 | e84b47335ea240f98f9acf972238671f ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/logrotate_3.8.3.bb |
20 | d04640731915ada48dc77fdca6077f9c ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/files/act-as-mv-when-rotate.patch |
21 | 2659dd5e88e2f01fb13a748efca60494 ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/files/s-flag.patch |
22 | e526950acfca08b16489ec549bf8bcb4 ./modified_packages/GPL_LGPL_licensed_packages/logrotate-3.8.3/files/disable-check-different-filesystems.patch |
23 | 7925683d7dd105aabe9b6b618d48cc73 ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/busybox-1.23.2.tar.bz2 |
24 | 4932d5f889fcf5ea0efb115d58f3945b ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/busybox_%.bbappend |
25 | eeeb3725cd7a599246113f102ecc8c96 ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/nslookup_timeout.patch |
26 | d4ec40ae5c20a5dd6954bd8c0e27ca3a ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/defconfig |
27 | a9c592a93e6500f6b7219957b52b2dbb ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/udhcpc-script |
28 | bfdc6b8805ffbdc383b424e669c24608 ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/rename_dhcp.patch |
29 | 6211b045eda898ba5be6bee3f8c68b2e ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/defconfig-debug |
30 | b32b9fac3d29e3216706cfabec9540dd ./modified_packages/GPL_LGPL_licensed_packages/busybox_1.23.2/files/dhclient |
31 | 127132c24e9ebfc6d579250f56d0afc7 ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/linux_vorwerk.tar.gz |
32 | 3a50affe643811614bfeadeeff0e5d17 ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/linux-vorwerk_2.6.35.bb |
33 | d2c3bdf62571f54d5e66eb5dea841ed5 ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/exec_tid_core_pattern_linux2.6.35.patch |
34 | 2950a66c8283f29491229bb4f898b68a ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig_netfilter |
35 | b0f29654b309d7422f07ceaf7efea91d ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/fix_inotify_gcc5.patch |
36 | 82cf88cc9d06ed082fae739d51d742cd ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/ubi_upd_flash_after_prep_for_update.patch |
37 | 75974192ebc65ccd2c28b1e418918089 ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig |
38 | 9a51bedd04525147f58199c8f0de0a0f ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/freebox.patch |
39 | 279ce6049324bd466123a27b3e466dd4 ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/add_gcc5_header.patch |
40 | 075a555047d06a39c709a830a770281b ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/fix_uninitialized_macro_req.patch |
41 | c35c49916b027beb409a56344e1524b6 ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/dcp.c |
42 | 2faadc1b6d1700268ab0aa2432669cc9 ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig-rdv |
43 | cba19c44122d9e4f25e8459583d9e80a ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/ptrace_coredump_linux2.6.35.patch |
44 | 19f84f7c3e36ff653abeaa04d37fafb5 ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/perl_deprecated_defined.patch |
45 | 75974192ebc65ccd2c28b1e418918089 ./modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/defconfig-std |
46 | 1e8ab2cf8392d2303ac151e7b870446d ./modified_packages/GPL_LGPL_licensed_packages/e2fsprogs-1.42.9/e2fsprogs_%.bbappend |
47 | 3f8e41e63b432ba114b33f58674563f7 ./modified_packages/GPL_LGPL_licensed_packages/e2fsprogs-1.42.9/e2fsprogs-1.42.9.tar.gz |
48 | 4eb6fe21874e841e809d5e552f6b93d8 ./modified_packages/GPL_LGPL_licensed_packages/e2fsprogs-1.42.9/files/symlinks.patch |
49 | b740702d4bc38a70ce1d3f9b87ea5e80 ./modified_packages/GPL_LGPL_licensed_packages/wireless_tools.30.pre9/wireless-tools_%.bbappend |
50 | ca91ba7c7eff9bfff6926b1a34a4697d ./modified_packages/GPL_LGPL_licensed_packages/wireless_tools.30.pre9/wireless_tools.30.pre9.tar.gz |
51 | 88d5447da306e56ff6e627ad9c6c6d63 ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/imx-bootlets-vorwerk_10.12.01.bb |
52 | f112ea757cbaeb32c96adf7924103daa ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/cst_tools.tar.gz |
53 | d2aa76e57da2a2cdb79b829703cd09a4 ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/otp_tools.tar.gz |
54 | a59f177e95453ea7e6d49267eb5b6904 ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/imx-bootlets-src-10.12.01.tar.gz |
55 | a3229f9645f400a22e214d7e76218f48 ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/files/makefile.patch |
56 | 2e3d6bf0e34fb2d0714f2da9ed19eb91 ./modified_packages/GPL_LGPL_licensed_packages/kobsng-10.12.01/kobsng_10.12.01.bb |
57 | 2c0f4fd363e587eb965317e59f552cb8 ./modified_packages/GPL_LGPL_licensed_packages/kobsng-10.12.01/kobsng.tar.gz |
58 | 536d048c8e8eeebcd9757d0863ebb0c0 ./modified_packages/GPL_LGPL_licensed_packages/iptables-1.4.21/iptables-1.4.21.tar.bz2 |
59 | ee07b484eb407486b6bb7d9b7810e872 ./modified_packages/GPL_LGPL_licensed_packages/iptables-1.4.21/iptables_%.bbappend |
Bimby has provided me with his source code and I am getting the exact same checksums when running on each individual files. So, definitely no watermark there :)
Moritz M. schrieb: > > So what about the files itself: > Well, I have checked and the MD5 checksum from the files that I have got from Vorwerk are all equal, BUT, on my tar file it is missing the following folder: <code> ./modified_packages/GPL_LGPL_licensed_packages/imx-bootlets_10.12.01/ </code> So it seems that the source code is not "signed" with any personal data. Can you share the source code (because yours is more complete) on a online sharing host like mega.co.nz or similar (where it does no expire and do not have download limits)... @Schang S.: Can you share how you setup the QEMU with a working GUI? Thanks!
Since Vorkwerk is ignoring my request... would be really great if someone could share the code. Thanks!
Schang S. schrieb: > Bimby has provided me with his source code and I am getting the exact > same checksums when running on each individual files. So, definitely no > watermark there :) With Bimby you mean me or Vorwerk? I did not share any source code to you...
And as for running qemu. My folder with all my files is a big mess and I'm not sure of all the history of changes I made so let me know if that works for you: Grab kernel image and initrd here: https://people.debian.org/~aurel32/qemu/armel/ If you wish to mount the disk image in order to make changes sudo kpartx -a thermomix.raw && sudo mount /dev/mapper/loop0p2 thermomixext3/ And then to unmount it sudo umount thermomixext3 && sudo kpartx -d thermomix.raw You then need to convert the image to qcow2 format (to be done each time you modify the raw image that can be mounted as described just before) qemu-img create -b thermomix.raw -f qcow2 thermomix.qcow2 And then run qemu qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda thermomix.qcow2 -append "root=/dev/sda2" You'll get the GUI screen at some point (with the error message). To get your shell just hit enter which will mke the GUI image disappear. I believe that this setup did not fully work in the first place and I had to make a few modifications to the disk image but I have not documented anything at that time ... Good luck !
Schang S. schrieb: > And as for running qemu. My folder with all my files is a big mess and > I'm not sure of all the history of changes I made so let me know if that > works for you: > Thanks, so you did not have the GUI working without errors like Ikaro P., or am I wrong? Regarding the source code you got from Vorwerk, did you got a public link or you need to authenticate with username and password?
No I did not get it to work but I am not too concerned by that as I would prefer being able to decrypt the cook stick and then determine if recipes can be changed. As for the source code, Moritz kindly sent me a link earlier today :)
Schang S. schrieb: > No I did not get it to work but I am not too concerned by that as I > would prefer being able to decrypt the cook stick and then determine if > recipes can be changed. > > As for the source code, Moritz kindly sent me a link earlier today :) Ok, so if you find something now with the kernel source code, please share... :)
The source code helped figure out what is being done with losetup (they applied a patch that is publicly available). So I've been able to use it with the key provided in cookey.txt but the loop device can not be mounted and does not look like a file system that can be mounted so I'm a bit stuck right now.
So, the TM5 is using a modified version of losetup which is basically util-linux-2.26.2 with patch util-linux-2.26-20150310.diff I've downloaded that version on computer, applied the patch and compiled. From there, I had to to modprobe cryptoloop otherwise you'll get the following error: ioctl: LOOP_SET_STATUS: Invalid argument, requested cipher or key length (128 bits) not supported by kernel So, I'm assuming that Ikario's initrd image did not contain that module. Again, I've been doing these tests from my computer (not the VM in qemu) so this was easy to fix. Then, I could run losetup -e aes128 -P /tmp/cookey.txt /dev/loop0 recipes.img which brings a loopback device at /dev/loop0 that is waiting to be mounted. sudo ./losetup -a /dev/loop0: [fc00]:177473618 (recipes.img) encryption=CryptoAPI/aes-cbc Interesting to see here that when running the original losetup of my computer (so not the patched version), it says type=18, which is not 0x10 or 16). sudo losetup -a /dev/loop0: [64512]:177473618 (/home/[REDACTED]/thermomix/recipes.img), encryption aes-cbc (type 18) The problem here is that the loopback device does not look like a file system. The mount command does not want to mount it. And in fact, when you check with binwalk, it does not identify anything but random data: sudo binwalk /dev/loop0 DECIMAL HEXADECIMAL DESCRIPTION ------------------------------------------------------------------------ -------- <nothing> As I also have access to a dump of the cook key, I've also tried to run losetup on it and had the same behavior. What is sort of annoying here is that losetup will not tell you that your password is right or wrong, it will just use it as a key. Anf if the key is wrong, then the deciphered data are just junk. I was thinking that maybe the cook stick content has not been extracted correctly but I doubt it because at least for the cook key (wifi) I have 2 partitions that were just fine so no reason for the third partition (encrypted on) to not have been extracted correctly. As for the encryption key/password found in cookey.txt, I trust Ikario did not make that one up :) So, for short, I'm stuck again. I've had a quick look at modified open source code but there does not seem to by anything related to encryption (aside from the linux utils patch that was already publicly known).
Again, could anybody please share the source code? (PM also welcome). Would really like to take part in this ;)
Matthias L. schrieb: > Again, could anybody please share the source code? (PM also welcome). > Would really like to take part in this ;) Now that we know that the source code is not "signed" with personal data, I could share the source code, but my source code is missing a folder, so I would suggest that Schang S. oder Moritz M. share the complete source code...
As Moritz provided me with the source I can not decide on his behalf to share it, even though it is GPL and I don't even understood why Vorwerk is not simply releasing it to the public without requiring people to ask for it (BTW I did request the code 2 or 3 days ago and never got a reply). After making no progress using the patched version of losetup, I started looking at the modified/added source code corresponding to the linux kernel. From what I understand, Vorwerk is using a module called DCP to handle encryption (not sure encryption of what exactly). This does not seem to be something they developed as traces of it can be found on the Internet but this module seems to have been discarded from official kernel at some point (or was never included in it). There is another module called Vorwerk key-store that has a submodule referred to as cloud key or something. There is bitbake (.bb) file that provides all changes made to vanilla 2.6.35 linux source code. After applying all those changes, I was able to run the kernel compilation which failed because some Vorwerk header files (.h) are missing from the source code. The .bb file also explains that when compiled with gcc5, the kernel won't boot for unknown reasons so they recommend compiling with gcc4.4. After excluding the Vorwerk key-store module (the one that is missing headers and made the compilation fail) I was able to have the linux image compiled (including the DCP part which could be the one handling decryption of AES loop). Using that kernel image in qemu failed (no surprise because Vorwerk documented that it would not work when compiled with gcc5 and I did not have a gcc4.4 at hand). Another interesting point - but maybe concerning too - I found in the .bb file is that they have a series of sed commands to inject (that's what comments say in the .bb) hard-coded AES128 keys inside the code of the DPC driver. If that's the case, then things will get more complicated because the keys have not been released in the 300MB archive of course. I'll try to install and old debian with kernel 2.6 and old gcc to compile the kernel in the same conditions as Vorwerk. The one thing that I find strange is why would they have hard-coded keys and still be sing the cookey.txt file with losetup. Also, I am wondering if the recipes.img that was share here has been extracted properly. I can't recall who extracted the image but I'd like to know what tools have been used and how they were used (dd ?).
@ikaro hope you read this: As I checked the certs of your dump today, I noticed that there are some certs and two root certs listed in /tmp/certificates, but there is only one valid private key for one cert that expired in 2017. If this private key got any use, there must be a new valid cert & private key in the last Firmware Updates. We could decrypt the traffic if we got the new cert.
:
Bearbeitet durch User
Hi all, finally there is a GitLab repository which hosts all the v2.3 GPL/LGPL source code: https://gitlab.com/therm0m1x/tm5-sources I somebody wants to contribute just fork the project and afterwards create a merge request. As there is also a wiki included I plan to sum up all the knowledge collected so far. Any help doing this is highly appreciated. Cheers.
I forgot to mention somebody already published the sources already on github: https://github.com/scharri/vorwerk-tm5-oss-sources If somebody could ask Vorwerk (opensource@vorwerk.de) for the recent sources (should be 2.4 now) and contribute these sources. That would be nice.
If you are interested in breaking the cookido comnunication you can contact me. We wont publish anything until everything works perfect.
Hans H. schrieb: > If you are interested in breaking the cookido comnunication you can > contact me. We wont publish anything until everything works perfect. Hi Hans, can you please share some info about this privately? Thanks! :)
[Auf Deutsch unten] I've read all your posts with great interest. I've repaired a lot of devices before, but this device is a fortress! Everything is secured and protected with cryptography and 2048-bit signatures. 1. CN601 may be a serial port, however nothing is output to it (checked with oscilloscope). Probably it was used during board bring-up only. The footprint fits 4-pin JST connector BM04B-SRSS-TB. The pinout is 1:GND 2:OUT 3:IN 4:3.3V. 2. Attaching a USB keyboard/mouse does nothing (no drivers?). 3. If you attach a USB Ethernet dongle with AX88772/72A/72B chipset, the device enters service mode and you can connect to it at 192.168.76.1. Unfortunately, the service protocol requires authentication with 2048 bit RSA before executing any commands. So it is very hard to get in this way. 4. I did get into the device in the end. As Ikaro_P says, the developers are only human. 5. Here is a copy of the Linux kernel from the device. I believe I am entitled to share this under GPL (section 3c). https://mega.nz/#!PqhyTIiY!70HDBcwl6Lb-DhgPQ6xk0LIvXCcl4vxZY5F_C6egb-E 6. As others have found, the encryption key for the recipe chip is not the one posted earlier, they have done something devious. (I will not share the real key on the Internet to avoid wrath from Vorwerk.) 7. Having the encryption key is not enough to create your own recipe chip. All files on the recipe chip are signed with 2048 bit RSA signatures. 8. Fortunately, despite all the layers of paranoia, there is a bug/feature in the implementation of recipe chip verification that makes DIY recipe chips possible without having to break the RSA key. I will not say any more for now. Happy hacking :) --- [Entschuldigung für Fehler in meinem Deutsch.] Ich habe alles Ihrer Posts mit großem Interesse gelesen. Ich habe viele andere Geräte repariert, aber dieses Maschine is eine Festung! Alles ist gesichert und geschützt mit Kryptographie und 2048-Bit-Signaturen. 1. CN601 ist möglicherweise eine serielle Schnittstelle, aber es wird nichts ausgegeben. Wahrscheinlich wurde es nur während des Entwicklung verwendet. Der Fußabdruck passt für 4-poligen JST-Stecker BM04B-SRSS-TB. Die Pinbelegung ist 1:GND 2:OUT 3:IN 4:3,3V. 2. Das Anschließen einer USB-Tastatur/Maus führt zu nichts (keine Treiber?). 3. Wenn Sie einen USB-Ethernet-Dongle mit AX88772/72A/72B-Chipsatz anschließen, das Gerät wechselt in den Service-Modus und Sie können eine Verbindung zu 192.168.76.1 herstellen. Bedauerlicherweise, das Serviceprotokoll erfordert das Authentifizierung mit 2048 Bit RSA. Es ist also sehr schwer, auf diese Weise zu kommen. 4. Letztendlich bin ich in das Gerät eingebrochen. Wie Ikaro_P sagt, sind die Entwickler nur menschlich. 5. Hier ist eine Kopie des Linux-Kernels vom Gerät. Ich glaube, ich bin berechtigt, dies unter der GPL zu teilen (Abschnitt 3c). https://mega.nz/#!PqhyTIiY!70HDBcwl6Lb-DhgPQ6xk0LIvXCcl4vxZY5F_C6egb-E 6. Wie andere gefunden haben, ist der Schlüssel für die Rezeptsticks nicht der, der zuvor hier veröffentlicht wurde. (Ich werde den echten Schlüssel nicht im Internet teilen.) 7. Der Schlüssel reicht nicht aus, um eigene Rezeptchips zu erstellen. Alle Dateien auf den Rezeptchips sind mit 2048 Bit RSA-Signaturen gesichert. 8. Zum Glück, trotz all den Schichten der Paranoia, gibt es ein Fehler in der Implementierung der Rezeptstick-prüfung. Deswegen ist es möglich, die eigene Rezeptsticks erstellen. Ich werde vorerst nichts mehr sagen. Happy hacking :)
Hi, Great work ! The kernel image that you have posted does not seem to load in qemu. Running 'file' on the image returns "data". Were you able to successfully run it in qemu ?
Hi Schang, I have not tried it in qemu. The file I shared before is the uncompressed kernel (loaded in memory at address 0xc0008000). Here is the zImage format version which might work better: https://mega.nz/#!z7xRUQgB!DYFHi3t1uAPBvGyTe-jZ4dp9gM7zakHOx76q631dNtw Matt
Hi Matt C, sehr sehr gute Arbeit! Kannst du uns verraten wie du es geschafft hast, einen eigenen Rezeptchip zu generieren? Ich denke die ganze Community wartet schon voller Spannung auf diese Infos :) ---------------------------------------------------------------- very very great work! Could you please share some more information on how to generate custom cooking book sticks? I guess the entire community is waiting full of expectation on this Information :) Viele Grüße Johannes
Share your achivements with us Matt C, please. I have been testing your kernel file, but it's too complex for me. Thank you very much for your time and dedication.
Hello everybody, Winter is comming, I will have time to look at TM5 again. Great job everybody! This is my understanding. Can you tell me if I taking the good way? 1. We have access to the last source code: https://gitlab.com/therm0m1x/tm5-sources 2. When a cook stick is inserted, we know that netlink call the following command: losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 4. Schang S tried to compile losetup with Vorkerk patch (util-linux-2.26-20150310.diff that is a public patch) but the resulting loopback device is not mountable: Schang S. schrieb: > The problem here is that the loopback device does not look like a file > system. The mount command does not want to mount it. And in fact, when > you check with binwalk, it does not identify anything but random data: > sudo binwalk /dev/loop0 According to Matt C., encryption key is not correct (they have done something devious): Matt C. schrieb: > 6. As others have found, the encryption key for the recipe chip is not > the one posted earlier, they have done something devious. (I will not > share the real key on the Internet to avoid wrath from Vorwerk.) So, according to my understanding, there are 3 possibilities: 1. losetup command is not correct: losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 2. cookey.txt doesn't contain the good key: The given key is not correct (EiOJeNLiooqwWobaVDVrbJWLCifvQC5oDqNqHfuSYBt3y4vwN3YKq2EsvFK3U4M9) Or the file is preprocessed first and key is deviated from this one 3. The real kernel make something with the key that is not present in the patch util-linux-2.26-20150310.diff Can you tell me if my understanding is good ?
Hi Sigma P., See the dcp_aes_setkey_blk function in https://github.com/scharri/vorwerk-tm5-oss-sources/blob/master/modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/dcp.c for a clue. Matt
So the actual key is in the driver itself and set if the compare key is used...?!
Matt C. schrieb: > See the dcp_aes_setkey_blk function in > https://github.com/scharri/vorwerk-tm5-oss-sources/blob/master/modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/dcp.c > for a clue. Thanks for the clue matt. I will look into this. Sigma P. schrieb: > According to Matt C., encryption key is not correct (they have done > something devious): > > Matt C. schrieb: >> 6. As others have found, the encryption key for the recipe chip is not >> the one posted earlier, they have done something devious. (I will not >> share the real key on the Internet to avoid wrath from Vorwerk.) > > > So, according to my understanding, there are 3 possibilities: > 1. losetup command is not correct: > losetup -e aes128 -P /opt/cookey.txt /tmp/dev/loop1 /tmp/dev/sr1 > > 2. cookey.txt doesn't contain the good key: > The given key is not correct > (EiOJeNLiooqwWobaVDVrbJWLCifvQC5oDqNqHfuSYBt3y4vwN3YKq2EsvFK3U4M9) > Or the file is preprocessed first and key is deviated from this one > > 3. The real kernel make something with the key that is not present in > the patch util-linux-2.26-20150310.diff > > Can you tell me if my understanding is good ? Even if the dcp_aes_setkey_blk function does something devious with the key, it is important that everyone looks in the patents again! As seen in my screenshot(search for "patent" in this page for the full patent), the key to decrypt the data partition of the recipe chip depends on the hardware serial of the recipe stick and some key of a keyring that is referred in the first partition of the recipe stick. Because Vorwerk registered a patent for this actions, they will use it for the recipe stick, maybe for the wifi stick too. So keep in mind that no matter what the kernel does with ikaros AES key before something is decrypted with it, you can only decrypt a recipe chip with it, that has the same serial number as ikaros AND the same key is referred on the recipe chip. Since ikaro talked a lot about the wifi stick verification, I think the last thing his tm decrypted before he dumped the fw was the wifi stick he used. So things to find out: 1. What was the last thing ikaros tm decrypted with the given AES key? Its unlikely that we can decrypt anything else with it. 2. Is the encryption/decryption action mentioned in the patents used for the wifi stick too? 3. Since we know that every recipe chip with the same recipes on it has the same serial(we know that, right?), the question is if the referred key is also the same. We should collect hashsums/content of the first partition of some recipe chips with the same recipes on it and check that. I ordered one "Das Kochbuch" chip today and will share this if it arrived. Does someone else got the "Das Kochbuch" chip and could do this too? 4. As the content on all wifi sticks is the same, does a wifi stick has any serial or referred key that is unique, other than the vendor_id stored in the db? We need hashsums of the files to find that out.If all wifi sticks are the same, we find out what devious the kernel does to the key and ikaros key was really used for his wifi stick, we should be able to decrypt our wifi sticks content. Unfortunately I got no wifi stick to dump at the time. 5. We did not talked a lot about the recipe signature thing. As you can see in some post of Schang S.(search for "cs.tar"), there is a signature stored for every recipe in the db. Even if we could decrypt every stick and the whole tm fw, if the RSA private key is not stored on the tm(which would be really dumb), we can not change or add any recipe. We have to know what matt knows about the recipe verification. I will start to look into the /opt/Thermomix/Thermomix executable again because I think the verification is done in there, but I really dont know how to start. We have to work structured on this so we dont do the same work.
:
Bearbeitet durch User
The key does not depend on the serial number. (The signatures do however.)
Matt C. schrieb: > The key does not depend on the serial number. (The signatures do > however.) Does it only depends on the referred key of the keyring stored in the tm? The patent is not clear about it. Or is the keyring never used? For what did they made a patent then?
> For what did they made a patent then? I don't know, the patent scheme might have been used in a prototype machine? Or be intended to misdirect people? :) > As the content on all wifi sticks is the same, does a wifi stick has > any serial or referred key that is unique, other than the vendor_id > stored in the db? The WiFi stick has a unique ID that is printed on the bottom, and this can be queried from the microcontroller on the stick. I think the files are the same on each stick though. The security scheme for these is quite different from read-only recipe sticks (and I think harder to attack). Matt
Matt C. schrieb: >> For what did they made a patent then? > > I don't know, the patent scheme might have been used in a prototype > machine? Or be intended to misdirect people? :) Do you know that for sure? Did you decrypt a recipe stick without anything from the maybe non-existent key-ring?
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
Matt C. schrieb: > See the dcp_aes_setkey_blk function in > https://github.com/scharri/vorwerk-tm5-oss-sources/blob/master/modified_packages/GPL_LGPL_licensed_packages/linux-kernel-2.6.35/files/dcp.c > for a clue. Wow, I just look quickly on my phone because I was away all the day. I really will check what this function do because it seems to replace the key by a static one. I'll check that. Thanks Hans H. schrieb: > 5. We did not talked a lot about the recipe signature thing. As you can > see in some post of Schang S.(search for "cs.tar"), there is a signature > stored for every recipe in the db. Even if we could decrypt every stick > and the whole tm fw, if the RSA private key is not stored on the > tm(which would be really dumb), we can not change or add any recipe As Matt C. said, code is written by human (not anymore for a long time, thanks AI) but here it's the case. If you have an exploit in the check function, no need have the private key. And in some cases you even deduce it. Bimby T. schrieb: > Hi everyone, so if the files on recipe chip are signed with 2048 bit RSA > signatures we could not change the recipe chip, right? Extacly the same than my previous answer. Hans H. schrieb: > Even if the dcp_aes_setkey_blk function does something devious with the > key, it is important that everyone looks in the patents again Matt C. schrieb: >> For what did they made a patent then? > > I don't know, the patent scheme might have been used in a prototype > machine? Or be intended to misdirect people? :) +1, totally agree with you
Guten Abend alle, sorry but I will write in English. My wife had problem with TM5 weight, is shows wrong, random values, everything other was fine. We send TM5 to authorized service and they said that they replaced mainboard and send thermomix back to us. The question is if they really replaced whole mainboard or not. We put our cook-key (which we didn't send them) and it didn't ask us to provide wlan ssid and password to our wifi network. Don't you know that ssid and password is stored in the TM5 or cook-key? Thanks for reply! Jaro
Jaro J. schrieb: > My wife had problem with TM5 weight, is shows wrong, random values, > everything other was fine. We send TM5 to authorized service and they > said that they replaced mainboard and send thermomix back to us. The > question is if they really replaced whole mainboard or not. We put our > cook-key (which we didn't send them) and it didn't ask us to provide > wlan ssid and password to our wifi network. Don't you know that ssid and > password is stored in the TM5 or cook-key? I think this is not the right place for TM5-support. Pls. open your own thread, because this is offtopic. But if you thing there is an securityproblem simply change SSID and key in your router!
Hi Jaro, The WiFi details are stored in the TM5, however not on the mainboard - the processor is on a separate board behind the LCD screen. So it's possible that they could have replaced the mainboard, I'm not sure how you would tell for sure. I had a similar problem with the TM5 scales which was my original reason for needing to get into the Thermomix, in my case they were fluctuating between 0 and MAX (seems like a common problem). The problem went away after: * unplugging and replugging the three connectors from the mainboard to the scale (labelled WAAGE), and * unscrewing and re-tightening the three screws that go down through the mainboard into the feet. I'm not sure which of these made the difference. It's possible that in your case a mainboard replacement was actually required. The ADC for the scale is on the mainboard. Matt
:
Bearbeitet durch User
Sven L. schrieb: > Jaro J. schrieb: >> My wife had problem with TM5 weight, is shows wrong, random values, >> everything other was fine. We send TM5 to authorized service and they >> said that they replaced mainboard and send thermomix back to us. The >> question is if they really replaced whole mainboard or not. We put our >> cook-key (which we didn't send them) and it didn't ask us to provide >> wlan ssid and password to our wifi network. Don't you know that ssid and >> password is stored in the TM5 or cook-key? > > I think this is not the right place for TM5-support. Pls. open your own > thread, because this is offtopic. > > But if you thing there is an securityproblem simply change SSID and key > in your router! Thank you for answer, Maybe it wasn't needed to write the whole story - I'm sorry. Since you guys are getting into electronic and reverse engineering of TM5 I just asked because you probably already know where are ssid and password stored? In TM5 or cook-key?
Matt C. schrieb: > Hi Jaro, > > The WiFi details are stored in the TM5, however not on the mainboard - > the processor is on a separate board behind the LCD screen. So it's > possible that they could have replaced the mainboard, I'm not sure how > you would tell for sure. > > Matt Matt, thank you very much for reply and for the comprehensive answer! It is what I needed.
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.
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.
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
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
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) ?
> 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
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.
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.
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
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...
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.
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
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
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 ;)
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 ?
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.
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! :)
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 :)
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!
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
Hi Peter, The same for me. Can you please share your libaries? Thanks in advance
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…
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..?
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 ?
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 :-) ...
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... :)
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 ?
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.
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?
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 ?
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
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 ?
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 ?
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.
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
I have a jailbroken iPad. Just let me know if I can help providing files :-) BR
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.
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.
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.
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
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 ?
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... :)
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...
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.
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
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.
(I know I'm late... more comming soon, I promiss) 2faf 32c6 f26b 5cc0 21c1 8988 019a f3a5
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! :)
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? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.