Forum: Offtopic Thermomix Rezeptchips

Kevin K. schrieb:
>> Wie woanders schon mal angenommen, könnte ich mir aber auch gut
>> vorstellen, das es sich hier nur um Testdaten aus der Fabrik des Flash
>> Speichers handelt, die einfach noch nicht überschrieben wurden.
> Denke ich auch - eine Signatur über die gesamten 2,6 o. 4GB zu prüfen
> würde zu lange gehen. Wer lange Weile hat, kann in einem Image mal einen
> Solchen Bereich mit hallo123 vollschreiben ;)

Bin ich gerade bei ***grins*** ...

Also...

Habe nun mehrere Verbatim Clip-it Sticks getestet.
Bisher habe ich mit dem 4GB mit SM3257ENLT Chip gearbeitet.
Nun habe ich einen 4GB mit SM3257ENAA, der funktioniert genau so gut.
Einen 2GB mit SM3211BC1 Chip habe ich nun auch testen können. 
Funktioniert genau so gut!

An den SMI Tool Einstellungen habe ich heute auch herrum gespielt:
Das einzige was vom Thermomix geprüft wird, ist die Seriennummer.
Habe den Rest der Einstellungen vor dem beschreiben eingelesen und in 
die .ini Datei eingetragen (und somit unverändert gelassen) um dies zu 
testen.

Desweiteren habe ich die Imagegröße auf erst auf 1GB geschrumpf und den 
Rest mit Nullen überschrieben...hat er auch einwandfrei gelesen.
Danach habe ich die magische Adresse 0x808000 gefunden, die weiter oben 
im Thread schonmal angesprochen wurde. Vor dieser Adresse befindet sich 
ein Block voll Nullen. Danach folgen Daten, die sich ständig auf dem 
Rest des Stick mehr oder weniger zufällig wiederholen.

Und siehe da: Dem Thermomix reichen die 8.421.376 bytes!
Der Rest ist Datenmüll auf dem Stick.

Was leider nicht geht, ist irgendwo Daten zu ändern. Die 8MB werden 
ständig auf ihre Konsistenz geprüft und es folgt sofort eine 
Fehlermeldung.

Hier übrigens mein Setup.

Wow das sieht ja richtig klasse aus.
Woraus hast du denn die Sachen gebaut?
3D Drucker?

Ach übrigens Amazon verkauft auch die Sticks.
Leider funktionieren die nicht.
Es handelt sich bei den Sticks um Appotech DM233 Controller.
Der Chip ist aber ganz genau so groß wie der im Thermomix Chip.


Darf ich fragen wie du deine her hast?

Alexander Schäfer schrieb:
> Wow das sieht ja richtig klasse aus.
> Woraus hast du denn die Sachen gebaut?
> 3D Drucker?
>
> Ach übrigens Amazon verkauft auch die Sticks.
> Leider funktionieren die nicht.
> Es handelt sich bei den Sticks um Appotech DM233 Controller.
> Der Chip ist aber ganz genau so groß wie der im Thermomix Chip.
>
>
> Darf ich fragen wie du deine her hast?

Die Teile habe ich an der 2,5D Fräse gemacht aus PVC.

Meine Sticks habe ich von eBay. Reichelt hat die auch. Ich habe mir die 
Modelnummern notiert:
Verbatim#43905 1010-177 für den 2GB Stick in Oliv
Verbatim#43910 1103-177 für den 4GB Stick in Pink

Hast du mal auf dem Russischen Forum geschaut, ob du eine Software für 
den Controller findest? Wie gesagt, du musst nur Seriennummer ändern 
können und eine Autostart Image drauf flashen.

Auf der russischen Seite hatte ich nichts gefunden.
Auf einer chinesischen Seite war eine Software für den Chip.
Da aber mein Chinesisch sich in Grenzen hält, habe ich es nicht mal 
runter geladen bekommen.
Das hatte ich aber gestern schon probiert und wusste nicht dass es auch 
mit anderen funktioniert. Daher hatte ich auch nicht ganz so viel Mühe 
rein gesteckt. Werde es aber noch mal probieren und wenn ich Glück hatte 
berichten.
Da mein Rezept Chip ganz sicher defekt ist wäre es klasse wenn ich nur 
den Chip tauschen könnte. Ich habe mir auch schon überlegt einen 
günstigen Rezept Chip zu bestellen (ebaykleinanzeigen) und ihn dann zum 
basteln zu benutzen. Hab zwar schon drei hier liegen, kann aber diese 
nicht noch mal riskieren kaputt zu machen.

Hallo Leute,

danke erstmal an alle in dem Thread für die Infos und Hartnäckigkeit an 
dem Thema!

Ich habe auch heute meinen Thermomix bekommen. Gleich auch damit 
gekocht. Genial das Teil. Ich habe mit meiner Frau 50/50 gemacht so sind 
das nicht so viel Geld für jeden. Egal - Sparen dann geht sichs aus.

Das mit dem USB ist cool. Auch die Neuigkeiten, dass anscheinend dass 
das Modell des Sticks relativ egal zu sein scheint.
Hat schon jemand mit einem anderen Modell mal das gleiche versucht?

Anscheinend scheint es ja nur die Daten am Stick bis zur Adresse 
0x808000 und die Seriennummer wichtig sein.

Weiter oben wurde ja mal über WLAN usw.. diskutiert. Hat schon jemand 
mal versucht einen WLAN Stick an den Thermomix zu hängen?
Mit dem Adapter unten von Carlos B. würde das ja gut klappen. Auch 
Tastaturen usw... oder auch einen USB/RS232 Wandler?

Ein Freund hat einen 3D Drucker, wir werden mal versuchen sowas in 3D zu 
printen und dann kann ich auch mit etwas USB - Material testen. 
Einstweilen kann ich euch nur danken und das Thema weiter verfolgen ;-)

gruss aus Österreich

Alexander Schäfer schrieb:
> Auf der russischen Seite hatte ich nichts gefunden.
> Auf einer chinesischen Seite war eine Software für den Chip.
> Da aber mein Chinesisch sich in Grenzen hält, habe ich es nicht mal
> runter geladen bekommen.
> Das hatte ich aber gestern schon probiert und wusste nicht dass es auch
> mit anderen funktioniert. Daher hatte ich auch nicht ganz so viel Mühe
> rein gesteckt. Werde es aber noch mal probieren und wenn ich Glück hatte
> berichten.
> Da mein Rezept Chip ganz sicher defekt ist wäre es klasse wenn ich nur
> den Chip tauschen könnte. Ich habe mir auch schon überlegt einen
> günstigen Rezept Chip zu bestellen (ebaykleinanzeigen) und ihn dann zum
> basteln zu benutzen. Hab zwar schon drei hier liegen, kann aber diese
> nicht noch mal riskieren kaputt zu machen.

Wie hattest du deinen Chip kaputt gekriegt?
Falsches ISP aufgespielt, oder Inhalt gelöscht?

Carlos B. schrieb:
> Wie hattest du deinen Chip kaputt gekriegt?
> Falsches ISP aufgespielt, oder Inhalt gelöscht?

Wie ich oben gelesen habe mit dem Hersteller Tool von SMI. Beim Auslesen 
wenn ich mich nicht irre...

Aber wie es scheind könnte er ja mit dem Dump oben den Stick wieder 
reparieren ;-)

Ich habe ihn zuerst gelöscht und danach frittiert.
Als du geschrieben hast das man es wieder hin bekommt, habe ich mich 
wieder an den Rechner gesetzt und den Chip mit meinen selbstgebautem 
Clip verbunden. Irgend was ging aber schief und der Chip wurde 
kurzgeschlossen. Nach kurzer Zeit roch es relativ komisch....
Na ja ich werde mir wohl eine bessere Lösung für das auslesen des Chips 
bauen müssen.

@Knochi
In den Log werd ich bei Zeiten nochmal rein schauen!

Carlos B. schrieb:
> Hier übrigens mein Setup.

was sind das für Kontaktstifte die du da verwendet hast? Bekomm ich die 
bei Reichelt?

Ich habe mir vor einer Zeit diese hier bestellt:
http://www.amazon.de/Federkontakt-Block-1-reihig-6-pol-Ladekontakt-Schnittstellenkontakt/dp/B00OOS2BBA/ref=sr_1_1?ie=UTF8&qid=1423865934&sr=8-1&keywords=Federkontakt-Block+1-reihig+6-pol

Vielleicht kann man die auch als Kontaktstifte für den Chip benutzen.

Alexander Schäfer schrieb:
> Ich habe mir vor einer Zeit diese hier bestellt:
> 
http://www.amazon.de/Federkontakt-Block-1-reihig-6-pol-Ladekontakt-Schnittstellenkontakt/dp/B00OOS2BBA/ref=sr_1_1?ie=UTF8&qid=1423865934&sr=8-1&keywords=Federkontakt-Block+1-reihig+6-pol
>
> Vielleicht kann man die auch als Kontaktstifte für den Chip benutzen.

Oh. Die sind cool.
Meine sind von Fixtest. Kriege ich aber nur bei mir auf der Arbeit.
Privat kommt man da glaube ich schlecht dran.

Auf der Docking-Station habe ich eine präzisions Buchsenleiste genommen. 
Die gibts bei Reichelt.

Alexander Schäfer schrieb:
> [...]
> Ach übrigens Amazon verkauft auch die Sticks.
> Leider funktionieren die nicht.
> Es handelt sich bei den Sticks um Appotech DM233 Controller.
> Der Chip ist aber ganz genau so groß wie der im Thermomix Chip.

Hier das Gleiche - hatte mir von Reichelt je einen weissen und einen 
schwarzen ClipIt Stick schicken lassen beide hatten den Appotech 8233 - 
dachte zuerst mein virt. XP wuerde Aerger machen... Scheint wohl nicht 
so.

Werde mir die Appotech spez. Tools (DM8233_QCTool o. DM_UDiskAP) 
besorgen und ein bischen rumpielen - waere cool, wenn der TM nichtmal 
auf einen SMI besteht...


Schoenes WE!

-K

Carlos B. schrieb:
> Also...
>
> [...]
> Nun habe ich einen 4GB mit SM3257ENAA, der funktioniert genau so gut.
> Einen 2GB mit SM3211BC1 Chip habe ich nun auch testen können.
> Funktioniert genau so gut!
> [...]Das einzige was vom Thermomix geprüft wird, ist die Seriennummer.

Richtig geil! Der *ENAA ist inzw. glaub' leichter zu finden als der 
ENT...
Gute Arbeit - you just made my day!

> Desweiteren habe ich die Imagegröße auf erst auf 1GB geschrumpf und den
> Rest mit Nullen überschrieben...hat er auch einwandfrei gelesen.
> [...]
> Und siehe da: Dem Thermomix reichen die 8.421.376 bytes!
> Der Rest ist Datenmüll auf dem Stick.

Kann man eine 2. Part. (CDFS o. HDD) auf dem Stick anlegen und da was 
ablegen? :D

>
> Was leider nicht geht, ist irgendwo Daten zu ändern. Die 8MB werden
> ständig auf ihre Konsistenz geprüft und es folgt sofort eine
> Fehlermeldung.

Leider, aber das sollte auch noch zu schaffen sein ;)

Nochmal dickes Lob fuer dieses Etappenziel!

-K

Kevin K. schrieb:
> Kann man eine 2. Part. (CDFS o. HDD) auf dem Stick anlegen und da was
> ablegen? :D
>

2. Partition kann als Flashspeicher genutzt werden, solange der TM die 
Daten auf der ersten Partition findet.

Leider muss die erste Partition als CDFS angelegt werden. Was anderes 
ließt er nicht! Dummerweise ist diese dann schreibgeschützt und kann 
nicht mit WinHex o.Ä. nachbearbeitet werden (soweit ich testen konnte).

Ein weiteres interessantes Detail:
Bevor die Fehlermeldung auftritt, wird der Splashscreen des Rezeptchips 
angezeigt. Erst dann folgt die Fehlermeldung, kurz bevor der Rezeptindex 
angezeigt werden würde.
Ich habe die Daten erst ab Adresse 0x408000 (also etwa die 2. Hälfte) 
manipuliert. D.h. er ließt zumindest den Splashscreen ohne die folgenden 
Daten zu prüfen. U.U. habe ich auch Teil des Rezeptindex überschrieben. 
Wer weiss...

Weiss einer von euch zufällig die Auflösung des Displays des TM5?
Ich finde unter der Modellbezeichnung des Bildschirms nichts.

Habe mal ein wenig rumgerechnet:
Der Chip "Kochen hat Saison" hat von seinen 8.421.376 byte nur 3747840 
byte an Daten. Der Rest sind Nullen.
Auf dem Chip sind laut Rezeptindex 93 Rezepte. Das sind im Durchschnitt 
40,3KB an Daten pro Rezept.
Bei jedem Rezept ist mindestens ein "Vorschaubild" dabei. Falls das 
Display 800x480 pixel groß ist ist das Bild etwa geschätzte 250x250 
Pixel groß.
Ich habe mal gerade ein Foto auf diese Größe verkleinert und in 
verschiedenen Formaten konvertiert. Selbst bei 256 Farben ist das BMP 
62,5KB, das GIF hat 34,5KB, das JPG hat 21,3KB, das PNG 31,9KB. Das ist 
mindestens die Hälfte der Daten.

Hallo morpheus128,

