Hier meldet sich mal Iranian from Hell aus dem schönen Libanon ... Wenn jemand einige Datensätze vor und die korrespondierenden Datensätze nach der Entschlüsselung loggen könnte wäre die Sache sehr einfach. Habe hier 4 Tesla-karten mit 530 Gigaflops pro Stück, die sogar MD5 Hashes in maximal 24Stunden knacken können, für die herkömmliche Rechner 1 oder 2 Jahre bräuchten. Die distributed Engine auf CUDA basis würde ich dann natürlich implementieren ... falls jemand auch noch schnelle Rechner hat mit entweder Tesla oder zumindest mit ner neueren NVIDIA karte könnte man sich die Arbeit dann aufteilen!
zwei kurze Hinweise zum PIC: 03ff 0c04 movlw 0x04 d.h. Reset-Vektor auf 0x3ff passt zum 12F509 und nicht zum 12F508 ansonsten wäre das Wort auf 0x1ff lesbar, was es aber nicht ist. Ich bin beim Auslesen nicht auf 0000 0ff6 xorlw 0xf6 gekommen sondern auf 0000 0a60 was einfach ein Sprung über die ausgelesene Routine in den nicht lesbaren Bereich wäre. Zum Code: Der auslesbare Teil ist doch zunächst ein rückgekoppeltes Schieberegister mit 80 bit. Von diesem wird in jedem Schritt ein Bit neue generiert und wieder rückgekoppelt. D.h. möglicherweise äussere Schleife mit 64 Durchläufen { 4 Schritte Schieberegister XOR Verknüpfung Bank0 ^ Bank1 -> Bank1 unbekannter Code } Zur Ausführungszeit: ich komme auf 3*(45+1)+45=183 Zyklen Dazu kämen noch ~40 für die äussere Schleife Damit sollte das ganze etwa 14ms dauern (1Zyklus -> 1 Mikrosekunde). Zu den verwendeten Eingangsdaten: das Ergebnis hängt nur exakt von den 82 Eingangsbits (42 bit Wetterdaten + 40 bit Datum/Uhrzeit) ab. Bei den Wetterdaten sind 2 konstant auf 0, damit bleiben 80 bit Eingangsdaten. Vorhergehende Daten spielen keine Rolle. Zum PIC Auslesen: Falls die 50mV sich auf den Report von Skorobogatov beziehen: da ging es um den 16F84A. Das ist wohl leider nicht direkt übertragbar. Zumindest habe ich bisher nur gesehen, dass Code und Code Protection völlig synchron gelöscht werden und der Code Speicher viel früher leer ist. Wenn man den Vorgang vorzeitig abbricht, ist immer zuerst der Code Speicher leer. Das heisst allerdings nicht, dass danach keine auswertbare Information mehr vorhanden ist. Wer sich da genauer mit beschäftigen möchte, kann ja mal nach Data Remanence suchen. Zum WDT: Da das IC erst nachdem es schon >30s nach dem letzten Reset gelaufen ist, wirklich bereit ist sinnvolle Ausgangsdaten zu liefern, kann man wohl davon ausgehen, dass der WDT Timer genutzt wird um diese 'Anlaufsperre' zu realisieren. Die gleiche Sperre greift, wenn Daten decodiert worden sind. Sonst könnte ja jemand auf die Idee kommen, einfach mal viele verschiedene Eingangsdaten nacheinander durchzuprobieren.
@Iranian: Die Datensätze findest du weiter oben. Sind allerdings wohl nicht 100% fehlerfrei! Deine Infrastruktur klingt interesssant! Du kannst damit auch loslegen, wenn du nicht den Schlüsselalgorithmus kennst? Wie sieht dann das Ergebnis aus?
Abdul: Mit sicherheit werde ich dann bekanntes einbauen, aber theoretisch würde es auch ohne Informationen gehen! Diese Karten können mehrere Billionen Vergleiche pro Sekunde machen, sind eben "High Performance Computing" Karten ... Über kurz oder lang findet man schon die richtige Verknüofung aus Binären operationen. Komplizierteres wie PGP kann man bei nem PIC ja wohl ausschliessen. Leider haben die Logs von oben nur die verschlüsselte information. Notwendig wäre die Wetterstation so mitzuloggen dass man die Daten auch in unverschlüsselter form hätte. Ein kinderspiel dann die Maske zu berechnen, egal wie oft da subtrahiert wird. Ich persönlich tippe ein 1 Sekunde rechenzeit mit den Teslakarten :)
Sollte der Xor richtig sein, und der WDT genutzt werden, dann kann das testen durch externen Reset beschleunigt werden.
Abdul: Habe mal einen Test gemacht: Hab ein 85bit wort genommen und konsequent alles möglichen xor/and/or/shift/etc operationen in abhängigkeit von konstanten im rahmen 0-32 sowie in abhängigkeit von den anderen bits gemacht (also jedem einzelnen bit sowie allen möglichen binären verknüpfungen von zwei oder mehreren bits) Das dann in einer Rekursionstiefe von 100. Die Karten haben exakt 1,2 Sekunden gebraucht :) d.h. ich habe alle möglichen Verschlüsselungsvarianten des 85bit wortes in abhängigkeit jeder kombination der 85bits sowie allen konstanten von 0 bis 32 in nur 1,2 Sekunden berechnet ... Machen wir das für 4-5 Datensätze so können wir sehr schnell rausfinden wie genau gexort etc. pp. wird!
@Iranian: Du scheint neu mitzulesen. Leider ist man allein mit Lesen des Threads locker ne Stunde beschäftigt. Eine Zusammenfassung findest du hier: http://www.mikrocontroller.net/articles/DCF77_Wetterinformationen Die Mitschnittdaten hier sollten wohl gehen: Beitrag "Re: AVR: Wetterinformationen über DCF77" Es gibt wohl von verschiedenen Autoren Sätze! Kannst du zu deiner Hardware mehr sagen? Könnte mir vorstellen, daß man die für viele Dinge gut gebrauchen könnte. Auf jeden Fall sehr interessant. Alles natürlich rein akademisch. Ob du deine Sekunde halten kannst, wage ich zu bezweifeln! Ich warte schon mal die einstweilige Verfügung gegen Mikrocontroller.net am Montag ab... Also den Thread mit allen Daten vorher downloaden! Gruß - Abdul
@Iranian: Ich bin leider nicht so das Mathematik-Genie. Kann daher deinen Angaben nur schwer folgen. Auch wenn ich mal erfolgreich einen vom Hersteller als unknackbar angepriesenen und mit Preisgeld ausgeschriebenen 'USB'-Stick geknackt habe. Das ist allerdings verjährt, sonst hätte ich es jetzt nicht geschrieben :-) Meine Stärke ist Hardware digital und analog von DC bis HF, und unorthodoxe Denke. Mich würde ja mal brennend interessieren, was du so täglich machst. Klingt ja sehr geheimnisvoll und viel interessanter als das Fernsehprogramm. Werde jetzt aber erstmal ne Kuchenpause einlegen. Habe auch noch andere Baustellen. Auch interessante ;-) Vielleicht bist du ja der Mann, auf den hier alle warteten. Wir brauchen einen richtigen Kryptofreak! Gruß - Abdul
Abdul: Klingt jetzt vielleicht ein bisschen behämmert, aber beruflich arbeite ich auf einem Fischkutter .... Mit dem ganzen Kryptographie-Gedöns bin ich auch nicht wirklich vertraut, ich weiss nur dass die High Performance Computing Karten in der lage sind binnen Sekunden alle möglichen Verschlüsselungsmöglichkeiten die auf Binären Operationen beruhen und nur von den ca 100 bits sowie konstanten werten im 32bit bereich zu berechnen...und das mehrere hundert mal wiederholt auf sich selbst angewendet. Sprich: wenn wir einen datensatz (vorher/nachher) haben haben wir vielleicht mehrere huntert tausend möglichkeiten von unverschlüsselt nach verschlüsselt zu kommen. Der zweite datensatz hat auch etwa soviel. wenn wir mehrere haben picken wir uns einfach die methode raus wie bei allen datensätzen als mögliche lösung vorhanden ist.
@noch einer: danke für den Hinweis. Dann macht das ganze auch mehr Sinn. Ich habe mal an einen Ausgangspin einen externen 10k Pull-up gehängt. Der Pin geht nach einem Reset nach ca.14us auf low. Da aber der analysierte Teil deutlich länger dauert, hat das alles nicht so recht gepasst. Ab Adresse 1 scheint dann eine Unterroutine zu sein. Gruß, Walter.
Ich werde jetzt einfach mal anfangen eine vernünftige implementierung auf die beine zu stellen und werde sie dann hier posten. ich arbeite mit CUDA, sodass nur leute mit TESLA karten oder mit neureren Grafikkarten wie der GTX280 (die für mathematische operationen sehr gut missbraucht werden kann) davon gebrauch machen können!!! Wäre schön wenn jemand die daten vor und nach der verschlüsselung loggen könnte. Ansonsten wird schonmal das tool stehen um später evtl. die bitmasken (auch rekursiv angewandt) berechnen zu können Ich werd den code einfach halten :)
@Iranian Vorher und nachher daten sind hier zu finden: http://www.mikrocontroller.net/attachment/24819/20070716.txt
NixChecker: Wäre lieb wenn du mir kurz erklären könntest was genau jetzt was ist bei den logdaten .... sind das schon die IN-werte über die 3-minuten phase der wetterdatenübertragung? und wie kommt es dass beim out die stunden angaben nicht erwähnt worden sind. wenn ich das zu 100% verstehe wie die logdaten zu lesen sind sollte ich morgen eigentlich die lösung haben!
Hi, hier mal ein log von mir mit vorher-nachher Daten. Die ersten 59 Bits je Reihe sind das was über die Antenne reinkommt. Bei jeder dritten Zeile hängen die 82 Bits die in den Chip reingehen dran, der Rest dahinter ist das was wieder rauskommt. Die Daten sind 100% richtig. Aufgrund meines Auswerteverfahrens kann ich das ohne weiteres behaupten. MfG
Angehängte Dateien:
-
DCFlog.png
3 KB
und hier nochmal welche Bits in den Chip reingehen. Ist alles farblich markiert und sollte selbsterklärend sein. Die Nullen zwischen den farblichen Feldern sind nur zum auffüllen. Es gehen also weder Status-Bits noch ParitätsBits rein.
Um konkret was zu machen, könnte Walter nicht die Sleep-Zeiten nochmals nache einem HW-Reset auslesen, würde bez. Patch-Code helfen.
@Iranian
Eingabe+Ausgabe+Statusmeldung:
><0100110011000101111101000101010001001000100100000000000000011010001110
010011100000010001000000010011110110>
Eingabe: insgesamt 82 bit lang
Davon:
Datapack1: 14 bit
Datapack2: 14 bit
Datapack3: 14 bit
Minute: 8 bit
Hour: 8 bit
Day: 8 bit
Month: 5 bit
Weekday: 3 bit
Year: 8 bit
Ausgabe: insgesamt 22 bit lang + 2 bit Statusmeldung
Davon:
Wetter für den Tag: 4 bit
Wetter für die Nacht: 4 bit
Unwetter: 4 bit
Niederschlag: 3 bit
Switch: 1 bit
Temperatur: 5 bit
Statusmeldung: 2 bit
@Gast (Gast): evtl. verstehe ich deine Logdatei falsch, aber bei dir ist jeweils bei der 3. Zeile (die Lange, welche alle Infos enthält) die letzten beiden Stelle oftmals 11. Bei dexters Log sind die meistens 10. Ich meine, die 11 stehen für fehlerhafte Daten!? Aber evtl. täusche ich mich auch. Deine .png Datei ist IMHO richtig. P/\UL Und falls hier mc.net wirklich dicht gemacht werden sollte ;) haben wir immer noch freenet... (http://de.wikipedia.org/wiki/Freenet)
Nein, die letzten beiden Bits sind keine Status-Meldung. Zumindest bei meinem Chip aus der Meteotronic Start konnte ich das ausschließen. Die letzen beiden Bits haben manchmal (nicht immer) zum Tageswechsel gewechselt. Und außerdem wäre es doch recht unrealistisch wenn innerhalb von 3 Stunden immer genau ein Bit in den verschlüsselten Daten falsch wäre, oder?
P/\UL wrote: > falls hier mc.net wirklich dicht gemacht werden sollte ;) haben wir > immer noch freenet... (http://de.wikipedia.org/wiki/Freenet falls es dicht gemacht wird kann ich ganz schnell ein forum einrichten, welche adresse nicht veröffentlicht wird, die adresse könnt ihr bei mir per pn bekommen...
Wenn es sich nicht um eine echte Verschlüsselung, sondern nur um eine "Verwurschtelung" handelt, könnte man vielleicht die dahinter liegenden Funktionen mit einem Neuronalem Netz finden. Das war vor zwei Semestern bei mir ein Fach an der Uni. Ein Multi-Layer-Perceptron(MLP) kann theoretisch beliebige Funktionen realisieren und diese durch Eingabedaten + Korrekte Ausgabedaten finden. Gelernt wird aber durch Gradientenabstieg, was bedeutet das ganze läuft in ein lokales Minima der Fehlerfunktion. Deswegen gebe ich einem MLP bei einer echten Verschlüsselung keine Chance und die doch sehr gleichmäßige Verteilung von 0 und 1 sahen mir danach aus, aber bei ein paar einfachen logischen Verknüpfungen wäre das vielleicht einen Versuch wert. Nebenbei ist die Methode tolerant gegen ein paar Datenfehler. Aber bitte denkt bei der ganzen Aktion an Andreas, also Forumswechsel bevor es zuspät ist.
Walter, könntest du bitte auf mein MP antworten, möchte ungern den Patch ins Forum stellen.
Zum Patch, ist verdammt eng geworden, aber es geht. Sprich mittels externem MCU ist man dann imstande, für jeden Befehl den Speicherdump zu bekommen. Daraus lässt sich dann sicherlich der Alghoritmus ableiten.
Protokollanalysen sind meines Wissens nicht verboten, das veröffentlichen von Informationen zum unberechtigtem Zugriff auf verschlüsselte Daten dagegen schon. Auch wenn wie hier nicht kommerzielle Absicht, sondern sportlicher Ehrgeiz dahintersteckt. Da das rechtlich erlaubte meiner Einschätzung nach jetzt ziemlich ausgelotet sein dürfte, und ich in diesem Fall (im Gegensatz zu WLAN-Verschlüsselung o.ä.) kein öffentliches Interesse an einer Analyse erkennen kann, möchte ich den Thread an dieser Stelle sicherheitshalber schließen.
Thread beobachten
Seitenaufteilung abschalten