Hallo zusammen, soeben lese ich bei www.elv.de, dass seit November 2006 über das DCF-Signal auch Wetterinformationen gesendet werden sollen (siehe dazu auch http://shop.elv.de/output/controller.aspx?cid=74&detail=10&detail2=16794&refid=). Hat jemand davon gehört und weiß mehr über das Datenformat der Wetterinformationen? Da ich einen DCF77-Empfänger auf AVR-Basis bereits realisiert habe, möchte ich diesen ggf. entsprechend erweitern. Tobias.
Ich denke das Zusatzsignal wird nicht leicht zu entschlüsseln sein... "- Empfängsgeräte mit der Meteotime Technologie können die Daten empfangen und entschlüsseln (siehe PRODUCTS)." Zu finden hier : http://www.meteotime.com/web/c1-200_c2-1185.aspx
Hört sich interessant an, was mir aber in dem Dokument von Christoph Kessler schon wieder aufstösst ist dieser Satz: [Zitat] Die übertragenen Daten können nur mit der über den Lizenzvertrag beschaffbaren Dechiffriervarianten geprüft und für die Auswertung bzw. Anzeige nutzbar gemacht werden. [/Zitat] Weiss da schon jemand genaueres ob die Daten überhaupt nicht nutzbar sind, oder nur "schwer zugänglich" sind?
Den Satz hatte ich noch gesucht, schade dann müssen wir warten, bis jemand das ganz rückwärts engineered hat... Ich habe das Dokument auch nur durch rumgooglen gefunden und weiß nichts näheres.
@Michael S. Lies das Dokument von hkw-elektronik doch mal zuende! Das steht exakt, welche Info in welchem Bit steht, welche Regionen es gibt etc. etc. Mehr braucht man meiner Meinung nach nicht. Gruss, Matti
"Die Bit-Numerierung der Wetterbits bezieht sich nicht auf die Bit-Numerierung in der Rosette des DCF-Protokolls." Die sind vermutlich irgendwie verscrambled, dazu braucht man noch einen Schlüssel
Das gilt es, herauszufinden :-), bei Gelegenheit logge ich die Bits mal und gucke nach Regelmäßigkeiten ;-) Lange bleibt das doch sowieso nicht geheim und den Schlüssel ändern können sie nicht, weil dann die auf den Markt geworfenen Geräte nicht mehr funktionieren.
> Das steht exakt, welche Info in welchem Bit steht, welche Regionen es > gibt etc. etc. Da steht nur fast alles, aber 1. laut PTB ist das Signal in den bits 1-14 Ampplitudenmoduliert und nicht wie das Zeitsignal Phasenmoduliert 2. fehlt die Information wann die Wetterdaten für eine bestimmte Region gesendet werden 3. sind die Daten chiffriert und die genannten Bitpositionen beziehen sich auf das dechiffrierte Signal eigentlich schade
Auch ELV hat da wohl "noch" nichts eigenes. Die Wetterstation welche ELV vertreibt ist ein reseller Artikel von http://www.irox.ch @Matti: Das Dokument habe ich gelesen, aber mir erschliesst sich daraus keine Möglichkeit die Daten im Datenwort zu dekodieren. Aber vielleicht hab ich noch was anderes überlesen, was du gelesen hast... @Christoph Kessler: Da sich Meteotime bei PTB anscheind eingekauft hat und da wohl was Vertraglich bis 2013 geregelt ist, wären die schön blöd das "jederman" so einfach zur Verfügung zu stellen. Aber wie schon gesagt, ich hab mich mit der Materie auch noch nicht so sehr beschäftigt... kann mich also auch Irren!
@Michael Rein von der Logik her sind die Daten nur schwer zugänglich. Da alle Empfänger auf die gleichen Daten zugreifen, kann keine richtige Verschlüsselung mit individuellen Passwörtern oder sowas verwendet werden. Das einfachste ist wohl, wenn jemand die Bits mitschreiben würde und sich dazu die dekodierten Informationen auf so einer Wetterstation anschaut. Aber das ist auf alle Fälle eine interessante Sache. Da sollte wir dran bleiben.
Kann man die Wetterstation von elv irgendwo anzapfen, um den dechiffrierten Datenstrom abzugreifen?
Und was willste damit, wenn Du die Zuordnung nicht weißt? Die Reihenfolge des dechiffrierten Stromes muß doch nicht der in der Beschreibung entsprechen. Außerdem werden die Daten wohl nicht den Custom-Chip verlassen, der in der Wetterstation sitzt, bevor sie auf die Anzeige gelangen...
Ja ich nehme auch an, da geht ein Bit in den Controller rein und eine gemultiplexter LCD-Pixelgrafik raus. Bei 14 Bit pro Minute muß der Rückwärts-Ingenieur viiiiel Geduld haben.
hmmm, da scheint sich jemand richtig gedanken über die chiffrierung gemacht zu haben. Es gibt einen "ASIC" (Ich Tipp auf uC oder PLD) von der Firma Meteo Time GmbH, ebenfalls CH, welcher den Datenstrom dekodiert! http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf Leider hab ich bei Meteo Time selbst noch nichts über den IC in Erfahrunge bringen können.
"Die Steuerung und das binäre Datenformat übernehmen Sie bitte dem Manuel des Lizenzvertrages" Muß man den Manuel zum Entnehmen öffnen? Wird man dafür in der Schweiz nicht lebenslang verknurrt ? "Lizenzstufen 1 bis 3" das auch noch?
Nun, man muß wohl einen Dekodierchip kaufen, da schiebt man die kodierten Daten rein, dann kommen da die Klardaten raus. http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf Die Datenbeschreibung in dem anderen HKW-PDF bezieht sich wohl auf das, was aus dem IC herauskommt. Aufgrund der geringen Datendichte kann die Verschlüsselung nicht sehr stark sein, wahrscheinlich gerade ausreichend, um Anbieter unlizensierter Dekoder verklagen zu können. Gruss Jadeclaw.
Du sagst es, 1-Wire ist auch simple and stupid, aber leider mit nem Patent belegt... Aber, warten wir mal ab, is ja auch noch nicht so alt die "Neuerung" auf 77,5kHz!
Es sollte doch möglich sein, solch einen IC auszuquetschen bis man die Verschlüsselung hat. Das sollte doch vollautomatisch mit nem relativ einfachen Programm gehen?! Gruß, Christian
@Schlebinski: mach ma; fg vermtl. nur bedingt legal, asserdem wenn da dementsprechende Algorythmen dahinter stecken, schiebst du vorne 100mal 001001010 rein und bekommst hinten 100mal was anderes raus! ;-)
Interessante Entwicklung. Ich dachte bisher, das die ersten 14 Bit vom Bundesamt für Zivilschutz zur Bevölkerungswarnung "gebucht" wurden oder werden sollten (s.Anhang). Aber das war dann wohl nix.
also wie ich das "verschlüsseln" würde is aber nur nene 1. gedanke ich habe einen konfigurierbaren inverter ich habe eine satz maskierungsbits mit welchen ich den inverter kofiguriere welche maskierungsbits ich verwende mahce ich von der Kalenderwoche abhängig. ergo ich greife mir 16 bit aus meinem nutzdatenstrom vernegiere das mit meinen der kalenderwoche netsprechnden maske und so musst du jede woche neu den passenden code raussuchen. bullshit für alle weil es sich momentan nicht vorhersehbar ändere mein derzeitiger speicherbedarf für die nächsten 10j 54*10*16bit~ 1kbyte wenn ich dann noch zusätzliche dinge einbastel und beim durchschieben keine beshcleunigung zulasse (es geht eben nur 1 byte pro minute) dann könnte das länger dauern da bräuchten alle die mit machen einen 2. empfänger für den aktuellen code is aber nur ne idee vom klo in ca 2 min ausgeschissen erstmal guggen interessiert wäre ich auch
sach ma balu, das mit dem "hinten rauskommen" war aber net so wörtliche gemeint...
doch die idee ist von diesem ort dort hat man die besten gedanken an manchen tagen
Hallo, ich glaube hier helfen die ganzen Vermutungen nicht weiter. Mindestens einer muß eine Empfängerschaltung aufbauen und die Daten über einen längeren Zeitraum aufzeichnen. Vieleicht bekommen wir ja ein paar Leute zusammen die das Projekt in Angriff nehmen. Wenn sich das ganze als nicht machbar herausstellt kann man immer noch aufhören. Wir haben es dann aber wenigstens probiert. Zitat: "Die Bit-Numerierung der Wetterbits bezieht sich nicht auf die Bit-Numerierung in der Rosette des DCF-Protokolls. Die sind vermutlich irgendwie verscrambled, dazu braucht man noch einen Schlüssel." Natürlich beziehen sich die Wetterbits nicht auf die Bits der Rosette, sondern aus 3 min werden jeweils 15 bit genommen und zu den Wetterbits zusammengesetzt. Warscheinlich ist hinten dran noch eine Checksumme. Ob die ganze Sache verschlüsselt ist wird man sehen wenn man den Empfänger fertig in Betrieb hat und die Wettervorhersage unsinnige Werte liefert. Also lasst uns einen Empfänger bauen und dann weiter schauen. Gruß Rene
Hallo, Zitat: "Die Genauigkeit und Stabilität der Trägerschwingung sowie die Parameter der Modulationen wurden unverändert belassen." Habe ich doch glatt übersehen, also ist kein neuer Empfänger nötig. Gruß Rene
Nein, kein neuer Empfänger! Die alten gehen vorzüglich. Ich habe gerade eine neue Funkuhr gebastelt, da kann man die Bits ´reinwabbeln sehen. Ich habe auch noch ein Reichelt-DCF-Modul liegen, das klatsch ich mal an einen Controller und hänge ein EEPROM dran und lasse es ein paar Tage daddeln. Die Daten schicke ich dann hier als TXT. Ich mache mir allerdings Gedanken über Falschbits bei Empfangsstörungen - das müssen die ja auch irgendwie kontrollierbar machen...?
@Rene: Ich stimme dir da zu, ich werde heute Abend mal ein wenig auf der 77,5Khz "reinhören" und schauen ob sich in den abgesprochenen Bit's was getan hat. The Slow hat mal zu Anfangs bemerkt: > 1. laut PTB ist das Signal in den bits 1-14 Ampplitudenmoduliert und > nicht wie das Zeitsignal Phasenmoduliert. Hab den Parsus grad auch bei ptb.de gefunden. > Die Steuereinrichtungen wurden so gestaltet, dass die Dateninhalte, > die während der Sekunden 1 bis 14 amplitudenmoduliert übertragen werden, > von dritter Seite beigestellt werden können. Wenn das so ist, bekommst du diese Information nur mit einem geeigneten Empfänger mit. Klar, wenn die restlichen Bits, die das Zeitsignal übertragen gleichgeblieben sind, ändert sich für zig tausend Uhren nichts, aber das MeteoTime Daten bekommst du nicht mit... Schauen wir mal was der Abend/Nacht bringen wird!
Hallo
Am einfachsten ist es wahrscheinlich den Dekoder Chip zu kaufen und
diesen
mit kopierten Datenströmen zu füttern. Wäre überhaupt interessant was
dieser Chip kostet, vielleicht zahlt sich das ganze reverse Engineering
gar nicht aus.
<
Ich mache mir
allerdings Gedanken über Falschbits bei Empfangsstörungen - das müssen
die ja auch irgendwie kontrollierbar machen...?
>
Ich nehme an das es eine Checksumme gibt.
LG
Michael
DCF77 ist doch immer amplitudenmoduliert. Die unterschiedich langen Impulse bestehen aus einer Amplitudenreduzierung, das ist AM. PS: passus (lat.) der Schritt, nicht Parsus wie parser
Wenn der Dekoderchip z.B. < 2 EUR kostet wäre ich bereit dies so zu tun. Da ich aber im Datenblatt zu selbigem IC schon wieder was über Lizensstufen und Lizensvertrag lese, wird das wohl eher nicht der Fall sein. > Dechiffrier- IC zum Lesen der Meteotime Wetterdaten für die Lizenzstufen > 1 bis 3. Die Steuerung und das binäre Datenformat übernehmen Sie bitte > dem Manuel des Lizenzvertrages. @Christoph Kessler: öhm, hat recht, mit beidem... Nur komisch das PTB die Bits 1...14 anders beschreibt als die darüber. Und wegen Passus, ich hatte kein lat. ausredesuch PS: Bist du eigentlich der mit dem Blechdosenrecycling?!?
Jaja, die Weihnachts-Keksdose als 900MHz-Resonator hab ich hier irgendwo schon mal gezeigt.
Hallo zusammen, ich habe auch heute nacht um 0.00 Uhr den Datenlogger gestartet. Ich dachte mir, den Logger 48 Stunden laufen zu lassen und dann die beiden Tage zu vergleichen. Vom ersten ansehen denke ich schon, dass zumindestens das 14. bit eine Checksumme ist. Ich stelle den File auch hier ein. Dann können wir die Ergebnisse vergleichen und zumindest Empfangsfehler von einzelnen korrigieren. Da es z.Zt. 90 Regionen gibt, für die 4 mal täglich Informationen kommen und diese jeweils 3 Minuten beanspruchen, ergibt sich hieraus schon 1080 Sendeminuten pro Tag. Der Rest bis 1440 ist bestimmt noch für Erweiterungen der Regionen reserviert. Jede Bit-Info besteht aus max. 42 bit, von denen noch die Checksummen abzuziehen sind. Da es hier um wichtigere Infos geht, könnte ich mir auch vorstellen, dass die sich nicht mit Fehlererkennung zufrieden gegeben haben, sondern Fehlerkorrektur installiert haben. Vermutlich bleiben die Minuten, die jeweils für eine Region benutzt werden, über alle Tage gleich. Dann können wir die Änderungen von einem Tag zum anderen für eine Region leicht sehen. Was ich für unbedingt nötig halte ist ein funktionierender Empfänger, der die empfangenen und geloggten Daten im Display anzeigt. Dann könnte es uns gelingen, die Daten zu dechiffrieren. Ansonsten ist das wohl schwierig. Gruß Rolf
Hallo Zusammen, ich habe mal bei meteotime angefragt, ob es den Chip zu kaufen gibt, hier die Antwort: "Nein, der Chip ist als einzelteil nicht käuflich. Wir beliefern nur die herstellende Industrie. Wir haben aber Kunden, die an einer Modul-Lösung mit definierter Schnittstelle arbeiten und diese dann an Einzelanwender anbieten werden. Ob diese Module noch dieses Jahr erhältlich sein werden wissen wir aber nicht." Gruß Bernd
@Bernd: sowas ähnliches habe ich mir schon gedacht... Evtl. kann mal jemand über die "Industrie" versuchen an Muster ranzukommen. Aber wenn da keine Stückzahlen >1000 glaubhaft dahintersteht, denke ich wird man da auf Granit beissen. Haben sie was über die Lizensen gesagt? Was die kosten würden und/oder wie man die bekommt? Gruß Micha,
Hallo Bernd Aus dieser Mail geht meiner Meinung nach folgendes klar hervor: 1. Meteotime war so gescheit die ersten 14Bit vom Dcf77 Signal zu kaufen 2. Meteotime will maximal abcashen 3. Meteotime behält sich vor sollte es nicht so laufen wie vorgestellt, noch einen abcash Versuch mittels Modulen über Hintermänner zu starten 4. Meteotime kann mich mal... LG Michael
Hallo zusammen, hier mal der log (100K) vom 1.2.2007 00:00:00 bis 2.2.2007 23:59. Checksum habe ich noch nicht wirklich entdeckt. Wenn ich Parity Fehler dahinter geschrieben habe, dann war in der Zeitinformation ein Fehler, der Zeile würde ich also nicht unbedingt vertrauen. Vielleicht hat ja jemand Zeit und Lust daran etwas rumzuknobeln. Gruß Rolf
Hallo zusammen Beiliegend noch ein Auszug aus http://www.metas.ch/de/metINFO/2006/METinfo_3_06.pdf Mit Informationen zu Meteotime. Hilft aber bei der Decodierung auch nicht weiter. Gruss Konrad
Vielleicht kann man ja das Wetter von www.meteotest.ch mit den Signalen vergleichen? Markus
@for_ro: tnx für die Aufzeichnung! Also nachdem ich mir die Daten nun mal durchgesehen habe und en Kollege mit ein wenig heuristik-algorythmen darüber hergefallen ist, bin ich im Moment der Meinung: --> Chaos! In dem Dokument das Konrad gepostet hat, steht nochmals drin, das die Wetterdaten Zeitbezogen sein können. for_ro, ich hab nicht die möglichkeit die Daten des Zeitzeichensenders so lange so aufzuzeichnen, aber könntest du das ganze nochmal incl. der Zeitzeichens machen? Also alle 59Bits? Würde evtl. noch weiterhelfen... Gruß Micha,
Ich habe das Ganze hier aufmerksam mitgelesen, DCF interessiert mich immer. Dann darf ich mal eine Bemerkung am Rande loswerden. ELV propagiert die Übertragung von Wetterdaten in den bisher "ungenutzten" Bits am Anfang des Telegramms. Ich habe hier 2 ELV-PC-DCF-Funkuhren (die auch die Daten von ELV-Wettersensoren empfangen) und wundere mich seit einem viertel Jahr, dass ich keine Uhrzeit mehr empfange. Nach einigem Email-Verkehr mit ELV habe ich die Module zur Überprüfung eingeschickt. Vor ein paar Tagen habe ich sie zurückbekommen. "Aufgrund der Umstellung des DCF-Signals ist diese Uhr nicht mehr in der Lage, die Uhrzeit auszuwerten." Zu gut deutsch: die Software des Controllers ist fehlerhaft und kommt mit der Nutzung der unteren Bits nicht klar (die Software hatte übrigens auch jedes mal bei der Zeitumstellung Probleme). Einfach nur peinlich (und ärgerlich), oder? Da werde ich wohl den verwendeten Prozessor "abkratzen" und einen kleinen AVR dran setzen. Ich frage mich allerdings, ob ich der Einzige bin, der eine solche Uhr (noch) nutzt (das Teil ist von 1997). Übrigens arbeiten alle meine anderen Funkuhren (gekaufte von Junghans bis Aldi und selbstgebaute und programmierte) absolut problemlos. Also, viel Erfolg beim Nutzen der Wetterdaten, für mich bedeutet die Umstellung nun aber ersteinmal neue Arbeit. Jörg
@Micha, meinst du wieder für 2 Tage? Ich kann den heute Nacht um 0.00 Uhr starten und dann beliebig lange. Gruß Rolf
@Jörg: Ich habe, so wie es scheint, ein ähnliches Problem. Meine Auerswald DCF77 verliert nach ca. 30min die Synchronisation und synchronisiert dann nicht mehr. Am Empfänger liegts nicht, aus- und wieder einstöpseln desselben hat keinen Effekt, Nach Aus- und Einschalten der Uhr läuft die Synchronisation wieder korrekt durch. Defektzeitpunkt und Meteotime-Aufschaltung passen hier auch zusammen. Da ist dann wohl auch ein neuer Controller fällig. Oder ein kleiner ATTiny, der die Meteotime-Bits aus dem DCF-Signal entfernt. Die ELV-Uhr scheint sich wohl darauf zu verlassen, daß die Bits 1-14 über längere Zeit gleich bleiben und benutzt für die Redundanzprüfung dann alle 58 Bits. Die Lösung, die Bits 1-14 dauerhaft auf 0 zu setzen, könnte hier etwas Arbeit ersparen (z.B. die Sensorauswertung neu zu stricken). Gruss Jadeclaw.
Hallo, hab auch was zu dem Thema. http://shop.elv.de/output/controller.aspx?cid=74&detail=10&detail2=16794&refid=702A1 Gruß Jörg
Hallo Jörg Kennen wir schon danke. Aber ich zahl doch nicht 280 Euro für ein Grafikdisplay, das DCF Daten auswertet und anzeigt. 80 und ich hätte es schon gekauft,... LG Michael
@Jörg, jadeclaw: Da bin ich mal gespannt, ich hab hier im Umfeld auch einige DFC77 Empfänger die meinem support unterstehen, welche zumindest bis jetzt aufholzklopf keine Probleme machen... Jörg, hast du den eMail Verkehr mit ELV noch verfügbar? Oder anders gefragt, was für einen Typ PC-Uhr war das? Ich hab hier auch noch solche "Dongles" für den Game-Port, muss ich heute Abend mal intressehalber anwerfen! Vielleicht sollte man mal mit dem Problem an PTB herantreten. Denn immerhin sind das zwar bis jetzt nur kleinigkeiten, aber viele merken es evtl. garnicht das ihre Uhr nicht mehr Zeitsignal-Synchron läuft. Denn die meisten (mein Funkwecker inklusive) schalten einfach auf internen Clock um und laufen "falsch" weiter! @for_ro: Ja, einfach nochmal aufzeichnen, 1 oder 2 tage sollte mal für den Anfang wieder reichen. Aber mit der zeitinformation dabei. Also alle 59 Bits! Das wäre Klasse! Gruß Micha, PS: Meine Funkwetterstation mit DCF77 Empfänger zeigt -gerade aufgefallen- das Antennesymbol auch nicht mehr an. Muss ich mal heute Abend genauer untersuchen!
Gestern abend gab es scheinbar für einige Minuten ein Empfangsproblem, die DCF-LED flackerte nur wild herum oder blieb für einige Minuten ganz aus. Etwas später rappelte sich der Empfang wieder und alles lief sauber weiter. Zu dem Problem mit manchen Funkuhren kann ich nur sagen, daß früher die Bits 0 bis 14 halt einfach nur "0" waren. Wahrscheinlich kommen diese Uhren in der Parität oder einfach beim Zählen durcheinander, weil jetzt hin und wieder "1"en dazwischen sind. Eine Ausnullung der ersten 14 oder gar 20 Bits mittels eines kleinen "Zwischeninterpreters" sollte dieses Problem beseitigen. Meine Eigenbauuhren ignorieren die ersten 20 Bits, weil die bei dem Empfang eines Zeittelegramms sowieso über sind. Somit machen Empfangsfehler in dem Bereich das Telegramm auch nicht jedes Mal kaputt. Ich frage mich jetzt allerdings, wer für den Schaden aufkommt, der bei älteren Industrie- oder Kirchturmuhren durch die Protokollumstellung entsteht... Ganz zu schweigen von der Luftfahrt und Navigation...
@Travel Rec. >kaputt. Ich frage mich jetzt allerdings, wer für den Schaden aufkommt, >der bei älteren Industrie- oder Kirchturmuhren durch die >Protokollumstellung entsteht... Ganz zu schweigen von der Luftfahrt und >Navigation... Was für eine Protokollumstelleung? Die Paritätsbits haben immer nur die Zeit und Datumsbits abgedeckt. Bits 1..14 waren immer schon "dont care". MfG Falk
Das sag mal den älteren Uhren. Irgenwas müssen die ja mit den Nullen gemacht haben. Daß die "Parität" sich nur auf das eigentliche Zeittelegramm bezieht, ist mir auch klar ;-)
@Travel Rec. >Das sag mal den älteren Uhren. Irgenwas müssen die ja mit den Nullen >gemacht haben. Daß die "Parität" sich nur auf das eigentliche Wer solchen Murks programmiert muss ihn auch auf eigene Kosten updaten. Oder er ist clever und macht einen Hype ala Y2K draus ;-) MfG Falk
Genau! Der (völlig unbeabsichtigte) DCF-Uhren Bug ;-)
Wenn man weiß, wann die "defekte" Uhr den Sender abfragt, könnte man ja um diesen Zeitpunkt herum einen eigenen DCF77-Sender neben der Uhr einschalten, der die korrigierten Impulse abstrahlt. Besonders geschickt wäre, auch die Langwellen frequenz im Controller zu erzeugen und zu modulieren.
Mein Funkwecker ist 2x Abgestürzt diese Woche. Nicht das das was damit zu tun hat... panikmodus ein
@Sebastian: Meiner "stürzt" täglich mehrmals nacheinander ab... Meist so zwischen 5 und 5:15Uhr... aber ich denke nicht, das es was mit der Umstellung des DCF77 Signals zu tun hat! ;)
Standardquarze direkt zum Runterteilen auf 77,5 kHz gibts anscheinend nicht 11M / 142 = 77,46k das trifft schon ganz gut 11,0592M / 143 = 77,33k 12M / 155 = 77,42k na es läßt sich was finden, gerader Teilfaktor wäre praktischer, also 11 MHz schon mal ein Kandidat.
Die ELV-Uhren hat nicht zufälligerweise Micros*** programmiert? ;-)
@ Michael S. (mst) Die von mir angesprochenen PC-DCF-Funk-Empfänger sind die kombinierten mit DCF-Empfang und Funk-Wettersensor (AS2000 u.ä.). Gab es vor ein paar Jahren mal recht preiswert. "Dongle"-Empfänger liefern nur die einzelnen DCF-Impulse an den PC und eine Software auf dem PC liest diese dann ein und auswertet sie aus. Hier könnte natürlich auch hier die PC-Software Probleme machen. Den Email-Verkehr mit ELV habe ich natürlich noch (allerdings zuhause). Großartige details kann man da (zumindest von Seiten ELV) nicht entnehmen. Ich habe uach lange gebraucht, um den Ausfall mit diesen Wetterdaten in Zusammenhang zu bringen, da waren die Module bereits bei ELV zur Überprüfung. Die Idee mit dem zwischengeschalteten Controller ist gar nicht so dumm. Allerdings hat mich in der Vergangenheit das einfache "Übertragungsprotokoll" für das Auslesen mit dem PC gestört, und das wäre nun ein Anlass, das Ganze mal auf eine ordentliche Abfrage per RS232/UART umzustellen. Bisher ging das ja mit BitBanging und das läuft unter Win2k und aufwärts wahrscheinlich eh nicht mehr (habs noch nicht versucht). Tipps für die Wettersensordaten habe ich schon gefunden. Jetzt fehlt nur noch die nötige Zeit. Jörg
Die "Zwischenschaltung" nach meinem Vorschlag wäre drahtlos. Ein DCF-Modul und ein 8-Pinner würde reichen, 11 MHz Takt, der Timer teilt das auf 77,5 herunter, ein Spannungsteiler am Ausgang wird von einem zweiten Portpin als "open collector" beschaltet im Sekundentakt nach Masse gezogen und damit der Ausgangspegel reduziert. Ein dritter Portpin ist der Eingang des DCF-Moduls. Zur vollen Stunde geht das auf Sendung und mit ein paar Drahtwindungen über die fehlerhafte Uhr wird die mit korrigierter DCF-Zeit bedient.
Nochn Vorschlag, besonders simpel: TTL-Doppel-Monoflop 74xx221, eines detektiert den fehlenden 59-Sekunden-Impuls, das andere nullt die nächsten 14 oder 20 Bit.
Schubs! Bitte lasst diesen Thread nicht verhungern. Ich bin zwar zu dusselig um Substanzielles beitragen zu können, doch interessieren tut's mich brennend! ;-))
Schon lustig: da meckert man über heuristische Programmierungen, die sich den damals aktuellen Signalstand für Vereinfachungen zunutze gemacht haben (die nun nicht mehr gelten) und will im gleichen Atemzug durch Beobachtung den Code knacken, als ob damit nicht genau dasselbe passieren würde. Wenn die einen Baustein verkaufen, der jahrzehntelang funktionieren muß, aber der Code knack-gefährdet ist, werden die sich sicherlich nicht allein auf "security by obscurity" verlassen. Ein Ex-Mitarbeiter, der das Verfahren postet und schon kann jeder Bastler das Signal decodieren? Nie! Die Decodierung selbst wird auch wieder per "fernwartung" umprogrammierbar sein; alles andere wäre verrückt. Sobald also das reverse-engineering beendet ist, wird der nächste Level des Hackerspiels aktiviert ... Irgendwie ist es ja auch weniger Aufwand, einen PC eine Wetterwebsite parsen und die Signale selbst senden zu lassen. Also wenn das hier nicht als sportliche Herausforderung verstanden wird, den bösen Leuten, die hier ein Geschäftsmodell aufbauen wollen, mal zu zeigen, wo der Hammer hängt ... würde ich es einfach bleiben lassen!
...ich warte grad mal auf das Log von Rolf Im forum (for_ro), damit ich nächste Woche im G'schäft wieder was zu tun hab! :-) @Philipp Sªsse (philipp): Wir sind doch hier freischaffenden Künstler, da brauchen wir über Sinn und Unsinn nicht nachdenken! Würde jeder so denken, "einfach bleiben lassen", dann bleibt das eigene geistige Know-How doch auf der Strecke. Selbst wenn sich nur ein Frame decodieren liesse und sie dann den Algorythmus ändern, hat es sich meines erachtens nach schon für "mich" gelohnt... Aber ich wäre Vorsichtig mit dem zugeben und posten eines "ich habe es Geschafft"... Die rechtliche Lage müsste man hier erst einmal genauer untersuchen lassen! Aber zu den Empfangsproblemen noch was: Ist wohl wirklich so, meine Wetterstation scheint da auch irgendwie ihre Probleme zu haben. Hatte heute ich mal die Batterien ruas und nach dem wieder einlegen, wurde die Uhrzeit zwar nach ein paar Minuten empfangen und auch angezeigt, aber... ...das Antennesymbol blinkt erst, wird dann dauernd angezeigt und verschwindet dann nach ca. 30-60min ganz. Seither blinkte es zu beginn, dann blieb es statisch angezeigt für normalen Empfang... Naja, Hauptsache sie Empfängt einmal die Zeit, das Teil hätte keine Tasten mit denen man die Uhrzeit stellen könnte! :-) Gruß Micha,
Philipp Sªsse wrote: > Wenn die einen Baustein verkaufen, der jahrzehntelang funktionieren muß, > aber der Code knack-gefährdet ist, werden die sich sicherlich nicht > allein auf "security by obscurity" verlassen. Ein Ex-Mitarbeiter, der > das Verfahren postet und schon kann jeder Bastler das Signal decodieren? > Nie! Wenn das Verfahren so geheim ist, dann werden es halt einfach nur sehr wenige Mitarbeiter kennen. > Die Decodierung selbst wird auch wieder per "fernwartung" > umprogrammierbar sein; alles andere wäre verrückt. Sobald also das > reverse-engineering beendet ist, wird der nächste Level des Hackerspiels > aktiviert ... Das Update ist entweder verschlüsselt oder unverschlüsselt. Wenn es unverschlüsselt ist, dann bringt es nicht viel. Wenn es verschlüsselt ist, dann kann der Mitarbeiter, der die normale Verschlüsselung verrät, ja auch gleich diese Verschlüsselung verraten -> Ich kann hier also keinen Vorteil erkennen. Außerdem sind Updates ja auch nicht ohne Risiko. Wenn das Update schiefgeht, dann produzierst Du damit ja einen Garantiefall. Außerdem gibt es ja Empfänger, die das Update nicht gehört bzw. nicht vollständig empfangen haben, für diese musst Du dann z.B. täglich das Update wiederholen. Deswegen kann ich mir nicht vorstellen, dass es ein remote Update gibt. Markus
Hallo zusammen, hier die Aufzeichnungen von 2 Tagen, mit allen Ticks. Zur besseren Lesbarkeit habe ich einige Blanks mit einfügen lassen. Was auffällt, ist, dass die meisten Fehler durch einen zusätzlichen Tick während der ersten 14 Bits kommen. Damit kommen evtl. viele Uhren nicht zurecht. Vielleicht rühren daher eure Fehler. Die Ticks sind allerdings nicht immer zur vollen Stunde, wo die meisten Batterie getriebenen Uhren empfangen Man müsste sich das mal mit einem Oszi ansehen. Nur sind die leider recht selten. Gruß Rolf
many thanks! Gleich mal nächste Woche drüber herfallen... Gruß Micha,
Ach übrigens wenns auch nur ein ganz simples Verschlüsselungsverfahren ist könnt ihr aufzeichnen soviel ihr wollt und es wird trozdem immer zufällig erscheinen.
...hinter jedem Chaos steckt ein System! Gruß Micha, PS: Ich bezweifle auch, das es auch diesem Wege machbar ist, aber Versuchen kann man es ja mal... aber wie ich schon scheib: Zugeben würde ich es nicht!
Ja klar, es sieht aber aus wie Zufall das sit doch der Witz bei ner Verschlüsselung. Und selbst einfache Block Kryptosysteme die leicht in Hardware zum implementieren gehen lassen dir keine wirkliche Chance.
Hallo zusammen lasst euch bloss nicht von diesen ewigen Das-bringt-doch-eh-nichts-Nörglern abhalten. In der Firma haben wir ohne Ende Leute, die sagen, dieses oder jenes wird nichts und die sind dabei noch unheimlich einfallsreich. Richtig unterstützen werden immer nur eine handvoll. Es macht doch Spass, an so was rumzuknobeln. Und es ist sicherlich niemand in der Lage zu 100% vorherzusagen, dass es nicht geht. Als die Jungs anfingen, das S65 Display anzuschliessen habe ich auch gedacht, ohne Doku kriegen die das nie hin. Und was soll ich euch sagen: Es klappt fantastisch. Also machen wir weiter. Gruß Rolf
@alle nach meiner Meinung könnten wir die Codierung mit etwas guten Willen dechiffrieren. Dazu müssten aber u.a. mehrere Randbedingungen erfüllt sein: 1. Problematik Mitschnitt: - wir benötigen viele Mitschnitte über längere Zeiträume von mehreren Standorten Deutschlands (wegen Raumwelle/Bodenwelle usw) (Rolf sein formatierter Mitschnitt wäre als Mustervorlage sehr gut geeignet, Rolf, großes Lob an Dich) - Aus den vielen Mittschnitten muss ein einziger lückenloser und fehlerfreier "Referenz_Mitschnitt" erstellt werden. Denn ein einziger "fehlerbehafteter" Mittschnitt könnte die Decodierung/Deciffrierung extrem erschweren. - Die Wettervorhersagen müssten auch mit protokolliert werden, zur Auswertung der Daten Bis hierhin war's noch relativ einfach, gel....... 2. Decodierung / Dechiffrierung: - zuerst sollten wir untersuchen, in welchen Abständen, wenn Überhaupt, das Codierverfahren geändert wird. Bsp: Ändert sich das Wetter nicht (Großwetterlage), sind die Vorhersagen meistens nahezu konstant - wir müssen hier alle gemeinsam überlegen, welche WETTERINFORMATIONEN jeden Tag gleich gesendet worden sein könnten Anmerkung: Nach meiner Meinung ist das Codiersystem / Chiffriersystem sehr gefährtet, denn wir wissen, welche Vorhersageinformationen enthalten sind .... Beispiel Erfurt: http://www.wetter.com/v2/?SID=&LANG=DE&LOC=7000&LOCFROM=7000&type=WORLD&name=Erfurt&id=40158 Zum rechtlichen Aspekt: Wir sind uns doch alle einig, das wir das dechiffrierte / decodierte Signal nicht nutzen wollen, wir wollen doch nur wissen wie die Informationen codiert worden sind. Und das kann uns doch keiner verbieten. Bernhard PS: Schaut Euch mal die Enigma an, und wir Deutschen dachten, diese Chiffriermaschine wäre sicher... haha http://de.wikipedia.org/wiki/Enigma_(Maschine)
Ich könnte mir schon vorstellen dass das nur eine halbherzige Bitverwürfelung ist, mit dem Ziel eine unerlaubte Verwendung illegal zu machen. Wenn es sich aber um eine richtige Verschlüsselung handelt, z.B. vernünftig implementiertes AES, dann sind die Erfolgschancen exakt 0.
Die Enigma an sich war schon sicher und wäre ohne bei entsprechender Handhabung auch nicht geknackt worden (z.B. Aufbau der Funksprüche war immer gleich bzw. haben immer gleich angefangen, viele Standardmeldungen mit immer gleichem Aufbau, Einstellungen wurden aus Unwissenheit/Faulheit beibehalten etc.). Der endgültige Durchbruch um auch die Marine-Enigmas zu entschlüsseln kam auch erst, als ein Codebuch sowie eine Enigma in die Hände der Briten fiel.
Klingt einerseits sehr interessant, ich höre auch das erste mal davon... Andererseits ist mir aufgefallen das meine eigenbau Funkuhr schon seit längerer Zeit nicht mehr oft synchronisiert ist. (Ich sehe auf dem LCD wenn fehler im empfangenen sind) Ab November könnte hinkommen... Ich muss wohl damals davon ausgegangen sein das die bits immer 0 sind und so baut sich die uhr wohl öfter misst beim parity check... werde mir das wohl mal etwas genauer ansehen müssen. Ich währe auch durchaus bereit irgendwie dazu beizutragen die Informationen zu entschlüsseln (auch wenn ich noch nicht weis wie... vlt. protokolle posten?) Währe doch cool ein Nokia-Display an die Uhr zu hängen und da die Wettervorhersage zu sehen 8-) Ich sollte wohl besser ins Bett gehen und da weiter träumen... achja: abo
Andreas Schwarz wrote: > Ich könnte mir schon vorstellen dass das nur eine halbherzige > Bitverwürfelung ist, mit dem Ziel eine unerlaubte Verwendung illegal zu > machen. Wenn es sich aber um eine richtige Verschlüsselung handelt, z.B. > vernünftig implementiertes AES, dann sind die Erfolgschancen exakt 0. Warum so kompliziert? Ein einfacher Blockchiffre im CBC Mode und alle Träume über dechiffrierung sind eh nahezu dahin. http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode Analysieren wir doch mal euren "Angriff": >> zuerst sollten wir untersuchen, in welchen Abständen, wenn Überhaupt, >> das Codierverfahren geändert wird. Warum sollte man das ändern?? (oder meisnt du wann sich die Datenblöcke unterscheiden?) >> Ändert sich das Wetter nicht (Großwetterlage), sind die >> Vorhersagen meistens nahezu konstant im R-CBC Mode Wird gleiches niemals zweimal gleich verschlüsselt! (Initialisierungsvektor könnte die Zeit sein oder wird im ersten Block übertragen) >> wir müssen hier alle gemeinsam überlegen, welche WETTERINFORMATIONEN >> jeden Tag gleich gesendet worden sein könnten Selbst wenn man EXACT wüßte welche Informationen übertragen wurden kann man dadurch keine Rückschlüsse auf zukünftiges machen (siehe erster Punkt) (Zitat) Der CBC-Mode hat einige wichtige Vorteile: - Klartextmuster werden zerstört. - Jeder Geheimtextblock hängt von allen vorherigen Klartextblöcken ab. - Identische Klartextblöcke ergeben unterschiedliche Geheimtexte. >> Nach meiner Meinung ist das Codiersystem / Chiffriersystem sehr >> gefährtet, >> denn wir wissen, welche Vorhersageinformationen enthalten sind .... Siehe oben das ist völlig Gleichgültig. Selbst wenn ich den ganzen Tag aaaaaaaaaaaaaa...a übertrage würde dadraus eine Zufällige (gleichverteilte) Buchstabenfolge. Das ist keine Schwarzmalerei, ich wollt nur drauf hinweisen das WENN die das auch nur etwas klever verschlüsselt haben --> no Chance
Wenn es denn so wäre, wie oft würden gleiche Bitfolgen (gleiche 14 Bitblöcke) bei solch einer Verschlüsselung vorkommen? (verteilt über die Zeit)
Hallo zusammen, völlig unabhänging vom sportlichen Ehrgeiz, den ich sher gut verstehen kann, solltet ihr ein paar Dinge überlegen: 1. Da hat sich jemand (gute) Gedanken gemacht und will damit Geld verdienen. Das ist nicht verwerflich und das zu torpedieren ist ehrlich gesagt nicht lustig. 2. Sooo wichtig ist diese Information ja eigentlich gar nicht, man bekommt das Wetter ungefähr zig-mal am Tag kostenlos von jeder Seite aufgedrängt. 3. Das Hacken verschlüsselter Informationen ist strafbar, völlig unabhängig von der weiteren Verwendung. Wenn tatsächlich jemand das trozdem wollen und schaffen sollte, täte er gut daran, das nicht in dieser Form zu veröffentlichen. Wenn er allerdings einen Vorschlag postet, wie man in 14 Bits sinnvoll Wetterinformationen verpacken kann, kann er den sogar GPL stellen ;-) Wäre ja schade, hier die besten Leute einige Zeit nicht mehr anzutreffen, oder...? Gruß Uli
Wenn man vereinfacht davon ausgeht das unser ganzes Alphabet aus 26
Buchstaben besteht {a, b, c, ... , x, y, z} und ich dir immer ein a
sende (also der gnze Block besteht dann aus 14 a's) würde 1/14 = 0.07
aller Blöcke gleich sein (in etwa) was gleich der Wahrscheinlichkeit
entspricht das ich dir was zufälliges gesendet habe (und nicht real
verschlüsseltes).
Das "Spiel" dazu heißt "Real or Random"
A und B spielen ein Spiel nach folgenden Regeln:
- B wählt sich zufällig ein bit b aus {0,1}
- A darf nun Anfragen an B stellen (idr beliebige Bitfolgen, belibig
viele)
- A beantwortet diese Anfrage mit der Verschlüsselung der Anfrage wenn
das Bit b = 0 ist, ansonsten wird ein zufälliger Bitstring gleicher
Länge ermittelt und verschlüsselt.
- Nach beendigung der Anfragephase muß A sagen ob b = 0 oder 1 war
- Wenn A richtig liegt hat er gewonnen, sonst verloren.
Man sieht das B natürlich in 50% der Fälle gewinnt wenn er einfach
garnix anfragt sondern einfach zufällig 1 oder 0 sagt.
Deshalb ist ein "guter" Angreifer auf ein System der welcher in diesem
Spiel mehr als 50% aller Spiele gewinnt.
Also wenn die ganze decodierung in einem 8pinner erfolgt, kann ich irgendwie nicht glaube das ein zu aufwendiger Verschlüsselungsalgorithmus verwendet wird. Und außerdem kennen wir ja nicht nur den verschlüsselten Datenstrom, sondern theoretisch auch den decodierten (wenn sich jemand den entsprechenden chip kaufen würde).
> Also wenn die ganze decodierung in einem 8pinner erfolgt
Die Anzahl der Pins sagen da nichts aus.
Ich habe mir dcf_log_2Tage_59Ticks.txt mal angesehen. 14% der Werte fürs
Wetter (bei 2881 Werten insgesammt) kommen nach meiner Zählung zwei oder
mehrfach vor. Jemand mit etwas Statistik könnte mal sagen ob dies bei
zufälligen (=verschlüsselt) Werten zu erwarten wäre oder nicht.
Naja wenn ich so einen Chip kaufen kann... und wer sagt dir das das was vorne reingeht 1:1 das entschlüsseltet ist was hinten rausgeht? Könnte ja auch sein das einfach nen ASCII String rauskommt sobald man genügend gültige Daten eingespeisst hat. Und wie ich shcon sagte das entschlüseln ist nicht sehr komplex das kann man mit etwas Logik recht einfach machen, das schafft selsbt nen AVR nebenbei, jezt nimmst du noch 100 Schlüssel die gleichverteilt gewählt werden entschlüsselt halt der controller das ganze 100mal, das heißt selsbt wenn du es schaffst einen Schlüssel zu brechen, beleiben noch 99 weitere wo du Datenmüll erhälst.
Ich habe mir die erste mitgeschnittene Datei einmal näher angesehen. (Werte in Excel übernommen und Pivot-Tabelle erzeugt) Es wurden insgesamt 2880 Datensätze aufgezeichnet. 6 der 14-bit-Datensätze erscheinen 4 mal. 43 erscheinen 3 mal. 279 erscheinen 2 mal und der Rest ist nur einmal vorhanden. Mit der Annahme, dass sich das Wetter innerhalb von zwei Tagen nicht so häufig ändert, scheint die Verschlüsselung etwas anspruchsvoller zu sein. Entweder erstreckt sich die Verschlüsselung über mehrere Blöcke oder aber die Zeitinformation wird geschickt einbezogen. Eine Entschlüsselung ohne "social engeneering" erscheint mir aussichtslos.
Wie im Wiki beschrieben kann man für den CBC Mode auch ein TimeStamp verwenden, und bei einer Zeitübertragung ist das doch ne super möglichkeit :)
so also ich habe mal ein bissel überschlagen
die machen für 90 regionen eine 4 tage vorschau
pro tag werden 54 bit benötigt (! nur gedanklich überschlagen kein
belastbarer wert)
macht 19440 bit die übertragen werden müssen hier fehlen aber
prüfsummen und redundanz denn wenn mal nicht optimaler empf ist dann
würde sonst ne region / tag einer region ausfallen. zumal pro 24h nur
20160 bit zur verfügung stehen passt eine vollständige widerholung gar
nicht rein.
die jungs machen mindestens noch 2 andere sachen komprimieren oder in
der übertragungsart überhaupt.
hat sich schonmal einer die schwingungen auf dem dcf angeguggt ?
ein normaler empf interessiert sich ja nur für die "hüllkurve"
nich das die da noch mit phasensprung innerhalb ihres bits basteln.
wie bin ich auf 54 bit gekommen?
8 windstärken -> 3 bit
15 vorhersage tag -> 4 bit
15 vorhersage nacht-> 4 bit
8 niederschläge -> 3 bit
63 temp tag -> 7 bit
63 temp nacht -> 7 bit
bis hier isses einfach bei folgendem bin ich mir unsicher
sonnenzeiten:
dafür würde ich nicht vollständig hh:mm übertragen sondern nur die mm
weil so markant wird sich die erde nicht schneller oder langsamer drehen
den rest mit ungefährer vorgabe im controller
also -> 7 bit aufgang
-> 7 bit untergang
wetterentwicklungen kritische (11 stck.)
können ja da sein oder nicht, viele nicht in kombination
also -> 8 bit
5 wetterlagen entspricht 6 stufen
sowie 9 windrichtungen sind beides doofe zahlen würde ich kombinieren
zu 15 stufen -> 4 bit
so das sind meine gedanken den region würde ich nicht mit übertragen
das ding hast zu wissen das 7:oo berlin dran ist
56 bit sind ein ganzzahliges vielfaches von 14
Bei den ganzen Überlegungen zur Verschlüsselung wird übersehen, dass die Geräte ja auch batteriebetrieben sein können und deswegen auf keinen Fall die ganze Zeit auf Empfang sind. Die Verschlüsselung kann sich also kaum auf einen größeren Bereich beziehen sondern immer nur auf ein (oder wenige) Telegramm(e). Wenn es also einen veränderlichen Startwert gibt, dann wohl tatsächlich die Zeit. Auch darf der Entschlüsselungschip nicht beliebig viel Strom verbrauchen. Will man damit einen größeren Markt abdecken, dann muss das Ganze billig sein, d.h. ein möglichst günstiger Prozessor -> wenig Programmspeicher, wenig RAM. Markus
Wärend meiner Pilotenzeit zu Beginn des Computerzeitalters wurden die Wetterdaten in Zahlenkolonnen per Fernschreiber übertragen. Die "Wetterfrösche" zeichneten an Hand dieser Daten die Wetterkarten. Möglicherweise sind die neuen Wetterdaten im DCF77 ähnlich "codiert" wie damals. Leider habe ich die alten Unterlagen nicht mehr, aber vielleicht nützt es, mal nach aviation weather oder nach wind aloft forecasts zu suchen um das alte System zu verstehen.
Jörn Paschedag wrote: > Wärend meiner Pilotenzeit zu Beginn des Computerzeitalters wurden die > Wetterdaten in Zahlenkolonnen per Fernschreiber übertragen. Das kenn ich noch. Als Gymnasiast war es ein Jahr lang meine Aufgabe um 18 Uhr die Ablesungen zu machen, die Codierung zu erstellen und per Fernsprecher nach Salzburg durchzugeben. > Die > "Wetterfrösche" zeichneten an Hand dieser Daten die Wetterkarten. > Möglicherweise sind die neuen Wetterdaten im DCF77 ähnlich "codiert" wie > damals. Glaub ich ehrlich gesagt nicht. Das Zeugs ist so speziell, dass es eigentlich nur für einen Meteorologen interessant ist. Ich denke mal, da wird nicht viel mehr drinnen sein als: Regionscode Temperatur Niederschlagswahrscheinlichkeit Luftdruckvorhersage schön/bewölkt/schlecht/Regen Nebel ja/nein Für die breite Masse reicht das.
was drinn ist und mit welcher "genauigkeit" habe ich (oder wie es alle können auf der website lesen) aufgeschlüsselt und zusammengefasst
@kbuchegg IMHO sagt man auch heute noch Wetterfrösche zu den Meteoro-logen ;-)
fassen wir mal zusammen, was wir sicher wissen: (bitte korrigieren bzw ergänzen...) # es werden 14 bit pro minute gesendet, 20160 bit /tag # die info wird 2x tägl. gesendet , 10080 bit /alle info # info ist bzgl. 60 regionen , 168 bit / region (maximal) # info besteht aus : Ort, Temp., ...(s.o. @balu , ca 50bit nötig) - info könnte 2 oder 3x wiederholt werden # info hat keinen einfach erkennbaren kopf, d.h. entweder serieller string mit "marke", dann daten-block, oder der "kopf" ergibt sich aus der zeit-info, zb jede gerade 10-minuten-zeit ist der block-anfang wegen fehler, empfangs-ausfall usw, muss relativ oft ein sync möglich sein, der datenblock hat dann parity oder nen crc (wenn verwürfelt + reed-solomon oder so...schlechte karten für uns)
Hi, Christoph Kessler hat doch ganz oben im Thread den Link zur PDF geschickt: http://www.hkw-elektronik.de/pdf/DB%20W-Protokoll-V%201.pdf Da ist doch alles haarklein aufgeschlüsselt.
bei der beschreibung handelt es sich aber um die decheff version oder lese ich gerade was falsch
Was meinst du mit 'decheff'? Das Protokoll ist genau dasselbe wie beim Rest der Bits, also 'Quasi-BCD', bzw. Binär.
Da steht auch genau drinn wie das mit der Regionseinteilung ist : Ein Wetterprotokoll für eine Wetterregion und eine Vorhersage wird über den Verlauf von 3 Minuten gesendet. Diese Wetterdaten sind über die Sendezeit einer festenRegion zugeordnet. Sollte das jemand mal im orginal haben steht irgendwo in nem heft dabei wann was gesendet wird !!!! Das bedeutet man weiß wann welcher input kommt und man weiß wie die Wetterdaten sind und wie sie entschlüsselt sein müssten weil es da auch drinn steht =) Beispiel : Anzahl Datenbits: Tag - 4 Bit; Nacht - 4 Bit Lage: Wetter Tag - Bit 0 bis Bit 3 Wetter Nacht - Bit 4 bis Bit 7 Dateninhalt: verschiedene Wetterbeschreibungen Gültigkeitsbereich: getrennt für Tag und Nacht usw... Das heißt man wüsste genau wie der input unverschlüsselt sein müsste ^^ und man müsste den verschlüsselten input aufzeichen und das 2-3 tage und dann nach Gemeinsamkeiten schauen. Zeitverschlüsselung fällt außerdem eigendlich weg da das ja immer zu bestimmten Zeiten gesendet wird. Gruß Andreas ( sehr interessanter Tread )
Das ist aber alles die Aussage auf der Encoder Seite. Was vorne herein kommt, kann schon wieder was ganz anderes sein. Angenommen die Übertragung für Gebiet X startet laut der PDF-Datei um 10:00 so könnte doch die eigentliche Übertragung des Signales schon um 9:00 oder 8:34 erfolgt sein. Doppelübertragung mehrfach verteilt, Prüfsummen, Schlüllel, etc. Der Controller hinter dem Encoder wartet, bis es 10:00 ist und erhält für das geforderte Gebiet seine Fehlerfreien Daten. Dieses System ändert man jeden tag anhand des Schlüssels. Ich würde sagen aufgrund der wenigen Bits/Tag würde eine Entschlüsselung ewigst dauern/fast nicht möglich sein. Gruß, Tubie
@alle
Könnte jemand von Euch in Erfahrung bringen, wann welche Daten für
welche
Region gesendet werden?
(Bsp: wenn ich das Gerät um 00.00 Uhr einschalte,
stehen die Wetterinformationen um 03.00 Uhr für Erfurt zur Verfügung?
Schalte ich das Gerät erst um 4 Uhr ein, wann stehen dann die
Wetterdaten für Erfurt zur Verfügung ? Wie sieht es für andere Regionen
aus)
Stehen die Wetterdaten komplett zur Verfügung,
oder wird in der Stunde X die Windstärke übermittelt
und in der Stunde Y erst die Temperatur?
Ich hätte eine große Bitte:
Stellt uns bitte einen längeren Mitschnitt zur Verfügung, wir suchen
einzelne Bitts, die zu gleichen Uhrzeiten immer gleich sind,
in einer Datenbank (Access) wären dies / dieses schnell gefunden ;)
Bernhard
Ich denke ich werde meinen Wetter-Datenlogger mal kurzfristig umstricken und statt Wetterdaten die Bits 1 bis 19 aufzeichnen. Mit 512kB läuft er 'ne Weile, dann kann ich in Ruhe mal zumindest die Wiederholung der Bitmuster auswerten. Vielleicht gibt' bis dahin auch von anderer Seite neue Erkenntnisse.
In der Bedienungsanleitung dieses METE-ON1 steht drin: "Temperaturvorhersage Tag und Nacht (beim 4ten Tag, dem DAY 3, keine Nachttemperatur)" http://www.elv-downloads.de/service/manuals_hw/71481_METE_ON1_manual_g.pdf Ich kann in der Protokollbeschreibung keine derartige Einschränkung finden. Bin ich zu blind dafür oder werden hier Bits gespart? Könnte aber natürlich auch eine Einschränkung des Gerätes sein. Außerdem wird in der Bedienungsanleitung nochmals drauf hingewiesen, dass es Regionen mit 4 und Regionen mit 2-Tage Vorhersage gibt. Das steht zwar auch im Protokolldokument, aber da kann man es leicht überlesen. Markus
Also irgendwie hab ich das Gefühl, dass das ganz ohne einem Chip zum Testen nichts wird. Es wäre ja auch interessant, ob der Chip so: Bit rein-->Bit raus arbeitet oder zB 8x Bit rein und dann erst ein Byte raus. Ich glaube ein Chip würde Reverse-Engineering wesentlich erleichtern
Als erstes überprüft mal ob die Wetterdaten mit gleichem Wetter zur gleichen Region aber zu unterschiedlichen Zeiten gesendet denoch gleich codiert sind. Wenn dies so ist dann ist die Wahrscheinlichkeit sehr hoch das der Dekoder eben nicht mit wechselnden Schlüsseln, Schlüsseln aus der Uhrzeit oder ähnlichem arbeitet. Sehr wahrscheinlich wäre dann entweder ein Schlüssel pro Region oder generell nur ein einztigster Schlüssel, eg. Verfahren. Gruß Hagen
Es ist aber leider unmöglich zu sagen ob ein Wetter gleich war wenn sich bsp die Vorhersage dann um nen halben tag oder so aktuallisiert oder auch nur die Winddstärke sich ändert. Also ohne Versuchsobjekt ist das eigendlich unmöglich. Gruß Andreas
Hi, lese schon eine Weile mit, dickes Lob an Euch Inthusiasten!!! nach allem Horroszenario bin ich ja froh, daß unsre Kirchenuhr noch richtig geht mit PIC16F877 da geht die rote LED (1.richtig decodierte Min + 1 =2.richig dec. Minute)immer noch an und Pendel wird bei Fehler >10 sec angehalten, Zeit, Temp. und Pendelauslenkung alle 2h auf Chipcard geschrieben, täglich mithören um auf 433 Mhz... sri wg PIC steig grad um... was mich stört sind die "nur 14 Bit", seid Ihr sicher, das da nicht weitere technische Kunstgriffe gemacht werden? Der Text stammt von 2004, vielleicht heute nicht mehr pseudo-random sein http://www.piester.de/dp200403.pdf "4.3 Phasenmodulation Zur Modulation mit einem Phasen-„Rauschen“ (PM) wird die Trägerphase entsprechend eines PRN-Kodes (Pseudo-Random Noise Kode) mit einem Phasenhub Dj von ± 13∞ um ihren Mittelwert jm umgetastet [16]. Als PRN-Kode wird eine binäre Zufallsfolge p(t) maximaler Zykluslänge mit N Zeichen (N = 29 = 512) verwendet, so dass die Phasenzustände jm + Dj und jm – Dj gleich häufig (je 256 mal) auftreten. Dadurch bleibt der Mittelwert der Trägerphase unverändert, und die Verwendung der Trägerfrequenz als Normalfrequenz wird durch das Phasenrauschen nicht nennenswert beeinträchtigt. Bild 7 zeigt den Verlauf der Amplituden und derPhase der DCF77-Trägerschwingung während einer Sekunde. Der Träger, die AM-Sekundenmarken und die Phasenumtastung sind zueinander phasensynchron. Die Erzeugung von p(t) erfolgt mit dem in Bild 8 gezeigten Schieberegister, dessen Ausgänge 5 und 9 über ein Exklusiv- Oder-Gatter auf den Schieberegistereingang rückgekoppelt sind. Jeweils 0,2 s nach Sekundenbeginn wird das Schieberegister aus dem Zustand Null neu gestartet und nach Ablauf eines vollständigen Zyklus, etwa 7 ms vor der nächsten Sekundenmarke, wieder angehalten. Die Taktfrequenz fT des Schieberegisters beträgt 645,83 Hz und ist eine Subharmonische (77 500/120) der Trägerfrequenz 77,5 kHz. omit beträgt die Dauer TT eines Zeichens 1,55 ms und die Dauer eines vollständigen Rauschzyklus 793 ms. Im PRN-modulierten Signal dienen zehn invertierte Pseudozufallsfolgen in den Sekunden 0 bis 9 als Minutenkennung. Andere Informationen werden in den Bits 1 bis 14 nicht übertragen. Generell erfolgt die Übertragung von Binärdaten mit der PRN durch Invertieren der Pseudozufallsfolge p(t) (siehe Bild 8). Mit jedem Rauschzyklus wird ein Bit übertragen, wobei nicht invertierte Pseudozufallsfolgen p(t) der binären Null und invertierte Pseudozufallsfolgen p(t) der binären Eins entsprechen. Wenn eine Schaltsekunde eingeführt wird, erscheinen bei der PRN die 10 invertierten Rauschfolgen p(t) zur Minutenmarkenidentifizierung um 1 s später. Ab der 15. Sekundenmarke ist die durch PM und AM übertragene Binärinformation identisch, so wie sie zuvor dargestellt wurde. " https://www.ptb.de/de/org/4/44/pdf/dcf77.pdf: "Wegen der Anwender, die DCF77 als Normalfrequenzsender nutzten, wurde von nun an der Träger für die Dauer der Sekundenmarken nicht mehr auf Null getastet sondern nur auf eine Restamplitude von 25 % abgesenkt." Was nicht heißt, daß das immernoch so ist. Ich weiß nicht, welches Datum hinter diesem Text steht, aber erzählt mir mal, welche (kommerziellen) Anwender noch ein solches Normal nutzen. Hab das zwar heut Vormittag mal ein paar min mitgeschrieben, konnte allerdings keine unterschiedliche Trägerabsenkung wirklich ausmachen. Als ich Okt. 2005 angefangen habe, DCF mittels PIC zu decodieren las ich schon was im netz von unterschiedlichen Trägerabsenkungen, leider hab ich die Seite nicht wiedrgfund. wejens die Verschlisselung... det wird nich jans so dolle sinn, da reicht schon die Drohung überlegt Euch mal, den Text vor 20 Jahren auf das normale DCF... Gruss Karst
Markus Kaufmann wrote: > Wenn das Verfahren so geheim ist, dann werden es halt einfach nur sehr > wenige Mitarbeiter kennen. Wie geschrieben: "security by obscurity" war gestern. >> Die Decodierung selbst wird auch wieder per "fernwartung" >> umprogrammierbar sein; alles andere wäre verrückt. Sobald also das >> reverse-engineering beendet ist, wird der nächste Level des Hackerspiels >> aktiviert ... > > Das Update ist entweder verschlüsselt oder unverschlüsselt. Gemeint war jetzt kein Firmwareupdate! Ein Seed, ein Paßwort o.ä. Das kann "unsichtbar" zwischen Nutzdaten verschwinden. > Wenn es verschlüsselt > ist, dann kann der Mitarbeiter, der die normale Verschlüsselung verrät, > ja auch gleich diese Verschlüsselung verraten Zwei-Schlüssel-System. Es ist nicht nötig, daß ein Mitarbeiter beide Schlüssel kennt. > Deswegen kann ich mir nicht vorstellen, dass es ein remote Update gibt. Wie gesagt, kein Firmwareupdate, sondern Key-Update. So würde ich es machen. Aber von mir aus kann man auch unterstellen, daß die auf den Kopf gefallen sind. Von mir aus. Ich will ja auch niemandem den Spaß verderben. Ich habe geschrieben: »Irgendwie ist es ja auch weniger Aufwand, einen PC eine Wetterwebsite parsen und die Signale selbst senden zu lassen. Also wenn das hier nicht als sportliche Herausforderung verstanden wird, den bösen Leuten, die hier ein Geschäftsmodell aufbauen wollen, mal zu zeigen, wo der Hammer hängt ... würde ich es einfach bleiben lassen!« Also, warum nicht einfach so ehrlich sein, daß der »Nutzwert« der Aktion sich darauf beschränkt, es einfach zu tun?!
hmm, aber wenn es da nen keychange geben sollte, wie bekommen es nacher eingeschaltete stationen mit?
Hallo zusammen ich hab das Ganze hier sehr interessiert mitgelesen und mir auch so meine Gedanken zum decodieren gemacht. Wenn ich es Codieren müßte würde ich die Zeit als quasi rollierenden Schlüssel mit reinnehmen. Da man ja nicht weiß wann welche Region gesendet wird, würde ich das auch nicht zu festen Zeiten tun, sondern immer wechselnd nach irgendwelchen Regeln. Von daher könnte es sein das selbst die genauen Informationen über die codierten oder auch decodoerten Daten nicht viel nutzen wenn man den Zeitpunkt nicht kennt. Die einzige Change scheint mir zu sein: Daten mit zuschreiben und gleichzeitig beim Wechsel einer Anzeige an einem gekauften Empfänger die decodierten Daten zu nötieren und vor allen Dingen die genaue Zeit dazu. Und das an mehreren Tagen um zu sehen wann die Regionsdaten denn so kommen. Alles sehr spannnend, aber nicht einfach wie ich glaube. Gruß Wolfgang
Falls die in Ihrem eigenen Dokument nicht lügen, dann wird !jede Region! immer zu einer vorbestimmten Zeit gesendet. Und das jeden Tag wieder zur gleichen Zeit, was den Vorteil hat der Empfänger weiß einfach um ... uhr ist region x und um ... +3min die nächste Region. Somit spart man sich das senden der Region in der ohnehin knapp bemessen Datenmenge, die man sicherlich somit besser verwenden kann. Damit scheidet verschlüsselung durch Zeit eigendlich aus. Zu dem Fernupdate der Schlüssel das geht nicht man könnte höchstens sagen momentan ist Schlüssel ... gefragt aber wenn ein gerät z.b. nen monat nicht empfängt und in der Zeit ändert sich der Code dann wäre das ja unbrauchbar. Ich glaub nicht das die sowas machen würden. Gruß Andreas
>Damit scheidet verschlüsselung durch Zeit eigendlich aus.
Wieso das? Du kannst ja immer noch den Key an die Zeit binden.
Damit ist lediglich ausgeschlossen, dass die Regionen irgendwann kommen.
Hi, ich lese auch immer mal wieder interessiert mit. Ein Gedanke der mir kam (vielleicht steht es auch hier drin und ich hab es überlesen)ist, woher weiss der Empfänger in welcher region er steht?!? Kann man das einstellen oder ist da ein GPS-Empfänger mit drin :-) Gruss, Steffen
Kann dem Decodier IC eigentlich egal sein. Aber das kann man dann sicher mit der Nummer, die auch in dem pdf gedruckt ist einstellen.
@stefen du hast es überlesen es kommen alle regionen du stellst lokal ein was du willst die elv uhr kann 4 (5) regionen
ehm wieso von der stunde den wehcselnden schlüssel abhängig machen geht doch auch der tag die woche das jahr
vermutlich is kein key drin, wozu denn? wegen ein paar irren, die selbst ne uhr auf avr machen?? wohl kaum. aber: datenblock hat 3 min, gibt 42 bit. daten sind soweit bekannt, 22 bit. was sind die 20 restlichen??? ich vermute: der block hat ne heftige fehlerkorrektur, da info nur 4x am tag 1x kommt, wärs sehr doof, wenn er 6 std lang zb berlin 38° anzeigt, weil ein bit falsch empfangen wurde... also : 22 b daten, 20 b crc bzw (übel) bits verwürfelt mit double reed solomon korrektur...dann sind bitfehler korrigierbar. dekodieren wird dadurch...schwierig...extra key erübrigt sich.
Philipp Sªsse wrote: > Markus Kaufmann wrote: > >> Wenn das Verfahren so geheim ist, dann werden es halt einfach nur sehr >> wenige Mitarbeiter kennen. > > Wie geschrieben: "security by obscurity" war gestern. Ach was. Wenn ich daran denke, was beim Studium alles als veraltet und "macht man heute nicht mehr" bezeichnet wurde, aber heutzutage (10 Jahre später) immer noch gemacht wird... > Wie gesagt, kein Firmwareupdate, sondern Key-Update. So würde ich es > machen. Aber von mir aus kann man auch unterstellen, daß die auf den > Kopf gefallen sind. Von mir aus. Kryptografie ist nicht selbsterklärend. Schau doch nur mal, wieviele Leute glauben, die statische Verschlüsselung beim http-auth sei sicher. Weil, das ist ja verschlüsselt. Als ob es keine replay-Attacks geben würde. Markus
Hi, hab das auch sehr interessant verfolgt ;) Ich bin auch gerade ein bisschen am Spielen mit Mikrokontrollern :D als nächstes steht bei mir ein DCF77 Wecker an und da bin ich bei Wikipedia auf die Wetterinfos gestoßen ;) da wurde ich natürlich neugierig :) Mal sehen, vllt. kann ich etwas helfen und einen stetigen Datenlogger basteln, also die Daten gehen dann vom Controller -> PC -> Internet ;) mfg Niclas
und wenn die die daten doppelt senden. z.b. das jeder block um einen datensatz verschoben noch mal gesendet wird?
servus hab den thread hier gestern bekommen und wie der zufall wollte is meine Uhr heute 5 Monate 5 tage und 10 stunden zu früh dran gewesen(zum glück hab ich mich nicht vom wecker wecken lassen da ich ne Klausur geschrieben hab). ich wollte nur sagen das es ne uhr für 20 € gibt die das wetter anzeigt bzw. vorraussagt. ob das jetzt über nen barometer oder über die 14 Bits passiert seh ich nicht aber man bekommt de hier: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=16783 mfg batman(aber psst)
lässt sich denn eine Region am Wecker einstellen? Denn wenn man der Uhr nicht sagen kann, wo sie steht, dann wird sie sich die Daten wohl eigenständig besorgen. Ist die Wettervorhersage denn nur per Bikini Girl möglich oder gibt es da auch genauere Daten, mit denen man was anfangen kann, wenn man sie irgendwie mitloggt? Gruß Martin
Die von Frederik gepostete WS empfängt keine DCF77-Wetterdaten sondern arbeitet nur über eigene Sensoren. Ein Barometer hat die auch nicht, nur Temp./Feuchte :)
Hallo! Unter http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf gibt's Infos zu dem Decoder IC. Da das Ding offenbar "active" geschaltet werden muss zum Empfangen gehe ich mal von folgendem Zusammenhang aus: gleiche Region -> tägl. gleiche Sendezeit Woher sonst sollte der Controller wissen, wann er den IC einschalten soll? > - wir benötigen viele Mitschnitte über längere Zeiträume > von mehreren Standorten Deutschlands (wegen Raumwelle/Bodenwelle usw) > > (Rolf sein formatierter Mitschnitt wäre als Mustervorlage > sehr gut geeignet, Rolf, großes Lob an Dich) > > - Aus den vielen Mittschnitten muss ein einziger lückenloser und > fehlerfreier "Referenz_Mitschnitt" erstellt werden. > > Denn ein einziger "fehlerbehafteter" Mittschnitt könnte die > Decodierung/Deciffrierung extrem erschweren. Vielleicht sollte mal jmd. eine Website aufsetzen, wo man die verschiedenen empfangenen Daten sammelt und in eine Datenbank zur Auswertung packt... Gruß, Andreas Weller
Aber noch was Anderes: Es werden ja auch "Bevölkerungswarnungen" übertragen - hat jemand evtl. davon das Codierungsschema? Dazu findet sich nämlich genauso wenig - aber warum? Denn "Warnungen an Alle" in einem undokumentierten Format auszusenden ist IMHO unsinnig... Gruß, Andreas Weller
Vorschlag: Unter http://www.distrelec.com/ishopWebFront/catalog/product.do/para/language/is/de/and/shop/is/CH/and/id/is/03/and/node/is/alagaaac/and/series/is/1.html gibt's eine Uhr für 99 CHF ≙ ~60 EUR. Bei so vielen Interessenten sammeln wir, einer bestellt die Uhr und wir gehen folgendermaßen vor: Wir betrachten den Chip in der Uhr als Black-Box. Von Interesse ist nur das Verhalten der Black Box, die über definierte Schnittstellen eine bestimmte Input- Output-Verarbeitung sicherstellt und ob sich eine Systematik finden lässt. Ziel wäre ein Reverse Engineeren des verwendeten Protokolls - nicht das Disassemblieren von evtl. vorhandenen Software. 1. Einige Zeit Daten aufzeichnen und mit der Uhrenanzeige vergleichen 2. Die serielle Kommunikation am Chip belauschen 3. Verbindung Empfänger/Chip trennen und eigene, bekannte Daten rein mit Vergleich welches Wetter angezeigt wird. 4. Chip raus bauen und eigene Daten rein -> output loggen Frage: ob wohl auch wirklich dieser obskure Decoderchip darin verbaut ist??? Gruß, Andreas Weller
@for_ro: Ich bin noch nicht dazugekommen die Daten durchzuschauen... @Andreas Weller: Im Moment ist zumindest mein Stand das es wohl nur den Dekoderchip gibt. Aber die 60EUR wäre im verglich zu dem ELV Ding für knapp 300EUR eine echte Überlegung wert... zumal der beide Zeitzeichensender Empfangen kann! Allerdings würde ich mich als Meteotime gerne dazu bereit erklären ein "Softwaremodul" in C oder VHDL zur Verfügung zu stellen wenn ich dafür von der Firma die es beziehen möchte ein NDA und eine menge Kohle bekommen würde. -hypotetisch natürlich- Mittlerweile muss ich mir aber selbst was eingestehen und schliesse ich mich bedingt der Aussage von Läubi an: Die Daten sind vermtl. zu dynamisch um damit eine evtl. korrelation auf Wetterdaten zu machen. Es gibt zu viel Variablen um die "Ausgangsdaten" mit den "Eingangsdaten" sinnvoller Weise in Verbindung zu bringen. Das der Algorythmus allerdings wärend der Laufzeit des Systems geändert wird, glaube ich nicht. Erstens ist viel zu wenig Platz im Protokoll um sowas anständig und vorallem zuverlässig zu realisieren und zwweitens, was ist mit einem System welches den Software update verpasst? 250000 Reklamationen... Ne, glaub ich nicht... Ich würde, -könnte ich mir halt Vorstellen- das noch mit einer Art LUT die periodisch umgeschalten wird zusätzlich verwurschteln. Gehen wir nur mal vom kleines AVR aus, mit 8k Flash und 8PIN's! Oh, da krieg ich viele LUT's und Algorythmen rein... Wenn ich diese LUT's umschaltbar machen, und reserviere mir dafür -sagen wir mal- 4 Bits im Protokoll, die Sende ich alle 60min dann habe ich zusätzlich zu meinem Algorythmus noch 2^4 Möglichkeiten das zu verwurschteln... und Geschwindigkeitsoptimiert muss es auch nicht sein... ufff Gruß Micha, PS: Alles natürlich rein hypotetisch, evtl. zufällige Übereinstimmungen mit dem "echten" Meteotime Protokoll sind rein zufällig!
Mit https://erlangen.ccc.de/index.php/DCF77 könntest du das Verhalten des Weckers testen ohne ihn öffnen zu müssen. Habt ihr mittlerweile ein "Testobjekt" organisiert.
@for_ro: Schreib' mal bitte ein längeres Log mit. In news:de.org.ccc - bzw. http://groups.google.de/group/de.org.ccc/browse_thread/thread/1893933cb0a93fe4/0a5c858ef0c28377 wird das Thema auch bearbeitet. Ein User dort meint Anzeichen zu haben, daß sich alles im 2 h Rhythmus wiederholt. Vielleicht könntest du ja Schaltung und Software veröffentlichen - das würde gleichzeitiges Loggen zur Fehlerkorrektur vereinfachen.
Hallo, ich hab mir zum einfacheren Experimentieren mal ein kleines Programm zur Interpretation der Bits zusammengeschustert. Entspricht der Spezifikation im oben verlinkten Dokument. Nur war mir die Verwendung von Bit 15 nachtsüber unklar. > % gcc -o bin2weather bin2weather.c > % ./bin2weather 1100011000111100101010 > --------- Generell --------- > Wetter Tag: vorwiegend bewoelkt (1100 => 3) > Wetter Nacht: Nebel (0110 => 6) > Temperatur: -1 °C (101010 => 21) > ----- Bedeutung bei Tag ----- > Schweres Wetter: Feinstaub (0011 => 12) > Niederschlagswahrscheinlichkeit: 45 % (110 => 3) > ---- Bedeutung bei Nacht ---- > Wind: Scirocco S (0011 => 12) > Windstaerke: 5-6 Bft (110 => 3) > Bit 15 unused: 0 Wie wahrscheinlich auch immer es sein mag, dass am 4.2.(?) in irgendeiner der Empfangsregionen ein Schirokko wütete. Ein paar Gedanken, wie ich zu den Bits gekommen bin: - Laut Dokument gibt es eine Übertragung am Tag und eine bei Nacht und Regionen mit täglich 2 bzw. 4 Updates. - Bit 15 schaltet tagsüber bei der Interpretation der Bits 8-11 zwischen "Unwetter" und "Relatives Vormittagswetter / Sonnenscheindauer" um. - Bit 15 ist, wie es aussieht, Nachts nutzlos? => Bedeutet, dass es vier verschiedene Datensätze bei der Übertragung gibt: Tag + Bit15 ein, Tag + Bit15 aus, Nacht + Bit15 ein, Nacht + Bit 15 aus Also müssten die Regionen mit nur einem Update tagsüber entweder auf die Unwetterwarnungen (wahrscheinlich) oder die Sonnenscheindauer/Vormittagswetter verzichten. Es gibt, wie erwähnt, 480 dreiminütige Zeitfenster pro Tag. Die 60 Regionen mit vier Updates bräuchten davon 240 Zeitfenster. Die 30 Regionen mit zwei Updates bräuchten 60 Zeitfenster. Also wären hier 180 Zeitfenster "übrig". Im Laufe von zwölf Stunden (Tag/Nacht-Periode) wären das 90. 90 ist auch die Gesamtzahl der Regionen. Na ja, muss nichts heißen. Bei der Dechiffrierung werden aus 42 Bits irgendwie 22 ... Das Bit 15 fiel mir hier ins Auge, weil man auf dieses bei der Übertragung verzichten könnte. Man wüsste sowieso, dass in einer Region mit zwei Updates pro Tag das Bit nie verändert werden dürfte und in Regionen mit vier Updates jedes zweite Mal (vielleicht auch anhand der Uhrzeit bestimmt) das Bit gesetzt sein müsste. Verzichten wir auf das Bit bleiben 21 Bit übrig. Halb so viele wie vorher, hurra. > 10100101001110 000101 0000000 0 000000 0 000100 001 01000 11100000 0 0 00:00:00 > 01000010111011 000101 1000000 1 000000 0 000100 001 01000 11100000 0 0 00:01:00 > 11100011011100 000101 0100000 1 000000 0 000100 001 01000 11100000 0 0 00:02:00 Für die 1100011000111100101010, die ich oben verwendet hab, hab ich also aus Verzweiflung einfach jedes zweite Bit aus dem neueren Log von oben genommen. Vielleicht bilden die Zwischenräume irgendwelche Paritätsbits oder geXORte Werte vorheriger, um mich mal gewaltig aus dem Fenster zu lehnen. ;) Grüße und vielleicht bringts was, pb0
Gute Idee... > % ./bin2weather 1100011000111100101010 > --------- Generell --------- > Wetter Tag: vorwiegend bewoelkt (1100 => 3) > Wetter Nacht: Nebel (0110 => 6) > Temperatur: -1 °C (101010 => 21) > ----- Bedeutung bei Tag ----- > Schweres Wetter: Feinstaub (0011 => 12) > Niederschlagswahrscheinlichkeit: 45 % (110 => 3) > ---- Bedeutung bei Nacht ---- > Wind: Scirocco S (0011 => 12) > Windstaerke: 5-6 Bft (110 => 3) > Bit 15 unused: 0 Aber scheinbar nicht ganz korrekt - oder die Daten waren nichts. IMHO sollte laut http://de.wikipedia.org/wiki/Scirocco folgendes zutreffen: -1 °C und Scirocco schließt sich aus. Feinstaub und Scirocco hingegen nicht...
> -1 °C und Scirocco schließt sich aus.
Also bei dem Bild in Wikipedia welches einen Scirocco zeigen soll liegt
vorne auf den Häuserdächern noch Schnee...
@Malte: OK - ich geb's zu: Irrtum :-) Hatte nur was von "Wüstenstrum" und Sahara gelesen... for_ro könnte jetzt nochmal einige Tage mitschreiben, so das ein Vergleich mit aktuellem Wetter möglich wäre - dann müsste gleichzeitig jemand das Wetter zu den gelisteten Städten aus der PDF Datei täglich in eine Tabelle packen. Dann kann man zumindest sehen, obs näherungsweise stimmt
Hallo. Geht es nicht eher darum aus 3*14 Bits=42 Bits (1 Protokoll für eine Region), 2 mal 22 Bits zu machen?? ( 1 Protokoll Tags, 1 Protokoll Nachts ) Die Bits 8-11 im Protokoll scheinen doch z.B. zweideutig zu sein. Im Tagesprotokoll werden dort schwere Wetter definiert bzw. durch Bit 15 gesetzt z.B. die Sonnenscheindauer. Im Nachtprotokoll wird hingegen die Windstärke definiert. Wozu werden dann aber die Bits 0-3 und 4-7 ( Wetterbeschreibung Tag/Nacht ) doppelt übertragen?? (Wenn meine Vermutung richtig wäre). Vielleicht liege ich in meiner Überlegung falsch. Oder doch nicht?!?! Grüße eisenbahndirk.
Wieso sollte man eigentlich nicht aus
3*14=42 bit genau 22 bit machen?
Eigentlich passt das doch ganz gut:
60 Regionen mit je 4 Tageswerten
und je 3 Nachtwerten
30 Regionen mit je 2 Tageswerten
(steht so in der Detail PDF Bedienungsanleitung, insbesondere dass der
vierte Nachtwert fehlt)
Das ergibt 60*(4+3)+30*2=480 Datenblöcke.
Das wiederum füllt genau einen Tag (480*3min=24h)
Die 2*4 bit für die Wetterlage wären dann zumindest für die 60 Regionen
mit Tag und Nachtdaten doppelt.
Noch eins:
Wenn man 3*14=42 bit (0..41) zusammensortiert sieht man folgendes:
bit14: immer 0
bit18: Mittelwert 0.36
bit21: immer 0
bit28: Mittelwet 0.61
Bei allen anderen ist 0 und 1
gleich häufig vertreten.
Interessant ist auch noch dass an den Positionen
15-22
16-23
...
20-27
besonders häufig die Bitkombinationen
0-1 und 1-0 auftreten
0-0 und 1-1 dagegen seltener.
Weitere Besonderheiten habe ich nicht
finden können. Insbesondere keine Periodizität.
(auch keine Wiederholung nach 2 Stunden)
Einen weiteren Hinweis gibt es noch in der
Bedienungsanleitung: offensichtlich kann es
bei Empfangsstörungen passieren, dass die Daten
für einen Tag unvollständig empfangen werden. Das spricht gegen
Interleaving und starken
Fehlerschutz, da dann - wenn überhaupt -
ein kompletter Datensatz fehlen würde.
Vermutung: Also eher einfach so etwas wie 4 bit auf 7 bit inklusive
Fehlerschutz erweitern, dann XOR mit einem Wert der aus Datum und
Uhrzeit mittels LUT bestimmt wird und 2 solche Einträge pro Minute
übertragen.
Sobald jemand ein Decoder IC hat, sollte es nicht schwer sein solche
Vermutungen durch geziellte Änderungen bei den Eingangsdaten zu prüfen.
Ohne das IC dürfte das ziemlich schwierig sein...
Ich habe mir nach P. B.'s verfahren mal 4:00:00 angeschaut... Ergebniss: ------------------------------------------------------------- 1110 1000 1110 111 000010 = 14 8 14 7 2 Wetter Tag: Schneeregen starke Niederschläge + Schweres Wetter Wetter Nacht: Leicher regen Temperatur: -20°C Bei Tag: Schweres Wetter: Radiation / 5-8 Std. Sonne; Sprung 3 Niederschlagswarschinlichkeit: 100% Bei Nacht: Windrichtung: reserviert Windstärke: >= 10 ------------------------------------------------------------- Leider eher unwarscheinlich... :( Ich versuche mir gerade über einen Freund an so einen Chip zu kommen... Mal sehen was daraus wird ;)
> Also eher einfach so etwas wie 4 bit auf 7 bit inklusive > Fehlerschutz erweitern, dann XOR mit einem Wert der aus Datum und > Uhrzeit mittels LUT bestimmt wird und 2 solche Einträge pro Minute > übertragen. Was ich mich bei Ansicht von http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf frage ist, ob der Decoder IC überhaupt die aktuelle Uhrzeit übergeben bekommt. Es wäre doch auch denkbar, daß der MC die Wetterdaten von der Uhrzeit trennt und nur diese an den Chip übergibt. Nach dem Schema in dem PDF wäre auch das zumindest denkbar. Die Frage ist, ob dann überhaupt eine LUT existiert. Gruß, Andreas Weller
Wenn ein MC die Datenvoneinander trennt, dann wäre es sogar möglich, dass er die Wetterinformationen puffert, abwartet ob die Zeit korrekt empfangen wurde und erst wenn das geschehen ist schiebt er den Puffer zum Decodier-IC. Also nicht 1 Bit / Sekunde sondern gleich alle 14 auf einmal. D.h. Reverse Engineering ist leicht (bei Vorhandensein eines Decodier-IC)
Hallo! Ich habe bin2weather von P. B. mal unter Windows (VC6) compiliert. Vielleicht animiert das ja auch Andere, die nicht die Möglichkeit haben, sich damit zu beschäftigen... @Andreas Weller: Wollte grad die 60 € Uhr aus dem Link bestellen, den du gepostet hast - die liefern aber nur nach .CH :-( Hast du da vielleicht Kontakte - oder wohnst du dort?
was ich an dem programm etwas komisch finde ist das 011 als 4 oder 1110 als 7 interpretiert werden. Ich würde 1110 als 14 interpretieren oder?
Ludwig Wagner wrote: > was ich an dem programm etwas komisch finde ist das 011 als 4 oder 1110 > als 7 interpretiert werden. Ich würde 1110 als 14 interpretieren oder? Ich auch ;)
Hallo zusammen! > was ich an dem programm etwas komisch finde ist das 011 als 4 oder 1110 > als 7 interpretiert werden. Ich würde 1110 als 14 interpretieren oder? Im Programm heißt es aber doch z.B. > unsigned char code = bit0 * 1 + bit1 * 2 + bit2 * 4 + bit3 * 8; AFAIK ist es aber doch doch genau so: 1, 2, 4, 8, 16... Hab's aber noch nicht gestartet und ausprobiert (nur den Quelltext kurz gesichtet) @dd: > Wollte grad die 60 € Uhr aus dem Link bestellen, den du gepostet hast - > die liefern aber nur nach .CH :-( > Hast du da vielleicht Kontakte - oder wohnst du dort? Nein ich wohne leider nicht dort - schön wär's ;-) Weiterhelfen: nun ja, vielleicht - ich kenn' jmd. der in .CH arbeitet... Hab auch die Lieferbarkeit nicht überprüft. War nur eine schnelle Google Suche nach Alternativen zu dem 300 EUR ELV Teil. Gruß, Andreas Weller
>> unsigned char code = bit0 * 1 + bit1 * 2 + bit2 * 4 + bit3 * 8; > >AFAIK ist es aber doch doch genau so: 1, 2, 4, 8, 16... Die Frage ist: wie rum müssen die Bits verarbeitet werden bei dem Protokoll? Um bei dem Beispiel zu bleiben: 011: a) 0*1 + 1*2 + 1*4 = 6 oder b) 0*4 + 1*2 + 1*1 = 3 1110 a) 1*1 + 1*2 + 1*4 + 0*8 = 7 oder b) 1*8 + 1*4 + 1*2 + 0*1 = 14 Bei den Zeitinformationen wird nach Schema a) codiert: http://www.gumo.de/sonstiges/zeitzeichensender/
hmmm... das müsste man sich mal etwas genauer anschaun, das könnte durchaus sinn machen
Hy Ich finde das auch gerage interessant. mal eine frage: laut http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf ist das empfänger-modul ein UE6015. http://www.hkw-elektronik.de/deutsch/produkte/bauteile.php ist das ein standart modul wie das von reichelt/conrad? weil da ja noch signale zum modul gehen. pon ist klar, nur mit dem hld kann ich garnichts anfangen. mfg
Laut Datenblatt: HLD AGC hold input CMOS compatible, digital input; LOW active; by default set to HIGH via internal pull-up resistor. AGC hold mode: HLD = HIGH sets normal function, HLD = LOW (VHLD = GND) holds for a short time the AGC voltage. This can be used to prevent the AGC from peak voltages, created by e.g. a stepper motor. Once HLD is used then it is recommended to keep HLD activated (HLD=LOW) as long as the interference can be detected on the cristal filter. Typical values are 100…200ms. Auf gut Deutsch: brauchen wir nicht.
http://www.elv-downloads.de/newsletter/indexnewsletter2007_02c.htm Die nächsten, die was vom Kuchen abhaben wollen, ohne die ersten 14Sekunden gekauft zu haben. Konkurenz belebt eben das Geschäft.
@Axel > Die nächsten, die was vom Kuchen abhaben wollen, ohne die ersten > 14Sekunden ... Aber in der Beschreibung steht etwas von einem Stellitenempfang, nichts von DCF, oder?
JAHaa
>ohne die ersten 14Sekunden gekauft zu haben.
Wollte ich damit sagen.
Ob das stimmt?
Stimmt, die übertragen per Staellit. Axel schreibt ja auch "ohne die ersten 14 Sekunden gekauft zu haben". Wäre auch interessant zu wissen, ob man an diese Wetterdaten einfacher rankommt.
Hallo! Ich denke es funktioniert auf ähnlicher Basis wie die alten Pagernetze. Da stehen die schönen Sat gesteuerten Funkstationen in der Gegend rum und keiner benutzt mehr die Pager. Werd das Morgen mal überprüfen... Die Dinger senden irgendwo im 70 cm Band (ca. 460 Mhz). Die Codierung nannte sich Pocsag. Man konnte es immer mittels Soundkarte decodieren... IMHO wäre eine Decodierung aber aufwändiger als bei DCF77. Gruß, Andreas Weller
Hab mal nen bischen gegoogled: Hier ein paar Links: Protokoll / Frequenzen etc. http://de.wikipedia.org/wiki/POCSAG Skyper etc. : http://de.wikipedia.org/wiki/Skyper_%28Pager%29 vielleicht hilft das hier auch weiter http://funkmeldesystem.de/ Ach und übrigens: Die von e skyper und wetter.de wollen auch was vom Kuchen. Guckst du: http://www.emessage.de/de/skyper/index.html
das IC zur deschifrierung hat nur 8 pins, ein serielles daten-in und ein serielles daten-out. Also wenn wir jetzt noch jemanden finden der beide seriellen BUSe belauschen kann, dann erstmal die seriellen in-daten mit den 14 bits des DCF77 vergleicht und dann mal eine weile die in und out daten logt dann müsste man das doch entschlüsseln können oder? Außerdem kann man dann noch raus finden wie das mit den regionen ist (eine region einstellen und schauen wann der IC aktiviert wird, falls das wirklich so läuft). Und wenn das nicht hilft einfach mal den dekoder IC nehmen und unter dem Mikroskop analysieren ;)
a) > die seriellen in-daten mit den 14 bits des DCF77 vergleicht b) > unter dem Mikroskop analysieren zu a) Ich denke, Du wirst KEINEN Unterschied erkennen können. Sind die ersten 14 Sekundenimpulse vom DCF nicht die seriellen In- Daten vom Chip? zu b) klar! Den Chip zu "Finger" nach Oldenburg schicken und via PD500 oder SRS326 Röntgen lassen ;-))) Viele Grüße, sehr interessant AxelR. [Edit] Zitat wird nicht grün, komisch
<OT> Zitat wird nicht grün, weil das '>' nicht das erste Zeichen in der Zeile ist. </OT> Gruss Jadeclaw.
Einen POCSAG-Decoder für die Soundkarte gibts hier: http://www.dsp4swls.de/dsp/pocsag.html den hab ich selbst schon mit Amateurfunk-Funkruf auf 439,985 MHz ausprobiert
Christoph Kessler (db1uq) wrote:
> Einen POCSAG-Decoder für die Soundkarte gibts hier:
Danke für die Info.
Gruss
Jadeclaw.
geht bei euch grade DCF77, bei mir seit ca 20 min nicht mehr, bekomm hier nur 1 ser rein, außer der synchonisation. Dachte ja schon es liegt am empfänger, aber mein Wecker von TCM hat plötzlich auch keinen Empfang mehr. Kann also bitte mal jemand bestätigen, dass DCF77 noch online ist. Danke, Michi
Hallo! Hab' mich ml ein wenig mit dem Pocsag-Kram beschäftigt. Also bei den verwendeten 1200 baud ist es schon einfacher die Wetterdaten zu verstecken und/oder stärkere Kryptoverfahren zu verwenden. Ich denke es ist bei DCF77 einfacher die "relevanten" Daten zu finden: wir wissen, daß sie in den ersten 14 Bit stecken müssen. Bei Pocsag ist es schon aufwändiger... Wer sich trotzdem mal ein Bild machen möchte: unter http://www.uploadwiz.com/WIZ1008554360 habe ich einen Mitschnitt bereitgestell der Frequenz 466.23 MHz - dürfte e*messenger sein.
Also im Amateurfunkgesetz stand mal - oder staht noch ...werden versehentlich solche Sendungen empfangen, so darf weder deren Inhalt noch die Tatsache des Empfangs jemandem mitgeteilt werden... oder so ähnlich. POCSAG auf Amateurfunk ist dagegen frei für alle, die Frequenz hatte ich genannt.
So einfach wie ihr Euch das mit dem Loggen vorstellt ist das nicht: Aus dem Handbuch: … Die vom Mete-ON 3 dargestellten Wettervorhersagen werden zwischen 22:00 und 4:00 morgens empfangen (UTC Zeit, in Zentraleuropa ist das im Winter +1 Stunde und im Sommer +2 Stunden). Um nach der Inbetriebnahme erste Vorhersagen ablesen zu können, müssen Sie also eine Nacht abwarten! Die neuen Tagesvorhersagen stehen ab 3:00 morgens zur Verfügung. Die neuen Nachtvorhersagen stehen ab 6:00 morgens zur Verfügung. …. Zusätzlich geht das ganze Gerät in den PowerSave-Mode, d.h. das IC ist im überwiegende Teil der Zeit deaktiv. Hier kommen einfach zu wenige Daten zusammen, dass eine Dekodierung möglich wird. Aus meiner Sicht muss man das IC auslöten und mit Daten füttern.
Andreas, abo ist nicht mehr nötig. Du kannst auf den Link "Email-Benachrichtigung aktivieren" klicken, das hat denselben Effekt. mfg, Stefan.
Moin! Albatros wrote: > Hier kommen einfach zu wenige Daten zusammen, dass eine Dekodierung > möglich wird. Aus meiner Sicht muss man das IC auslöten und mit Daten > füttern. Ist denn schon klar, daß dieses ominöse IC in den Geräten überhaupt dediziert eingebaut ist oder ob das alles irgendwie komplett integriert ist? Muß mal meine schweizer Connections spielen lassen und so ein Gerätchen ordern. In Deutschland kosten die Dinger nämlich leider knapp 100 EUR plus Versand. Gruß, Didi
>In Deutschland kosten die Dinger nämlich leider knapp 100 EUR plus Versand
Welche Dinger? Eine Uhr, die die Wetterdaten auswertet oder dieses
Dekodier-IC?
100 € für ein IC ist doch schon ein bisschen heftig.
-> Um welche Uhr geht es?
Moin! wulf wrote: >>In Deutschland kosten die Dinger nämlich leider knapp 100 EUR plus Versand > Welche Dinger? Eine Uhr, die die Wetterdaten auswertet oder dieses > Dekodier-IC? > 100 € für ein IC ist doch schon ein bisschen heftig. > -> Um welche Uhr geht es? Sorry, hab mich etwas unklar ausgedrückt ... die "Mete-ON 3"-Uhr meinte ich: 99 sFr in der Schweiz und 99 EUR bei uns in Deutschland. Frage ist eben, ob da auch wirklich der Chip drinsteckt oder ob alles auf einem IC integriert ist inklusive der Uhren-Funktion. Wenn alles klappt, habe ich wohl Ende nächster oder Anfang übernächster Woche so ein Gerät hier und wenn man es zerstörungsfrei zerlegen kann, mache ich mal ein paar Bilder von der Platine. Gruß, Didi
Auf der Hauptplatine ist ein SO-8 mit einer kryptischen Nummer. Das DCF77-Orgnialsignal kann von der Empfängerplatine bezogen werden (Achtung: ist nur ca. 3 min aktiv und enthält ein zusätzliches Logiksignal). Viel Spaß beim Dekodieren.
Albatros wrote: > Auf der Hauptplatine ist ein SO-8 mit einer kryptischen Nummer. > Das DCF77-Orgnialsignal kann von der Empfängerplatine bezogen werden Hättest Du ein Bild von der Schaltung ?
Moin zusammen! Bernhard Schulz wrote: > Albatros wrote: >> Auf der Hauptplatine ist ein SO-8 mit einer kryptischen Nummer. >> Das DCF77-Orgnialsignal kann von der Empfängerplatine bezogen werden > Hättest Du ein Bild von der Schaltung ? Das wollte ich auch gerade fragen ;-) SO-8 korrespondiert zumindest mal mit dieser Beschreibung: http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf Vor allem wäre interessant, wie einfach sich das Gehäuse der Uhr öffnen läßt und ob das ohne sichtbare Beschädigungen vonstatten geht (hoffentlich geschraubt und nicht geclipst!). Schon mal danke an Albatros für entsprechende Infos! Gruß, Didi
Moin! John-eric Kamps wrote: > laut > http://www.hkw-elektronik.de/pdf/DB%20DC-IC-deut.pdf > ist das empfänger-modul ein UE6015. > http://www.hkw-elektronik.de/deutsch/produkte/bauteile.php > ist das ein standart modul wie das von reichelt/conrad? Hier gibts das Datenblatt: http://www.hkw-elektronik.de/pdfenglisch/UE6015%20-%20DE%20V4.1.pdf Demnach ist es tatsächlich eine Art Standardmodul - nur ein etwas leistungsfähigerer Empfängerchip mit einem Haufen Optionen wie z.B. umschaltbare Antenneneingänge, wählbare Ausgangs-Polarität (H-L-H oder L-H-L), usw. Außerdem ein klassischer ASK-(Amplitude Shift Keying)-Empfänger, also keine Auswertung der Phasenmodulation. Das sollte ggf. die Auswertung der 14 Bit durchaus vereinfachen ;-) Grundsätzlich dürfte kein Weg daran vorbeiführen, Ein- und Ausgangssignal des "Dechiffrier"-ICs direkt zu vergleichen und daraus seine Schlüsse zu ziehen. Sonst wird man wohl kaum weiterkommen. Gruß, Didi
Moin! Albatros wrote: > Die vom Mete-ON 3 dargestellten Wettervorhersagen werden zwischen 22:00 > und 4:00 morgens empfangen (UTC Zeit, in Zentraleuropa ist das im Winter > +1 Stunde und im Sommer +2 Stunden). Um nach der Inbetriebnahme erste > Vorhersagen ablesen zu können, müssen Sie also eine Nacht abwarten! In diesem Dokument ist alles noch etwas detaillierter nachlesbar: http://www.hkw-elektronik.de/pdf/DB%20W-Protokoll-V%201.pdf "Die Wetterdaten werden über 24 Stunden in jeder Minute ergänzend zur Uhrzeit und dem Datum von Sekunde 1 bis Sekunde 14 übertragen. Ein Wetterprotokoll für eine Wetterregion und eine Vorhersage wird über den Verlauf von 3 Minuten gesendet. Diese Wetterdaten sind über die Sendezeit einer festen Region zugeordnet. Die Sendezeitpunkte für die Wetterregionen entnehmen Sie bitte dem Handbuch aus dem Lizenzvertrag. Die übertragenen Daten können nur mit der über den Lizenzvertrag beschaffbaren Dechiffriervarianten geprüft und für die Auswertung bzw. Anzeige nutzbar gemacht werden. Die Dechiffriereinheit erzeugt die Meteotime-Wetterdaten von Bit 0 - Bit 21." Und weiter: "Die Bitbeschreibungen in der nachfolgenden Zusammenstellung der Wetterdaten basieren auf dem aus 3 Minuten gebildeten Datenwort. Die Bit-Numerierung der Wetterbits bezieht sich nicht auf die Bit-Numerierung in der Rosette des DCF-Protokolls." Das bedeutet also: - während 3 Minuten werden 3x14 Bit = 42 Bit übertragen - aus diesen 42 Bit werden in der "Dechiffriereinheit" 22 Bit erzeugt - dies sind dann die Wetterdaten für eine feste Region - welche Daten für welche Region kann man nur dem Lizenzvertrag entnehmen - lt. Handbuch wird zwischen 22:00 und 4:00 UTC gesendet, hier steht 24h Das sind doch schon mal ein paar Anhaltspunkte, auf denen man aufbauen können sollte ... Meine METE-ON 3 geht voraussichtlich Montag in die Post ;-) Gruß, Didi
42 bei 180 und einem intervall von 86400 zu entschlüsseln ist nicht schnell vollbracht mit rechnern unter 1KHz! Da hat schon 1962 eine Maschine... Die simple(Intervall) Änderung zu begreifen wurde schon 1938 verstanden... Noch ein wenig AVR -- SAM und es klappt auch mit dem nachfolgen. Für die Kosten der Schaltung kann ich auch sicherlich ein Modul kaufen! Und habe dann eine Standbyschaltung unter 50uA! Nicht alles was glänzt ist Gold, aber es zu erringen lohnt sich, es sei denn man ist ein studierter Student der keine Aufgaben findet. Oder ein Ingenieur dem bei Harz4 langweilig wird und ausser Studieren nichts gelernt hat! Gruss M. Viele Grüße Michael
Moin Michael, mir scheint, Du hast da was falsch verstanden ;-) Es geht nicht um Aufwand/Kosten-Nutzen-Verhältnisse, sondern einfach um den sportlichen Ehrgeiz, das Verfahren zu decodieren ... Klar kann man sich für den Aufwand ein Modul fertig kaufen, aber das ist doch langweilig. Außerdem kann man da durchaus noch was lernen dabei. Gruß, Didi
Wenn es darum geht das man sich alles biliger fertig kaufen könnte dann gäbe es hier kaum ein projekt. Hier geht es darum Spaß am basteln zu haben und besonders darum das man sich alles selbst anpassen kann wie man will. Und man kann stolz sein wenn man fertig ist! ;)
Definition eines Hobbys: Mit möglichst maximalen Aufwand den geringsten Nutzen erzielen ;)
Das Gehäuse ist mit 6 Schrauben verschlossen. Lässt sich ohne Garantieverschleiß öffnen. Die Drähte an das IC sind Messleitungen.
> Die Drähte an das IC sind Messleitungen.
An welchen Pin des IC liegen welche Signale an?
Moin zusammen! Weiter oben hatten wir ja schon die Info zur ELV-Wetterstation. Jetzt ist es offiziell bei teltarif.de gemeldet worden: http://www.teltarif.de/arch/2007/kw10/s25164.html "Wohnzimmer-Wetterstation wird per Paging-Signal aktualisiert" Gruß, Didi
> Die Drähte an das IC sind Messleitungen.
Und - was hast du gemessen?
Ich schaue gerade den neuen elv-Sommerkatalog 2007 durch, da sind die beiden DFC77-Geräte Mete-on 1 und 3 sowie das Pager-Gerät (die Bezeichung WD 4000 sehe ich allerdings nirgends) drin. Hab mal gegoogled, hier unterhalten sich auch einige zum Thema "elv WD 4000" : http://www.wetterstationen.info/phpBB/viewtopic.php?t=10424&start=45&sid=b042423f83f049c3a4548d1f8480322c Zitat: "Wer noch den alten Scall-Dienst kennt: die Funkzonen sind mit denen von Scall identisch, habe gerade die Karten miteinander verglichen. Sowohl Zoneneinteilung als auch Nummerierung stimmen exakt überein." zu Scall gibts noch die Karte: http://www.wetterstationen.info/phpBB/download.php?id=3517&sid=e3c666ffdfe18d829e3d2f0c552c3249
Die Frequenzen liegen alle im 466MHz-Bereich: http://www.trust-us.ch/ds/49/006_Scall.html : "Zur Zeit (1994) ist Scall nur mit speziellen Scall-Empfaengern, die auf den Frequenzen f3(466,230Mhz) laufen, moeglich. Ab 1.3.1995 soll es moeglich sein, auch andere Cityruf-Empfaenger auf den Frequenzen f1(465,970) und f2(466,075) auf Scall umzubuchen." http://pcphy4.physik.uni-regensburg.de/pager/grund.html : "Cityruf 465.97MHz Scall 466.230MHz Skyper 465.97MHz Telmi 448.425MHz Quix 448.475MHz Euromessage 466.075MHz Scall ist als Tarif eingestellt, die Frequenz aber noch im Gebrauch durch die e*message GmbH, die auch Skyper und Cityruf von der deutschen Telekom übernommen hat (Situation 11/2003)." Demnach findet die Übertragung der Wetterdaten auf 466,230 MHz statt.
Läubi Mail@laeubi.de wrote: > Andreas Schwarz wrote: >> Ich könnte mir schon vorstellen dass das nur eine halbherzige >> Bitverwürfelung ist, mit dem Ziel eine unerlaubte Verwendung illegal zu >> machen. Wenn es sich aber um eine richtige Verschlüsselung handelt, z.B. >> vernünftig implementiertes AES, dann sind die Erfolgschancen exakt 0. > > Warum so kompliziert? Ein einfacher Blockchiffre im CBC Mode und alle > Träume über dechiffrierung sind eh nahezu dahin. > > http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode > Ich denke nicht, dass eine einfache CBC zur Anwendung kommen kann. Da nicht alle verbundenen Systeme ( Sender und Uhren) mit einander verbunden sind und gleiche Startbedingungen haben. Eine sehr hilfreiche Information wäre z.B. zu wissen, wie schnell eine frisch eingeschaltete Uhr die Wetterinformationen bereit stellt. Daraus lässt sich der 'Aufstart-Zeitpunkt' der Verschlüsselung identifizieren. Eine echte CBC würde nämlich erfordern, dass alle Chips immer mit Energie versorgt sind um den Key-Change mit zu verfolgen. Ich tippe daher auf eine software technisch recht simple, aber sicherheitstechnisch sehr effektive AES mit bekanntem, aber geheimen Key auf beiden Seiten. Um ehrlich zu ein, genau das habe ich bei anderen Dingen auch so gemacht. Was ich aber noch loswerden muss ist mein wirklicher Unmut: 1. ...dass eine Institution, die durch meine Steuergelder finanziert wird, Knowhow aus dem Ausland einkauft um daraus ein profitables Geschäft zu machen, dessen Gewinne wieder im Ausland versickern. 2. ... dass eine Einrichtung, die eine öffentliche Dienstleistung zur Verfügung stellt nun mit verdongelten Systemen kombiniert wird, die sich der Kontrolle der Öffentlichkeit entziehen. Wenn Ihr das Protokoll knacken wollt, dann habt ihr meine volle Unterstützung, da es in meinen Augen eine Verletzung des Auftrages seitens der PTB, eine logistische / finanzielle Niederlage für die deutsche Industrie, und ein Schlag ins Gesicht aller deutscher Entwickler ist. Dafür gehört die PTB ebenso abgestraft, wie die meteotime. Im übrigen bin ich dafür, dass die PTB sich nun zu einem großen Teil aus den Lizenzen finanzieren sollte und die Beiträge aus Steuergeldern zurück gefahren werden müssen, da sie sich von ihrem Non-Profit Forschungsauftrag zurück gezogen hat. Ich habe momentan wenig Zeit wegen Hausumbau, werde aber mal das ganze DCF-Material am Wochenende einsammeln und nächste Woche zu einem funktionsfähigen Empfänger zusammen bauen. Damit werde ich dann einen Langzeit-Log laufen lassen. Da mein PC eh immer an ist, kann das Modul das gleich in einen Logfile laufen lassen. Gruß, Ulrich
Hey! Kann mir jemand sagen ob und wie ich die Wetterdaten auf der 466,230 MHz entschlüsseln kann und ist es überhaupt erlaubt diese einfach zu verwenden?
Weiter oben habe ich schon den Link zum Soundkarten-Decoderprogramm genannt. Ob die Daten verschlüsselt sind weiß ich nicht, vermutlich ja. Empfang mit der ELV-Wetterstation ist selbstverständlich gestattet, selbstgebautes vermutlich nicht. Nochmal der Link: http://www.dsp4swls.de/dsp/pocsag.html
Ulrich P. wrote: >> Warum so kompliziert? Ein einfacher Blockchiffre im CBC Mode und alle >> Träume über dechiffrierung sind eh nahezu dahin. >> >> http://de.wikipedia.org/wiki/Cipher_Block_Chaining_Mode >> > > Ich denke nicht, dass eine einfache CBC zur Anwendung kommen kann. Da > nicht alle verbundenen Systeme ( Sender und Uhren) mit einander > verbunden sind und gleiche Startbedingungen haben. Eine sehr hilfreiche > Information wäre z.B. zu wissen, wie schnell eine frisch eingeschaltete > Uhr die Wetterinformationen bereit stellt. Daraus lässt sich der > 'Aufstart-Zeitpunkt' der Verschlüsselung identifizieren. Eine echte CBC > würde nämlich erfordern, dass alle Chips immer mit Energie versorgt sind > um den Key-Change mit zu verfolgen. Muß doch garnicht... Möglichkeit a) Fester Startwert --> unsicher, unflexibel Möglichkeit b) Zufälliger Startwert --> muß mitübertragen werden (bei 128bit verschl. immerhin 16byte...), guter Zufallsgenerator nötig, Probleme bei Übertragungsfehlern Möglichkeit c) Zeit ist der Startwert --> Zeit wird eh übertragen und ist allen Empfängern "bekannt" Möglichkeit c) ist einfach, schnell, effizent und bietet ein höchstmaß an Sicherheit für diesen Einsatzzweck.
Moin zusammen! Was haltet Ihr davon, wenn wir in diesem Thread mit dem DCF77-Wetter weitermachen und einen neuen für die Pager-Netz-gebundenen Wetterstationen aufmachen? Ich beziehe mich da durchaus mit ein, da ich hier auch schon über die Pager-Geschichte was geschrieben habe. Ansonsten wird die Übersichtlichkeit in diesem Thread massiv leiden. Meine Uhr (METE-ON 3) ist inzwischen auch eingetroffen - leider hatte ich noch keine Zeit, mich mit einem Datenlogger zu bewaffnen und das Tracen anzufangen. In diesem Zusammenhang: die Pin-Belegung des Dechiffrier-IC ist immer noch nicht klar, oder habe ich das überlesen? Danke und Gruß, Didi
Läubi Mail@laeubi.de wrote: > Möglichkeit c) Zeit ist der Startwert --> Zeit wird eh übertragen und > ist allen Empfängern "bekannt" > > Möglichkeit c) ist einfach, schnell, effizent und bietet ein höchstmaß > an Sicherheit für diesen Einsatzzweck. Hmm... Also einen CBC aus einem öffentlichen Schlüssel... der in Form der Uhrzeit mitgesendet wird... Ich weiß nicht. Das klingt nach einem billigen XOR... Naja, alles Raterei. Loggen was das Zeug hält und dann mal mit Phantasie ans Werk. Was mir auffiel, war, dass die ELV Uhr 24/7 auf Empfang ist. Etwas, dass mir ungewöhnlich erscheint, selbst, wenn diese Uhr mehrere (5) Wetter Informationen empfangen kann. Es hätte ja gereicht dann 5 mal am Tag zur passenden Zeit den Empfänger zu aktivieren. Ein weiterer Umstand, der gegen das reine Zeitscheiben basierte Versenden von Wetterinformationen spricht, ist die Tatsache, dass Unwetter-Warnungen versendet werden können. Da sich diese Wetterlagen auch gerne kurzfristig bilden, muss es möglich sein für beliebige Gebiete eine Sondermeldung zwischen schieben zu können, sonst wäre das Feature sinnlos. Damit sind wir aber zurück beim Datenformat, dass m.E. auch eine Information über die gerade gesendete Wetterzone beinhalten müsste. Es wäre damit möglich Sondermeldungen einzufügen, ohne die 3-Minuten regel zu verletzen. Ein Empfänger, der stromsparend die Sondermeldungen ignoriert, schaltet zur korrekten Zeit ein, sieht anhand der Zonenkodierung, dass es vorher Sondermeldungen kamen und seine Zone im Verzug ist. Dann wartet er halt ein paar Minuten länger, bis seine Info kommt und schaltet dann ab. Andersherum, es gibt noch freie Bits in der Tagesscheibe. Wer hat denn gesagt, dass diese Lückenlos ist. Warum nicht alle x Minuten eine Sondermeldung zulassen? Das würde es auch erklären, warum die Uhr 24/7 auf Empfang ist. Eine Bitte an unsere Heuristiker, die hier schon Software gebastelt haben um das Protokoll statistisch auszuwerten: Kann einer von Euch mal den Bitstrom als Differenz von der Zeit zerlegen? M.E. müsste es gerade in den letzten Tagen bei einem Großteil der Wetterinformationen einen leeren Datenblock geben, da keine schweren Wetter zu verzeichnen waren. Dieser Datenblock müsste sich hoffentlich mehrfach Täglich wiederholen. Mal ehrlich, wenn die angepriesenen Warnungen von schwerem Wetter nicht kurzfristig übertragen werden können, dann ist das ganze Protokoll Mist und es ist nicht besser geeignet als jede Baumarkt-Wetterstation. Viel Aufwand um wenig Nutzen. Wer will schon erfahren, dass das, worauf er gestern mit dem Auto ins schleudern kam, Blitzeis war... Also muss dafür Platz rund um die Uhr sein, sonst ist das wieder ein teures Produkt, dass die Menschheit nicht braucht. Ich denke auch, dass wir im Sommer mehr Erfolg mit dem Dekodieren haben werden, da dann die allgemeine Wetterlage stabiler ist. Momentan ist immer irgendwo Wind und damit eine mehr oder weniger schnelle Änderung der Wetterlage möglich. Die Wahrscheinlichkeit vergleichbare Wetterinformationen in einem Datenstrom mit unbekanntem Anfangspunkt zu erhalten, ist aktuell sehr gering. Gruß, Ulrich
Man müsste mal wissen, was in den Decoderchip reingeschrieben wird. Wenn da nur das reingeht, was in den 14 Bits drinne war, dann wird definitiv nix mit der Uhrzeit initialisiert/verschlüsselt. Wenn man dann schon dabei ist, kann man ja auch mal versuchen, das IC mehrfach mit der selben Datenfolge zu befüttern. Sollte dabei immer das Gleiche rauskommen ist es sicher kein CBC o.ä.. Gruß Andreas
Also mein Budget ist momentan arg strapaziert, daher ist das nix mit ner Uhr von 90..270€ nur zum zerlegen. Aber wenn jemand in der Nähe zu GI-WZ-WBG wohnt, das Teil hat, aber jemandem braucht, der mit einem schweren Agilent Mixedmode Scope umgehen kann und selbiges auch gleich mitbringt, dann meldet Euch. Dann ist das mit der Pinbelegung und den Signalen schnell gegessen. Gruß, Ulrich
Pinbelegung steht im hier etliche Male verlinkten Datenblatt zum Decoder. Ich würde eher sagen, dass da ein AVR mit dem SPI im Slavemode völlig ausreicht (na gut, 2 AVRs). Die Datenrate dürfte auch nicht so arg hoch sein, so dass man da eventuell auch mit Bitbaging aufm LPT (mit Levelshiftern natürlich) mitlesen kann. Wenn ich es recht in Erinnerung habe, ist doch auch schon irgendeine solche Uhr fachmännisch "bedrahtet" worden. Wie sieht es denn da aus? MfG Andreas
> muss es möglich sein für beliebige >Gebiete eine Sondermeldung zwischen schieben zu können, sonst wäre das >Feature sinnlos. Woher weiss die Uhr wo sie gerade ist? Hamburg? Heidelberg? München?
Andreas Lang wrote: > Pinbelegung steht im hier etliche Male verlinkten Datenblatt zum > Decoder. ... Also die Datenblätter, die hier verlinkt waren, haben ein hübsches Bildchen von einem 8-Pin SOIC, aber da stehen nur Nummern auf den Pinnen und ein hübsch buntes Blockschaltbild. Aber keine Zuordnung der Pinne zu den im Blockschaltbild genannten Signalen. DB 20DC-IC-deut.pdf heißt das Doc dazu. Im Datenblatt wird weiterhin auf Signale an X5 und M1 bezug genommen, was aber mit den Ziffern 1..8 am IC nichts gemein hat. Das witzige an dem Datenblatt ist, dass sie zu jedem Lizenzvertrag einen Manuel liefern... Der arme Kerl. Gruß, Ulrich
hmmm...blubb stimmt auffallend. Der Bus ist wohl irgendein SPI-Verschnitt. Saftung sollte einfach zu finden sein, für den Rest gibt es auch nur wenige möglichkeiten. Wenn man erst mal den Clock gefunden hat, sollte der Rest simpel sein. Ich nehme mal an, dass der Master zuerst den chiffrierten Kram reinblubbert und der Chip dann irgendwann mit dem Statuspin mitteilt, dass er fertig ist. Dann wird vermutlich noch einmal ein Transfer gestartet und der Master liest den Kram zurück.
@No.1: Den Standort wird der Besitzer wohl selbst einstellen müssen.
Moin!
Dirk W. wrote:
> @No.1: Den Standort wird der Besitzer wohl selbst einstellen müssen.
Den Standort stellt der Besitzer selbst ein. Allerdings werden wohl
Daten für alle Regionen empfangen und die Standort-Einstellung wirkt
sich nur auf die Anzeige aus.
Leider habe ich keinen (bevorzugt mehrkanaligen) Datenlogger verfügbar,
sonst könnte ich mich da mal dranmachen.
Gruß, Didi
Da bin ich nochmal ... Habe gerade gesehen, daß in dem METE-ON 3 eine Art Programmierschnittstelle vorgesehen ist, die über einen kleinen Deckel auf der Unterseite des Gerätes auch von außen zugänglich ist. Habe mal zwei Bilder davon gemacht: http://diet.gmxhome.de/pics/METE-ON3-Stecker1.jpg http://diet.gmxhome.de/pics/METE-ON3-Stecker2.jpg Die Pin-Bezeichnungen lauten VPP, DATA, GND, MODE und VDD. Kann sein, daß man da drüber die Firmware updaten kann. Außerdem noch ein Bild von der Platine samt Decoder-Chip (hinter dem Elko): http://diet.gmxhome.de/pics/METE-ON3-Platine.jpg und eins vom DCF77-Empfänger: http://diet.gmxhome.de/pics/METE-ON3-DCF77.jpg Gruß, Didi PS: Bilder übrigens sind mit einem Sony Ericsson P990i Smartphone im Makro-Modus aufgenommen und von 1600x1200 auf 640x480 runtergerechnet. Gut - die Schärfe (bzw. den Autofocus-Punkt) kann man noch optimieren, aber ich bin so schon ganz begeistert ;-)
Schicke Fotos! Kannst Du nicht mal versuchen, ein Foto möglichst senkrecht auf den Decoder Chip zu machen. Aus dem Layout sollte sich doch wenigstens die Pinbelegung teilweise ermitteln lassen. Nett ist doch, dass sie zur Ankopplung von Debuggern und Logicanalyzern direkt Messpunkte vorgesehen haben. Das erleichtert die Arbeit doch ungemein :) Gruß, Ulrich
Hallo Ulrich, muß ich mal ausprobieren ein besseres Foto zu machen. Ist etwas schwierig wegen der Kabel, die recht kurz sind. Bei Gelegenheit probier ichs mal und bei Erfolg setze ich das Foto hier rein. Gruß, Didi
Wetterstationen liefern beim Auslesen keine der APRS-Protokoll-Spezifikation für Wettermeldungen entprechenden Datenstrings. Insofern ist für die Darstellung in gängigen APRS-Anwendungen (z.B. UI-View) oder auf dem TH-D7, TM-D700 eine Umwandlung der Daten erforderlich. Im stationären Betrieb kann eine entsprechende Umwandlung der Daten durch das Programm "UI-Weather" erfolgen. Die hier fragliche Wetterstation WS-2300 wird unterstützt. UI-Weather liest die Datei "curdat.lst" des beigefügten Wetterprogrammes "HeavyWeather" aus und generiert eine Datei "wx.txt". Hier findet sich der APRS-WX-String. UI-View32 greift wiederum auf diese Datei zu und versendet entsprechende Wetterbaken. Problematisch ist der Betrieb hingegen, wenn ein Netzanschluss zur Versorgung eines Notebooks nicht verfügbar ist. Hier greifen komerzielle Hardwarelösungen wie "WX-Trak" von Byonics. Jedoch sind die unterstützten Wetterstationen in Deutschland schwerlich zu erwerben. Ziel ist es mithin, unter Verwendung der Wetterstation WS-2300 und eines TNC, einen APRS -konformen Wetterstring zu erzeugen und als APRS-Bake auszusenden. Der Teil-String soll im Bakentext wie folgt aussehen: _202/000g000t071r000p000b10180h46 Im Beispiel entspricht "b10180" einem Luftruck von 1018.0 hpa. Zusätzlich sollen außerdem im "Statusfeld" weitere telemtrische Daten (z.B. Spannung, Helligkeit, etc.) übertragen werden. Lösung: Zur Lösung wurde von Joachim (DF4IAN) zunächst eine Platine für die Hardware-Kopplung des Einganges an die Wetterstation WS-2300 erstellt. Vermittels der WS.CON-Software (geschrieben mit Microchip MPLAB C18-Compiler in C) werden die über die erste serielle Schnittstelle bei der WS-2300 abgefragten Daten im integirierten PIC-18 F 252 verarbeitet. Der PIC-18 F 252 beinhaltet 32kByte Flash-ROM, 1.5kByte RAM, 256Byte EEPROM, AD-Wandler, Pulsweitenmodulator, serielle Schnittstellen, sowie mehrere Zeitgeber. Der Software-Kern für die Abfrage der Wetterdaten der WS-2300 besteht dabei in aus einer stark modifizerten Version von Kenneth Lavrsen’s (OZ1IDD) open2300-Software. Die Software von Joachim unterstützt in der aktuellen Version aber zudem eine Analogwert-Aufbereitung mehrerer Kanäle, d.h es ist neben der eigentlichen Konversion der Wetterdaten auch ein Übertragen von Analogwerten wie z.B. U, I, Einstrahlleistung/m2, sowie uv-Strahlung möglich. Am Ausgang werden die softwaremäßig im APRS-Format aufbereiteten Datenstrings, welche mit einem Zeitstempel der DCF-77 Uhr der WS-2300versehen sind, über die zweite serielle Schnittstelle an den Aux-Eingang des TNC 2 (mit UI-Digi 1.9 b3 Firmware) übergeben. Die Form der APRS-Protokoll kompatiblen Strings und die Formatierung weiterer telemetrischer Sensor-Daten im Statusfeld des APRS-Strings, läßt sich im Parametriermodus flexibel über eine seriell verbundene Eingabeeinheit gestalten. In der aktuellen Version versteht Joachim das Modul ws.con, über die ursprüngliche Aufgabenstellung hinaus, als flexiblen Technologieträger, bei dem die unterschiedlichsten Eingangsdaten aufbereitet und in ein beliebiges Übertragungsformat umgesetzt werden können.
Hallo Don Schön und gratuliere! Aber was genau hat dein Beitrag mit diesem Thread zu tun? LG Michael
Hallo, ich habe was gefunden was vielleicht auch nützlich ist: bei Conrad gibt es jetzt eine Uhr, die auch für 50 Regionen Wettervorhersagen macht, allerdings soll die eine "satellitengestützte Funkwetterstation" sein. Ist da vielleicht auch so eine die über DCf die daten holt? Sie kostet 49€, für Experimente dann eigentlich eher erträglich als die ELV-Variante. luxx
das ist unter http://www.wetterdirekt.com/?key=konzept beschrieben. also über das Pager-Netz. Nix DCF77.
Für mich ist das eine manuelle Wettervorhersage, die über Satelit verbreitet wird.
I have collected the DCF77 data stream for some time and a brief analysis of the new bits shows one + six correlations which give a strong hint about the encoding: Collect bits 1-14 of the DCF77 timegram for periods of three minutes at a time and you get 42bit "meteotime" datagrams, ie: collect for minute 00-02, 03-05, 06-08, ...57-59. In these 42 bits, the first bit and the eight bit are always zero. Given their respective probabilities for being set, the second and ninth bit are different 10% too often. The same goes for 3rd+10th, 4th+11th, 5th+12th, 6th+13th, and 7th+14th. It is not very often that all the first seven such pars are different, but it happens, and some cases even look as suspicious as this one: -######-------####----##-#--##-#--##---#-- The format documented in the pdf, will by nature of weather generally being pleasant at this time of the year, be heavy on zeros in the front end of the datagram, that could cause the above. All this leads me to venture the guess that the datagrams are scrambled with a seven bit tapped shift-register based scrambler. The shift register is obviously preloaded with some "magic" content at the start of each datagram, because otherwise the first N-ish bits would leak through and they clearly don't. The other thing is that there is no such correlation for bits outside the first block of 14 bits of the 42 bit datagram, this could strongly indicate that the entire sequence of DCF77 bits are run through the scrambler, not just the meteotime bits. The next logical step, is to get a "known plaintext". With an "official" meteotime clock, it should be possible to "encode" the displayed values into a datagram, and if we know when the display updated, the immediately preceeding datagram is likely to be the one we want. XOR'ing the "known plaintext" against the received datagram should give us the scrambler output for the 3 minute window, and a simple brute-force attack should be able to uncover the taps on the shiftregister and the value at the start of the 3 minute window. Happy Hacking :-) Poul-Henning
Hallo,
Es kommt hier in einigen Postings so rueber, als ob das hier gilt:
(1) Dinge wie CBC sind in diesem Szenario nicht anwendbar
=>
(2) Zu jedem Plaintext existiert GENAU NUR EIN Ciphertext.
(1) ist korrekt: CBC geht nicht, da die Empfaenger ja nicht synchron
starten und jederzeit aussetzen und wieder-einsteigen koennen muessen.
ABER
(2) ist falsch: Zum dem selben Plaintext koennten sehr wohl identische
Ciphertexte existieren. Und zwar ganz ganz simpel:
Cipher := SymmetricEncrypt(Masterkey, Wetter + Zufallsstring)
('+' bezeichne hier lediglch eine Bitstring-Aneinanderkettung.)
Somit gibt es zu zwei identischen Plaintexten (Wetterdaten) NIE der
selbe Cipher, weil sie mit unterschiedlichen Bits "gesalzen" sind!
Der Zufallsstring muss ja auch nicht besonders lang sein, um voellig
unterschiedliche Ciphers zu identischen Plains hervorzurufen.
(vorrausgesetzt der symetrische Verschluesselungsalgorithmus ist
halbwegs stark. Derartige Alorithmen sind allerdings auch durchaus auf
kleinerer Hardware lauffaehig).
Die Information, auf welchen Standort sich die Wetterdaten beziehen
muessen nicht verschluesselt gesendet werden (bei 14 CipherBits gilt es
ja alles einzusparen was geht), sie sind ja aus Stunde:Minute ableitbar.
Fazit: Wenn der Hersteller auch nur wenige "Salt"-Bits mit einstreut,
ist auch ein Known-Plaintext-Angriff sinnlos, und es laesst sich keine
Tabelle
"Ciphertext <-> Plaintext" aufzubauen!
Falls es so implementiert ist schliesst das leider natuerlich auch nicht
aus, dass zB Protokollbefehle der Art existieren, welche die Empfaenger
dazu veranlassen, auf einen neuen Masterkey umzuschalten, wenn der alte
kompromittiert ist.
Der neue Masterkey wuerde dann natuerlich nicht over air gehen, sondern
nur gesagt "nehmt den 2. Masterkey aus eurer internen,
werksseitig-initialisierten Tabelle".
Es bleibt natuerlich zu hoffen, dass das nicht so implementiert wurde
...
@Poul-Henning hi Poul-Henning, i know you wrote CRC. CBC was mentioned above here in #495856. let's hope they encrypted the weather data using a shift register as you estimate (or some similar security-by-obscurity stuff) - and not some AES.
Wie steht's denn mittlerweile mit Mittschnitten von DCF, angezeigten, und den zwischen den ICs ausgetauschten Daten? Läßt sich vielleicht 'schon mal' die Zuordnung Region-Zeit ermitteln, ohne daß die Kodierung bekannt ist? Z.B.: Sendet der Host-Controller dem meteo-chip den eingestellten Standort? Woher bezieht meteotime die Wetterdaten / sind die übermittelten Daten auf anderem Weg uz erhalten? (sind angezeigte Daten auf der Uhr identisch zu einer Wetter-Seite im Netz?) Sind die Uhren die ganze Zeit auf Empfang? > Achtung: ist nur ca. 3 min aktiv vs. > ELV Uhr 24/7 auf Empfang ist Ich bin wirklich gespannt, ob das zu knacken ist. Angesichts der vorhergehenden Bemühungen der PTB und anderer, ein Warnsystem zu implementieren (diese Informationen findet man eher, als etwas über den Wetterdatendeal..) ist es unverhältnismäßig, daß man für den Empfänger(bau) eine Lizenz kaufen muss, und das Geschäft ein Di-pol (schweizer Unternehmer / HKW) ist.
Nur mal ne blöde Frage: Sagen wir mal einer hätte den Code geknackt, wäre es dann nicht illegal das zu veröffentlichen??
Das ist vielleicht ja der Grund für den abrupten Abriss der Diskussion.. Schön wäre dann aber ein Hinweis aus dem Kreis der Eingeweihten.. Wenn es nämlich möglich ist, würde ich es auch mal probieren.
Ich würde mich auch mal über ein paar Infos über den Fortschritt des Loggens und Vergleichens freuen!
Kurze Info von T-Systems, die den Sender betreiben: http://www.t-systems.de/tsi/de/92946/Startseite/UeberTSystems/Best-Practice-Online/Ausgabe-01-2007/Projects:%20Zeitzeichen/Projects-KM-2007-01-05-Zeitzeichen
Hallo! Unter http://www.meteomarkt.ch/shop/catalog/index.php?cPath=2_16 gibt's den Wecker für mittlerweile ca. 55 EUR - das ist schon eher ein Preis, den ich mir vorstellen kann um ein "Referenzobjekt" zu erwerben. Aber einen Haken gibt's: Versand nach .DE für 22,-- EUR - da stößt sich wohl die schweizer Post an den dt. Kunden gesund :-(
vlt. gibts hier ja einen aus der Schweiz, der das für dich übernehmen kann? Vlt. hätten ja sogar mehr als eine Person interesse...
@all: Wie ist denn eigentlich der Status der Signaldekodierung? Ist da schon irgendjemand weitergekommen?
So Leute, Hosen runter! Wieso schreibt ihr nichts mehr?? Aufgegeben? Ich will wissen, ob man das Rätsel lösen kann! Los!
Gut dass ich diesen Thread gefunden habe! Hier in Mainz gibt es seit einigen Monaten mit der großen Bahnhofsuhr am Bahnhofsgebäude. So wie es aussieht, lässt diese sich auch durch die Meteotime-Daten aus dem Tritt bringen. Fakt ist, dass sie nach einem Neueinschalten der Stromversorgung immer ein paar Tage läuft, bis wohl in den Bits 1-14 ein so unglückliches Muster auftritt, das sie aus dem Takt bringt. Dann bleibt sie einfach stehen. Der Betreiber der Uhr, die Firma Hevert Arzneimittel (die Uhr gehört eigentlich zu einer Leuchtreklame) hat bereits mehrfach Techniker kommen lassen, die die Uhr überprüft haben, aber keinen Fehler gefunden haben (wie auch - das Uhrwerk ist in Ordnung). Sie haben dann immer die Stromversorgung unterbrochen und neu eingeschaltet, woraufhin die Uhr wieder ca. 1 Tag lief (ist sowas wie ein "Stadtgespräch" in Mainz, mittlerweile ist es schon fast eine fortlaufende Story in der Tageszeitung ;) Nun, jedenfalls hat mich dieser Thread darauf gebracht, dass es vielleicht was mit diesen Meteo-Daten zu tun hat (vllt. wartet die uhr nicht brav 14 Sekunden, sondern interpretiert das erste Bit was 1 ist als erstes Datenbit oder so). Ich werde jedenfalls mal die Firma Hevert darauf hinweisen, ich weiß nicht ob die das mit dem Meteotime schon wissen. Vielleicht kann man der Uhr ja eine neue Firmware verpassen oder auch den DCF-Dekoder austauschen. Diese Bahnhofsuhr war in den letzten Jahren morgens meine zuverlässigste Zeitquelle... ;) Gruß Fabian
Mist, in meinem ersten Satz fehlt das Wort "Probleme" nach dem 8. Wort. ;-D
Stehe ich jetzt komplett auf dem Schlauch? Soll das Problem tatsächlich an den Meteo Daten liegen? Wie werden DCF-Dekoder ohne µC gebaut? Mit Schieberegister und solchen Sachen? Gibt es da eine technischen Grund die ersten 14 bits als "0" anzunehmen und dann ab dem 15. zu dekodieren? Wenn nicht: Stümper!
Ich glaube auch, dass die "Programmierer" (Entwickler, Hersteller) dieser Bahnhofsuhr stümperhaft gearbeitet haben. Aber die Wetterdaten sind ja jetzt erstmal da, also muss an der Uhr irgendwas geändert werden. Neuer Chip oder was auch immer, jedenfalls finde ich die Erklärung gar nicht so unplausibel dass es irgendwas mit den Meteodaten zu tun hat. Schließlich trat das erste Problem mit der Uhr genau dann auf, nachdem die Firma Meteotime diese 14 Bit "gekauft" hat...
Ich habe mal die zwei Tage lang geloggten Daten (dcf_log_2Tage_59Ticks.txt) so umgewandelt dass in einer Zeile immer die zusammengehörenden 3 Minuten stehen. Vielleicht hilft das beim Entschlüsseln.
Hallo Gemeinde, ich möchte nur etwas hinzufügen. Nach Poul-Henning Kamp (Gast) Datum: 15.04.2007 15:17 ist jedes erste und achte Bit des ersten 14 Bit Satzes gleich 0. Es geht bei Minute 1 los und stellt sicherlich den Kopf dar.
Wenn das erste und achte Bit null sein soll, dann habe ich das oben falsch zusammengesetzt. Ich hätte um 00:01 Uhr anfangen müssen. Hier ist nochmal die richtige Version. Ich habe mir nochmal den Beitrag von Poul-Henning Kamp durchgelesen. Ich finde wir sollten so vorgehen wie er es beschreibt. Einmal mit einer Meteo-Uhr die abgelesenen Daten in Bits mithilfe des PDFs von Meteotime umwandeln. Dabei die Uhrzeit des Datenempfangs der eingestellten Region rausfinden. Dann die mitgeloggten DCF-Daten für diese Uhrzeit mit den Klartextdaten vergleichen und dabei den verwendeten Schieberegister-Algorithmus ermitteln und den Initwert bestimmen. Oder man macht es einfacher und wartet bis irgendeiner von euch mit den Entschlüsselungs-ICs was rausfindet.
Hi codebreakers, Here are some infos abut the "dechiffrier-IC", discovered with an IROX Mete-On 3 hooked to a logger. Without the details on the hardware, lets see the structure of communication: MO3 -> DCIC (82 bits at all): ----------------------------- 0-13 (14) - first data packet (minute 1, 4, 7...) 14-27 (14) - second data packet (minute 2, 5, 8...) 28-41 (14) - third data packet (minute 3, 6, 9...) 42-49 (8) - minute (bcd) 50-57 (8) - hour (bcd) 58-65 (8) - day (bcd) 66-70 (5) - month (bcd) 71-73 (3) - weekday (bcd) 74-81 (8) - year (bcd) Time data is the actual time. The decoding begins immediately after the last bit of the third packet received, so this is the time with the second packet transmitted. DCIC -> MO3 (24 bits at all): ----------------------------- 0-21 - plain weather data (as described in "DB W-Protokoll-V 1.pdf", with a minor difference described below) 22-23 - unknown, most of the time (99%) '10', sometimes '11' The temperature and rain data shown on the MO3 display matches exactly to the logged data decoded with the protocol in the pdf file. The weather icon data is decoded as follows: transmitted - shown 1 - 1 2 - 2 3 - 3 4 - not discovered yet 5 - 11 6 - 9 7 - not discovered yet 8 - not discovered yet 9 - not discovered yet 10 - 7 11 - 8 12 - not discovered yet 13 - 10 14 - not discovered yet 15 - not discovered yet Other data can't be verified with the MO3, because it can display weather icon, temperature and rain forecast data only, and only for the actual day and night. Attached You will find a log parsed with the infos above, it will make clear this mess. Happy hacking, Dexter
Hi Ich bin neu hier. Tag zusammen . Das Thema interessiert mich brennend. Vieleicht könnt ihr mit dieser Info was anfangen. *********************************************************** Zeit (UTC): Prognose: 22:00 - 03:59 Aktueller / kommender Tag (TODAY im Display) 04:00 - 09:59 Folgender Tag (DAY 1 im Display) 10:00 - 15:59 Darauffolgender Tag (DAY 2 im Display) 16:00 - 18:59 Darauffolgender Tag (DAY 3 im Display) 19:00 - 21:59 30 Zusatzregionen mit 2-Tages-Prognose *********************************************************** Quelle: http://www.wetterstationen.info/mete-on-1.php Karl
Zunächst einmal: Klasse, dass jemand am IC mitgelogged hat. Das ist sicher schon mal ein Schritt in die richtige Richtung. Leider gelingt es mir nicht weitere Regelmässigkeiten zu finden. Die Idee der XOR-Verknüpfung mit dem Ausgang eines rückgekoppelten Schieberegisters kann man allerdings in der einfachen Form ausschliessen: es gibt Datensätze die decodiert identisch sind. Wenn man jeweils zwei solche nimmt sollten die Eingangsdaten für diese XOR verknüpft Rückschlüsse auf das Schieberegister zulassen. Dazu passen die Daten aber nicht (oder das Schieberegister ist länger als 16 bits) Deutlich mehr Eingangsdaten könnten ein wenig helfen. Viel wichtiger wäre aber, dass jemand mal untersucht, wie das IC bei veränderten Eingangsdaten reagiert. Dafür ist es nötig, dass jemand das IC entsprechend mit modifizierten Daten ansteuert. Damit könnte man die folgenden Fragen klären: Es gibt 82 Eingangsbits mit bis zu 42 frei wählbaren Datenbits. Am Ausgang sind es aber nur 24 bits. Wozu dienen die restlichen bits? a) Fehlerkorrektur b) zusätzliche Steuerdaten c) Zufallsdaten Dazu sollte man jeweils ein Eingangs-bit ändern: wieviele/welche bits ändern sich in den Ausgangsdaten? Wenn sich bei einem bit noch nichts ändert, gibt es eindeutig einen Fehlerschutz für die Daten. Dann sollte man weitere bits ändern und das mapping vom Eingang auf den Ausgang feststellen. Gibt es eine Abhängigkeit von vorausgegangenen Daten oder ist jeder 3-Minuten Abschnitt einzeln decodierbar? Dazu sollte man die Reihenfolge der Eingangsdaten verändern und beobachten, ob sich das auf das Decodierergebnis auswirkt. Ein letzter Kommentar: Aktuell gibt es widersprüchliche Angaben dazu, wann die Daten für eine bestimmte Region übertragen werden: Dexter: 00:00 - 02:59 Today-Day 03:00 - 05:59 Today-Night http://www.wetterstationen.info/mete-on-1.php : 22:00 - 03:59 Aktueller / kommender Tag (TODAY im Display) welche sind nun die richtigen, bzw. was ist die Quelle für die Angaben von Dexter?
Hi "noch einer Gast", I am working now on this "data altering project": A microcontroller will emulate the DCIC for the MO3 to send different plaintexts to discover some weather icon codes not seen yet. The same controller will also hook the DCIC to a PC to test different input streams: - already received (and known as good) packets with some bits altered to test the error detection/correction, - simple test packets (all zeros, all ones, etc...) to analyze the coding scheme. The logs will be available soon(?)... :) And the time problem: Both times are the same, therefore right, because 22:00 - 03:59 is in UTC. Our local time (transmitted by DCF77) is UTC+2: one hour + is the time zone, and the another one is "daylight saving time" used in summer. The log shows practically the local time. Happy hackning, Dexter PS: Sorry for the bad english, but my deutsch is even worse, close to nothing... :(
Hi
Möglicher Lösungsansatz : ! ?
Die Signale von der "Antenne" (Simulierte Teildaten) an ein
Anzeigegerät senden. (Z.B. nur 3 x 14 Bit alle 3 Miuten und sonst
KEINE Daten mehr.
Beabbachten was die Anzeige macht ! ?
Nur mal so mein Gedanke.
P.S. Manchmal findet auch ein Blindes Huhn ein Korn.
Vielleicht hilft es euch, ansonsten dschnell wieder vergessen.
Hallo Jungs ! Lasst uns ein Wettercode Buch erbeuten und nichts wie ab nach Bletchley. kleiner Spass. Aber vom Prinzip her war England im 2.WK trotz des besitzes einiger Enigmas nicht in der Lage ohne erbeutete Unterlagen mitzulesen. dh. der Algor. war bekannt ,doch der war nutzlos ohne die Tages- schlüssel. Das Problem ist ähnlich hier: Ich denke auch nicht ,das Keys über die Luft übetragen werden. Die Masse an Intelligenz sitzt im IC. Grundsätzlich muss man erstmal rausfinden ob jeweils der selbe Input auch immer den selben Output erzeugt (an verschiedenen Uhrzeiten) Dazu wird man wohl eien DCF77 Geber aufbauen müssen .(AVR) Geber mit den Logfiles füttern und guggen was passiert. Jetzt kann man das Logfile verändern und schaun. und so weiter Ich mach mit. Gruss Andreas
Nur so mal gefragt: Hat sich das niemand patentieren lassen ? Wenn ja, muß doch in der Patentschrift stehen, wie die ganze Sache funktioniert oder kann man soetwas als Firma einfach 'geheim' halten ?
Selbstverständlich, kann eine Firma ein "Betriebsgeheimnis" haben, z.B. Cola Rezept, der rühmliche "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0" key, auch glaub ich nicht das die Zusammensetzung von Chanel No.5 irgendwo in einem Patent steht. War jetzt der eigentlichen Sache nicht sonderlich dienlich, aber ich finds irrsinnig spannend, hoffentlich knackt ihr das. ;) -wiebel
> Dazu wird man wohl eien DCF77 Geber aufbauen müssen .(AVR) Geht auch standalone: https://erlangen.ccc.de/index.php/DCF77
Hi Face --> Bringt uns NICHT weiter. Habt ihr eine "Uhr" , bei der mann Informatieonen auslesen kann. Ich denke so an ein Uhrmodul, das damals Conrad-Elektronik für ca. 10 Euro hatte.
Da der Link nicht funktioniert, kann ich nicht schauen, was für ein Modul es ist (nächstes Mal bitte einfach die Bestellnummer posten) aber die Wetterbits empfängt prinzipiell jeder DCF77-Empfänger. Das Problem ist aber nicht das Empfangen, sondern das dekodieren der Wetterinformation.
Hallo Habe mir aus nem AVR ne Uhr gebaut. Wo liegen genau die Wetterbits? von Sekunde Anfang 01 bis Ende 14 oder schon von Sekunde 00-14. Gruss Andreas
> Wo liegen genau die Wetterbits? > von Sekunde Anfang 01 bis Ende 14 oder schon von Sekunde 00-14. Kennst du http://www.dcf77.com/deutsch/kodierung.htm ? Es müssten die ersten 14 Bit nach der Minutenmarke sein...
Nur zur Info: Hier in Hessen ist eine Meteotime Uhr im Real Prospekt vom Wochenende aufgetaucht. 59€ soll das Teil kosten, dass auch ein Meteotime Logo trägt. Ist zwar nicht so schick, wie das große Vorbild aus der Schweitz, abere dafür auch erheblich leichter zu bekommen. Kann man nur hoffen, dass es auch mit dem fragwürdiegn Chip bestückt ist und dieser nicht bereits integriert wurde. Gruß, Ulrich
> Hier in Hessen ist eine Meteotime Uhr im Real Prospekt vom Wochenende > aufgetaucht. 59€ soll das Teil kosten, dass auch ein Meteotime Logo > trägt. Daten gibt's hier: http://tinyurl.com/38e5w8
Hallo Habe mal bei Dexters Text Datei gleiche Outputs gesuchtund habe festgestellt das nichtmal Ansatzweise die Inputs übereinstimmen. Das wird wohl schwierig Mfg Andreas
Ich würde sagen die Zeit und das Datum spielen ins Decoding mit rein. Beides ändert sich in jedem Datenblock und ist niemals (wieder) gleich.
aber dann müsste man ja wenn man in den chip "falsche" daten reinschiebtm also immer gleiche uhrzeit etc auch immer das gleiche rausbekommen?! dann würde man sehen obs so ist oder nicht
Ja genau. Aber das muss eben erst mal jemand ausprobieren. Soweit ich bisher mitgelesen habe hat es noch niemand probiert.
@Luxx: > aber dann müsste man ja wenn man in den chip "falsche" daten > reinschiebtm also immer gleiche uhrzeit etc auch immer das gleiche > rausbekommen?! dann würde man sehen obs so ist oder nicht Dexter hat geschrieben, dass er's ausprobieren möchte. @Mobifu: > Kennt ihr das Cryptool 1.4.10 Ist das ein hint? Leider hab' ich das falsche OS installiert :-(
Das Cryptool befördert erstaunliches zu Tage. Wenn man die Autokorrelations Funktion über einen Mitschnitt laufen lässt der keine Uhrzeit enthält also nur die 42 Bits von ein paar Stunden. dann gibt es eine Periodizität mit schlüssellänge 1 ?????? Schlüssel 30 Hex schaut mal selber . gruss Andreas
Hi >dann gibt es eine Periodizität mit schlüssellänge 1 ?????? >Schlüssel 30 Hex Äh, kannst du das näher erklären! Heißt das Input + Hex 30 (-30H) ? >schaut mal selber . Wo ?
Na Cryptool runterladen und los Schlüssel 30Hex mit XOR auf die Inputdaten. Gruss Andreas
Fehlt da zur Vollständigkeit, und um es auch ohne Cryptool nachvollziehen zu können, nicht noch die Information welches der 42 Input-Bits zu welchem de 24 Output-Bits gehört? Denn bei einem einfachen XOR müßten ja input und output gleich lang sein.
Das sind doch nur statistische Betrachtungen im Bitmuster und keine Dekodierung der Inputs. z.B tauchen in der Autokorr. Fkt. 3 Spitzen im Abstand von 42 Bits auf. Komisch ? 1 und 8 Bit ist klar aber das dritte? Mfg Andreas
Für die "nicht Windowsnutzer" im Anhang eine PDF von Mobifu's Anregungen
Interessant auch die automatische Vigenère Analyse: Ermittelte Schlüssellänge: 42 Ermittelter Schlüssel: 101010010101001111100110110011111111111010 Näheres zu Vigenère: http://de.wikipedia.org/wiki/Polyalphabetische_Substitution Aus den Daten in http://www.mikrocontroller.net/attachment/20863/dcf_log_2Tage_59Ticks.txt wird damit: 00001100011010 10111011010111 00011100100110 10101111111101 11101111011000 01100111001100 11001000110001 10001011111010 11101010101010 11101011001110 11101111111011 01111110010010 11000001101101 10111011000001 11111100111001....
Wenn ich den diesen Text damit analysiere erhalte ich eine Keylänge von 35 Zeichen . Komisch ? Andreas
Ich will ja keinen entmutigen, aber die Dateien mit den Daten in ASCII Darstellung in ein Tool zu laden und auf Wunder zu hoffen wird wohl wenig bringen. Bisher kommt ja auch nur das heraus was vorher schon bekannt war: -Die verschlüsselten Daten sind 42 bit lang -Davon sind 2 bits mit Abstand 7 konstant 0 Daraus folgt, dass die Autokorrelationsfunktion periodische hohe Peaks im Abstand von 42 bekommt und nochmal etwa halb so hohe im Abstand von +/-7 um die hohen Peaks herum. (daher also 3 Peaks) Die Vigenère Analyse spricht einfach auf diese periodische Wiederholung an. Und solange man Vigenère nur auf '0' und '1' anwendet, bleibt das sowieso eine einfache XOR Verknüpfung. Man müsste erstmal überlegen, wieviele bits zu einem Symbol zusammengehören, bevor das sinnvoll anwendbar wird. Die oben erwähnten 0x30 als XOR Schlüssel ergeben sich wohl einfach daraus, dass '0'=0x30 das häufigste Zeichen ist, wenn man die Daten als ASCII '0' und '1' darstellt. Trotzdem gibt es in den ersten 14 bit noch mehr Regelmässigkeiten als nur die beiden Werte, die konstant 0 sind. Das lässt zumindest darauf schliessen, dass nicht alle bits perfekt verschlüsselte Daten sind.
Zum anderen läst sich nur mit den Daten aus Dexters Datei 20070716.txt einen Analyse durchführen. Denn dort sind Cyphertext und entsprechender Klartext vorhanden. Aber ich würde mal abwarten bis Dexter den Dekoder-IC mit eigenen Daten gefüttert hat. Besonderst das Ergebniss von speziellen Bitmustern wie alles 0 und alles 1 usw. wäre hier interessant.
noch ein paar konstruktive Informationen: Zu dem Thema gibt es zwei passende Patente bzw. Gebrauchsmuster: DE 20 2006 017 739 U1 "Einrichtung zum Empfang verschlüsselter Informationen" -Schlüssel wird nicht übertragen, sondern aus der Uhrzeit abgeleitet -Beispiel: AES Verschlüsselung -Daten und Schlüssel können bis zur Blocklänge aufgefüllt werden -beliebige Operationen können auf die Zeitdaten angewendet werden, um den Schlüssel zu erzeugen DE 20 2005 019 853.6 / EP 1798612 "Datenübertragungen in langsamen Übertragungssystemen, wie durch Zeitzeichensender" 22 Nutzbits + 20 Prüfbits = 42 bits Übertragung in 3 Minuten Minute n : 14 Nutzbits Minute n+1: 8 Nutzbits + 6 Prüfbits Minute n+2: 14 Prüfbits Die genauere Nutzung der 22 Nutzbits zu den verschiedenen Tageszeiten ist auch beschrieben. Die oben beschriebene Aufteilung der Nutz und Prüfbits auf die Minuten kann ich allerdings in den Daten bisher nicht finden. Es würde wirklich sehr helfen, wenn jemand das IC mal mit modifizierten Eingangsdaten füttern könnte, und die Ergebnisse berichten würde...
http://www.zorc.breitbandkatze.de/crc.html habe ich gefunden . wenn man bischen mit spielt könnte man vermuten die ersten acht bits gehören zu einem CrC meine Einst. CRC Order 8/CRC Poly 4/nächsten beiden 0. Data länge 34/ sodas der enstehende voran gestellte Rest vorne und hinten immer eine Null enthält. mfg Andreas
> -Schlüssel wird nicht übertragen, sondern aus der Uhrzeit abgeleitet > -Beispiel: AES Verschlüsselung Das kann man doch sicherlich ausschließen. Dann sollten die Daten doch etwas mehr "rauschen" und nicht so systematisch sein, wie bereits in anderen Postings gezeigt wurde...
Hi codebreakers, I have done more tests with DCIC. It was feed with a data packet from an early log, but some bits were altered to test error correction. The results are the following: - First of all, the meaning of the last two (22 and 23) bits of the output data is now clear: 00 - decoding failed 10 - decoding passed 11 - decoding passed, but error correction was made - Any single bit error in the time data used as key (bits 42 to 81 of the input) makes the decoding impossible. - Any single bit error in the cipher text (bits 0 to 41 of the input) will be detected, corrected and signed in the output by DCIC. - Double bit errors in the cipher text make the decoding impossible. - The 0. and 7 . bits of the input data, which are always '0', are treated a little different: One or both of them can be inverted, the DCIC does not care about it and will decode the packet without the sign "error correction was made". But if these don't care bits (one or both of them) are changed with any other bit, then the DCIC will treat this as double bit error, and will not decode the packet. - If the decoding fails, then the output will show a fixed value of <1000000000000000000001 00> regardless of the input, so there isn't any chance to test the structure of the cipher algorithm with different tricky inputs. Happy hacking, Dexter
> So there isn't any chance to test the structure of the cipher algorithm > with different tricky inputs. Is there any speed limit? So you may input a fixed time and fuzz around the weather bits - brute-force checking for valid data. As we know all three parts: key: time decoded: weather data encoded: on air transmitted data there must be a chance. May be one should ask in sci.crypt for help...
With 22 data bits + 20 bits redundancy and single bit error correction: for every valid data word there are 42 additional ones that would be decoded with the same result (plus error correction indication). If you just chose random data you should have a correct data word on average every 2^20 tries i.e. one out of one Million. If you also take the corrected into account that would be one out of ~ 25.000 tries. Normal use could require: 5 cities 4 days 2 (day+night) = 40 decoding actions per day. So to get one hit you would have on average an load of the decoder equivalent to 600 days of usage. With an increased speed at least one test every 3 seconds should be feasible. The 3 seconds is just the value from the decoder datasheet. This would give a hit on average every 21 hours. It would be interesting to hear which speed can be obtained in reality. The good news: the PIC 12F509 (this is at least the decoder in the Mebus version of the device) to my understanding does not have any means to permanently store any information. There is only the program EEPROM but no data EEPROM. Correct? After a power cycle it should all be the same as before again. So if someone can try this, it would be interesting to get a collection of valid input data words for the same key=timestamp. To keep this synchronized, I would suggest to start with the first timestamp of the Dexter trace as we than already have a known correct data word. Having this collection of samples should allow to understand how the error protection is working in detail. After that one could try different timestamps...
There are very hard time limits. The decoding itself takes 1.25 seconds, and after every decoding (or after power up) You must wait a little more than 30 seconds, so the overall decoding time of one packet is about 32 seconds. Dexter
Hallo, der PIC 12F509 hat keinen Daten EEPROM nur 1K Programm mit 41 Byte Variablen. Also ohne Spannung kein Datenerhalt. Interessant wäre die OSC-Beschaltung der PIN 2/3 da die Verarbeitungszeit relativ hoch ist. Sicherlich beabsichtigt wird der Chip in den Sleep-Modus zum Strom sparen geschickt. MfG Chip
Chip wrote: > [...] nur 1K Programm [...] Hat schonmal jemand, der so eine Uhr hat, versucht, das Programm auszulesen? Ich nehme zwar schwer an, daß die Dinger mit Code-Protection geflasht werden, aber es schadet ja nicht, das mal zu überprüfen... ;) > [...] da die Verarbeitungszeit relativ hoch ist. Die Verzögerungen könnten auch bewußt eingebaut worden sein, um das Reverse-Engineering zu erschweren.
Die lange Verzögerung dürfte definitiv dazu dienen, das Reverse Engineering zu erschweren. 30s - so lang kann nicht mal ein PIC brauchen um in Wallung zu kommen.
Deshalb die Frage nach dem Takt OSC-Beschaltung der PIN 2/3, es geht von außen z.B. über den vorh. Uhrenquarz 32.. kHz oder über INTOSC intern mit 4 MHz. Wenn der von außen langsam getacktet ist könnte man den Pic mit max. 4 MHz takten also 125x schneller. Das würde das Reverse-Engineering enorm beschleunigen.
Ich habe mal die Pins des 12F509 der Beschriftung der Testpunkte
auf der Platine der Wetterstation gegenüber gestellt.
Es handelt sich um die Mebus Wetterstation mit Meteotime Empfang von
Real.
IC5 ist der Decoder:
VDD 1* 8 VSS
GP5/OSC1/CLKIN TP38 2 7 TP35 GP0/ICSPDAT
GP4/OSC2 TP36 3 6 TP37 GP1/ICSPCLK
GP3/MCLR/VPP 4 5 TP39 GP2/T0CKI
alternativ könnte noch ein anderes IC bestückt werden.
Dies hätte dann folgende Beschaltung:
TP37 1 8 VDD
TP38 2 7 MCLR/VPP
TP36 3 6 TP39
TP35 4 5 VSS
Folgende Signale sind an den Testpunkten zu finden:
TP35 clock in (high ~850us, low ~30ms)
TP36 clock out
(während des Reintaktens der Daten:
wie clock in, nur einige Microsekunden verzögert
während der Datenausgabe:
invertiert zu clock in,etwas vor clock in)
TP37 data out (24 bits)
TP38 data in (82 bits)
TP39 control/status
Eingabephase: low
Ausgabephase:high
Nachher: 45s high, alle 3s für 20us low
Die Daten ändern sich jeweils wenige Mikrosekunden vor der steigenden
Flanke auf clock in.
Der MCLR/VPP Pin ist mit einem Kondensator verbunden, der an GND geht.
Da Pin 2 die Eingangsdaten bekommt, ist eine Verwendung als Takteingang
ausgeschlossen.
Signale am IC:
-MCLR/VPP hat im Betrieb den gleichen Pegel wie Vdd
(kein externer Reset im Betrieb?)
-wenn der Dekoder nicht genutzt wird, sind alle anderen Signale auf low
-alle 3 Minuten werden Daten zum Dekoder und zurück geschickt
unabhängig davon, welche Städte gewählt worden sind
Es gibt einen Testmodus (Testtaste während des Resets gedrückt halten
und dann mehrmals ^)
In diesem Testmodus lässt sich auch der Dekoder mit einem festen Muster
testen:
Eingang: 01000010100011
01101010100111
10011000011000
10100000 Minute: 5
01001000 Stunde: 12
11001000 Tag: 13
00100 Monat:4
001 Wochentag: 4
01100000 Jahr: 06
Ausgang: 01011 10010 01010 11111 1110
Generell ist das Timing etwa folgendermassen:
82 Eingangsbits mit jeweils ~31ms: 2.5s
250ms 'Denkpause'
24 Ausgangsbits mit jeweils ~31ms: 0.7s
danach schliesst sich eine Phase an, die im Normalbetrieb 45s Sekunden
dauert
In dieser 45s Phase ist TP39 noch auf High Pegel (mit kurzen
Unterbrechungen von ~20us)
Die Phase kann aber offensichtlich vorher abgebrochen werden.
Im Testmodus war eine Wiederholung alle 15s möglich, da man nicht viel
schneller durch die Punkte des Testmenüs kommt (EEPROM
lesen/schreiben...)
Mit externer Ansteuerung sollte man also schon deutlich schneller werden
können als bisher angenommen. Ob man auf die 3.5 Sekunden der
eigentlichen Datenübertragung runterkommt oder die noch abkürzen kann,
kann ich allerdings nicht sagen.
Kurze Info noch zum EEPROM auf der Platine:
es handelt sich um ein 24C512. Die 64kByte Daten werden im Wesentlichen
wohl zum Speichern der Städtenamen, Menütexte etc., der Wetterdaten und
Einstellungen für den Hauptprozessor verwendet. Programmcode des
Hauptprozessors ist hier wohl nicht zu finden.
Es werden alle Daten komplett im EEPROM gespeichert. Es wird aber nur
alle 3 Stunden ein neuer Satz geschrieben und auch die Anzeige
angepasst. Wer also vor Ablauf der 3 Stunden einen Reset auslöst oder
die Batterien entfernt, bekommt gar keine Daten angezeigt.
Die Zeiten sind aktuell 02:59:17 MESZ und dann alle 3 Stunden.
Eigentlich müssten die Zeiten UTC basiert sein (00:59:17 UTC) und sich
im Winter eine Stunde nach vorne verschieben.
Die I2C Leitungen zum EEPROM finden sich praktischerweise direkt am 16
Pin Stecker hinter der Abdeckung.
berichtigung: 1010000 0 Minute: 5 010010 0(0) Stunde: 12 << fehler ?! 110010 0(0) Tag: 13 00100 Monat:4 001 Wochentag: 4 01100000 0 Jahr: 6 ###################################### höher als 8 stellen ohne parität gehts im zeitsignal nicht ! minute -1 parität = 7 stellen = 1010000 = 5 stunde -1 parität = 6 stellen = 010010 = 10 ! <<< tag = 6 stellen = 110010 = 13 wo. tag = 3 stellen = 001 = 4 = Donnerstag jahr -1 parität = 8 stellen = 01100000= 6 die geklammerten nullen sind auch zuviel.
sorry, monat vergessen: minute -1 parität = 7 stellen = 1010000 = 5 stunde -1 parität = 6 stellen = 010010 = 10 ! <<< tag = 6 stellen = 110010 = 13 monat = 5 stellen = 00100 = 4 wo. tag = 3 stellen = 001 = 4 = Donnerstag jahr -1 parität = 8 stellen = 01100000= 6 bei stunde ist eine null zuviel und beim tag sind am ende 2 nullen zuviel. stimmts nun ?
@jupp die 12 uhr angabe ist richtig gewesen mit 010010, auch die 0 am ende der stundenreihe ist zu streichen. und die 00 am ende von der tagesreihe ist auch unverständlich. die frage ist - sind die nullen tatsächlich dabei gewesen, oder sind die versehentlich bei der abschrift dazu gekommen ? folgend ein paar, mit meiner pc-soft aufgezeichnete pakete. 1,5v funkwecker dcf-signale am gameport abgefragt. http://dcf.cya.de die soft für unten stehendes paketformat ist noch nicht verfügbar.
1 | 011011000100101000011000010010001100011111 1100000 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:03 Paket: 1 |
2 | 001001001001010110001100111110000111011001 0110000 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:06 Paket: 2 |
3 | 011011000000010001110001000001111011100101 1001000 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:09 Paket: 3 |
4 | 010100101111001110000111011010100001111101 0100100 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:12 Paket: 4 |
5 | 000001000000010111110011001100010100110110 1010100 1 100100 0 000001 001 10010 11100000 1 20.09.07 09:15 Paket: 5 |
6 | 011001001011000101011010010100110101101111 0001100 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:18 Paket: 6 |
7 | 001100100001100011010100111110110111110011 1000010 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:21 Paket: 7 |
8 | 010101100011101110111101110111011111011111 0010010 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:24 Paket: 8 |
9 | 000100001110011110111001000010111100110010 1110010 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:27 Paket: 9 |
10 | 011000100011111011111101011110011000101101 0000110 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:30 Paket: 10 |
11 | 010111000101010010001101011100111001011100 1100110 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:33 Paket: 11 |
12 | 011111100100001001010101010101001001010001 0110110 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:36 Paket: 12 |
13 | 011111100101010011111000010101110101011110 1001110 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:39 Paket: 13 |
14 | 011100000101010000111100010100011011111000 0100001 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:42 Paket: 14 |
15 | 011011100000001101111001101000111110111101 1010001 1 100100 0 000001 001 10010 11100000 1 20.09.07 09:45 Paket: 15 |
16 | 011111100100001010110110110010110111011111 0001001 0 100100 0 000001 001 10010 11100000 1 20.09.07 09:48 Paket: 16 |
17 | 000101100100111111100111101000101000001101 1000101 1 100100 0 000001 001 10010 11100000 1 20.09.07 09:51 Paket: 17 |
18 | 000100001110001111001100101000110111101011 0010101 1 100100 0 000001 001 10010 11100000 1 20.09.07 09:54 Paket: 18 |
19 | 010100100000101110110101111010100001000101 1110101 1 100100 0 000001 001 10010 11100000 1 20.09.07 09:57 Paket: 19 |
20 | 011110000000010001110001010111100110010100 0000000 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:00 Paket: 20 |
21 | 011101000111011100011000001001101011110111 1100000 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:03 Paket: 1 |
22 | 011001001010111001000010000010101011010101 0110000 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:06 Paket: 2 |
23 | 001000000010001100001111010100111000111101 1001000 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:09 Paket: 3 |
24 | 001000000010111100001111111101100111101010 0100100 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:12 Paket: 4 |
25 | 001111101010100001011100011000100101111110 1010100 1 000010 1 000001 001 10010 11100000 1 20.09.07 10:15 Paket: 5 |
26 | 010001100110010100001011001011000100010100 0001100 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:18 Paket: 6 |
27 | 000001000001010101100101100110011111010000 1000010 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:21 Paket: 7 |
28 | 011101000001010111001000111101111110111111 0010010 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:24 Paket: 8 |
29 | 001011000110010001001001111010111110011100 1110010 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:27 Paket: 9 |
30 | 010111001100010100110110111110111010000000 0000110 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:30 Paket: 10 |
31 | 011100100010110101001110110001100111111110 1100110 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:33 Paket: 11 |
32 | 001100001101110000110100111000000101000111 0110110 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:36 Paket: 12 |
33 | 000101100001101100011100011010000100011101 1001110 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:39 Paket: 13 |
34 | 010011100100110010000111000000111100011110 0100001 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:42 Paket: 14 |
35 | 010101100101000011011010000001100110100011 1010001 1 000010 1 000001 001 10010 11100000 1 20.09.07 10:45 Paket: 15 |
36 | 011001100001001111001001000101001001110001 0001001 0 000010 1 000001 001 10010 11100000 1 20.09.07 10:48 Paket: 16 |
37 | 000100001000001101100000111110011010001110 1000101 1 000010 1 000001 001 10010 11100000 1 20.09.07 10:51 Paket: 17 |
38 | 001100001000110010101001101100100110101010 0010101 1 000010 1 000001 001 10010 11100000 1 20.09.07 10:54 Paket: 18 |
39 | 010010101111101110000001110011000110011011 1110101 1 000010 1 000001 001 10010 11100000 1 20.09.07 10:57 Paket: 19 |
40 | 010101000010110110001101001101010110000000 0000000 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:00 Paket: 20 |
41 | 001110101100100111110010101111111110010010 1100000 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:03 Paket: 1 |
42 | 000001000011111101110001101101001101101101 0110000 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:06 Paket: 2 |
43 | 010001100011001110110110110000100000111110 1001000 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:09 Paket: 3 |
44 | 011001100111000001110110001111100010000111 0100100 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:12 Paket: 4 |
45 | 000101001110011111100001110111111100000000 1010100 1 100010 0 000001 001 10010 11100000 1 20.09.07 11:15 Paket: 5 |
46 | 000001000101000110101111100001110000110011 0001100 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:18 Paket: 6 |
47 | 001110001001110100011111001010110001110111 1000010 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:21 Paket: 7 |
48 | 010101001110010000100000011001110101011111 0010010 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:24 Paket: 8 |
49 | 001001000101110101011010100011001011000110 1110010 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:27 Paket: 9 |
50 | 010100100010011101001110111000011000000010 0000110 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:30 Paket: 10 |
51 | 000011000100111000100001010011000110100110 1100110 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:33 Paket: 11 |
52 | 001100101010111111001011011010100111011100 0110110 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:36 Paket: 12 |
53 | 001011000110010001100011000110101110111000 1001110 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:39 Paket: 13 |
54 | 000011001011010111100000000110101011011101 0100001 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:42 Paket: 14 |
55 | 000000000000010010111011001001100110100111 1010001 1 100010 0 000001 001 10010 11100000 1 20.09.07 11:45 Paket: 15 |
56 | 001001101011101111000100011100100110010111 0001001 0 100010 0 000001 001 10010 11100000 1 20.09.07 11:48 Paket: 16 |
57 | 011111000011101011110101000011001110110100 1000101 1 100010 0 000001 001 10010 11100000 1 20.09.07 11:51 Paket: 17 |
58 | 001111101001000011101010101110001011000100 0010101 1 100010 0 000001 001 10010 11100000 1 20.09.07 11:54 Paket: 18 |
59 | 010001101111011110010011110101110100101010 1110101 1 100010 0 000001 001 10010 11100000 1 20.09.07 11:57 Paket: 19 |
60 | 000111001100011010111000011010011110101010 0000000 0 010010 0 000001 001 10010 11100000 1 20.09.07 12:00 Paket: 20 |
Moin zusammen! Habe schon ewig nicht mehr hier reingeschaut. Hut ab! Da geht ja echt was in Sachen Decodier-/Dechiffrier-Versuche! Wer selbst noch eine günstige Meteotime-fähige Uhr sucht: bei ELV gibts inzwischen eine für 39,95 EUR mit Vier-Tages-Vorhersage: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=19148 Das nächstgrößere Modell kostet 59,95 EUR und zeigt noch etwas mehr Daten an (Wind-Vorhersage ...): http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=19151 Sehr günstig, wenn man das mit der Mete-on 1 für 279 EUR vergleicht ... Hier alle "WetterDatenStationen" bei ELV: http://www.elv.de/output/controller.aspx?cid=74&detail=1&detail2=440 Happy hacking, Didi
Und schon ist die WFC300 vergriffen :) Hat sie hier Jemand im Forum gekauft?
Ich kram diesen alten Thread mal wieder nach oben. Ich habe nicht mehr verfolgt, ob jemand das Protokoll selbst gehackt hat, aber wie ich grade beim Einkaufen gesehen habe, steht wohl im aktuellen EAM-Magazin 7/2007 (http://www.eam-magazin.de/) ein Artikel mit der Aufschlüsselung des Protokolls drin. Eventuell interessiert das ja noch jemanden.
Das Geschäft mit der Lizenz-Verkauf wurde aufgegeben? Donnerwetter...
Wenn du die Zeitschrifst kaufst, wirst du dich ärgern: Da steht sinngemäß drin, dass es keine Nachbauanleitung zu einer DCF Uhr mit Wetteranzeige geben wird. Es werden nur die bereits dekodierten Bits beschrieben.
Das passt. Man verprellt seine Geschäftspartner (=Lizenznehmer) nicht, indem man ihnen die Grundlage des Geschäftsmodells nimmt. Noch läuft die Geldmaschine und es besteht keine Veranlassung, sie durch vorzeitige Offenlegung des Protokoll kaputt zu machen. Aber kauft euch mal schön alle das Heft EAM. Die anderen Artikel sind vielleicht auch interessant. ;-)
Ich hätte natürlich erstmal reingesehen.. Auf der meteotime homepage steht nichts von einer aufgabe des lizenzgeschäftes..
Hm, ich hab im Kiosk nur kurz reingeschaut und den Artikel gesehen. Sah so aus, als wäre es komplett. Sorry für die "Falschmeldung"
Micha wrote: > Hm, ich hab im Kiosk nur kurz reingeschaut und den Artikel gesehen. Sah > so aus, als wäre es komplett. Sorry für die "Falschmeldung" Ging mir anfangs auch so. In der Mitte des Artikels ist ein Kästchen wo relativ deutlich steht, dass die das Protokoll nicht veröffentlichen dürfen. Es hätte mich auch gewundert, wenn die jetzt doch das Protokoll komplett abdrucken.
Also gibt es ein HEX-Datei für einen Pic der das decodieren kann?
Also wie, jezt? Der Artikel sagt, dass nur bekanntes aus den Bits dekodiert wird, aber er sagt auch, dass er was dekodiert, und dann doch wieder nicht. Also ist das lediglich eine DCF-Uhr ohne Wetterinfos, weil die sind ja kodiert und damit unzugänglich. Kann das mal jemand aufklären, bevor alle an den Bahnhof rennen ( der ist hier 25km weit entfernt!) Oder um mich flo anzuschließen: Dekodiert die HEX nun irgendwas außer der Uhrzeit oder nicht? Räzelnd, Ulrich
Die Ausgabe enthält zwei Artikel, die sich mit DCF77 befassen. Der zum Thema Wetterdaten ist eigentlich Werbung für eine bei Conrad für (IIRC) knapp 300 Euro erhältliche Wetter-Uhr und beschreibt nebenbei das bereits bekannte Format der Wetterdaten nach der Entschlüsselung. Die Hex-Datei gehört schätzungsweise zum zweiten Artikel, der dem Titel nach zu schließen eine Bauanleitung für einen "normalen" DCF77-Funkwecker enthält, also ohne Auswertung der Wetterbits.
Mit anderen Worten: Die sind auf dem gleichen Stand wie wir. Dann kann man sich den Kauf sparen. Und DCF77-Uhren gibt es einige hier in der Codesammlung. Gruss Jadeclaw.
hallo, bin gerade ganz neu hier bei, und zufällig auf eure fleissige arbeit gestoßen, habe nur nach näheren informationen zu den 14 bits geforscht, da ich aktuell dran bin mit mit einem pic, ein dcf test signal sender zu programieren, da wäre es dann natürlich auch nützlich, sinvolle wetterdaten mit einbinden zu können. zur dekodierung, fände ich es auch erstmal interesant eine komerzielle version von so einem chip zu haben, hat jemand schonmal die wetterstation bei elv gekauft ? und kann mir sagen ob da so ein "loser" chip mit anzapfungs möglichkeiten verbaut wurde ? ich meine die für 39,95, also die nr: 68-761-48 (WFC 300) wenn da so ein ding drin ist, würde ich mir gerne mal eine bestellen, bitte um rückmeldung, möchte nicht das ding jetzt bestellen und dan nacher zurück schicken müssen. dann was in eigener sache, mache auch gerne bei interesse ein eigenen thread auf. zu meinem programieren von dem sender, wenn jemand mit interesse dran hat, mehme immer gerne hilfe an ! hänge aktuell an der FM modulierung der pseudo zahlen, wie muss ich das genau mit dem Phasenhub von ±10 Grad auf den 77,5 kHz verstehen ? also ich takte den pic mit einem 18,228 MHz, was dann heißt, das 4557000 takte einer sekunde endsprechen, bei 77,5 khz und eine schwingung der 77,5 khz gleich 58,8 takte, was sich ja gerade zu anbietet, für eine FM modulation. wie muss ich mir den phasenhub vorstellen, das ich eine abweichung von +- 7,75 khz vornehmen muss, zwichen einem 0 und 1 bit ? also bei interesse, komme aus dem großraum mannheim/ludwigshafen danke im vorraus kiwi_
Bei DCF gibt es nur die Amplituten-Modulation oder die Phasen-Modulation. Es gibt keine Freqeuenz-Modulation die braucht zuviel Bandbreite.
hallo Marco, also wenn ich das nicht falsch verstehe, sagen aber viele webseiten was anderes: http://de.wikipedia.org/wiki/DCF77#PZF.2FPM "...seit Juni 1983 diese Information auch über eine Phasenmodulation des Trägers mit einer Pseudozufallsfolge (PZF) in einer Länge von 512 Bit übertragen. ..." gruß kiwi_
Da hier immer mal wieder nach dem Decoder IC und hinsichtlich der Lizenzbestimmungen/-kosten gefragt wird. Die jährliche Basis-Lizenzgebühr (geht an Meteotime) für das erste angedachte Anwendungsgebiet kostet 60 Kilo-Euro, jeder weitere Applikationsbereich (es gibt insgesamt 9) kostet 20 Kilo-Euro zusätzlich. Zum Verständnis: Ein Applikationsbereich wäre z.B. der Bereich "Wetterstationen", ein weiterer Bereich "Analoge Armbanduhr" und ein dritter z.B. "Digitale Armbanduhr" Die Lizenzgebühr pro Chip (geht an Meteotime) hängt von der verbauten Stückzahl ab und beträgt zwischen 3 und 17 Euro. Dieser Betrag wird gegen die Jahres-Gebühr verrechnet, bis diese aufgebraucht ist. Die Kosten für den Chip selbst der über hkw (=nominated Supplier) vertrieben wird, ist mit denen mengenabhängig direkt auszuhandeln und nahezu vernachlässigbar (kleiner 3 Euro/St.)
Autsch! 60kEuro Einstiegsgebühr ist schon heftig. Damit will man sich wohl Kleinbetriebe und Bastler vom Hals halten. Gruß Jadeclaw.
Das gibt eine Orientierung, mit welchen Schadensersatzforderungen der erfolgreiche Hacker zu rechnen hat, wenn er sein Wissen öffentlich preisgibt...
Erst mal muss es den "erfolgreichen" Hacker geben... Wenn jemand die Informationen anonym irgendwo zur Verfügung stellt, hier auch nur einen Link dazu postet dann verbreitet sich das so schnell das selbst das löschen der Info oder des Links zu spät kommt. Solltest du der erfolgreiche Hacker sein wäre es eine Schande mit der Info hinterm Berg zu bleiben. Die kommerzielle Aufmachung des Projekts schreit ja schon förmlich nach Reverse Engineering.
Dank Vorratsdatenhaltung wäre das bereits jetzt ein unkalkulierbares Risiko.
Naja, wenn Jemand Informationen anonym posten will, dann kann er das auch. Zur not halt aus einem Internet-Cafe, oder an einem öffentlichen WLAN-Accesspoint.
Ich habe einige Informationen destilliert: http://www.mikrocontroller.net/articles/DCF77_Wetterinformationen Vielleicht mögen die, die sich besser auskennen, das noch ergänzen / besser formatieren. Eine Übersicht gibt evtl. neue Ideen..
Moin! Florian ...... wrote: > Und schon ist die WFC300 vergriffen :) Hat sie hier Jemand im Forum > gekauft? Nein, aber seit ein paar Tagen steht hier eine WFC500 ;-) Nettes Gerätchen für den Preis, wenn man das mit der METE-ON 1 vergleicht. Gut, deren Design ist vielleicht etwas schicker, aber sonst kann sie auch nicht mehr ... Jetzt ist übrigens meine METE-ON 3 (dieser Funkwecker mit Wetterempfang und Vorhersage für den aktuellen Tag und die kommende Nacht) übrig. Etwas weiter oben hatte ich Bilder von der Platine verlinkt. Es ist der Decoder-Chip drin - also das richtige Gerät, um damit Decodier-Versuche zu machen :) Gruß, Didi
wie kommt man an patent DE 20 2006 017 739 U1 "Einrichtung zum Empfang verschlüsselter Informationen" heran?
Man sucht hier: http://publikationen.dpma.de/DPMApublikationen/qry_pat_beg.do Gib bei Dokumentinformation die Nummer ein.
jede seite einzeln als pdf.. vielleicht geht der link hier: http://publikationen.dpma.de/DPMApublikationen/pdf_any_pgd.do?hitlistCurrent=2&docId=DE202006017739U1¤tDocId=DE202006017739U1&docDate=29.03.2007&id=8760568&hitlistAll=32
Na dann wißt ihr jetzt, daß der Schlüssel nicht konstant ist, sondern aus der Zeit berechnet wird...
genau ihr "böswilligen Nachahmer", und zwar in etwa so: http://publikationen.dpma.de/DPMApublikationen/pdf_any_pgd.do?hitlistCurrent=1&docId=DE3139852¤tDocId=DE3139852&docDate=09.01.1986&id=3383703&hitlistAll=1 Schöne Schrift! Doof wird man davon nicht, auch wenn es dem Entschlüsseln vermutlich nichts nützt..
man kann übrigens auch auf 'full document' klicken, wenn man es gefunden hat.
http://de.wikipedia.org/wiki/Kryptoanalyse#Angriffsszenarien Unterüberschrift Known Plaintext... Ihr müßt also die chiffrierten Telegramme und deren Sendezeit sammeln, die dieselbe Anzeige auf dem Display erzeugen.
> http://publikationen.dpma.de/DPMApublikationen/pdf...
1981 angemeldet? Wird wohl kaum speziell für die Wetterdaten erstellt
worden sein.
Mit der "DCF77-Zeit" darf doch jeder Anstellen, wonach ihm der Sinn steht. Aber was wird eigentlich in der Bedienungsanleitung der am Markt erhältlichen "Wetter-Uhren" über die Nutzung der empfangenen Daten ausgesagt? Man könnte doch auf die Idee kommen, die 22 (bzw. 24) dekodierten Datenbits aus dem Decoder einer solchen Uhr kontinuierlich in einen PC einzuspeisen und dort so sämtliche aktuellen Wetterdaten round-robin vorzuhalten. Der PC könnte diese dann dem Internet zur Verfügung stellen; ein ganz simpler deamon könnte den kompletten Datenpool (und einen "Zeiger" auf den Datensatz, der zuletzt empfangenen wurde, i.e. die auf 3min genaue Uhrzeit) auf eine Anfrage hin "raw" ausliefern. Die 480*3Byte passen bei gängiger MTU ja sogar noch in ein Paket, sodaß man aus Effizienzgründen sogar UDP verwenden könnte. Einen Anzeige-Client kann dann jeder nach seinem Geschmack entwickeln. Dexter: How to connect such a clock with a pc in a cheap and simple way? One may attach such a clock on his home pc and use a commmon hosted "root server" as a distributing proxy.
aber wo ist der vorteil gegenüber z.b. flughafenwetterdaten, die sich auch so parsen lassen?
Hi! Also das in den Patenten beschriebene Cryptoverfahren macht ein reverse Engineering doch recht schwer. Es ist ja nicht nur, dass der Schlüssel ganz oder teilweise aus der übertragenen Uhrzeit erstellt werden könnte, sondern dass aus dieser Zeit ein Index auf eine Schlüsseldatenbank erstellt werden könnte. D.h. aber, dass es in dem PIC eine COde-Tabelle geben kann, oder sogar Teile oder der ganze Code des PIC als Tabelle selbst dienen könnte. Das bedeutet, dass man, wenn man einen Schlüssel hat, mit diesem am nächsten Tag schon nichts mehr anfangen kann. Die Errechnung des Schlüssels muss also für einen unbestimmt langen Zeitraum geschehen. Dann muss man aus den geknackten Schlüsseln auch noch eine Beziehung zur Uhrzeit ableiten. Zudem nennt das Patent auch eine Option den Schlüssel, bzw. seinen Index aus einer Zeitdifferenz zu bilden... Möglicherweise steckt da also noch mehr Sicherung dahinter. Alles in allem also ein recht mühseliger Weg, wenn man das reverse Engineeren möchte. Gruß, Ulrich
Einkaufstipp: Falls sich wirklich mal jemand für die Mete-On 1 interessiert und zufällig nach Helgoland kommt - ich hab meine dort im Oktober für 150 Euro gekauft. Dank Zoll- und MwSt-Freiheit der Insel :)
Hat da mitlerweile jemand was neues rausgefunden? Hab mich schon bei Wikipedia durch ein paar Korrekturverfahren gewühlt und werd mich demnächst mal hinsetzen udn mal stumpf n bischen was durchrechnen, welches Verfahren in Frage kommen könnte. Alternativ hilft der Matheprof evtl. auch weiter, der auch Kryptologievorlesungen anbietet. Vielleicht hat der mal ne Stunde Zeit nach den Prüfungen ^^ Dank dexter wissen wir ja nu jetzt, welche Daten anscheinend fürs Wetter und für die Fehlerkorrektur sind. Evtl. dackel ich auch mal zum Mediamarkt und besorg mir sone Uhr, wenns die da noch gibt. Meine zukünftige Nixie soll mir schließlich das Wetter vorhersagen können ;)
Hallo, ich habe mir den thread nun in über 3 Stunden durchgelesen und finde es schade das es noch niemand herausgefunden hat. Denn ich habe nämlich ein Programm geschrieben (für windows) womit man die DCF-Zeitdaten auswerten kann und die systemuhr dementsprechend stellt und diese Daten loggt, ich hb da mal eine Datei angehängt (leider haben wir hier nicht so guten empfang, daher sind zuletzt auch viele Fehler drin) Ich habe leider keine aktuelle datei, denn dafür ist der empfang zu schlecht in den letzten Tagen. Ich wollte mein Programm so umschreiben, dass ich auch wetterdaten anzeigen lassen könnte aber das ist schade das es noch keine lösung gibt... gruß thomy_pc
Hier 'n Link zum Thema Wetterinformationen: http://www.hkw-elektronik.de/pdfdeutsch/DB%20W-Protokoll-V%201.pdf Schön beschriebener Aufbau des Signals. :-)
Thilo M. wrote: > Hier 'n Link zum Thema Wetterinformationen: > http://www.hkw-elektronik.de/pdfdeutsch/DB%20W-Protokoll-V%201.pdf > > Schön beschriebener Aufbau des Signals. :-) Das nützt nix. Die Daten werden verschlüsselt übertragen. Das zu dechiffrieren ist die eigentliche Kunst, die noch keiner hinbekommen hat.
Willivonbienemaya .. wrote: > Das nützt nix. Die Daten werden verschlüsselt übertragen. Das zu > dechiffrieren ist die eigentliche Kunst, die noch keiner hinbekommen > hat. Weil die Leute sich auch immer wieder Saudumm anstellen. Entweder gibt es Logs von den 14 Bits oder von den 14 Bits + Zeit/Datum oder von den 14 Eingangs und Ausgangs Bits. Aber jemand der alle Eingangsbits(Wetter und Zeit) und die dazugehörigen Ausgangsbits postet fehlt noch immer. Genauso wie der, der selber generierte Daten in den Decoder schickt und schaut was rauskommt (ok, bis auf Dexter). Achja und ab und an kommt so ein Spaten wie Thilo M. vorbei, der wieder diesen Tollen Signalaufbau postet...
Hallo, ich hätte den Vorschlag, dass man nur die Wetterdaten EINES Standortes über mehrere Tage loggt und diese mit der Wettervorhersage vergleicht, dann könnte man schauen, was sich an den Ausgangsbits ändert, wenn man bekannte Eingaben hat. Zur Verschlüsselung: Ich glaube, dass hier das Datum mit drinhängt, das bedeutet, jeder Tag anderer Schlüssel und damit ganz schwer nachvollziehbar. Das könnte man mit dem täglichen loggen herausfinden. P.S. habe leider keinerlei Ausstattung mit der ich das machen kann, interessant finde ich es trotzdem.
Das beste wäre wirklich, wenn jemand mal so eine Uhr besorgen könnte, hat das inzwischen mal jemand geschafft? Wenn man den Chip direkt ansprechen kann, duerfte das Knacken tatsaechlich nicht mehr so schwer sein.. Ich glaube auch nicht, so wie manche vermutet haben, dass der eine stark eingeschraenkte Taktrate hat..
Wow, ich hatte mir nur mal "just for fun" so eine DCF77 Empfangsantenne gekauft ohne mir vorher gross gedanken drueber zu machen. Als ich dann das Protokoll bei wikipedia nachgelesen hab, bin ich auf die verschluesselte Wetterinfo aufmerksam geworden und bin nach einer Websuche dann hier gelandet. Ich habe nun in ueber 3h den gesamten Thread gelesen und muss sagen "Hut ab!". Ich werde jetzt erstmal nen uC an die Antenne haengen und ne Uhr bauen. Spaeter kann ich dann das ganze auch evtl. mal mitloggen und hierbei helfen.
Habt ihr vielleicht schon daran gedacht, das die Daten auf die 100ms bzw 200ms Sekunde Moduliert werden wie bei einem Radiosender? http://de.wikipedia.org/wiki/Amplitudenmodulation Vermutlich wird auf die 77.5kHz Trägerwelle das Nutzsignal Moduliert, da am Anfang schon erwähnt wurde, das die ersten 14 Bit Amplitudenmoduliert sind.
Hallo, DCF77 ist Amplitudenmoduliert, schon immer... Eine Trägerabsenkung bei den Sekundenimpulsen ist eine AM. Die Impulsfolge auch in den ersten 14 Sekunden muß eingehalten werden, sonst kommt keine übliche Funkuhr mehr klar. Gruß aus Berlin Michael
Die kodierte Zeitinformation wird wie bisher als Amplituden- und Phasenmodulation übertragen http://www.ptb.de/de/aktuelles/archiv/presseinfos/pi2006/pitext/pi061212.htm Lässt sich das mit der Phasenmodulation bewerkstelligen? Dabei würde die bisherigen AM-Empfänger nicht beeinflusst werden? http://de.wikipedia.org/wiki/Phasenmodulation Diese Technik befindet sich doch auch in den aus der Mode gekommenen Modems
Außerdem sieht der Wecker gar nicht mal so schlecht aus http://www.swisswetter.ch/mall/irox-mete-on-3.htm Das einzige was mich jedoch bei allen Funkweckern stört ist: Mit dem Funksignal wird die Uhrzeit, das Datum und der Wochentag gesendet. Ist es nicht möglich einen Funk-Wecker zu machen, den man einstellen kann das er nur von Montag bis Freitag um 06:00 Weckt und am Samstag und Sonntag nicht, ohne das jeden Freitag die Weckfunktion von Hand auszuschalten und Sonntag Abend wieder einzuschalten?
Gottfried S. wrote: > Ist es nicht möglich einen Funk-Wecker zu machen, den man einstellen > kann das er nur von Montag bis Freitag um 06:00 Weckt und am Samstag und > Sonntag nicht, ohne das jeden Freitag die Weckfunktion von Hand > auszuschalten und Sonntag Abend wieder einzuschalten? Gibt es zuhauf, meiner macht das z.B., man kann mehrere Weckzeiten programmieren und zu jeder die Tage festlegen.
Hab einen gefunden :) http://www.corner-shop.de/junghans/cgi-bin/junghans_deta.pl?refnr=150400100 Funktionen: Einzelalarm, Wochenalarm Mo-Fr Währe nett auch mit Wetterdaten alles in einem Gerät, aber man kann vermutlich nicht alles haben
@Gottfried: Ich glaube das mit der Phasenmodulation wurde bereits ausgeschlossen. Und wenn es denn Phasenmodulation waere, dann koennte man das doch nicht mit den normalen DCF77 Empfaengern empfangen, oder? Weil die geben das ja binaer aus.
Toller Krimi hier! Phasenmodulation kann auch binär sein, heißt dann PSK. Hier wird aber nur AM verwendet, damit der Empfänger möglichst billig wird. Für PSK braucht es einen sauberen und genauen Quarzoszillator. Da das Wetterprotokoll offensichtlich laut einer der Patentschriften: 1. zum Katastrophen-System kompatibel sein soll, und 2. das Katastrophen-Protokoll anscheinend erheblich einfacher strukturiert ist/war vermute ich eines der inaktiven Bits als simplen Unterscheider, welcher Art das übertragene Datenpaket ist. Eine 1-Bit Unterscheidung würde auch die sofortige Alarmierung ermöglichen. Das Wetterprotokoll zieht sich ja mindestens über 3 Minuten hinweg. Bleibt dran! Sollte doch mit eine paar Krypto-Experten leicht knackbar sein. In einen 1K PIC paßt selbst in Assembler nicht sonderlich viel Code rein. Wer hat eigentlich wie den genauen PIC-Typ herausgefunden? Gruß - Abdul
> Bleibt dran! Sollte doch mit eine paar Krypto-Experten leicht knackbar > sein. In einen 1K PIC paßt selbst in Assembler nicht sonderlich viel > Code rein. Mutige These... Ich glaube schon, dass man eine AES Entschlüsselung in 1k Code unterbringen könnte. Außerdem ist nicht gesagt, dass es exakt ein bestimmter und bekannter PIC ist, es kann auch ein ASIC auf Basis eines PIC sein. Es kann aber auch ein komplettes ASIC mit einem zufällig PIC ähnlichen Pinning sein. Ich baue zwar jede Art von Algorhythmus in C oder Assembler, aber Cryptographie ist leider (noch) nicht meine Stärke. Aber ich arbeite daran :) Gruß, Ulrich
Kann da nicht mal jemand eben den chip auf-ätzen und rein schauen was es ist? Eventuelle lock-bits lassen, sich wenn man den chip erstmal offen hat ja leicht entfernen.
Das mit dem Pic, dachte ich war ja bestätigt? Ich würde rückgekoppelte Schieberegister für recht wahrscheinlich halten, mit irgendwelchen Bits uas den letzten drei Zeitinfos als IV. Man bräuchte da ja in erster linie erstmal viele Datenblöcke und müsste die auch dekodiert vorliegen haben. Dann kann man ja mal schaun, ob da Auffälligkeiten drin sind. MfG Andreas
Obs ein PIC oder mir wegen ein ASIC basierend auf PIC ist, könnte man durch einen Programmer für PICs eingrenzen. Der sollte zumindest den PIC-Typ aktiv erkennen können wenn man das IC als PIC ranhängt. Hier sind die PIC-Experten gefragt. Kenne mich mit den Dingern nicht aus. Weiter oben wurde was von Fehlerkorrektur erwähnt. Das wurde ja gemessen. Effiziente Korrektur ist mit Turbo-Codes möglich. Aber auch da bin ich nicht Experte :-( Vielleicht sollte man nochmal mit dem Crypto-Tool experimentieren. Wieviel RAM hat der PIC? Er muß ja wohl mindestens 3 Minuten zwischenspeichern und dann noch Platz für die Berechnung haben. Und wenn man obigen Beobachtungen glauben darf, wird der Datenblock nach Bearbeitung als ganzes ausgegeben. Macht also nochmal Platz für einen kompletten Block. Stromverbrauch und Spannungsabhängigkeit können den Prozessor weiter eingrenzen. Gruß - Abdul
Finde das ja alles sehr interessant, Bloß wieso machen die dat nich kostenfrei? Naja, Ich hab an meinem Server nen DCF-Empfänger dran, isn Billigteil von Conrad, Darum is leider nicht alles in Ordnung was die Daten angeht, aber sollte reichen, da könnt ihr genug verschlüsselte Daten rausholen: http://thomy-pc.homeip.net/dcflogs.php?file=DCFLog00059.log Noch ein schönes Wochenende, gruß thomy_pc
Wow. Ordentliche Arbeit! Für eine harte Kryptoanalyse ist eine Fehlerrate von 93% allerdings wohl ziemlich knapp. Wer hat einen besseren Epmfänger für ihn? Auffallend sind die Schwankungen im Tastverhältnis einiger Bits im Wetterbitstrom. Entweder da wird eine Information übertragen, oder der Empänger hat Baselinewander-Probleme. Schön das es weitergeht. - Abdul
Naja, ein neuer Empfaenger sollte wohl nicht das Problem sein. Die gibts ja schon fuer 5 EUR. Aber so ein Problem mit der zuverlaessigkeit habe ich momentan auch. Ich habe in meinen Daten auch sehr viele Fehler drin und wenn ich z.B. den Loetkolben neben die Antenne halte, spielt das Ausgangssignal von dem Empfaenger verrueckt. Weiss da einer ob das am Empfaenger selbst liegt oder an irgendeiner fehlenden abschirmung? Die Verbindung vom Ausgangspin zum Mikrocontroller ist bereits so kurz wie moeglich.
Es würde helfen, wenn du die Art des Lötkolbens und ein Bild des Empfängers zeigen würdest. Eigentlich sollte einem guten Empfänger selbst das Geknackse eines alten Weller-Lötkolbens nichts ausmachen. Aber vielleicht wohnst du auch sehr weit weg vom Sender? Gibt übrigens gerade auch bei Pollin Empfänger mit digitalem Ausgang. Vermutlich die Standard-Billigschaltung. Man könnte natürlich auch einfach drei parallel betreiben und mehrheitlich entscheiden lassen... Oder den Empfänger abgesetzt betreiben. Im Dachstuhl des Hauses oder so. Mit Auswertung der Fehlerrate könnte man nahe Gewitter detektieren... - Abdul
> wenn ich z.B. den Loetkolben neben die Antenne halte, > spielt das Ausgangssignal von dem Empfaenger verrueckt. Na nimm Dir einfach mal ein Radio, daß Langwellenempfang zuläßt, dann hörst Du die Störungen etc. Es handelt sich um eine induktive Antenne mit Richtwirkung, die generell keine zu nahem Metallteile mag - die Antenne wird dadurch verstimmt. Pack dem Empfänger in ein Kunstoffgehäuse mit paar Meter abgeschirmtem Kabel dran, plaziere ihn weit weg vom allem Gerät und achte auf die Ausrichtung der Richtung FFM. Dann sollte der Empfang besser werden.
So siehts im Moment aus: http://img183.imageshack.us/img183/3884/dsc00781vb8.jpg Der Loetkolben hat 30W und ist von Bosbach und ich wohne ca. 250km vom Sender weg. Es ist der Empfaenger von Pollin. Wie muss ich die Antenne denn ausrichten? In Laengsrichtung zum Sender oder quer? Und besser stehend oder liegend?
senkrecht zur Längsachse sollte nach FFm zeigen .. bedenke, dein Steckbrett beinhaltet Metall als Verbindungsschienen .. sehr ungünstiger Antennenort! Du solltest die Antenne mit der dazugehörigen Platine in ein Plastikgehäuse ... s.o.
Ich habe bei einem Test des Pollin Teils einen fehlerfreien Empfang über einige Stunden gehabt. Richtig ausgerichtet muss allerdings schon sein, und ist vielleicht auch besser wenn ein paar cm drumherum nicht viel ist was Strom oder Magnetfeld leitet.
Das Display dürfte wegen dem Multiplexen auch recht bestialisch stören. Empfänger samt seiner Platine weiter weg stellen. Dazwischen einfach das dreipolige Kabel mit dem Digitalsignal. Idealerweise in einer abgeschirmten Audioleitung. Oder ein Koaxkabel mit Phantomspeisung. Das sollte helfen. Die Ferritantenne darf nicht senkrecht (nach oben) stehen, sondern waagerecht liegend! Frankfurt ist dann die Winkelstelle, an der die wenigsten Störungen detektiert werden. Es gibt davon auf dem Vollkreis immer zwei Stellen im Abstand von 180°, weil die Antenne symmetrisch ist. - Abdul
Gast wrote: > > Aber so ein Problem mit der zuverlaessigkeit habe ich momentan auch. Ich > habe in meinen Daten auch sehr viele Fehler drin und wenn ich z.B. den > Loetkolben neben die Antenne halte, spielt das Ausgangssignal von dem > Empfaenger verrueckt. > > Weiss da einer ob das am Empfaenger selbst liegt oder an irgendeiner > fehlenden abschirmung? Die Verbindung vom Ausgangspin zum > Mikrocontroller ist bereits so kurz wie moeglich. Hi, die Güte des DCF-Signals/Empfangs ist neben dem Empfänger von ganz vielen anderen Faktoren abhängig: -- Wetterlage -- Tageszeit (Sonnenstand) -- PC/Laptop in der Nähe (sollte > 2m sein) -- Monitor in der Nähe (Röhre, TFT, ... dito für den Abstand) -- nicht zu nahe an der Schaltung (µC, geMUXtex Display, ... > 30cm) -- Schaltung nicht mit einem Schaltnetzteil versorgen, sondern mit einem normalen Trafo. Bei einem SNT gibt's übelste und hartnäckige Störungen, die DCF unbrauchbar machen. Was das für Störungen sind, weiß ich net, zumindest scheinen sie nicht übern Äther zu kommen sondern über VCC. Entstörmassnahmen (Drosseln im Stromweg, LC-Filter, ...) erwiesen sich als nutzlos, das einzige was dann hilft ist dann Erdung der Schaltung. Zumindest sind das meine Erfahrungen mit DCF-Empfang. Ich nutze das 641138 vom Conrad in mehreren Uhr-Projekten.
>> http://thomy-pc.homeip.net/dcflogs.php Abdul K. wrote: > Wow. Ordentliche Arbeit! Für eine harte Kryptoanalyse ist eine > Fehlerrate von 93% allerdings wohl ziemlich knapp. 93% wurden korrekt empfangen :-) Eine Fehlerrate von 7% bedeutet bei 45 auswertbaren Bits eine Fehlerrate f_b von 0.16% Wenn man davon ausgeht, dass die Fehler unabhängig voneinander sind, hat man nämlich
Sind die Wetter-Bits von der gleichen Fehlerrate betroffen, dann sind in den "korrekten" Datensätzen 2.3% der Wetterblöcke unwissentlich falsch empfangen worden. Ich hab auch mal n bisschen mitgeloggt, formatiert als C-Initializer http://www.gjlay.de/dcf_2008-05-18.txt Fehlerhafte Datensätze (0:26, 3:37, 3:43) sind nicht dargestellt. Die dargestellten Datensätze sind geprüft auf -- Parity -- Bitlängen -- Konsistenz Grüß, Georg-Johann p.s. Die dritte Zahl im Initializer stellt die unteren 16 Bits dar, das zweite Element sind die DCF-Bits (Bit 0 zuerst).
Hi, ich hab es jetzt geschafft das Signal deutlich zu verbessern. Meine Uhr laeuft nun schon seit >18 h und das ohne einen einzigen Bitfehler. Demnaechst werde ich dann noch eine Schnittstelle zum PC implementieren und dann kann ich auch mit logs dienen. :) Ich habe grade allerdings auf der Homepage der PTB noch was gefunden was eine Frage aufgeworfen hat: "Die Wahrscheinlichkeit dafür, Schaltsekunden auslassen zu müssen, ist gering, die technischen Einrichtungen am Sender lassen es jedoch zu." Quelle: http://www.ptb.de/de/org/4/44/442/dcf_kode.htm (unten) Was meinen die mit Schaltsekunden auslassen? Gruss
Hallo, > "Die Wahrscheinlichkeit dafür, Schaltsekunden auslassen zu müssen, ist > gering, die technischen Einrichtungen am Sender lassen es jedoch zu." > Quelle: http://www.ptb.de/de/org/4/44/442/dcf_kode.htm (unten) > > Was meinen die mit Schaltsekunden auslassen? Da das Jahr eben nicht genau 365 Tage lang ist, wird nötigenfalls die letzte Stunde des 30.6. oder 31.12. um 1s auf 61s "gestreckt" -- dann hat das DCF77-Signal 59 Bits! Dies wird während der Stunde, an deren Ende es passieren wird, mit dem "Ankündigungsbit" angekündigt. Das PTB kann solche Schaltsekunden also scheinbar auch "weglassen". Gruß Fred
Fein! Vermutlich hast du aber keine Information darüber, ob in den ersten 14/15 Bits ein Fehler auftrat?? Deine Aussage bezieht sich wohl nur auf die Prüfbits im originalen Zeit-Btstring. Bezüglich deines Zitats der PTB zu Schaltsekunden: Diesen Aspekt hatte ich bislang auch nicht wahrgenommen. Stimmt, da kann ja mal eine Minute länger als 60 Sekunden sein! Da die Schalterei mit den per se vorlaufenden Bahnhofsuhren kompatibel sein muß, würde ich sagen es ist so zu interpretieren: Diese Minute wird einfach eine Sekunde länger. Die normalerweise letzte (59.) Sekunde wird NICHT ausgesetzt, dagegen in der nachfolgenden zusätzlichen Sekunde WIRD der Puls ausgesetzt. Sollte noch mal jemand anderer verifizieren. Ob das so wirklich jeder Chinawecker verkraftet? Mir kommt da gerade so ein ungutes Gefühl auf. Wann ist die nächste Schaltsekunde angedacht? Oder du fragst die PTB mal an. Darüber werden sie sicher Auskunft geben. Eine andere Frage ist auch, wie die Bevölkerungswarnungen im Datenstrom untergebracht werden sollen: 1. Durch Unterscheidung z.B. anhand es ersten Bits einer Minute, oder 2. Durch freie Bitstring-Kombinationen in den Meteodaten. Also Bitstrings, die von der Meteo-Codierung nicht ausgenutzt werden. Man sollte also mal die Meteo-Bits dahingehend untersuchen, ob irgendwelche Kombinationen niemals auftreten, oder besser gleich welche Bitkombinationen wie oft auftreten. Gruß - Abdul
> Was meinen die mit Schaltsekunden auslassen? > Ich nehme an, Du weiß, daß all n Jahre ein Jahr um eine Sekunde verlängert werden muss. (/ genaues findest DU auch bei der PTB ) Diese "Schaltsekunde" wird angekündigt und gesendet. Und nun KANN es halt passieren, daß dies Info ausfallen muss bzw kann. Das ist damit gemeint ist ja auch nicht so schlimm, denn nach spätestens einer Minute( Wenn Dein Programm jede Minute auswertet ) bist DU ja wieder auf dem Laufenden Hanns
Erklärt aber nicht, wieso eine Schaltsekunde "ausfallen" kann. Ich könnte mir ein möglichen Grund vorstellen: Die Verbindung zwischen Braunschweig und dem Sender in Mainflingen ist irgendwie gerade gestört. Vielleicht sind die Atomuhren in Mainflingen nicht zur Erkennung einer Schaltsekunde in der Lage und die Sender-Steuerung bekommt diese Info offline aus Braunschweig irgendwann rechtzeitig vorher und "webt" das dann ins Nutzsignal ein. Übrigens gibt es bei der PTB ein Dokument, wo die Verlängerung der Minute genau so beschrieben ist, wie ich es oben vorstellte. War also meine Vermutung richtig. Gruß - Abdul
"Fein! Vermutlich hast du aber keine Information darüber, ob in den ersten 14/15 Bits ein Fehler auftrat?? Deine Aussage bezieht sich wohl nur auf die Prüfbits im originalen Zeit-Btstring." Doch, die habe ich. Bei meiner Uhr laeuft das so: Jeder Puls wird auf seine Laenge geprueft. Mein Empfaenger hat da leichte Abweichungen aber die kurzen Pulse kommen bei 1Mhz auf einen Zaehlerstand von etwa 93 +- 3 (mit vorteiler 1024) und die langen auf 190 +-3. Also etwa 93 und 190 ms. Ich habe da die Toleranzen eng gesetzt, sodass alles mit einer Laenge von 83-103 als 0 erkannt wird und alles von 180-200 als 1. Kommt ein Puls mit einer anderen Laenge an gibt das Programm den Wert 2 zurueck. Die Fehlererkennung basiert alleine darauf zu pruefen ob in den Daten eine 2 drin ist. So wird jedes Bit getestet. Das einzige was dabei passieren koennte ist das ein kurzer Puls zufaellig in die 180-200 faellt oder ein langer aus irgendeinem Grund kuerzer wird und in die 83-103 faellt. Allerdings finde ich das die wahrscheinlichkeit doch sehr gering waere. Und da die Uhr schon seit ueber 20 Stunden laeuft und noch nicht ein einziger Fehler aufgetaucht ist, kann ich mit an Sicherheit grenzender Wahrscheinlichkeit sagen das alles richtig lief.
Ah, ich dachte du hast eine billige Biterkennung. Bei deiner Methode sieht die Sache besser aus. Die Prifbits benutzt du gar nicht? Allerdings ist die Aussage, es wäre in den 20 Stunde noch nie zu einem Fehler gekommen, mit Vorsicht zu genießen: 1. Entweder es war so wirklich, oder 2. Deine Fehlererkennung funzt nicht. Ich zweifele nicht an deinen Fähigkeiten. Wollte es nur erwähnen. Vielleicht einfach mai einen eigenen DCF77-Bitstring generieren und einspeisen. Man weiß ja nie. In der Schweiz sollen übrigens die gleichen Meteo-Daten über den Äther gehen. Stimmt das? Nebenbei: Hat mich doch wirklich erstaunlicherweise zwei Tage Arbeit gekostet, mir einen DCF77-Empfänger zu basteln mit dem ich dann meinen Referenzquarz für den angedachten Frequenzzähler ziehen möchte. Allerdings wohne ich auch 500km vom Sender entfernt. - Abdul
Sagt mal, da ist was, was mir ganz gewaltig zum Hals raus hängt: Wer bezahlt letztlich die PTB und ihren Funknippel? Richtig. Der Steuerzahler. Und welche gottverdammte Drecksfirma verdient nun mit irgendwelchen verfluchten Lizenzen ihr Geld? Sorry, aber sowas stinkt doch zum Himmel?!
Nene, die Lizenz ist beim Schweizer Wetterdienst. http://www.meteotime.com/web/ Der benutzt die ersten 14 Bit für seine Informationen und verkauft Lizenzen an Die Hersteller der Wetterstationen. Die Gebühr für die Nutzung der ersten 14 Bit geht an die PTB und entlastet somit den Steuerzahler.
Nein, die Pruefbits verwende ich (noch) nicht. Das werde ich aber noch implementieren um noch sicherer zu sein. Die Schaltung und der Code ist zu 95% jetzt am Wochenende entstanden, daher noch nicht ganz vollstaendig. Die Fehlererkennung funktioniert ;) Ich habs schon getestet indem ich mal was metallisches neben die Antenne gehalten hab. Da ich noch eine LED dran habe die die Pulse optisch darstellt habe ich auch eindeutig den Fehler gesehen den die Zange erzeugt hat und der wurde dann auch gezaehlt.
Thilo M. wrote: > Nene, die Lizenz ist beim Schweizer Wetterdienst. > Der benutzt die ersten 14 Bit für seine Informationen und verkauft > Lizenzen an Die Hersteller der Wetterstationen. > Die Gebühr für die Nutzung der ersten 14 Bit geht an die PTB und > entlastet somit den Steuerzahler. War mal wieder vorschnell... hab nix gesagt^^ Aber warum zum Geier müssen die dann immer noch verschlüsselt sein? Ich mein, so nen toller Code, dass die Verschlüsselung Lizenzen nötig macht, kann es wohl net sein.
Sven Pauli wrote: > Thilo M. wrote: >> Nene, die Lizenz ist beim Schweizer Wetterdienst. >> Der benutzt die ersten 14 Bit für seine Informationen und verkauft >> Lizenzen an Die Hersteller der Wetterstationen. >> Die Gebühr für die Nutzung der ersten 14 Bit geht an die PTB und >> entlastet somit den Steuerzahler. > > War mal wieder vorschnell... hab nix gesagt^^ Aber warum zum Geier > müssen die dann immer noch verschlüsselt sein? Ich mein, so nen toller > Code, dass die Verschlüsselung Lizenzen nötig macht, kann es wohl net > sein. Naja, überall wo man Geld verdienen kann, kann der Schlüssel nicht gut genug sein! Ich habe daran auch sehr großes Interesse (Solarthermische Anlage mit 'vorausschauender' Steuerung).
Vielleicht sollte man ein Preisgeld für das Knacken aussetzen. Wäre auch was für den rührigen CCC. Ich denke solange das zumindest vereinzelte Interesse nicht nachläßt, wird wohl auch die Verschlüsselung bald geknackt werden. Darf man sowas überhaupt knacken oder ist das hier bereits die Aufforderung zu ungesetzmäßigen Handeln? Vielleicht hat es auch schon jemand geschafft und er hat entwder Angst es zu veröffentlichen bzw. möchte daraus ein eigenes Geschäftsmodell entwickeln. Es fällt zumindest auf, das einige der früheren Poster sich nicht mehr dazu melden. Gruß - Abdul
Naja, wenn daraus einer ein 'Geschäftsmodell' ohne Lizenz macht, ist es mit Sicherheit strafbar. Aber nur des Knackens wegen, ohne daraus Profit zu schlagen, dürfte kein Problem sein. ;) Leider fehlt mir die Zeit und die Kenntnis über Verschlüsselungstechniken um mich intensiv damit zu beschäftigen. :(
Hm Thilo - Das war aber jetzt ne Ansage: Zu denken es wird kein Problem sein und dann zu behaupten, du kannst es nicht. Ich leider auch nicht :-() Man sollte ein paar Leute der Kryptoanalyse auf diesen Thread hier aufmerksam machen. Vielleicht würde der eine oder andere derer nur kurz Lachen und dann posten. Mathematica ist auch nicht schlecht für DES-Schlüssel auseinanderzunehmen. Ich bin aber eher Hardwaremensch und versteh nicht viel davon. OK, ich gebs zu. Einmal habe ich auch einen Code geknackt. Der Hersteller meinte, sein Dongle wäre nicht knackbar. Das reizte mich... Meteodaten ist halte ne nette Spielerei. Ich vermute, der Vertrag wird nicht verlängert und die Bits werden in ein paar Jahren neue Beätigungsfelder suchen... Gruß - Abdul
>Das war aber jetzt ne Ansage: Zu denken es wird kein Problem sein und >dann zu behaupten, du kannst es nicht. Ich meinte, es wäre wohl rechtlich kein Problem, sachlich steht auf 'nem anderen Blatt ...
Abdul K. wrote: > Man sollte ein paar Leute der Kryptoanalyse auf diesen Thread hier > aufmerksam machen. Vielleicht würde der eine oder andere derer nur kurz > Lachen und dann posten. Ich würd mein Boppes verwetten, dass es keiner schafft, den Wetter-Code zu knacken. Hier sind zwar sehr viel Leute mit hellem Oberstübchen unterwegs, aber ohne Idee, was da abgeht, hat man einfach keine Chance. Und selbst wenn...
Georg-johann L. wrote: > Abdul K. wrote: >> Man sollte ein paar Leute der Kryptoanalyse auf diesen Thread hier >> aufmerksam machen. Vielleicht würde der eine oder andere derer nur kurz >> Lachen und dann posten. > > Ich würd mein Boppes verwetten, dass es keiner schafft, den Wetter-Code > zu knacken. > > Hier sind zwar sehr viel Leute mit hellem Oberstübchen unterwegs, aber > ohne Idee, was da abgeht, hat man einfach keine Chance. Und selbst > wenn... Jupp, wie ich oben shcon schrieb, die Sicherheit eines Cryptosystms basiert nicht auf der Geheimhaltung des Verfahrens. Und wenn die nicht doof sind (was ich mal nicht vermute die wollen ja Geld dafür) dann hat man auch mit "loggen" keine Chance.
Läubi Mail@laeubi.de wrote: > Jupp, wie ich oben shcon schrieb, die Sicherheit eines Cryptosystms > basiert nicht auf der Geheimhaltung des Verfahrens. Es sollte nicht davon abhängen. Nicht selten tut es das aber.
Das ist doch eine gute Anwendung von Verschlüsselung. Da steckt gerade soviel Geld drin, dass es sich eben nicht lohnt den originalen Chip zu sezieren...
Solange man es nicht probiert, weiß man recht wenig! Gut, man kann warten bis andere zuerst Entdeckerfreuden haben... Vielleicht wäre die Sezierung des Chips ein guter Schritt. Heiße 95% Schwefelsäure oder Salpetersäure reichen zur Entfernung des Kunststoffs. Danach unters Mikroskop. Die meisten Hersteller haben Logos drauf. Den vermuteten Chip nachkaufen und auch diesen behandeln und dann vergleichen. Sehen wir mal von Revisionen des Chipdesigns ab, ist der Chip damit gut eingekreist. Aber hatte nicht irgendwo oben jemand bereits was von PIC erzählt? Ich würde momentan auf einen stinknormalen PIC setzen: Ist billig, weit verbreitet, reicht vermutlich technisch völlig aus. Das war der Hardware-Ansatz. Die Kryptofreaks sollten sich die Logs vornehmen... - Abdul
ich werde im nächsten semester mal einen meiner prof´s zum thema interviewen .....sonst hab ich für so spielchen grade leider keine zeit ...
> Das war der Hardware-Ansatz. > ...Naja, Das das ein PIC ist schon klar. Aber da war doch mal was mit Protect-Bits löschen direkt auf dem Chip. Dafür wird Ausrüstung einer Preisklasse benötigt für die im Nutzen für den Angreifer nicht genug Geld steckt.
Was wäre denn, wenn man den Original Chip blind mit Daten füttert und das Ergebnis aufzeichnet. Wenn ich das richtig gesehen habe gehts ja um 14 Bit. D.h. man hat 2^14 Möglichkeiten (16384) So hat man zu jedem Eingangs- ein Ausgangsmuster...
Nicht ganz... Es sind 3x 14 Bit. Jede Minute wird nur ein drittel übertragen, für mehr ist einfach kein Platz. Das heisst in der Summe sind es 42 Bit. Dazu kam noch, dass oben jemand gepostet hat, dass der Chip nur in gewissen Zeitabständen überhaupt arbeitet. Das Intervall weiß ich jetzt grad allerdings nicht mehr aus dem Kopf. Ansonsten kommt einfach keine Antwort. Wahrscheinlich um genau solchem rumprobieren vorzubeugen.
Andreas wrote:
> Das heisst in der Summe sind es 42 Bit.
Der Decoder bekommt nicht nur jeweils die ersten 14 Bit, sondern den
kompletten Datenstrom des DCF77-Signals und es steht die Vermutung im
Raum, daß er aus den Zeit-Bits jeweils den Schlüssel für die Wetterdaten
berechnet.
Das wurde aber alles weiter oben im Thread schon ausführlich diskutiert.
Reinhard Max wrote: > Andreas wrote: >> Das heisst in der Summe sind es 42 Bit. > > Der Decoder bekommt nicht nur jeweils die ersten 14 Bit, sondern den > kompletten Datenstrom des DCF77-Signals selbst mit "nur" 42 bit bräuchte man dann eine Tabelle mit 512GB um alle ein/ausgabe kombinationen zu speichern. Und wie gesagt ich hätte es so gemacht: Die Zeit ist der Initialisierungsvektor (darf ja bekannt sein) und schon purzelt da nur zufälliges aus dem Encoder --> no chance. Und das werden dir auch die "crypto freaks" sagen, die haben das nämlich erfunden ^_^
Also ich denke nicht das es so kompliziert wird. Man muesste sich mal so eine Uhr mit diesem Chip kaufen und die Ein- und Ausgabe davon loggen. Soweit ich mich errinnern kann steht hier Thread was davon das nur 42 bit reingehen. Also schonmal keine zusaetzliche Zeit die als Schluessel dienen kann. Aber das laesst sich ja mit einem Oszi auch nochmal testen. Das die Zeit als Schluessel dient faellt auch aus dem Grund raus das die Wetterdaten fuer eine Region immer zur gleichen Zeit gesendet werden. Wenn man nun die Eingabe in den Chip mitloggt, und auch ein log vom DCF signal hat dann kann man also rausfinden zu welcher Zeit der Bitstring der da reingeht uebertragen wurde. Man weiss somit wann die Daten zur eingestellten Region gesendet wurden. Aussserdem hat man massig Ein- und Ausgabedaten womit die crypto leute doch was anfangen koennen sollten. Ein wechselnder Schluessel wurde ja auch bereits ausgeschlossen weil ausgeschaltete Uhren den ja dann nicht mitbekommen wuerden. Die Art des Chips ist damit eigentlich voellig egal.
Sorry Gast, Das simple Loggen von Ein und Ausgabe wäre naiv. Du könntest zb einfach die 14 Bits mit denen der ersten 14 Bit der Zeitinformationen XOR erknüpfen und schon sehen die 14 Eingabe und 14 Ausgabebits schön chaotisch aus. Dieses XOR wäre natürlicht trotzdem leicht knackbar und dient hier nur als Beispiel. Die c't hatte doch letztens einen Artikel in dem gezeigt wurde wie sie RFID Karten geknackt haben Karte in Säure aufgelöst, dann Schicht für Schicht die Metallayer wegpoliert und mit einem guten Mikroskop + Digicam hochaflösende Fotos gemacht und so dann den Schaltplan rekonstruiert. Bei elektrischen Ladungen (Flash) müsste man sicherlich anders vorgehen da man die wohl nicht unter einem Mikroskop "sehen" kann.
http://www.hkw-elektronik.de/pdfdeutsch/DB%20W-Protokoll-V%201.pdf hilft das evtl weiter oder schon bekannt? vermute ich mal...
Soweit ich das verfolgt habe, waren ja die Zeitdaten durchaus Teil des Systems, also quasi der IV. Ich würde jetzt mal empfehlen, so rund 64 Testmuster mit bekanntem Plaintext zu nehmen und da mal alle Bits in den Zeitdaten zu toggeln, eins nach dem anderen. Wenn der Chip das bei keinem der COdes merkt, dan ist das Bit vermutlich garnicht verwendet. Persönlich vermute ich, dass das wohl rückgekopplte Schieberegister, implementiert auf dem PIC sind. Einfach und vergleichsweise effektiv. GSM verwendet das ja z.B. auch. MfG Andreas
Also mal ehrlich: Dieses Datenblatt beschreibt - Wetterdatenprotokoll, Datenblock 1, Datenblock 2, Datenblock 3, ... ... kann auch bedeuten, das es mehr als 3 Blöcke benötigen kann. Mal etwas anderes, wie würdet ihr verfahren wenn ihr so eine Verschlüsselung von Daten machen müsstet? Ich würde es folgendermaßen bewerkstelligen wenn wenig Ressourcen zur Verfügung stehen und dennoch einen "relativ" sicher die Daten schütze. 1. Die Daten werden in Blöcke geteilt mit einigen Bits als Erkennung um welchen Datenblock es handelt. 2. Beim Senden der Daten auch sinnlos generierte Daten zwischen den Blöcken schieben 3. Transposition der gesendeten Datenblöcke - Block 4, Nichtsbedeutend, Block 1, Nichtsbedeutend, Nichtsbedeutend, Block 3 ... 4. Transposition der gesendeten Bits 5. Prüfsumme ob die Daten richtig angekommen sind 6. Sind alle Daten eingelangt, so wird eine Zeit abgewartet - wer würde daran denken, das die Daten die gerade aus dem Chip kommen schon vor "Stunden" empfangen wurden?
7. Eine vereinfachte Darstellung der Auswertung um diejenigen, die zu entschlüsseln versuchen in die Irre zu leiten
Wenn ich etwas mit so wenig Bits verschlüsseln müßte, dann würde ich zeitliche Verschiebungen in Betracht ziehen. Lohnt es sich bei der grobgliedrigen Wettervorhersage überhaupt dafür einen Euro auszugeben? Da ist doch jeder Blick aus dem Fenster genauer.
Oszi40 wrote: > Lohnt es sich bei der grobgliedrigen Wettervorhersage überhaupt dafür > einen Euro auszugeben? Da ist doch jeder Blick aus dem Fenster genauer. Wenn du uns noch erzählst, wie du dem µC beigebracht hast, aus dem Fenster zu sehen und das Wetter zu erkennen, dann bist du der Held. Gruß Rolf
Gottfried S. wrote: > Mal etwas anderes, wie würdet ihr verfahren wenn ihr so eine > Verschlüsselung von Daten machen müsstet? ---- 1. Mit einem simplen Algoritmus wie etwa quisci verschlüsseln. Als Schlüssel dienen ein fest einprogrammierter Schlüssel (evtl aus einer Schlüsseltabelle) sowie die Zeit 2. Zu jedem Datensatz einen Fehlerkorrektur-Code erstellen. Das kann sinnvollerweise nur auf den verschlüsselten Daten gemacht werden 3. Den Datensatz in 3 Happen zerlegen 4. Bits permutieren ---- 2. und 3. können natürlich auch vertauscht werden Unsinnige Daten würde ich keine einstreuen, weil ich ja der Krypto-Held bin und die Bandbreite nicht so berauschend ist. 4. würde ich mir wahrscheinlich sparen (aus gleichem Grund, zudem bringt's nicht wirklich zusätzliche Sicherheit).
Guten Abend, nachdem ich diesen Thread mehr oder weniger komplett durchgelesen habe, muss ich sagen: hut ab, es scheint doch noch angagierte Reverse engenieure zu geben. Ich selber hatte bis jetzt nicht die zeit und die nötigen Gerätschaften um mich selber mal aktiv mit der Materia auseinander zu setzen. Doch das hat sich heute geändert. Ich habe soeben meinen Wecker "TFA meteotronic star"bekommen, und direkt zerlegt, wer detailfotos haben will kann mich ansprechen, wobei hier eingentlich schon alles sehr gut beschrieben ist, ich konnte alles bezüglich verschaltung und aufbau verifizieren.Generell würde mich mal interessieren, ob dieser thread nur etwas eingeschlafen ist, oder ob ihr alle die offnung verloren habt? Ich selber bin noch bis hinter beide Ohren motiviert, wobei es mir wirklich um den Sportlichen Ehrgeiz geht.....
Hallo Thorsten - Wohl etwas eingeschlafen, aber es lesen noch genug mit. Wirst du den PIC mit manipulierten Daten füttern und schauen was er draus macht? Oder was hast du dir vorgestellt? Gruß - Abdul
Bis jetz habe ich nur ein paar ideen gesammelt und werde mal schaun, was sich davon umsetzen lässt: zunächstmal wollte ich den pic ein wenig bei der Arbeit beobachten, obwohl das hier eigentlich auch schon hinreichen dokumentiert ist. Dabei wollte ich mir mal Gedanken darüber machen, mit welchen neuen Ansätze zum Thema Reverseengeneering mann evtl was ausrichten könnte(Nein ich will nichts neu erfinden, nur Sachen probieren, die hier noch ausser 8 blieben); Aber da muss ich mich auch noch ein bisschen mehr einarbeiten. Ein Zweiter Ansatz wäre es mal einen separaten µC zu bemühen, der sowohl den Dateneingang, als auch die Ausgabe des Dechiffrier IC überwacht. Meine vision sag, dass er beides separat mitloggen soll, und z.b. auf einer SD karte speichern. Der Ganze aufbau kommt dann an einen Ort meiner Wahl mit geeigneten Empfangsbedingungen. Das würde meiner Meinung nach eine wirkliche Effektive Langzeitbeobachtung ermöglichen. Dazu muss ich aber sagen, dass ich eigentlich auch noch andere hobbies habe, und sich das ganze daher wohl noch etwas hinziehen, bzw einfrieren, wird. Die dritte und letzte Möglichkeit für mich wird es sein, den Versuch zu unternehmen ein geeignetes Interface zu entwerfen, welches es einfach macht den IC mit beliebigen Daten zu füttern, und seine Ausgabe auszulesen. Diesen Aufabau werde ich dann einem guten(freund und kryptologen) zum speiel geben : ) Gesetz dem Falle, dass keine der erwähnten Methoden fruchtet, werfe ich den komischen Wecker aus dem Fenster...
Och, zum Rauswerfen ist es noch zu früh und sicherlich würdest du auch einen Abnehmer finden. Eher geht er durch die Bastelei in die ewigen Elektronengründe. Dein Freund ist Kryptoanalytiker? Wenn er dann auch von der praktischen Fraktion ist, wäre das interessant. In den PIC (wenn er denn richtig identifiziert wurde) paßt nur 1KByte ROM und die paar Byte RAM lassen eine große Verzögerung auch nicht zu. Außerdem ist der Hersteller des ICs keine High-Tech Schmiede. Ist die Frage, ob sie den Auftrag für diese Software selber friemelten oder an einen "Experten?" rausgaben... Es klingt so, als hättest du schwierige Empfangsbedingungen?? Darf man fragen wie weit weg du von Mainflingen wohnst? Daß die Antenne richtig ausgerichtet werden muß und keine Bildröhre in 1-2 Meter Abstand sein darf, weißt du schon? Ich kenne deinen Wecker nicht. Vermute aber er hat ne Ferritantenne wie alle anderen auch. 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. Gruß - Abdul
Man könnte von dem Encoderchip das Die freilegen und mitm Mikroskop den Schaltplan ausfindig machen. (So ähnlich mit mit der Mifare Karte in der c't)
Man könnte von dem Encoderchip das Die freilegen und mitm Mikroskop den Schaltplan ausfindig machen. (So ähnlich wie mit der Mifare Karte in der c't)
Das Die kann man untersuchen, das Programm wirst du so jedenfalls nicht ohne weiteres rauslesen können. Seit vielen Jahren legen die Chiphersteller genau dafür extra Aluminiumlagen über den Flash-Bereich. Eine elektrostatische Abtastung ist dadurch unmöglich. Man müßte das Die abtragen. Außerdem müßtest du aufwändig rauskriegen, welcher Platz im Flash wo auf dem Die zuzuordnen ist. Ist sicherlich letztendlich machbar und es gibt dafür auch einschlägige Firmen, aber das wird beyond this group sein. Zur Mifare Karte kann ich wenig sagen. Das war wohl eine hardcodierte simple Karte mit einem inneren Drahtlayout. Gruß - Abdul
aber weiso nicht einfach das die freilegen, lockbits löschen(UV o.ä.), auslesen und ab in den disassembler?
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.
Hier meldet sich mal Iranian from Hell aus dem schönen Libanon ... Wenn jemand einige Datensätze vor und die korrespondierenden Datensätze nach der Entschlüsselung loggen könnte wäre die Sache sehr einfach. Habe hier 4 Tesla-karten mit 530 Gigaflops pro Stück, die sogar MD5 Hashes in maximal 24Stunden knacken können, für die herkömmliche Rechner 1 oder 2 Jahre bräuchten. Die distributed Engine auf CUDA basis würde ich dann natürlich implementieren ... falls jemand auch noch schnelle Rechner hat mit entweder Tesla oder zumindest mit ner neueren NVIDIA karte könnte man sich die Arbeit dann aufteilen!
zwei kurze Hinweise zum PIC: 03ff 0c04 movlw 0x04 d.h. Reset-Vektor auf 0x3ff passt zum 12F509 und nicht zum 12F508 ansonsten wäre das Wort auf 0x1ff lesbar, was es aber nicht ist. Ich bin beim Auslesen nicht auf 0000 0ff6 xorlw 0xf6 gekommen sondern auf 0000 0a60 was einfach ein Sprung über die ausgelesene Routine in den nicht lesbaren Bereich wäre. Zum Code: Der auslesbare Teil ist doch zunächst ein rückgekoppeltes Schieberegister mit 80 bit. Von diesem wird in jedem Schritt ein Bit neue generiert und wieder rückgekoppelt. D.h. möglicherweise äussere Schleife mit 64 Durchläufen { 4 Schritte Schieberegister XOR Verknüpfung Bank0 ^ Bank1 -> Bank1 unbekannter Code } Zur Ausführungszeit: ich komme auf 3*(45+1)+45=183 Zyklen Dazu kämen noch ~40 für die äussere Schleife Damit sollte das ganze etwa 14ms dauern (1Zyklus -> 1 Mikrosekunde). Zu den verwendeten Eingangsdaten: das Ergebnis hängt nur exakt von den 82 Eingangsbits (42 bit Wetterdaten + 40 bit Datum/Uhrzeit) ab. Bei den Wetterdaten sind 2 konstant auf 0, damit bleiben 80 bit Eingangsdaten. Vorhergehende Daten spielen keine Rolle. Zum PIC Auslesen: Falls die 50mV sich auf den Report von Skorobogatov beziehen: da ging es um den 16F84A. Das ist wohl leider nicht direkt übertragbar. Zumindest habe ich bisher nur gesehen, dass Code und Code Protection völlig synchron gelöscht werden und der Code Speicher viel früher leer ist. Wenn man den Vorgang vorzeitig abbricht, ist immer zuerst der Code Speicher leer. Das heisst allerdings nicht, dass danach keine auswertbare Information mehr vorhanden ist. Wer sich da genauer mit beschäftigen möchte, kann ja mal nach Data Remanence suchen. Zum WDT: Da das IC erst nachdem es schon >30s nach dem letzten Reset gelaufen ist, wirklich bereit ist sinnvolle Ausgangsdaten zu liefern, kann man wohl davon ausgehen, dass der WDT Timer genutzt wird um diese 'Anlaufsperre' zu realisieren. Die gleiche Sperre greift, wenn Daten decodiert worden sind. Sonst könnte ja jemand auf die Idee kommen, einfach mal viele verschiedene Eingangsdaten nacheinander durchzuprobieren.
@Iranian: Die Datensätze findest du weiter oben. Sind allerdings wohl nicht 100% fehlerfrei! Deine Infrastruktur klingt interesssant! Du kannst damit auch loslegen, wenn du nicht den Schlüsselalgorithmus kennst? Wie sieht dann das Ergebnis aus?
Abdul: Mit sicherheit werde ich dann bekanntes einbauen, aber theoretisch würde es auch ohne Informationen gehen! Diese Karten können mehrere Billionen Vergleiche pro Sekunde machen, sind eben "High Performance Computing" Karten ... Über kurz oder lang findet man schon die richtige Verknüofung aus Binären operationen. Komplizierteres wie PGP kann man bei nem PIC ja wohl ausschliessen. Leider haben die Logs von oben nur die verschlüsselte information. Notwendig wäre die Wetterstation so mitzuloggen dass man die Daten auch in unverschlüsselter form hätte. Ein kinderspiel dann die Maske zu berechnen, egal wie oft da subtrahiert wird. Ich persönlich tippe ein 1 Sekunde rechenzeit mit den Teslakarten :)
Sollte der Xor richtig sein, und der WDT genutzt werden, dann kann das testen durch externen Reset beschleunigt werden.
Abdul: Habe mal einen Test gemacht: Hab ein 85bit wort genommen und konsequent alles möglichen xor/and/or/shift/etc operationen in abhängigkeit von konstanten im rahmen 0-32 sowie in abhängigkeit von den anderen bits gemacht (also jedem einzelnen bit sowie allen möglichen binären verknüpfungen von zwei oder mehreren bits) Das dann in einer Rekursionstiefe von 100. Die Karten haben exakt 1,2 Sekunden gebraucht :) d.h. ich habe alle möglichen Verschlüsselungsvarianten des 85bit wortes in abhängigkeit jeder kombination der 85bits sowie allen konstanten von 0 bis 32 in nur 1,2 Sekunden berechnet ... Machen wir das für 4-5 Datensätze so können wir sehr schnell rausfinden wie genau gexort etc. pp. wird!
@Iranian: Du scheint neu mitzulesen. Leider ist man allein mit Lesen des Threads locker ne Stunde beschäftigt. Eine Zusammenfassung findest du hier: http://www.mikrocontroller.net/articles/DCF77_Wetterinformationen Die Mitschnittdaten hier sollten wohl gehen: Beitrag "Re: AVR: Wetterinformationen über DCF77" Es gibt wohl von verschiedenen Autoren Sätze! Kannst du zu deiner Hardware mehr sagen? Könnte mir vorstellen, daß man die für viele Dinge gut gebrauchen könnte. Auf jeden Fall sehr interessant. Alles natürlich rein akademisch. Ob du deine Sekunde halten kannst, wage ich zu bezweifeln! Ich warte schon mal die einstweilige Verfügung gegen Mikrocontroller.net am Montag ab... Also den Thread mit allen Daten vorher downloaden! Gruß - Abdul
@Iranian: Ich bin leider nicht so das Mathematik-Genie. Kann daher deinen Angaben nur schwer folgen. Auch wenn ich mal erfolgreich einen vom Hersteller als unknackbar angepriesenen und mit Preisgeld ausgeschriebenen 'USB'-Stick geknackt habe. Das ist allerdings verjährt, sonst hätte ich es jetzt nicht geschrieben :-) Meine Stärke ist Hardware digital und analog von DC bis HF, und unorthodoxe Denke. Mich würde ja mal brennend interessieren, was du so täglich machst. Klingt ja sehr geheimnisvoll und viel interessanter als das Fernsehprogramm. Werde jetzt aber erstmal ne Kuchenpause einlegen. Habe auch noch andere Baustellen. Auch interessante ;-) Vielleicht bist du ja der Mann, auf den hier alle warteten. Wir brauchen einen richtigen Kryptofreak! Gruß - Abdul
Abdul: Klingt jetzt vielleicht ein bisschen behämmert, aber beruflich arbeite ich auf einem Fischkutter .... Mit dem ganzen Kryptographie-Gedöns bin ich auch nicht wirklich vertraut, ich weiss nur dass die High Performance Computing Karten in der lage sind binnen Sekunden alle möglichen Verschlüsselungsmöglichkeiten die auf Binären Operationen beruhen und nur von den ca 100 bits sowie konstanten werten im 32bit bereich zu berechnen...und das mehrere hundert mal wiederholt auf sich selbst angewendet. Sprich: wenn wir einen datensatz (vorher/nachher) haben haben wir vielleicht mehrere huntert tausend möglichkeiten von unverschlüsselt nach verschlüsselt zu kommen. Der zweite datensatz hat auch etwa soviel. wenn wir mehrere haben picken wir uns einfach die methode raus wie bei allen datensätzen als mögliche lösung vorhanden ist.
@noch einer: danke für den Hinweis. Dann macht das ganze auch mehr Sinn. Ich habe mal an einen Ausgangspin einen externen 10k Pull-up gehängt. Der Pin geht nach einem Reset nach ca.14us auf low. Da aber der analysierte Teil deutlich länger dauert, hat das alles nicht so recht gepasst. Ab Adresse 1 scheint dann eine Unterroutine zu sein. Gruß, Walter.
Ich werde jetzt einfach mal anfangen eine vernünftige implementierung auf die beine zu stellen und werde sie dann hier posten. ich arbeite mit CUDA, sodass nur leute mit TESLA karten oder mit neureren Grafikkarten wie der GTX280 (die für mathematische operationen sehr gut missbraucht werden kann) davon gebrauch machen können!!! Wäre schön wenn jemand die daten vor und nach der verschlüsselung loggen könnte. Ansonsten wird schonmal das tool stehen um später evtl. die bitmasken (auch rekursiv angewandt) berechnen zu können Ich werd den code einfach halten :)
@Iranian Vorher und nachher daten sind hier zu finden: http://www.mikrocontroller.net/attachment/24819/20070716.txt
NixChecker: Wäre lieb wenn du mir kurz erklären könntest was genau jetzt was ist bei den logdaten .... sind das schon die IN-werte über die 3-minuten phase der wetterdatenübertragung? und wie kommt es dass beim out die stunden angaben nicht erwähnt worden sind. wenn ich das zu 100% verstehe wie die logdaten zu lesen sind sollte ich morgen eigentlich die lösung haben!
Hi, hier mal ein log von mir mit vorher-nachher Daten. Die ersten 59 Bits je Reihe sind das was über die Antenne reinkommt. Bei jeder dritten Zeile hängen die 82 Bits die in den Chip reingehen dran, der Rest dahinter ist das was wieder rauskommt. Die Daten sind 100% richtig. Aufgrund meines Auswerteverfahrens kann ich das ohne weiteres behaupten. MfG
Angehängte Dateien:
-
DCFlog.png
3 KB
und hier nochmal welche Bits in den Chip reingehen. Ist alles farblich markiert und sollte selbsterklärend sein. Die Nullen zwischen den farblichen Feldern sind nur zum auffüllen. Es gehen also weder Status-Bits noch ParitätsBits rein.
Um konkret was zu machen, könnte Walter nicht die Sleep-Zeiten nochmals nache einem HW-Reset auslesen, würde bez. Patch-Code helfen.
@Iranian
Eingabe+Ausgabe+Statusmeldung:
><0100110011000101111101000101010001001000100100000000000000011010001110
010011100000010001000000010011110110>
Eingabe: insgesamt 82 bit lang
Davon:
Datapack1: 14 bit
Datapack2: 14 bit
Datapack3: 14 bit
Minute: 8 bit
Hour: 8 bit
Day: 8 bit
Month: 5 bit
Weekday: 3 bit
Year: 8 bit
Ausgabe: insgesamt 22 bit lang + 2 bit Statusmeldung
Davon:
Wetter für den Tag: 4 bit
Wetter für die Nacht: 4 bit
Unwetter: 4 bit
Niederschlag: 3 bit
Switch: 1 bit
Temperatur: 5 bit
Statusmeldung: 2 bit
@Gast (Gast): evtl. verstehe ich deine Logdatei falsch, aber bei dir ist jeweils bei der 3. Zeile (die Lange, welche alle Infos enthält) die letzten beiden Stelle oftmals 11. Bei dexters Log sind die meistens 10. Ich meine, die 11 stehen für fehlerhafte Daten!? Aber evtl. täusche ich mich auch. Deine .png Datei ist IMHO richtig. P/\UL Und falls hier mc.net wirklich dicht gemacht werden sollte ;) haben wir immer noch freenet... (http://de.wikipedia.org/wiki/Freenet)
Nein, die letzten beiden Bits sind keine Status-Meldung. Zumindest bei meinem Chip aus der Meteotronic Start konnte ich das ausschließen. Die letzen beiden Bits haben manchmal (nicht immer) zum Tageswechsel gewechselt. Und außerdem wäre es doch recht unrealistisch wenn innerhalb von 3 Stunden immer genau ein Bit in den verschlüsselten Daten falsch wäre, oder?
P/\UL wrote: > falls hier mc.net wirklich dicht gemacht werden sollte ;) haben wir > immer noch freenet... (http://de.wikipedia.org/wiki/Freenet falls es dicht gemacht wird kann ich ganz schnell ein forum einrichten, welche adresse nicht veröffentlicht wird, die adresse könnt ihr bei mir per pn bekommen...
Wenn es sich nicht um eine echte Verschlüsselung, sondern nur um eine "Verwurschtelung" handelt, könnte man vielleicht die dahinter liegenden Funktionen mit einem Neuronalem Netz finden. Das war vor zwei Semestern bei mir ein Fach an der Uni. Ein Multi-Layer-Perceptron(MLP) kann theoretisch beliebige Funktionen realisieren und diese durch Eingabedaten + Korrekte Ausgabedaten finden. Gelernt wird aber durch Gradientenabstieg, was bedeutet das ganze läuft in ein lokales Minima der Fehlerfunktion. Deswegen gebe ich einem MLP bei einer echten Verschlüsselung keine Chance und die doch sehr gleichmäßige Verteilung von 0 und 1 sahen mir danach aus, aber bei ein paar einfachen logischen Verknüpfungen wäre das vielleicht einen Versuch wert. Nebenbei ist die Methode tolerant gegen ein paar Datenfehler. Aber bitte denkt bei der ganzen Aktion an Andreas, also Forumswechsel bevor es zuspät ist.
Walter, könntest du bitte auf mein MP antworten, möchte ungern den Patch ins Forum stellen.
Zum Patch, ist verdammt eng geworden, aber es geht. Sprich mittels externem MCU ist man dann imstande, für jeden Befehl den Speicherdump zu bekommen. Daraus lässt sich dann sicherlich der Alghoritmus ableiten.
Protokollanalysen sind meines Wissens nicht verboten, das veröffentlichen von Informationen zum unberechtigtem Zugriff auf verschlüsselte Daten dagegen schon. Auch wenn wie hier nicht kommerzielle Absicht, sondern sportlicher Ehrgeiz dahintersteckt. Da das rechtlich erlaubte meiner Einschätzung nach jetzt ziemlich ausgelotet sein dürfte, und ich in diesem Fall (im Gegensatz zu WLAN-Verschlüsselung o.ä.) kein öffentliches Interesse an einer Analyse erkennen kann, möchte ich den Thread an dieser Stelle sicherheitshalber schließen.
Thread beobachten
Seitenaufteilung abschalten