20 Kb an Daten ist für ein Rezept mehr als ausreichend (inkl. 
Motorteuerung).
Ich habe spasseshalber mel ein Rezept von der Rezeptwelt in einen 
Texteditor kopiert. Ich habe die komplette Seite, also alles was auf der 
Seite so rumsteht (ohne Bilder), kopiert - das sind gerade mal 5 KB an 
Daten. Dann wird ja noch die Steuerung des TM benötigt. da sind weitaus 
weniger Daten nötig als im geasmten Rezept stehen.

Groszügig gerechnet werden das wohl nie mehr als 5 KB an Daten für 
Rezept + Steuerung sein.

LG

richi

Zu den SW-Paketen: Wenn da ein AVR auf der Steuerungseinheit sitzt 
(finde das Foto der Platine nicht mehr...), könnte avrdude für ein 
In-System-Update genutzt werden.

Moin,


ich habe mal rumgespielt - und jetzt einen sehr seltsamen ClipIt - muss 
wohl noch mehr spielen ;)
Ich muss dazu sagen, das mein XP eine VM ist - das koennte beim 
Auswerfen des Sticks am Bus Aerger machen...
Das Tool welches 'tat' war das Partitionierungstool von einer rus. Seite 
fuer den DM8233. Das will bei 'Settings' ein Passwort - man findet es in 
der partition.cfg als Kommentar.
Das Ding hat nur mehrere Nachteile.
- Die SerNr ist buggy - musste den Haken bei Dec. wegmachen, weil sonst 
nur Muell entsteht.
- Das Partitionieren ist 1.Part norm. Stick 2.Part CD (oder nur CD)
- Macht unter VM komische Sachen - schreibt den Controller, aber das 
Image nicht - kann man sich vorstellen was das im Ergebnis bringt ;) - 
Genau, ein READ-Only-FS mit nicht korrigierbarem Datenmuell...
- Das ganze Tool bleibt weit hinter den Moeglichkeiten des SMI - sollte 
der Chip Wurst sein, wuerde mir das trotzdem Wurst sein ;) SMI ist 
stressfreier ;)


-K

Es sind anscheinend nur die weißen und schwarzen Modele mit dem Appotech 
DM8322 bestückt (meine unbestätigte Vermutung).
Da fängt die Modellnummer mit einer 5 an (siehe Foto).
Hier noch der Link zu dem Model:
http://www.amazon.de/Verbatim-Clip-4GB-Speicherstick-weiß/dp/B00440D0G8/ref=pd_sim_sbs_computers_1?ie=UTF8&refRID=1K1351K2T5RH421DDZH3

Sicher ist aber das der Verbatim ‘Clip-It’ in zwei verschiedenen 
Varianten zu kaufen gibt. Der Stick mit dem Appotech DM8322 hat ein 
wesentlich kleineren Chip verbaut als die Variante mit dem sm3257enlt.
Zur besseren Verständnis habe ich noch zwei Fotos erstellt.
Hoffe ich konnte helfen ;-)

Alexander Schäfer schrieb:
> Es sind anscheinend nur die weißen und schwarzen Modele mit dem Appotech
> DM8322 bestückt (meine unbestätigte Vermutung).
> Da fängt die Modellnummer mit einer 5 an (siehe Foto).
Bei reichelt.de war die P/N (auf Packung) 43900 (weiss - schwarz 43901)
Ein von amazon.de heute angekommener hatte P/N 97555  (schwarz) - der 
hat aber leider auch keinen SMI, sondern einen 'ITE IT1176 A1BA' :( - 
bei diesem ClipIt sind allerdings die mitteleren 2 USB Kontakte schmaler 
als die Aeusseren - Chip gleich gross wie SMI...
Die Verpackung ist anders:
- Appo reichelt, kleiner Chip, kleinere Verpackung, das grosse Feld mit 
'Clip-it' 'USB DRIVE' ist weiss
- Amazon ITE, 'groesserer' Chip, groessere Verpackung, grosses Feld ist 
hier rot

> Hier noch der Link zu dem Model:
> 
http://www.amazon.de/Verbatim-Clip-4GB-Speicherstick-weiß/dp/B00440D0G8/ref=pd_sim_sbs_computers_1?ie=UTF8&refRID=1K1351K2T5RH421DDZH3
>
> Sicher ist aber das der Verbatim ‘Clip-It’ in zwei verschiedenen
> Varianten zu kaufen gibt.
Leider min. 3 jetzt...

Bei den Appos schauen zudem noch diese 2 winzigen Kontakte gerade so an 
der Kante vom Buegel raus - die fehlen beim SMI (oder sind weiter 
hinten? - der Appo hat da noch 2 groessere versteckt).

> Zur besseren Verständnis habe ich noch zwei Fotos erstellt.
Werde auch noch welche nachreichen...
> Hoffe ich konnte helfen ;-)

Ironie des Schicksals - ich hatte mir zum rumspielen einen 'Verbatim 
PinStripe 4GB' (schwarz) besorgt. Wollte mal andere Chips als den SMI 
probieren. Nun, die ClipIts waren dann Appo, aber der PinStripe stellte 
sich als 'SMI SM3257 ENLT'heraus :D (Verba. P/N ist 49061 ). Da ich mit 
'rumspielen' wollte, war mir der klassische 'Schiebestick'-Formfaktor 
egal...

Ein Verbatim 'Micro USB Drive 4GB' (P/N 44048) - entpuppte sich als 
Phison PS2251-67 (PS2267) - die Phison hatte ich als Zweitwahl gesetzt, 
weil deren Tools auch brauchbar aussahen.

-K

Ich kenne einen 'USB Stick Importeur' direkten Kontakten nach Asien. Bei 
Ihm kann man Sticks direkt mit Wunschchip bestellen. Soll ich mal 
anfragen? Welche Menge?

Da es wohl keinen Hersteller gibt der nur den einen Chip sondern immer 
wieder neue Chips je nach momentanen Preis verbaut ist eine genaue 
Aussage über die USB Sticks nicht möglich.
Entweder man bestellt eine große Menge über einen Importour oder man 
bestellt sich direkt einen Chip von Vorwerk.
Da ich absolut kein Interesse an Raubkopien habe werde ich mir einen von 
Vorwerk bestellen. Der Vorteil ist das man kein Gehäuse bauen muss und 
der Chip 100% richtig ist. Der günstigste Chip ist für 27€ zu bekommen. 
Weitere Suche nach einen funktionierenden USB Stick wird mich wohl mehr 
Geld kosten.

Alexander Schäfer schrieb:
> Da es wohl keinen Hersteller gibt der nur den einen Chip sondern immer
> wieder neue Chips je nach momentanen Preis verbaut ist eine genaue
> Aussage über die USB Sticks nicht möglich.
> Entweder man bestellt eine große Menge über einen Importour oder man
> bestellt sich direkt einen Chip von Vorwerk.
> Da ich absolut kein Interesse an Raubkopien habe werde ich mir einen von
> Vorwerk bestellen. Der Vorteil ist das man kein Gehäuse bauen muss und
> der Chip 100% richtig ist. Der günstigste Chip ist für 27€ zu bekommen.
> Weitere Suche nach einen funktionierenden USB Stick wird mich wohl mehr
> Geld kosten.

An dieser Stelle sei noch mal darauf hingewiesen, dass unser Ziel ist 
eigene Rezepte zu schreiben. Das Kopieren dient nur dazu, um 
herauszufinden welche Parameter stimmen müssen, damit der TM den Chip 
als Original erkennt. Also z.B. Seriennummer, Chipsatz etc.
IMHO lohnt sich das Kopieren auch nicht wirklich, wenn man bedenkt, dass 
man sich erst einen Adapter für USB Sticks bauen muss. Und die anderen 
Kochbücher fallen erfahrungsgemäß sowieso gegenüber dem Grundkochbuch 
stark ab.

Bis denne
Knochi

Ich stimme Alexander zu.
Da jetzt klar ist, woran man rumschrauben darf und woran nicht, kann man 
direkt an dem Originalchip arbeiten.
Eine Docking Möglichkeit braucht man so oder so. Entweder um den Stick 
an den TM zu bringen, oder halt um den Chip mit dem PC zu verbinden.
Das eine versteckte Partition o.Ä. noch auf dem Chip ärger bereitet, ist 
jetzt ausgeschlossen.

Also auf gehts: Verschlüsselung knacken!

Übrigens habe ich mir mal das vollständige Patent genau durchgelesen. 
Dort ist bereits alles erklärt womit wir es hier zu tun haben. 
Allerdings haben sie viele Möglichkeiten erwähnt und tatsächlich nur 
eine Kombination daraus umgesetzt. Die Frage ist nun welche und kann man 
diese umgehen/reproduzieren?
Ich tippe auf eine Kombination aus SHA-256 für die Hash Berechnung und 
RSA-Algorithmus für die Chifrierung.

Eigentlich war geplant, einen Teil des Sticks am PC lesbar zu machen. 
Das haben sie anscheinend geknickt, da man sonst super über eine 
Plaintext-Attacke den Code hätte knacken können...

Fabian O. schrieb:
> Ich kenne einen 'USB Stick Importeur' direkten Kontakten nach Asien. Bei
> Ihm kann man Sticks direkt mit Wunschchip bestellen. Soll ich mal
> anfragen? Welche Menge?

Hi Fabian - schön zu wissen; aber aus anderem Grund als vermutet...

Ein paar Chips herumliegen zu haben um zu testen und evtl. später 
strukturiert kochen zu können ist das eine (etwa einen Chip mit 'Menüs 
zum testen', einen mit 'lieblings Rezepten',...). Wie Knochi and Andreas 
aber schon meinten, sind Mengen einer Lieferung eines Importeurs 
allerdings wohl weit jenseits selbst einer grosszügigen Bestellung von 5 
Chips/User.

Ein paar Fehlkäufe kann man noch nutzen um zu lernen (Features anderer 
Hersteller, überhaupt den Umgang mit Controllerchips auf Sticks und 
damit verbundene Themen,...) - und wie die Beschreibungen zu den ClipIt 
Sticks wohl nicht zu vermeiden. Rein ökonomisch gesehen hat Andreas 
recht - mit ca. 20% Markanteil von SMI muss man so viele Sticks kaufen 
um Glück zu haben, das es sich tatsächlich eher lohnt gleich den Vorwerk 
Chip zu kaufen (min. 5 Käufe zu min. 8 Euro > billigster Chip).

Wenn aber der Importeur Tools besorgen kann, mit denen man am PC mit den 
Stickcontrollerchips direkt reden kann, dann wird's spannend 
('production tools'). Die meisten auf der russischen Seite(n) taugen für 
wenig mehr als die Ser/VId/PId zu setzen und evtl. ein ISO-Image 
hochzuladen. Firmware runterladen z.Bsp. ist meist nicht vorgesehen. 
Lustig wäre es etwa auch auf einem Stick 2 CDs zu haben. Oder die Daten 
der HDD als ISO zu exportieren - das würde einem ersparen jedes Mal ein 
ISO Image komplett hochzuladen wenn man nur ein paar Werte ändern will. 
Wenn das nicht öffentlich geht - schick mir einfach eine PM - solche 
Tools wären nicht nur für dieses Projekt für mich von Interesse.

Ich habe leider immer noch keinen TM, so das im Moment (noch) mehr Zeit 
für Grundlagenforschung bleibt ;)

Eine Erkenntnis eben derer: bei verschiedenen Sticks sind erhebliche 
Schwankungen in der Leitungsaufnahme am USB Port gemeldet worden - 
nichts gefährliches, aber bei der Entscheidung welchen der Clonechips zu 
benutzen vielleicht mit zu beachten.

So, da nun anscheinend klar das Seriennummer = legitimer Stick(?) ist, 
fehlt der nächste Schritt: ??? = legitime Daten.
Ich gehe davon aus, das entw. eine Prüfsumme abgelegt wird (wäre für uns 
cool) oder eine Signatur erstellt wird (erhebl. Aufwand das 
nachzustellen).
Evtl. kann man dann aus dem ??? schliessen was gemacht wird 
(md5,sha,..). Ich würde nochmal den Busmitschnitt durchgehen - ist da 
irgendwo ein Hinweis auf eine ziemlich kleine Menge Daten entw. gleich 
zu Anfang oder zum Ende zu finden?

Grüsse,

-K

Versteht mich nicht falsch, ich hatte dir den eindruck das sich hier 
viele mit der auswahl passender "Probiersticks" beschäftigten und wollte 
daher anbieten mich mal nach passenden Sticks mit garantiert richtigem 
Chip zu schauen - mehr nicht.

Ich denke die Verschlüsselung ist im Patent beschrieben. Privat und 
Puplic Key. Also einen Art PGP mit Zusätzlichem Salt in Form der Stick 
SN und damit wirds verdammt schwer. :'(

Nun, ich habe SHA-256 und RSA nicht ohne Grund genannt.
Im Patent werden zwar diverse Möglichkeiten erwähnt, aber explizit auf 
die beiden hingewiesen!
Es ist die Rede von der Verschlüsselung des Datenpakets bestehend aus 
der Seriennummer (2), der Rezeptdaten (4) und der Prozessdaten (5) für 
den TM, mit einer public/private Key fähigen Verschlüsselung. Und später 
wird noch ein Hash berechnet und zusätzlich auf dem Stick abgelegt.

