Das mit den lockbits war auch einer meiner ersten Gedanken, wobei ich sagen muss das das meine erste bastelei in diese Richtung ist. Gibt es eingentlich gute Literatur zum Thema Reverseengineering,(wobei mich die Physikalischen Methoden mehr interessieren)? Die Hoffnung,das man den IC selber mit Hausmittlen analysieran kann hab ich aber eingentlich schon aufgegeben, da sie Strukturen ja schon recht klein sind ; ) Bin aber gern für neue vorschläge bereit. Das es sich um den angegebenen Pic handelt kann ich auch bestätigen, denke ich. Das mit den schwierigen Empfangsbedingungen war so nicht gemeint, mein Vorschlag zielte eher in Richtung Redundanz. Ich wollte so lediglich Sicherstelen, dass der Datenstrom wirklich komplett und fehlefrei über einen Langen Zeitraum mitgeloggt wird, was ich für die Entschlüsselung einer einigermaßen guten Verschlüsselung also obligatorisch betrachte. btw: ich wohne zzt in Aachen, habe keinen röhrenmonitor (in Betrieb) und auch sonst wüsste ich keine Störquelle. Ich denke das Problem als ich den Wecker gestern auf Empfang testete war, das die eingebaute funktion zum Empfangstest sehr träge ist. Ja auch meine Uhr benutzt eine Ferrit Antenne. >Interessant wäre auch, ob es vielleicht andere Funkwecker gibt, die >nicht genau diesen PIC haben, sondern über Lizenz von HKW eine eigene >Implementation. Diese müßte ja kompatibel sein und ist eventuell >leichter hackbar. Das wäre in der Tat interessant, wobei ich es für sehr unwahrscheinlich halte, da es meiner Meinnung nach grade ein wesentlicher Sicherheitsaspekt ist den decoder auszulagern, und den Personenkreis der eingeweihten klein zu halten. >Dein Freund ist Kryptoanalytiker? Wenn er dann auch von der praktischen >Fraktion ist, wäre das interessant. Er ist in der Tat praktisch versiert und sehr vielseitig gebildet, was diesen Bereich angeht. Er sprach diesbezüglich auch von Verfahren um das entschlüssel wirklich systematisch anzugehen. Davon verspreche ich mir mehr erfolg, als vom bloßen Versuch in die zahlreichen Bits irgendetwas herein zu interpretieren. Er meinte, wenn es keine andere Lösung gibt, dann aollte ich ihm irgeneine schnittstelle bauen, die es ermöglicht den pic mit daten zu füttern und abzuhören. Dazu noch eine frage: Wieviel Datensätze kann der pic in einer gewissen zeit dechiffrieren, wenn man ihn lässt. Also ich meine, wenn man ihn vom Rechner aus füttert, wie viel datensatz pärchen (Verschlüsselt<=>unverschlüsselt) bekommt man in sagen wir mal einer stunde berechnet? und gibt es eine Möglichkeit diesen Durchsatz zu erhöhen(z.b. takung)?
zuerst mal die Frage, wo es gerade wieder einen solchen Wecker zu einem guten Preis gibt? Ich mache auch noch mal ein paar Mutmaßungen: Das Füttern mit Daten halte ich für den wichtigsten Aspekt bei dieser Arbeit. Es ist klar, dass aufgrund des Zeitscheiben Verfahrens die Uhrzeit während der Übertragung der Wetterdaten für einen Standort immer die gleiche sein sollte. In die Verschlüsselung könnte also lediglich das Datum eingehen. Das könnte man verifizieren, in dem man den Chip mehrfach mit der gleichen verschlüsselten Wetter-Information und bekannten und gefälschten Datumsinformationen füttert. Das sollte zeigen, in wie fern und in wie weit das Datum das Ergebnis beeinflusst. Was für meine Idee spricht, ist die Information aus den wenigen Unterlagen über das Protokoll, das bestimmte Standorte an eine bestimmte Uhrzeit koppelt. Und es ist auch sinnvoll, weil man eigentlich den kompletten Empfänger still legen kann, wenn für den Standort irrelevante Informationen gesendet werden. Alte Funkwecker schalten ja auch nur zwischen 02:00 und 03:00 Uhr ein und synchronisieren einmal. Die neuen tun das eben zu der für ihren Standort sinnvollen Uhrzeit. Ein wirklicher Streamchiffre ist auch nicht wirklich möglich, da der Chip dann keinen Anfangsvektor hätte, wenn er in Betrieb genommen wird. Es kann also nur eine Abhängigkeit vom Datum geben, bzw. in den nicht fürs Protokoll genutzten Bits eine weitere Abhängikeit eingebaut sein. Diese Bits sollten aber auch Redundanzinformationen erhalten und können nicht für beides gleichzeitig eingesetzt werden. Aufgrund der wenigen Bits insgesammt, kann auch mit einem 'schweren' Algorhythmus nur eine leichte Verschlüsselung erreicht werden. Denke ich... Eine weitere Idee, warum diese Wecker das zeitgesteuerte Einschalten nicht machen, kann nur drei Gründe haben: 1) Die Batterie-Hersteller subventionieren diese Wecker 2) Die Chips reduzieren die Laufzeit pro Batterie kaum und so ist die Software billiger 3) Meine obigen Ideen sind falsch und es ist ein in den 'leeren' Bits, dem Datum und der Uhrzeit untergebrachter Streamchiffre, der da fröhlich herum-mutiert und den Code ziemlich unknackbar macht. Gruß, Ulrich
also ich muss sagen, dass ich punkt 3 für sehr unwahrscheinlich halte, die Vergangenheit hat gezeigt, dass viele Firmen "unknackbare" system erscahffen haben sollte. Und ich denke grade an Premiere z.b. Obwohl bei denen die Verlustspanne noch etwas höher liegen sollte ; ) ich halte punk 2 für realistischer. Die leute die sowas entwerfen sind wohl leider keine Perfektionisten. Warum auch, wenns onehin niemand jemahls mehr anschen wird (falsch ged8 ;) Um deine erste Frage zu benatworten, die ich leider Gestern übersehen hatte: Ich habe meinen wecker auf ebay ersteigert, hat mehrere auktionen gedauert, aber ich denke mit 26€ inclusive versand, hab ich nicht zu viel ausgegeben. generell: sofortkaufen ab 40€, und auktionen meist so 30-35 €. also alles in allem bezahlbar. btw: mich würde mal interessieren, wieviel prozent des umsatzes an leuten abfällt, die das ding auseinander nehemen ; ) Was in interessant finde: ich beobachte in den letzten Tagen, dass meine Uhr wohl Teilweise Datensätze nur halb entschlüsselt: an zwei tagen fehlt ein temperatur wert. Kann sich das jemand erklären? fehler im system? ein übertragungsfehler sollte doch bei einem Verschlüsselten paket alle daten unbrauchbar machen, oder eben keine, oder sehe ich das falsch? nun ist aber Schlafenszeit.
Hallo, auch ich habe die Meteotronic Start Wetterstation und habe festgestellt das dort die Pinbelegung etwas anders aussieht als oben beschrieben. Das Protokoll ist allerdings das selbe. Ein paar Kommentare zu den Erkenntnissen hier im Thread: Das die letzten beiden Bits der Ausgabe des Chips als Indikator fuer die Fehlerkorrektur dienen kann ich nicht bestaetigen. Die Bits waren gestern z.b. IMMER_ 11 und heute waren sie bis jetzt _IMMER 10. Scheint also eher was mit dem Datum zu tun zu haben, wobei die Frage ist warum der Chip das an die Station weitergibt. Die kennt das Datum ja ohnehin schon. Was hier bisher noch gar nicht zur Sprache kam ist das es 3 Lizenzen fuer den Empfang der Daten gibt (daher wohl die unterschiedlichen ICs!?). Naemlich eine a-Lizenz mit der man die Daten fuer Tag1 entschluesseln kann, eine b-Lizenz mit der man die Daten fuer Tag1 und 2 entschluesseln kann und noch eine c-Lizenz fuer alle vier Tage (siehe http://www.meteotime.com/data_access/meteotime/downloads/meteotime_doc_25_9_06.pdf ). Es muss also davon ausgegangen werden das die Daten fuer Tag1 anders verschluesselt sind wie die fuer Tag2 und diese dann wiederum anders wie die fuer Tag3 und 4. Die Meteotronic Start Wetterstation gibt von 0:00 Uhr - 2:59 Uhr, von 6:00 Uhr - 8:59 Uhr und von 9:00 Uhr - 11:59 UHR (alle Zeiten MESZ) ALLE Wetterdaten an den Chip weiter. Es findet also alle drei Minuten eine Kommunikation statt obwohl die Daten gar nicht gebraucht werden. Ziemlich merkwuerdig, oder? Kann sich da einer einen Reim drauf machen? Gruss
ups. Die letzte Zeitspanne muesste "12:00 Uhr - 14:59 Uhr" lauten, nicht "9:00 Uhr - 11:59 Uhr". Also so: ######### ######### ######### ----------------------------------------------------------------- 0 3 6 9 12 15 18 21 0 Die "#" zeigen Zeiten an wo alle drei Minuten eine Kommunikation stattfindet. Es kann auch nicht daran liegen das es Tagesdaten sind. Mein erster Gedanke war naemlich das die Station schon an den verschluesselten Daten erkennt ob es sich dabei um Tages- oder Nachtdaten handelt. Dagegen spricht aber das das ganze zwischen 18:00 Uhr und 20:59 Uhr nicht passiert obwohl auch da Tagesdaten gesendet werden.
Sorry fuer den triple-post. Hier das ganze nochmal anders formatiert. Hoffe so klappts: ######### ######### ######### ----------------------------------------------------------------- 0 3 6 9 12 15 18 21 0
Das mit der Übertragung NUR zu vordefinierten Zeiten (wie es ja selbst in der Protokollbeschreibung steht) glaube ich inzwischen nicht mehr. Es mag vielleicht für "aktualisierte" Daten gelten, aber ansonsten gehe ich davon aus, daß die Wetterdaten permanent übertragen werden. Anders kann ich mir nämlich nicht erklären, daß eine bei Penny um 17 Uhr neu gekaufte DCF-Wetterstation (von TFA) bereits um 21 Uhr des gleichen Abends den ersten Wetter-Wert im Display (Nachttemperatur für Tag 3) anzeigt. Bis zur kompletten Anzeige aller Daten hat es allerdings 24 Stunden gedauert. Das interessante an diesem Modell ist übrigens, daß es absolut keine Pufferspeicher besitzt. Sobald man die Batterien rausnimmt, hat die Station alles vergessen, was sie je wußte und der Synchronisationsprozeß neu beginnt. Gleiches gilt für einen Wechsel der Vorhersage-Zone - es werden keinerlei Daten vorgehalten sodaß auch dabei die vollständige Synchronsation 24 Stunden dauert. Im Gegensatz dazu speichert meine Mete-On-1 die Wetterdaten sämtlicher Zonen, sodaß die Werte bei einem Zonenwechsel sofort zur Verfügung stehen.
Wenn du sie um 17 Uhr aufgestellt hast und eine Region >40 gewaehlt hast dann kommt die Nachtinformation fuer Tag3 noch zwischen 17 und 18 Uhr MESZ. Ist also nicht ungewoehnlich.
ich hatte die Station in Region 12 benutzt. Falls es jemanden interessiert, die METE-ON-1 gibt es aktuell bei www.reichelt.de für 179,90 Euro unter der Artikel Nr. WS METE-ON 1
Hallo, ich lese nun auch schon einige zeit mit und möchte mal meine gedanken dabei zur diskussion stellen. 1. kauf einer wetterstation: wenn es leute geben die es geschafft haben für nur 30euro soetwas zu kaufen, wieviel kostet soetwas dann wenn man eine sammelbestellung tätigt? mir fehlt leider die erfahrung und die kontakte, aber vielleicht geht es genau "dir" anders? ;-) 2. wann kommt was: gut, alle 3 minuten scheint eine neue wetterinformation zu kommen (welche auch und für welche region auch immer), doch welche info zu welcher zeit kommt bleibt dabei ja noch offen. wenn man nun jeden tag zur gleichen zeit die batterie entfernt, kommt dann immer wieder die gleiche wetterinformation als erstes? also z.b. immer zuerst eie temperatur für tag 2? wo ich dann auch stutzig geworden bin ist die message von "Gast" >Wenn du sie um 17 Uhr aufgestellt hast und eine Region >40 gewaehlt hast >dann kommt die Nachtinformation fuer Tag3 noch zwischen 17 und 18 Uhr >MESZ. Ist also nicht ungewoehnlich. woher weiß man das >region 40 die infos zu der uhrzeit bzw. in dem fenster kommen? hab ich etwas verpasst? 3. wenn also ein zeitfenster hat, in dem sich eine gewisse info einstellt, dann könnte man den input doch mitloggen und anschließend noch mal seperat in den chip schieben und so genau den bitstream erkennen der die info auslöst. also, was sagt ihr dazu?
Wann welche Region gesendet wird ist kein Geheimnis. Das steht sogar in dem Patentblatt was auch hier im Thread und in dem Wiki-Artikel verlinkt ist. Die Uebertragung der Tagesdaten fuer Tag1 beginnt um 0:00 Uhr MESZ (10:00 Uhr UTC) mit Region 0. Um 0:03 Uhr kommen die Tagesdaten fuer Tag1 fuer Region 1, dann Region 2, 3, 4, usw. Ab 3:00 Uhr das gleiche mit den Nachtdaten fuer Tag1. Ab 6:00 Uhr das gleiche mit den Tagesdaten fuer Tag2. ... Ab 18:00 Uhr das gleiche mit den Tagesdaten fuer Tag4. Von 21:00 Uhr bis 23:59 Uhr kommen dann noch die vier Uebertragungen fuer die 30 restlichen Regionen. Also Tages und Nachtdaten jeweils 1,5h versetzt. Die moegliche Uebertragungsrate ist somit vollstaendig ausgeschoepft.
Hallo, noch ein paar Ideen: - Verfahren zur Fehlerkorrektur herausbekommen. Das muß direkt mit den gesendeten Daten arbeiten, weil schon ein falsches Bit die Entschlüsselung verhindern würde. - Mit einem Oszilloskop den Stromverbrauch beim Entschlüsseln aufzeichnen, Korrelation mit den Daten suchen, wenn man Glück hat, bekommt man etwas über den Schlüssel heraus. - Den Kontroller beim Entschlüsseln mit grenzwertiger Stromversorgung ärgern bis er Fehler macht und dadurch evtl. etwas über den Schlüssel verrät. Jürgen
> - Den Kontroller beim Entschlüsseln mit grenzwertiger Stromversorgung > ärgern bis er Fehler macht und dadurch evtl. etwas über den Schlüssel > verrät. Man kann das versuchen, ist aber mittlerweile bei den Chipherstellern usus, das zu verhindern. Ob der PIC das macht weiß ich nicht. Also sollte es für die drei Lizenzvarianten drei verschiedene ROM-Versionen geben? Mir erschließt das mit den Lizenzen nicht so recht. Es besteht keinerlei Möglichkeit, abundzu andere Vektoren in die Datenübertragung einzuschieben? z.B. um uns zu verwirren oder den Dechriffrierer auf einen anderen Schlüssel umzuschalten? Gruß - Abdul
> Also sollte es für die drei Lizenzvarianten drei verschiedene > ROM-Versionen geben? Mir erschließt das mit den Lizenzen nicht so recht. Es koennte auch sein das die Hersteller der Stationen einfach Chips bekommen mit einer Software drauf die einfach keine Daten ausgibt wenn eine falsche Uhrzeit eingegeben wird. Mit "falsch" meine ich eine Uhrzeit zu der Daten gesendet werden die mit dieser Lizenz nicht freigeschaltet sind. > Es besteht keinerlei Möglichkeit, abundzu andere Vektoren in die > Datenübertragung einzuschieben? z.B. um uns zu verwirren oder den > Dechriffrierer auf einen anderen Schlüssel umzuschalten? Nein. Die Sache mit dem Schluessel uebertragen faellt sowieso flach weil sonst eine Station nach dem einschalten erstmal auf einen neuen Schluessel warten muesste. ---- Noch was zur Spannungsversorgung. In dem im Thread verlinkten Datenblatt zu dem Dechiffrier-IC steht eine max. Spannung von 3,6V. Bei der Meteotronic Start haengt der Chip allerdings direkt an der Batteriespannung (3x 1,5V = 4,5V). Ich hab die Station mal testweise mit 3,0V laufen lassen, aber da erscheint schon die anzeige "Bat". Das koennte allerdings auch mit den unterschiedlichen ICs zusammenhaengen.
Das was mir am meisten erfolgsversprechend erscheint ist das Mitloggen von Eingangs- und Ausgangsdaten von diesem ominösen Chip. Das dürfte kein großer Aufwand sein und kann automatisiert ablaufen. Das sollte über mehrere Tage gemacht werden, um z.B. festzustellen ob auch Datum bzw. Uhrzeit Einfluss auf den Entschlüsselungsalogrithmus haben. Wenn man dan genug Daten hat könnte man vielleicht den Schlüssel herausfinden. Jetzt kenn ich mich aber in Kryptografie überhaupt nicht aus. Ich weiß nur dass es nicht einfach sein wird den Schlüssel herauszubekommen. Ich denke das die Ingenieure, die das Protokoll entworfen haben, schon ein bisschen Gehirnschmalz hineingesteckt haben.
Hmm... Natürlich seriell ;) War ein wenig schnell eben. Aber in welchem Timing? Nachdem der Prozessor die Daten der ersten Minute bekommen hat, kommt da schon was raus? Oder wartet der die kompletten 3 Minuten, dann wird berechnet und dann kommen Daten raus? Aber in welchem Timing? Genau so, wie das DCF Signal? Oder jagt der die decodierten Daten einfach in gewissen Abständen raus?
Abdul K. wrote: >> - Den Kontroller beim Entschlüsseln mit grenzwertiger Stromversorgung >> ärgern bis er Fehler macht und dadurch evtl. etwas über den Schlüssel >> verrät. > > Man kann das versuchen, ist aber mittlerweile bei den Chipherstellern > usus, das zu verhindern. Ob der PIC das macht weiß ich nicht. Na man könnte die Betriebsspannung zu passender Zeit kurz (im us-Bereich) einbrechen lassen, so schnell, daß es der Brown-Out-Detektor nicht mitbekommt. Ich glaube nicht, daß PICs speziell für Kryptografie designt wurden und dementsprechend gegen solche Angriffe immun sind, im Gegensatz zu Smartcards (die wurden früher mal mit ähnlichen Techniken geknackt). Jürgen
Sicherlich sind PICs nicht direkt für Kryptoanwendungen gedacht. Was aber nun, wenn irgendwo eine Anleitung publik wird, in der genau beschrieben wird wie man einen PIC knackt? Wie sieht dann das Quartal für Microchip aus? Das werden sie vermeiden wollen!! Gruß - Abdul
Der Pic benötigt pro Instruction 4 Taktcykeln, anhand des Stromverbrauchs, mit einem schnellen Oszi gemessen lässt sich fetsstellen welche Befehle er gerade abarbeitet. Jeder Befehl hat eine charakteristische Stromfunktion.... Deshalb ist der PIC auch nicht für Sicherheitsanwendungen einsetzbar. Wer Lust hat kann ja mal messen, sofern der Typ bekannt ist ließe sich mit etwas Geschick die laufende Software analysieren....
Mit 4MHz getaktet macht das 1.000.000 Befehle pro Sekunde! Da kommt bestimmt eine Menge Daten zusammen!
Der Algo wird so einfach sein das es durch die 3sek. Wartezeit unmoeglich wird den in endlich langer Zeit durch Inp/Oup zu knacken oder es ist ein Designfehler und es werden alle "3??" Nachrichten gebraucht. Sollte man mal abtesten. Auf alle Fälle wird versucht durch wustes Bitgewackel den gemeinen Datenlogger vom knacken abzuhalten..... ;-)
Die Wartezeit ist nur ca. 250 us und das auch nur einmal alle drei Minuten. Waeren also "nur noch" 250.000 Befehle.
Ich denke mal, dass es ja sowieso eher interessant ist, zu sehen, welche Art von Befehlen ausgeführt wird, da wir im Moment ja noch nicht wisse, welche Art von Algorithmus es überhaupt ist. MfG Andreas
Hat eigentlich schon jemand herausgefunden, zu welcher Zeit welche Zone übertragen wird? Denn zum Beispiel der Zeitbereich "22:00 - 03:59 Aktueller / kommender Tag (TODAY im Display)" Verfügt über genau 120 * 3 minuten Da es aber nur 60 Zonen gibt, bleibt genau die Hälfte übrig. Oder wird alles doppelt übertragen?
Nicht doppelt. Aber zu jedem Tag gehoeren zwei Pakete. Eins fuer den Tag und eins fuer die Nacht. Die Infos zur Wetterlage sind bei beiden gleich, allerdings werden z.b. im Nacht-Paket Winddaten uebertragen und im Tagespaket an gleicher stelle Infos zu schwerem Wetter.
Ah stimmt ja, das habe ich übersehen. Weißt du zufälligerweise auch, wie das dann gemacht wird? Zone 0 Tag Zone 0 Nacht Zona 1 Tag Zone 1 NAcht..... oder Zone 0 Tag Zone 1 Tag ... Zone 0 NAcht Zone 1 NAcht Unbd wie sieht es mit dem Day 3 aus? der kann für jede Zone nur ien Packet übertragen. mfg Sevi
Es ist so wie deine zweite Aufzaehlung. Also erst Tag fuer alle Zonen, dann Nacht. Das ist wohl einfacher fuer die Wetterstation weil sie dann nur alle 3 Stunden ein Paket auswerten muss. (bzw. fuer Zonen >59 alle 1,5h) Am Tag 4 fehlt einfach das Nachtpaket. Meine Station zeigt da allerdings auch eine Nachttemperatur an. Wie sie darauf kommt weiss ich aber nicht. Evtl. errechnet sie einen Erwartungswert aus den Nachttemperaturen der anderen drei Tage.
Hallo, habe seit 3 Tagen einen DCF77-Empfänger, will einen ATMEGA8 dafür programmieren und bin heute hier hereingestrauchelt. Zum Bit 1 und 8, die im 1 von 3 Blöcken immer 0 sind: das sind die Alarmbits des Katastrophensignals, die aus Kompatibilitätgründen 0 bleiben müssen. Daraus ergibt sich ein Nutzsignal von 12 + 2x14 = 40 bits, nicht wahr ? Gibt es eigentlich bereits nwnder, die ihren controlller mit einem offiziellen Decoder aufgemotzt haben ? Also z.B. DCF77->Decoder->AVR->PC, um im Pc die kompletten Wetterdaten zu haben ? Gruss, Michael
...würde mich auch interessieren. Speziell ob ein Chip aus einer "einfachen" Uhr, d.h. ohne Anzeige der erweiterten Werte diese dann auch richtig dekodiert!?
Moin @Michael: Wo hast du die Info für das Katastrophenalarmsignal her? MfG Andreas Lang
@Andreas Lang: Quellen: http://www.nafuo.din.de/sixcms_upload/media/2609/Vortrag%20INS%20Bevoelkerungswarnung%20Hannovermesse%202008.pdf und http://de.wikipedia.org/wiki/DCF77#Bit-Struktur_DCF77-Alarmsignal_des_Feldversuches
Hier ein Beitrag in der "elektronik industrie" zu dem Thema: http://imperia.mi-verlag.de/imperia/md/content/ai/ae/fachartikel/ei/2008/09/ei08_09_064.pdf
Wenn ich nichts übersehen habe, geht die Patentschrift leider mit keiner Silbe auf das Verschlüsselungsverfahren ein, hilft also beim Kernproblem dieses Threads nicht wirklich weiter. Die einzig nützliche Information scheint mir zu sein, daß in den Wettertelegrammen immer zuerst 22 Nutzdatenbits und dann 20 Prüfbits übertragen werden und nicht wie bei der Uhrzeit Nutz- und Paritätsbits im Wechsel. Allerdings ist nicht gesagt, daß das Ganze am Ende auch wirklich exakt so implementiert wurde wie im Patent beschrieben.
Hallo zusammen, habe den Thread mal durchgelesen. Die Dechiffrierung scheint (noch) nicht (öffentlich) möglich zu sein. Der Ansatz von Dexter schein mir am vielversprechensten zu sein. Um die Bits der Wetterdatenbits varieren zu können müßte aber die Paritätsprüfung der Wetterdaten bekannt sein. Denn der Chip dekodiert die Wetterdaten anscheinend nur bei gültiger Parität. -Hat hierzu schon jemand einen funktionierenden Ansatz? -Sind noch Leute aktiv die das entsprechende Equipment und eine funktionierende Wetterstation haben? Mein Interesse an dem Thema ist natürlich rein akademischer Natur. Habe seit heute einen Attiny2313 der mir die einzelnen Bits ausgibt. (Scheint auch gut zu funktionieren)
Hallo, Ich habe aufgrund der empfangsschwierigkeiten einen neue Spannungsversorgung an den empfänger angeschlossen, so wie es scheint wird scheint es nun mit dem empfang besser zu sein. Die ganzen anderen Log-Dateien habe ich verschoben, wer sie haben möchte, soll sich melden: http://www.thomy-pc.de/?site=kontakt Die neuen Logdateien sind dann hier: http://www.thomy-pc.de/serverstatus/dcflogs.php Übrigens, die Fehler die dort reinkommen sind zu 99,999% Fehlimpulse oder fehlende Impulse. Bitfehler sind äußerst selten. gruß thomy_pc
Hallo zusammen, hab den Thread interessiert verfolgt und mir bei ELV eine DV323 besorgen lassen. (Bilder folgen). Sind 2 bare Dies (vergossen) drin, ein 16 pol. (programmier ?)-Stecker etc. Es ist ebenfalls eine alternative 8-polige Bestückung für den (Decoder ?)-Chip vorgesehen (Vcc auf 8, GND auf 5 - also eher kein PIC). Für mich klingen die beiden folgenden Ansätze sehr vielversprechend: 1) Test der Fehlertolleranz und der Fehlerkorrektur 2) generelle Angriffe durch frei formulierte Dateneingaben Weiteres in Kürze. Gruß, Walter.
Mal rein zu Übersicht: Sind die übertragenen Wetterdaten die gleichen wie bei Kachelmannwetter? Dann lohnt der ganze Aufwand eh nicht. Nach meiner Beobachtung sind deren Wettervorhersagen meistens ziemlich daneben. Ein Blick an den Himmel mit Prüfung der Windgeschwindigkeit ist genauso aussagekräftig. Ich wohne praktisch direkt neben einer seiner Wetterstationen und vergleiche deren Online-Wetterprognose mit dem, was dann hier ankommt. Oftmals schwanken die Vorhersagen innerhalb Stunden drastisch! Ziemlich unrealistisch. - Abdul
Hi Abdul, aus meiner Sicht: ...und wenn sie in dem Signal die mittlere Mondfeuchte übertragen würden... - es ist verschlüsselt - es ist verboten es zu öffnen - es ist nicht trivial genug Gründe mein Hirn anzustrengen, ich finde es ein cooles Projekt, auch wenn (oder gerade weil) nichts materielles dabei rumkommt ;-) BTW: mit der Qualität dieser Vorhersagen hab ich ähnlich schlechte Erfarungen gemacht. Gruß, Walter.
Momentan glaube ich nicht, daß es jemand knacken und auch publizieren wird. Lasse mich aber gerne vom Gegenteil überzeugen. Das Interesse hat offensichtlich sehr nachgelassen. Ob es rechtlich ein Problem ist, weiß ich nicht. Meinst du? Ich wollte nur die Leute vorwarnen, die die Daten dann irgendwie für sich nutzen wollten. Z.B. für die eigene Haussteuerung. Eine Verwendung für eigene Projekte zu verschlüsseln, könnte ich mir schon vorstellen! Das akademische Interesse darf also bestehen bleiben. Grüße - Abdul
Zur Fehlerkorrektur: Nach etwas Google Recherche bin ich auf den Hamming (7,4) code gestoßen. Dieser erlaubt in jedem 7 Bit Wort einen Fehler. Rechnerisch würde das heißen 6 Worte zu je 4 Bit davon gehen 2 Bit weg da diese für die PTB verwendet werden d.h. es werden 22 WetterBits übertragen die natürlich noch verschlüßelt sind. Problem die Hamming Matrix ist wählbar. Um die verschlüßelten Wetterbits zu erhalten müßte man erst die Hamming Matrix herausfinden. ALs ersten Vorschlag würde ich Vorschlagen dass die erste Spalte der Hamming Matrix (1 0 0 0) ist was gleichbedeutend mit dem ersten Datenbit ist. Dadurch ließe sich steuern dass das erste Zeichen des Hammingwortes gleich null ist wenn das erste Zeichen des Datenwortes auch 0 ist. (wichtig für PTB Bits). Dagegen spricht: Prinzipiell sind max 6 Bitfehler korrigierbar anscheinend wird aber nur einer korrigiert. (siehe DEXTER) Quelle zu Beispielimplementation Hamming Code: http://michael.dipperstein.com/hamming/index.html Was halten die Experten davon?
Hallo, auch ich habe mich vor einiger Zeit an diesem Wettercode versucht. Hatte eine Wetterstation gekauft und die Kommunikation abgezapft und am PC mitgeloggt und analysiert. Es sind einige Stunden da reingeflossen und rausgekommen ist letztendlich nichts. Ich habs dann nachher aufgegeben aus folgenen Gruenden: -Man bekommt (genauere) Wetterdaten einfacher von irgendwelchen Webseiten. Einen Parser dafuer zu schreiben ist weit einfacher als die Verschluesselung zu knacken. -Die Zukunft dieser Art der Wetteruebertragung ist ungewiss. Die Vertraege laufen afaik noch bis 2012, was dann passiert weiss keiner. Dann waere also die ganze Muehe nur fuer ~4 Jahre. Ich weiss, es geht nicht nur darum die Wetterdaten zu bekommen, sondern auch darum den Ehrgeiz zu befriedigen und ich will auch niemanden hier entmutigen. Aber denkt einfach mal drueber nach. Gruss
>Einen Parser dafuer zu schreiben ist weit einfacher als die >Verschluesselung zu knacken. Schon. Nur habe ich einen Heizungsregler, der auch die Beladung des Pufferspeichers steuert, in dem ist 'ne DCF77-Uhr integriert (Eigenbau). Da ich den Puffer nicht gerne belade, obwohl zwei Stunden später die Sonne 'rauskommt, wären die Informationen über das Wetter am kommenden Tag schon hilfreich, und das ganz ohne Hardwareänderung.
@ Thilo M. Genau dieser Gedanke verfolgt mich schon seit ewigkeiten... Gruß, Tubie
Thilo M. wrote: >>Einen Parser dafuer zu schreiben ist weit einfacher als die >>Verschluesselung zu knacken. > > Schon. > Nur habe ich einen Heizungsregler, der auch die Beladung des > Pufferspeichers steuert, in dem ist 'ne DCF77-Uhr integriert (Eigenbau). > Da ich den Puffer nicht gerne belade, obwohl zwei Stunden später die > Sonne 'rauskommt, wären die Informationen über das Wetter am kommenden > Tag schon hilfreich, und das ganz ohne Hardwareänderung. Wäre es dan nicht besser das Modul ggf über nen RFM12 oder so mit "externen" Daten zu versorgen? Oder man kauft sich halt ne Uhr wo der Chip schon drin ist und nuzt das ganze ganz legal...
Hallo, Mich würd das ganze schon interessieren, denn mit dem Programm mit dem ich die Daten logge, welches ich mit einem weiterem Empfänger an meinem Stand-PC nutze, würde ich die Daten gerne dekodieren sodass ich persönlich da wetterdaten anzeigen lassen kann, leider habe ich nicht die mittel (und auch kein Geld, da Schüler) diese daten zu loggen wenn ich solch eine wetterstation hätte, die erfahrung solche daten zu entschlüsseln, oder zumindest einen Ansatz zu finden. Nunja, ansonsten ich hab für euch Logdateien bereitgestellt (der link is in meinem Letzen Posting.. gruß thomy_pc
Hallo zusammen, bei Aldi(Süd) gibts ab nächster Woche ein Funkwetterstation mit Wettervorhersage durch Symbole. http://www.aldi-sued.de/de/html/offers/2867_8765.htm Kann jemand von euch abschätzen ob hierzu die DCF77 Wetterdaten genutzt werden oder lediglich die Temperaturen / Tendenzen. Grüße
Da ist ziemlich sicher kein Meteotime-Dekoder drin. Weder der Preis noch die Beschreibung sehen danach aus.
Da steht ja auch schon das der Sensor 100m Reichweite hat. Wenns per DCF77 gehen wuerde braeuchte man ja keinen Aussensensor. Ich gehe also auch davon aus dass es nicht per DCF77 geht. Der Preis ist allerdings nicht so unglaublich guenstig fuer ne Wetterstation die ueber DCF77 geht. Bei ebay gehen die fuer ~25 EUR weg.
gast wrote: > Da steht ja auch schon das der Sensor 100m Reichweite hat. Wenns per > DCF77 gehen wuerde braeuchte man ja keinen Aussensensor. Wenn es nur um die Vorhersage ginge hättest Du recht, aber wie willst Du ohne Außensensor die aktuelle Außentemperatur und -Luftfeuchtigkeit an Deinem Standort angezeigt bekommen? Übrigens haben alle Meteotime-Stationen, die ich bei ELV auf die Schnelle durchgeschaut habe, auch einen Außensensor.
die Funkwetterstation bei Aldi mit Wettervorhersage durch Symbole, wird warscheinlich nur ueber die Tendenz des Luftdruckes eine Prognose des Wetters angeben. Frank
Hallo Zusammen. ich hab meine Station jetzt mal aufgemacht, ein bisschen mitgeloggt. Schließlich habe ich das "Decoder-IC" von Uhren-IC getrennt und ein meinen eigenen Controller angeschlossen. Wie im Beitrag vom 09.09.2007 18:31 von "noch einer" erwähnt: Ich kann nur alle 45 Sekunden ein Cipher-Telegramm schicken und bekomme darauf ein Klartext Telegramm zurück. Die Taktzeiten habe ich allerdings auf 200us (je high und low) drücken können. Das Senden des Cipher dauert jetzt 36ms, das Empfangen des Plain 10ms, die Pause dazwischen unverändert ca. 270 ms. Mit der "hohen" Geschwindigkeit kommt es aber immer wieder zu Hängern (Crypt-IC antwortet nicht). Schicke ich das Telegramm früher, bekomme ich immer (unabhängig vom Telegramm): 100000000000000000000100 Auch wenn ich im Cipher irgendein Bit (bis auf das erste) ändere, bekomme immer die obige Antwort. Das erste Bit kann ich aber (zumindest von 0 auf 1) ändern, das Ergebnis bleibt das gleiche. Es scheint also eine gewisse Plausibilität in den Cipher-Daten vorhanden zu sein - der Decoder kann somit offensichtlich erkennen, ob das Telegramm gültig ist. Die Uhrzeit ist damit wohl auch fest verbunden (ein ändern der Uhrzeit mit gleichen Cipher-Daten brachte ebenfalls das obige Telegram). Soweit meine ersten Tests. Gruß, Walter. PS: meine Station (DV323 von Elektor hat auch nen Funk-Außensensor)
Nachtrag: hatte nen Fehler in der SW. Kann die Bitzeiten (senden und empfangen) ohne Probleme auf 48 us drücken. Senden dauert somit 8.6 ms, Empfang entsprechend. Die Pause natürlich unverändert. Walter.
>Auch wenn ich im Cipher irgendein Bit (bis auf das erste) ändere, >bekomme immer die obige Antwort. Eine schlichte Checksumme dürfte die wahrscheinliche Ursache dafür sein.
Versuch mal, den Chip zu resetten in dem Du kurz die Versorgungsspannung unterbrichst. Evtl. reicht nur ein kurzer Impuls um einen evtl. vorhandenen Brown-Out-Detector zu triggern. Dann könnte man viel schneller Cipher-Telegramme senden.
Hallo, kann mir eine die genaue Bezeichnung für die MEBUS Wetterstation (oder eine andere Wetterstation, bei der der Decoder Chip "ablötbar -> SMD oder DIL, aber nicht vergossener "bare die" ist) nennen. Am Besten eine Station mit einem erkennbaren Decoder Chip (PIC,AVR...). Evtl. lässt sich das Problem (zwar nicht so elegant aber effektiv) von dieser Seite angehen. Zum Code selber: Für mich sieht es jetzt so aus, als wenn die 20 Bit im Cipher sich aus Checksumme [über Daten (erste 22 bit) und Zeit (letze 40 Bit) (wie auch immer)] und Fehlerkorrekturcode [über die Daten (wieder erste 22 bit)] zusammensetzen. Bei meinen Tests konnte ich zwar keine fehler-korregierenden Eigenschaften feststellen, werde das aber nochmal überprüfen. Weiter oben (Dexter vom 25.08.2007 13:37) war die Rede davon, dass zumindest ein Bit kippen kann (nicht in den Zeit Daten). Ändert man aber die Zeit-Daten kommt "immer" ein Fehler (daher die Annahme, dass die Checksumme über alles geht die Fehlerkorrektur nur über die Nutzdaten). Zur Wartezeit: wenn es gut gemacht ist, ist die Wartezeit (ca.45 Sekunden) VOR dem decodieren eingefügt worden, ein Reset würde also nichts bringen. Werde das asap überprüfen. Gruß, Walter.
Grundsätzlich ist nur gesichert, was man auch überprüft hat. Fehler werden überall gemacht, also muss man überprüfen ob man über ein Power-Down den Chip resetten kann. Aber anyway: Ich habe den Thread erst kürzlich gefunden und nur quergelesen; habe keine Lust mir Hardware zu besorgen; habe aber Interesse am dekodieren. Um es nochmals klarzustellen: Du hast ein Setup, bei dem Du die verschlüsselten Daten, die in den Chip reingehen, und die entschlüsselten Daten, dir aus dem Chip rauskommen, mitgeschnitten werden kann? Werden da minütlich irgendwelche Daten entschlüsselt? Wenn ja, könntest Du hier mal ein Tages-Log der Bits reinhängen? Hast Du schon systematisch Tests gemacht, wie z.B. verschiedene Anzahl von Bits kippen/setzen/löschen? Was ist mit vertauschten Bitpositionen? Hast Du schon Datenbits verschiedenere Datensätze gemischt etc.?
Hallo, @unbekannter: - Logs wurden schon einige eingestellt, bitte s.dort - ich habe einen Decoderchip (aus einer Wetterstation) DV323 von Elektor, bare die vergossen, somit keine Bezeichnnug verfügbar). Alternative Bestückung vorgesehen: SOP8: 1= data out 8=Vcc 2= data in 7= Reset (?) 3= clk out 6= n.c. 4= clk in 5=GND Ich kann Telegramme senden und die Antwort des Decoders empfangen. 45 Sekunden Zwangspause scheint auch nach dem Reset zu kommen. Ablauf etwa wie folgt: - Start MCU (nach Power on oder Reset) - inits -- LOOP start - delay 45 sek. - get telegram cipher - decode - send telegram plain -- LOOP end ich habe nochmal einen Test gemacht: in einem geloggten Telegram habe ich jedes Bit der Reihe nach invertiert und es an den DCIC geschickt. Positive antworten habe ich nur nach Änderung von Bit 0 und 7 bekommen. Ich folgere daraus, dass mein DCIC KEINE Fehlerkorrektur sonder nur eine Fehlererkennung macht, anders als bei den Messungen von Dexter der je ein Bit kippen konnte. Das legt den Verdacht nahe, dass sowohl Fehlererkennung als auch Fehlerkorrektur in den Daten enthalten ist aber nicht von jedem DCIC genutzt wird. In meinem Fall habe ich also nur die Möglichkeit einer Known-Plain-Text Attake, nicht aber einer Choosen-Plain-Text Attake (auch wenn hier Plain und Cipher vertauscht sind). Ich denke der nächste Schritt wäre herauszufinden wo in den Daten Fehlerkorrektur- und Fehlererkennungs-Informationen enthalten sind. Auch wenn in der Patentschrift steht, das die ersten 22 Bit Nutzdaten und die folgenden 20 Bit Korrekturdaten sind sollten wir uns nicht all zu sehr darauf verlassen. Somit wäre es interessant DCICs zu finden, die Fehlerkorrektur machen. Welche Wetterstationen haben einen "auslötbaren" DCIC ? @Dexter: Welche Station hast Du verwendet (genaue Bezeichnung bitte). Gruß, Walter.
Angehängte Dateien:
-
contactless_m.jpg
200 KB
Hier noch ein Bild vom DCIC und der alternativen Bestückungsfläche. Hat jemand ne Idee, welcher Controller da passen könnte (so es sich denn um einen Standart Controller handelt. PIC und AVR passen wohl eher nicht). Gruß, Walter.
Die 45ms kommen mir als power-up timer verdammt bekannt vor, kenne sie von 2 verschiedenen Prozessortypen. Ist es möglich, eine Verbrauchmessung während des Resets sowie bei Verbrauch zu machen ? mit ozi. Weiters, ob unterschiedliche know error bit mittels differenzial-korrelazion erkannt werden kann.
Chris wrote:
> Die 45ms kommen mir als power-up timer verdammt bekannt vor,
Nur dass es hier 45s sind...
Ist es möglich, die 6 TestPunkte zu identifizieren. Komisch, daß es 6 sind, hätte gedacht, 4 würden reichen.
und weiter geht's: ich hab mal nach möglichen Kandidaten für das leere Footprint gesucht. Bei microchip, atmel, freescale, Zilog,Holtek,NXP,infineon,nec,TI und ST hab ich nix gefunden, was da passen würde... aber: bei EM Electronics (ja, hab ich auch noch nie gehört ;-) Der EM6580 z.B. würde dort so einigermassen reinpassen. Ist ein 4-Biter, super low power und rennt mit internem Oszillator (so wie ich das verstanden habe) mit bis zu 800 kHz. Gibt's als Maske und Flash. Dabei eine kleine Änderung: 1= data out 8=Vcc 2= data in 7= Vreg (mit C nach Ground) 3= clk out 6= Reset (wenn enabled) 4= clk in 5=GND Die Pins der Serial IO passen leider nicht. Kann aber auch zu Fuß gemacht werden. Im Manual hab ich nix über die Programmierung Auslesen Ausleseschutz gelesen, nur einen Verweis auf die Möglichkeit, das Dingens mit nem Elnec Programm zu bearbeiten mittels ICSP (da schau her !) Soweit der Stand und damit gleich die Frage: kennt jemand das Teil ? Wie wird's programmiert (nein, ich hab noch nicht gesucht, wollte das hier erstmal loswerden) und noch viel wichtiger (wenn auch nicht wirklich sportlich): wie kann man das Teil auslesen (auch wenn der Beschreiber das nicht will ;-) Schönen Abend, Walter.
Eine AN mit einer Programmieradapter kann man sich für ICSP von der Website downloaden.
Hi zusammen, die Belegung zum ISP hab ich gefunden, aber nix zum Protokoll. In der AN die ich gesehen habe wird beschrieben wie man mit nem Tool von Elnec programmieren kann aber keine Details. Dissassembler hätte ich schon am Start ;-) Kennt einer von Euch die Controller näher ? Haben die nen Ausseleschutz (Protectbits, Fuses etc.) Kann mir jemand die ISP-Protokollbeschreibung besorgen ? Wäre doch sehr hilfreich. Oder ne Quelle zu einem günstigen In-Circuit-Programmer (BeeProg etc. konsten doch ne ganze Menge...) Gruß, Walter.
@ Walter: Dein Ehrgeiz ist im Moment anscheinend riesengroß. Weiter so! Was allerdings zu bedenken ist: du brauchst erstmal eine Platine, auf der der entsprechende IC bestückt ist. Kann natürlich sein, dass unter dem "schwarzen Klecks" ein ebensolches versteckt ist; ich glaubs nicht; muss man aber auf jeden Fall ausprobieren. Also weiterhin viel Spaß mit der Sache! :-)
Nochmal zur Klarstellung: Hatte oben irgendwo nicht jemand den genauen PIC indentifiziert? Ist der EM zu diesem zumindest vom Pinout was Stromversorgung angeht, kompatibel? Zu Marin kann nicht nicht viel sagen, da noch nie verwendet. Es ist aber eine Firma aus dem Bereich Uhren und die Verwendung eines Chips von denen wäre hier dann naheliegend. Vielleicht gibt es mehrere Generationen, eventuell mit unterschiedlichen Controllern?? Obacht! Eventuell bringt der Chip absichtlich Müll raus, wenn er in einem zu offensichtlichen Timing angesteuert wird!
Hallo Abdul, nein, der ME ist nicht Pin-Kompatibel zum PIC. SOP8, Vcc auf Pin8 und GND auf Pin 5 - hab ich bei keinem anderen Controller gefunden. Auch der C an Pin 7 würde zum ME passen. Haber leider bisher fast nichts über ICSP des ME gefunden. Ich vermute, dass es verschiedene Varianten des DCIC gibt (warum auch immer, evtl. verschiedene Genereationen). Bei meiner Wetterstation habe ich auch keine Fehlerkorrektur feststellen können. Dass absichtlich ein "falscher" alternativer Footprint auf die Platine gesetzt wurde halte ich für unwahrscheinlich (ist aber natürlich nicht ausgeschlossen). Stromaufnahme hab ich noch nicht gemessen. Muss mal sehen, ob ich Vcc oder GND auftrennen kann. Das mit dem "offensichtlichen Timing" halt ich auch für unwahrscheinlich, da ich bekannte Muster (aus älteren Logs) decodieren kann (immer richtig). Eigene (gültige !) Eingangsmuster zu erzeugen habe ich noch nicht geschafft. Dazu ist es meiner Meinung erst einmal nötig, in den Eingangsdaten - Nutzdaten - Fehlererkennungsdaten (Error detection, ED) - Fehlerkorrekturdaten (Error Correction, EC) zu identifizieren. Es kann (anscheinend, wenn implementiert) nur 1 Bit korregiert werden. Wenn dadurch ED und EC identifiziert werden könnten wäre es auch möglich, eigene gültige Eingangsdaten zu erzeugen. Dann wären wir auch von der kryptographischen Seite wieder im Rennen. Gruß, Walter.
Wenn wirklich nur ein Bit als Fehler erkannt und korrigiert werden kann, dann wuerde als Fehlererkennung ja ein einfaches parity-bit ausreichen. Man konnte dann versuchen das parity-bit zu aendern und noch ein beliebiges weiteres. Dann sollte er den Fehler nicht mehr erkennen koennen und evtl. kommt dann wieder was richtiges raus. Problem an der Sache ist die Position herauszufinden. Wenn mans systematisch macht sollte das aber selbst manuell kein grosses Problem sein.
Gast wrote: > Wenn wirklich nur ein Bit als Fehler erkannt und korrigiert werden kann, > dann wuerde als Fehlererkennung ja ein einfaches parity-bit ausreichen. Mit einem Parity-Bit kann man einen Einzelbitfehler nur erkennen aber nicht korrigieren.
Wenn ein CRC mitgeht, dann kann man ihn auch korrigieren, dauert halt. Ich mache das mit 8bit crc, da kommt ein 7bit wert raus, hänge das Parity-bit ran, und so ist 1 bit corrigierbar, langsam aber platzsparend und effektiv.
Ich bin kein ECC-Freak, aber soweit ich weiß gibt es diverse Klassen bei den CRCs. Manche davon können auch zur Fehlerkorrektur verwendet werden, was vor allem von der Blocklänge abhängt. Man könnte sich an Henning Paul wenden. Der kennt sich damit aus und spricht deutsch. Vielleicht brauch der Chip die 45 sec. einfach zum Rumrechnen? Und er bekommt dann jede Minute ein neues Datenpaket ist dann wieder 45 sec. beschäftigt... Blieben also 15 sec. über, um die Toleranzen eines onchip RC-Oszillators abzufangen?! Würde gut passen. Diese Zeitspanne wurde dann offensichtlich gleich als "BLOCKzeit" verwendet. Was ja naheliegend ist. Das man den EM-Code einfach zu auslesen kann, würde mich wundern. Protection ist heute Standard. Gibt der Chip nach dem Einschalten von alleine irgendwas aus? Da er jederzeit synchronisieren können muß, wird er wohl nicht sonderlich auf die sequentiell richtige Datenreihenfolge am Eingang achten. Er könnte es aber! Gruß
Wenn deine Vermutung stimmt, was einleuchtend ist, dann würde ich nicht auf einen ECC tippen, sondern auf block encryption, welche mittels eines Schlüssels verschlüsselt ist, eventuell auch in recursiver function, neues Datenpaket wird mit letztem unencrypted datenpaket xor´ed oder so. Das würde eher einleuchten, und da wird es dann schwerer. Tea, Xtea, Bluefish, ... fallen mir spontan ein.
Bezieht Chris sich auf Abdul? Der Chip hat nur begrenzte Resourcen. Kann man diese Verfahren dort überhaupt unterbringen? Sein RAM ist auch sehr begrenzt. Ist die Frage, ob er überhaupt irgendwelche Daten aus dem jeweils vorherigen Datenpaket zwischenspeichern kann. Außerdem geht das nur begrenzt gut, da er jederzeit eingeschaltet werden kann und dann zeitlich irgendwo im Datenstrom aufsetzen muß! Gruß
Ja, hatte mich auf Abdul bezogen. Ja, TEA, XTEA usw werden bevorzugt eingesetzt, weil sie mit begrenzten resourcen auskommen, sei es RAM, wie Rechenzeit. Normalerweise dauert sowas ca 20-30ms bei 1Mhz taktzeit (pic), bei 32khz würde das 8 sekunden heissen. Das mit dem Datenstrom irgendwie aufsetzten, wenn es 64 stationen gibt, dann beginn mit der 1sten und warte bist die kommt, und fang dort an. Nimm eventuell die Uhrzeit als init, von der 1st station, verwirf das Ergebnis, bzw behalte es intern, und dann fangen die 64 an. Die 64 sind jetzt nur fiktiv.
Wenn es "ein wenig funktionieren soll", dann müßte er mindestens so viel zwischenspeichern können, daß er ein kaputtes Impulstelegrann für einige Zeit verkraften kann?
Die Information wird ja genügend oft gesendet, rechne mal aus, wie oft das gesendet wird.
Chris wrote: > Die Information wird ja genügend oft gesendet, rechne mal aus, wie oft > das gesendet wird. Jedes Wetter-Telegramm wird innerhalb von 24 Stunden genau einmal gesendet, oder welche Information meinst DU?
Das denke ich bezieht sich nur auf die einzelne Wetterinformation vom Flughafen, der sie alle <30min ändert. Wenn dem wirklich so wäre, dann dürfte es im 24stunden Zeitraum nur ca 500 telegramme mit Wetterinfos geben.
Habe in der Spec nachgeschaut, alle 3 Minuten wird die Wetterinfo einer Region (vorhersage + aktuell) gesendet, sprich alle 3 Minuten wird sie wiederholt.
puhh... die letzten posts glaenzen aber extrem mit falschem Halbwissen. Das muss ich mal etwas aufraeumen. 1. Es kann nicht sein das der Chip 45s rechnet. Die Station sammelt die Daten ueber drei Minuten und gibt sie dann dem Chip als seriellen Datenstrom. Dieser antwortet dann sofort (wenige ms delay). Also kaum Rechenzeit. 2. Die Wetterdaten werden pro Region genau einmal pro Tag gesendet. Das sind 7 Pakete. 3x Tag und Nacht von heute bis Uebermorgen und 1x Tag vom 4. Tag. 3. Das die Pakete mit dem Klartext vom Vorherigen verschluesselt sind kann auch nicht sein. Die Station uebergibt nicht alle drei Minuten Daten an den Chip, sondern (teilweise) nur die relevanten, also nur EIN Paket aus drei Minuten. Bevor hier Leute ernsthaft mitreden wollen, sollten sie lieber einmal die specs. lesen, ansonsten kommt hier alles durcheinander.
Hier eine Idee von mir, vielleicht ist sie nützlich: Früher, beim C64, konnte man im Lautsprecher des angeschlossenen Fernsehers 'Mithören' was der Prozessor gemacht hat. Die Schaltvorgänge der CPU haben sich ganz leise in das Audio-Teil reingekoppelt. Man konnte gut hören, ob die CPU grad eine Warteschleife durchlief oder intensiv was rechnete. Sogar ISR-Routinen konnte man raushören, da diese periodisch wiederholt wurden. Vielleicht kann man den Controller über einen Widerstand (27 Ohm oder so) betrieben und daran einen empfindlichen Verstärker hängen (oder eine Spule an den Controller halten) Wenn der Controller keine Schutzmassnahmen dagegen hat, stehen die Chancen gut, dass man raushören kann, ob der Controller während der 45 Sekunden intensiv rechnet oder nur eine Warteschleife durchläuft. Das menschliche Gehör ist hier besser geeignet als ein Oszi, mit dem man das vielleicht viualisieren könnte! Damit kann man vielleicht auf die komplexität des Verschlüsselungsalgos rückschliessen! Viel erfolg, ist sehr spannend der Thread!
Die Trick-Kiste ist geöffnet ;-)
Hallo zusammen, erstmal: schön, dass das hier wieder aufflammt. Wie Gast schon sagt: Vom "CentralChip" werden die Daten über 3 Minuten vom DCF-77 Empfänger gesammelt (3x14 = 42 Bit), noch mal 40 Bit Zeitinfo angehängt und an den DCIC weitergegeben. Dieser antwortet innerhalb von 270ms. (ich weiss, es kostet viel Zeit sich durch die obigen Beiträge zu wühlen, ist es aber echt wehrt - dann müssen wir nicht alles von neuem aufrollen - nicht böse gemeint) Ich kann bekannte Telegramme (aus vorangeganenem logging) in bliebiger Reihenfolge an den DCIC senden und bekomme immer die richtige Antwort. Somit schließe ich eine Verkettung aus. Mitschreiben der Stromwerte halte ich für eine sehr gute Idee. Werde mir das mal näher anschauen. Interessant sind sicher auch die 45 Sekunden Pause. Bin immer noch auf der Suche nach dem ICSP (auch wenn der Einwand berechtigt ist, dass das Ding bestimmt Codeprotection hat [und es ausserdem extrem unsportlich wäre ;-)]) Gruß, Walter.
Laut meinen infos hat es keine code-protection, wohl aber eine checksum. Entweder, es ist nicht möglich, den Code auszulesen, daß nur die checksum ausgerechnet wird, und ausgegeben, oder man kann ihn auslesen. Aber achtung, sollte das Epoxy ein Wafer sein, ist warscheinlich, nicht sicher, daß es keine flash, sondern eine rom version ist. Die VPP beträgt 15V, bei 3V vdd, nach dem proggen, kann die checksum nachträglich ausgelesen werden, waveformen der pins sind in den an´s, die icsp-befehle leider nicht.
Hallo zusammen, schön zu sehen dass wieder Leben in den Thread kommt. Die letzten Posts lassen allerdings die Unkenntniss der bereits weiter oben im Thread diskutierten Tatsachen erkennen. Deshalb nochmal zusammengefasst: - 60 Regionen mit 4 Tagesprognose - 30 Regionen mit 2 Tagesprognose Jede Prognose benötigt 42/40 Bit aus dem DCF77 Signal d.h alle 3min kommt eine Prognose. Was bedeueted das die jede Prognose nur einmal gesendet wird. Die Sendezeiten der jeweiigen Regionen sind festgelegt und stehen weiter oben im Thread. Zur Entschlüßelung werden 3*14 Bit Wetterdaten und die Zeit/Datum Daten des zuletzt gesendeten Wetterdatenblocks an den DCIC gesendet (Dexter / Walter Freywald 4.11.08) Der DCIC gibt dann den Entschlüßelten Datenstrom mit 24Bit aus von denen 2 Bit anscheinend Statusinfo (Fehlererkennung/Fehlerkorrektur) zum entschlüßelten Datenstrom sind. Ich hatte weiter oben mal die Vermutung geäußert dass es sich um einen Hamming(7,4) Code handeln könnte. Statistische Untersuchungen haben gezeigt dass die Daten in unterschiedlichen Zusammensetzungen sehr gleichmäßig verteilt sind. Deshab sind die untersuchten Zusammensetzungen meiner Ansicht kein Hamming Code. Grüße
Leider ist die Übersichtlichkeit des Threads komplett hinüber. Vielleicht findet sich jemand und macht für jeden neu überarbeiteten Punkt ein paar Sätze auf einer extra HTML-Seite? <Nein, ich habe dafür keine Zeit> Dann multiplizieren wir mal die 800kHz (??) mit 270ms und bekommen die mögliche maximale Prozessorbefehlszahl, die er überhaupt abarbeiten kann. Müßte noch jemand klären, wieviele Zyklen der Chip pro Befehl im Durchschnitt brauch. Damit hätten wir ein Maß für die mögliche Komplezität der Verschlüsselung. Abzüglich der Zeit aus dem Hörtest :-) Gruß
es gibt doch bereits ne seite im wiki darueber. die koennte mal jemand erweitern.
Angehängte Dateien:
-
DSCN8553.JPG
880 KB
Ich habe das Modell "METEOTRONIC START" Wetter Info Center von www.TFA-dostmann.de günstig auf ebay bekommen. Im Anhang ein Bild vom Decoder IC; weitere Datailfotos mache ich gerne.
Hei, habe begonnen den Thread mal mehr durchzulesen. Bin darauf gestoßen, daß es eine Uhr mit PIC 12F509 gibt. Da holt man die FW einfach raus, ist die beschaffbar ?
Wieviele verschiedene Decoder IC modelle sind denn eigentlich nun bekannt? Ist das auf dem bild oben nicht vielleicht auch ein PIC ? Die Aufschrift sagt: HKW 581 7252G7 wenn ich das richtig lese.
Es könnte ein Pic sein, muß es aber nicht. Ev. könnte ich den Pic auslesen, sollte der beschaffbar sein.
Der HKW581 soll ein spezieller Dechiffrierchip sein. Kein PIC, kein AVR. http://imperia.mi-verlag.de/imperia/md/content/ai/ae/fachartikel/ei/2008/09/ei08_09_064.pdf
Hi Chris, hab ne Zeit lang mit den PICs (12er und 16er) gearbeitet. Die haben Codeprotection. Wenn's da nen Weg aussen rum gibt, würde mich (sehr) interessieren (da kenne ich die ICSP commands ;-) Mit dem PIC: War so weit ich das verstanden habe ne Mebus Station (09.09.2007 von "noch einer"), damals bei Real. Habs aber selber nie gesehen, nur im Thread gelesen. Der Chip von Thorsten Fnord könnte (unter anderem) auch nen PIC sein (auch wenn er anders bedruckt ist). (Pin 1 Vcc, Pin 8 GND). Ließe sich auch über ICSP identifizieren. SOP8 Gehäuse würde sich auch gut zur Stromanalyse eignen. @Thorsten: danke für die Info. Kannst Du nen paar Messungen machen (Vcc, GND, Takt und Daten Signale) ? Gruß, Walter.
Pic becommt man über microchipdirect auch mit ander Bezeichnung gelasert. Auch ich würde ein Pic vermuten, abgesehen von VPP, würde eine Pin-Messung mit 5V, bei 3V VCC z.B. nicht den reset-pin von einem i/o pin unterscheidbar machen ? oder besser ohne vcc, und an vcc messen ? Mittels Power-Glitch 50mV oder 10V für die alten typen, lassen das copy-protection verschwinden, ohne das Flash zu löschen. Ich vermute mal stark, daß die Daten in Form von http://de.wikipedia.org/wiki/DCF77#Bit-Struktur_DCF77-Alarmsignal_des_Feldversuches sind, sowie eine xor/scrambling mit dem Zeitsignal besitzen.
Hab leider kein Oszi hier, aber Vcc und Gnd werde ich finden, .... Morgen ; ) In die anderen Beinchen kann ich höchstens mal reinhören, und euch das Geräusch,falls hörbar, beschreiben : )
Hier der Link zum Wiki, falls (sich) jemand die Mühe/Ordnung machen möchte: http://www.mikrocontroller.net/articles/DCF77_Wetterinformationen
@Chris, (ein bisschen OT): kannst Du mir noch paar Infos oder Links zum PIC und Glitching geben. Hast Du da Erfahrung ? Vpp, hab ich auch drüber nachgedacht: Ich kenne bei diversen Controllern sogenannte parasitäre Dioden, die Überspannung an den meisten Pins gegen Vcc (und Unterspannungen gegen GND) ableiten. Diese Dioden vertragen Ströme so um die 500 uA (ganz grob). Der Pin für VPP (so es ihn den gibt) dürfte die Diode ja nicht haben... Z.B. Über 10kOhm Widerstand an den zu testenden Pin gehen und Spannung langsam über Vcc heben. Kommt man über 6V (bei angenommeren Vcc=5V), so scheint keine Diode vorhanden zu sein. Oder auch Verhalten bei MCU mit bekanntem VPP-Eingang vergleichen. Bitaufbau: guter Hinweis. Danke. Bit 0 und 7 (in der Beschreibung 1 und 8) würden passen (werden anscheinend ignoriert - hat der Test gezeigt.) Werde mal ein paar Tests mit den Parity Bits machen. Gruß, Walter.
Vpp, würde nicht über 5V gehen, 3V vcc sowie 5V testspannung, damit kann nichts passieren. Bei 2V VCC könnte bei 5.5V der pic schon in den icsp modus gehen, aber 5.5V ist bei neueren technologien schon zuviel. Power-Glitsching, geht problemlos, gleich nach dem ICSP-command erase-all ein glitch von von 0.7-2ms (bei den meisten) geben, und das Löschen des Flashes wird übersprungen. Da sieht man, wie wichtig Abblockkondensatoren sind.
OT: http://www.cl.cam.ac.uk/~sps32/mcu_lock.html Die genaue Technik für Pic war mal in einem PDF desselbigen Authors. Habe es selbst auch ausprobiert, es funktioniert problemlos. Der Witz ist, daß sie ein Problem hatten, mit 10V, dann einen Spannungsdektor deswegen extra eingebaut haben, in den A versionen, und dann klappt es mit 50mV. Trotzdem sind die Pic´s billig und ich setzt sie immer noch ein, kann aber schon mal vorkommen, daß ich den VPP Pin durchbrennen lasse, wenn ich einen Prototypen zu einem neueren Kunden rausgebe, sowie Bootloader mit Verschlüsselung.
Angehängte Dateien:
-
Decoder.JPG
840 KB
Das ist es, was mein Multimeter sagte : ) Die beiden Pins mit den Roten Bezeichner sind halt mit den Polen der 3X1,5v batterien verbunden, bei den anderen hab ich nur gegen GND gemessen auf welchem Potential sie stationär liegen...
Das würde den Verdacht bekräftigen, daß es sich um ein Pic handeln könnte.
Würde folgendes vorschlagen, IC auslöten, auf protoboard mit condensator sowie ICSP eines pic´s. dann bitpattern testen. Gleichzeitig kann man auch die Strohmaufname, sowie diese beim Einschalten testen, und mit einem Pic vergleichen. Sollte die stimmen, kann man mit sehr hoher Warscheinlichkeit einen Pic vermuten und einen Programmieradapter anlegen. Was kostet die Uhr ?
Ich hab mir etwas zeit mit der Anschaffung gelassen, und gewartet, bis eine günstig war. Soweit ich mich entsinne habe ich mit Versandt knapp 28€ bezahlt, das ist jetzt ca. ein halbes Jahr her....
Solltest du einen pic programmierer haben, wäre folgendes von interesse: VCC 2V (restliche uhr ausgeschaltet) und VPP über 47k Wiederstand an 5.5V, denn VCC+3.5V müßten schon den PIC in den Programmiermodus setzen. Eventuell auch 5.6V oder 1.9V VCC, wenn der PIC dann läuft. Auch wenn es kein PIC ist, schadet es dem IC nicht, zumindest >99%. wenn kein 47k, einfach größer gleich 10k, aber unter 50k. Wichtig, VPP muß vor VCC anliegen.
Kann die 28€ Uhr auf Bolzano / Bozen eingestellt werden ? Wenn ja, wie heisst die ? und wo hast du sie gekauft ?
Bitte erst lesen, steht fast alles oben! Aber zur frage: Zumindest in der Anleitung steht Bolzano / Bozen mit dem Regionscode 27 verzeichnet. Gekauft auf ebay. Modell "METEOTRONIC START" Wetter Info Center von www.TFA-dostmann.de Ich hab leider keinen PIC-programmer und hier auch zzt. nur eingeschränkte Möglichkeiten.
Guten Abend: @Chris: danke für die Infos. Das hört sich sehr vielversprechend an (gute Idee auch mit dem Durchbrennen ;-) Endlich mal was konkretes in der Richtung. Werde es mal ausprobieren. Was ist der Hintergrund zu Bozen ? @Thorsten: Danke für die Messungen. Hab mir auch die oben genannte Wetterstation besorgt. Wenn Sie da ist werde ich das Teil gleich mal auf PIC untersuchen. Gruß, Walter.
Hallo,
ich hab ein paar Messungen mit der "Meteotronic Start" gemacht
(s.Anhang, Logicanalyser und Oszi)
Hauptunterschied zur DV323 von Elektor:
Die Clockimpulse sind sehr kurz (s.a.Ahnhang)
Die Abgebildeten Daten sind aus dem Selbstest ("SET" Taste beim Einlegen
der letzen Batterie halten, dann mit "SNOOZE" Taste Tests
durchschalten).
Soweit ich das gesehen habe ist das Gehäuse für nen PIC zu klein
(scheint nen 0.5 Pin Pitch zu sein).
Werde das mit der Vpp dennoch ausprobieren.
Generell zum Ablauf der Daten Ein- und Ausgabe:
Wetterstation TFA (Meteotronic Start)
8 PIN DCIC SOP (stimmt mit der Beschreibung von "noch einer" vom
09.09.2007 überein, ebenso die Beschreibung der Alternativbestückung.
BTW: bei der Meteotronic ist keine Alternativbestückung vorgesehen,
lediglich ein EEProm könnte bestückt werden - Bilder folgen)
Pin1 Vcc Pin8 GND
Pin2 Data in Pin7 Clock in
Pin3 Clock out Pin6 Data out
Pin4 Vcc Pin5
Ablauf:
input: Data in -> 1,2us -> CLK in(H) -> 26,4us -> CLK out(H) -> 5,8us
-> CLK in(L) -> 3,2us -> CLK out(L)
DCIC "denkt nach" für ca.250ms, dann geht CLK out(H)
output: CLK in(H) -> 4,0us -> CLK out(L) -> 9,4us -> CLK in(L) -> 11.6us
-> Data out(H) -> 3,0us -> CLK out (H)
Soweit meine Erkenntnisse hierzu.
Werde den Chip vom "Master" trennen und ein paar "rein-raus"-Spiele
machen und versuchen mir mal die Stromaufnahme anzusehen.
Gruß,
Walter.
Hallo Leute, ich habe mir mal die statistische Verteilung der '1' und '0' Bits bezogen auf die jeweilige Bitposition innerhalb des 42-bittigen Wetterdatenblocks angesehen und bin bei der Auswertung eines Logs über einen kompletten Tag zu folgendem Ergebnis gekommen: Wahrscheinlichkeit für eine '1' an den Bit-Positionen des verschlüsselten Wetterdatenblocks : Bitposition Block1 Block2 Block3 Bit Pos 01: 0.00 0.50 0.50 Bit Pos 02: 0.54 0.51 0.50 Bit Pos 03: 0.44 0.51 0.50 Bit Pos 04: 0.55 0.49 0.50 Bit Pos 05: 0.40 0.50 0.50 Bit Pos 06: 0.52 0.50 0.50 Bit Pos 07: 0.54 0.51 0.50 Bit Pos 08: 0.00 0.51 0.51 Bit Pos 09: 0.46 0.50 0.50 Bit Pos 10: 0.43 0.51 0.50 Bit Pos 11: 0.46 0.50 0.50 Bit Pos 12: 0.44 0.50 0.50 Bit Pos 13: 0.51 0.50 0.49 Bit Pos 14: 0.61 0.50 0.50 Meine Schlüsse hieraus: Da im Block 2+3 annähernd alle Bits mit der gleichen Wahrscheinlichkeit '0' als auch '1' sind, vermute ich, dass sich an diesen Stellen die verschlüsselten Wetterdaten (22 Wetterbits + 6 Füllbits) befinden. Durch die Verschlüsselungsmethode wird die Häufigkeit des Auftretens einer '1' genauso groß wie für eine '0'. An der Position 1+8 des 1.ten Blockes steht immer eine '0' => Alarm-Bit, wie bereits weiter oben im Thread erwähnt. Die restlichen 12 Bits des 1.ten Blockes tendieren in ihrer Häufigkeit je nach Bitposition eher zu einer '0' bzw '1'. Deshalb vermute ich, dass es sich bei diesen Bits im 1.ten Datenblock um eine Checksumme, Fehlerkorrekturbits oder ähnliches handelt. Gruß uzi
Angehängte Dateien:
-
verlauf.png
7,2 KB
Wieviele Wetterdaten hast du in diese Berechnungen einbezogen? Ich hatte das mal mit 120 Wetterbloecken (mit je 42 Bits) gemacht und habe keine so schoene Verteilung bekommen (siehe Bild im Anhang).
Da der Chip sowohl Clock (müßte nicht unbedingt so sein) als auch enschlüsselte Daten (logisch) mit einem nachmeßbaren Timing rausschiebt, kann man daraus die wahrscheinlichsten Clock-Frequenzen des Chips leicht bestimmen. Offenbar werden wohl diverse Chip-Generationen verbaut. Die Pinbelegung ist ja selbst für die Versorgungsanschlüsse unterschiedlich. Interessant wäre es auch noch mit einem Spektrumanalysator oder Amateurfunkempfänger an der Versorgung des Chips nach auffälligen Frequenzen zu suchen. Dafür würde ein einfacher Ferritübertrager in Reihe zum VCC-Pin als Auskopplung reichen. Dann wäre noch die Sache mit der minimal möglichen Versorgungsspannung und für die Charaktierisierung des internen Oszillators eine Temperaturmeßkurve genau obiger Frequenzen. Gruß
Hallo 'Gast' für meine Berechnung der Wahrscheinlichkeit einer '1' bzw '0' für die entsprechende Bitposition habe ich die Logs von 11 Tagen also ca. 5200 Datensätze zu je 42 Wetterdatenbits ausgewertet. Gruß uzi
Hi Leute, Ich werde mir demnächst auch eine Uhr zulegen, Mein ehm. Ausbilder hat viel mit Pic-Controllern zu tun, Der ist auch noch Ausbilder, daher kann es etwas dauern bis der mal einen Wunsch erfüllt, Gibt es eine Uhr wo mit Sicherheit ein Pic drin ist? Ich habe irgendwo mal gelesen, das Pics nicht besonders sicher sind, was den Programmcode-Inhalt angeht, das man die Code-Protection umgehen kann, jedoch finde ich dies nicht mehr wieder.... mich-selbst-ohrfeig Ansonsten kann ich euch bisher nur Log-Dateien Bereitstellen: http://www.tt-soft.org/dcflogs/ Als Download: http://www.tt-soft.org/dcflogs/index.php?dlfile=allzipped Nunja, bis dahin euch erstmal viel erfolg, ich werde hier täglich reinschauen... gruß thomy_pc
Hallo Leute, um bei der Sache hier ewas weiter zu kommen, halte ich die folgenden Dinge für hilfreich: 1. Wo befinden sich in den 42Bit (bzw 40 Bit + 2 Alarmbit) der verschlüsselten Wetterdaten die eigentlichen Nutzdaten und wo die Prüfbits für die Fehlerkorrektur ? Hierzu habe ich ja bereits vor einiger Zeit meine Untersuchungsergebnisse bekannt gegeben. Gibt es hierzu vielleicht noch andere Meinungen / Widersprüche / Bestätigungen ??? 2. Thomas (Thommy_PC) hat ja auf seinem Server bereits einige Logfiles mit den über DCF übertragenen Daten bereitgestellt. => Ist jemand in der Lage diese Logfiles zum Dechiffrier-IC zu senden und die dazu passenden dekodierten Wetterdaten mitzuloggen? Je mehr komplette Datensätze bestehend aus den verschlüsselten Wetterdaten + dazugehörige Datum/Zeitinformationen + dekodierten Wetterdaten vorhanden sind, umso besser. Hierraus könnte dann ggf. eine "Known Plaintext" Attacke durchgeführt werden, um der Verschlüsselung bzw. dem Prüfbit-Mechanismus auf die Spur zu kommen. 3. Kennt sich hier einer etwas besser mit Kryptographie bzw. Kodierungstheorie aus ? Was haltet ihr davon ? Gruß uzi
Der schnellste Kryptographische Ansatz waere eine differential power analysis. Man braucht dazu einen 12bit ADC.
uzi wrote: > 3. Kennt sich hier einer etwas besser mit Kryptographie bzw. > Kodierungstheorie aus ? Waren beide gerade vor kurzem meine Diplomprüfungsthemen... und daher sage ich dir: Wenn die nicht richtig gepfuscht haben: No way. Trozdem wären mehrere Klar/Chiffretextpaare interessanter als irgendwelche häufigkeitsanalysen oder rohe "logs". Besonders interessant wäre natürlich Datensätze in denen eine Information (oder alle) gleich sind, dann sieht man gleich ob gleiches zu gleichem Verschlüsselt wird. Vieleicht funktioniert auch sowas wie der Bleichenbacker Angriif (one Million questions attac) der Decoder scheint ja mit etwas definiertem zu antworten wenn was "falsch" läuft.
Wie gesagt, erster Ansatz, "differential power analysis". Sollte da nicht ordnungsgemaess programmiert worden sein, so kann man damit den Crypto in die Knie zwingen.
chris wrote: > Wie gesagt, erster Ansatz, "differential power analysis". > Sollte da nicht ordnungsgemaess programmiert worden sein, so kann man > damit den Crypto in die Knie zwingen. Na dann sag doch mal was die guten Leute machen sollen, vieleicht probierts einer aus ;)
>Waren beide gerade vor kurzem meine Diplomprüfungsthemen... und daher >sage ich dir: Wenn die nicht richtig gepfuscht haben: No way. Naja das sehe ich anders. Wir wissen das es ein wahrscheinlich 8 Bit Rechner ist und damit unterliegt das System einer definierbaren Leistunggrenze die weit, sehr weit unterhalb der Rechenpower liegt die ein Hobbyangreifer zur Verfügung stehen wird. Desweiteren können wir mit großer Wahrscheinlichkeit davon ausgehen das die Anzahl der möglichen Schlüssel stark begrenzt ist, und es kein Verfahren gibt diese Schlüssel dynamisch zu ändern. >Trozdem wären mehrere Klar/Chiffretextpaare interessanter als irgendwelche >häufigkeitsanalysen oder rohe "logs". Das denke ich auch. Je mehr desto besser und wichtig ist dabei die Korektheit dieser Daten. Da also Plaintext/Ciphertext bekannt sind, da wir eine solche CPU mit eigenen Daten füttern können, kommen viel mehr und viel einfachere Verfahren des Angriffes in betracht. Known Plaintext/Ciphertext Attacks, choosen Ciphertext Attacks, differientielle Analyse usw. Eine "differential power analysis" denke ich sollte sich bei einem System wie dieses am einfachsten abwehren lassen, solange der Entwickler das auch berücksichtigt hat. Wenn ich die Informationen in diesem Thread richtig interpretiere dann muß man an den Cryptoprozessor den Timestamp und den Ciphertext senden. Als erstes würde ich also verifizieren wollen ob dieser Timestamp mit dem Ciphertext korreliert. So könnte man feststellen ob der Timestamp für die Schlüsselerzeugung mit benutzt wird. Wenn ich ein solches System entwickeln sollte, mit den gegebenen Rahmenbedingungen, dann würde der eigentliche Cipher von geringer Komplexität sein. Dafür dann aber eine komplexere Schlüsselerzeugung bestehend aus dem Timestamp der umgerechnet ein Index in eine im FLASH gespeicherte Schlüsseldatenbank dient. Mit zb. 8Kb als Schlüsseldatenbank, quasi OTPs, dürfte man schon eine enorme Varianz erzielen. Gruß Hagen
12 Bit ADC, man misst die Spannung/Strohmaufnahme des uC. Dazu reduziert man auch die Entstoerkondensatoren, sowie fuerht ein Wiederstand dazwischen ein. Nun fuetter man den uC mit source-dateien, und loggt es mit. Dann fuettert man ihn mit modifizierten source-dateien, auch geloggt. Sieht man unterschiede, so kann man z.B. evaluieren, welche bits zusammengehoeren, wie der Algorithmus ist usw. z.B. kann man so problemlos passwoerter herausbekommen. Ein Beispiel von korrekt und inkorrekter Programmierung. char *password="test"; for(i=0;*pw;i++) if (pw[i]!=password[i]) return 0; ... richtig char r; for(r=i=0;*pw;i++) if (pw[i]==password[i]) r++; if (r!=strlen(password)) r=0; if (!r) fake(); else doit(); return r; Das ist nur ein einfaches Beispiel, wenn bits zusammengeklaubt werden usw, ist das noch viel kritischer, wie z.B. bei crypto-keys.
Man muß bedenken es wird ein Pic mit 1k oder 0.5k Speicher eingesetzt. 200 gehen mit dem Interfacing drauf, also bleiben ca 300 Instruktionen uebrig, inkl jeglicher Tabelle.
Dein Beispiel zeigt aber auch das der Entwickler mit sehr einfachen Regeln diesen Angriff austricksen kann. Für mich ist das eher ein Raten und Expermientieren statt Nachdenken und analysieren. Als erstes wie gesagt korrekte Ciphertext/Plaintext/Timestamp Paare sammeln und diese mit anderem Timestamp nochmals austesten. Der Prozessor anwortet dann ja ob er korrekt entschlüsseln konnte. Ein ansich sehr einfacher Test der schonmal eine wichtige Frage über das System beantwortet. Gruß Hagen
>Man muß bedenken es wird ein Pic mit 1k oder 0.5k Speicher eingesetzt.
Woher hast du diese Information ?
Weiter oben im Thread, pic12f509 , pic12f508 (von anderen quelle).
Hallo, ------- @uzi (Gast), Mein nickname ist thomy_pc und nich thommy_pc (reagier ich gaanz empfindlich drauf ;)) ------- Wie ich hier so mitbekomme wird hier kaum noch Forschub betrieben, es werden nur Ideen verbreitet, gut, kann ich fast verstehen das ihr arbeiten geht und darum abends keine Lust mehr habt, aber am wochenende hat man doch ein wenig mehr zeit... hätte ich die erfahrung und möglichkeiten würde ichs zumindest mal machen 2-3 Wochenenden zu opfern... So, Nochmal zu den strom und spannung messen, wie genau funktioniert das: >Dazu reduziert man auch die Entstoerkondensatoren, sowie fuerht ein >Wiederstand dazwischen ein. gut, man kann die spannung messen, welche über den widerstand abfällt, aber was genau kann man mit dem signal anfangen? PS: Ich habe Elektroniker für geräte und systeme gelernt und kann mit Fachbegriffen etwas anfangen... gruß thomy_pc
Prozessoren haben meist während jedem Befehl eine andere Stromaufnahme. Das kann man Auswerten.
Hallo, @Thomy-PC: Stromanalyse hab ich mit dem (vermutlichen) PIC schon gemacht (Bilder stelle ich rein, sobald ich mein Kabel gefunden habe ;-)) Vorgehen war ganz einfach: Blockkondensator raus, 1kOhm (ja, ist sehr groß, Controller arbeitet aber trotzdem) in Reihe mit Vcc, dann mit dem Oszi am Vcc-Pin des Controllers gemessen. Bekommen einen Spannunghub von knapp einem Volt. In das Gezitter kann man einen 4 MHz Takt des Controller interpretieren... Denke mal, am Wochenende mehr dazu. @Hagen Re: die Idee mit dem ausgewechselten Timestamp ist ansich gut nur hat sich bei den Tests gezeigt, dass ich bis auf Bit0 und 7 (Alarmbits ?) nichts ändern kann (aus den gesammten 82 Eingangsbits). Somit momentan noch Fehlanzeige :-( Es wurde weiter oben von einer Chipvariante berichtet, die ein gekipptes Bit korregieren konnte. Kennt jemand so eine Wetterstation ? Ich sehe das auch so, dass zuerst die Positionen der Korrektur- und Fehlererkennungsbits identifiziert werden müssen, dann der Fehler- und Korrekturmechanismus. Danach sind wir in der Lage, nicht nur Known- sonder auch Choosen Plaintext Atacken zu fahren. 2. Ansatz immer noch die unsportliche Variante: Chip aufmachen und reingucken. Die Sache mit dem PIC klang sehr vielversprechend. Schönen Abend, Walter. PS: ich mir beim Durchmessen noch aufgefallen: Bit 7 wird ca. 30% schneller Verarbeitet (verworfen ?) als die anderen Bit (die alle sehr gleichmäßig abgearbeitet werden). Bit 0 dauert am Längsten (Aufwachphase ?). Weitere Bilder am Wochenende.
Strohm/Spannungsmessungen. Generell wird 12bit gebraucht, ev mit 1kohm wiederstand geht auch weniger. Es wird der Unterschied von guten und falschen Mustern ausgewertet. So bekommt man z.B. mit, welche bits wohin gehören (scrambling), bevor crc drankommt, sowie bekommt man eine Idee, wie kompliziert der Crypto-code ist und auch, ob eventuell verschiedene Bits abgearbeitet werden. Z.B. muesste es problemlos feststellbar sein, ob 4 bytes gleichzeitig mit demselben Alghorithmus (normaler blockcifer) abgearbeitet wird, oder vielleicht was einfaches, einfach nur xor mit ein paar lookups.
Walter Freywald wrote: > Danach sind wir in der Lage, nicht nur Known- sonder auch Choosen > Plaintext Atacken zu fahren. Das ist dann aber eine choosen ciphertext Attake ;) Für choosen plaintext brauchst du das Teil was dir eine Wetterinformation verschlüsselt in einen chiffretext...
Mal ein ganz einfacher vielleicht auch aussichtloser Ansatz ... Der Dekoder IC ist ein PIC12F509, wieso laden wir uns die firmware nicht einfach herunter?
ich kenn mich mit pics kein stück aus .... aber ich denke "Programmable Code Protection" wird dies verhindern
Gibt es eigentlich auch Log mit Vorher -> Nachher oder gibts nur die Rohdaten vonner Antenne?
abo Sehr interessante Details bei euch, vor allem die "Methoden" finde ich sher spannend...wer hat sich das bloss alles ausgedacht! Klaus.
Die Firma, die das Produkt auf den Mark gebracht hat, hat vermutlich diesen Thread angeschoben (der Threadstarter hat nur einen Beitrag geschrieben), um zu sehen wie sicher das Design ist. Die Firma kann ganz beruhigt sein, in den Händen dieses Forums ist das Geheimnis gut geschützt.
Siggi wrote: > Die Firma kann ganz beruhigt sein, in den Händen dieses Forums ist das > Geheimnis gut geschützt. Die wollen nur das wir mehr von ihren Uhren kaufen X-)
Bislang habe ich die Teile erfolgreich boykottiert. Wenn ich wissen will wie das Wetter wird, gucke ich aus dem Fenster.
Siggi wrote: > Die Firma, die das Produkt auf den Mark gebracht hat, hat vermutlich > diesen Thread angeschoben (der Threadstarter hat nur einen Beitrag > geschrieben), um zu sehen wie sicher das Design ist. Sehr unwahrscheinlich. Wenn es nicht zwei mit dem gleichen Namen gibt, hat er aber noch als Gast einige weitere Beiträge geschrieben. http://www.google.de/search?hl=en&q=+site:www.mikrocontroller.net+Tobias+Schilgen Da die Menge an Daten doch sehr begrenzt sind, müsste dies dann nicht auch für die Schlüssellänge gelten? Ein Schlüssel der länger ist als der zu verschlüsselnde Text macht doch wenig sinn oder?
Der Schlüssel könnte auch ein Array sein die in irgeneiner Weise indiziert wird:
1 | schlüssel = keys[(Tag + Stunde + Monat)] |
Wären dann halt max 70 Schlüssel, wenn du den Schlüssel für einen Tag brichst hast du am Nächsten Tag wieder Müll.
genau diese Vorgehensweise wäre auch meine Vermutung. Man benötigt keine aufwendige Schlüsselableitung, zb. die secure Hash Funktionen können auf 8'bittern schon einiges an Rechenzeit kosten. Davon abgesehen hätten sie den theoretischen Nachteil das wenn sie einemal gebrochen wurden man zu jedem beliebigem Index den Schlüssel ausrechnen könnte. Benutzt man dagegen ein Array[] mit guten Zufallszahlen und indiziert in irgendeiner Form über den TimeStamp, tja dann heist es wirklich alle Schlüssebits knacken durch probieren. Gruß Hagen
Hallo, wenn jeder befehl eine andere stromaufnahme hat, könnte man daraus dann nciht die befehlsfolge welche abarbeitet wird komplett rekonstruieren, wenn man weiß, welcher Befehl wie viel Strom schluckt? Ist sicherlich ein mords aufwand... gruß thomy_pc
Hmm, wenn es wirklich "nur" 14 bits wären, könnte man das sogar tun, würde dann wohl rund 12 Tage dauern. MfG Andreas
>wenn jeder befehl eine andere stromaufnahme hat, könnte man daraus dann >nciht die befehlsfolge welche abarbeitet wird komplett rekonstruieren, >wenn man weiß, welcher Befehl wie viel Strom schluckt? Hmm - was machst Du, wenn 2 oder mehr Befehle dieselbe Stromaufnahme zur Folge haben?
Nabend zusammen, Bilder hab ich zwar noch keine (kommen noch) aber: Ich hab mal nen PIC Programmer hingehängt, 12F509 eingestellt und gelesen. Und siehe da, es kam was raus, was wohl auch zu dem Teil passt. Ein weiterer deutlicher Hinweis darauf, dass es sich bei diesem Chip (aus der "Meteotronic Start" um einen PIC12F509 handelt. Bei aktivem Code protect (hier natürlich der Fall ;-) sind trotzdem die 1. 40 Worte sichtbar. Was da drinsteht sieht für mich auf den ersten Blick aus wie eine Zufallszahlengeneratorinitialiserung (perverses Wort). Bei genauerem Hinsehen denke ich, dass es doch eher ein Fake ist um solche "Schlauköpfe" wie uns sinnlos zu beschäftigen. Besonders zu denken geben mir die XOR-Vernküpfungen nach der Schleife. Da wird zwar das Bank-Select Bit von FSR immer ein und ausgeschaltet. Das hat aber für den direkten RAM-Zugriff eine Bedeutung. Also werden meiner Meinung nach einfach die Bytes 12,13,14,15...(vermutlich weiter) gelöscht. Oder hab den Baustein falsch identifiziert und es befinden sich andere Register hier... Die Fuse-Bits klingen auch plausibel: Watchdog on (hab ich nicht getestet) MCLR on (hab ich getestet -> geht) Codeprotect on (ich sag jetzt mal nix) OscInt (was anderes bleibt ja nicht ;-) Soweit dazu. Interessant wäre jetzt z.B. mal zu sehen, ob man nach einem Reset die 4 Schleifendurchläufe den Stromaufzeichnungen zuordnen kann. Mann, Mann, Mann, und bis hierher haben wir 2 Jahre gebraucht. Wenn wir so weitermachen schaffen wir das nicht bis 2010 ;-) Gruß, Walter.
Ups, sorry, da ist mir ein Fehler unterlaufen: FSR bit 5 kontrolliert auch den direkten Speicherzugriff. Die Daten werden also nicht (zwangsläufig) gelöscht sondern der Code kann wirklich Teil einer größeren Schleife zur Initialisierung des ... ich schreib's jetzt nicht nochmal...sein. Also nicht zwangsläufig ein Fake ! Gruß, Walter.
ne kleine Idee zur Ideensammlung: Von den Fuse-Bits hab ich nicht so den Peil - aber löschen lässt es sich anscheinend nicht so direkt. Kann man denn eine neue Firmware einspielen? Wenn man später mal den Decoder-IC mal "nicht mehr sooo dirngend" braucht, vielleicht könnte man ja auch ein Proggi schreiben was uns die Daten aus dem EEPROM preisgibt, sodass wir anhand derer evtl die vermutete Decoder-Tabelle finden? Zum vermuteten Zufallsgenerator: Ich gebe eine Kombi X rein und bekomme eine Kombi Y raus. Kombi X wieder rein, Kombi Y wieder als Ausgabe. Ist ja alles statisch - wozu benötige ich dann einen Zufallsgenerator? cu, olly...
Was mich wundert ist der Xor mit dem Ram in bank1. Entweder ist das eine alte Kopie derselben Strings, oder es gibt wirklich eine S-Box, oder eventuell mit alten Daten von vorherigen decodierrunden (anderen Inputdaten), würde ich ev. machen. Sollte ich eine möglichkeit finden, den chip zu patchen, würdest du das machen ?
Gibts eigentlich ne plausible Erklaerung dafuer das nur die ersten 40 Woerter ausgelesen werden koennen? Das klingt fuer mich irgendwie sehr merkwuerdig, habe allerdings mit PICs nix zu tun.
Kannst du bitte ein 16F509 Sample von Microchip organisieren, sofern erhältlich, eventuell auch 2.
Das ist normal bei den 12er cores, das wird für Konfigurationsdaten genutzt, anstatt eines nicht vorhanden EEproms. z.B. sensordaten eingelesen / gemessen und dann alten Konfiguration in ein NOP unwandeln, und neuen Wert einprogrammieren.
Ist das nicht illegal? Was würde passieren, wenn einer wirklick die Kodierung hackt?
ATxmega wrote: > Ist das nicht illegal? Was würde passieren, wenn einer wirklick die > Kodierung hackt? Benutzen oder Verkaufen ist sicher illegal, Hacken ohne Veröffentlichung meines Wissens nicht.
Ich sag mal so: Die Kodierung benutzt eine Pearson-Hashfunktion...
Ich weiß, man kann damit vermutlich ganz schnell den Chip unbrauchbar machen, wenn es keinen Weg zurück mehr gibt. Aber reichen beim PIC nicht 40 Worte um eine kleine 'Ich lese alles aus und sende es an die serielle' Routine zu schreiben?. Die allermeisten Hacks passieren doch genau so, dass man irgendwo Code einschleust und mal ein RAM/ROM-Dump macht. Ist ja nur eine Idee. Würde den Decoder auch nur dann schießen, wenn man hinterher die 40 Bytes nicht wieder zurück schreiben könnte. Gruß, Ulrich
Kann man denn überhaupt diese 40Bytes gezielt löschen? Üblicherweise lässt sich Flash nämlich nur komplett oder Seitenweise löschen.
Benedikt K. wrote: > Kann man denn überhaupt diese 40Bytes gezielt löschen? Üblicherweise > lässt sich Flash nämlich nur komplett oder Seitenweise löschen. Ein Vorredner meinte doch, dass das für Konfigurationsdaten genutzt werden könnte. Das macht nur Sinn, wenn man diesen bereich auch gezielt löschen kann. Andererseits macht ein Ausleseschutz aber nur dann Sinn, wenn er den Zugriff vom Konfig-FLASH auf den Programm-FLASH verhindert und nur den umgekehrten Zugriff zuläst. Aber wer weiß...
ich weiss grad nicht wie ein Zufallsgenerator auszusehen hat, aber ist es vielleicht die lange Schleife am Anfang (~30 Sekunden), nach der man erst Zeichen sendne kann? die Idee mit dem 40-Byte-Proggi gefällt mir... genial einfach! cu, olly...
abo
Gast wrote:
> Ich sag mal so: Die Kodierung benutzt eine Pearson-Hashfunktion...
Woher weißt du das?
rossi75 wrote:
> die Idee mit dem 40-Byte-Proggi gefällt mir... genial einfach!
Das erscheint mir wirklich zu einfach. Wenn man das ersetzten könnte um
den Code auszulesen, könnte der Hersteller auf Condeprotect ja auch
gleich ganz verzichten.
da gibt es sichelrich einen Haken, und zwar, das sich das flash nur komplett oder seitenweise löschen lässt wie Benedikt K. (benedikt) erwähnte, wodurch einem das auch nciht weiter bringt, denn dann is das proggi ja futsch... Aber bestätigt isses ja noch nicht... gruß thomy_pc
Sorry für weiteren Post, Ich habe soeben das Datenblatt des Pic12F509 gewälzt und festgestellt, das es die Register welche für den Flash-Zugriff benötigt nivvh enzhält (EEADR, EEADRH und EEDATA) EEADR stehen für die unteren 8 Bit und EEADRH für die oberen 5 Bit. EEDATA enthält dann dementsprechend die daten, aber da der 12F509 solche register scheinbar nicht besitzt wird dies sicherlich ein ding der Unmöglichkeit... Zumindest werden diese Register in keinen Datenblatt erwähnt. gruß thomy_pc Und noch eon schönes Wochenende
Der 509 hat kein EEprom. Anstatt eines EEprom, können die 40 byte Flash auch nach der code-protection umprogrammiert werden.
Das hieße, es lässt sich zwar ein Programm einschleusen, aber es kann nicht das restliche Programm auslesen werden, sondern nur den RAM? Wenn es gelinge dies nach jedem Befehl zu tun, könnte man die Operationen doch auch teilweise nachvollziehen. Dürfte aber schwer werden.
Genau, das Ram ausgeben würde gehen, dazu braucht es jedoch einen externen uC, damit das Ding weiterhin funktioniert. Was ev. auch gehen würde, ware den code um 8x zu beschleunigen.
Noch als Zusatz. Entweder die Entwickler haben das mit den 40bytes übersehen, hatten keinen Speicherplatz, daß sie gezwungen waren, es so zu tun, oder das ist nur ein Fake. Daß es ein Fake ist, bezweifle ich, da der Code handgeschrieben sowie Speicherplatzoptimiert ist. Mich verblüfft es eigentlich, daß die Entwickler sich so in die Karten schauen lassen. Ich an ihrer Stelle hätte z.B. den Interfacecode in diesen Bereich gestellt, sowie andere kleinigkeiten, welche A nicht wichtig bez. Cryptografie sind, B sowieso ersichtlich sind, wie z.B. serielle code-ein und Ausgabe, C den Code dazu getimed, sowie ev den Ram zuvor gesäubert, daß RAM-auslesen nichts bringt.
Ich konnte den bisherigen Antworten nicht genau entnehmen, ob es nun möglich ist, die ersten 40Bytes durch eigenen Code zu ersetzen oder nicht. Falls ja, dann macht es für mich durchaus sinn, hier wichtigen Code hinzusetzen: Sobald man diesen durch eigenen Code ersetzt, funktioniert die Software nicht mehr. Man müsste innerhalb dieser 40 Takte Befehle einbauen die sowohl den RAM Inhalt auslesen, als auch das selbe machen wie der ursprüngliche Code. Da der Watchdogtimer an ist, muss das ganze vermutlich auch noch in der gleichen Zeit passieren als beim Orginalcode. Wenn dagegen die IO Routinen an dieser stelle stehen würden, dann wäre es viel zu einfach diese so anzupassen, dass irgendwelche anderen RAM Inhalte ausgegeben werden.
>Ich konnte den bisherigen Antworten nicht genau entnehmen, ob es nun >möglich ist, die ersten 40Bytes durch eigenen Code zu ersetzen oder >nicht. Es ist möglich, 1er bits durch 0er bits zu ersetzten. Sprich Code Patchen, oder Konfigurationsdaten ersetzen oder einfügen, sollte der Code das vorsehen. Ein NOP hat opcode 0, deswegen kann ein wert durch ein Nop ersetzt werden, und ein Wert dahinter reingeschrieben werden. Z.B. ist es so möglich, Sensoren nachzuconfigurieren, Code auf verschieden Subsysteme anzupassen usw, ohne ein EEprom zu nehmen. Diese uC kosten ca 30-50 Cent schon in wenigen Stückzahlen. >Falls ja, dann macht es für mich durchaus sinn, hier wichtigen Code >hinzusetzen: Falsch. Z.B. gibt der Code aufschluß auf die Zyklen sowie art der Verschlüsselung. Wenn nun z.B. gewisse bits gepatcht werden, und man vergleicht die Resultate, bekommt man unweigerlich dei Verschlüsselung/Schlüssel raus. es sind nicht 40 Befehle, sondern 65 Befehle. >Da der Watchdogtimer an ist, muss das ganze >vermutlich auch noch in der gleichen Zeit passieren als beim >Orginalcode. WDT hat zimlich hohe tolleranzen,insgesamt eine Varianz von 27ms. Zudem kann man den WDT problemlos abstellen. >Wenn dagegen die IO Routinen an dieser stelle stehen würden, dann wäre >es viel zu einfach diese so anzupassen, dass irgendwelche anderen RAM >Inhalte ausgegeben werden. Einfach Werte einlesen, verarbeiten, restliches RAM rücksetzen, Werte ausgeben. Ist nicht Sicherheitskritisch. Code-Teile des Algorithmus inkl Zyklen ist sehr kritisch, da es den Alg verrät, bez auch Angreifbar macht.
Hallo, erstmal vielen Dank für die vielen Ideen ! - Samples zum PIC gibts z.B. bei Conrad (Wald- und Wiesen Controller) - Direktes Auslesen des Flash ins (meines Wissens -> Harvard Architektur, Tabellen werden über RETLW realisiert) nicht möglich (Wenn es aber gelänge, die ersten 40 Worte seperat zu löschen und wieder zu beschreiben, dann könnte man mach solchen Tabellen suchen...) Die Idee von Chris, den WDT abzuschalten hat mich auf eine andere Idee gebracht: Oszillator auf LP umschalten. Dann kann das Ding von aussen getaktet werden. Scheint ne statische Architektur zu sein (DC-4MHz). So kann man wirklich im "Einzelschritt" durch das Programm steppen (zumendest, bis die Ports initialisiert werden und kommuniziert werden soll) und die Stromaufnahme in den einzelnen Steps besser messen (der Chip ist dann zum decodieren allerdings unbrauchbar). Sicher auch ein interessanter Ansatz, die anfänglich Initialisierung dahingehend zu manipulieren, dass die Entschlüsselung vereinfacht wird und leichter auf den Schlüssel / den Mechanismus geschlossen werden kann. An vorderster Stelle steht für mich aber immer noch der 50mV Glitch beim Bulk Erase.Hat da jemand Erfahrung ? Chris, Du hattest da mal was erwähnt. Ich hab das Dokument auch gefunden. Früher waren es 10V, bei der A-Version anscheinend die 50 mV. Heisst jetzt 50 mV, dass die Vcc UM 50mV oder AUF 50mV abgesenkt wird ? Zum Ausblick: ich hab echt darüber nachgedacht, was passiert, wenn es jemand wirklich schaffen sollte, das Ding zumindest auszulesen (komplett): Ist dann hier alles vorbei ? (Abgesehen davon sollte der Algorithmus dann hier vielleicht so dargestellt werden, dass das System nicht ohne weiteres nachgebaut werden kann (z.B. ohne Schlüssel). Ich persönlich will keinem Schaden und das Geschäft vermiesen !) Ich denke nein, denn dann geht es erst wirklich los, den dann bekannten Algorithmus auf Schwachstellen zu untersuchen :-) Es ist also, wie auch immer es weiter geht, kein Ende in Sicht ;-) Voller Glitch voraus ! Gruß, Walter.
Mit dem Glitch, zuerst an Pic testen. Bringe bitte in Erfahrung, welcher typ das ist, soweit möglich. Es gibt meines Wissens 5 Revisionen des Chips, nicht A sowie 4 verschiedene A versionen, A0-A3. Bevor du das mit dem Glitch testen solltest, würde ich auch im Angesicht der versch. Versionen einen Patch austesten. Weiters wäre vorher zu ergründen, ob ev nicht doch eine recursive Verschlüsselung verwendet wird. Das sollte auf alle Fälle zuvor ausgetestet werden.
Warscheinlich ist es möglich, einen Patch zu schreiben, der einen Ram-Dump nach jedem Befehl macht. Dazu bräuchte ich die genaue GPIO-zuordnung sowie deren Funktion und ev. Mitschnitte wenn möglich. Frage: Soll ich diesen Weg weiter Verfolgen, nur SW support, habe keine HW.
>Frage: >Soll ich diesen Weg weiter Verfolgen, nur SW support, habe keine HW. Auf jeden Fall! Jeder kompetente Kommentar und das Fachwissen im Hintergrund sind hilfreich! Vielen Dank für deine Unterstützung!
Ja, das war ein Chip, der nur einmal programmiert werden kann. Da er jedoch immer noch rasend Absatz findet, speziell der 12c505, hat microchip ihn in neuerer Technologie neu aufgelegt, und daraus ist die F(lash) variante gekommen, der dann auch noch zu allem Überfluß das Debug-Silicon verpasst wurde sowie andere Kleinigkeiten. Also das Config-Word hat noch andere Einstellungsmöglichkeiten. Zurück zum DCF77, ich hätte dieses Wochenende Zeit, den Patch zu machen, unter der Woche eher nicht. Dazu müßte ich aber verlässlicherweise die Beschaltung wissen. Zum Code, das Xor an Stelle 0 ist ein Platzhalter für ein Goto/Call, das ev. zusätzliche Features bereitstellt, umschaltet, oder eventuell verschiedene Hw-interfaces, bereitstellt, oder auch z.B. den Alarmausgang oder dergleichen handeln kann, jedenfalls in die Richtung. Anders ist dieses Xor nicht zu erklären. Kann aber auch nur ein Bitset/clr sein. Risiko beim Patch: Sollte der Code getimed sein, geht der Chip nicht mehr. Getimed heißt, daß z.B. der Timer zu einem bestimmten Zeitpunkt initialisiert wird und dann zu fixen, also reproduzierbaren Zeiten dessen Wert mit dem Key oder ev. Daten gexort oder addiert wird. Wie seht ihr das ?
Da das hier sich sehr in die Länge ziehen wird, poste ich mal die Befehlsliste des pic´s. Da kann man dann sehen/nachschauen, daß man z.B. aus einem RRF sehr schön ein movf sowie ein movwf machen kann, um Ram auszugeben. Man kann lediglich 1er in 0er verwandeln, nicht umgekehrt. f=file_register, l=literal, d=direction (f=1 / W=0), b=bit, a=address xorlw 1111 llll llll andlw 1110 llll llll goto 110a aaaa aaaa call 1001 aaaa aaaa iorlw 1100 llll llll movlw 1100 llll llll retlw 1000 llll llll btfsc 0110 bbbf ffff btfss 0111 bbbf ffff incfsz 0011 11df ffff decfsz 0010 11df ffff incf 0010 10df ffff comf 0010 01df ffff movf 0010 00df ffff rlf 0011 01df ffff rrf 0011 00df ffff swapf 0011 10df ffff bcf 0010 bbbf ffff bsf 0011 bbbf ffff xorwf 0001 10df ffff addwf 0001 11df ffff andwf 0001 01df ffff iorwf 0001 00df ffff subwf 0000 10df ffff movwf 0000 001f ffff decf 0000 11df ffff clrf 0000 011f ffff clrw 0000 0100 0000 clrwdt 0000 0000 0100 sleep 0000 0000 0011 option 0000 0000 0010 tris 0000 0000 0fff nop 0000 0000 0000
Seid ihr sicher dass es sich um einen PIC12F5xx handelt und nicht um einen PIC12C...? Wenn es nämlich der C ist ist es ein nur einmal programmierbarer IC ... Wäre eigentlich sinnvoll beim Produktionseinsatz da diese One Time Programmable Controllers viel günstiger sind als die Löschbaren!
Hallo Chris, erstmal die Pinbelegung: Pin1 Vcc Pin8 GND Pin2 Data in Pin7 Clock in Pin3 Clock out Pin6 Data out Pin4 RST/Vpp Pin5 n.c. Die Sache mit dem Patch hab ich noch nicht ganz verstanden. Willst Du damit das RAM auslesen ? Bleibt der RAM-Inhalt während des Programmierens / Löschens erhalten ? Wichtige Frage: Wie kann ich den Chip-Typ ermitteln (besonders die RevNr) (möglichst, ohne ihn zu löschen) ? Wäre bereit, einen zu opfern, wenn uns das weiter bringt. Weißt Du, wie das Löschen vor sich geht ? Wie sieht das Flash aus (so es denn eines ist), wenn der Flashvorgang vorzeitig abgebrochen wird ? Werden die Zellen parallel zu "1" gesetzt ? Werden sie erst zu "0" geschrieben ? Gruß, Walter.
@Cagara Ja, den C type gibt es nähmlich nicht mehr, und hat es auch nie im 150 mil soic Gehäuse gegeben, nur im viel breiteren. Auch wenn es der C type wäre, die Sache wäre identisch, da auch dieser gepatcht würde. Partielles FW-Löschen geht halt nicht. @Walter Freywald Patch: es geht hier um den Code nach dem Reset. Wenn hier eine Routine eingeschleußt werden könnte, welche den Ram ausliest, sowie den Ram modifizieren kann, dann wären 2 Sachen möglich. 1) Die orginal Routine mittels externem uC simulieren 2) Ram ausgeben. Stell dir weiters vor, daß der externe uC die Resetleitung kontrolliert. Somit wäre es möglich, nach jedem Befehl einen Dump des Ram-Inhaltes zu bekommen, da der Ram ja bei einem Reset nicht verändert wird. Um das zu bewerkstelligen, muß warscheinlich das movlw von pos 3 durch ein NOP ersetzt werden, um so an 64 Runden zu kommen, 4 sind warscheinlich zuwenig. Das heißt auch, wenn der code getimed ist, sprich der Inhalt des Timers0 in die Codierung einfließt, die Sache nicht funktioniert. Das ist unwarscheinlich, aber möglich, zudem der Timer warscheinlich nicht genutzt wird. Das ist das Risiko. Ansonsten, wenn man den Ram-Inhalt herausbekommt, nach jedem Befehl, ist es leicht, den Code zu Knacken. Warscheinlich werden die RRF in movwf und movfw umgewandelt, um den Inhalt des Rams rauszubekommen. Wie genau das geht, muß ich mir noch überlegen, da auch die Portinitialisierung (tris) gemacht werden muß, sowie input und output der variablen, die der Code normalerweise macht, damit das Ganze trotz patch funktioniert, mittels externem uC. Revision: Date-Code und nachfragen/nachschauen. Ev Datum von Error-sheets usw lesen.
Hallo, ich noch mal, im Link unten versucht gerade jmd die Löschroutine aufzurufen, dann den Chip während des Löschens mit "Unterspannung" zu versorgen, damit das Löschen nimmer funktioniert um direkt nach dem Löschen die Spannung wieder zu normalisieren und die LOCK- oder FUSE-Bits zu verändern. Auch ein sehr interessanter Ansatz. Allerdings hab ich was von 32 kHz gelesen, was schnell zum Timen wann die Spannung wieder erhöht werden muss, oder? Beitrag "PIC code protection gesetzt! Muss man den PIC erst löschen, oder kann man direkt überschreiben?" cu, olly...
Ja, das geht, wurde früher auch gemacht, was Daniel schriebt, jedoch das sind neuauflagen. Mehr als 64 bytes kann man ohne Microprobing nicht auslesen. Microchip hat einen Designfehler gemacht, demnach Microprobing problemlos geht, aber das ist ein anderes Thema. Wenn du dir das Hex ansiehst, sind da nur 0x40 words oder 64 words ausgelesen, wobei je 12bit in 16bit reingepackt wurden, weshalb das dann auch die addresse 0x80 vorkommt, danach ist Schluß, wie man auch dem Datasheet entnehmen kann, daß die restlichen Code-Words lediglich als 0x00 ausgelesen werden, wenn der Copierschutz an ist.
Ps. Daniel, deine infos sind falsch, aber im Prinzip ist es richtig, was du sagst.
@Walter Freywald wäre es möglich, den NC Pin genauer zu untersuchen. Laut Datenblatt hat er keinen pull-up, somit kann/darf er nicht NC sein. Ändert sich da was, z.B. error_correction_aktiv, wenn man den anderst beschaltet.
@Walter Freywald wäre es möglich, den NC Pin genauer zu untersuchen. Laut Datenblatt hat er keinen pull-up, somit kann/darf er nicht NC sein. Ändert sich da was, z.B. error_correction_aktiv, wenn man den anderst beschaltet. Im Prinzip braucht man sowieso einen uC, am besten einen Pic, welcher mit 16Mhz oder 20Mhz getakted wird, sowie alle Pins an den targed pic angeschlossen hat. Weiters wäre rs232 nicht schlecht, sowie wenn die pins der Uhr an denselben angeschlossen wären. Was hast du da ? Man kann auch einen AVR nehmen, nur da bin ich in ASM wegen Timinggenauen Abfragen nicht fit.
Angehängte Dateien:
-
wakeup.jpg
75 KB
Guten Abend, anbei mal ein paar Bilder. Zuerstmal: der Controller scheint in einer Art Slepp Mode zu sein und ca. alle 2 Sekunden 32us aktiv zu werden. Wenn er "aufwacht, sieht das aus wie im angehängten Bild. Das ganze geschieht ohne äußeres Zutun. Wenn ich mir aber den WDT anschaue, so ist sein Timeout mit ca.18ms angegeben, dann noch nen 1:8 Postscaler, da komme ich auf 144 ms aber sicher nicht auf 2 Sekunden - somit wohl doch kein Sleep ? Die wirklich Arbeitsphase beträgt ca. 24 us, also 24 Befehle. Sehe ich das richtig (Clock intern 4MHz, 4 Zyklen/Befehl). Gruß, Walter. PS: kann man eigentlich mehere Anhänge beifügen ?
Angehängte Dateien:
-
takt_1.jpg
74 KB
Teil2: das angehängte Bild zeigt die Stromaufnahme während des Arbeitens. Deutlich zu erkennende Zacken alle ca.250ns -> MHz. Kommentare dazu ? Gruß, Walter.
Angehängte Dateien:
-
Anschwingen.jpg
78 KB
Teil 3: hier sieht man die Stromaufnahme vor dem Senden des ersten Bits: Scheint wieder aus einer Art "Low-Power" zu kommen. Dann nach ca.27us Arbeit wird schon der erste Pin gesetzt, also wohl eher kein Reset. So wie ich das verstanden habe führt der Controller nach einem Wakeup (egal welche Quelle) einen Rest aus. Dies würde nun aber gar nicht zur ausgelesenen Software passen, da deutlich länger als 27 us gearbeitet wird bevor ein Pin gesetzt werden kann. Frage an dieser Stelle: was passiert auf dem Controller in diesen "Ruhephasen" ? Gruß, Walter.
@Chris, der n.c. ist Ausgang und scheint eine Art Busy zu sein. nach Anfrage für ca. 36 Sekunden auf High. Wenn in dieser Zeit eine weitere Anfrage geschickt wird kommt eine Fehlermeldung zurück. War aber ne gute Idee ;-) Gruß, Walter.
die 2.3 Sekunden nominelle Zeit passen zum WDT. Es ist kein 1:8 teiler, sondern ein 8bit prescaler, wobei der 3bit einfach der Index eines Multiplexers ist, welcher die verschiedenen bits des 8bit prescalers durchschalten. 111 ist als 18ms x 128 = 2.3 sek. Welche Ströhme misst du eigentlich. Sleep modus braucht nur uA, der rest mA.
wenn ich mir den Code anschaue, komme ich auf ca 245 uS auführungzeit nur in den ersten 64 Befehlen.
Ich möchte mangels PIC-Kenntnisse nochmal was zur Theorie beitragen. Vielleicht kann ich da etwas Übersicht und interessante Anhaltspunkte liefern: 1. Die Datenbits um die es hier im minütlichen DCF77 Uhrzeit-Telegramm geht, werden von einer externen Firma, nicht der PTB zur PTB angeliefert. Das klingt erstmal harmlos und uninteressant. Ich gehe darauf aber weiter unten weiter ein. 2. Die meisten hier werden wohl auch der Meinung sein, daß irgendeine uhrzeitabhängige Verschlüsselung stattfindet. Die aktuelle Uhrzeit ist sehr gut geeignet, weil sie: 2a. Immer nur einmal auftritt 2b. Sowieso übertragen wird, also keine extra Bandbreite brauch 3. Es scheint nach bisherigen Kenntnisstand wohl ein der billigsten Mikrocontroller für die Entschlüsselung verwendet zu werden. Vermutlich sind es mehrere Plattformen/Generationen von Chips evenutell unterschiedlicher Hersteller. Das läßt ein reiches Feld von Versuchen offen und das benutzte Feature-Set der beteiligten Controller kann nur die Schnittstelle derer aller Funktionalität sein! Mengt man nun obige Punkte zusammen, dann fällt mir spontan ein: Es ist für die externe Firma gar nicht sooooo einfach, die aktuelle Uhrzeit zur Verschlüsselung zu nutzen, weil: 4a. In der Uhrzeit Redundanzen vorhanden sind in Form von BCD-Kodierung, Paritätsbits (Die man nur zur Kontrolle oder Korrektur, aber nicht zur Schlüsselraumerweiterung (Kein weiterer Informationsinhalt möglich) nutzen kann), eventuell mehr. 4b. Die nächste_ Uhrzeit für das _nächste Telegramm nicht immer eindeutig a priori bestimmt werden kann. Man denke an Schaltsekunde und die Informationen in den zusätzlichen Statusbits wie "aktive Antenne, heute Alarmierungsbit für PTB-Mitarbeiter" usw. (Kenne die jetzt nicht alle auswändig). Soll sagen: Man wird nicht alle Zeitbits zur Verschlüsselung benutzen!! Ich schließe vor allem die Paritätsbits und sich nur langsam ändernde Stellen wie die Jahresdaten aus! Fragt sich, wie die externe Firma mit der PTB datentechnisch verknüpft ist. Liefert die PTB eventuell die _nächste(n)_ Uhrzeit(en) an diese Firma per Datenleitung ab?? Das wäre für uns die schlechteste Annahme, da dann die Firma praktisch alle Datenbits für den Schlüssel benutzen kann. In Anbetracht dessen, das der Mikrocontroller nicht sonderlich resourcenreich ist, würde ich daher trotzdem erstmal von einer relativ einfachen Verschlüsselung ausgehen. Die Frage wäre also: 5. Welche Bits des Uhrzeitstrings werden wirklich benutzt? 6. Wie sind diese permutiert ("verwürfelt")? Und ja, ich vermute momentan eine einfache XOR-Verknüpfung im Kern der Entschlüsselungsroutine. Mögen die Eingangsdaten zu dieser auch irgendwie 'asymmetriert' werden... z.B. durch eine einfach AND-Verknüpfung der Uhrzeitbits. Ihr könnt nun gerne meckern, wie unsäglich stümperhaft mein Gesülze ist, aber laßt es euch mal durch den Kopf gehen! Und sei es nur als Anregung. 7. Zu guter Letzt möchte ich noch darauf hinweisen, daß vermutlich schon jetzt Mitarbeiter von HKW-Elektronik bzw. der Entwickler der Software hier mitlesen und eventuell sogar unter Pseudonym Fehlinformationen einschleusen... Sonnigster Gruß - Abdul
Ps, nach dem WDT ist ein 10uS langer DTR timer aktiv. Abdul: Gut, dann gehe doch bitte mal von dem ausgelesenen Xor-generator aus, welcher einen 32bit Bereich, nähmlich die ersten 32 bits der 84 bit Daten mittels Xor verknüpft. Dies könnte 64 mal wiederholt werden, wobei dann allerdings noch Code vorhanden ist, der warscheinlich eine Addition bzw Subtraktion beinhaltet. Was natürlich auch sein könnte, als Seed könnten die 84 bit DCF Signal genutzt werden, da der Seed komischerweise 84bits ist, welcher auf 88 bits aufgeweitet wird.
Thread beobachten
Seitenaufteilung abschalten