mikrocontroller.net

Forum: Offtopic Thermomix Rezeptchips


Autor: Alexander S. (alexschabel)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Jetzt gibt es auch eine offizielle Vorwerk Seite zum WLAN-Chip

http://cook-key.de/

Autor: David N. (knochi)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Also ist es offiziell... jetzt müssen wir noch an so nen Tester 
rankommen :-)

Autor: Clyde B. (clyde_b)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
WLAN ist zwar klasse, aber auf dem besagten Portal kann man keine 
"eigenen" Rezepte eingeben. Quasi nur gekaufte verwalten, was nicht 
wirklich besser als die fixen gekauften Kochbücher ist.

Es ist ja eigentlich der Wunsch, eigene Rezepte mit der Kiste zu 
verarbeiten. Hoffentlich kommen wir hier irgendwie weiter.

Autor: Hans Ulli K. (elektroman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fabian O. schrieb:
>
> Zu 1: In den Credits steht was von dhcpd.
> Zu 2: ich fänd 50-100€ okay wenn es damit freien Zugang zur Rezeptwelt
> gibt. Hatte mal zwei Sticks dran (Realtek und Atheros) jedoch ohne
> erfolg.

Ich würde auf einen RaLink tippen, da deren Treiber schon länger im 
Kernel sind

Autor: David N. (knochi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tja man sollte sich wohl schonmal mit WireShark und Co 
auseinandersetzen. Vielleicht bekommt man ja auf den Weg Rezepte in das 
Teil. Wobei da garantiert eine https Verschlüsselung dazwischen ist.

Autor: Fabian O. (fabiiian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
David N. schrieb:
> Tja man sollte sich wohl schonmal mit WireShark und Co
> auseinandersetzen. Vielleicht bekommt man ja auf den Weg Rezepte in das
> Teil. Wobei da garantiert eine https Verschlüsselung dazwischen ist.

Denk ich auch. Dann hoffen wir mal, das auf SSL Pinning verzichtet 
wurde.

Autor: Uwe W. (uwe_w45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zugegeben, ich habe lange nicht mitgelesen:

Ist bekannt, dass es bald einen WLAN-Chip geben wird? Ist gerade im 
internationalen Betatest, wie man HIER:

http://thermofix-bonn.blogspot.de/2015/10/sensation-viel-fruher-als-werwartet.html

nachlesen kann.
Vorgesehen ist (zunächst?), dass nur Rezepte aus dem kostenpflichtigen 
meinthermomix-portal übertragen werden können.
Da dort überwiegend Rezepte der bereits gekauften Chips vorgehalten 
werden, macht es nicht viel Sinn, wenn dieser WLAN-Chip lediglich das 
wechseln der Chips erleichtern soll.
Vorteil könnte sein, dass Fehlerhafte Rezepte aus den Chips korrigiert 
auf den WLAN-Speicher-Chip übertragen werden. Außerdem gibt es 
Rezeptsammlungen, die es als Chip nicht gibt. Die hätte man dann auch 
endlich in der Guided Cooking Funktion vorliegen.

Ich kann mir aber nicht vorstellen, dass langfristig nicht auch Rezepte 
anderer Quellen übertagen werden sollen können. Schon allein, um eure 
Bemühungen zu stüren ;)

Wie auch immer: Es wird ein einfacher "Zugang" zum Gerät für euch ;) ;)

: Bearbeitet durch User
Autor: Uhu U. (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Waldemar H. (vual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu U. schrieb:
> Enttäuschendes Testergebnis für den Thermomix
> 
http://www.welt.de/wirtschaft/article149298360/Enttaeuschendes-Testergebnis-fuer-den-Thermomix.html

...da ist meine Frau und ihr TM5-Clan anderer Meinung ;-)

Autor: Barney G. (fuzzel)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Waldemar H. schrieb:
> ...da ist meine Frau und ihr TM5-Clan anderer Meinung ;-)

Ich auch, fuer das Geld koennen wir 10x richtig gut essen gehen und das 
Danach ist eh nicht zu bezahlen.

Also ich persoenlich halte von dem Geraet nix.

Nur eine Meinung von einem eigentlich stillen Mitleser.

Autor: Wolfgang B. (changman)
Datum:

Bewertung
5 lesenswert
nicht lesenswert

Autor: Markus H. (markusfooo)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo liebes Forum,

ich bin kürzlich versucht gewesen mich etwas mit unserem Thermomix und 
dem Rezeptchip zu befassen. Da ich dieses Forum erst im Nachgang 
entdeckt habe, war es für mich super spannend meine Erkenntnisse zu 
challengen und möchte diese noch mal zusammenfassen:

* Der Chip ist "doof" und nur ein USB Stick, das Image kann einfach 
runter geladen werden.
--> Beitrag "Re: Thermomix Rezeptchips"
* Nur am Anfang befinden sich Nutzdaten (ca. die ersten 8MB)
--> Vermutung hier 
Beitrag "Re: Thermomix Rezeptchips", 
"Beweis" hier 
Beitrag "Re: Thermomix Rezeptchips"
* Aufgrund der Entropie tippte ich auch eine Verschlüsselung
--> Ebenfalls aufgefallen hier 
Beitrag "Re: Thermomix Rezeptchips" und 
die Patente (geniale Idee von euch übrigens) weisen auf AES hin 
Beitrag "Re: Thermomix Rezeptchips"

Mit Hilfe des "französischen Images" habe ich dann ein Diff zu "meinem 
Buch" erstellt und das brachte folgende Erkenntnisse:
* Die ersten 512 Byte sind völlig verschieden
* Die Bytes 512 - 2224 sind identisch
* Die Bytes ab (und inkl. 2224) sind wieder unterschiedlich (das franz. 
Image ist sogar etwas kleiner)
--> Vielleicht handelt es sich um verschiedene (Teil)Schlüssel oder 
Schlüsselkette, wobei der Identische Teil von "Vorwerk" ist?

Dann wollte ich mit dem USB-Trace 
(Beitrag "Re: Thermomix Rezeptchips") 
nachvollziehen, welche Parts zuerst gelesen werden um so vielleicht den 
Aufbau besser verstehen zu können. Einen kleinen Einblick was wann 
gelesen wird findet sich zwar bereits hier 
Beitrag "Re: Thermomix Rezeptchips", 
allerdings war ich auch an den Daten interessiert, daher habe ich selbst 
nochmal den Trace geöffnet.
Nun hatte ich erwartet, da wir beide das Grundkochbuch genutzt haben, 
dass ich bei einem SCSI-Read-Command die Daten aus meinem Image wieder 
finde - genau das ist aber nicht der Fall! So scheint "mein" Image 
bereits zu Beginn unterschiedliche Bytes zu haben (ich beziehe mich auf 
die 34te SCSI Operation, ein READ an Adresse 0 von
16384 Bytes).
--> Vielleicht ist die Seriennummer Teil des Schlüssels und das erklärt 
damit unterschiedliche verschlüsselte Daten - aber wäre das nicht 
unwirtschaftlich für jeden Chip ein eigenes Image zu beschreiben?

Hier meine Daten zum Chip:
* Seriennummer: 1004000540010005 (die gleiche wie hier 
Beitrag "Re: Thermomix Rezeptchips")
* MD5Sum vom Image (die ganzen 4GB): c879fb469d7953cb96e56fa65c42beda

Hat wer das gleiche Image oder andere Werte?

Viele Grüße!

: Bearbeitet durch User
Autor: Alexander S. (esko) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Markus H. schrieb:
> Hier meine Daten zum Chip:
> * MD5Sum vom Image (die ganzen 4GB): c879fb469d7953cb96e56fa65c42beda

MD5 von recipes.img ist 32790d0c33309850f1c40ce67b3e3453
Beitrag "Re: Thermomix Rezeptchips"

Kann jemand diese Datei wieder hochladen?

Autor: Eckhard S. (eckhard_s)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Markus H. schrieb:

> Mit Hilfe des "französischen Images" habe ich dann ein Diff zu "meinem
> Buch" erstellt und das brachte folgende Erkenntnisse:
> * Die ersten 512 Byte sind völlig verschieden
> * Die Bytes 512 - 2224 sind identisch
> * Die Bytes ab (und inkl. 2224) sind wieder unterschiedlich (das franz.
> Image ist sogar etwas kleiner)
> --> Vielleicht handelt es sich um verschiedene (Teil)Schlüssel oder
> Schlüsselkette, wobei der Identische Teil von "Vorwerk" ist?
>
>
> finde - genau das ist aber nicht der Fall! So scheint "mein" Image
> bereits zu Beginn unterschiedliche Bytes zu haben (ich beziehe mich auf
> die 34te SCSI Operation, ein READ an Adresse 0 von
> 16384 Bytes).
> --> Vielleicht ist die Seriennummer Teil des Schlüssels und das erklärt
> damit unterschiedliche verschlüsselte Daten - aber wäre das nicht
> unwirtschaftlich für jeden Chip ein eigenes Image zu beschreiben?
>
> Hier meine Daten zum Chip:
> * Seriennummer: 1004000540010005 (die gleiche wie hier
> Beitrag "Re: Thermomix Rezeptchips")
> * MD5Sum vom Image (die ganzen 4GB): c879fb469d7953cb96e56fa65c42beda
>
> Hat wer das gleiche Image oder andere Werte?
>
> Viele Grüße!

Es gibt die Chips in verschiedenen Sprachen.

Vielleicht erklärt das den Unterschied der Bytelängen?

Autor: X. Y. (fastmov)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo, bin der neue.

Ist Euch aufgefallen, dass sich der Chip merkt, welche Rezepte als 
letztes gekocht wurden? Ich habe ja tapfer das Forum studiert aber bin 
dann doch irgendwann abgestorben, weil ich vieles nicht verstehe.

Aber es MUSS sich auf dem Chip (Falls es nicht in der Maschine 
gespeichert wird, das kann jemand testen, der 2 ansonsten gleiche Chips 
besitzt) irgend etwas ändern.

Hoffentlich hilft diese profane Beobachtung bei dem Ziel, einen selbst 
beschreibbaren Chip zu entwickeln.

Leider bin ich ansonsten bin ich ein ziemlicher Laie auf dem Gebiet. Ein 
selbst beschreibbarer Chip wäre traumhaft. Ein "verbesserter" Cook-Key 
(also das ganze per WLan oder auch Bluetooth) wäre es umso mehr.

Meine Lösung ist ein Tablet mit Rezept an der Wand und das funktioniert 
fast genauso gut. Man muss statt auf "Weiter" zu drücken eben Dauer, 
Temperatur, Mixgeschwindigkeit und ggf. Linkslauf eben manuell eingeben, 
damit kann ich leben :-)

Autor: Fabian O. (fabiiian)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Zufällig jmd. aufm 32C3?

Autor: Andreas J. (dolar)
Datum:
Angehängte Dateien:

Bewertung
-2 lesenswert
nicht lesenswert
Hallo Leute,
wie ich letztes jahr sagte würde ich eine gui beisteuern, aber 
mittlerweile habe ich das nicht in c++ sondern in html/js hier in der 
schublade liegen.
ich nutze dafür die sql.js (ich habe keine ahnung von krypto und sql.js 
unterstützt das auch nicht) und nach einigem kopf auf den tisch schlagen 
kann ich die lokalen bilder in der sqlite auch in chrome speichern und 
laden.
rezpte aus der db kann ich anzeigen lassen, aber der eingabemodus ist 
noch nicht geschrieben weil ich da gerne erstmal die db struktur hätte 
um nicht alles wieder umschmeissen zu müssen

irgendwie verstehe ich nicht das die uns so lange zappeln lassen und da 
mal ein paar infos auf den tisch legen.
ich sehe das so: das teil liegt extrem über den vergleichbaren geräten 
die es jetzt immer wieder für 200€ gibt. das einzige merkmal was mir 
jetzt ins auge sticht ist eben das "betreute wohnen" äh.. kochen.

ich habe mir das teil nur wegen dem thread hier gekauft weil ich von der 
dbox2 damals so verwöhnt war hoffte ich auf ein schnelles gelingen.
aber das wurde auch mit einem enormen hardware aufwand geknackt. ich 
möchte nicht an jeden pin vom ram ein drähtchen löten um das auszulesen.

Autor: Bac B. (bac)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
X. Y. schrieb
> Ist Euch aufgefallen, dass sich der Chip merkt, welche Rezepte als
> letztes gekocht wurden?
> Aber es MUSS sich auf dem Chip (Falls es nicht in der Maschine
> gespeichert wird, das kann jemand testen,

Falsche Fährte, die zuletzt gekochten Rezepte werden im TM gespeichert!

Beweis: Wenn ich eines dieser Rezepte aus der Menüfunktion (ohne 
verbundenen Chip) aufrufe, werde ich zB aufgefordert:
Verbinden Sie den Thermomix Rezept-Chip "Das Kochbuch"

Autor: S. Z. (ceving)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dario C. schrieb:
>
> Ich habe mich hier durch den Thread gewurschtelt und festgestellt, dass
> die Aussagen Krypto betreffend - ich will niemanden beleidigen - aber
> fast alle falsch sind.
>

Wenn du Krypto kannst, müsste dir klar sein, dass es wahrscheinlich 
total sinnlos ist, sich am USB-Stick abzureagieren.  Es ist ziemlich 
unwahrscheinlich, das man, ohne den TM5 zu modden, irgend etwas auf 
welchen USB-Stick auch immer schreiben kann.

Wenn ich einen TM5 bauen müsste, würde ich den USB-Stick mit einem 
privaten Schlüssel signieren und in die TM5-Firmware den öffentlichen 
Schlüssel und die Signaturprüfung packen.  Dadurch würde der TM5 nur 
Daten akzeptieren, die von Vorwerk signiert wurden.  Und der dafür 
nötige Schlüssel würde bei Vorwerk im Tresor liegen.  Es würde mich 
schwer wundern, wenn Vorwerk irgendwas anderes gebaut hätte.  Und das 
bedeutet, dass kein Weg daran vorbei führt, die Firmware des Gerätes zu 
ändern.

Und das bedeutet, dass ein Hack des TM5 damit beginnen muss, den 
Diagnose-Port auf dem Board zu finden, um einen Zugang zum Linux zu 
bekommen.  Es ist viel einfacher, die Programme unter Linux zu tracen, 
um dadurch heraus zu finden, was auf dem USB-Stick sein muss.  Und nur 
so wird man auf dem TM5 entweder die Signatur-Prüfung abschalten oder 
seinen eigenen Schlüssel hinterlegen können.

Die Entropie von einem Hexdump zu berechnen oder darin nach 
irgendwelchen Mustern zu suchen, halte ich für völlige 
Zeitverschwendung. Die Zeit kann man besser in die Zubereitung des 
Hefezopfs investieren. Den habe ich heute morgen mit Orangenmarmelade 
genossen. Sehr lecker und zwar deswegen, weil nicht ich das Rezept auf 
den USB-Stick geschrieben habe. ;-)

Autor: Markus H. (markusfooo)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ich stimme S.Z. vollkommen zu - hätte ich das implementieren müssen, 
hätte ich es genau so gemacht (öffentlicher Schlüssel auf Thermomix und 
Signatur prüfen).

Ohne Hack des Thermomix selbst (d.h. damit er die Signatur nicht mehr 
prüft) wird da wohl nicht viel zu holen sein.

Autor: Markus H. (markusfooo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Obwohl ich zugeben muss: zumindest den Inhalt lesen zu können wäre schon 
spannend - aber das auch nur aus technischem Interesse.

Die Aktion hätte wohl kaum einen Mehrwert (ausser die Rezepte am PC zu 
lesen ;)).