Mal ne andere Sache die mir aufgefallen ist:
Ich habe mittlerweile drei verschiedene Chips analysieren können ("Das 
Kochbuch", "Wertvoll geniessen", "Kochen hat Saison"). Beim Vergleich 
sind mir zwei Blöcke aufgefallen, die bei allen drei Chips Identisch 
sind.
Der erste Block geht von 0x200 bis 0x89F und der zweite von 0xA00 bis 
0xBD7.
Auf den ersten beiden Chips sind die Blöcke jeweils um 16 Bytes länger 
und unterscheiden sich nur im Vergleich zum letztgenannten Chip.

Jemand eine Idee, was das für Daten sein könnten?!

Ich meine gelesen zu haben, das die Sticks von "Silicon Power" direkt 
von "Silicon Motion" gefertigt werden. Auf der russischen Seite wurde 
der "Silicon Power Touch T01" Stick erwähnt der den SM3257ENLT drin 
haben sollte. Daraufhin habe ich mir einen 8GB T01 gekauft. Der hatte 
aber einen anderen SMI Chip verbaut (ich meine SM3255AA o.Ä.).

Wäre unwahrscheinlich einen "Silicon Power" Stick mit nem Chip von einem 
anderen Hersteller drin zu finden, oder?!

Carlos B. schrieb:
> [...]
Irgendwie musste ich beim lesen eben dieser Stelle spontan an das alte 
Mac-OS Dateisystem denken:
> der Seriennummer (2), der Rezeptdaten (4) und der Prozessdaten (5) für

Die Rezeptdaten (4) sind der 'Resource fork' (klar lesbar auf CDFS)
Die Prozessdaten (5) der 'Programmcode' auf versteckt/verschl. Teil (was 
die SMIs hergegeben hätten).
Haben sie aber schlussendlich nicht so umgesetzt (anscheinend) - was 
wieder Hoffnung weckt.
So ist nämlich eben doch bekannter Klartext im Chiffrat enthalten 
(solange das vorher nicht komprimiert wurde...).

> den TM, mit einer public/private Key fähigen Verschlüsselung.
Ich glaube irgendwo auch sowas wie eine Anzahl an 'mitzuführenden' 
Schlüsseln gelesen zu haben. Das waren ziemlich viele - nur auf Vorrat 
um kompromittierte widerrufen zu können, oder stehen die im Zusammenhang 
mit etwa der Anzahl der gültigen Seriennummern?
> Und später
> wird noch ein Hash berechnet und zusätzlich auf dem Stick abgelegt.
Über diesen Punkt war ich ebenso gestolpert - wenn das Buch in einem 
Rutsch gelesen wird, ist wohl das Buch signiert/'hashed' (ich glaube 
weiter oben hatte jemand schon nur einzelne Bytes geändert und Fehler 
bekommen...). Allerdings haben wir diese Prüfsumme mWn noch nicht 
gefunden - kann man eigentlich die Seriennummer etwa des 'Saison' Chips 
in einen Stick packen, der mit 'Das Kochbuch' betankt wurde? Wäre schon 
mal eine Variable weniger ;)


VlG,

-K

Hi alle,

noch kurz: vielleicht sollten wir auch die zweite Front nicht ganz aus 
den Augen verlieren: der TM5 selbst.
Wenn tatsächlich starke Verschlüsselung mit ordentlich langen Schlüsseln 
benutzt werden, wäre es u.U. einfacher dem Gerät einen selbst 
generierten Schlüssel unterzujubeln. Allerdings müssten wir dann aber 
auch nach einem anderem Weg suchen, uns die Infos über den Aufbau eines 
Rezeptes und die passenden Steuerbefehle zu verschaffen. Könnte aber 
auch dort zu finden sein, wo man den Schlüssel einschleust - dort sind 
die Daten evtl. dann offen... Will heißen: Debugport etc ;)

Wir sollten an beiden parallel arbeiten - den Aufbau des Buches (wie 
Hashwert berechnen - und/oder wo Sign. ablegen) brauchen wir - wenn 
tatsächlich stark verschl. kommen wir evtl. am Gerät direkt schneller 
voran.

Zum Schluss was zum schmunzeln : ich habe irgendwo (in SoC-Beschr.?) was 
von OTG gelesen - sollte das implementiert sein, könnte es erlauben den 
TM5 als Gerät an etwa einem PC anzuschließen (auch für Debug? - TM5 ist 
dann Slave) sprich er wäre dann der
Thermo-Nukleare-RIESEN-USB-Stick :D ).



VlG,

-K

Carlos B. schrieb:
> [...]
> Auf den ersten beiden Chips sind die Blöcke jeweils um 16 Bytes länger
> und unterscheiden sich nur im Vergleich zum letztgenannten Chip.
>
> Jemand eine Idee, was das für Daten sein könnten?!
Brainstorming (bin immer noch ohne TM :( )
Gemeinsamkeiten:
Logo's?
Vor/Nachwort?
Eigenwerbung/Eula/Disclaimer/Warnung/...?

Tabellen-header/Dictionary?
* 2 Tabellen - Rezept und Steuerung
  - SQLite-Files?
  - Rezept Datei hat viele Felder (0x200 bis 0x89F)
  - Steuerung weniger Felder (0x0a00...)
  - Wo sind die Bilder zu Rezept dann?

1. Block 1695 bytes
2. Block 471 bytes

Pub/Priv Key?

16Byte = 128bit

Letzteres brachte mir einen langen Ausflug ein. Julien hatte 
ggaaaannnzzz weit oben ein paar gute Links und darauf fussend AES128b 
vermutet.
Klingt leider plausibel - leider, weil AES-128b im Prinzip sicher ist :( 
Features:
- No 'brute-force' - Rechenleistung eines sehr schnellen 2010 gebauten 
Rechners ist um Exponenten zu lahm um den Schlüssel innerhalb der 
bisherigen Lebenszeit des Universums zu berechnen
- Klartext Attacken wirkungslos

Mögliche Angriffsflächen:
- Schlechte Passwörter - Mensch 'erstellt' sie - hier eher nicht
- Es ist symetr. also kein pub/priv key - das was zum verschl. benutzt 
wurde ist das was man zum entschl. braucht
- Klartext möglich wenn mehrere bekannte Klartexte mit dem selbem 
Schlüssel (hier: versch. Chips)
- Es gibt inzw. 'indirekte' Angriffe - lauschen/timing in Prozessor 
cache etwa

Lichtblicke:
Konsequenz aus symtr. Verschlüsselung ist: sowohl bei der Produktion, 
als auch in dem TM5 muss der gleiche Schlüssel sein - einmal geknackt 
ist das Game-over - alle Chips alle TM5 haben denselben Schlüssel. Sehr 
riskant - aber zu umschiffen, indem man den Schlüssel asymetrisch 
verschlüsselt, und einfach beilegt
Blöderweise werden Klartext o. Cache Angriff nur möglich mit Zugang zum 
OS. für letzteres braucht man nicht einmal mehr root Rechte - bin aber 
noch nicht dahinter gestiegen, ob das auf für Dateien entschl. klappt - 
(Funk-)Netze ja...
Kommt man eingelogged an die Klardaten, so haben wir zusammen wohl 
bestimmt alles Sorten v. Chips

Cool wäre auch irgendwie einen OS-Dump zu bekommen...

Genug Zeit verdaddelt - ab ins Bett,


bis Bald,

-K

Hi all,

I'm interested in your work but I'm not familiar with german language at 
all (I'm french).
So I try to follow your work using google translate but the translation 
is very bad. I don't own a tm5 for the time being so i can't do any 
test.
Before modifying an existing recipe chip I would like to make a copy of 
it. Copy on which I could work without taking the risk of bricking the 
original one.

So I made some searches on goole to find the most appropriate usb 
flashdrive and, like Carlos.B, I found the Silicon Power T01 key on a 
russian web site.
Here is the partnumber you can find on Amazon : SP008GBUF2T01V1K
http://www.amazon.de/Silicon-Power-Touch-801-Speicherstick/dp/B00689HXA2/ref=sr_1_4?ie=UTF8&qid=1424425601&sr=8-4&keywords=silicon+touch+t01

The picture attached show the flashdrive properties using ChipGenius
And here under using ChipEasy :

Logical drive   : E:\            Capacity:  7.5G
Device ID       : VID = 090C     PID = 1000
Device SN       : 02501072159000000829
Device version  : 1100

Device vendor   : UFD 2.0
Device model    : Silicon-Power8G
Protocol        : USB2.0
Max power       : 500mA

Partition type  : FAT32          Device active   : OK
Aligned state   : 28 KB, Have been Aligned

Controller      : SMI
Controller model: SM3257ENLT
Flash Vendor    : SanDisk, Type: TLC, Single channel
Flash ID        : 45DE9493
Score           : 38             (Normal Score >= 30)
Firmware        : ISP 130506-AA-

Tools           : http://www.upan.cc/tools/mass/SMI/
OS Version      : Windows 7 Professional Service Pack 1
Update Status   : The current version is the latest version!


VID, PID and controller model seem to be the same than the recipe key 
but flash vendor is SanDisk whereas it should be Samsung.

Hope this will help.

Regards

Also noch mal ein paar Gedanken von mir.

Die Verschlüsselung findet im TM5 statt und ist somit nicht von dem 
Chipsatz des Speichermediums abhänging. Leider ist ist so auch nicht an 
die Originaldaten heranzukommen.

zur Verifikation des Gerätes reicht dem TM5 eine gültige Seriennummer.

Die Daten für das Grundkochbuch sind in den ersten 8Mb des 
Speichermediums abgelegt und werden ständig auf Konsistenz geprüft.

Vielleicht braucht man die Verschlüsselung auch gar nicht knacken, 
wenn..
1. ..der TM auch unverschlüsselte Daten akzeptiert
2. ..man das Dateiformat herausfindet, z.B. über Zugriff auf die 
Hardware

Ich denke mal die Verschlüsselung zu knacken ohne eine Sicherheitslücke 
oder eine fehlerhafte Implementierung ist nahezu unmöglich.


Bis denne
Knochi

Hab heute mal ein neues Lesegerät für den Chip gebaut.
Man kann die Verpackung die mit dem Chip mit geliefert wird wunderbar 
dazu missbrauchen.

Alexander Schäfer schrieb:
> Hab heute mal ein neues Lesegerät für den Chip gebaut.
> Man kann die Verpackung die mit dem Chip mit geliefert wird wunderbar
> dazu missbrauchen.

Wow! Respekt - da wird jeder Vorwerker Labormitarbeiter bestimmt blass 
vor Neid ;) - Und das aus 'Müll' (der Großteil des sichtbaren 
jedenfalls...) - bin gespannt wie viele 'flüchtig Reinschauer' jetzt auf 
ebay.de oder amazon.de verzweifelt danach suchen :D


VlG,

-K

Mano Galino schrieb:
> Hi all,
>
> I'm interested in your work but I'm not familiar with german language
> [...]
Welcome aboard - my French is rather rusty, but it seems as if we have a 
common foreign language ;)

>
> VID, PID and controller model seem to be the same than the recipe key
> but flash vendor is SanDisk whereas it should be Samsung.
>
I don't think the flash vendor matters - if any at all, then the 
controller chip, or rather the chip you plan on using should be capable 
of offering similar features as the SMI. That one you've got seems right 
(assuming the Chipgenius info was taken from your stick, that you've 
already bought).
The flash chips probably will have differences in available bytes, power 
consumption, speeds,... - but to the TM5 all this doesn't seem to 
matter.

You'll need some SMI tools from where you pulled the infos on the 
fitting stick (Russian site), and use it to upload an iso. Since you 
don't have a TM5, you won't even need to bother with other settings...

> Hope this will help.
>
> Regards

Alexander Schäfer schrieb:
> Hab heute mal ein neues Lesegerät für den Chip gebaut.
> Man kann die Verpackung die mit dem Chip mit geliefert wird wunderbar
> dazu missbrauchen.

Sehr geil! Gefällt mir!

Kevin K. schrieb:
> 1. Block 1695 bytes
> 2. Block 471 bytes

Sorry, die Blöcke sind jeweils ein byte länger (1696 und 472 bytes), da 
das letzte Byte mitzählt (mein Fehler).

Kevin K. schrieb:
> Letzteres brachte mir einen langen Ausflug ein. Julien hatte
> ggaaaannnzzz weit oben ein paar gute Links und darauf fussend AES128b
> vermutet.

Ja, das hat mir die letzten Tage auch Kopfzerbrechen bereitet. Habe mir 
die drei Images mal genauer angeschaut u.a. auch die Entropie. Die Daten 
sind innerhalb des Images so sauber verteilt, dass man daraus auf das 
Verschlüsselungsverfahren schließen können muss.

Zusätzlich haben die Datenblöcke so schön gerade längen, das müsste 
eigentlich als Indiz zu gebrauchen sein.


Hier mal die Daten, die ich zusammengetragen habe

1

"Das Kochbuch"

2

Datenlänge 0x639000 von 0x808000

3

Entropy = 7.999974 bits per byte.

4

Optimum compression would reduce the size of this 6524928 byte file by 0 percent.

5

Chi square distribution for 6524928 samples is 232.29, and randomly would exceed this value 84.31 percent of the times.

6

Arithmetic mean value of data bytes is 127.4850 (127.5 = random).

7

Monte Carlo value for Pi is 3.140989142 (error 0.02 percent).

8

Serial correlation coefficient is 0.000288 (totally uncorrelated = 0.0).

9

10

"Wertvoll geniessen"

11

Datenlänge 0x360000 von 0x808000

12

Entropy = 7.999950 bits per byte.

13

Optimum compression would reduce the size of this 3538944 byte file by 0 percent.

14

Chi square distribution for 3538944 samples is 245.46, and randomly would exceed this value 65.47 percent of the times.

15

Arithmetic mean value of data bytes is 127.4955 (127.5 = random).

16

Monte Carlo value for Pi is 3.141350640 (error 0.01 percent).

17

Serial correlation coefficient is 0.000449 (totally uncorrelated = 0.0).

18

19

"Kochen hat Saison"

20

Datenlänge 0x393000 von 0x808000

21

Entropy = 7.999949 bits per byte.

22

Optimum compression would reduce the size of this 3747840 byte file by 0 percent.

23

Chi square distribution for 3747840 samples is 263.67, and randomly would exceed this value 34.12 percent of the times.

24

Arithmetic mean value of data bytes is 127.4706 (127.5 = random).

25

Monte Carlo value for Pi is 3.141355020 (error 0.01 percent).

26

Serial correlation coefficient is 0.001010 (totally uncorrelated = 0.0).

Carlos B. schrieb:
> [...]
> Ja, das hat mir die letzten Tage auch Kopfzerbrechen bereitet. Habe mir
> die drei Images mal genauer angeschaut u.a. auch die Entropie. Die Daten
> sind innerhalb des Images so sauber verteilt, dass man daraus auf das
> Verschlüsselungsverfahren schließen können muss.
zumindest in Teilen.

>
> Zusätzlich haben die Datenblöcke so schön gerade längen, das müsste
> eigentlich als Indiz zu gebrauchen sein.
Vielleicht - aber wenn man durchfließende Datenströme komprimieren will, 
braucht man auch Blöcke ('cat file |gzip' etwa).

MMn ist die Datenmenge aber leider am unterem Rand des brauchbaren für 
100%-ige Aussagen - es bleibt ein Restrisiko, und ein gewisser 
Unsicherheitsfaktor. Meiner Meinung nach ist der groß genug, um den 
Aufwand den Du schon betrieben hast auch zu rechtfertigen. 
Ausdrückliches Danke hier nochmal dazu!

pi-error tendiert zu kleiner .02 -> encr.
Chi-quadr. allerdings eher um 250 -> kompr.

Allerdings sind die identischen Bereiche von verschiedenen Rezeptchips 
ein klarer Ausschluss des 'ganzes Image in einem Rutsch (AES-) 
verschlüsselt'. Das bedeutet mindestens das an den Stellen von neuem 
begonnen wird (sogar explizit exclusive dieser Bereiche).
Ich bin nicht der AES Profi - bitte korrigieren wenn ich Blech rede - 
aber eine saubere Impl. moderner krypt. Verfahren sollte folgende 
'Features' erlauben:
- 2 Durchläufe des identischen Klartextes mit gleichem Schlüssel ergeben 
2 völlig verschiedentlich aussehende Ergebnisse (dank 'IV' o. 'Salt')
- Da meist das Ergebnis der Operation auf einem Block (teilw.) wieder in 
die Berechnung des nächsten Blockes einfließt, sollten bei 
unterschiedlichen Klartexten mit aber teilweisen deckungsgleichen 
Passagen diese nicht als solche in den resultierenden Ergebnissen 
erkennbar sein.

Ob gerade Letzteres auch für AES gilt, wenn z.Bsp. ein genügend langer 
Block aus 0x00'ern mittendrin an gleicher Stelle anfängt würde ich 
vermuten, kann es aber nicht beschwören. Auf jeden Fall wäre das nur 
dann überhaupt möglich, wenn kein InitialisierungsVektor benutzt wird 
(sollte - ne, DARF nicht sein ;) ).

Vielleicht sollten wir so lange XOR auf eben diese Stellen exerzieren, 
bis was brauchbares rauskommt (Sern. anwenden?). Wir werden aber leider 
erst wissen was 'brauchbar' ist, wenn wir's sehen ;)
Hat jemand mal nach dem 'header' von dem CDFS gesucht? 'In meiner 
Jugend' war das mal der String 'CD001' glaub - ab dem 2. Byte oder so - 
weiss nicht ob Joliet/UDF sowas noch haben...

Aber xor sollte die Entropie nicht ändern - also doch lzma o.ä. kompr.?



Frohes Grübeln,

-K

Carlos B. schrieb:
> [...]
> Sorry, die Blöcke sind jeweils ein byte länger (1696 und 472 bytes), da

Zumindest 1696 sind 106x 128b oder 53 256bit Blöcke - jedenfalls eine 
auffällige Grenze/Größe...


LG,

-K

Kevin K. schrieb:
> Vielleicht sollten wir so lange XOR auf eben diese Stellen exerzieren,
> bis was brauchbares rauskommt (Sern. anwenden?). Wir werden aber leider
> erst wissen was 'brauchbar' ist, wenn wir's sehen ;)

:-D

Habe gerade mal aus Spaß die Seriennummer als AES-128 Schlüssel auf das 
Image losgelassen...kam nur Müll bei raus. Aber ein Versuch war es wert!

Kevin K. schrieb:
> Allerdings sind die identischen Bereiche von verschiedenen Rezeptchips
> ein klarer Ausschluss des 'ganzes Image in einem Rutsch (AES-)
> verschlüsselt'.

Das stimmt so nicht. Beim "Electronic Code Book Mode" (ECB-Modus) werden 
gleiche Eingangsdaten durchaus in gleiche Ausgangsdaten verschlüsselt. 
Meist ist dies ein Fehler bei der Anwendung der Verschlüsselung. Und 
alles sieht danach aus, dass es hier so ist. Dass sich das 4GB große 
Image auf 6,3 MB komprimieren lässt ist ein eindeutiger Hinweis darauf.
Hier gibt es mehr dazu:
https://de.wikipedia.org/wiki/Betriebsmodus_%28Kryptographie%29


> - 2 Durchläufe des identischen Klartextes mit gleichem Schlüssel ergeben
> 2 völlig verschiedentlich aussehende Ergebnisse (dank 'IV' o. 'Salt')

Den Initialisierungsvektor (IV) gibt es beim ECB-Modus nicht.


> Aber xor sollte die Entropie nicht ändern - also doch lzma o.ä. kompr.?

Doch. Ein XOR mit mit einer Zufallsfolge, oder einer Pseudozufallsfolge, 
wie sie beim Verschlüsseln vorkommt, erhöht die Entropie auf ihr 
Maximum.

Habe mir heute mal in Ruhe den Trace von knochi angeschaut.
Ich klasse, was da alles wiederzufinden ist.
Der TM lässt sich erst die Chip-Informationen ausgeben inkl. 
Seriennummer! Darunter seltsamerweise den Hersteller und Produkt-String 
die ihm eigentlich egal sind.
Darauf ließt erst die ersten 16KB (0x00-0x4000), dann springt er ans 
Ende der Daten und ließt da die letzten 4KB (0x638000-0x639000). Danach 
ließt er die 12KB davor (0x635000-0x638000) und anschließend die 8KB vor 
denen (0x633000-0x635000).
Ich denke, das in den ersten 16KB die Datenlänge und der Splashscreen 
des Buches gespeichert ist. Die 4KB am Ende wird wohl der Hash sein.
Warum er anschließend im Nullen Bereich (am Ende der Daten) rumließt 
verstehe ich nicht (erst 24KB, dann 82KB).
Darauf ließt er mal hier, mal da Datenblöcke ein:
0x625000 - 0x629000 16KB
0x629000 - 0x631000 32KB
0x631000 - 0x633000 8KB
0x5E9000 - 0x5ED000 16KB
weiter bin ich noch nicht.

Hmmm...die Pausen zwischen den Lesezugriffe sollten Aufschluss darüber 
geben, wann knochi auf dem Display was gedrückt hat. Schaue ich mir 
morgen an...

Alexander Schmidt schrieb:
> [...]
> Das stimmt so nicht. Beim "Electronic Code Book Mode" (ECB-Modus) werden
> gleiche Eingangsdaten durchaus in gleiche Ausgangsdaten verschlüsselt.
Du hast recht - das hatte ich mehr oder weniger nicht beachtet - nach 
dem Motto 'so bloed koennen sie doch nicht gewesen sein' ;)
In dem genanntem Wiki Artikel steht dann auch "Von der Verwendung des 
ECB-Modus wird daher abgeraten, es sei denn, es soll nur einmal ein 
einziger Nachrichtenblock verschlüsselt werden."
Ist aber von mir bloed gewesen, sowas gleich auszuschliessen - diese 
Moeglichkeit also weiter im Hinterkopf behalten.

Da wollte ich nun mal nachbohren was FreeScale denn genau implementiert 
hat - bin aber nicht so wirklich schlau geworden, schnell und grob so:
- sie haben 1280 bit "einmal-schreib-speicher" um Seriennummern o. 
Schluessel abzulegen
- Sie haben einen integrierten 'Co-Proz' der Sicherheitsfeatures bietet 
um folgendes zu ermoeglichen:
"Read-only unique ID for Digital Rights Management (DRM) algorithms, 
Secure boot using 128-bit AES hardware decryption, SHA-1 and SHA256 
hashing hardware, High assurance boot (HAB4)"

Der max 10Schluessel fassende 1xSchreibspeicher macht Sinn um Schluessel 
zum entschl. des IC302 abzulegen. Aber die Rezeptchips? Sollte das 
AES128b sein, und der Schluessel auftauchen, wuerde nichtmal ein 
FirmwareUpdate das Problem loesen koennen - scheint mir riskant... 
Laesst die Hoffnung das sie im OS irgendwo rumliegen koennten ;) (die 
stirbt ja bekanntlich ... ;) )


> Und
> alles sieht danach aus, dass es hier so ist. Dass sich das 4GB große
> Image auf 6,3 MB komprimieren lässt ist ein eindeutiger Hinweis darauf.

Das ist ein Hinweis dessen Konsequenzen ich bisher ausser acht gelassen 
hatte - danke!
Will ich einzelne Teile eines verschl. Ganzen herauspicken, ist ECB 
tatsaechlich eine angenehme Moeglichkeit (aber nicht die Beste). Will 
heissen, das wenn ich nicht alles einlesen will, sondern in der Mitte 
anfangen, ist ECB besser als Verfahren, bei denen man sich durchhangeln 
muss.
Soweit ich das aber ueberblicken kann, hilft das zwar nicht den 
Schluessel zu erlangen, aber vielleicht den Code zu brechen ;)
Gleiches wuerde immer gleich kodiert werden. Sind die Bloecke klein 
genug, kann man etwa die Milch aus Rezept 1 in Rezept 4 packen :D - man 
muss nur finden wie der kodierte Block Milch aussieht...

>
>> - 2 Durchläufe des identischen Klartextes mit gleichem Schlüssel ergeben
>> 2 völlig verschiedentlich aussehende Ergebnisse (dank 'IV' o. 'Salt')
>
> Den Initialisierungsvektor (IV) gibt es beim ECB-Modus nicht.
>
>
>> Aber xor sollte die Entropie nicht ändern - also doch lzma o.ä. kompr.?
>
> Doch. Ein XOR mit mit einer Zufallsfolge, oder einer Pseudozufallsfolge,
> wie sie beim Verschlüsseln vorkommt, erhöht die Entropie auf ihr
> Maximum.
Ich meinte einfaches XOR statt verschluesseln - sowas wie "Kochbuch XOR 
Seriennummer". Fuege ich der Seriennummer noch einen Zufallswert hinzu, 
erhoet sich natuerlich die Entropie - da hast du vollkommen recht. Was 
ich allerdings meinte, ist das die beobachtete Entropie wiederum gegen 
einfaches XOR spricht.


Bin vorhin hierrueber gestolpert - etwas OT, aber mal 'ne semi-lustige 
Anwendung des TM:
http://www.modernmummymayhem.com/2013/04/thermomix-helped-clean-couch/


LG,

-K

P.S.: @Carlos - merci! Ich hatte ebenfalls schon das Rueckwaertslaufen 
gesehen, aber nicht beachtet das ein Block 2048 Bytes sind, und vorne 
bei 0x0cXX rumgewuehlt, und mich gefragt was er da denn wieder will... 
Aber watt'n 'Rauschen' bevor das eigentliche losgeht... Bist du aus dem 
'Get TOC' schlau geworden?

P.P.S: Wenn man die Features des SoC sieht, fragt man sich wozu 
eigentlich noch den Atmel? Aber das Projekt fuer uebernaechstes Jahr 
steht schon: Hack den TM5! Der Soc hat soviele Zusatzfeatures, das man 
bloed waere ihn nicht voll in die Heimautomation zu integrieren :P
Aber Spass beiseite - da war (auch fuer unser Model) eine 10/100Mbs Eth. 
Schnittstelle - und eine Warnung: die Datenports des USB koennen max. 
24h lang 5V Level vertragen - max war glaub' mit 3.6V angegeben...

Kevin K. schrieb:
> Will ich einzelne Teile eines verschl. Ganzen herauspicken, ist ECB
> tatsaechlich eine angenehme Moeglichkeit (aber nicht die Beste). Will
> heissen, das wenn ich nicht alles einlesen will, sondern in der Mitte
> anfangen, ist ECB besser als Verfahren, bei denen man sich durchhangeln
> muss.

Man muss sich bei keinem Modus durchhangeln, im Sinn von alle Daten 
einlesen um Daten vom Ende zu erhalten. Beim "Cipher Block Chaining 
Mode" und "Cipher Feedback Mode" muss man zwei verschlüsselte Blöcke 
einlesen. Beim "Counter Mode" nur einen, ebenso beim "Output Feedback 
Mode". Wobei bei letzterem die Verschlüsselungsfunktion so oft berechnet 
werden muss, wie die Zahl der vorhergehenden Blöcke.
Bei typischen Blöcken von 128 Bit oder 256 Bit und einer Gesamtlänge von 
hier nur 8 MB ist dies kein Problem, das wären 64 mal die 
Verschlüsselungsfunktion, die hier sogar in Hardware implementiert ist.


> Gleiches wuerde immer gleich kodiert werden. Sind die Bloecke klein
> genug, kann man etwa die Milch aus Rezept 1 in Rezept 4 packen :D - man
> muss nur finden wie der kodierte Block Milch aussieht...

So ist es. Das ist auch ein Ansatzpunkt.


> und eine Warnung: die Datenports des USB koennen max. 24h lang
> 5V Level vertragen - max war glaub' mit 3.6V angegeben...

Das mit den 24 h halte ich für ein Gerücht. Solche langen Angaben 
betreffen meist nur Elektronenmigration, da passiert bei 100 h auch noch 
nicht viel.

Viele Grüße,
Alexander

PS: Bitte kürze beim zitieren mehr.

Kevin K. schrieb:
> Bist du aus dem 'Get TOC' schlau geworden?

Weiss nicht was du meinst. Ist das ein bestimmter Befehl? Welche 
Paketnummer?

Alexander Schmidt schrieb:

>>[...] kann man etwa die Milch aus Rezept 1 in Rezept 4 packen :D - man
>> muss nur finden wie der kodierte Block Milch aussieht...
> So ist es. Das ist auch ein Ansatzpunkt.
Da hier jemand vor einer Weile eine franz. Version eines KB erwähnte - 
wäre das evtl. schon der erste Ansatz - angenommen Texte sind 
verschieden aber die Steuerbefehle gleich - mit Glück sind sie weit 
genug von einander entfernt um sie auseinander halten zu können... 
Versuch wär's Wert - wenn ich vorherige Posts korrekt verstanden habe, 
hätten wir durch den USB Mitschnitt schon Stellen an denen konkret 
Rezepte stehen...

>> [...] die Datenports des USB max. 24h 5V
> [...] da passiert bei 100 h auch noch nicht viel.
Das Datenblatt hatte max. 3,6V für USB-Data angegeben, und dann mit * 
auf die 24h bei 5V hingewiesen - wollte nur nicht das jemand da böses 
erlebt. Sie hatten auch explizit darauf verwiesen, das die im SoC 
integrierten A/D Wandler für die Dauer der 5V am USB evtl. unkorrekte 
Ergebnisse liefern.
Konnte mich zudem an Warnungen zu Port CN602(?) erinnern, dort einfach 
USB anzuklemmen. Anscheinend sollte man an diesem Gerät aber nicht 
einmal mit 5V an den echten USB Port gehen (oder zumindest nicht über 
Nacht stecken lassen) - ich würde also auf keinen Fall den vermuteten 
Debugport 1:1 mit USB verbinden, sondern tatsächlich warten bis jemand 
beim Booten einen Oszi dran hatte.
Irgendwie müssen die da geschummelt/gepennt haben - USB sollte 
eigentlich min. 4,4V und höchstens 5,25V vertragen.


> PS: Bitte kürze beim zitieren mehr.
Werde es versuchen - schon alleine weil ich irgendwie das Gefühl habe, 
hier immer ganze Tapeten oder Romane zu schreiben - hoffe ich nerve euch 
nicht (zu sehr?) damit...


VlG,

-K

Carlos B. schrieb:
>> Bist du aus dem 'Get TOC' schlau geworden?
Ich hatte irgendwie öfter als vermutet einen 'get table of contents/...' 
(TOC und ein paar weitere Arten von Inhaltsverz. waren in dem SCSI-Cmd 
genannt - HDD,Speicher,...) gesehen, aber leider auch kein einziges mal 
ein brauchbares Listing als Antwort gesehen. Evtl. waren das jeweils für 
HDD/CDFS um das richtige zu suchen... aber irgendwie doch ein paar mehr 
als man erwartet hätte... Schien mir jedenfalls so.

Kevin K. schrieb:
>>> [...] die Datenports des USB max. 24h 5V
>> [...] da passiert bei 100 h auch noch nicht viel.
> Das Datenblatt hatte max. 3,6V für USB-Data angegeben, und dann mit *
> ...

Dies gilt nur für die Datenports, nicht für die USB Versorgungsspannung. 
Die Datenports D+ und D- am USB sollten immer zwischen 3,0V und 3,6V 
liegen. Hier ein Zitat vom Datenblatt des ATmega32U4:
"To comply with the USB Electrical specification, USB buffers (D+ or D-) 
should be powered within the 3.0 to 3.6V range"

Kevin K. schrieb:
>>> Bist du aus dem 'Get TOC' schlau geworden?

Oh, mir ist gerade aufgefallen, das ich entweder andere Einstellung habe 
als ihr, oder ihr habt das falsche Programm. Bei mir sehen die Pakete 
ganz anders aus als im obigen Screenshot.

Ich benutze das "USB Mobile HS / USBMobile T2 Protocol Suite" aus dem 
Link von knochi's Post.

Von SCSI Befehlen sind bei mit keine Spur.

Carlos B. schrieb:
> "To comply with [...]

Merci fuer die Klarstellung - d.h. "It's not a bug, it's ..."

Carlos B. schrieb:
> [...]
> Von SCSI Befehlen sind bei mit keine Spur.

Das sind bestimmt die Einstellungen. Ich glaube rechts oben kamen die 
her. Die Einstellungen das Hintergrundrauschen auszublenden hilft auch - 
das sind die 'Hide NAKs' o. 'Hide Chirps' - die Kästchen in denen sich 
kleine gelbe Kreuze unten rechts in rote wandelen, nach dem "2 only".
Sollten die kleinen Icon-Schalter über dem Dump fehlen, kann man sie 
auch unter View finden.
Ich hoffe das die Bytes die im 'Stacking view' zusammenfassend angezeigt 
werden, auch wirklich in einem Rutsch gelesen werden. Es sieht nach 
einem gewissen Muster aus, wo erstmal 4-8K gelesen werden, denen dann 
meist ein oder mehrere grössere Blöcke folgen (bis zu 120K). Wenn der 
Data-View an ist, kann man die Daten aus so einem Schwung auch einfach 
in einem an hexdump ähnlichem Format speichern. Da kommen dann Dateien 
wie im letztem Screenshot bei rum. Ich hatte 
lesenummer-groesse-adresse-zeit immer als Namen genommen. Wobei die 
Adresse mit Vorsicht zu genießen ist - meine olle Büchse mit dem 
Virt-Win hat einen üblen Font in dem Tool - da sind 8, B und so ziemlich 
blöd...

Hallo zusammen,


ich habe ein Feature in der USB-Prot-View-Soft gefunden, die sich 
'Decoded fields view' nennt - dort werden die bits in den SCSI Paketen 
recht gut aufgedröselt.
Diese gehäuften 'Get TOC's waren mir ja schon vorher mal als seltsam 
aufgefallen - mit den SCSI-decoder sind sie noch seltsamer geworden. 
Wenn ich mich recht entsinne war das ausgehendes Jahrtausend eine 
Methode CDs zu schützen - einfach mehrere (un-)gültige TOCs anlegen, und 
lesen - wenn's Fehler gab -> orig, bei fehlerfreiem Müll lesen -> Kopie 
oder so ähnlich.

Evtl. ist das folgende nur heiße Luft, und darauf zurückzuführen, das 
die Controller nur ein CDFS haben statt auch noch 1 HDD & 1 sec.HDD 
haben, aber im Prinzip meldet der Chip 3 mögliche Geräte auf 'Request 
Mode Sense' oder 'Get Config' anfragen (alles so um Zeitstempel 12sec - 
transf#22 nach transa#58210). Ich glaube 'Get Config' liefert nackte 
Bytes, nämlich 12, 24 o. 32 - während der 'mode sense' das zwar 
ausschmückt, aber im Grunde die gleichen Bytes aneinander reiht.
Der Controller liefert zunächst 3 'Beschreibungen' - Nummer, LBAs und 
deren Größe. Die scheinen allesamt erstmal Schrott - da ich ins Bett 
will, hier meine Notizen:

1

Descriptor 1:

2

Byte  #Block    Length    Size

3

MSB  180707    772923    12.297.039.385.845  12,2TB

4

LSB  070718    232977    1.061.321.385.000  1TB

5

6

2A 180707 71 772923

7

8

9

Descriptor 2:

10

Byte  #Block    Length    Size

11

MSB  140100    002114    11.101.344.768    11GB

12

LSB  000114    142100    364.090.368    364MB

13

14

21 140100 08 002114

15

16

17

Descriptor 3:

18

Byte  #Block    Length    Size

19

MSB  002114    140000    11.099.176.960    11GB

20

LSB  142100    000014    26.383.360    26MB

21

22

00 002114 21 140000 (00 00)

23

24

Reply 1 TOC of Track0?

25

00 120101

26

00 140100

27

00 000200

28

29

Reply 2 TOC of Track1?

30

Illegal...

31

32

Resulting Re-request possibly introd. Descr0:

33

MSB  000500    00000A    12.800      12K

34

LSB  000500    0A0000    838.860.800    838MB

35

36

70 000500 00 00000A

37

38

changes Descr. 1 to:

39

00 000000 20 000000

40

leaving Descr. 2&3 as are, minus trailing 2 0x00

Die Zahlenfolge unter einem 'Gerät' (Descriptor) ist jeweils so, wie sie 
im Dump steht. Interessant ist hier die Zahl zwischen Anzahl der Blöcke 
und Blockgröße - das Feld ist angeblich 'reserved' und sollte '0' 
betragen. Das erste Byte ist jeweils der 'mode sense' (=ID?).
Interessant scheint hier, das die Werte irgendwie alle zwar Hex-Bytes 
sind, aber keine Buchstaben darin vorkommen (A-F).
Er versucht dann nacheinander(?) den Inhalt der 'Geräte' zu lesen - das 
erste Ergebnis führt wiederum nur zu Ziffern.
Das 2. platzt erwartungsgemäß. Danach fängt der Spaß an, kurz und 
einfach: der Fehler führt zu reset, nach 1. reset wird vorne ein Gerät 
eingefügt, und eines geändert (0 Blöcke mal 0 Größe) aber wiederum mit 
'illegaler' Zahl dazwischen. Das Spiel geht dann weiter - TOC lesen, 
reset, mal mehr, mal weniger Geräte,... bis es sich dann irgendwo vor 
dem 'XOR Write' bei ca. 13s Zeitstempel einpendelt, und danach alles 
glatt läuft - richtige Größe, komisches springen beim lesen - was Carlos 
weiter oben beschrieben hat.
Vielleicht Zufall, aber 4 'Phantasie' Geräte sind 32Byte - oder 2 
Schlüssel oder 2 Werte die XOR 1 Schlüssel ergeben - es könnte auch 
sein, das die Anzahl der Geräte am Ende ein vielfaches von 32Byte 
ergeben...

Springt jemandem da was ins Auge? (Meine sind schon halb zu... ;) )

-K

Moin,
leider ist das ja ziemlich eingeschlafen hier.
Ich habe mir den weiter oben verlinkten USB Stick (Silicon Power Touch 
801 8GB Speicherstick USB 2.0) von Amazon bestellt. Dieser hat 
tatsächlich den SM3257ENLT als Chip verbaut.

Hallo Zusammen,

diese Sticks habe ich mir bestellt, sollten auch funktionieren.

http://computer-pc-shop.de/shop/details.php?art=164347&artname=USB-Stick+++8GB+Silicon+Power+T01+Black%2FMetallic+Case

hallo zusammen,
Ich discution dieses Thema, da es sehr interresant sein, aber ich frage 
mich fragt MEHRERE ca Ich bin französisch, und ich versuche zu 
übersetzen, was nicht offensichtlich ist auch bei Google-Übersetzung 
allem etwas technisch.

-kann haben actuelement MEHRERE Clef Rezept eine Taste, die verhindern 
würde mich beschäftigt viele Schlüssel gestellt wird alles sehr 
praktisches Rezept auf derselben Taste es.
-sait actuelement irgendwelche leeren Schlüssel Kauf 4 oder 8 GB?
- Möglicherweise müssen Sie ein Schaltbild, um erzeugt ein USB-Laufwerk 
wie diese haben?

https://www.mikrocontroller.net/attachment/247694/CIMG1688.JPG

-Muss Ich installierte Linux zwingend, um den Schlüssel Rezept TM 
extrahieren oder kann ich es in Win 7?

vielen Dank für Ihre reponce

Hallo zusammen,

habe seit letzter Woche auch einen Thermomix TM5 und wollte einfach mal 
nachfragen, obs inzwischen Neuigkeiten zur Verschlüsselung der Chips 
gibt.

Ich hoffe, dass der Thread nicht eingeschlafen ist, sondern es noch 
aktive Versuche gibt, eigene Chips zu programmieren.

Hi,

Schade dass das hier so eingeschlafen ist. Wollte nur noch mal darauf 
hinweisen, daß die c't in der aktuellen Ausgabe den TM5 unter die Lupe 
nimmt.
Ausserdem gibt es im Video Podcast Nerds zu sehen die mit dem Ding Eis 
machen.

http://m.heise.de/newsticker/meldung/c-t-uplink-6-6-Thermomix-Dias-scannen-Kim-Dotcom-2650328.html

Bis denne
Knochi

Hi,

gibt es mittlerweile neue Erkenntnisse? Würde mich brennend 
interessieren, meinen Chip zu modden.

Guten Abend,
meine Frau hat heute ihren Thermomix bekommen und mir gleich die Frage 
gestellt, ob es möglich ist eigene Rezepte einzuspeichern. Da habe ich 
mich an diesen Thread erinnert, den ich mal aus Interesse gelesen habe.

Gibt es mittlerweile Fortschritte? Es wäre ein gutes Feature :-)

Hallo,

ich habe nun seit einer Woche auch einen TM5.

Folgendes zu mir:
- ich kann Elektro
- ich kann Krypto
- ich kann nicht gut (PCs) programmieren

Ich habe mich hier durch den Thread gewurschtelt und festgestellt, dass 
die Aussagen Krypto betreffend - ich will niemanden beleidigen - aber 
fast alle falsch sind.

Das ganze Halbwissen hier aufzugreifen und richtigzustellen ist mir 
nicht möglich, aber ich würde gerne, sofern sich jemand findet der 
mitarbeitet die Sache mal professioneller angehen.

Wie gesagt, ich kann Krypto, weil ich das studiert habe und seit 2005 
beruflich mache. Zusammen mit jemandem der programmieren kann, sollte 
man schon ein gutes Stück weiter kommen.

Ich selber habe mal eine Datei (ich glaube das französische Kochbuch 
wars) hier heruntergeladen und angefangen mit meinen schlechten 
PC-Programmierkenntnissen diese zu analysieren. Zuerst habe ich ein 
Muster gesucht, das sich wiederholt. Dabei bin ich darauf gestoßen, dass 
die Bytefolge: c8 85 b8 03 12 24 b6 67 7a 7b fe 2c eb 87 05 76 genau 
224200 Mal vorkommt.

Das Erstaunliche dabei ist, dass der Abstand zwischen dem 1, und 2. 
Vorkommen und zwischen dem 3. und 4. Vorkommen und so weiter immer genau 
8192 (0x2000) Byte beträgt. Die anderen Abstände zwischen 2. und 3. 
Vorkommen, und zwischen 4. und 5. Vorkommen sind immer unterschiedlich. 
Hier die ersten und die letzten Vorkommen, damit Ihr seht, was ich 
meine:

Gesucht: c8 85 b8 03 12 24 b6 67 7a 7b fe 2c eb 87 05 76

Gefunden ab + Abstand +  Abstand
Adresse:    +     Hex +      Dec
------------+---------+---------
0x0080c44c;   80c44c;    8438860
0x0080e44c;     2000;       8192
0x00810c5e;     2812;      10258
0x00812c5e;     2000;       8192
0x0081526b;     260d;       9741
0x0081726b;     2000;       8192
0x00821f55;     acea;      44266
0x00823f55;     2000;       8192
0x00824f3b;      fe6;       4070
0x00826f3b;     2000;       8192
0x00828a39;     1afe;       6910
0x0082aa39;     2000;       8192
0x0083ce5a;    12421;      74785
0x0083ee5a;     2000;       8192
0x0085d805;    1e9ab;     125355
0x0085f805;     2000;       8192
0x00860077;      872;       2162
0x00862077;     2000;       8192
0x008658c0;     3849;      14409
0x008678c0;     2000;       8192
...
0xeffec1ce;     1f75;       8053
0xeffee1ce;     2000;       8192
0xefff1e56;     3c88;      15496
0xefff3e56;     2000;       8192
0xefff4409;      5b3;       1459
0xefff6409;     2000;       8192
0xefff931c;     2f13;      12051
0xefffb31c;     2000;       8192
0xefffd680;     2364;       9060
0xeffff680;     2000;       8192

Bevor ich jetzt anfange Krypto zu erklären, stelle ich erstmal die Frage 
ob hier jemand in der Lage und willens ist, zusammen mit mir das Problem 
anzugehen, dann würde ich mal aufschreiben, was man versuchen könnte.

In erster Linie, würde man alle Muster finden wollen. Als ich angefangen 
habe, hoffte ich, dass es 8196 Byte gibt, die sich immer wiederholen und 
nur am Anfang etwas anderes steht, aber das scheint ja nicht der Fall zu 
sein.

Schritt 1 wäre daher zu klären: Welche Bytefolgen wiederholen sich immer 
wieder, wo sind die und wie oft wiederholen sie sich und was bleibt über 
an Daten, die nur einmal vorhanden sind.

Wenn sich jemand meldet, erkläre ich auch die verschiedenen 
Kryptoverfahren und wieso einige nicht in Frage kommen (z.B.: AES-ECB)

Ach so, eventuell kann mir jemand sagen, welche Images es schon alles 
gibt und wo man die findet. Zudem könnten Images von einem leeren 4GB 
Stick, der mit unterschiedlichen Dateisystemen formatiert wurde auch 
weiterhelfen.

Grüße aus Bochum, wo es die beste Currywurst gibt,

Dario

Dario C. schrieb:

> Folgendes zu mir:
> - ich kann Elektro
> - ich kann Krypto
> - ich kann nicht gut (PCs) programmieren
[...]

Klingt doch gut. Soll das per PN ablaufen oder darf da jeder mitlesen?

Ich möchte nicht unbedingt der auserwählte Programmierer sein (außer es 
meldet sich sonst niemand), aber interessieren tut es mich doch sehr was 
du zu erzählen hast.

(ich weiß, ist OT) aber wie zum Teufel kann man "Krypto" können, aber 
nicht programmieren?


naja, egal: was ist dein (erstes) Ziel?
herausfinden welche Verschlüsselung es ist (ausgeschlossen hast ja schon 
ein paar)?
nachdem der (teil) des Schlüssel wohl im Thermomix selber ist, wird


>Schritt 1 wäre daher zu klären: Welche Bytefolgen wiederholen sich immer
>wieder, wo sind die und wie oft wiederholen sie sich und was bleibt über
>an Daten, die nur einmal vorhanden sind.

muss man, wenn man "Krypo kann" nicht auch  schon mal was von B-Tree, 
Hashtabelle oder ähnlichem gehört haben? (oder verwechsle ich hier 
verschlüsseln und komprimieren..) auf jeden fall wäre es damit wohl 
schnell gelöst, und da muss man auch nix selbe erfinden, gibts fix 
fertig für alle sprachen.. auch wenn ich den sinn dahinter nicht sehe..

>Das Erstaunliche dabei ist
wirklich? ein Header-Satz und dann eine Daten-Satz, wieder ein Header, 
wieder Daten.. ja, sehr ungewöhnlich...

Ein Ziel könnte ein Konverter-Programm sein, welches eine 
Rezepte-Datenbank in ein Thermomix-USB-Image konvertiert, was dann am 
Thermomix verwendet werden kann.

Vom Prinzip her kann man eigene Thermomix-Rezepte in "jeder" 
Rezeptverwaltung pflegen. Daher sollte man hier auf eine offene 
Rezeptverwaltung mit Exportmöglichkeiten setzen. Das Export-Format ist 
dann Grundlage für den Konverter.

Bisher kenne ich nur die üblichen Thermomix Online-Portale, die aber 
keine Exportfunktion unterstützen. Ich kann mich diesbzgl. aber mal 
umsehen, welches Format da geeignet erscheint. Dann braucht man sich um 
einen Rezept-Editor nicht weiter kümmern. Grundlage wäre das 
Export-Format.

Projektziele wären dann beispielsweise ein TM-USB-Adapter (Hardware) und 
ein Konverter (Software). Für die Hardware sollten wir hier genug Leute 
finden. Ein Layout würde ich auch erstellen können, wenn die Schaltung 
klar ist.

Für eine Software (Konverter) könnte ich mich zur Verfügung stellen. 
Natürlich nur unter der Bedingung die SW und die HW Open Source zu 
stellen.

Bevor hier angefangen wird über die Entwicklung von "Konvertern" oder 
Ähnlichem zu sprechen müssen erstmal die Probleme gelöst werden die 
Rezepte von dem Chip zu lesen, eigene Rezepte im selben Format zu 
schreiben und sie vor allem so auf einen Chip zu schreiben, dass sie vom 
TM 5 akzeptiert werden.
Wenn das alles "manuell" funktioniert, dann ist der richtige Zeitpunkt 
um über die Entwicklung von "Konvertern" nachzudenken, vorher ist es nur 
vergeudete Zeit und Ablenkung im Thread.

>Ein Ziel könnte ein Konverter-Programm sein
das ist schon klar,
ich meinte eher was das ziel ist, den USB-Stick (weiter) zu untersuchen, 
wo doch für jemanden der "krypto kann" klar sein dürfte, dass es ohne 
Daten vom Thermomix (key), zu nix führen kann...

Robert L. schrieb:
>>Ein Ziel könnte ein Konverter-Programm sein
> das ist schon klar,

Das ist ja auch schon mal was.

Die Rezepte haben ja Namen, die man auf dem Display sehen kann. Wäre 
dies nicht ein guter Ansatzpunkt?

Annahmen:
1) Rezepte sind zu Datensätzen zusammengefasst, wobei ein Datenfeld den 
Rezeptnamen als Inhalt hat.

2) Datenfelder sind durch Trennzeichen getrennt. (Welche?)

3) Datensätze sind in einer Reihenfolge (z.B. alphabethisch) abgelegt

Ansatz:
Länge der Datenfelder in den Datensätzen mit den Längen der Rezeptnamen 
vergleichen.

Sorry, bin kein Krypto. Mir fielen noch weitere Ansätze ein, falls das 
was hergibt. Sicherlich muß man erstmal Verschlüsselung und Kompression 
klären, da muß ich aber passen.

Hallo Zusammen,

t'schuldigung, jetzt ist es doch etwas länger geworden:


@Fabian O. (fabiiian)
> Soll das per PN ablaufen oder darf da jeder mitlesen?
Ich bin eigentlich immer für öffentlich.

@Robert L. (lrlr)
> (ich weiß, ist OT) aber wie zum Teufel kann man "Krypto" können,
> aber nicht programmieren?
Zum einen liegt es an meinen Qualitätsansprüchen an mich selbst zum 
anderen an meiner Erfahrung. Ich habe einige Zeit Krypto auf 
eingebetteten Systemen programmiert (8 Bitter und so) und dann war ich 
lange Projektleiter, jetzt gebe ich nur noch Schulungen zu IT-Sicherheit 
(z.B. im Linuxhotel).

C Programmieren geht gerade so, und ich habe mich mit meine obrigen 
Analyse schon schwer getan, hier mein (schlechter) Code.

1

#include <stdio.h>

2

#include <stdlib.h>

3

#include <stdint.h>

4

5

int main(void){

6

7

    FILE *datei;

8

    FILE *result;

9

    uint8_t buf[2048];

10

11

    // uint8_t muster[4] = {0xB0, 0x8F, 0xEF, 0x24};

12

    // uint8_t muster[4] = {0x56, 0x45, 0xF1, 0xD4};

13

    // uint8_t muster[8] = {0x12, 0x24, 0xB6, 0x67, 0x7a, 0x7B, 0xfe, 0x2c};

14

    // uint8_t muster[16] = {0x8E, 0x68, 0xC8, 0x8D, 0x38, 0xEB, 0x78, 0x0e, \

15

                             0xC2, 0xA5, 0xE4, 0x10, 0x7A, 0x40, 0x7C, 0xB5};

16

    // uint8_t muster[16] = {0x6e, 0xb3, 0x4c, 0xd5, 0x60, 0x74, 0xa9, 0x13, 0x48, 0xe4, 0xd3, 0x7c, 0xb2, 0xf9, 0xc1, 0xb2};

17

18

    uint8_t muster[16] = {0xC8, 0x85, 0xB8, 0x03, 0x12, 0x24, 0xB6, 0x67, 0x7a, 0x7B, 0xfe, 0x2c, 0xeb, 0x87, 0x05, 0x76};

19

20

    unsigned char c;

21

    long long bc;

22

    long long ltreffer;

23

    long long diff;

24

    long long treffer;

25

    int cnt;

26

    int gleich;

27

    int i;

28

    ltreffer = 0;

29

    treffer = 0;

30

31

    // Dateien öffnen

32

    datei = fopen( "recipes.img", "rb");

33

    result = fopen( "result.txt", "w");

34

35

    // Suchmuster ausgeben

36

    for (cnt=0; cnt<sizeof(muster); cnt++){

37

        if (muster[cnt] < 16){

38

            printf("0");

39

            fprintf(result, "0");

40

        }

41

        printf("%x ", muster[cnt]);

42

        fprintf(result, "%x ", muster[cnt]);

43

    }

44

    printf("\r\n");

45

    fprintf(result, "\r\n");

46

47

48

    // Fehlerbehandlung

49

    if(datei == NULL){

50

        printf("Fehler beim Öffnen von recipes.img\r\n");

51

        exit(EXIT_FAILURE);

52

    } else {

53

        printf("recipes.img erfolgreich geöffnet!\r\n");

54

        // Anzahl 2048 Bit Blöcke: 1966080

55

        for (bc=0; bc<66080; bc++){

56

            // einen Block einlesen

57

            // printf("lese Block %d\r\n",bc);

58

            for (cnt=0; cnt<2048; cnt++){

59

                buf[cnt] = fgetc(datei);

60

            }

61

            // gelesenen Block ausgeben

62

            /*

63

            for (cnt=0; cnt<(2048); cnt++){

64

                if ((cnt % 16) == 0){

65

                    printf("\r\n");

66

                }

67

                if (buf[cnt] < 16){

68

                    printf("0");

69

                }

70

                printf("%x ",buf[cnt]);

71

            }

72

            printf("\r\n");

73

            */

74

            // Muster suchen

75

            for (cnt=0; cnt<2048; cnt++){

76

                gleich = 0;

77

                for (i =0; i<sizeof(muster); i++){

78

                    if (muster[i] == buf[cnt+i]){

79

                        gleich++;

80

                    }

81

                }

82

                if (gleich == sizeof(muster)) {

83

                    treffer = bc*2048 + cnt;

84

                    diff = treffer - ltreffer;

85

                    /*

86

                    printf("0x%8x; ", treffer );

87

                    printf("%8x; ", diff);

88

                    printf("%10d ", diff);

89

                    printf("\r\n");

90

                    */

91

                    fprintf(result, "0x%8x; ", treffer );

92

                    fprintf(result, "%8x; ", diff);

93

                    fprintf(result, "%10d ", diff);

94

                    fprintf(result, "\r\n");

95

                    ltreffer = treffer;

96

                }

97

            }

98

        }

99

    // Dateien schließen

100

    fclose(datei);

101

    fclose(result);

102

    }

103

    printf("Ende.\r\n");

104

    return 0;

105

 }

> egal: was ist dein (erstes) Ziel?
> herausfinden welche Verschlüsselung es ist
Naja, sagen wir mal so: Zuerst herausfinden OB es eine Verschlüsselung 
ist.
Dazu bräuchte man idealerweise den Plaintext, den wir nicht haben.

Es handelt sich bei dem Chip ja um  ein Blockdevice, auf das (da nehme 
ich mal kühn an) nur lesend zugegriffen wird. Wollte ich das 
verschlüsseln hätte ich sowas gemacht, wie es auch Truecrypt macht. Also 
so, dass man gar kein einziges Byte Klartext (auch keinen Header) mehr 
hätte.

Eine weitere Annahme ist, dass der Chip ja von allen Thermomixen gelesen 
werden muss, also die Information, die man benötigt um einen Chip zu 
entschlüsseln, muss in jedem Thermomix drin sein. Teile können natürlich
auch auf dem Chip sein.

Kommen wir zu der Frage: Warum ist das Verschlüsselt.
1.) Weil niemand sehen soll, was da drauf steht.
2.) Als Kopierschutz

Als Kopierschutz wäre aber quatsch, denn wenn man den Chip kopiert, kann 
man die verschlüsselten Daten mit kopieren. Ein Kopierschutz kann daher 
nur funktionieren, wenn man nicht alles kopieren kann (z.B. die 
Seriennummer)
Dann würde man das aber richtigerweise mit einer kryptographischen 
Signatur lösen. Etwas nach der Art: "Signatur von Seriennummer des Chips 
erzeugt mit dem Private Key vom Hersteller" Der TM5 braucht zum Prüfen 
nur den Public Key.

Das bedeutet, selbst wenn ein Angreifer alle Chips und alle TM5 hätte,
könnte er immer keine Chips kopieren, wenn er die Seriennummer des Chips 
nicht kopieren kann.

Typische Fehler sind dann zum Beispiel: Man verschlüsselt den Chip mit 
einem kryptographischen Schlüssel, der aus der Seriennummer des Chips 
und einem weiteren Geheimnis (das im TM5 gespeichert ist) gebildet wird.

Wenn in dem Fall ein Angreifer dieses Geheimnis aus EINEM TM5 
rausbekommt, kann er munter Chips erzeugen, die von allen TM5 angenommen 
werden.

Aber wie ich schon schrieb, ob es sich überhaupt um eine Verschlüsselung 
handelt ist noch nicht gesichert.

> muss man, wenn man "Krypo kann" nicht auch  schon mal was von B-Tree,
> Hashtabelle oder ähnlichem gehört haben? (oder verwechsle ich hier
> verschlüsseln und komprimieren..)
Ich kenne vollständig balancierte Bäume und auch Hashtabellen aus der 
Datenbanktheorie, wie uns das hier weiterhelfen sollen müsstest Du mir 
aber erklären.

> auch wenn ich den sinn dahinter nicht sehe..
Die einzige Möglichkeit, die ich sehe, ohne den TM5 zu öffnen ist es 
Paare aus Klartextdaten und den dazugehörigen verschlüsselten Daten zu 
finden um dann zu klären, wie "verschlüsselt" wird. Dazu sollte man 
klären:
1. Sind die Daten auf unterschiedlichen Chips der selben Kochbücher
   identisch?
2. Was sind die Klartextdaten, oder was könnten die sein?
   Wenn sich unterschiedliche Blöcke wiederholen, nehme ich an,
   dass sich die Klartextdaten auch wiederholen. Zusammen mit weiteren
   Infos, zum Beispiel wie das Dateisystemen ausgebaut ist, könnte ,
   man dann darauf kommen, was die Klartextdaten zu diesen Blöcken sind.
   Und dann kann man mal überlegen, wie das "verschlüsselt" wurde

> wirklich? ein Header-Satz und dann eine Daten-Satz, wieder ein Header,
> wieder Daten.. ja, sehr ungewöhnlich...
Ich finde es ungewöhnlich, dass 224200 Datensätze ein 399 Seiten dickes 
Kochbuch abbilden? Und warum kann 7zip diese 224200 Datensätze auf 7MB 
packen?


> ich meinte eher was das ziel ist, den USB-Stick (weiter) zu untersuchen,
ACK

> wo doch für jemanden der "krypto kann" klar sein dürfte, dass es ohne
> Daten vom Thermomix (key), zu nix führen kann...
Wie ich oben schon schrieb, das ist nicht unbedingt der Fall.

Wenn ich es designed hätte könntest Du auch den Thermomix untersuchen 
und
würdest trotzdem nicht zum Ziel kommen. Die könntest dann nur "gewinnen" 
wenn:

a) Du es schaffst die Seriennummer mit dem Chip zu kopieren, aber dann
   kopierst Du auch immer meine Kochbücher und kannst keine eigenen 
Rezept-
   Chips erstellen.
b) Du die Daten in jedem Thermomix änderst, der Deine Chips akzeptieren 
soll.
   Das wurde zum Beispiel einmal bei einen Angriff auf die PS3 so 
gemacht.
   Ein USB-Dongle hat einen Buffer-Overflow-Error im Gerät ausgelöst und
   so eigenen Code eingeschleust, der das Betriebssystem verändert und
   so den Kopierschutz entfernt hat.

Aber, aus Erfahrung weiß ich, dass es selten der Fall ist,
das Krypto richtig genutzt und implementiert wurde,
die Chancen stehen daher nicht schlecht.

Ein Beispiel, wie man es hätte falsch machen können:
Verschlüsselt wird jeder Block mit AES im CounterMode [1] als Nonce wird 
die Seriennummer des Chips verwendet und der Schlüssel ist im TM5 
gespeichert.
Dann könnten wir einen Chip schnell entschlüsseln, wenn wir den Klartext 
von einem einzigen Block kennen würden.

Ich hoffe ich konnte einiges klären.

Zusammenfassend: Der erste Schritt ist möglichst viele Informationen zum 
Klartext zu bekommen, damit man ein paar Plain-/Chiphertext Paare 
erhält, um dann zu überlegen, ob und wie da verschlüsselt wurde.


Grüße

Dario

[1] https://de.wikipedia.org/wiki/Counter_Mode

@Clyde B. (clyde_b)
> Die Rezepte haben ja Namen, die man auf dem Display sehen kann.
> Wäre dies nicht ein guter Ansatzpunkt?
nicht wirklich, denn wo steht "Risotto" denn genau auf dem Chip.
Ich meine zielführender ist es Infos über die mögliche Struktur darunter 
zu finden und zu wissen, welche Daten sich immer wiederholen.

Aber mit der Datenbank ist auch keine schlechte Idee, denn da steht ja 
oben im Therad irgendwo, dann die folgenden Pakete zum Einsatz kommen:
> \unmodified_packages\libsqlite\sqlite3.c
> \unmodified_packages\libsqlite\sqlite3.h
Also wird wohl eine sqlite Datenbankstruktur irgendwo zu finden sein.

Was ich übrigens vermisse ist sowas wie libopenssl, die würde man 
nämlich brauchen, wenn man verschlüsseln will und nicht alles selber neu 
programmieren will. Es sei denn man kauft sich was ein.

Dario

HiDario,

schön, dass sich hier wieder was tut.
Ich weiss nicht, wie intensiv du den thread gelesen hast, aber ich hatte 
ja mal ziemlich zum Anfang USB Logs gezogen. Hier liesse sich 
zumindestens eine Zuordnung von Datenblöcken zu einzelnen Informationen 
herstellen.

Hast du auch gelesen, dass Chips bereits erfolgreich kopiert wurden?

Bis denne
Knochi

@David N-K (knochi)

> Ich weiss nicht, wie intensiv du den thread gelesen hast,
Sagen wir mal 2h lang habe ich gelesen.

> ja ich hatte ja mal ziemlich zum Anfang USB Logs gezogen. Hier liesse sich
> zumindestens eine Zuordnung von Datenblöcken zu einzelnen Informationen
> herstellen.
Das wäre der zweite Schritt.

> Hast du auch gelesen, dass Chips bereits erfolgreich kopiert wurden?
Nein. Wo steht das?


Dario

@Dario C:
>Als Kopierschutz wäre aber quatsch,

dass der schon erfolgreich kopiert wurde, hast wohl übersehen?
Beitrag "Re: Thermomix Rezeptchips"

>Plain-/Chiphertext Paare
>erhält, um dann zu überlegen, ob und wie da verschlüsselt wurde.

gibt es wirklich (aktuelle) Verschlüsselungen die so schlecht sind dass 
die so einen Rückschluss zulassen?

>Ich kenne vollständig balancierte Bäume und auch Hashtabellen aus der
>Datenbanktheorie, wie uns das hier weiterhelfen sollen müsstest Du mir
>aber erklären.

Kurzfassung:

du willst "identische Blöcke" finden, also wirst du erstmals die 
minimale Länge eines solchen Blockes definieren müssen (z.b. 10 
Zeichen),

jetzt gehst du die Datei, Zeichen für Zeichen durch, und schreib den 
Aktuellen Wert (also aktuelles Byte + die nächsten 9) in die hashmap

z.B.
http://wiki.delphi-jedi.org/wiki/JCL_Help:TStringHashMap

dort kannst zu jedem (hash vom) String auch ein Datenobjekt ablegen (die 
Anzahl)

dann die top10 ermitteln, das File nochmal von vorne durchsuchen und 
immer wenn man auf einen der TOP10 stößt, die weiteren vorkommen 
suchen..

IMHO müsste das funktionieren...


> Und warum kann 7zip diese 224200 Datensätze auf 7MB
>packen?
vielleicht weil viel unnützer Müll drinnen ist, dutzendfach identisch, 
falls jemand auf die Idee kommt, gleiche Texte suchen zu wollen.. ;-)

Dario C. schrieb:
>> Hast du auch gelesen, dass Chips bereits erfolgreich kopiert wurden?
> Nein. Wo steht das?

An mehreren Stellen. 1=1 Kopien sind kein Problem. Wichtig ist dabei nur 
die SN des USB Devices nicht zu verändern. Ich wollte da mal ein paar 
Dumps und SN Sammeln aber hat sich leider kaum jmd. beteiligt. Es hat 
auch jmd. das Patent von Vorwerk gepostet, da steht einiges dazu drin.

Dario C. schrieb:
> @David N-K (knochi)
>
>> Ich weiss nicht, wie intensiv du den thread gelesen hast,
> Sagen wir mal 2h lang habe ich gelesen.
>

OK das Material reicht wahrscheinlich für 2 Tage ;-)

>> ja ich hatte ja mal ziemlich zum Anfang USB Logs gezogen. Hier liesse sich
>> zumindestens eine Zuordnung von Datenblöcken zu einzelnen Informationen
>> herstellen.
> Das wäre der zweite Schritt.
Dann sag Bescheid

>> Hast du auch gelesen, dass Chips bereits erfolgreich kopiert wurden?
> Nein. Wo steht das?
Weiter oben. Scherz beiseite, müsste ich selber suchen. Im Wesentlichen 
ging das so:
Man besorge sich einen USB Chip mit dem gleichen Controller und 
konfiguriert den mit einem Herstellertool so, dass er aussieht wie der 
TM Chip inkl. Seriennummer.
Dann noch das Image drauf und fertig.
Eigentlich sollte dann noch versucht werden, was passiert, wenn man die 
Informationen im Controller verändert, um herauszufinden was für den TM 
wichtig ist.

>
> Dario

Hallo Dario

Wenn ich mich richtig erinnern kann stand im Patent auch drin, dass man 
mit einem Rechner/Computer den Chip lesen/entschlüsseln kann ohne den 
"Masterkey" zu kennen. Allerdings wird der Thermomix einen Chip nicht 
anzeigen/akzeptieren, der nicht mit dem Masterkey 
"verschlüsselt/erzeugt" wurde.

@Robert L. (lrlr)

>> Als Kopierschutz wäre aber quatsch,
> dass der schon erfolgreich kopiert wurde, hast wohl übersehen?
stimmt, das habe ich übersehen.
Aber es bestätigt meine Aussage.

>> Plain-/Chiphertext Paare erhält, um dann zu überlegen,
>> ob und wie da verschlüsselt wurde.
> gibt es wirklich (aktuelle) Verschlüsselungen die so schlecht sind
> dass die so einen Rückschluss zulassen?
Nein, aber oft werden aktuelle Verfahren falsch angewendet.

Beispiel 1: Die Leute lesen, dass die einzige mathematisch beweisbar
sichere Chifre das One-Time-Pad ist und implementieren das wie folgt.
Im Gerät ist ein 2048Byte Schlüssel, mit dem werden alle Blöcke 
verschlüsselt. Das Fatale ist, dass sie den Algorithmus zwar korrekt 
implementiert haben, Ihn aber falsch benutzen.
Siehe https://de.wikipedia.org/wiki/One-Time-Pad unter dem Punkt 
"Mehrfachverwendung des Einmalschlüssels"

Beispiel 2: ECDSA Signaturen sind sicher. Aber man benötigt, im Laufe 
der Signaturerzeugung eine Zufallszahl, die nicht geheim ist. Wenn man 
zwei Signaturen erzeugt und für Beide die selbe Zufallszahl benutzt kann 
ein Angreifer den Private Key berechnen und das System ist gebrochen. 
Wenn Du jetzt sagst, dass niemand so doof ist, kann ich Dir versichern, 
dass ein Spielekonsolenhersteller genau diesen Fehler gemacht hat, siehe 
https://events.ccc.de/congress/2010/Fahrplan/attachments/1780_27c3_console_hacking_2010.pdf 
Folie 122ff, besonders interessant der XKCD dazu: https://xkcd.com/221/
Nochmal im Klartext: Der Schlüssel liegt hochsicher irgendwo bei dem 
Hersteller, er ist in keiner Spielekonsole gespeichert und nur weil die 
den falsch verwendet haben, wurde er der Öffentlichkeit bekannt.

>> balancierte Bäume und auch Hashtabellen
> du willst "identische Blöcke" finden, ....
Das was Du beschreibst ist aber nicht fertig, dass muss ich 
programmieren

> jetzt gehst du die Datei, Zeichen für Zeichen durch, und schreib den
> Aktuellen Wert (also aktuelles Byte + die nächsten 9) in die hashmap
Das ist eine Möglichkeit, aber das muss man eben programmieren, oder 
hast Du ein fertiges Tool, was das kann? Ich tue mich schwer sowas "mal 
eben" zu hacken.

> IMHO müsste das funktionieren...
Stimmt, auch wenn es bestimmt eleganter ginge, aber wie ich schrieb: ich 
bin eben nicht der PC-Programmier-Guru. Ich habe noch nicht einmal eine 
IDE installiert und musste mir für meine erste Analyse erstmal den gcc 
installieren.

>> Und warum kann 7zip diese 224200 Datensätze auf 7MB
>> packen?
> .. unnützer Müll drinnen ist, dutzendfach identisch,
Wenn man jetzt weiss, was das im Klartext ist, dann sieht die Sache 
schon besser aus.

> falls jemand auf die Idee kommt, gleiche Texte suchen zu wollen.. ;-)
Meine Erfahrung sagt, dass es normalerweise nicht so ist.


Dario

Interessant wäre es zwei verschiedene Kochbücher zu dumpen und den 
"Blödsinn" zu vergleichen, evtl. Ist hier was identisches zu erwarten?

@Waldemar Heimann (vual)
> Interessant wäre es zwei verschiedene Kochbücher zu dumpen und den
> "Blödsinn" zu vergleichen, evtl. Ist hier was identisches zu erwarten?

Interessant wäre es auch zwei gleiche Kochbücher zu dumpen und zu 
vergleichen.
- Haben gleiche Kochbücher die selben Seriennummern?
- Ist der Inhalt ansonsten identisch?

Dario

Dario C. schrieb:
> @Waldemar Heimann (vual)
>> Interessant wäre es zwei verschiedene Kochbücher zu dumpen und den
>> "Blödsinn" zu vergleichen, evtl. Ist hier was identisches zu erwarten?
>
> Interessant wäre es auch zwei gleiche Kochbücher zu dumpen und zu
> vergleichen.
> - Haben gleiche Kochbücher die selben Seriennummern?
> - Ist der Inhalt ansonsten identisch?
>
> Dario

Ich würde gerne helfen, habe leider (noch) keine Aufnahme für den Chip. 
Ich werde zuhause (bin  bis Do. im Ausland) mal was basteln und 
versuchen den Chip mit dd (nur MacOS) zu klonen. Hilft das weiter?

Waldemar H. schrieb:
> Interessant wäre es zwei verschiedene Kochbücher zu dumpen und den
> "Blödsinn" zu vergleichen, evtl. Ist hier was identisches zu erwarten?

Wurde schon weiter oben gemacht.
Die sind Identisch.
Selbst die Seriennummer des USB-Sticks.

Hallo

Wäre es nicht interessant mit einem Sniffer sich mal an die USB 
Schnittstelle zu hängen?
Hatte das oft mit RS232 gemacht, da war das mit einem Y Kabel einfach. 
Bin mir aber sicher das gibt's für USB auch?

Lg

Michael W. schrieb:
> Hallo
>
> Wäre es nicht interessant mit einem Sniffer sich mal an die USB
> Schnittstelle zu hängen?
> Hatte das oft mit RS232 gemacht, da war das mit einem Y Kabel einfach.
> Bin mir aber sicher das gibt's für USB auch?
>
> Lg

Ja das geht. Habe ich auch schon gemacht. Das Log und die Diskussion 
findest du weiter oben im Thread.

Suche mal auf der Seite nach LeCroy

Bis denne
Knochi

Andere Frage:
Wenn es scheinbar nur darum geht die ersten paar Megabyte, VID, PID und 
Seriennummer zu kopieren. Wie sieht es dann mit einem Teensy 
https://www.pjrc.com/teensy oder einem Rubberducky 
http://hakshop.myshopify.com/products/usb-rubber-ducky-deluxe aus? Wäre 
das möglich, damit eine funktionsfähige Kopie zu erzeugen, an der man 
dann einfach rumprobieren könnte, was passiert, wenn man einzelne Bytes 
ändert.

Noch was: Hat irgendjemand schon mal eine Sammlung an solchen Daten in 
der Art
Kochbuch | VID | PID | s/n | checksum(Byte0-xMB) | checksum(all)
angelegt?

Oder hat jetzt noch jemand eine Quelle für einen funktionierenden Stick?

Dario

Hallo miteinander,

ich habe jetzt die letzten zwei Tage damit verbracht hier mitzulesen und 
zu begreifen was bisher passiert ist.

Ich selber habe keinerlei Erfahrungen im Bereich Code Knacken oder 
tiefere Analysen.

Ich habe einige Ideen und Fragen zusammengesammelt:

1. Wisst ihr schon was genau in dem CDFS drin ist?
2. Ist der Bereich des CDFSs eventuell rein die SQLite DB?
=> wie beispielhaft / pseudocode dd if=sqlite.db of=/dev/cdfs
3. Gehen wir davon aus, das die SQLite DB die Rezepte beinhaltet - wäre 
es dann nicht möglich den Bereich der DB soweit einzugrenzen - sagen wir 
64MB - (habe gelesen das jemand den Stick auf 1GB beschränkt hat), 
sodass wir - auch wieder aufgegriffen eine Plaintextatacke starten 
könnten auf den Header Descriptor einer SQLite Datenbank (Verkleinerung 
auf 64MB um die Analyse kleiner zu halten)
4. Ich habe mittlerweile aufgenommen, das sich datenblöcke mit 
anscheinend Nutzdaten wiederholen -> könnte dies das "Trennzeichen" bzw 
der Beginn der Spalte darstellen?
5. Interessant fand ich auch den Ablauf bei der erstmaligen 
Initialisierung des Kochbuchs erste und letzte paar KB - danach die 
jeweiligen davor - Können wir dabei davon ausgehen das die ersten und 
letzten KB in Teilen den Schlüßel, bzw die Antwort darauf enthalten, 
sodass eventuell im Bereich dazwischen die SQLite DB liegt? --> würde 
bedeuten, wenn wir den Bereich extrahieren, könnten wir eventuell an die 
DB rankommen.
6. Ist - wie schon mal vermutet die SQLite DB in einem zip file, welches 
eventuell verschlüßelt ist und jedes mal unverschlüßelt ins RAM des TM 
kopiert wird?
==> Gedanke dahinter -> hat das zip file ein einfaches Passwort, welches 
innerhalb mehrerer Tage / Wochen extrahiert werden könnte?

Dario C. schrieb:
> och was: Hat irgendjemand schon mal eine Sammlung an solchen Daten in
> der Art
> Kochbuch | VID | PID | s/n | checksum(Byte0-xMB) | checksum(all)
> angelegt?

Das war auch mal mein Ansatz, hat aber kaum jmd. mitgemacht. Kannst es 
gerne nochmal probieren, ich würde mich mit drei Chips beteiligen...

moin - ich habe mir mal das image von hier geladen und durch den reveal 
laufen lassen den es unter https://f00l.de/hacking/ gibt. sinn dahinter 
war, zu sehen was eventuell in diesem image ist - habe mal die ausgabe 
als datei angehängt. vielleicht bringt das ja jemandem etwas.

@ thomas H. wo hast du das image her? die links sind doch alle tot?
habe ich da einen übersehen?

@timtanner
hi, ich weiss nicht mehr welcher beitrag das war - auf jeden fall gab es 
hier noch einen funktionsfähigen link.

mit meinen forschungen bin ich auch noch nicht viel weiter gekommen, mir 
gehen die ideen aus - und leider sieht das hier auch nicht wirklich 
lebendig aus...

Ich konnte keinen funktionierenden Link finden. Wenn du mir dein Image 
des Chips zur Verfügung stellst, kann ich mal versuchen, was 
rauszufinden.

hier gibts mal neuen input!
hat meine frau heute von so ner thermomix trulla bekommen. ;-)

Es gibt ein vegetarisches Buch. Ist das nicht toll!!!!!!!!!!!!!!!!

Andreas S. schrieb:
> hier gibts mal neuen input!
> hat meine frau heute von so ner thermomix trulla bekommen. ;-)

Oh Hund. Wer gibt denn solche Texte an Kunden raus?

Also wenn das kein Fake ist, drängen sich mir direkt zwei Fragen auf.

1. Ist die nötige Software schon auf dem Gerät, oder hat der WLAN-Chip 
dann einen Speicher, welcher ein Update ausführt?

2. Vorwerk knöpft dem Kunden wahrscheinlich wieder 100€ für ein Teil ab, 
in dem sie einen 8,50€ USB WLAN Stick einbauen. Funktioniert auch ein 
handelsüblicher USB WLAN Stick?
Eventuell muss hier, analog zu machen SmartTVs, auf einen bestimmten 
Chipsatz geachtet werden.

Hat schonmal jemand versucht einen Linux kompatiblen WLAN Stick 
anzustöpseln?

Bis denne
Knochi

David N. schrieb:
> Also wenn das kein Fake ist, drängen sich mir direkt zwei Fragen auf.
>
> 1. Ist die nötige Software schon auf dem Gerät, oder hat der WLAN-Chip
> dann einen Speicher, welcher ein Update ausführt?
>
> 2. Vorwerk knöpft dem Kunden wahrscheinlich wieder 100€ für ein Teil ab,
> in dem sie einen 8,50€ USB WLAN Stick einbauen. Funktioniert auch ein
> handelsüblicher USB WLAN Stick?
> Eventuell muss hier, analog zu machen SmartTVs, auf einen bestimmten
> Chipsatz geachtet werden.
>
> Hat schonmal jemand versucht einen Linux kompatiblen WLAN Stick
> anzustöpseln?
>
> Bis denne
> Knochi

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.

Jetzt gibt es auch eine offizielle Vorwerk Seite zum WLAN-Chip

http://cook-key.de/

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

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.

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.

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.

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 ;) ;)

Enttäuschendes Testergebnis für den Thermomix
http://www.welt.de/wirtschaft/article149298360/Enttaeuschendes-Testergebnis-fuer-den-Thermomix.html

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 ;-)

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.

Noch ein aktueller Test von TITANIC Stiftung Magentest:

http://www.titanic-magazin.de/news/titanic-stiftung-magentest-der-thermomix-tm5-von-vorwerk-7720/

Gruß

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!

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?

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?

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 :-)

Zufällig jmd. aufm 32C3?

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.

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. ;-)

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.

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 ;)).

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 :(

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.

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.

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

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.

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.

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. :-)

Leute, bitte beim Thema bleiben.

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.

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.

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

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!

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...

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.

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

Kann das Update beliebig oft eingespielt werden oder nur einmal ?

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

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!

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.