Autor: Martin S. (sirnails)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Man merkt - alle die hier so gehyped haben, besitzen nun ihren 
Thermomix, und bei 99% verstaubt er jetzt im Schrank. Und drum ist hier 
auch nichts mehr los :(

Autor: W.P. K. (elektronik24)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wahrscheinlich wollen die meisten dann doch lieber was Richtiges und in 
vernünftigen Portionsgrößen essen. Dann wird der TM eben nur noch hin 
und wieder für Marmelade, Eintopf, Nüsse hacken etc. eingesetzt und 
ansonsten richtig gekocht.
Glück gehabt, das Abendland geht doch nicht sooo schnell unter.

War bei der Nachbarin das Gleiche: erst gab es alle Naselang irgendwas 
"mit meinem Thermomix gekocht", nach ein paar Monaten ist es 
eingeschlafen.

Ich habe ja nichts gegen den TM - es gibt sicherlich Nischenanwendungen, 
da wäre er super und hilfreich - also alle paar Tage mal für einen Teil 
einer Mahlzeit. Aber als generelles und universelles Kochgerät, sorry: 
keine Chance gegen Herd/Ofen und Topf/Pfanne.  Und für 1000 Euro sowieso 
nicht.

Autor: Barney G. (fuzzel)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.P. K. schrieb:
> sorry:
> keine Chance gegen Herd/Ofen und Topf/Pfanne.

Naja, kann man sooo jetzt nun auch nicht vergleichen. Ich meine das 
Dingen ruehrt fuer 1000.- irgendeinen Brei zusammen, mehr macht das ja 
nun auch nicht. Vielleicht was fuer's Altenheim, aber ich zerlege dann 
doch lieber den Fisch mit Messer und Gabel und matsch die Kartoffeln 
selber klein statt im Thermomix "Fischfrikadelle" anzuwaehlen.

Aber ich sehe es auch so. Die stehen jetzt alle im Schrank und gammeln 
vor sich hin, ist ja meist so.

Autor: David N. (knochi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Man merkt - alle die hier so gehyped haben, besitzen nun ihren
> Thermomix, und bei 99% verstaubt er jetzt im Schrank. Und drum ist hier
> auch nichts mehr los :(


Stimmt... Ohne gehackten Rezeptchip ist das Ding ja quasi ohne Funktion. 
Ich habe die 1000€ ja auch eigentlich nur investiert, weil ich mir das 
mal angucken wollte.

Habt ihr so einen Thermomix eigentlich mal aus der Nähe gesehen? Das die 
Dinger nur Brei produzieren ist mindestens 15 Jahre her. Bei uns ist der 
TM jeden Tag im Einsatz. Bevor man eine Küchenmaschine in der 
Preiskategorie anschafft sollte man sich schon genau überlegen, wie das 
in den Alltag passt.

Ich koche selber sehr viel und gerne und war selbst skeptisch. Aber nun 
genug mit dem unsachlichen Geschreibsel. Das tut hier auch eigentlich 
nix zum Thema. Wenn ihr über das Für und Wider des TM quasseln wollt, 
macht nen eigenen Threat auf. Am Besten in einem anderen Forum wo es 
noch mehr Stammtischthemen gibt.

Bis denne
Knochi

Autor: Carsten F. (telefisch)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Es gibt einfach Zuviele dumme Menschen die jeden ihr "Wissen" mitteilen 
müssen.

Diese unqualifizierten Aussagen und Diskussionen haben hier nichts 
verloren. Aber ist doch geil wenn man wieder klugscheissen kann und 
damit auch noch die ärgern kann die es besser wissen.

Klingt für mich nach dem klassischen Neid der Besitzlosen.
Ich bin damit aus dieser Duskussion raus. Schade, hatte gut angefangen.

Autor: Barney G. (fuzzel)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Da der Thread eh tot ist...

David N. schrieb:
> Das die Dinger nur Brei produzieren ist mindestens 15 Jahre her.

Na was kann das dolle Dingen denn sonst noch ausser heissen Brei machen? 
Yo, man kann auf den Kochtopf noch 'n Kochtopf stellen und dann 
duensten. Wow.
ALLES Andere muss dann nochmal in einen extra Topf, Pfanne, Backofen und 
wenn ich mit der Thermokocherei fertig bin habe ich 3x so viel Geruempel 
zu spuelen wie normalerweise. Oder schaelt mir das Teil die Kartoffeln, 
Moehren, Zwiebeln und Co auch noch ?
Das Dingen macht doch NICHTS anderes als ein Rezept vorzulesen und mit 
gepiepe zu nerven. Die Kroenung, man muss staendig irgendwelche Knoeppe 
druecken und dem auch brav Bescheid geben das die Zwiebeln jetzt drin 
sind, also trotz das es einem Arbeit abnimmt steht man doof daneben. Man 
oh man.
Naja, ist wohl so ein Thema wie MAC vs PC, habe ich auch noch nicht 
verstanden.

Autor: Clyde B. (clyde_b)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Ich habe schon den Vorgänger besessen und nutze ihn regelmäßig seit 
langer Zeit. Auch in Kombination mit anderen Küchengeräten/Töpfen und 
Pfannen.

Gegenüber konventionellem Kochfeld kochen kann er die Temperatur 
hinreichend genau regeln, was sehr komfortabel ist und unbeaufsichtigte 
exakte Arbeitsschritte erst ermöglicht.

Ebenso sind direktes Einwiegen, Zeit- und Stufenwahl effektive Optionen 
um Rezepte gelingsicher zu entwickeln, reproduzieren und dokumentieren. 
Dies sollte nicht unterschätzt werden und es ist kein MUSS, denn ich 
kann mit dem Teil auch frei Schnauze ohne Rezept etwas zubereiten, wenn 
man sich eingearbeitet hat.

Der TM soll nichts ersetzen. Er kann Arbeitsschritte erleichten und wer 
das sinnvoll einzusetzen weiß, hat einen Vorteil. Wie groß der bei jedem 
einzelnen ist und ob das seinen Preis rechtfertigt, ist eine persönliche 
Abwägung.

Wenn ich an die ganzen Kaffeeautomaten und die nicht einkalkulierten 
Folgekosten denke, ...

Wer auf Zusatzstoffe achten muss/will, kommt ums Selbermachen nicht 
herum. Mit dem TM ist es einfach, Brotaufstriche, Wurst- und 
Käsealternativen, Kosmetik, Wasch- und Reinigungsmittel, Vollkornmehl, 
Würzmittel, Liköre, Salben, etc. herzustellen. Und man weiß was drin 
ist.

Wer darin nur Brei herstellen kann, hat den TM nicht begriffen oder 
braucht ihn einfach nicht, was ja auch sein kann. :-)

Autor: Mode M. (mode)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Leute, bitte beim Thema bleiben.

Autor: Axel W. (axelmi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da anscheinend das Grundkochbuch immer die gleiche Seriennummer hat, 
stellt sich für mich die Frage, ob das bei anderen Kochbüchern mit dem 
selben Titel auch so ist.
Ausserdem ob die Bytes 512 - 2224 identisch bei allen büchern ist oder 
innerhalb eines Buchtitels.
Ich hab leider nur das Leicht & Lecker und noch niemanden gefunden der 
das gleiche hat.
Steht die aufgelaserte Seriennummer auf der Rückseite aussen (der 
Buchstabencode) in Beziehung zu der Seriennummer des Usbsticks ?
Für den Cook-Ring (Wlan-Adapter) muss man diese Nummern im Portal 
eingeben und kann damit sich die Bücher freischalten....


Ausserdem kann ich mich Mode M. nur anschliessen und beim Thema bleiben. 
Dieser Flamewar um den Thermomix nervt nur.

Autor: Christoph H. (christoph_h408)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich halte mich jetzt mal bewusst aus der Pro/Contra Diskussion zum 
Thermomix raus. Meine Frau hat einen in der Küche stehen, also will der 
auch mal aus Nerd-Perspektive betrachtet werden. Über die Rezept-Chips 
reinzukommen, ist wohl wenig erfolgsversprechend wenn ich eure 
bisherigen Ergebnisse korrekt interpretiere.

Ich versprechen mir eine größere Chance wenn das Ding erstmal in meinem 
Netzwerk hängt. Da ja bald ein WLAN Modul für das Gerät erscheint werde 
ich mir das mal besorgen. (Achtung Produktwebseite: 
https://cook-key.de/)

Generell hätte ich da zwei Ansätze, wenn das Ding erstmal ne IP hat 
könnte man scannen ob man irgendwie von aussen auf das Ding kommt (nen 
SSH Server wird es wohl leider nicht laufen haben denke ich). Alternativ 
könnte ich mir vorstellen den Netzwerkverkehr mitzulesen, wobei der ja 
vermutlich verschlüsselt sein wird. Der muss ja auf irgendeine Art im 
Netz erreichbare API zugreifen. Wenn ich diesen API Server im lokalen 
Netz dann simuliere müsste ich ja eigene Rezepte auf das Teil bekommen. 
Warum der Hersteller soviel Wert darauf legt, nur seine Rezepte auf das 
Gerät zu schicken, verstehe ich nicht. Zumindest wenn jemand dieses 
dämliche Jahresabo für alle Rezepte abschliesst, kann derjenige über das 
Thermomixportal weder eigene Rezepte abspeichern noch die vorhandenen 
Rezepte individuell optimieren. Das wäre sicherlich umzusetzen, scheint 
aber in der Vertriebspolitik nicht vorgesehen zu sein.

Aber ich denke, wenn das Gerät erstmal im Netzwerk hängt habe ich mehr 
Angriffspunkte ohne das Gerät auseinanderzuschrauben.

Autor: Ivo B. (ivoburkart)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
So. Hab mal mit dem Cook Key etwas rumgespielt.

Erstmal ist auf dem Key ein Firmware-update für das Gerät gespeichert. 
Evtl. kann man da was drehen (siehe unten)

Rezepte und Favoritenlisten werden vom Server auf den Speicher des Chips 
synchronisiert. D.h. die Rezepte sind danach offline nutzbar.

Hab mal ein SSL man in the middle versucht, und es scheint so als führt 
der TM5 eine ordentliche Zertifikatprüfung durch.

Allerdings wird eine unverschlüsselte HTTP anfrage gesendet (URL ist 
/now) die sehr wahrscheinlich zur Zeitsynchronisation dient gestellt. 
Danach ist alles HTTPS.

Mit dem proxy versucht er es ca. 5 mal und gibt dann mit einer 
Zahlenfehlermeldung auf.

Man müsste also nur die Stammzertifikate in dem Firmwareupdate verändern 
und schon könnte man einen eigenen Rezepteserver starten.

Nachtrag: Leider keine offenen Ports

: Bearbeitet durch User
Autor: Winston S. (winston_smith)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe (noch?) keinen Thermomix, aber der Thread ist sehr interessant.

Angriffspunkte, die mir noch einfallen:
- Man sollte einfach mal eine Tastatur an den USB-Port anstecken und 
CTRL+ALT+F1 drücken. Vielleicht erscheint dann ein Terminal auf dem 
Bildschirm? :O)
- Es ist sehr alte Software installiert (2.6er Kernel(!), vermutlich 
auch altes openssl, glibc, ...)! Da müsste man doch den passenden 
fertigen Exploit finden können und ausführen (Vielleicht beim parsen der 
Zertifikate in openssl oder so?)
- Auf die schnelle habe ich jetzt den hier gefunden: getaddrinfo() in 
der glibc wird exploitet - man simuliert also quasi einen DNS server, 
der anstatt die echte Adresse zum Update-Server aufzulösen, einen 
Exploit schickt, der dann von der glibc ausgeführt wird: 
https://www.exploit-db.com/exploits/40339/
- Ich habe das natürlich alles nicht getestet, sollen nur Denkanstöße 
sein.

Viel erfolg!

Autor: 1nv41n 1. (1nv41n)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den sehr interessanten Thread! Haben einen TM5 und bekommen in 
den nächsten Tagen den WLAN Cook Key.. Hätte die selbe mim-attacke 
geplant gehabt wie @ivoburkart. Werde versuchen eine USB-Tastatur direkt 
an den TM5 anzuschließen (mit Magnet) und dann melden was passiert.
Ich kann mir sehr gut vorstellen, dass nach dem Firmwareupdate über den 
Cook Key auch eventuell vorhandene Lücken geschlossen werden.
@ivoburkart: Wird das Update automatisch durchgeführt oder erst nach 
WLAN Einrichtung usw? Ist das Update auf dem Cook Key gespeichert wie 
die Informationen auf den Kochbüchern? Eventuell könnte man da ja ein 
image ziehen...

Autor: Martin S. (sirnails)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Also ohne hier jemanden was vorschreiben zu wollen:

Der TM5 Hack ist juristisch auf sehr dünnem Eis, weil man hier durchaus 
von technischen Schutzmaßnahmen zur Beschränkung des Zugriffs sprechen 
kann.

Entsprechend wäre es weitaus besser (auch für den Seitenbetreiber), das 
wenn was kommt, ihr nicht angemeldet postet, und eventuell auch einen 
VPN wie hide.me oder hidemyass.com nutzt.

Autor: Ivo B. (ivoburkart)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1nv41n 1. schrieb:
> @ivoburkart: Wird das Update automatisch durchgeführt oder erst nach
> WLAN Einrichtung usw? Ist das Update auf dem Cook Key gespeichert wie
> die Informationen auf den Kochbüchern? Eventuell könnte man da ja ein
> image ziehen...

Das update ist auf dem key drauf. Das muss man installieren um die 
WLAN-Funktionalität überhaupt zu erhalten.

Ausserdem ist das Basiskochbuch mit auf dem Key, so dass der Basis-Chip 
nicht mehr nötig ist.

Was ein paar leute stören wird: Der Empfang ist sehr schlecht für die 
Größe des moduls. Zudem war es mir nicht möglich eine Verbindung mit 
einem 5ghz Netz herzustellen

Autor: Axel W. (axelmi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann das Update beliebig oft eingespielt werden oder nur einmal ?

Autor: Ivo B. (ivoburkart)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das update kann nur einmal eingespielt werden. Bei Einsetzen des Keys 
wird man gefragt ob man das machen will

Autor: 1nv41n 1. (1nv41n)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Martin S. schrieb:
> Also ohne hier jemanden was vorschreiben zu wollen:
>
> Der TM5 Hack ist juristisch auf sehr dünnem Eis, weil man hier durchaus
> von technischen Schutzmaßnahmen zur Beschränkung des Zugriffs sprechen
> kann.
>
> Entsprechend wäre es weitaus besser (auch für den Seitenbetreiber), das
> wenn was kommt, ihr nicht angemeldet postet, und eventuell auch einen
> VPN wie hide.me oder hidemyass.com nutzt.

Danke Martin für den Denkanstoß!  Bin da ganz bei dir, und ob dieser 
Rahmen hier der richtige ist Frage ich mich auch.
Nur zum Verglich: Falls wer die Tiptoi Stifte von Ravensburger kennt - 
Da haben findige Reverse-Engineers so viel über die Funktionsweise des 
Stiftes herausgefunden um jetzt selber Bücher drucken zu können. Ist das 
jetzt verboten oder nur einfach genial? Verkauft Ravensburger jetzt 
weniger Bücher? Ich denke wohl kaum.

Und wenn man vielleicht erreicht, selbst Rezepte programmieren zu 
können, schadet das dann Vorwerk? Wird dann diese Funktion freigegeben? 
Kauft man dann die Online-Rezepte weniger? Kann sein, nur die 5-10 
(sorry) Geeks die das machen werden wohl keinen Umsatzschaden anrichten 
können, oder?

Ich für meinen Teil kann nur sagen: Spaß am Tüfteln sollte nicht 
verboten sein. Exploits public zu machen um damit dem Hersteller zu 
schaden ist natürlich ein no go!

Autor: Winston S. (winston_smith)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Entsprechend wäre es weitaus besser (auch für den Seitenbetreiber), das
> wenn was kommt, ihr nicht angemeldet postet, und eventuell auch einen
> VPN wie hide.me oder hidemyass.com nutzt.

Eigentlich geht das hier total am Thema vorbei, aber wenn man sich schon 
in der Richtung Schützen will, dann bitte richtig mit dem Tor Browser ( 
https://torproject.org ).

Back 2 Topic:
Probiert mal den exploit mit der glibc aus, den ich weiter oben gepostet 
habe an die, die einen solchen Thermomix besitzen. Damit solltet ihr zum 
Ziel kommen.

Autor: 1nv41n 1. (1nv41n)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
1nv41n 1. schrieb:
> Danke für den sehr interessanten Thread! Haben einen TM5 und bekommen in
> den nächsten Tagen den WLAN Cook Key.. Hätte die selbe mim-attacke
> geplant gehabt wie @ivoburkart. Werde versuchen eine USB-Tastatur direkt
> an den TM5 anzuschließen (mit Magnet) und dann melden was passiert.
> Ich kann mir sehr gut vorstellen, dass nach dem Firmwareupdate über den
> Cook Key auch eventuell vorhandene Lücken geschlossen werden.
> @ivoburkart: Wird das Update automatisch durchgeführt oder erst nach
> WLAN Einrichtung usw? Ist das Update auf dem Cook Key gespeichert wie
> die Informationen auf den Kochbüchern? Eventuell könnte man da ja ein
> image ziehen...

Danke für die Infos!
Mit HP Tastatur hat nichts geklappt, leuchtet nicht mal, auch nicht mir 
Magnet.

Autor: Thomas D. (digitalfreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe mir auch einen Cook-Key besorgt in der Hoffnung hier ein 
Möglichkeit zu finden eigene Rezepte unterzubringen. Ich habe den Thread 
mit Begeisterung gelesen. Meine Hoffnungen wurde im Prinzip zerstört: 
Keine API zur lokalen Kommunikation sondern direkte Kommunikation mit 
dem Vorwerkserver über gesicherte Verbindung die sich nich mit einem 
mitm Angriff austrixen lässt.
Ich mache mir auch wenig Hoffnung das man über die Updatefirmware 
reinkommt, die ist vermutlich genau so signiert wie die Kochbuchchips 
und wenn man die schon nicht "knacken" kann wird es mit dem Update 
sicher auch nicht gelingen.
Einzig ein Hack der TM5 Firmware, wie schon oft erwähnt, wird wohl die 
Problemlösung näher bringen.
Hat schon mal jemand die TM5 soweit analysiert um die Flashbausteine mit 
der Firmware zu lokalisieren und eventuell auszulesen. Eventuell ist ja 
die Firmware dort unverschlüsselt, wobei meine Vermutung auch eher ist 
das die selbst dort verschlüsselt ist.
Vorwerkt scheint sich ja vor Hacks sogar so sehr zu fürchten das sie 
sich nicht mal trauen eine Android App herauszubringen.

Eventuell bekommt man ja eine Custom-FW drauf aber der Aufwand ist 
sicher sehr sehr groß.

Grüße,
Thomas

Autor: Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Es stellt sich die Frage nach dem Verhältnis von Aufwand zum Nutzen ein 
Gerät zu hacken welches in allen Bewertungen zwischen durchschnittlich, 
laut und gefährlich eingestuft wird.

Namaste

Autor: Waldemar H. (vual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist der Verlauf der Einrichtung vom Cook-Key gezeigt. Wer es nicht 
hat und wen es aber interessiert

Youtube-Video "Cook-Key - Aktivierung und Update des Thermomix"

Autor: Hans Ulli K. (elektroman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Waldemar H. schrieb:
> Hier ist der Verlauf der Einrichtung vom Cook-Key gezeigt. Wer es nicht
> hat und wen es aber interessiert
>
> Youtube-Video "Cook-Key - Aktivierung und Update des Thermomix"

???
15 Rezepte Buttons WTF ???, das ist ja noch schlimmer als bei Druckern 
...

1nv41n 1. schrieb:
> Danke für die Infos!
> Mit HP Tastatur hat nichts geklappt, leuchtet nicht mal, auch nicht mir
> Magnet.
Hätte mich auch gewundert, soweit kenne ich mich langsam mit dem USB 
Protokoll aus.
Wenn ihr Glück habt kann man den Cook Key an einen normalen PC 
anklemmen. Aber hier könnte Vorwerk auch noch eine Falle eingebaut haben
Die USB-ID ist könnte keine "offizielle". Vielleicht kann man aus der 
MAC Adresse von den WLAN NIC Rückschlüsse ziehen, aber das ist nicht 
sicher.

Thomas D. schrieb:
> Hallo zusammen,
>
> ich habe mir auch einen Cook-Key besorgt in der Hoffnung hier ein
> Möglichkeit zu finden eigene Rezepte unterzubringen. Ich habe den Thread
> mit Begeisterung gelesen. Meine Hoffnungen wurde im Prinzip zerstört:
> Keine API zur lokalen Kommunikation sondern direkte Kommunikation mit
> dem Vorwerkserver über gesicherte Verbindung die sich nich mit einem
> mitm Angriff austrixen lässt.
> Ich mache mir auch wenig Hoffnung das man über die Updatefirmware
> reinkommt, die ist vermutlich genau so signiert wie die Kochbuchchips
> und wenn man die schon nicht "knacken" kann wird es mit dem Update
> sicher auch nicht gelingen.
> Einzig ein Hack der TM5 Firmware, wie schon oft erwähnt, wird wohl die
> Problemlösung näher bringen.
> Hat schon mal jemand die TM5 soweit analysiert um die Flashbausteine mit
> der Firmware zu lokalisieren und eventuell auszulesen. Eventuell ist ja
> die Firmware dort unverschlüsselt, wobei meine Vermutung auch eher ist
> das die selbst dort verschlüsselt ist.
> Vorwerkt scheint sich ja vor Hacks sogar so sehr zu fürchten das sie
> sich nicht mal trauen eine Android App herauszubringen.

Wenn Vorwerk das sauber entwickelt hat (was ICH glaube) ist der minimale 
Bootloader im ROM vom SoC (*) und der läd halt den 2. Stage Bootloader 
und entschlüsselt ihn.

(*)
z.B. Marvell Kirkwood/Armada habe intern einen minimal Bootloader dieser 
kann bei einem kaputten Flash benutzt werden um per serielle 
Schnittstelle einen neuen Bootloader auf das NAND/ SPI NOR Flash zu 
schreiben.
Die Doku dazu ist in den Sourcen von U-boot
Natürlich ohne Verschlüsselung ...

Autor: Michael M. (Firma: DO7TLA) (do7tla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir fällt auf das nur versucht wird über den USB Anschluss in das Gerät 
zu kommen.
Es hat bisher noch keiner so richtig im Thermomix selber auf der 
Hauptplatine die Seriellen oder andere vorhandene Schnittstellen 
untersucht.
Möglich das es im Gerät noch eine USB Schnittstelle gibt die für 
Servicezwecke da ist.

Autor: Hans Ulli K. (elektroman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael M. schrieb:
> Mir fällt auf das nur versucht wird über den USB Anschluss in das Gerät
> zu kommen.
> Es hat bisher noch keiner so richtig im Thermomix selber auf der
> Hauptplatine die Seriellen oder andere vorhandene Schnittstellen
> untersucht.
> Möglich das es im Gerät noch eine USB Schnittstelle gibt die für
> Servicezwecke da ist.

Das Problem an solchen USB Schnittstellen ist, der Kernel muss diese 
erkennen und nutzen -> unwahrscheinlich

Auch seriell ist schwer, z.B. wird bei Xioami mini Router nach dem 
ersten Boot diese abgeschaltet !. Nur per Service Request kommt man auf 
die BOX um alles umzubauen. Selber gemacht !

Irgendeiner muss eben auf der Kiste "probieren" per Oscar (Oszilloskop 
für die jüngere Generation) und nach der seriellen Schnittstelle suchen.
Aber an 1000 (T)EUR zu testen, da glaube ich die "bessere" Hälfte würde 
einem den  .... versohlen.

Persönlich brauche ich so einen Staubfänger nicht.
Besonders wenn man sieht was da sonst noch alles drumherum passiert, das 
ist ja fast so schlimm, wie die Influenzer auf Youtube

Autor: Michael M. (Firma: DO7TLA) (do7tla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans Ulli K. schrieb:
> Aber an 1000 (T)EUR zu testen, da glaube ich die "bessere" Hälfte würde
> einem den  .... versohlen.

Daran wird dieses Projekt scheitern!


Deswegen die untersuchung der Hauptplatine.
Da ist die warscheinlichkeit deutlich größer das man weiterkommt als 
über den Äußeren USB Anschluß.

Autor: Fabian O. (fabiiian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MAC ist übrigens 00:13:43:XX:XX:XX

Das ist der Prefix von:

Matsushita Electronic Components (Europe) GmbH
Zeppelinstrasse 19
Lueneburg  Niedersachsen  21337
DE

: Bearbeitet durch User
Autor: Migel C. (migelchen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Winfried J. schrieb:
> und gefährlich eingestuft wird.
>
> Namaste

Gefährlich wäre mir neu. ^^
Verhältnismäßig laut und kostenintensiv ja, aber gefährlich wohl kaum.

Autor: Tobias C. (toco)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die aktuellen Open Source Versionen für Software Version: 201605230000

Linux kernel 2.6.35.3-imx GPLv2 (from Freescale SDK 10.12.01, + custom 
patches)
Busybox 1.15.0 - GPLv2
GNU C librarz 2.11.1 - LGPLv2.1
libgcc 4.4.2 - CPL-3.0-with-GCC-exception
libstdc++ 4.4.2 - CPL-3.0-with-GCC-exception
kobs-ng 10.12.01 - GPLv2 (+custom patches)
mtd-util 201006 - GPLv2
util-linux 2.21.2 - GPLv2
logrotate 3.8.3 - GPLv2
dhcpd (ISC) 3.0.3b1 - ISC license
zlib 1.2.8 (28-04-2013) - zib license
libpng 1.6.18 (July 23, 2015) - libpng license
libjpeg 9a (19-Jan-2014) - libjpeg license
libfreetype 2.6.1 (04-October-2015) - GPLv2
m2mxml-C 1.0 (08-03-2013) - LGPLv2.1
libwebsockets v1.5-chrome47-firefox41 - LGPLv2.1
curl 7.21.6 - MIT license
sqlite 3.7.16 - Public Domain
openssl 1.0.2d (09-July-2015) - OpenSSL license
nanomsg 0.5-beta MIT license
avrdude 6.11.1 - GPLv2
lrzsz 0.12.20 - GPLv2
e2fsprogs 1.41.4 - GPLv2
libsqlite 3.7.16 - public domain
libcre 1.2.4 - BSD 3-clause license
libxml2 2.6.28 - MIT license
popt 1.6.3 - MIT license
wireless-tools - GPLv2 & (LGPLv2.1 | MPL-1.1 | BSD)
wpa-supplicant 2.4 - BSD license

: Bearbeitet durch User
Autor: Nix I. (nixis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
guten tach

meine frau hat jetzt auch so´nen tm5 mixer mit wlan ....

wir nutzen erstmal die 6 monate inkl. für das cookidoo, danach ist ja 
ein abo fällig (36,-€).
der cook-key ist nach erfolgreicher sync auch offline (ohne wlan) 
nutzbar.

ivoburkart schrieb das bis auf /now alles https bzw. ssl verschlüsselt 
ist.

frage: woher weiß der cook-key ob mein abo gültig ist ?
ist ein ev. zeitsync mit ntp notwendig da der "datensatz" auf dem stick 
bzw. ein mögliches zertifikat ein ablaufdatum hat ?
was ist wenn der ntp manipuliert wird ?

okay so bekommt man zwar keine eigenen rezepte drauf auf das was drauf 
ist bleibt zumindest drauf.

Autor: D. E. (depp)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias C. schrieb:
> Die aktuellen Open Source Versionen für Software Version: 201605230000
>
> Linux kernel 2.6.35.3-imx GPLv2 (from Freescale SDK 10.12.01, + custom
> patches)
[...]
> wpa-supplicant 2.4 - BSD license

CVE-2015-1863
Heap-based buffer overflow in wpa_supplicant 1.0 through 2.4 allows 
remote attackers to cause a denial of service (crash), read memory, or 
possibly execute arbitrary code via crafted SSID information in a 
management frame when creating or updating P2P entries.


Das klingt doch nach allem was man braucht um mit einem SoftAP kurz vor 
Schulschluß in der Wohnsiedlung viel Freude zu bereiten :-D

Autor: Chris R. (chrisr2710)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ich habe mal den Cook-Key auseinander gebaut und ein Bild davon 
angehängt.

Hier die Infos:
1. USB-Stick
2. Mikrocontroller PIC16F1454
3. USB-Hub FE1.1s
4. Wifi PAN9010U

Wie könnte man nun weiter vorgehen?

Autor: David N. (knochi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na das sieht ja übersichtlich aus. Keine weiteren Komponenten auf der 
Rückseite?

Vielleicht könnte man die Kommunikation zwischen pic und WiFi Modul 
belauschen.
Kann aber auch sein, dass der PIC nur den USB Hub und das WLAN Modul 
beim Start konfiguriert.

Jedenfalls sehe ich da eine Programmierschnittstelle, evtl. auch eine 
Angriffsfläche.

Leider habe ich so ein Teil nicht zur Hand, sonst würde ich Mal das 
Oszilloskop dranhängen.


Bis denne
Knochi

Autor: Chris R. (chrisr2710)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, auf der Rückseite ist nichts mehr.

Mit einem Oszilloskop habe ich noch nie gearbeitet. Ich hätte einen 
Raspberry Pi zur Hand. Kann ich damit etwas überwachen oder rausfinden 
was uns weiterhilft? Oder kann man die Daten die auf dem USB-Stick sind 
irgendwie auslesen?

Welche Programmierschnittstelle kannst du auf der Platine erkennen? Das 
schräge schwarze Plastikteil mit den 4 Eingängen ist für die 4 Pins am 
Thermomix (wo der Cook-Key mit Magnet befestigt wird).

Autor: Chris M. (christoph_m988)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Chris,

wie hast du den Cook-Key den aufbekommen?
Ich bin mit den üblichen Werkzeugen zum Öffnen von Handy und anderen 
Geräten gescheitert...allerdings hat meine Frau mich auch schon kritisch 
beäugt.
--> Vielleicht kannst du hier noch ein paar zusätzliche Fotos 
einstellen, damit man sieht, wo die Klips (?) sind/wie man den Key 
beschädigungsfrei öffnet :)

Bei dem USB-Hub-Chip handelt es sich lauten Datenblatt um ein 
4-Kanal-Hub 
(https://cdn-shop.adafruit.com/product-files/2991/FE1.1s+Data+Sheet+(Rev.+1.0).pdf).
Es wäre jetzt interessant an die verbleibenden zwei Ports zusätzliche 
Geräte anzuschließen (bspw. USB Tastatur). So wie das auf deinem Foto 
aussieht, könnte man die Tastatur auch direkt in die USB-Buchse 
einstecken? Oder eine WebCam, einen WLan-Stick....

: Bearbeitet durch User
Autor: David N. (knochi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris R. schrieb:
> Nein, auf der Rückseite ist nichts mehr.
>
> Mit einem Oszilloskop habe ich noch nie gearbeitet. Ich hätte einen
> Raspberry Pi zur Hand. Kann ich damit etwas überwachen oder rausfinden
> was uns weiterhilft? Oder kann man die Daten die auf dem USB-Stick sind
> irgendwie auslesen?
Mit dem Raspberry könnte man Mal versuchen, ob irgendwo ein Uart zu 
finden ist, vielleicht spuckt der ein paar Informationen aus.

> Welche Programmierschnittstelle kannst du auf der Platine erkennen? Das
> schräge schwarze Plastikteil mit den 4 Eingängen ist für die 4 Pins am
> Thermomix (wo der Cook-Key mit Magnet befestigt wird).

Ich meine die goldenen Testpunkte links oben. Offensichtlich gehen 
mindestens zwei auf den PIC.

Autor: Hans Ulli K. (elektroman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris R. schrieb:
> Ich habe mal den Cook-Key auseinander gebaut und ein Bild davon
> angehängt.
>
> Hier die Infos:
> 1. USB-Stick
> 2. Mikrocontroller PIC16F1454
> 3. USB-Hub FE1.1s
> 4. Wifi PAN9010U
>
> Wie könnte man nun weiter vorgehen?

Dann wollen wir mal die Bauteile analysieren ...
1. USB-Stick
nichts besonderes.
Vielleicht Treiber und/oder Rezepte drauf

2. Mikrocontroller PIC16F1454
für irgendwas zum steuern oder speichern.
Dazu später mehr

3. USB-Hub FE1.1s
ein einfaches USB 4 fach HUB IC
wenn noch ein EEPROM vorhanden ist, kann dieses mit einer USB VID/PID 
vom "Hersteller" beschrieben werden. Es sollen zwei Ports benutzt sein. 
Einer für den USB Stick und einer für das WLAN Modul.
Mal sehen ..

4. Wifi PAN9010U
Ein WLAN Modul von Panasonic, das mit einem Marvell 88W8782 bestückt 
ist. Dazu soll es Linux/Android Treiber geben

Also nichts besonderes, wenn nicht der Mikrocontroller wäre.
Laut Datenblatt hat der eine USB Schnittstelle und sogar USB 2, der 
dritte Teilnehmer auf dem HUB.

So wie es aussieht hat dieser keine Funktion, ggf. vielleicht für den 
USB Stick ...

Könnte es sein, das dort was versteckt ist ??

Ist der gleiche Aufbau HUB-IC, Stick, Mikrocontroller auf den den Rezept 
Buttons ??

Autor: David N. (knochi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans Ulli K. schrieb:
> Chris R. schrieb:
>> Ich habe mal den Cook-Key auseinander gebaut und ein Bild davon
>> angehängt.
>>
>> Hier die Infos:
>> 1. USB-Stick
>> 2. Mikrocontroller PIC16F1454
>> 3. USB-Hub FE1.1s
>> 4. Wifi PAN9010U
>>
>> Wie könnte man nun weiter vorgehen?
>
> Dann wollen wir mal die Bauteile analysieren ...
> 1. USB-Stick
> nichts besonderes.
> Vielleicht Treiber und/oder Rezepte drauf
Da wird das Softwareupdate für den ersten Start drauf sein. Später dann 
die Rezepte.

> 2. Mikrocontroller PIC16F1454
> für irgendwas zum steuern oder speichern.
> Dazu später mehr

>
> 3. USB-Hub FE1.1s
> ein einfaches USB 4 fach HUB IC
> wenn noch ein EEPROM vorhanden ist, kann dieses mit einer USB VID/PID
> vom "Hersteller" beschrieben werden. Es sollen zwei Ports benutzt sein.
> Einer für den USB Stick und einer für das WLAN Modul.
> Mal sehen ..
Und einer für den PIC

> 4. Wifi PAN9010U
> Ein WLAN Modul von Panasonic, das mit einem Marvell 88W8782 bestückt
> ist. Dazu soll es Linux/Android Treiber geben
>
> Also nichts besonderes, wenn nicht der Mikrocontroller wäre.
> Laut Datenblatt hat der eine USB Schnittstelle und sogar USB 2, der
> dritte Teilnehmer auf dem HUB.
>
> So wie es aussieht hat dieser keine Funktion, ggf. vielleicht für den
> USB Stick ...
Ich nehme Mal an, da der TM ja nur einen USB Port hat, übernimmt der PIC 
das Housekeeping, also Konfiguration des WLAN Moduls, des USB Hubs und 
das ansteuern der LEDs.

> Könnte es sein, das dort was versteckt ist ??
Ich fürchte nicht. Der TM greift auf die drei Geräte vermutlich einfach 
als USB Devices zu. Lädt Rezepte über das WiFi Modul und speichert diese 
wie gehabt verschlüsselt auf den Stick.

> Ist der gleiche Aufbau HUB-IC, Stick, Mikrocontroller auf den den Rezept
> Buttons ??

Ne da ist nur ein USB Stick, ähnliche diesem drin. Weiter oben sind 
Fotos.
Ist ja dann auch nur ein Gerät und keine LEDs.

Bis denne
Knochi

Autor: Chris R. (chrisr2710)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hier sind noch ein paar weitere Fotos. Leider ist der Cook-Key verklebt, 
sodass ein zerstörfreies öffnen nicht möglich ist. Ich habe mit einem 
Messer die weiße Abdeckung ringsherum aufgehebelt. Das hat ganz gut 
funktioniert.

Anschließend muss man die 4 markierten Punkte (runde Huckel) mit einem 
Messer abschneiden damit man die Platine entfernen kann.

Wenn man die Platine komplett freiliegend haben möchte, müsste man noch 
die Lichtleiter entfernen (ebenfalls auf der Rückseite die 10 runden 
Huckel, aber kleiner). Ich habe das gemacht.

=> Eigentlich würde ich gerne irgendwie an das Zertifikat kommen, um den 
WLAN-Verkehr beeinflussen zu können.
=> Oder wie könnte ich per Konsole irgendwie auf das System kommen?
=> @knochi: wie könnte das mit dem UART gehen?

Ich bräuchte Infos von euch, was ich versuchen soll, wenn sich sonst 
niemand anderes traut das Teil zu zerlegen :-D

Mfg Chris

Autor: Chris M. (christoph_m988)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Chris,

hast du mal versucht an den USB-Port andere USB Gerät (Maus oder 
Tastatur, Bluetooth-Stick) anzuschließen (anstelle des USB-Sticks im 
Cook-Key)? Interessant wäre sicher auch mal ein USB-auf-VGA-Adapter 
(LogiLink USB zu VGA Display: https://www.reichelt.de/?ARTICLE=132672).

Danke und viele Grü0e

: Bearbeitet durch User
Autor: Ivo B. (ivoburkart)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde mal vermuten der pic ist für die led.

Autor: Chris R. (chrisr2710)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, habe ich bisher nicht versucht. So ein USB-VGA-Adapter habe ich 
nicht. Wenn ich nur eine Tastatur anschließe bringt mich das nicht 
weiter, oder was ist der Hintergrund?

Autor: Fabian O. (fabiiian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt ihr den Thread mal von Anfang an gelesen? Das haben wir doch alles 
schon probiert.

Der WiFi Chip ist IMO nichts anderes als ein USB Hub mit Memorystick, 
WiFi Client und USB Led Controller. Und da SSL Pinning an ist, bring es 
uns auch nicht weiter. Bleibts wohl beim kopieren der Chips :(

Autor: Michael M. (Firma: DO7TLA) (do7tla)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es schon neuigkeiten zu dem Mainboard im TM selber?
Hat hier schon jemand Forschungen angestellt?

Leider lese ich in diesen Thread nur viel zu den USB Anschluss und dem 
Cookkey.
Und da drehet man sich wohl nur noch im Kreis.

: Bearbeitet durch User
Autor: Axel W. (axelmi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Usb Anschluss ansich ist doch ein interessanter Angriffspunkt.
Mit dem Facedancer/Raspdancer 
(https://github.com/travisgoodspeed/goodfet/tree/master/contrib/facedancer) 
ist es möglich USB Geräte zu simulieren und das Protokoll zu 
manipulieren. Vielleicht ist es damit möglich Fehler im Usb-Stack oder 
Device-Treiber zufinden.

Platinen für den Raspdancer21 hab ich heute bekommen. Sobald er zusammen 
gebaut ist, wollte ich damit mein Glück versuchen.

Autor: Stephan M. (Firma: Herr) (assiy2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibts denn schon wieder Neuerungen bezüglich des Themas?

Viele Grüße,
AssiY2K

Autor: Sdfseezzef S. (Firma: zerzer) (qsdsqdf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok guys,

According to their patent 
(https://docs.google.com/viewer?url=patentimages.storage.googleapis.com/pdfs/US20140337631.pdf), 
the golden target everyone should focus is the private key stored in the 
TM5. But to access it, it is required to get a living session on TM5 
(private key is to be encrypted for sure in the "offline" firmware).

Only solution I can see is to find an exploit (type buffer overflow) in 
communicating via USB interface or if using the cook-key, http packet 
crafting could also be a vector. What do you think, some of you are 
aldready on the deck? PM me.

Autor: Ikaro P. (ikaro_p)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Looks like this community is stuck, so I have decided to give us all a 
little present.

EiOJeNLiooqwWobaVDVrbJWLCifvQC5oDqNqHfuSYBt3y4vwN3YKq2EsvFK3U4M9 
(AES128)

Enjoy.

--Ikaro Psi

P.S. The security on this machine is very very impressive, I have pretty 
much never seen done anything this right and I do security for living, 
those engineers were thinking of every little detail. Sadly even them 
are only humans :)

Autor: Daniel V. (Firma: DJ) (daniel_ventura)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
woah, thank you man! :-)

Autor: Stephan M. (Firma: Herr) (assiy2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Ikaro,

Thanks for that. But what can we do with the key?

Best regards and have a great weekend,
AssiY2K

Autor: Daniel V. (Firma: DJ) (daniel_ventura)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
think this is the private key extracted from the fw ;-)
you can do almost everything on this machine with it.
for example digging for the ssl certs :-)

: Bearbeitet durch User
Autor: Mode M. (mode)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo kommt der Key her?
Ich kann nur empfehlen, den Key local zu speichern. Er wird hier ggfs. 
nicht lange öffentlich stehen.
Vielleicht ist es auch nur ein Fake....

Autor: Daniel V. (Firma: DJ) (daniel_ventura)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich gehe mal davon aus dass er den key (sofern es wirklich der private 
key der Maschine ist) irgendwie aus dem laufenden ram rausbekommen haben 
könnte. ich könnte mir vorstellen dass der thermi ein Silicon based 
security Konzept ähnlich wie zb bei spielkonsolen hat.
ps. es ist herzlich egal wo der key herkommt solange er valid ist ;-)

: Bearbeitet durch User
Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dann mal gespannt ob es hier weiter geht, leider kann ich nichts 
sinnvolles dazu beitragen :D

Autor: David N. (knochi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese Information sollte uns doch einen neuen Hebel geben. Also ich habe 
mal stumpf den Wikipedia- Artikel zu AES gelesen. Darin wird auf ein 
Tool verlinkt, welches sich AES-pipe nennt. In der Read.me steht was von 
verschlüsselten CD-ROMs, wenn mich nicht alles täuscht hatten wir doch 
Anfangs was von einem CD Laufwerk gesehen. Vielleicht kann man damit die 
Images von den Cook Keys ver- bzw. Entschlüsseln.

Link: http://loop-aes.sourceforge.net/

Habe im Moment wenig Zeit, probiert das mal jemand?

Bis denne

Knochi

: Bearbeitet durch User
Autor: Chris R. (chrisr2710)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Could you please explain what to do with this key?

I am not really familiar with encryption, but I think the key is too 
long for AES128 encryption. AES28 means 128 bit, but this key is 512 
bits long.

Can anyone give more details?

Autor: Martin P. (billx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ikaro P. schrieb:
> EiOJeNLiooqwWobaVDVrbJWLCifvQC5oDqNqHfuSYBt3y4vwN3YKq2EsvFK3U4M9
> (AES128)

Vom aussehen her hätte ich nun auf base64 plädiert.... aber so wirklich 
Sinnvoll ist das was ich da raus bekomme auch nicht.


0x12 0x23 0x89 0x78 0xd2 0xe2 0xa2 0x8a 0xb0 0x5a 0x86 0xda 0x54 0x35 
0x6b 0x6c 0x95 0x8b 0xa 0x27 0xef 0x40 0x2e 0x68 0xe 0xa3 0x6a 0x1d 0xfb 
0x92 0x60 0x1b 0x77 0xcb 0x8b 0xf0 0x37 0x76 0xa 0xab 0x61 0x2c 0xbc 
0x52 0xb7 0x53 0x83 0x3d

Mhm was könnte denn an KDF hier sinnvoll sein?
Vielleicht wird wirklich einfach sowas wie dm-crypt verwendet?

: Bearbeitet durch User
Autor: Waldemar H. (vual)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,
hat jemand die Richtigkeit des veröffentlichten Keys bereits in 
irgendeiner Weise verifiziert?

Ich kann da leider nicht helfen, da ich mich damit leider nicht auskenne

Gruß

Autor: Moritz M. (mom)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

kurz nachdem hier ein Thermomix Einzug hielt und ich rausfinden wollte, 
was da drin ist und wie denn das WLAN funktioniert, stieß ich auf diesen 
Thread.

Mir selbst ein Bild zu machen, wurde mir untersagt, aus der Angst den 
Thermomix zu zerforschen.

Nun habe ich kürzlich den Dichtungsring vergessen und das Innenleben mit 
Milch geflutet. So war meine Chance gekommen und ich konnte doch mal 
schauen.

Im Nachhinein sah ich, dass das Meiste hier schon besprochen wurde. Aber 
der Vollständigkeit halber hier noch was zur Steuerplatine:

Dort gibt es einen STM32F100R8 mit unbestücktem JTAG-Connector und einen 
ATxmega16D4.

Ich habe es noch etwas ausgeführt und Bilder gibt es auch[1].

Grüße Moritz

[1]: 
https://nerdgenieur.tumblr.com/post/166890591787/i-accidentally-the-thermomix

Autor: Stephan M. (Firma: Herr) (assiy2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Moritz,

Danke für deinen klasse Beitrag. Ich habe mir deinen Blog mal 
ausführlich durchgelesen. Macht Spaß :-)

Bleibt die Frage, wie man jetzt in das System vom TM5 kommt?

Viele Grüße,
Stephan

Autor: Moritz M. (mom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Stephan. Einziges Manko: die Frequenz mit der ich dazu komme, neue 
Beiträgen zu schreiben.

TM5 System: keine Ahnung.

Mein Ansatz wäre wahrscheinlich mal die Testpads auf dem Mainboard zu 
untersuchen ob da vielleicht eine UART dabei ist und CN601 genauer 
anzuschauen, ob das wirklich USB ist.

Sonst fällt mir noch ein, den äußeren USB Anschluss ohne den 4 poligen 
Kontaktstecker zu testen, nicht dass der TM5 daran doch was erkennt nur 
wird der äußere Stecker vielleicht nicht ordentlich aktiviert (mangels 
korrekt platziertem Magneten). Und dann mit USB-Lan Adapter testen.

SOnst könnte man auch den USB-Traffic zwischen Cook-key und TM 
anschauen, aber keine Ahnung was das für neue Erkenntnisse bringen 
würde.

Du siehst, einen richtigen Plan habe ich nicht.

Und um irgendwas mit dem vermeintlichen Private Key aus 
Beitrag "Re: Thermomix Rezeptchips" zu 
machen, fehlen mir die Skills.

Autor: Stephan M. (Firma: Herr) (assiy2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Moritz,

Das gleiche Problem habe ich auch, mir fehlen die nötigen Skills und die 
Zeit. :-(

Viele Grüße,
Stephan

Autor: Ikaro P. (ikaro_p)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
I can has firmware dump?

https://uloz.to/!6LxjhQYGAnoY/1-squashfs

Beitrag #5196357 wurde vom Autor gelöscht.
Autor: Daniel V. (Firma: DJ) (daniel_ventura)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thx man!!!!

Autor: Julian W. (julian-w) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mir das Image mal heruntergeladen, scheint tatsächlich authentisch 
zu sein unter opt findet sich einiges interessantes...

Autor: Thomas H. (decafbad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieht echt interessant aus - kann man das vielleicht irgendwie über qemu 
zum laufen bringen und dann die Chips anschließen? Ab dem Moment müsste 
man ja ins System eingreifen können, da man dort Tastatur und tty 
Zugriff haben müsste...

Welche Firmware ist das? Die aktuelle vom Cook Key oder die „alte“?

Autor: Philipp L. (philippl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thx! Echt nette informationen. in netlink finden sich sehr interessante 
Abläufe. wie wohl so ein DEBUG COOKIE aussieht?
philipp

Autor: Thomas H. (decafbad)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde auf VM oder emulation gehen. Mir sind auch noch Zertifikate in 
der Firmware aufgrfslllen...

Autor: Chris R. (chrisr2710)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann jemand mal bitte ein paar mehr Infos geben, wie man mit der Datei 
umgeht? Welches Programm benötige ich (Windows)? Oder geht nur Linux?

UPDATE: hat sich erledigt! 7Zip ist die Lösung zum entpacken des 
Verzeichnisses ;-)

: Bearbeitet durch User
Beitrag #5197528 wurde vom Autor gelöscht.
Autor: Marco H. (marco_h883)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Wow also der Firmwaredump "liest" sich wirklich spannend. Ich bin da
zwar persönlich nicht ausreichend im Thema um beurteilen zu können, ob
man durch die Veröffentlichung des Dumps demnächst eigene Rezepte
hochladen kann, aber spannende Dinge habe ich trotzdem gefunden:

- Unser TM5 heißt an vielen Stellen in der Firmware TM41 (siehe
/etc/rc/rc.conf: export HOSTNAME="tm41")

- Es gibt einen Debug Modus, der Telnet und FTP Server aktiviert (siehe
/etc/rc/rc.local:
# Defines what shall be done for Debug and Release builds of TM5
# Possible values: 1 - for  debug | 0 - for release. Are switched by
build system during build.
# Default value for build system is "1 - for debug" (for LTIB builds
used by developers))

- Es gibt einen Supervisor Modus der gestartet wird, wenn keine Serial
Number "eingebrannt" wurde (/opt/Thermomix/Thermomix.sh)

- der o.g. angebliche AES128 Key liegt unter /opt/cookey.txt (kein
Tippfehler meinerseits...)

- unter /tmp/certificates liegt ein "client_TM5" Zertifikat mit privatem
Schlüssel.

Autor: Stephan M. (Firma: Herr) (assiy2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Marco,

Vielen Dank für deine Forschungen, das sind schon mal hilfreiche Infos 
:-)



Gruß,
Stephan

Autor: Moritz M. (mom)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Danke allen Beteiligten, das sieht ja alles spannend aus.

Hat denn jemand eine Idee, wie man den FTP oder Telnet Server nutzen 
kann?

Bei einem USB-Anschluss in einem Auto hörte ich davon, dass man mit 
einem USB-LAN-Adapter zum Ziel kam und sogar eine IP per DHCP vom Auto 
bekam.

Ich habe in
/etc/rc.d/init.d/usbpower
 noch Folgendes gefunden:
#!/bin/sh

if [ "$1" = "stop" ]
then
    echo "PowerOff USB"
    echo 85 > /sys/class/gpio/export
    echo out > /sys/class/gpio/gpio85/direction
    echo 1 > /sys/class/gpio/gpio85/value
    echo 85 > /sys/class/gpio/unexport
fi

if [ "$1" = "start" ]
then
    echo "PowerOn USB"
    echo 85 > /sys/class/gpio/export
    echo out > /sys/class/gpio/gpio85/direction
    echo 0 > /sys/class/gpio/gpio85/value
    echo 85 > /sys/class/gpio/unexport
fi


Damit wird bei "start" ein ein GPIO Pin auf low gezogen, bei "stop" auf 
high. Ich vermute, dass damit der externe USB-Anschluss eingeschaltet 
wird, getriggert durch den Magnet im Rezept-Chip.

Autor: Moritz M. (mom)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Ikaro P. schrieb:
> I can has firmware dump?
>
> https://uloz.to/!6LxjhQYGAnoY/1-squashfs

Thanks a lot for your effort.

How did you extract the firmware?

Do you know if U-Boot is used as bootloader?

Autor: Sigma P. (sigmapic)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ikaro P. schrieb:
> I can has firmware dump?
>
> https://uloz.to/!6LxjhQYGAnoY/1-squashfs

Thank very much for that dump.

Please, can you tell me how di you extract it ?

I successfully uncompress the file system.
There are a lot of interesting things but the most important one is the 
binary /user/sbin/checkimg.

I successfully emulated the ARM926EJ-S processor (processor from TM5) 
with Qemu.
I ran checkimg and the result is:
Wrong aguments. Please use one of following commands:

To decrypt single pack file with embedded public key:
(Note: filename passed as packfile must be one of 3 possible
filenames: firmware.pack, data.pack, extra.pack)
    checkimg -d <in_bundlefile> <out_packfile>

Print SW version info:
    checkimg -i <in_bundlefile>

Verify consistency of an image only:
    checkimg -c <in_bundlefile>

I already started to analyse this binary with a disassembler.
I think a lot of our questions is inside this binary.
The good thing is that it has almost no dependencies.

Let's start to work on it.

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

The second interesting thing is the script /opt/app.sh and especially 
the function update_data_partition() that show the data process.

Autor: Chris R. (chrisr2710)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ikaro Psi, great work!! Thank you!

How can we get the image from our TM5 ourselves?? This would help the 
most!

Autor: David N. (knochi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

also auf meinem WIndows PC mit 7-ZIP bekomme ich zahlreiche Daten-Fehler 
beim entpacken des Images... Das würde erklären, warum das Image im 
Emulator nicht läuft. Ist das bei euch auch so?

Interessant ist auch das Verzeichnis /opt/Thermomix/automated_receipes/

hier liegen.xml Dateien der integrierten Rezepte.. da kann man schon mal 
gucken, wie die aufgebaut sind. Vielleicht findet man ja auch einen Weg, 
wie der TM5 die Rezepte unverschlüsselt über einen beliebigen USB Stick 
(oder WLAN Stick) annimmt. Wäre doch das einfachste?!

Bis denne
David

: Bearbeitet durch User
Autor: David N. (knochi)
Datum:

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

Hey Sigma,

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




Thanks
David

Autor: David N. (knochi)
Datum:

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

Findet sich übrigens in /opt/cookey.txt

Autor: Sigma P. (sigmapic)
Datum:

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

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

Then, access through ssh.

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

Autor: Chris R. (chrisr2710)
Datum:

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

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

Autor: Chris R. (chrisr2710)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch ein Ansatz wäre, etwas mit dem Key in der /opt/cookey.txt zu 
entschlüsseln. Dafür habe ich mal in allen Dateien nach "cookey.txt" 
gesucht. In der Datei /usr/sbin/netlink habe ich folgenden Code 
gefunden. Könnte der dafür genutzt werden, um die Daten des USB-Sticks 
der sich im Cookkey befindet zu entschlüsseln?
------------ Power-cycling USB interface ----------
/etc/rc.d/init.d/usbpower stop
/etc/rc.d/init.d/usbpower start
mkdir -p /tmp/dev/
mknod /tmp/dev/ttyACM0 c 166 0
/usr/sbin/eth stop
settings_cloud.sdb material/photo/150x150/vorwerk_trademark_logo.png
umount -f
losetup -d
rm -f
rmdir
/usr/sbin/eth start
mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ mkfs.ext4
tcsetattr usbTermio /sys/ /idVendor i j q u z rm -f /tmp/dev/ sd /../../../../../../../serial sr s.+(\d+) sd([a-z])\d+
mknod -m 644 /tmp/dev/loop b 7
mknod -m 644 /tmp/dev/ b 11 b 8
mkdir -p
losetup -e aes128 -P /opt/cookey.txt
mount -o ro
mount

Autor: Dirk K. (d-k)
Datum:

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

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

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

Autor: Sigma P. (sigmapic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris R. schrieb:
> Noch ein Ansatz wäre, etwas mit dem Key in der /opt/cookey.txt zu
> entschlüsseln. Dafür habe ich mal in allen Dateien nach "cookey.txt"
> gesucht. In der Datei /usr/sbin/netlink habe ich folgenden Code
> gefunden. Könnte der dafür genutzt werden, um die Daten des USB-Sticks
> der sich im Cookkey befindet zu entschlüsseln?
>
>
> ------------ Power-cycling USB interface ----------
> /etc/rc.d/init.d/usbpower stop
> /etc/rc.d/init.d/usbpower start
> mkdir -p /tmp/dev/
> mknod /tmp/dev/ttyACM0 c 166 0
> /usr/sbin/eth stop
> settings_cloud.sdb material/photo/150x150/vorwerk_trademark_logo.png
> umount -f
> losetup -d
> rm -f
> rmdir
> /usr/sbin/eth start
> mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ 
> mkfs.ext4
> tcsetattr usbTermio /sys/ /idVendor i j q u z rm -f /tmp/dev/ sd 
> /../../../../../../../serial sr s.+(\d+) sd([a-z])\d+
> mknod -m 644 /tmp/dev/loop b 7
> mknod -m 644 /tmp/dev/ b 11 b 8
> mkdir -p
> losetup -e aes128 -P /opt/cookey.txt
> mount -o ro
> mount
> 


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

A also started to analyse this binay.

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

Note: It would be great if you can speak english

Autor: Dirk K. (d-k)
Datum:

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

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

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

Autor: David N. (knochi)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hi,

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

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

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

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

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

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

Cu
David

Autor: Chris R. (chrisr2710)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
The code I found in /usr/sbin/netlink is of course not usable. But I 
thought to post it, because it reveals details about how to mount the 
encrypted Cook-Key. But I don't have the skill to mount the encrypted 
image. There is a file called "tm5.img" on the Cook-Key as written in
mount -t ext4 -o noatime,commit=2,data=journal tm5.img material/ mkfs.ext4

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

: Bearbeitet durch User
Autor: Daniel S. (schuballaa)
Datum:

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

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

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

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

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

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

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

Autor: Ikaro P. (ikaro_p)
Datum:

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

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

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

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

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

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

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

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

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

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

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

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

: Bearbeitet durch User
Autor: Joachim S. (oyo)
Datum:

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

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

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

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

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

No recipes seem to be stored in these files though. The most interesting 
information I could find in these files were the following tables:
Table "settingsCloudApp" in file "settings_cloud_default.sdb":
id|remoteAddress|TCPPort|remotePath|pingAddress
1|css.tmecosys.com|443|/ws|l.root-servers.net
which suggests URL https://css.tmecosys.com:443/ws

Table "settingsCloudAppDebug" in file "settings_cloud_default.sdb":
id|mac|ssn|serial|version
1|AABBCCDDEEFF|0123456789ABCDEF|00000000000000000|203801010000

Table "settingsCloudApp" in "settings_empty_en.sdb":
id|remoteAddress|TCPPort|remotePath
1|css.tmdesync.com|3080|/ws.ashx
which suggests URL https?://css.tmdesync.com:3080/ws.ashx

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

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

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

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

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

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

Autor: Sigma P. (sigmapic)
Datum:

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

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

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

Why, IDA Pro is perfect for that.


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

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

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

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

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

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

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

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

Have fun!


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

Autor: Moritz M. (mom)
Datum:
Angehängte Dateien:

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

Where did you find this information?

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

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

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

Edit: attached pics to post.

: Bearbeitet durch User
Autor: Moritz M. (mom)
Datum:
Angehängte Dateien:

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

: Bearbeitet durch User
Autor: Joachim S. (oyo)
Datum:
Angehängte Dateien:
  • tm5.sh (4,07 KB, 132 Downloads)

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

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

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

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

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

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

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

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

Autor: Sigma P. (sigmapic)
Datum:

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

Well done!

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

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

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

Do you have some ideas ?

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

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

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

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

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

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

dlink1 "dlink-8B91" "zubnw96594"

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

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

: Bearbeitet durch User
Autor: Joachim S. (oyo)
Datum:

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

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

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

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

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

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

Autor: Bimby T. (bimby)
Datum:

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

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

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

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

: Bearbeitet durch User
Autor: Moritz M. (mom)
Datum:

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

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

Autor: Bimby T. (bimby)
Datum:

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

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

Autor: Joachim S. (oyo)
Datum:

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

Pretty much, yeah.

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

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

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

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

Autor: Moritz M. (mom)
Datum:

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

Autor: Bimby T. (bimby)
Datum:

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

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

Autor: Joachim S. (oyo)
Datum:

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

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

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

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

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

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

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

Autor: Sigma P. (sigmapic)
Datum:

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

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

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

Autor: Joachim S. (oyo)
Datum:

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

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

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

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

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

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

Autor: Sigma P. (sigmapic)
Datum:

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

I agree, chance is low.


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

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


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

Yep, I read it.


I don't know how to continue.

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

Autor: Sigma P. (sigmapic)
Datum:

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

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

I'm sure we shoudld get Thermomix Kernel.

Autor: Sigma P. (sigmapic)
Datum:

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

Autor: Joachim S. (oyo)
Datum:

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

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

> I don't know how to continue.

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

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

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

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

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

What do you and the others think about this?

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

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

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

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

: Bearbeitet durch User
Autor: Sigma P. (sigmapic)
Datum:

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

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


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

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

Autor: Sigma P. (sigmapic)
Datum:

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

Hello Knochi,

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

Autor: Sigma P. (sigmapic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Does somone already success to clone a cookie ?

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

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

I am right?

Autor: Fabian O. (fabiiian)
Datum:

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

Autor: Sigma P. (sigmapic)
Datum:

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

Please, can you share kernel patches from Vorwerk CD.

Autor: Fabian O. (fabiiian)
Datum:

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

Send me a PM

Autor: Boe C. (boe_c)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Hallo zusammen,

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

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

Das habe ich mal versucht (*zum Nachahmen sollte man wissen was man 
tut*)
1. qemu installieren und Kernel/initrd, der oben erwähnt ist downloaden
2. squashfs unter linux mounten (auf /mnt/thermomix)
3. 128MB - Raw-Harddisk erstellt
dd if=/dev/zero of=thermomix.raw bs=1024 count=128k
4. mittels cfdisk thermomix.raw das Image partitioniert
   Ich hab da 2 Partitionen erstellt
   p1) 19MB für Squashfs (hab dann gemerkt das es sinnlos ist)
   p2) 50MB ext3  (hier ist dann das rootfs drin)
5. mit "kpartx -a thermomix.raw" das Image als loop-harddisk 
"registrieren"
   Danach kann p1 und p2 als
   /dev/mapper/loop0p1 und /dev/mapper/loop0p2  (oder loop1..)
   angesprochen werden
6. mkfs vom rootfs und mount
mkfs.ext3 /dev/mapper/loop0p2
mount /dev/mapper/loop0p2 /mnt/thermomixext3
7. rsync
rsync -av /mnt/thermomix/ /mnt/thermomixext3/
Da ist mir aufgefallen, dass das squashfs GENAU bei der /bin/busybox 
einen io-Fehler hat und rsync nur diese Datei nicht kopiert.
[ 2780.290452] SQUASHFS error: Unable to read data cache entry [135cd]
[ 2780.290456] SQUASHFS error: Unable to read page, block 135cd, size 14359
Die Datei ist für das Funktionieren des Images aber nötig.

8. Debian busybox-static nach /mnt/thermomixext3/bin/busybox kopieren
   und zwar die Version von 
https://packages.debian.org/wheezy/busybox-static
   die hat keine glibc-Abhängigkeiten, die sonst - bei falscher Version 
- das
   Booten verhindern
9. unmount/usw
   umount /mnt/thermomixext3 
   kpartx -d thermomix.raw
10. qemu starten
    qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile \
                        -initrd initrd.img-2.6.32-5-versatile \
                        -hda thermomix.qcow2 \
                        -append "root=/dev/sda2" \
                        -redir tcp:2200::22

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

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

Vg

boecko

Autor: Boe C. (boe_c)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hallo,

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

9b. Differenz-Image thermomix.qcow2
qemu-img create -b thermomix.raw -f qcow2 thermomix.qcow2

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

vg

: Bearbeitet durch User
Autor: Boe C. (boe_c)
Datum:
Angehängte Dateien:

Bewertung
7 lesenswert
nicht lesenswert
Hallo,

kleines Update: nachdem ich ein weitere Partition in thermomix.raw 
angelegt habe und
/etr/rc.d/rc.local auf
mount -t ext3 /dev/sda3 /mnt/rwfs/data
geändert habe, kommt man zumindest soweit wie im Bild

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

Einen guten Rutsch an alle

boecko

Autor: Stephan M. (Firma: Herr) (assiy2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin Boecko,

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

Frohes Neues Jahr!

Autor: Ed U. (eduardito)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo an alle,

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

Maybe /r/ThermomixHomebrew?

Autor: Schang S. (Firma: keine) (schang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

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

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

Thanks

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

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

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

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

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

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

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


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

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

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

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

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


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

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

ncb_version = 3

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


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


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

Autor: Moritz M. (mom)
Datum:

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

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

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

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

Autor: Thierry G. (thierry_g) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
You can see all specification of the cooki-key on fcc-id

https://fccid.io/2AGELCK1

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

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

Autor: Thierry G. (thierry_g) Flattr this
Datum:

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

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

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

Autor: Thierry G. (thierry_g) Flattr this
Datum:

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

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

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

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

Autor: Bimby T. (bimby)
Datum:

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

Hi Thierry,

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

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

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

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

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

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

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

: Bearbeitet durch User
Autor: F. K. (firstfacility)
Datum:

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

Autor: Jörg P. R. (jrgp_r)
Datum:

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

Autor: Thierry G. (thierry_g) Flattr this
Datum:

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

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

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

it's a great idea !

Autor: Fabian O. (fabiiian)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@last posts:

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

Autor: Bimby T. (bimby)
Datum:

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

Hi Fabian,

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

: Bearbeitet durch User
Autor: Markus H. (markusfooo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey Bimby,

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

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

: Bearbeitet durch User
Autor: Martin S. (sirnails)
Datum:

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

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

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

Autor: Bimby T. (bimby)
Datum:

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

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

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

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

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

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

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

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

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

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

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

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

file d3
d3: data



mkdir /tmp/d1
mkdir /tmp/d2

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

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

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

ls material/
binary  photo

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

ls |wc -l
206

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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



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

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

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

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

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

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

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

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


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


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

Autor: Stephan K. (stylon)
Datum:

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

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

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

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

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


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

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

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

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

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

Autor: Ikaro P. (ikaro_p)
Datum:

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

Autor: Bimby T. (bimby)
Datum:

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

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

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

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

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

Bewertung
5 lesenswert
nicht lesenswert
Update on cooksticks encryption:

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

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

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

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

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

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

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

Autor: Bimby T. (bimby)
Datum:

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

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

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

: Bearbeitet durch User
Autor: Stephan K. (stylon)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Good so see more activity here :-)

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

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

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

> [    0.800000] key_store: driver loaded

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

Autor: Stephan K. (stylon)
Datum:

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

Is it possible to share that emulator setup?

Autor: Sigma P. (sigmapic)
Datum:

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

I don't how to continue on my side.

Autor: Rui B. (rbarreiros)
Datum:

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

Best regards,

Autor: Andreas J. (dolar)
Datum:

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

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

https://uploadfiles.io/euabu

Autor: Gennadij D. (gennadij_d)
Datum:

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

Autor: Michael W. (mwulz)
Datum:

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

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

Autor: Alexander S. (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gennadij Degterjow: Interessante Idee.

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

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

Autor: Hans H. (Firma: kobs-ng) (haschhans)
Datum:

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

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

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

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


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

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

: Bearbeitet durch User
Autor: Thomas H. (thomashhh)
Datum:

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

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

Autor: Hans H. (Firma: kobs-ng) (haschhans)
Datum:

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

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

Autor: Bimby T. (bimby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ikaro P. schrieb:

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

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

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

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

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

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

Is it right? :)

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

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

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

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

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

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

Autor: Bimby T. (bimby)
Datum:

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

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

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

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

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

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

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

Autor: Bimby T. (bimby)
Datum:

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

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

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

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

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

Autor: Bimby T. (bimby)
Datum:

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

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

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

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

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

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

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

Autor: Julian W. (julian-w) Benutzerseite
Datum:

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

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

Autor: Moritz M. (mom)
Datum:

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

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

But maybe they are faster now ;)

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

Autor: Moritz M. (mom)
Datum:

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

Autor: Moritz M. (mom)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian W. schrieb:

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

I would be in.

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

Autor: Bimby T. (bimby)
Datum:

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

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

Autor: Bimby T. (bimby)
Datum:

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

There you go:

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

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

: Bearbeitet durch User
Autor: Moritz M. (mom)
Datum:

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

Nope, seems to be different:
╰─$ sha1sum tm5_2.3.tgz 
797380a69303a49e0267f0ec453395fc55b4c849  tm5_2.3.tgz
╰─$ md5sum tm5_2.3.tgz 
5d15bf2ec5c23e839073e335f90d437d  tm5_2.3.tgz

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


Autor: Schang S. (Firma: keine) (schang)
Datum:

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

Autor: Bimby T. (bimby)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moritz M. schrieb:

>
> So what about the files itself:
>

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

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

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

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

Thanks!

Autor: Matthias L. (malo)
Datum:

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

Thanks!

Autor: Bimby T. (bimby)
Datum:

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

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

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

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

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

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

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

And then run qemu

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

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

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


Good luck !

Autor: Bimby T. (bimby)
Datum:

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

No problem... :)

: Bearbeitet durch User
Autor: Bimby T. (bimby)
Datum:

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

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

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

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

Autor: Bimby T. (bimby)
Datum:

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

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

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

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

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

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

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

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

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

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


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



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

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

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

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

Autor: Matthias L. (malo)
Datum:

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

Autor: Bimby T. (bimby)
Datum:

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

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

Autor: Schang S. (Firma: keine) (schang)
Datum:

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

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

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

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

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

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

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

Autor: Hans H. (Firma: kobs-ng) (haschhans)
Datum:

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

: Bearbeitet durch User
Autor: Therm0m1x X. (therm0m1x)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hi all,

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

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

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

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

Cheers.

Autor: Therm0m1x X. (therm0m1x)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
I forgot to mention somebody already published the sources already on 
github:

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

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

Autor: Hans H. (Firma: kobs-ng) (haschhans)
Datum:

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

Autor: Bimby T. (bimby)
Datum:

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

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

Autor: Matt C. (thermomatt)
Datum:
Angehängte Dateien:

Bewertung
9 lesenswert
nicht lesenswert
[Auf Deutsch unten]

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

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

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

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

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

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

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

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

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

Happy hacking :)

---

[Entschuldigung für Fehler in meinem Deutsch.]

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

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

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

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

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

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

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

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

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

Happy hacking :)

Autor: Schang S. (Firma: keine) (schang)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Great work !

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

Were you able to successfully run it in qemu ?

Autor: Matt C. (thermomatt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Schang,

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

Matt

Autor: Johannes B. (johannesbehr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Matt C,

sehr sehr gute Arbeit!

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

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

very very great work!

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


Viele Grüße
Johannes

Autor: Alexander H. (alexander_h390)
Datum:

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

Autor: Matthias L. (malo)
Datum:

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

Autor: Víctor O. (vctor_o)
Datum:

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

Autor: Sigma P. (sigmapic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello everybody,

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

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

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

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

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

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

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

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


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

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

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

Can you tell me if my understanding is good ?

Autor: Matt C. (thermomatt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Xeno 2. (xeno22)
Datum:

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

Autor: Hans H. (Firma: kobs-ng) (haschhans)
Datum:
Angehängte Dateien:

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

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

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

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

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

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

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

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

: Bearbeitet durch User
Autor: Matt C. (thermomatt)
Datum:

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

Autor: Hans H. (Firma: kobs-ng) (haschhans)
Datum:

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

Autor: Matt C. (thermomatt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> For what did they made a patent then?

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

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

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

Matt

Autor: Hans H. (Firma: kobs-ng) (haschhans)
Datum:

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

Autor: Matt C. (thermomatt)
Datum: