Es ging im Forum um die Daten der MeteoData welche über den DCF-77 die Wetterdaten übertragen! Der Post wurde dicht gemacht (rechtlichen Grund gab es keinen) ! Gibt es irgendwo ne Grp welche an der Stelle weiter gemacht hat? Grüße Alex
:
Gesperrt durch User
Na ich weiß ja nicht ... Wenn es um das knacken eines kommerziellen Datenstroms geht gibt es sicherlich rechtliche Probleme.
Ich bin neulich auf http://www.dcf77logs.de/ gestossen. Die Datenbasis zum Knackversuch dürfte vorhanden sein. Mich würde vor allem interessieren, wenn, wie das geknackt wurde.
MagIO schrieb: > Na ich weiß ja nicht ... > Wenn es um das knacken eines kommerziellen Datenstroms geht gibt es > sicherlich rechtliche Probleme. Es gibt in DE das sogenannte "LockPicking". Da versucht man innerhalb kürzerster Zeit ein Schloss zu knacken. Das ist ein in DE anerkannter Sport! Auf digitaler Ebene kann man dies auch anwenden! Das Schloss ist ja auch komerziell!
Gast schrieb: > Ich bin neulich auf http://www.dcf77logs.de/ gestossen. Die Datenbasis > zum Knackversuch dürfte vorhanden sein. > Mich würde vor allem interessieren, wenn, wie das geknackt wurde. Die Daten sind ja mal der Hammer! Verschlüsselter und entschlüsselter Datensatz auf einmal! Hmmm, das klingt wirklich sehr interessannt!
Zitat: Hinweis: Die Wetterdaten werden über einen Dekodier-Chip (HKW581) aus einer Wetterstation, angeschlossen über einen FTDI232BM an den Server, dekodiert!
Nochwas: Dazu ist auch dasda sehr interresant. http://imperia.mi-verlag.de/imperia/md/content/ai/ae/fachartikel/ei/2008/09/ei08_09_064.pdf
Hallo, Wenn eine CSV-Datei von den Verschlüsselten und unversclüsselen Datensätzen (www.dcf77logs.de) erwünscht ist, einfach Bescheid sagen, und ja, ich bin der Betreiber der Seite... Gruß Thomas
Im letzten Thread schien der Durchbruch ja greifbar, hat sich hier noch was "im Untergrund" getan oder sind alle aktivitäten eingeschlafen. Grüße Timo
ok, den hatte ich gefunden, der ist ja aber doch recht alt.
Hallo, Ich hab mri mal die mühe gemacht und die Datensätze aus den Dateien rausgeholt und als CSV verpackt, Die dekodierten daten sind 22 Bit Lang, die verschlüsselten 82 bit die letzen 2 Bit (die zu den 24 Fehlen) sind statusbits und wurden hier in der csv-datei nicht beachtet, sodass die datei nur fehlerfreie einträge enthalten, fehlerhafte wurden bewusst herausgefiltert. Sollte dennoch eine Datei mit den Fehlerhaften Einträgen gewünscht werden liefere ich diese gerne nach... Einen Schönen Abend noch, Gruß Thomas
Hallöchen.. ich habe vor, die Wetterdaten des DCF77-Signals für meine Heizungssteuerung zu verwenden. Dazu habe ich legal eine Wetterstation WM-5002 von Technoline gekauft, in dem ein Dechiffrier-Chip HKW581 eingebaut ist. Diesen Chip werde ich auslöten und über ein AVR-Board benutzen um an die Wetterdaten zu kommen. Weitere Infos hier: http://www.cczwei-forum.de/cc2/thread.php?threadid=4110 Gruß Rolf
Hi, wir sind damals zu dem Schluß gekommen, dass es sich um einen PIC12F508 handelt. Die ersten 64 byte sind immer sichtbar, auch wenn die Codeprotection gesetzt ist. Der Ausgelesene Algorithmus ist ein 80 bit breites rückgekoppeltes Schieberegister mit ca 13 Abgriffen die in die Rückkopplung einfließen. Eine Idee war es, einen RAM Monitor zu schreiben. Die sichtbaren Bits des PIC lassen sich byteweise überschreiben. Dabei kann aber nur eine "1" zu "0" gesetzt werden, eine "0" aber nicht zu "1". "Chris" meinte damals eine Lösung zu haben, hat sich dann aber leider ausgeklinkt. Die 2. Idee war es, den RAM Inhalt vor oder nach der Decodierung auszulesen. Die Idee ist, dass der RAM Inhalt beim Löschen des Bausteins erhalten bleibt (noch nicht getestet). Also z.B. - an den Anfang der "Decodierroutine" einen goto $ schreiben (Programm bleibt dort stehen) - Chip starten und ein bekanntes Telegramm schicken - etwas warten, bis die Routine aufgerufen wird - Chip bei stehender Vcc löschen (RAM Inhalt sollte erhalten bleiben) - Eigenes Programm in den Chip schreiben, dass den RAM Inhalt ausgibt. Damit könnte man sehen, welche Daten in das Schieberegister geschrieben werden (von links oder von rechts geschoben) und welche Daten im den Zielregistern stehen. Soweit mein Kenntnisstand. Generell wäre es natürlich interessant, wie man die Fueses des PIC löschen kann ohne das Flash zu löschen (Stichwort Powerglitch). Ich habe da einige Tests gemacht aber leider kein positivies Resultat erziehlt. Gruß, Walter.
Nachtrag: ich habe noch eine 2.Wetterstation. Dort ist der Decoderchip auf die Platine gebondet und mit nem Schutztropfen versehen, also nicht direkt zugreifbar. Er verhält sich etwas anders als der vermutliche PIC12F508 Daneben ist noch ein SOP8 footprint auf der Platine auf welches auch die Daten und Taktleitungen geführt sind (Alternativbestückung ?) Vom Footprint könnte es ein EM6580 vom EM Microelectronic sein (Schweizer Untergruppe von Swatch). Dieser Chip verfügt über keinerlei Ausleseschutz ! Habe allerdings keinerlei Unterlagen über den Programmiermodus dieses Controllers. Ferner ist der Testpin dieses Chips für die Programmierung / das Auslesen nötig. Dieser ist aber durch den Schutztropfen nicht ohne weiteres zugreifbar. Vielleicht hat jemand Infos über die Programmierschnittstelle des EM6580. Den Tropfen könnte ich evtl. wegbekommen... Gruß, Walter.
Ich habe gesehen das der DC-IC einen Clock-Input besitzt! Dadurch wäre es doch möglich das Telegramm auf z.B. 1Bit/sek zu reduzieren, um anhand der Stromaufnahme die Rechenzyklen nachzubilden (irgendwo hier gab es mal einen Infobereich darüber)! Was passiert eigendlich wenn man dem IC lauter "0" oder "1" zusendet (eventuell mit passender Checksumme)? Auf diese weise geben einige "normalo"-Chiffer-ICs ihren Schlüssel bekannt! Edit: @Walter Den Tropfen müsstest eigendlich nichtmal wegmachen! Schau mal ob Du bei dem alternativen Footprint einige Einkerbungen findest welche von Nadeladapter herrühren! Eventuell wurde der IC im eingebauten Zustand programmiert!
Angehängte Dateien:
-
contactless_m.jpg
200 KB -
answer.png
110 KB -
question.png
110 KB
Hi Alex, Danke für den Hinweis mit den Nadeln. Leider ist auf dem alternativen Footprint der Test pin auf einen festen Level gelegt (kein Pull up oder Pull down). Zum Clock: Das Senden der Daten zum Chip läuft so: -> Daten an Data in anlegen -> Clock_in auf high ziehen <- Chip zieht Clock_out auf high -> Clock_in auf low ziehen <- Chip zieht Clock_out auf low Daten Empfangen: <- Chip zieht clock auf high -> Clock_out auf high ziehen <- Chip zieht clock_in auf low -> Clock_out auf low ziehen <- Chip legt Daten an <- Chip zieht Clock_out auf high Wenn ich mich recht erinnere kannst Du das beliebig langsam machen. Wenn Du Dir das auf dem Oszilloskop anschaust wirst Du sehen, dass Bit 7 (das Alarmbit eben) sehr viel schneller als die restlichen Bits vom Chip beantwortet (also verworfen ?) wird. Desweiteren gibt es eine "Zwangspause" zwischen den Anfragen von ca 40 Sekunden (auch nach einem Reset oder Power on). Es werden ja insgesammt 82 Bit gesendet (42 Bit codiert + 40 Bit DCF77 Daten), wobei Bit0 (Startbit) und 7 nicht verwendet werden und wir wieder bei unserem 80 Bit Schieberegister sind. Schickst Du ein ungültiges Telegramm (reicht schon ein gekipptes Bit) kommt vom Chip immer die gleiche Antwort: 0100000000000000000000000 Laut den Unterlagen vom Hersteller werden 22 Bit für die Wetterinfos verwendet. Die letzen beiden Bit sind (soweit ich weiss) immer 10 (oder eben 00 im Fehlerfall) Einer hatte mal berichtet einen Chip zu haben, der ein gekipptes Bit korregieren konnte und dann den Status mit 01 oder 11 ausgegeben hat (s.alter Thread). Ein weiterer Ansatz war es, gleiche decodierte Telegramme zu finden und dann die zugehörigen Codierten Telegramme zu vergleichen. Bisher ohne erfolgt ;-( Ich hatte mir das auch so vorgestellt, zuerst den Wiederherstellungs und Fehlererkennungs Mechanismus zu finden und dann erst das Crypt anzugehen. Ich habe einen Test gemacht und bei einem gültigen Telegram ein Bit nach em anderen kippen lassen (im Telegram war also immer ein Bit falsch). Bis auf den Bitkipper an Bit 7 kam immer ein Error-Telegram. Ich hab auch mal die Stromaufnahme aufgezeichnet (10 Ohm Widerstand und "normales" Oszi). Da konnte ich aber nicht viel erkennen. Gruß, Walter. PS: der "Reset pin" in dem Bild ist wahrscheinlich der Testpin für die Programmierung des EM6580.
Bitte in diesem Thread keine Schlüssel oder urheberrechtlich geschützten ROM-Dumps o.ä. hochladen, siehe Beitrag "Re: AVR: Wetterinformationen über DCF77".
Andreas Schwarz schrieb: > Bitte in diesem Thread keine Schlüssel oder urheberrechtlich geschützten > ROM-Dumps o.ä. hochladen, siehe > Beitrag "Re: AVR: Wetterinformationen über DCF77". Hi Andreas! Ja wird gemacht! Es geht hier nur um die Technik, und ob diese fehleranfällig ist (wir sind nur "Debugger")! Nicht um den Schlüssel selber! @Walter: Eventuell sind die Testpins (TPx) am schwarzen Klecks interessannt!
Hallo, Anbei noch eine Aktualisierte Liste der Daten, Gruß thomy_pc
Hi Thomy_pc, super Sache, danke ! @Andreas: ich möchte Dir an dieser Stelle auch versichern, dass mein Interesse rein "akademischer" Natur ist. Ich will niemandem sein Geschäft kauptt machen oder sonstwie schaden. Es geht mir auch, wie Alex schon geschrieben hat, darum, ein System zu untersuchen, eventuelle Schwachstellen zu finden, beispielhaft zu verstehen, welche Möglichkeiten man hat an solch eine Sache heran zu gehen. Gruß, Walter.
Hi Thomy_pc, kann es sein, dass Du die letzen beiden Bit in Deinen decodierten Daten abgeschnitten hast ? Gruß, Walter
...noch eine Korrektur zu einem meiner letzten Posts: 1) es werden 24 Bits ausgegeben (nicht 22), davon die letzen beiden sind bisher nicht dokumentiert und stellen anscheinend so eine Art Status dar. 2) ein fehlerhaftes Telegram wird (anscheinend) immer mit 100000000000000000000100 beantwortet (Status 00 anstelle von 10) @Thomy_pc: könntest Du vielleicht auch die letzen beiden Bits der Decodierten Daten mit aufzeichnen. Vielleicht kommen wir damit weiter. Danke. Walter
Hallo, die letzten beiden bits sind zwar nicht eindeutig dokumentiert, aber die bedeutung is folgende 10 ist fehlerfreie übertragung 00 ist nicht dekodiert (fehlerhafte eingangsdaten) 11 ist daten dekodiert, jedoch fehlerkorrektur vorgenommen, anbei eine Datei, wo ALLE datensätze vorhanden sind, auch die Fehlerhaften, inkl der letzten 2 Bits.. Zu der datei, Unterstriche in den Bits stellen nicht-empfangene bits dar, zu anfang wurden diese mit nullen aufgefüllt, aber seit ein paar monaten sind dieses unterstriche "_"
super, vielen Dank nochmal. Ich habe 2 Zeilen mit 11 am Ende gefunden. Kann Dein Chip korregieren ? Hast Du da mal Tests gemacht ? Ich werde die Zeilen mal meinem Chip zuführen, mal sehen, was der macht... Line 034980: 011110101000111011001000000101111110101000010011001100010000001100010010 1000010000;000000000011011100010011 Line 084086: 001011100010111101011110010000010010001110001010001001100000101000001000 1010010000;010010000000010000100111 Walter.
Meteo-data ist doch ein Wetterdienstleister. Gehört diese Software zu dieser Firma? Wo kann man diese erwerben? Danke für Infos
Hallo, bei den Zeilen handelt es sich um Fehler im Programmcode unter bestimmten umständen wurde der auslesevorgang zu schnell durchgeführt, sodass die Serielle schnittstelle zu träge ist. Es kann sein das noch mehr zeilen vorhanden sind, welche fehlerhaft sind EDIT: @Wilhelm Landberger: Meteo-data mag wohl ein wetterdienstleister sein, jedoch hat dies in unserem falle nichtss mit den wetterdaten zu tun, wir nennen die Wetterdaten hier halt meteodata, und die dekodierungssoftware gibt es nicht, das läuft über ICs., welche aus Wetterstationen entnommen wurden. ich Privat habe eine Software geschrieben, welche mit meinen selbstgebauten USB-Decodern klarkommt, diese ist jedoch ohne Dekoder-stick nur als DCF77-Datenlogger zu gebrauchen (welche auch die Systemzeit korrigiert, mehr informationen dazu unter http://www.tt-soft.org gruß thomas
Hallo Thomy-pc, danke nochmals für die Daten. Ich hab die Daten etwas aufbereitet: - Bit 0 und 7 entfernt (immer 0 und scheinbar nicht ausgewertet) - Trennung zwischen den 1. 40 Bit, den 2. 40 bit, dem Klartext und dem Status eingefügt - Zeitstempel hinzugefügt - sortiert nach Klartext - sortiert nach Häufigkeit Zu Beginn jedes Blockes Steht die Häufigkeit und der Klartextwert als Hex (für spätere Verarbeitung): M;[Häufigkeit][HEX Wert Klartext] Die größte Häufigkeit liegt bei über 600. Die Idee ist, Telegramme zu finden, die nur um 1 Bit von einander abweichen. Vielleicht kommen wir da weiter. Nachdem es anscheinend einen Mechanismus gibt, der 1 Bit korregieren kann (meine Station kann das anscheinend nicht) muss ein Datenfeld existieren das die Wiederherstellung ermöglicht. z.B: Bit 0 -21: Nutzdaten crypted (NC) Bit 22-37: 8x8 Matrix für Wiederherstellung von 64 Bit (22 Bit NC + 40 Bit DCF77) Bit 38-39: Checksumme über Matrix o.ä. Bit 40-79: DCF77 Daten Vielleicht können wir zumindest das Wiederherstellungsfeld identifizieren. Wichtig: Hat jemand einen Chip, der korregieren kann (anscheinend Statusmeldung 11) Wenn ja: aus Welcher Wetterstation. Damit könnte man testen, welche und wieviele Bit kippen dürfen. Gruß, Walter.
Hallo, Ich werde die nächsten Tage mal versuchen ob ich das Programm welches ich zum extrahieren der Wetterdaten aus den Logdateien nutze zu modifizieren, sodass ich das geliche format herausbekomme, werde damit dann die nächsten Datensätze herausgeben, Soll ich die fehlerhaften einträge auch mit einfließen lassen? Achja, @Walter: Keine Ursache...
Hallo, Ich habe mein Programm soweit umgeschrieben, es fasst die Gleichen datensätze nun zusammen, es ist zwar noch nicht so perfekt sortiert wie das von Walter, aber es tut seinen Zweck (hoffe ich, denn ich hatte ehrlich gesagt keine lust mehr ^^) Ich lade die dateien nun nicht mehr ins Forum hoch, da es mir zu lange dauert, Deshalb dort: http://www.dcf77logs.de/meteodata/MeteoData_Alle.zip (Alle Übertragungen, auhc die Fehlerhaften) http://www.dcf77logs.de/meteodata/MeteoData.zip (Nur die Fehlerfreien Einträge) In den ZIP-Dateien befinden sich jeweils die herkömmliche Variante wo nur die Binären Daten drinne sind 82 Bit Eingangsdaten, 24 Bit ausgangsdaten (inkl. dekoderstatus), und die Sortierte Variante, nach Walters vorlage. Da die Dateien von meinem Privaten Server geladen werden ist die Download-geschwindigkeit entsprechend meines Uploads begrenzt auf ~500kbps Gruß Thomas
Hallo Ich wollte nur mal fragen, ob es jemandem gelungen ist den Code zu entschlüsseln. Ich würde gerne selber eine Uhr mit Wetteranzeige basteln. Gruss Hannes
Hannes Furrer schrieb: > Hallo > > Ich wollte nur mal fragen, ob es jemandem gelungen ist den Code zu > entschlüsseln. Ich würde gerne selber eine Uhr mit Wetteranzeige > basteln. Dann ist es am vielversprechendesten sich eine Uhr mit passendem Chip zu kaufen und diesen zu verwenden.
Läubi .. schrieb: > Dann ist es am vielversprechendesten sich eine Uhr mit passendem Chip zu > kaufen und diesen zu verwenden. Welche günstige Wetterstation/Uhr ist denn zu empfehlen, wenn man gerne einen nicht gebondeten (Farbklecks) Chip haben möchte?
Ich habe mir sogar schon überlegt solch eine Uhr zu kaufen, an meinen HomeServer anzukoppeln, und ein kleines Display (verteilt im Haus) die Daten darstellen zu lassen. Alternativ nochn PlugIn auf meinem HomeClient.
Hallo, Ich habe gerade die Meteo-Data Zips aktualisiert, die links bleiben so wie gehabt: http://www.dcf77logs.de/meteodata/MeteoData_Alle.zip (Alle Übertragungen, auhc die Fehlerhaften) http://www.dcf77logs.de/meteodata/MeteoData.zip (Nur die Fehlerfreien Einträge) (maximal 60kb/s, mein Upload schafft nich mehr^^) Naja, ich bin der datenlieferant, was ihr da rausholen könnt is eure sache, wünsche dennoch viel Erfolg (wenns denn mal wieder voran geht ;)) Gruß Thomas
Thomas, knall die aktuellen Daten der letzten vier Tage einfach auf eine HTML-Seite. Die kann dann jeder der möchte, parsen. Brauch nicht viel Bandbreite.
Hallo, wie darf es denn aussehen? so wie in den Logdateien? so wie in den geparsten zips? Ich werd mein bestes tun, Gruß Thomas
Nachtrag, Ich habe jetzt ein kleines Script geschrieben, welches die letzten 4 vollständigen Logdateien, und die aktuelle Logdatei (heute) zurückgibt. d.h. es sind Mindestens immer 4 Ganze Tage zu sehen. Jeder datensatz beginnt mit <------------------------------ und endet mit ------------------------------> das was zwischen den abgrenzungen steht sind entweder hinweise das daten fehlen (z.b. durch serverausfälle) oder versionsinformationen der Empfängersoftware. http://www.dcf77logs.de/lastmeteodata.aspx Gruß Thomas
Dein Link lädt über 3MB Daten und anscheinend beherrscht dein Server auch kein zip. Geht es nicht kleiner? Ich weiß nicht, benutze es eh nicht. Ich denke aber das die Leute die es für Wettersteuerungen benutzen wollen, nur an einer Kurzform der Klardaten interessiert sind. Trotzdem danke für die viele Arbeit.
Hallo, vorher 2.5MB
1 | HTTP/1.1 200 OK |
2 | Server: WeSeiKon 3, Version: 3.0.1.0 |
3 | Date: Thu, 22 Apr 2010 07:56:46 GMT |
4 | X-AspNet-Version: 2.0.50727 |
5 | Cache-Control: private |
6 | Content-Type: text/plain; charset=utf-8 |
7 | Connection: Close |
8 | Content-Length: 2585150 |
Nachher: ~240kb
1 | HTTP/1.1 200 OK |
2 | Server: WeSeiKon 3, Version: 3.0.1.0 |
3 | Date: Thu, 22 Apr 2010 07:55:44 GMT |
4 | X-AspNet-Version: 2.0.50727 |
5 | Content-Encoding: gzip |
6 | Cache-Control: private |
7 | Content-Type: text/plain; charset=utf-8 |
8 | Connection: Close |
9 | Content-Length: 240613 |
etwa ein elftel.. Muss das manuell mit asp.net machen, aber sobald der browser gzip als content-encoding unterstützt wirds komprimiert... gruß thomas Nachtrag: Ich kann ja noch nen weiteren link erstellen, wo nur die klar-daten mit datum/uhrzeit und regions nummer und dergleichen übertragen werden, ist aber etwas aufwändiger, ich mach das wenn ihc am Wochenende zeit habe. Gruß thomas
Du kannst doch auch gleich die decodierten Werte als "String" in einer Datei direkt ausgeben. So könnten sogar Apps den Inhalt lesen und direkt auswerten. Da die Bits auch als Byte codiert werden können, wäre die Datei nur ein paar Bytes groß. Eventuel würde auch eine Datei mit Hex-Werten, getrennt von Leerzeichen reichen.
OK, es geht voran. Was macht man mit solchen Daten? Würde vermuten, eine Heizungssteuerung mit einem eher schwächlichen Controller die passenden Wetterdaten für die nächsten Tage zu liefern: 1. Um die Vorheizung zu optimieren 2. um auf einem Display am Hauseingang die Wetterdaten für die nächsten Tage anzuzeigen Folglich kann man lokal keine 2,5MB dekomprimierte Daten verwursten. Da wäre ja dann mindestens ein kleiner Linuxer-Board beschäftigt. Du kannst diese Datenmenge auch nicht mehr aufbringen, wenn nur ein paar hundert Interessenten sie ständig bei dir abholen. Also muß was kleines her! Sonst ist die ganze Mühe auf Dauer eh sinnlos.
Das is mir klar, das das auf dauer nix wird wenns dick und fett ist ;)
Ich habe heute und morgen nur nicht viel zeit, morgen eher als heute,
Dadurch habt ihr zeit mir vorschläge zu machen, welches datenformat
sinnvoll wäre, binär klingt schonmal gut, nur wie soll die "syntax" sein
die anordnung der Daten, ich wäre für eine Feste Länge pro Datensatz,
mein Vorschlag wäre
{Region}{Tag}{Monat}{Jahr}{Stunde}{Minute}{Dekodierte Wetterdaten}
Vielleicht habt ihr ja noch andere ideen, bisschen zeit zum überlegen
habt ihr ja sicher noch.
Gruß
Thomas
Nimm doch das Format in dem auch torrentfiles vorliegen: http://en.wikipedia.org/wiki/Bencode das ist recht einfach und universell.
Ein HTML-darstellbares File, oben die Daten in Hex-Darstellung, unten eine Legende. Also so, daß es keine Rückfragen gibt ;-) Die Daten werden doch in 24h komplett übertragen? Soviele Bits sind es doch nicht.
Angehängte Dateien:
-
WM5002.jpg
86 KB
Christian H. schrieb: > Läubi .. schrieb: >> Dann ist es am vielversprechendesten sich eine Uhr mit passendem Chip zu >> kaufen und diesen zu verwenden. > > Welche günstige Wetterstation/Uhr ist denn zu empfehlen, wenn man gerne > einen nicht gebondeten (Farbklecks) Chip haben möchte? Ich habe die Wetterstation WM 5002 von techno_line mit SMD-Chip den man auslöten kann: http://www.cczwei-forum.de/cc2/thread.php?threadid=4110 Die gibts bei Saturn oder MediaMarkt und Medimaxx Gruß Rolf
Meine Idee: Könnte man die Daten auf dem PC auswerten und dann per Funk mit dem ATmega128RFA1-Chip an verschiedene Epmfänger im Haus senden. Die Idee schwebt mir so als digitale Ladezeitschaltung für meine Nachtspeicherheizung vor. Mein Projekt im CC2-Forum: http://www.cczwei-forum.de/cc2/thread.php?threadid=4110 Gruß Rolf
Rolf Degen schrieb: > Könnte man die Daten auf dem PC auswerten und dann per Funk mit dem > ATmega128RFA1-Chip an verschiedene Epmfänger im Haus senden. Kann man... aber wieso so umständlich dann kann man doch gleich einen beliebigen Wetterdienst im Internet nutzen.
Hallo, Ich hab den Code dann mal soweit umgebaut Habe die Hex-Darstellung gewählt, reines Text-format jedes Byte ist durch ein leerzeichen getrennt 1. Byte ist Jahr in BCD-Form 0x10 für 2010 0x11 fpr 2011 usw.. 2. Byte ist der Monat in BCD-Form 0x01 für Januar ... 0x12 für Dezember 3. Byte ist der Kalendertag in BCD-Form 0x01 für 01. ... 0x31 für 31. 4. Byte ist Die Stunde 0x00 für 0 Uhr .. 0x23 für 23 Uhr 5. Byte ist die Minute in BCD-Form 0x00 für 0 Minuten ... 0x59 für 59 Minuten 6. Byte ist Regions-Typ 0x00 für 1. Tag (Heute, Höchstwerte) 0x01 für 1. Tag (Heute, Tiefstwerte) 0x02 für 2. Tag (Morgen, Höchstwerte) 0x03 für 2. Tag (Morgen, Tiefst) 0x04 für 3. Tag (Höchst) 0x05 für 3. Tag (Tiefst) 0x06 für 4. Tag (Höchstwerte) 0xff für 4. Tag der ersten 60 Regionen (enthält nur winddaten) oder für 1 und 2. Tag der zusätzlichen Regionen 60 bis 89. (Diese letzten am besten ignorieren, da die Regionsnummer für 4. Winddaten sind) 7.Byte ist Regions-Nummer in BCD-Form 0x00 für Region 00 ... 0x59 für Region 59 8. bis 10. Byte sind die Wetterdaten Beispiel für dekodierte Wetterdaten aus der Logdatei: 110011000000100010000110 Hier werden die letzten beiden bits auf 00 gesetzt anstatt abgeschnitten, damit ich volle drei byte habe. Die konvertierung ist wie folgt: 1100 1100 0000 1000 1000 0100 c c 0 8 8 4 Damit lautet das folgende Beospiel so: 10 01 18 19 11 06 43 cc 08 84 18. Januar 2010, 19:11, Höchstweret für den 4. Tag für die Region 43: 1100110000001000100001 Der Link zu den Logdateien: es werden die letzten 2 Logdateien analysiert, sollte ausreichen: http://www.dcf77logs.de/lastmeteodata.aspx Die dicken Zip-Dateien werde ich dennoch alle nase lang mal aktualisieren, sodass die Algorythmenanaylsierer auch mal neue Daten bekommen. Gruß Thomas
Hallo Thomas - Danke für deine Mühen! Das sollte dann auch der schwächliste AVR parsen können. Ist auch schön kurz in Bytes. Sind die Dealgorithmer schon weiter? Das zippen scheint aber nicht zu funzen laut meinem Log. Unterstützt das dein Webserver nicht standardmäßig? Aber gerade drüber nachgedacht: Das würde dem AVR auch nicht gut schmecken. Müßte er ja unzippen. Gruß - Abdul
Hallo, er zippt es wenn der browser im http-Header einen tag setzt accept-ecoding, wenn dies gesetzt ist, dann wird gezippt, eher nicht und auhc nur bei gzip, der webserver von sich aus kann das nicht, deshlab habe ich das in asp.net implementiert Nachtrag: Mein kollege wird versuchen das demnächst in den Webserver zu implementieren, der webserver ist nämlich eine privatentwicklung in vb.net gruß thomas
Aha. Laut dem Tool hier http://www.gidnetwork.com/tools/gzip-test.php ist diese Seite komprimiert. Wie sähe dann eine Dekomprimierungsroutine für Kleinkontroller aus? Aber was mir gerade auffiel: Mein Webbrowser IE6 sendet neuerdings keine Akzeptanz mehr. Woran kann das liegen?
Warum sind in deiner Datei eigentlich keine 480 Zeilen? 24h/60min*3
Abdul K. schrieb: > Aber was mir gerade auffiel: Mein Webbrowser IE6 sendet neuerdings keine > Akzeptanz mehr. Woran kann das liegen? Hat sich erledigt. Lag an Proxy-Einstellungen.
Abdul K. schrieb: > Warum sind in deiner Datei eigentlich keine 480 Zeilen? 24h/60min*3 Pro Tag werden 480 Datensätze übertragen. Das macht 480 Zeilen. In meiner Datei sind die Daten vom Vortag enthalten und die vom aktuellen Tag. Bei vollständig fehlerfreiem Empfang müssten also >480 Datensätze oder beim Tageswechsel 481 Zeilen in der Datei sein. Bzw. bei Tagesende und fehlerfreiem Empfang sind die letzten beiden Tage, sprich 960 Zeilen in der Datei. Da der Empfang aber nicht immer fehlerfrei ist, sind es meist weniger. Ich hoffe das beantwortet die Frage. Gruß Thomas
ja ok. Dachte es wären immer die letzten 24h. Später sah ich dann, das es wächst. Kann der Controller ja einfach gzip, deflate gar nicht mitsenden und bekommt dann die Daten plain serviert.
Hallo, mir ist vorhin beim durchsehen der letzten Logdatei aufgefallen das zwischen 19 und 20 uhr keine Wetterdaten übertragen wurden. Anbei der Auschnitt aus der Logdatei. Was für einen grund kann dies haben. Zumal das ja genau eine stunde ist. Gruß Thomas
Hallo, Jetzt gerade werden wieder keine wetterdaten übertragen, seit 25min ist totenstille. gibts probleme bei der Signalaufbereitung, kommen keine wetterdaten von meteotime rein? Offenbar werden die Wetterdaten blockweise zu je 1 Stunde an die Anlage geliefert... Gruß Thomas
Hm. Könnte sein. Bau einfach passenden Code in deine Auswertung rein. Du bist der Held! Benutzt oder plant das jemanden zu nutzen?
Vlt. hat Meteo Time Übertragungsproblem zum DCF77-Sender. Bin gerade auf www.dcf77logs.de Da ist das gleiche Problem. Die Seite find ich klasse. Gruß Rolf
Abdul K. schrieb: > Benutzt oder plant das jemanden zu nutzen? Zog ich mal in Erwägung ... Nu nicht mehr. :-/
Abdul K. schrieb: > Benutzt oder plant das jemanden zu nutzen? Ja ich, für eine Nachtspeichersteuerung in meiner Hütte um Energie zu sparen. Siehe meine Projekt-Seite unter: http://www.cczwei-forum.de/cc2/thread.php?threadid=4110 Gruß Rolf
Rolf Degen schrieb: > Vlt. hat Meteo Time Übertragungsproblem zum DCF77-Sender. > > Bin gerade auf www.dcf77logs.de Da ist das gleiche Problem. Die Seite > find ich klasse. > > Gruß Rolf ^^ Danke Ist ja auhc meine internetseite^^ außerdem hab ich die log auhc da her: vor allem unten in der Grafik zu erkennen: http://www.dcf77logs.de/logfiles.aspx?mode=swimg&file=DCFLog00645.log&showerr=true ebenso hier: http://www.dcf77logs.de/logfiles.aspx?mode=sdimg&file=DCFLog00645.log Gruß Thomas Nachtrag: Das war offenbar der erste Datensatz, wo es schon probleme gab:
1 | 0 00000000000000 001001 10000001 0001100 101001 111 00100 000010000 So, 25.04.10 18:01:00, SZ |
2 | 0 01000010100000 001001 01000001 0001100 101001 111 00100 000010000 So, 25.04.10 18:02:00, SZ |
3 | 0 00000000000100 001001 11000000 0001100 101001 111 00100 000010000 So, 25.04.10 18:03:00, SZ |
Danach ging es aber weiter. Ich habe 2 empfänger laufen, einen am Server, ein weiterer an meinem Arbeits-PC, beide haben die gleichen Daten aufgefangen, deshalb schließe ich Übertragungsfehler aus. Grruß Thomas
Huch, die Grafik sah ich nocht nicht. Nett. Hast du von HKW schon mal gehört? Spätestens jetzt ist es ja echt easy an die Wetterdaten zu kommen.
Bisher hat sich noch niemand bei mir gemeldet Gruß Thomas
Nachtrag: Was ich seltsam finde ist, das meine wetterstationen den 4. Tag heute nicht aktualisiert haben (Region 19, letzer fehlerfreie Datensatz bevor der erste fehlte) ebenso habe ich gerade eine Wetterstation auf eine andere Region eingestellt. Bisher haben diese immer sofort die nächsten Daten empfangen und angezeigt, das ist bei diesen heute nicht der fall. werden vielleicht irgendwo daten bezüglich der Regionen übertragen von denen wir noch nichts wissen? Sprich Regionscode irgendwo in den verschlüsselten daten?, in den unverschlüsselten kann nichts sein, der dekoder spuckt nicht mehr als 24 Bit aus, auhc wenn man es übertreibt und noch mehr auslesen möchte... Gruß Thomas
Hm. Wie auch immer. Es ist eine gute Gelegenheit für die Dekodierer.
Nur zur info: Das ganze hat sich gestern wiederholt, zur gleichen zeit, kann es sein, das in den Regionen (was ja nicht grad wenig sind) keine Daten mehr übertragen werden? http://www.dcf77logs.de/logfiles.aspx?mode=swimg&file=DCFLog00646.log&showerr=true Gruß Thomas
ok, war Quatsch, da gab es wohl mal eine Firma gleichen Namens.....
Die firma die hier die Wetterdaten bereitstellt heißt meteotime, meteodata ist eine andere... Gruß Thomas
Angehängte Dateien:
-
histOnes.jpg
61 KB
Hallo, hab mal die verschlüsselten Daten von Thomas geparst und einen ersten Blick darauf geworfen. Auf dem Bild im Anhang sieht man ein Histogramm, die x-Achse ist der Index eines Bits im chiffrierten Text, die y-Achse ist die Anzahl der Einsen, die im untersuchten Datensatz auf dieser Position vorgekommen ist. Es sind die ersten 42 Bits des Chiffretextes, d.h. der Zeitstempel ist nicht dabei. Was auf den ersten Blick auffält: Wie im Forum schon erwähnt wurde, wird die Position 0 und 7 nicht mit 1 belegt,(tatsächlich finden sich 8 Datensätze, wo die Position 0 mit einer 1 belegt ist, scheint mir aber ein fehlerhafter Datensatz zu sein) Weiterhin fällt die gleichmäßige Verteilung der Einsen auf den Stellen ab Index 14 und natürlich die Ungleichmäßigkeit bis zur Stelle 14, vor allem der Peak bei Index 13. Meine Vermutung: auf den letzten 28 Bits sind die tatsächlich verschlüsselten Daten - davor vielleicht eine Art correction code? Viele Grüße, Andreas
Es handelt sich dabei um fehlerhafte datensätze. dort wo bit 0 und bit 7 besetzt sind... Achja das Design der Seite (http://www.dcf77logs.de) und die Struktur habe ich komplett erneuert, das ganze hat mich fast 2 Wochen und viel Langeweile gekostet ^^ Falls ich irgrndwas bezüglich der DCF-Daten für euch tun kann, schreibt mir ruhig, (bevorzugt hier im thread, es sei denn es is off topic) Gruß Thomas
Hallo Leute, gibt Neuigkeiten, mich hat jemand aus Großbritannien angeschrieben bezüglich der Verschlüsselung, er ist ein kryptograph, ich habe ihm die Adresse von diesem Tread gegeben, sodass er sich hier verewigen kann mit seinen Erkenntnissen, er hat mir bereits einige Erkenntnisse geschrieben, jedoch weiss ich nicht ob ich diese hier so hne weiteres veröffentlichen darf. deshalb erstmal euch allen einen guten Rutsch ins neue Jahr.
Klingt interessant! Na da werd ich gleich mal schauen. Guten Rutsch! Die ersten Raketen gingen gerade weg...
Hi thomy_pc, erstmal nen gutes Neues Jahr. Die Erkenntnisse würden mich ja auch mal interessieren. Vielleicht kannst Du sie ja mal "unter dem Tisch" weiterreichen ;-) Gruß, Walter.
Hallo, heute gab es mehrere sehr kuriose fälle, es wurden keine wetterdaten übertragen, und zwar waren die dekodierten Daten leer, nicht wie üblich wenn was fehlt die verschlüsselten daten...
1 | <------------------------------ |
2 | IN: - Datenpaket 1.....................: 00110010101101 |
3 | - Datenpaket 2.....................: 01101101010010 |
4 | - Datenpaket 3.....................: 01001000000010 |
5 | - Minute...........................: 10011010 59 |
6 | - Stunde...........................: 11101000 17 |
7 | - Tag..............................: 10000100 21 |
8 | - Monat............................: 10000 01 |
9 | - Wochentag........................: 101 5 |
10 | - Jahr.............................: 10001000 11 |
11 | |
12 | OUT: - Tag..............................: 0000 0 0 - -- |
13 | - Nacht............................: 0000 0 0 - -- |
14 | - Wetterextreme....................: 0000 0 Keine |
15 | - Niederschlagswahrscheinlichkeit..: 000 0 0% |
16 | - Wetteranomalie...................: 0 Nein |
17 | - Temperatur.......................: 000000 0 <-21°C |
18 | - Dekoderstatus....................: 10 |
19 | ------------------------------- |
20 | Verschlüsselte Daten...: 0011001010110101101101010010010010000000101001101011101000100001001000010110001000 |
21 | Dekodierte Daten.......: 000000000000000000000010 |
22 | Uhrzeit................: 17:59 |
23 | Region.................: 17:59 Region: 19 (Höchstwerte, 4. Tag) |
24 | 19 - D - Bremerhaven, Bremen (Nordseeküste) |
25 | |
26 | |
27 | ------------------------------> |
Hier ist die Logdatei: http://www.dcf77logs.de/ViewLog.aspx?mode=meteo&file=DCFLog00927.log und die grafik zur logdatei, dort ist es sehr gut zu sehen: http://www.dcf77logs.de/LFGraphic.aspx?mode=meteo&file=DCFLog00927.log vielleicht hilft das ja bisschen beim entschlüsseln... leere datensätze
Hallo, seit gestern 17 Uhr wurden keine Wetterdaten mehr gesendet. Was ist da los, wenn Wetterdaten bisher fehlten, wurde immer eine Störung ausgelöst. Dieses mal nicht. Wie in der Wetterdatengrafik zu sehen kommen alle paar stunden noch datensätze rein.
Nachtrag: es werden nur noch Wetterrdaten für Region 0 übertragen. Region.................: 05:02 Region: 0 - F - Bordeaux, Aquitaine (Südwestfrankreich) Ich denke das es sich hierbei um einen Softwaretechnischen Fehler handelt... aber ob die Wetterdaten korrekt sind weiß der Geier... Meine Wetterstationen spinnen ebenfalls, zeigen nur noch -HH und kein wettersymbol mehr an.
(ja ich weiß dass der thread alt ist, aber das thema ist aktuell) sehr interessant! habt ihr eigentlich schon neue Erkenntnisse bzgl. der sicherheit der verschlüsselung? Ich denke es könnte evtl. ein kryptographisches Problem sein, wenn man jetzt so viele Datensätze mit dem gleichen Output hat ;-) Da sich die Minuten nur um 1 ändern sieht man auch gleich an den Wetterdaten was sich DORT ändern muss um den gleichen Output zu erzeugen. Das kann den Algorithmus sehr schwächen. Es geht schon in Richtung von "Choosen plaintext". Evtl. ist es jetzt auch möglich ein paar Sachen auszuschließen. Habt ihr euch mal damit befasst?
Hi, ja haben "wir". Ich hab versucht so einen Wetterempfänger aufzutreiben (andere haben bereits einen) mit dem Ziel erstmal die Rohdaten vor dem Chip, und die decodierten Daten nach dem Chip in eine Datei zu schreiben. Ich habs nicht fertig gestellt, aber hier im Tread wurde soetwas von einem anderen User bereits gemacht (Thomas)! Diese Datei kannst Du selbst mal etwas kryptologisch bearbeiten. Ich hatte bisher keine Zeit, mir das genauer anzuschaun. Aber so ein ALgorythmus wäre für andere Selbstbaugeräte interessant.
Angehängte Dateien:
-
enc1.PNG
1 KB
Hi, ich analysiere die Bits gerade (also dort wo nur 0 rauskommt). ich konnte schon einige merkwürdigkeiten feststellen. Lasse gerade verschiedene Entropietests drüberlaufen. Es scheint so als wären (wurde hier auch schonmal angemerkt) die ersten paar Bits NICHT pseudo-zufällig, sondern haben deutliche tendenzen. Bei den hinteren Bits gilt dies nicht mehr soweit ich das jetzt schon sagen kann. Gerade ist mir auch was sehr interessantes aufgefallen, da ich eine Stelle suchen wollte: Hab in die Suche im Firefox "000100110110111011" eingegeben. Das sind 15 Bit. Ich konnte diese 15 Bit genau 2 mal in den Datensätzen finden. Die Wahrscheinlichkeit, dass dies rein zufällig ist, liegt nahe 0. Bei einer weiteren Analyse konnte ich einen anderen 8 Bit Block auch zwischen diesen beiden Zuordnen. (siehe Bild) Steht es eigentlich fest, dass es ein 80-bit Rückgekoppeltes Schieberegister ist? Ich hab mal was von 13 Abgriffen gelesen. Das wäre aber eigentlich untypisch, 4 wären realistischer (man will ja schließlich alle zustände durchlaufen) Siehe http://www.xilinx.com/support/documentation/application_notes/xapp052.pdf Seite 5
Wetterdirekt benutzt ein anderes Verfahren. Die Übertragung läuft auf Pagerfrequenzen, soweit ich weiß. Wahrscheinlich 70-cm-Band. Eine solche Station habe ich auch mal geöffnet, alles aufgebondete und verkleckste Chips, die ganze Konstruktion wirkt ziemlich billig. Übrigens: Die Google-Suche nach "000100110110111011" liefert bei mir nur ein Ergebnis, in einer Sprache, die ich nicht verstehe. Das Xilinx-Datenblatt ist ganz interessant. Die 80 Bit und 13 Abgriffe wurden bisher nicht bewiesen, soweit ich weiß. Vielleicht eine Vermutung - oder die Entwickler kannten das Xilinx-Datenblatt nicht und wählten eine suboptimale Lösung.
oh sry, das war auf folgende Datei bezogen mit den 010... http://www.dcf77logs.de/ViewLog.aspx?mode=meteo&file=DCFLog00927.log es scheinen genrell einige abfolgen recht häufig aufzutreten. (dem entgegen steht aber, dass es täglich 480 Datensätze gibt, einige "Treffer" sind also rein zufällig). Auffällig ist aber auch, dass das erste der 3 Pakete oftmals gleich ist bzw. mit vielen 0en anfängt.
@Sebastian google übersetzung sagt: irgendein puzzle spiel bzw mathe rätsel
huiuiuiuii schrieb: > @Sebastian > > google übersetzung sagt: irgendein puzzle spiel bzw mathe rätsel Was hier auch so ist xD^^ Der Witz an der ganzen Technik ist ja, das wenn ich ne große Firma hätte, und z.B. für Gebäudesteuerung die Wetterdaten benötige, so würde ich mir nen Server schnappen, so ein Wetterempfänger drannbauen, die entschlüsselten daten mit meinem Schlüssel codieren und meiner Hardware zur Verfügung stellen. So würde niemand rausfinden woher die Daten ursprünglich stammen. Daher verstehe ich den Aufwand nicht, wie die Daten verschlüsselt werden.
nur da steht schon eine lösung^^ naja doch...man könnte mal ein paar dummysignale senden..un schon sieht man das die bei dir genauso ankommen
huiuiuiuii schrieb: > nur da steht schon eine lösung^^ > > > > naja doch...man könnte mal ein paar dummysignale senden..un schon sieht > man das die bei dir genauso ankommen Wie denn? Ich verschlüssel doch mein Datenpaket!
Man müsste nur Kunde bei dir werden;) Dann geht es:)
interessant: Ich hab mir schnell ein Script geschrieben, welches versucht Gemeinsamkeiten in den Datensätzen zu erkennen. Sofern es keine Zufälle sind, dann kann man nach aktuellem Stand einen 14-bit Ausschnitt aus JEDEM der Wetter-000..-Datensätze auf mind. einen anderen legen. Diese Datensätze weisen auch eine sehr hohe Gemeinsamkeit auf, es scheinen auch andere Teile gleich zu sein. (diese Infos sind mit vorsicht zu sehen, denn der reine "zufall" kann nicht ausgeschlossen werden!)
Moin, Na endilch passier tmal wieder was ;) Ich ahbe die ganzen Leeren wetterdaten hier einmal zusammengefasst: http://www.dcf77logs.de/ViewLog.aspx?mode=specialmeteo&file=22%20-%20Leere%20Wetterdaten.log Sorry das es Fehler 500 gab, Mysql macht probleme.. Gruß Thomas
Die ML-LFSR kann man XORen mit einer n-bit verzögerten Version. Wenn ich mich recht erinnere, kann man dann den Klartext lesen. Müßte danach suchen. Wird so bei BERT gemacht.
Hallo Leute! Ein Hinweis: Beachten Sie, dass fbit 0 ist für den Notfall Warnungen verwendet. Ein nicht zu vergessen Dexter Arbeit: Beitrag "Re: AVR: Wetterinformationen über DCF77" Auch Bit 0 und Bit 7 http://www.mikrocontroller.net/articles/DCF77_Wetterinformationen#Patente Patent Info kann auch hilfreich sein, auf Bits: http://www.mikrocontroller.net/articles/DCF77_Wetterinformationen#Patente PS: Sorry, mit Google von meinem schlechten Englisch übersetzt.
Leave it in english version. Most people can understand it successful.
@aaaaa, unter anderem wird in den Wetterdatenempfängern ein PIC (Microchip) eingesetzt, vermutlich ein 12x508. Eine Eigenschaft dieses Controllers ist es, dass trotz aktiver Codeprotection immer die ersten 64 Byte les- und schreibbar sind. Es wurden die Daten also ausgelesen und analysiert. Dabei kam eine Routine zum Vorschein, die ein Rückgekoppeltes Schieberegister mit 80 Bit breite und sehr vielen Abgriffen darstellte. Soweit würde das ja ganz toll passen. Es kann natürlich sein, dass es sich hierbei um einen "Honeypot" handelt (so würde ich das zumindest machen). Damals wurden hier 3 Änsätze verfolgt: 1) Ändern der SW: die Schieberegister Routine sollte erstzt werden durch eine Routine, die einen freien Zugriff auf das RAM ermöglicht (Lesen und Schreiben) 2) Auslesen des RAMs: Die Idee ist, dass trotz Bulk erase (Löschen des gesammten Flash, so es denn ein "F" Typ ist, bei dem auch die Code-Protection gelöscht wird) die Daten im RAM erhalten bleiben. Also: erste stelle der Schieberegister Routine so überschreiben, dass die SW stehen bleibt (Endlosschleife) nachdem die Codierten Daten in den Chip gelagen wurden, Erase chip, neue SW rein, die den RAM Inhalt ausgibt. 3) Codeprotection des PIC mittels Vcc Glitches umgehen. Chris (1 Thread) hatte da wohl was gemacht (zumindest angedeuetet). Hat sich leider nicht mehr gemeldet. Das Disassembly müßte sich irgenwo noch im ersten Thread befinden. Aber wie gesagt: mit Vorsicht zu genießen. Die Routine bildet zwar dieses Schiebergister ab aber es ist nicht sichergestellt, dass die Daten auch so damit verwurstet werden. Gruß, Walter. PS: aber sehr schön, dass das Thema wieder aufgegriffen wird !
Sind denn die Abgriffe am Schieberegister bekannt? Das wäre ein Ansatz. Man kann dann nach den Standardvarianten im I-Net suchen. Ein passender Begriff wäre Galois. Wird im Zusammenhang mit den Schwachpunkten von Verschlüsselung mit Schieberegistern als Verbesserung genannt. Punkt 2. ist halt blöde, denn dann ist das zu analysierende Programm auch futsch. Irgendwie muß das Schieberegister synchronisiert werden!!!! Es muß dafür passende sich oft wiederholende Vektoren als Eingangssignal im Funkdatenstrom geben. Muß oft passieren, denn sonst kann eine Uhr nicht nicht schnell genug aktuelle Daten bekommen. Dafür wäre ein Ansatz zur Größe des Schieberegisters: Durchschnittliche Zeit vom Einschalten bis zur ersten Anzeige von Wetterdaten messen.
Das Register kann sich doch aus dem Datenstrom des DCF synchronisieren.
Die Abgriffe am Schieberegister bekommt man aus dem Assemblercode raus. So einfach siehts aber doch nicht aus: Das ist keine "einfache" Rückkopplung sondern es sind so gesehen 2 Schieberegister: Das erste ist das große mit den 80 Bit. Das zweite ist ein kleineres mit 8 Bit. Das wird so gefüllt: Es werden mehrere Bytes aus dem großen Register ausgelesen, ein paar Bits ausgeblendet mit z.B. AND 00011001 und dann geXORt mit dem 8 Bit Register. Danach wird das 8 Bit Register noch ein paar mal hintereinander geschoben und mit einem vorherigen Stand geXORt. Das LSB dieses Registers wird dann nochmal mit dem LSB des 80-Bit Schieberegisters geXORt. Das macht soweit auch alles Sinn, habs auch schonmal nachprogrammiert (wobei ich nicht weiß ob ich das richtig gemacht habe...) aber noch nichts weiter erreicht. Problem ist vor allem: Es steht nirgends, wie das ganze Ding initialisiert wird. Ich gehe mal davon aus, dass die Uhrzeit/Datum als Teil eines Schlüssels verwendet wird. Merkwürdig ist auch folgendes: ... 0036 04a4 bcf 0x04,5 0037 0213 movfw 0x13 0038 05a4 bsf 0x04,5 0039 01b3 xorwf 0x13,f ... Was macht das? Speicherzelle auf 0 setzen durch XOR mit sich selbst? Zur Synchronisation: Ich denke das funzt schon ab dem 1. Datensatz den es erhält. Also alleine die aktuelle Uhrzeit braucht es dazu.
So wie du das beschreibst, wäre der Seed die aktuelle Uhrzeit/Datum. Das wird wohl letztendlich auch die Schwachstelle sein! Ist ja sequentiell und vorhersagbar! Denken heißt nicht wissen! Kann da mal jemand probieren? Ich habe leider keine Uhr und kenn mich mit PIC nicht aus. Eine Speicherstelle XORen und damit auf Null setzen, ist ein alter Hut. Bei irgendeiner CPU war das sogar der normale Weg und als Befehl 'Nullsetzen' in der Assemblersprache -> Binärcode ist dann XOR gewesen. Das mit den zwei Schieberegistern: Kann mich nicht erinnern, das vorher hier gelesen zu haben. Hm. Wo steht das? Jedenfalls, wenn das Verfahren so genau bekannt ist, müßte man doch dazu ne Menge im I-Net prinzipiell beschrieben finden.
zu den auf 0 setzen per XOR waren afaik die AVRs, denn der "clr r16" befehl ist auch der "eor r16,r16" befehl ;-) Schau mal in den Assemblercode rein (ist im anderen Thread als .asm angehängt), dort findest du eine Speicherzelle mit 0x1c als Adresse, die auch nochmal ein paar mal geschoben und mit sich selbst verXORt wird. Gerade eben kam mir noch eine Idee: Wir gingen doch immer davon aus, dass jede Uhrzeit nur einmal vorkommt, was zuerst auch logisch erscheint. Aber was ist mit dem Oktober? Dort wird von Sommerzeit auf Winterzeit umgestellt, also die Uhr eine Stunde zurück. Da die Seite offenbar gerade down ist, stelle ich die Daten direkt hier online die ich noch aufm PC habe. Was bringts? Gehen wir mal von folgendem aus: Es wird ein Key errechnet mit z.B. 40 Bit Länge, hernach werden die Daten mit diesem Key geXORt. in DIESEM FALL (und nicht hier wie gezeigt wird!!!) würde gelten: Klartext XOR Key = verschlüsselte Daten auch gilt: verschlüsselte Daten XOR Key = Klartext aber auch (wichtig!): verschlüsselte Daten XOR Klartext = Key Damit eine Verschlüsselung dieser Art funktioniert, muss natürlich jedesmal der gleiche Key rauskommen, mit dem man hernach XOR rechnet. Der Key wird errechnet (vermutlich) durch einen Festen Teil und dem aktuellen Datum. ABER: Ich habe zwei Datensätze mit gleicher Uhrzeit (Zeitumstellung) genommen und für diese den Key zu errechnen versucht. In diesem Fall müsste eigentlich der Key gleich sein. DAS IST ER ABER NICHT! D.h. es wird vermutlich NICHT am Schluss verschlüsselte Daten XOR Key gerechnet um das entschlüsselte zu erhalten. Das wirft schonmal Kanditaten wie RC4 (vorerst) aus dem Rennen. Habt ihr Ideen was man sonst noch mit diesen Daten anfangen könnte die im Anhang sind?
Sorry das es so viele Probleme mit dcf77logs.de gibt, seit ein paar tagen macht der Server Probleme ohne ende, und ich weiß ums verrecken nicht woran das liegt. Alles deutet auf die Datenbankverbindung hin, aber das ist nicht das porblem, andere webanwendungen können problemlos darauf zugreifen. Ich versuche das Problem näher einzugrenzen
IDEE: "normalen" (= fast wertlosen PIC) vom gehäuse befreien (gibt im I-Net anleitungen) und dann die Lockbits per UV(-Laser) löschen (wenn man weiß wo auf dem chip die sin), wenns geht dann den gesperrten PIC genauso entsperren und auslesen -> fertig PS: Das hier ist keine Anstiftung zu illegalen TAten, sondern eine eine algemeine Idee wie man einen (versehentlich) gesperrten PIC wider flottkriegt...
So, Ich hoffe das ich nun soweit im Griff habe, sollte es noch Probleme geben nicht Zögern eine mail zu scheriben! So, nun ende mit OT...
aaaaa schrieb: > DAS IST ER ABER NICHT! D.h. es wird vermutlich NICHT am Schluss > verschlüsselte Daten XOR Key gerechnet um das entschlüsselte zu > erhalten. Es muss nur ein Bit beim "selbstverändernden Schlüssel" sein! Wird das Bit für Sommer/Winterzeit mit als Schlüssel genommen, so ist es klar, das bei der So/Wi bzw Wi/So Umstellung bei gleichem Datum und gleicher Uhrzeit anderer verschlüsselter Text vorliegt.
>Max (Gast) >dann den gesperrten PIC genauso entsperren und auslesen -> fertig Und mit dem ausgelesenen HEX stellst du dann genau was an ?
@alex: dachte ich mir auch. Nur dieses Bit wird eben nicht übertragen! Wenn du dir die beiden Übertragungen ansiehst, dann bekommt der Chip die 3 Pakete + Datum/Uhrzeit. (falls ich was übersehen habe, korrigiert mich bitte) @Peter: Wenn ich das ausgelesene HEX-File habe, dann brauch ich noch ein paar Stunden, dann hab ich auch den C-Code zum Entschlüsseln ;-) Mit ein bisschen Assemblererfahrung ist das gut machbar. Weitere Infos zum "aufmachen" des Chips: http://www.rampantapathy.co.uk/12c508a.html Falls es dieser ist, wie schonmal vermutet wurde (evtl. nur mit mehr speicher): Es ist also definitiv möglich! http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf Seite 88 ;-)
Es gibt noch ein anderes Problem: Der Sender bekommt die Wetterdaten anscheinend im Paket per Internet. Im Sendezentrum DCF77 werden die dann an die eigentlichen Zeitdaten angehangen. Werden nun die Wetterdaten mit dem Zeitcode verschlüsselt, dann müßte der Wetterdatendienst die Zeitdaten a priori wissen! Das halte ich aber für unwahrscheinlich, denn die PTB hat noch diverse andere Abhängigkeiten, wie z.B. die Schaltjahrsekunde. So ganz offline können die Daten also nicht ankommen! Hm. Das die PTB die Zeitdaten vorher an den Wetteerdienst sendet, klingt unwahrscheinlich. Das die im Sendezentrum erst verschlüsselt werden, auch. Ich denke weiterhin, das die Wetterdaten anhand eines Seeds aus den Zeitdaten vrschlüsselt werden, wobei nur Zeitbits verwendet werden, die total regelmässig und daher vorhersehbar sind. Also nur einige wenige. Wie gesagt, der Code muß in der Lage sein recht kurzfristig zu initialisieren. Sonst dauern Wetterdaten ewig. Und was macht der Kunde nach dem Kauf der Uhr? Genau, er schaut drauf und will möglichst sofort Wetterdaten sehen.
aaaaa schrieb: > @Peter: > Wenn ich das ausgelesene HEX-File habe, dann brauch ich noch ein paar > Stunden, dann hab ich auch den C-Code zum Entschlüsseln ;-) Mit ein > bisschen Assemblererfahrung ist das gut machbar. Ja ne, iss klar. Träum weiter.
Mit dem richtigen Debugger durchaus machbar. Bis auf textuelle Labels und Kommentare, ist das Programm dann wieder da.
@Peter: Warum nicht? Hab schon einiges direkt in Assembler umgesetzt: Mein letztes größeres Projekt an dem ich arbeitete (war eine Arbeit die man machen musste, Thema durfte aber selbst gewählt werden) hatte eine Bearbeitungsdauer von ca. dreiviertel Jahr und enthält, rein vom Code her, ca. 7.000 bis 8.000 Zeilen Assemblercode. Sicher ist der andere Code nicht mehr ganz so schön zu lesen, weil eben Kommentare, Bezeichnungen für Variablen usw. fehlen. Dennoch ist es aber definitiv möglich das Ding auch wieder "schön" zu schreiben. @Abdul: Wie denkst du läuft die Verschlüsselung genau ab? Also welcher Algorithmus wäre dein Tipp?
Abdul K. schrieb: > Es gibt noch ein anderes Problem: > Der Sender bekommt die Wetterdaten anscheinend im Paket per Internet. Im > Sendezentrum DCF77 werden die dann an die eigentlichen Zeitdaten > angehangen. Das ist ja weiter kein Problem > Werden nun die Wetterdaten mit dem Zeitcode verschlüsselt, dann müßte > der Wetterdatendienst die Zeitdaten a priori wissen! Das halte ich aber > für unwahrscheinlich, denn die PTB hat noch diverse andere > Abhängigkeiten, wie z.B. die Schaltjahrsekunde. So ganz offline können > die Daten also nicht ankommen! Hm. Das die PTB die Zeitdaten vorher an > den Wetteerdienst sendet, klingt unwahrscheinlich. Das die im > Sendezentrum erst verschlüsselt werden, auch. Die Uhrzeit ist vorhersagbar. Dadurch kann der Verschlüsseler auch auf eine Art bestimmen wann ein Datensatz gesendet wird. Eine Schaltsekunde oder Sommer, bzw. Winterzeit (Die 2 Bit) fließen nicht in das Wetterdatendiagramm mit ein (Siehe Eingangsdaten in meinen Logs) Es gibt auch Unter der Rubrik "Besondere Ereigbnisse" wo Wetterdatensätze fehlen, (es werden nur Nullen gesendet) eine Weile vorher wird aber Bit 15 für Störung gesetzt. z.B. http://www.dcf77logs.de/ViewLog.aspx?mode=special&file=17%20-%20St%C3%B6rung.log Es sieht so aus als hätte die PTB einen Puffer von 15 Min > > Ich denke weiterhin, das die Wetterdaten anhand eines Seeds aus den > Zeitdaten vrschlüsselt werden, wobei nur Zeitbits verwendet werden, > die total regelmässig und daher vorhersehbar sind. Also nur einige > wenige. > > Wie gesagt, der Code muß in der Lage sein recht kurzfristig zu > initialisieren. Sonst dauern Wetterdaten ewig. Und was macht der Kunde > nach dem Kauf der Uhr? Genau, er schaut drauf und will möglichst sofort > Wetterdaten sehen. wenn der Glück hat sind diese nach 3 Minuten da, einem Datensatz, (irgend einer der vier Tage), Unabhängig davon was vorher in den Chip hineingegangen ist, ein Datensatz von 82 Bit (80 bit ohne den Alarmbits) genügen um ein Wetterdatendiagramm zu dekodieren.
hoineyNa hallo, da tut sich ja richtig was ;-) also: @Peter W: gibt mir den Hex code: 1 Stunde, dann erklär ich Dir, wie die Chiffre funktioniert. Ist echt kein Thema, da hat Max schon recht. Aber: Chip aufmachen und mit UV-Laser die Bits löschen ist die andere Sache. Theorie soweit - sogut. Ich werd's nicht machen können. Eher mit Semi-Invasiven Angriffen (Vcc Glitch beim Erase etc.) Ich denke aber, hier kommen wir nicht wirklich weiter (wäre ja auch unsportlich ;-) BTW: ein PIC 12x508 wird kaum in C programmiert sein, somit hat man nach dem Disassemly quasi den gleichen Code wie der Programmierer vor dem Assemblieren (...und bei 2K Worten ist das eh Kindergarten.) @aaaaa: ... 0036 04a4 bcf 0x04,5 0037 0213 movfw 0x13 0038 05a4 bsf 0x04,5 0039 01b3 xorwf 0x13,f ... bit 5 an Adresse 4 schaltet die RAM Bänke um (ja, extrem eklig, ist aber so beim PIC, bei den größeren hast Du sogar 4 RAM Bänke. Also: es wird auf die Bank 0 umgeschaltet, dann das Byte von Adress 0x13 nach W geladen, wieder auf Bank 1 umgeschaltet und mit dem dort (also eigentlich mit Adresse 0x80 + 0x13 (weil Bank1) = 0x93 verknüpft. Und: Der PIC rennt nach dem Reset bei Adresse 0 los, da steht ein Sprung nach weiter hinten. Ab Adresse 1 steht die "Schiebe-Register Routine" als Subroutine, wird wohl vom Hauptprogramm aufgerufen. Aber ich sage es nochmal: ich halte das ganze für einen "Honeypot". Es wäre doch ein sehr großer Zufall, dass ausgerechnet das Kernstück der Crypto-Routine als einziges sichtbar ist...ich hätte es auch so gemacht ;-) Wir sollten uns eher auf die Telegramme von Thomas (nochmal vielen Dank an dieser Stelle) konzentrieren. Damals wurde auch ein bisschen herumgemessen. Bit 6 (oder 7) wurde anscheinend beim Einlesen "übersprungen", also nicht verwertet. Macht ja auch Sinn (Alarmbit). Es wurde mal von einem Decoder Chip berichtet, der 1 Bit korregieren konnte (der PIC kann es nicht, habe alle Bits durchprobiert, nur das Alarm Bit war egal). Das spricht dafür, dass die Eingangsdaten auch Korrektur- (oder zumindest Check-) Daten enthalten um Übertragungsfehler zu erkennen, ggf. zu korregieren. Die sollten sich doch finden lassen. Wenn wir das haben, können wir "Choosen Plain (oder eigentlich Crypt) Text Atacken fahren. Das sollte in jedem Falle weiterführen. Ich hatte die Daten von Thomas mal nach Ausgangsdaten sortiert (sollten noch irgendwo hier im Thread oder im alten stehen). Da kam einiges an gleichen zusammen. Gruß, Walter.
Man könnte eines versuchen: zuerst einen bereits gesendeten Code nochmals reinsenden, und schauen ob dieser nochmals decodiert wird. Natürlich bit für bit / sekunde 1 mal. Dann das ganze testen, mit welcher schnelleren Geschwindigkeit das noch funktioniert (nicht das der Programmierer alleine schon an der Schrittgeschwindigkeit ein reverse-engeneering unterbinden wollte). Danach, wenn das geklappt hat, können wir etwas flotter testen, wie was verschlüsselt wurde. Wir senden also den Code nochmals rein, verändern aber diesmal die Sekunde. Bleibt das Ergemnis gleich = Sekunde ist nicht Keyrelevant. So machen wir das dann mit Minute, Stunde, Datum etc. So können wir rausfinden, ob die Zeit ein Codefaktor ist. Danach sollten wir anfangen die vorderen Bits zu verändern, und schaun was als Ergebnis rauskommt. Dumm nur, wenn ein CRC eingebaut ist, und ne Prüfsumme mitübertragen wird.
Wenn die Zeit da ist kann ich über Ostern ja mal einen weiteren Decoder an den Server Anschließen, welchen Ihr dann für eure zwecke nutzen könnt. Nachteil ist nur, das lediglich alle 40s ein Datensatz dekodiert werden kann. Ich habe noch 2 weitere Decoder, einen für Entwicklungszwecke (DCF-Reciever software) und einen weiteren als Backup-decoder, welcher an meinem Standrechner läuft. Als einziges lässt sich Bit 7 Kippen, dies ist bei alarmsituationen gesetzt, ebenso wird bit 0 für Alarmsituationen verwendet, lässt sich aber nicht kippen, Vermutlich prüft der Chip damit, ob es sich hier um ein Wetterdatensatz oder ein Alarmdatensatz handelt. sobald nur ein bit an den Daten der Urzeit gekippt wird (gut ich habe ncht jedes einzelne getestet) Wird nicht mehr dekodiert. Einen Datensatz kann man immer und immer wieder dekodieren, mit gleichem Ergebnis.
War nicht erwähnt, es würden Bitfehler korrigiert? Erst war die Sprache von zwei, später wurde das auf einen verifiziert. Wenn ich recht erinnere. Jetzt auf einmal keiner mehr? Ich habe leider keine Idee, wie der Algorithmus bzw. sein Schlüssel aussieht. Aber so ein PIC ist nicht riesig und kann wohl auch kein Flash für Daten bereitstellen zur Laufzeit (??), oder sich selbst durch Programmcode zerstören (??). Meiner Meinung nach, kann man bei der PTB einfach Bitmengen mieten. 2 wurden an den Alarmdienst vergeben. Die anderen eben an den Wetterdienst. Im Sender werden die Bits einfach nur noch per Maske verodert. Naja, vielleicht denke ich auch praktischer als die Leute bei der PTB ;-) Es kann natürlich auch mehrere Code-Versionen geben! Sowohl was den PIC angeht, als auch die übertragenen Codes. Wenn einer verschlissen ist (gehackt), wird der nächste benutzt. Mal sehen wie lange der Thread noch da ist. Thomas, walte deines Amtes!
Hallo, Was die bitfehlerkorrektur angeht, Es scheint Chipabhängig zu sein, der Chip von Texter damals konnte glaub ich ein Bit korrigieren, meine können das alle nicht,... Meine Chips stammen alle aus Tfa Meteotronic start/profi Diese haben die gleiche Platine, der unterschied ist nur das Display.
Thomas Berends schrieb: > sobald nur ein bit an den Daten der Urzeit gekippt wird (gut ich habe > > ncht jedes einzelne getestet) > > Wird nicht mehr dekodiert. Vielleicht solltest du dann auch das Pariätsbit mitkippen. Dann ist alles wieder ein gültiger Datensatz. Wird dann das selbe dekodiert?
Das Paritätsbit fließt nicht in die 80 Bit Eingangsdaten mit ein!
1 | IN: - Datenpaket 1.....................: 01100100010111 |
2 | - Datenpaket 2.....................: 01101111101010 |
3 | - Datenpaket 3.....................: 10010100010001 |
4 | - Minute...........................: 01000000 02 // 8 Bit Minuten |
5 | - Stunde...........................: 00000000 00 // 8 Bit Stunde |
6 | - Tag..............................: 10011000 19 // 8 Bit Kalendertag |
7 | - Monat............................: 00100 04 // 5 Bit Monat |
8 | - Wochentag........................: 010 2 // 3 Bit, ergibt mit Monat 8 Bit |
9 | - Jahr.............................: 10001000 11 // Jahreszahl 8 Bit |
Nirgends wird eine Parität verwendet. Die Parität dient nur zur übertragung vom Sender zum Empfänger, dieser kann damit gegenprüfen, ob ein Telegramm richtig empfangen wurde, macht auch wenig Sinn das der Decoder zusätzlich die Parität überprüft, wäre dann ja Doppelt, dieser Muss nur Prüfen ob die Wetterdaten korrekt entschlüsselt wurden, weil dies ja nicht vom Empfänger geprüft werden kann.
Wie ist das eigentlich: Sollte eine gute Verschlüsselung nicht so aussehen: Die Daten haben "rein zufällig" 0 und 1 an den jeweiligen Positionen. Das wird ja für die höheren Bits über 15 recht gut erreicht. ABER: Die niedrigeren Bits sind doch viel regelmäßiger. Seid ihr euch überhaupt sicher, dass diese Bits in die Verschlüsselung einfließen und dass dies NICHT eine (evtl. unverschlüsselte) Prüfsumme ist? Das würde dann zwar nicht mit der Patentschrift übereinstimmen, aber noch weniger glaube ich, dass der Anfang eines verschlüsselten Pakets so wenig "zufällig" ist, und dann ab Bit 14 oder so, die Werte nahezu perfekt sind. Was denkbar wäre, ist, dass diese Daten eine Art Initialisierungsvektor sind. (wenn man weiterdenkt könnte man auch vermuten, dass man bewusst manche schwache Vektoren ausgelassen hat. Gab damals ein ähnliches Problem bei WEP) Es würde dafür sprechen, da diese Bits nicht verschlüsselt sein können und auch nicht nicht genau 50% 1 und 0 haben müssen.
Hallo aaaaa, wie Thomas schon angemerkt hat: es gibt anscheinend Chips, die korregieren können. Meiner Meinung nach dürfen diese Korregierenden Code nicht verschlüsselt sein da im Falles eines Übertragungsfehlers im verschlüsselten Prüf/Korrektur Teil keine Korrektur mehr möglich ist. Ich nehme also an, dass zuerst die Nutzdaten verschlüsselt werden und dann die Korrekturdaten angehängt (oder vorangestellt) werden. Es stellt sich noch die Frage, ob die Korrekturdaten "nur" über die Wetterdaten erstellt werden oder auch den Zeitstempel mit einschließen. Wir haben somit vermutlich 22 Bit Wetter 18 Bit Korrektur 40 Bit Zeitstempel In Summe 80 Bit, die in den Controller reingeschoben werden Weitere Mutmaßung: Wetter und Zeit sind zusammen 62 Bit Nimmt man z.B. 2 Bit für Fehlererkennung (mini Hash), dann bleiben 16 Bit für Korrektur. Mit 16 Korrekturbit kann man z.B. eine Matrix von 8x8 aufspannen Könnte so aussehen: WWWWWWWW P WWWWWWWW P WWWWWWFZ P ZZZZZZZZ P ZZZZZZZZ P ZZZZZZZZ P ZZZZZZZZ P ZZZZZZZF P PPPPPPPP W: Weterbit F: Fehlererkennung Z: Zeitbit P: Paritätsbit Wenn jetzt ein Wetter oder Zeitbit kippt, stimmen 2 Paritäten nicht mehr (einmal Zeile, einmal Spalte), damit kann ein Bit korregiert werden. (Achtung: alles nur eine Überlegung) Generell könne aber auch ein stärkeres Korrekturverfahren eingesetzt werden, wie BCH (z.B. Reed-Solomon) Zur der Schieberegisterroutine: Hier werden anscheinend alle 80 Bit behandelt. Wäre ja nicht nötig, da 16 Bit davon anscheinend für die Fehlerkorrektur verwendet werden und auch nicht mögliche, da diese ja garnicht in die Verschlüsselung miteinfließen, da sie zum Zeitpunkt der Verschlüsselung noch garnicht bekannt sind. Bitte korregiert mich, wenn ich falsch liege. Gruß, Walter.
Nachtrag:
Um das ganze zu Vereinfachen nutze ich jetzt einfach mal die gängigen
Abkürzungen:
P -> Plaintext, Klartext
C -> Chipher text, verschlüsselte Daten
K -> KEY
E -> Fehlererkennung / korrektur
ich gehe davon aus, dass C abhängig ist von:
- P
- K (Zeitstempel)
- S evlt. ein Schlüssel
Ich vermute, dass C immer unterschiedlich ausfallen, da K immer anders
ist.
Wenn sich die 40 Bit wirklich aus C und E zusammen setzen und E durch
eine Paritäts-Matrix gewonnen wird müßten sich die 40 Bit mindestens um
3 Bit unterscheiden (ein geändertes Bit in C und folglich 2 geänderte
Bits in E).
Ich werde die Daten von Thomas mal daraufhin untersuchen.
z.B. sind hier 2 Datensätze, die sich nur um 1 Bit in K1 unterscheiden
und sich in P gleichen:
vv vvvv vvvvv vvvvvvvvv vvv vv vvvvv
C1: 1100100010111000110110111000001111001000
C2: 1111100101010111011001000110110100010111
v
K1: 00011100_0_1100000001010001001010010010000
K2: 00011100_1_1100000001010001001010010010000
^
P1: 0100010000000100100101;10 Mo, 14.09.2009, 06:38 Uhr
P2: 0100010000000100100101;10 Mo, 14.09.2009, 07:38 Uhr
In C+E sind 10 Bit identisch, 30 unterschiedlich (bei einem Bit
Unterschied in K)
noch ein Beispiel:
v vv vvvv vv v vvv v v v v
C1: 1010010010110010100100011000010101111000
C2: 1000011110111101111110010110110111101100
v
K1: 10010100_1_1001000010010000010011110010000
K2: 10010100_0_1001000010010000010011110010000
^
hier haben wir 23:17 (23 gleich, 17 unterschiedlich)
P1: 0100010000000100100101;10 So, 12.04.2009, 13:29 Uhr
P2: 0100010000000100100101;10 So, 12.04.2009, 12:29 Uhr
und noch ein drittes Beispiel, diesmal die Abweichung an stelle X:
vvvvvvv v v vv v v vvv vv v vvv
C1: 0011101100111010111010101111011111110010
C2: 1100010110110001110000010100011011101110
v
K1: 011001000_0_000000000001000010010010010000
K2: 011001000_1_000000000001000010010010010000
^
P1: 0100010000000100100101;10 Mo, 20.04.2009, 00:26 Uhr
P2: 0100010000000100100101;10 Mo, 20.04.2009, 02:26 Uhr
hier: 18:22
Wie eingangs erwähnt gibt es vielleicht noch ein S, mit dem K so
bearbeitet wird, dass die "Konfusion" möglichst groß wird, es also keine
ähnlichen Ks gibt.
Soweit meine momentanen geistigen Ergüsse - ich gehe mich sammeln und
lasse meinen Rechner nach geringen Abweichungen in C suchen.
Walter.
hat einer von den mitlesenden einen Chip, der auch Korrigieren kann? Bzw. kennt wer erhältliche (und bezahlbare!) Stationen die das können? Denn dann könnten wir mal klären, welches der 3 Datenpakete überhaupt WAS enthält. Wenn man nämlich z.B. 2 Bits (die nicht auf der gleichen Seite sind in dieser Fehlerkorrekturmatrix!) in der oben beschriebenen Fehlerkorrektur ändern würde, dann müsste sich das dahin auswirken, dass ein Bit der Daten "korrigiert" wird. Ein weiterer Schritt wäre, der aber sehr viele Versuche und Zeit erfordert: Herausfinden wo genau die Daten stecken. Ein 1 Bit Fehler würde immer korrigiert werden. Wenn man aber 2 mal einen 1 Bit Fehler hätte, dann würde das (sofern er nicht erkannt wird) zu 2 gekippten Bits in den entschlüsselten Daten führen. Evtl. wäre es sinnvoll, wenn man ermitteln würde, was wir da überhaupt vor uns haben. Denn dass die ersten 14 Bit wirklich verschlüsselte Daten sind glaube ich kaum. Sonst wäre das viel "schöner" verteilt mit den 0 und 1.
aaaaa schrieb: > Wie ist das eigentlich: > Sollte eine gute Verschlüsselung nicht so aussehen: Die Daten haben > ... > Was denkbar wäre, ist, dass diese Daten eine Art Initialisierungsvektor > sind. (wenn man weiterdenkt könnte man auch vermuten, dass man bewusst > manche schwache Vektoren ausgelassen hat. Gab damals ein ähnliches > Problem bei WEP) > Es würde dafür sprechen, da diese Bits nicht verschlüsselt sein können > und auch nicht nicht genau 50% 1 und 0 haben müssen. Es können keine 50% sein! Niemals!! Verschlüsselung muß immer eine Asymmetrie haben, allerdings kann die auf höherer Ebene erfolgen! Sollte auch, sonst ist das System mit den heutigen Methoden zu leicht knackbar. Ich nenne das mal eine innere Verschränkung der Vektoren. Kryptos werden dafür sicherlich bereits Begriffe geprägt haben. Die einzige Ausnahme ist die unknackbare Methode, einen Datenstrom per XOR mit einem Zufallsstrom zu verknüpfen. Ist der Zufallsstrom hinreichend gut zufällig und länger als der Datenstrom, so ist es prinzipiell nicht knackbar! Hier kann also Symmetrie herrschen, muß aber nicht in der Praxis! Daher der Begriff hinreichend. Diese Methode kanns aber nicht sein, den der Zufallsstrom ist bei den Wettersystem nicht vorhanden. Was mir noch einfällt: Die Sache mit den 15 Minuten Paketen zur PTB stand irgendwo bei denen! Das scheint also sehr wahrscheinlich. Vielleicht findet man in den Logs einen Aussetzer von genau 15 Minuten.
Abdul K. schrieb: > Was mir noch einfällt: Die Sache mit den 15 Minuten Paketen zur PTB > stand irgendwo bei denen! Das scheint also sehr wahrscheinlich. > Vielleicht findet man in den Logs einen Aussetzer von genau 15 Minuten. Siehe da, nach 15min der Störung werden keine Wetterdaten mehr gesendet: http://www.dcf77logs.de/ViewLog.aspx?mode=special&file=17%20-%20St%C3%B6rung.log Hier sind es 13 minuten: http://www.dcf77logs.de/ViewLog.aspx?mode=special&file=18%20-%20St%C3%B6rung.log Das könne einen 15min-Puffer andeutetn, dies habe ich dort aauch schon geschrieben Beitrag "Re: Was ist aus dem Thread der MeteoData geworden?" Bearbeitungsgrund: Links korrigiert
noch ein Link zum Thema Chip Gehäuse öffnen.http://cms.diodenring.de/en/electronic/mikrocontroller/83-ic-decapsulation Scheint nicht so ein abwägiger Weg zu sein.
würde ich gerne ausprobieren - wo bekomme ich NHO3 mit 90% her ;-)
Zur Not in der Apotheke. Gruß Thomas
Walter Freywald schrieb: > würde ich gerne ausprobieren - wo bekomme ich NHO3 mit 90% her ;-) ich denke das wäre noch die Vorgehensweise mit dem größten Erfolgsversprechen. denn möglich ist es definitiv. hab auch mal gegoogelt: scheint mehrere händler zu geben die das Zeug verkaufen, allerdings nur mit ca. 60%. sollte auch gehen? würde vermutlich nur länger dauern
aaaaa schrieb: > nur mit ca. 60%. sollte auch gehen? würde > > vermutlich nur länger dauern Zitat von der seite in meinem Link: "Warum geht nicht auch 65%ige HNO3? Diese enthält zuviel Wasser. Das führt zu zwei Problemen: Zum einen läuft die Reaktion mit dem Kunststoff stark verlangsamt ab, zum anderen greift die verdünnte Säure das Kupfer des Pads und der IC-Beinchen an. Interessanterweise tut das die 90%ige Säure nicht (zumindest nicht so sehr)." Scheinbar ist die Säure in der Wasser enthalten ist gegenüber Metallen agressiver. Säure zum Ätzen von Leiterplatten hat ja auch eine bestimmte Konzentration und ätzt nicht zwangsläufig schneller wenn sie höher konzentriert ist.
Und dann haste einen freien Chip! Und was dann? Oder hat jemand den passenden Laser und weiß wo er brennen muß? Und vergeß nicht den schweren Marmortisch! Im Hochhaus wird das also nix. Bei der Vorgehensweise würde ich dann eher eine Sammelaktion für die 1000 Euronen durchführen. Es gibt ja ein Angebot. Sogar nach DE-Recht. Eigentlich sind die Wetterdaten eh uninteressant. Das Ganze erinnert stark an Nintendo-Sammelkarten auf dem Schulhof. Viel Spaß und Tränen, wenig Sinn, viel Kosten für die Eltern. Die einzige mir interessant erscheinende Anwendung, wäre die eigene Nutzung für Projekte, sollte sich die Übertragung als robust und gut verschlüsselt, erweisen. Die 1-Bit Fehlerkorrektur mit 2-Bit Fehlererkennung wäre dann aber das mindeste, denn es gibt viele Alternativen.
Abdul, hast Du nicht den Sinn des Ganzen begriffen? Es ist die Ambition herauszufinden wie es geht! Natürlich könnten wir uns selbst eine Verschlüsselung ausdenken. Aber das ist ja nicht Sinn der Sache. Auch könnten wir jemand Geld geben, der das macht! Einfach wäre es den Programmieren zu schmieren. Aber das ist nicht das Ziel! Ziel ist es, es zu können! Das ist wie mit den Leuten, die Zuhause an einem Schließzylinder "Lockpicking" betreiben. Nur um es zu können, und nicht um später irgendwo einzubrechen...
Ja ja. Der zweite deinige Absatz hat aber wenigstens praktischen Nährwert -falls du mal vor der eigenen Haustür stehst. Wer der Programmierer ist, ist übrigens unbekannt. Hatte mal geforscht, aber keinen gefunden.
Abdul, glaubst Du die "Lockpicker" haben ihr Werkzeug immer dabei, falls mal der Schlüssel weg ist? Zudem ist dieses Projekt hier im etwas zu lernen. Aber Information wird wohl anderst gewertet als materielle Dinge... Ich hab mittlerweile den Verdacht, Dir passt es nicht, das wir dort forschen! Leiste bitte konstruktiven Beitrag, oder lass es! Rumstänkern bringt nichts, und macht nur den Thread kaputt.
Schön, das die Anfeindung von Alex nicht gelöscht wurde, meine Verteidigung aber sehr wohl! Leute, ich habe da verständlicherweise keine Lust mehr. Wer weiterdiskutieren will zum Thema, findet mich an besagter Stelle. Kennt ihr ja.
Zurück zum Thema: @Abdul K. ich habe was von ner Maske gelesen (ja, ruhige Hand sollte man beim Ausschneiden haben ;-) Die legt man auf den Die und geht mit nem "normalen" UV Löschgerät ran. So ein Teil hab ich. Teilweise liegen die "Lockbits" weit genug vom "Restflash" entfernt. Zur Analyse: Ich lasse gerade eine SW über die Daten von Thomas laufen, die Datensätze mit 4 oder weniger Bitunterschieden suchen. Da scheinen einige zu sein. Im Anhang ein Auszug von den bisherigen Daten Die Zahl vor der ersten Zeile ist die Zeilennummer (Referenz), die Zahl vor der 2. Zeile die Anzahl der Bitunterschiede. Wenn die SW durch ist (sind ja nur schlappe 217000 Zeilen) hänge ich mal die komplette Liste an. Gruß, Walter.
@ Walter, Die datensätze die vor einem Bestimmten zeitraum dekodiert wurden, wurden mit einer testsoftware aus den empfangenen Logdateien dekodiert, diese Logdateien beginnen mit "WETEOTIME Wetterdaten" hier kann ich keine Gewähr auf richtigkeit geben, wie man auch im ersten datensatz aus deiner simms.txt erkennen kann, ist dort als Quittierung 00 = Fehlgeschlagen und nicht das herkömmliche bitmuster bei fehlerhafter dekodierung. Zu der Zeit hatte ich noch nicht die richtigen timings (USB Adapterchip Eingang zu träge) laufen. Ich werde die Logdateien welche falsch sein könnten, nachträglich dekodieren, sodass ihr da korrekte Daten habt. Auch wenn es sich dabei nur um <10% der Gesamtdatenmenge handelt. Ich dachte bisher das sich das nur auf einzelne Datensätze auswirkt aber es sind offenbar mehrere nicht korrekt. Es handelt sich hierbei um die Logdateien DCFLog00001.log bis einschließlich DCFLog00115.log Ich werde diese ab morgen nochmal durch den Decoder jagen. Gruß, und gute nacht Thomas.
@Thomas: danke. Meine Überlegung ist wohl doch etwas fehlerhaft. Ich habe der Verleich abgebrochen (Ergebnis im Anhang). Es kommen durchaus Datensätze mit nur 3 Unterschieden in den ersten 40 Bit vor. Dafür sind aber einige Unterschiede im Zeitstempel. Da die Fehlerkorrekturdaten den Zeitstempel wohl mit einschließen muß ich diese also auch berücksichtigen. Neue Überlegung, neuer Versuch: Ich führe jetzt 2 Vergleiche durch, einmal für die ersten 40 Bit, einmal für die zweiten 40 Bit und stelle alle die Datensätze dar, der Unterschiedssumme < 11 ist. Gruß, Walter.
Hallo leute, das Ganze ging doch schneller als erwartet, ich habe hier jetzt einen Decoder online gestellt, vorherst nur einen, da ich den anderen nur zum durchlaufen der Logdateien bebötige. Wer Zugriff auf den Decoder erhalten möchte, dem Bitte ich um eine PN, da gebe ich dann den Link aus. Gruß Thomas
Zur Fehlerkorrektur, die ist vollständig dokumentiert aus einem Bericht über die verwendung des DCF Signals für den Zivilschutz vor der Verwendung als Wetterdaten. Die Gültigkeit ist verifiziert. Zum Pic. Es wurde ein modell ermöglicht, wo die ersten 64 bytes nicht verschlüsselt und immer programmierbar sind. Nur von 1 auf 0, aber das reichte um genügend Einblick in die Entschlüsselungsroutine zu haben und um sei es durch injekting wrong code als auch durch dumping intermediade results den Datenstrom zu entschlüsseln, auch wenn immer noch die Möglichkeit besteht, daß mehrere Systeme vorhanden sind und die dann über den Sender umgeschalten werden kann.
Hallo, Nachtrag: Ich habe doch entschlossen den Link allen zur verfügung zu stellen, http://www.dcf77logs.de/DecoderAccess.aspx Gruß Thomas
Thomas Berends schrieb: > Ich habe doch entschlossen den Link allen zur verfügung zu stellen, > http://www.dcf77logs.de/DecoderAccess.aspx Nicht schlecht, und per Datenbankabfrage werden auch keine gleichen Daten zweimal dekodiert nehme ich an.
Die ganzen DCF-Logs sind nicht in einer Datenbank gespeichert, das einzige was in einer Datenbank gespeichert ist, ist der Zeitraum einer Logdatei. Es geht alles direkt an den Decoder, keine umwege über eine Datenbank oder ähnliches. Das heißt wenn 2mal hintereinander das gleiche rein geht, dann wird der decoder auch zweimal genutzt. Aber Vielen Dank für den Vorschlag, so könnte ich die Auslastung des Decoders verringern, in dem ich die datenbank ausnutze. Ich mahc mich dann mal gleich an die Arbeit
So, nun werden bereits dekodierte Datensätze aus der Datenbank geholt, diese ist jetzt noch ziemlich leer. Die Meteologs werden nicht als Datenquelle genutzt. Sollte das ergebnis mal 111111111111111111111100 sein ist dies ein Indiz, das etwas mit der hardware nicht stimmt, sollte das wiederholt der fall sein, bitte ich um eine kurze email.
chris: bist du das "original" aus dem anderen thread? Habt ihr schon Erfolge mit eurer technik gehabt? konntet ihr den algorithmus identifizieren? hättest du noch weitere details zur fehlerkorrektur?
So, habe mir gerade die Daten angeschaut, bei denen das Ergebnis 22x 0 herauskommt. Es waren ja fast 25 Stunden, 472 Telegramme. Interessant (siehe angehängtes File): ein Telegramm hat bei den Eingangsdaten nur 22 Einsen (2011'0121:2008). Ein Telegramm mit 26 Einsen hat 12 führende Nullen (2011'0121: Als Maximum sind 3x 42 Einsen im Eingang. Die zweistellige Zahl nach dem Leerzeichen ist die Anzahl der Einsen. Ein Telegramm ist dabei, bei dem nur ein Bit im Ergebnis gesetzt ist (2011'0121:2002). Dort sind im Eingang 27 Bits high. Noch eine Unstimmigkeit: 000000000000000000010000 01 2009'0718:0720 steht im Log 010001000000010011010110 08 2009'0718:0720 gibt der decoder aus Thomas, könntest Du bitte die Decoder-Abfrage noch erweitern, sodass die Ein- und Ausgabe decodiert und kompakt angezeigt wird? Das Datumformat 2011'0423:1125 wäre mir ganz recht. Woher kommt eigentlich das Gerücht der 13 Abgriffe des Schieberegisters? Ich glaube, wir kommen so nicht weiter, das ist nur ein Stochern im Trüben, ich sehe nur zwei Möglichkeiten: wir besorgen uns eine größere Menge an Decodern und klemmen die an µCs, die dann systematisch alle sinnvollen Kombinationen abgrasen. Wie lange dauert eine Abfrage insgesamt? 280ms? Oder wir machen die ICs auf. Hat jemand ein Foto des PICs, auf dem man erkennt, wo die Fusebits sind? Oder wir versuchen es nochmal mit den Powerspikes, das kann doch nicht soo schwer sein.
@chris: schon lange nichts mehr gehört. Hast Du was herausbekommen ? Ich habe mal die Vergleiche angehängt. Weiß noch nicht genau, was wir daraus erkennen können, vielleicht hat ja jemand ne Idee. Aufbau: Erste Zeile vor dem Doppelpunkt: Zeile, mit der Verglichen wird Zweite Zeile vor dem Doppelpunkt: Unterschiede in Crypt, Unterschiede im Zeitstempel. Das Kleinste, was ich im Crypt gefunden habe ist 3, das Kleinste im Zeitstempel ist 1 (ist klar), das Kleinste in Summe ist 3,5 4,4 5,3 also immer mindestend 8 Unterschiede in den ersten 80 Bit Gruß, Walter.
@eProfi, in n Logdateien vor Februar 2009 können Datensätze falsch sein, hier handelt es sich um die Ersten nachträglich dekodierten Datensätze, damals gab es noch Probleme mit den Timings, vor 10 oder 11 Posts habe ich darauf aber noch hingewiesen... bis einschließlich dcflog00115.log ich bin dabei diese datensätze neu zu entschlüsseln, dies dauert aufgrund der Wartezeit zwischen den Vorgängen jedoch mehrere Tage bis Wochen.
Thomas: Du beziehst Dich auf 21.04.2011 00:46. Du gibst Du nicht 100% sicheren Logs bis 115 an, mein Beispiel ist aber MeteoLog_DCFLog00316.log Könntest Du so gut sein und meine anderen Punkte beantworten? Vor allem: wie lange dauert eine Dekodierung insgesamt? Kann ich Dir eine Datei mit Telegrammen schicken, die der Dekoder dann im Batch-Betrieb abarbeiten kann (wenn nichts anderes zu tun ist)? Vielen Dank für Dein / Euer tolles Engagement! Chris: hast Du bitte einen Link (oder einen anderen Hinweise / Suchbegriff) auf die Beschreibung der Fehlerkorrektur? Toll, dass Du Dich wieder meldest!
@chris, könntest Du mir bitte den Patch zukommen lassen, hatte damals leider nicht geklappt. Würde damit gerne ein bisschen herumexperimentieren. Danke. Walter.
offenbar sind da mehr datensätze kaputt als ich dachte. das kommt vor allem vor wenn der decoder meldet, dass er nicht bereit ist, gelegentlich setzt der seinen RDY-Ausgang für ein paar µs auf Ready und das wird dann offenbar vom dcf-receiver falsch interpretiert. Leider weiß ich nicht wann genau ich dieses Problem entdeckt und beseitigt habe. jedoch sollten diese Datensätze die äußerste ausnahme darstellen, alle Datensätze mit 00 am ende sind sowieso fehlerhaft, da die letzten beiden bit nur den Decoder-Status darstellen! Außerdem kann ich dort an dem Punkt sagen das ich 18.07.09 um 7:20:15 morgens den RAM des PCs zugemüllt habe, aus irgendeinem Grund fraß der Webserver so dermaßen viel RAM das der DCF-Receiver mitten in dem dekoder nicht mehr genug daten geben konnte und es zu dem resultat kam, zumindest sagt dies eine Systemlog aus, das der Webserver aufgrund massiven Speicherbedarfs automatissch beendet wurde. Zur Antwortzeit des Decoders weiß ich nicht viel, Ich bin mir absolut unsicher, vermute dort aber eine Zeit zwischen 180 und 250ms. ein Kompletter dekodiervorgang Eingeben und Rausholen der Daten inklusive dauert etwas über eine Sekunde. Ich mache das ganze mit dem PC, alles Softwarebasiert, und nicht mit einem Mikrokontroller. Die einzige Hardware ist der USB-Adapter und der Chip selbst. Im Ursprünglichem Thread wurde dies genau gemessen. Eine Datei mit Datensätzen kannst du mir gerne geben, jedoch muss cih erstmal meine Decoding-Anwendung umschreiben, weil diese in der Regel die DCF-Datensätze dekodiert, sprich drei minuten-sätze einließst, aufbereitet und an den Decoder sendet (dürfte aber nicht all zu aufwändig sein). Aber die ersten 115 Logdateien sind eventuell Fehlerhaft, und diese Dekodiere ich jetzt. Zum Parsen des Datums und der Urzeit, Ich möchte ungern noch etwas an der DCF-Seite ändern, da das ding immoment schon so dermaßen verfrickelt ist, und jeder kleinste eingriff schon immensen aufwand verursacht. montag und Dienstag habe ich noch frei.
Ich habe gerade nochmal den "alten" Thread durchgelesen. Im Beitrag von Dexter (25.08.2007, 13:37): - 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. Ich interpretiere: - Fehlerkorrektur gilt nur für Crypt Daten - Fehlererkennung gilt für Crypt und TimeStamp Ich bin verwirrt ! @chris: bitte hilf mir auf die Sprünge mit der Fehlerkorrektur. Danke. Gruß, Walter.
Walter Freywald schrieb: > - 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. Für den derzeit online abfragbaren Chip scheint das nicht vollständig zu stimmen: Bit 0 und 7 kann man zumindest bei einigen willkürlich rausgesuchten Nachrichten einzeln oder gemeinsam kippen ohne die decodierte Ausgabe zu verändern. Alle weiteren Zwei-Bit-Fehler mit invertiertem Bit 0 und einem weiteren invertierten Bit resultierten in Fehler-Ausgaben (100010000000100000001110), der verwendete Teststring (ohne Invertierungen) war 011100100110100010101011111011001011101101001000100000000000100100001001 1110001000. Vielleicht schiebt ja irgendwer anderes noch die weiteren 3240 möglichen Eingaben mit Zwei-Bit-Fehler durch den Chip.
Ich hab mir ein Skript geschrieben das gerade alle 2-Bit Fehler durchprobiert und an tommys decoder schickt. Ich mache aber erstmal nur 2-bitFehler auf den ersten 42 Bit. Alleine das dauert schon lange genug... Wird noch einige Stunden laufen (kann ja nur 1 mal pro Minute oder so nen Code reinschicken) bis ich Ergebnisse habe.
Ich habe soeben den 2. decoder für den webzugriff freigegeben, @aaaaa, du darfst dein intervall um die hälfte verkürzen, alle etwa 25s kannst du nun daten reinschicken... dann dürfte es schneller gehen. leider habe ich nur die ersten 29 Logdateien dekodiert, es dauert einfach zu lang.
Hallo, @Thomas: super, vielen Dank für die DoppelDecoder Seite ;-) ich hab mal weiter verglichen und folgende Zeilen gefunden (s.Anhang) es sind also nur 2 unterschiede in den ersten 40 Bit (bit 0 und Bit 7 hab ich vorher entfernt). Vielleicht hat ja jemand eine tolle Idee dazu. Weiter ist mir aufgefallen, dass in der Patentschrift von 42 (3*14) Datenbit gesprochen wird, 22 Daten (würde ja passen) und 20 Fehlerprüfbit, nur fallen bei uns ja Bit0 und Bit7 weg, also bleiben 20 Bit Daten oder 22 Daten und 18 Korrekturdaten. Wenn dem so ist, dann ist das Patent IMHO wertlos, oder schließt das andere Bitaufteilungen mit ein ?
Angehängte Dateien:
-
Diffs.png
3,1 KB
und noch was: ich habe pro stelle (1-40) das Auftreten von Unterschieden aufsummiert. Dabei zeigt sich eine deutliche Stufe von Bit 1-12 -> 13-40 (s.Anhang). Die durchschnittliche Unterschiedssumme liegt im ersten Bereich ( 1-12) bei ~2213 (13% unter dem Gesammtdurchschnitt) im zweiten Bereich (13-40) bei ~2697 (6% über dem Gesammtdurchschnitt) im gesammten Bereich (1-40) bei ~2552 Ich bin mir noch nicht ganz klar, was das bedeutet - I'm thinking... Walter.
Hallo, erste Ergebnisse aus meinen weiteren Versuchen mit tommys decoder: 2-Bit-Fehler werden immer erkannt. Habe alle Möglichkeiten in den 3*14 Datenbits durchprobiert. Ausnahme: Bit 0 und 7 kann man auf 1 kippen, das ändert nichts. Ansonsten gibt es aber keine Ausgabe, sondern nur einen Fehler. Also fassen wir zusammen: Erkennen und Korrigieren von 1-Bit-Fehlern ist möglich (Korrigieren nur mit Spezialdecodern) Erkennung von 2-Bit-Fehlern scheint auch immer möglich zu sein (Korrektur aber offenbar nicht, auch nicht mit Spezialdecoder) So ein Prüf-Raster wie weiter oben beschrieben, würde dieses Verhalten aufweisen. Der nächste Schritt wäre jetzt: 3 Bits gleichzeitig zu kippen. Mit den aktuellen Decodern würde es aber ca. 4 Tage dauern (wenn man jede Minute 2 Möglichkeiten probiert) um alle Möglichkeiten zu testen. ;-) Ich werde deshalb erstmal nur zufällige Bits kippen und schauen ob man da evtl. auch schon was erreichen kann. Mit etwas Glück finden wir da Zusammenhänge.
Nachtrag: im Beitrag: Autor: Deschutes (Gast) Datum: 12.08.2010 23:14 hat er die Verteilung von 1 und 0 gemessen und kommt ebenfalls zu dem Ergebnis, dass die ersten 14 Bit (oder 12 Bit ohne Bit 0 und Bit 7) ein anderes Muster zeigen als die restlichen 28 Bit, geht also analog mit meinem Ergebnis. Hat jemand dazu ne Idee ? Gruß, Walter.
Hallo, Ich habe mal einen Schuß ins Blaue... wenn es sich um eine Schieberegister handelt, schiebt vieleicht jemand zuerst die Zeit durch das Register, und erzeugt immer einen anderen Anfangsvektor. Da man die Zeit kennt, könnte man hier einen Bitfehler sogar korrigieren. Die Zeit hat evtl. nicht so eine hohe Varianz?
also nach ca. 24 Stunden kann ich sagen: 3 Bit-Fehler wurden jetzt JEDES mal erkannt. Es wurde kein einziges Paket dekodiert. Getestet wurden ca. 2000 Möglichkeiten.
Auch bei 4-Bit Fehlern tut sich bisher nix.
Was könnte das für eine Check sein?
Sowas wie CRC würde in Frage kommen, oder?
Bei Wikipedia steht folgendes was ziemlich genau passen müsste:
Erkannte Fehler (nach der Bitfiltertheorie) [Bearbeiten]
Der Vollständigkeit halber sei hier folgendes ergänzt:
Ein beliebiges Generatorpolynom erkennt sämtliche Bündelfehler, die
nicht länger als das Generatorpolynom sind - bis auf eines, nämlich
jenes, welches das gleiche Bitmuster hat wie das Generatorpolynom. Das
beinhaltet natürlich auch 1-Bitfehler als Bündelfehler der Länge 1.
Ein Generatorpolynom mit gerader Anzahl von Termen erkennt jede
ungerade Anzahl von Bitfehlern.
Mit der Bitfiltertheorie lässt sich zeigen, dass nur solche
Zweibitfehler nicht erkannt werden, deren Abstand ein Vielfaches des
Zyklus der Periode des längsten Bitfilters ist. Bei optimal gewählten
Generatorpolynomen vom Grad n mit gerader Anzahl von Termen ist dieser
Abstand 2n − 1 − 1, also beispielsweise bei n = 16 beträgt diese Periode
immerhin 32767, also mehr als 4000 Bytes!
Es lässt sich ähnlich zeigen, dass alle Einbitfehler korrigiert
werden können, wenn der Datenblock nicht länger als die eben erwähnte
Periode ist. Das folgt daraus, dass die Reste nach Division durch das
Generatorpolynom alle verschieden sind - so weit man verschiedene Reste,
von denen es höchstens 2n gibt, haben kann. Allerdings lassen unter
Umständen 3-Bitfehler die gleichen Reste, so dass in diesem Fall eine
Korrektur das Ergebnis noch mehr verfälschen kann. Allerdings sind 1-
und 2-Bitfehler immer mit Sicherheit zu unterscheiden.
Genaueres entnehme man der Referenz Analyse des CRC-Verfahrens mit
Bitfiltern. Dort findet sich auch eine Liste optimaler Generatorpolynome
verschiedener Grade.
Interessant: Wie wir schon festgestellt haben werden 1-Bit Fehler von
manchen Chips korrigiert. Auch das kommt hier vor.
Kanns evtl. CRC12 sein? Evtl. auch mit einem alternativen Polynom?
Ich habe folgende Zeilen gefunden (s.Anhang 0diff_cipher.txt) Diese haben in den ersten 12 Bit (CRC ???) 1-5 Unterschiede, in den nachfolgenden 28 (cipher ???) keinen Unterschied , dann wieder einen Unterschied in den letzen 40 Bit (Timestamp). Sollten also die ersten 12 Bit eine CRC oder ähnliches sein, so werden sie auch in Abhängigkeit vom Timestamp gebildet. Desgleichen gibt es aber auch Datensätze, die sich in den ersten 12 Bit nicht unterscheiden (0diff_crc.txt)
@Walter Hallo Walter, mir ist aufgefallen, dass in deinem File 1diff_chiper.txt, bei dem im chiffer-Teil jeweils nur 1 Bit Unterschied ist, sich die beiden verglichenen Blöcke im gesamten 80-Bit Block immer genau an 10 Bit-Positionen unterscheiden! Das kann eigentlich kein Zufall sein. Kannst du mal nachsehen, ob die feste Anzahl von 10 Unterschieden bei allen Blöcken vorkommt, die sich im Chiper-Bereich nur um 1 Bit unterscheiden ?
@Walter Hallo Walter, ich habe gerade gemerkt, dass meine Behauptung für den ersten Block nicht zutrifft. Aber trotzdem finde ich es bemerkenswert, dass dieser 10 Bit Unterschied so häufig vorkommt.
@Walter, die ersten 12 Bit sind 1-5 Unterschiede, cipher identisch, aber hast du auch mal die ausgabe bedacht, die ist jeweils unterschiedlich. Also kann es auch keine crc oder ähnliches sein, sicher sind wir erst wenn cipher identisch ist und ausgangsdaten identishc, gut ich bin kein kryptoexperte oder ähnlcihes, bitte korrigiert mich wenn ich müll rede ;)
> Sollten also die ersten 12 Bit eine CRC oder ähnliches sein, so werden > sie auch in Abhängigkeit vom Timestamp gebildet. Dann sollte sich die prozentuale Dynamik bei stabiler Wetterlage alle 24 Stunden wiederholen. Sorry, aber ich kann es nicht besser ausdrücken. Ausserdem muss ich immer an das Karnaugh Veitch Verfahren denken, wenn ich hier mitlese. Es mag ja einfach klingen, aber wäre es nicht möglich, ein Programm zu schreiben, welches als Eingangsdaten(bits) die aktuelle Zeit (Timestamp) und die empfangenen DCF-Daten bekommt und als Ausgangsdaten(bits) diejenigen Daten, die der Decoder ausspuckt? Zugegeben, in der Lehre mussten wir mit weniger Abhängigkeiten eine minimierte Logic entwerfen, das aber zu Fuß. Mit der Rechenleistung heutiger PCs sollte es doch kein Problem sein, den entsprechenden MinTerm zu finden. Oder liege ich da völlig daneben???
Hallo Ich habe mir jetzt auch mal solch eine Uhr besorgt. Ich habe den alten Thread und diesen hier ueberflogen. Ueberflogen deswegen weil ich ohne Uhr ja nicht viel mitreden konnte. Also erst mal nur die wichtigste Frage fuer mich. Mit welchem Programm loggt ihr die Daten mit und wie habt ihr das angeschlossen ? Wenn ich soweit bin das es mitloggt, werde ich beide Threads nochmal aufmerksam lesen muessen, dass ist klar. Eben habe ich bei ELV einige Uhren mit Wetterdaten fuer nur 19,95.- gesehen. Hat jemand solch ein Teil ? Teerkleks oder vernuenftiger Chip ?
Bei Penny Süd gibt es momentan die TFA Meteotronic Start 35.1080 für 29,99 mit Decoder im SOP8. Da konnte ich nicht anders... Zum PIC-Datenblatt: Der RC-Oszillator-Abgleich (0x3ff) ist ebenfalls nicht geschützt und kann immer programmiert werden --> max. Frequ. --> min. Wartezeit für Massendecodierung. Allerdings muss der Wert explizit von der Software in das OscCal-Register hineingeschrieben werden, ob das gemacht wird? Außerdem sind weitere ICs auf dem Weg zu mir. Im Anhang eine (unvollständige )Liste der momentan verfügbaren Uhren (TFA, Bresser, IROX, Mebus, LA CROSSE, TechnoLine, Cresta) mit EAN und Marktpreise. Die TFA WM5000 gibt es bei ebuy für 17+4 / 20+4 ! Vorsicht: es werden Uhren angeboten, die kein Meteotime haben: Bresser Wetter Station Wetterstation BF-Pro NEU 60+0 Digital DCF Multi Funk Wetterstation Sender Meteo Uhr 40+5 DCF Digital Wetter Station METEO Funk Thermometer 30+5
Wenn ihr unbedingt eure eigenen Decoder-Chips wollt, fragt bei diversen Verkäufern an ob ihr defekte oder beschädigte geräte bekommen könnt, TFA Meteotronic, start/profi das kommt deutlich günstiger als sich neue geräte zu kaufen! So habe ich das auch gemacht, Wenn Ihr glück habt sind nur die DCF-Antennen in den geräten Locker (passiert sehr leicht nach einem Sturz), die dann nur noch mit Heißkleber festgeklebt werden müssen...
@Michael Lehrmann: ja, ist bekannt. Beschreibt aber "nur" die Bedeutung der entschlüsselten Daten und die Position der Daten im DCF77-Stream. @Peter W.: Ich habe 2 Stationen, eine mit Klecks auf dem Bare Die und eine mit SOP8 Decoder Chip (PIC12x509). Für das Logging habe ich direkt an die Pins Kabel angelötet und nen Microcontroller angeschlossen, der mir die Daten dann seriell aufbereitet und an den PC übergibt. Für eine eigene Decoderschaltung habe dann den Chip rausgelötet und direkt an meinen Microcontroller angeschlossen, damit ich die Daten reingeben und wieder rausholen kann (ist ein synchron-serielles Protokoll). @Thomas: ich denke wir werden keinen Telegramme mit identischen Cipher und Plain finden, da der Schlüssel immer ein anderer ist (Timestamp oder davon abgeleitet). @me: nein, das sehe ich nicht so. Die Wetterlage / Wetterdaten liegen vermutlich verschlüsselt mit einem immer anderen Schlüssel in den ersten 40 Bit (vermutlich in den Bits 13-40). Ich habe mal die Telegramme von Thomas sortiert nach Plaintext (decodierte Wetterdaten), dabei habe ich 610 gleiche gefunden. Aufgrund des unterschiedlichen "Schlüssels" ergibt sich aber immer ein andere Cipher Text. Bei einem guten Krypto-Algorithmus sollte eine einzelne Bitänderung in Key oder Plain eine große Änderung im Cipher bewirken. Ausgehend von der Theorie, dass es sich bei den ersten 12 Bit um eine Checksumme oder ähnliches handelt und es Telegramme gibt, die sich zwar in den Bit 1-12 unterscheiden, nicht aber in den Bits 13-40 gehe ich davon aus, dass die Checksumme auch von den Bit 41-80 (Timestamp) abhängig ist. Es gibt auch Telegramme mit identischer Checksumme. Ich habe jetzt also Telegramme gesucht, die sich in den Bits 13-80 (Generator für die Bits 1-12) möglichst wenig unterscheiden um so vielleicht etwas über den Checksumme Mechanismus zu erfahren. Zu der Sache mit dem Logic-Diagramm: Das kannst Du eigentlich nur aufstellen, wenn alle Ein- und Ausgangszustände bekannt sind, das sind bei 80 Bit 2^80 ~ 10^20 Zustände, also echt viel ;-) Viele Krytpo-Algorithmen benutzen Runden und Schiebefunktionen, also kein einfaches XOR oder ähnliches. Zu der Sache mit dem Oszillator-Kalibrierungswert: Gute Idee ! Bei einem Reset startet die SW an Adresse 0x3FF. Dort steht der Kalibrierwert in from von MOVLW xx. Es handelt sich bei dem Wert um einen 7 Bit signed Wert, der Wert für die niedrigste Frequenz ist also 1000000, der für die mittlere ist 0000000, der für die höchste ist 0111111. Bei meinem Baustein ist der Wert 0x04 (0000100). Man kann die Bits aber wieder nur zu 0 schreiben. In meinem Falle kann ich den Baustein allenfalls langsamer machen. Um ihn schneller machen zu können müsste der oberste Bit (Vorzeichenbit) gesetzt sein. Eine andere Möglichkeit wäre, in den Fusebits auf LP Oscillator umzuschalten, da wird der externe Takt verwendet, dann fallen aber die Pins 2 und 3 weg (CLK out und DAT in), somit der Baustein dann nicht mehr wirklich nutzbar. Walter.
Angehängte Dateien:
-
contact1_small.JPG
58 KB
Nachtrag @Peter W: hier noch das Bild der Anzapfstellen. Der kleine Klecks in der Mitte ist der Decoder (bei dieser Wetterstation DV323 ist es wohl kein PIC sondern wahrscheinlich ein EM65...und der hat keine Copy protection, ich kenne aber leider das ICSP Protokoll nicht). Das 4fach Flachband mit der roten Ader ist die Verbindung zum Logger. Beim PIC in meiner Meteotronic Start ist die Belegung wie folgt: Pin1 Vcc Pin8 GND Pin2 Data in Pin7 Clock in Pin3 Clock out Pin6 Data out Pin4 Vcc Pin5 ??? (Busy oder so) Das Protokoll findest Du glaube ich im ersten Thread. Data in/out ist klar. Mit Clock_in Taktet der Master (Wetterstation) die Daten rein (82 Bit, 2 Bit werden verworgen, Bit0 und Bit7, kann man am Timing erkennen), der PIC antwortet mit seiner Clock Leitung (Clock out), wenn er das Bit übernommen hat. Bei der Datenausgabe ist es umgekehrt: der PIC signalisiert, wenn er ein Bit ausgegeben hat, der Master bestätigt die Übernahme mit der CLK_in Leitung.
@Walter Freywald EM65.... sollte das evtl. ein 4-Bit µP von em-microelectronic sein? Unter "www.emmicroelectronic.com" ist da schon was zu finden. Würde mich bei einem Batteriebetrieben Gerät nicht weiter wundern. Die Microelectronic Teile sind bestens für Lowest Power-Anwendungen geeignet. Die ASM-Programmierung ist so schlecht nicht, habe bereits einiges damit gemacht. Wobei ich mir kaum vorstellen kann daß in der Serie die Flashversion eingesetzt wird, sondern eher eine Masken-ROM-Version, die dann automatisch eine Auslesesperre hat.
@No Body: ja, genau den meine ich. Ist der einzige 8 pinner, der Vcc und GND an diesen Stellen hat. Der Test Pin lässt sich auch auf über 10V ziehen. Hast Du die Programmier Spec für das Teil ? (Protokoll für ICSP, Kommandos im Einzelnen etc.) EM rückt nix raus mit dem Hinweis auf Sicherheit (security by obscurity...manche verstehen's nie, armer Kerkhoff !) und ich will mir nicht extra nen Programmer kaufen...
Gibt es irgendwo eine Übersicht, in welcher Wetterstation ein SOP8 bzw. Bare Die sitzt? Ansonsten wäre es auch sehr hilfreich, wenn die Besitzer hier posten könnten was in ihrer Station jeweils drinsitzt.
Bezüglich der Vermutung es könnte sich bei den ersten 12 Bit (ohne Alarmbits)um einen CRC-12 handeln, habe ich mal ein paar Versuche mit dem Programm "CRC RevEng v0.40" [http://regregex.bbcmicro.net/reveng-readme.htm] gemacht. Mit dem Programm kann man auch unbekannte CRC Algorythmen/Parameter finden. Leider wurde ich nicht fündig. Aber vielleicht möchte sich ja noch jemand anderes daran versuchen..
Bin gerade dabei, die von mir oben angehängte Liste für den WikiArtikel DCF77 Wetterinformationen aufzuarbeiten. In ca. 15 Minuten bin ich so weit, dann dort bitte eintragen, wer welche Uhr hat und die ganzen anderen Infos (welcher Decoder, welche Bauform)...
@Walter
Hallo Walter,
du hast doch den Dekoder-Chip an einem Mikrocontroller hängen.
Kannst du damit eventuell die Ausführungszeit des Dekoders messen,
vom letzten Clock der Dateneingabe bis zur ersten Reaktion des Dekoders?
Kann dein Dekoder Bitfehler korrigieren oder nur erkennen?
Die Idee dahinter:
Wenn ich das richtig in Erinnerung habe, dann gilt, dass
- ein 1 Bit-Fehler in den Datum/Zeit-Bits erkannt wird
- ein 1 Bit Fehler im Chiper-Teil erkannt und von manchen Dekodern
korrigiert werden kann
dann müsste es eigentlich zwei verschiedene Arten von Prüfbits geben:
1. Prüfbit(s) über die gesamte 80 Bit Übertragung zur allgemeinen
Erkennung eines Fehlers
2. Prüfbits nur über den Chipher-Teil der Übertragung, um diese
korrigieren zu können
Nach unserer Vermutung liegen die Prüfbits in den ersten 12 Bit (14 mit
Alarmbits) der Übertragung, also im ersten Übertragungsblock.
Möglicherweise lässt sich aus der benötigten Verarbeitungszeit des
Dekoders erkennen, welche Art von Bit (Prüfbit Typ1, Prüfbit Typ2,
Chipher-Daten, Key-Daten(Datum/Zeit)) er gerade bearbeitet.
Also könnte man folgenden Versuch machen:
V1. Eine 82-Bit Block der nur aus '0' besteht in den Dekoder schicken
und die Ausführungszeit messen vom einclocken des letzten Bit bis
zur Ausgabe des Ersten Dekoder-Bits
V2. Dann jeweils nacheinander nur EIN Bit auf '1' setzen und die
Ausführungszeit messen. Dies für alle 80 Bit tun.
V3. Das gleiche wie bei V2 aber diesmal mit einem zunächst gültigen
Block durchführen und dann jeweils nur ein einziges Bit invertieren
und wieder die Ausführungszeit messen. Dies für alle 80 Bit des
Blocks durchführen.
Aus den wahrscheinlich verschiedenen Ausführungszeiten lassen sich
möglicherweise Rückschlüsse auf die Art des Bits an den verschiedenen
Bit-Position ziehen.
Kannst du diese Versuche durchführen ?
Hi, nach dem ich mich durch während des Nachmittags durch die beiden Threads gelesen hab, werd ich mir demnächst auch eine Funkwetterstation zulegen. Eines ist mir noch aufgefallen das ich gleich loswerden möchte. Walter Freywald schreibt in einem älteren Beitrag, dass er eine zweite Station besitzt, bei der sich neben dem gebondeten Chip noch ein weiterer SOP8 Footprint befindet. Der Footprint soll zu einem EM6580 passen. Jetzt bin ich nach ein bisschen suchen, nach Funkwetterstationen drauf aufmerksam geworden das der gleiche Hersteller auch sogenannte Sateliettenwetterstationen anbietet, die sich äußerlich nur gering/garnicht von den DCF77 unterscheiden. Wie ich oben gelesen hab bekommen die Satelittenwetterstationen ihre Signale über die alten Pagerfrequenzen. Wenn man jetzt davon ausgeht das sich die Platine bei diesen Geräten auch eben durch den einen Chip unterscheidet, könnte man bei der Fertigung einfach einen anderen Chip bestücken. Und da EM eine Untergruppe von Swatch ist und Swatch frühers auch Pager hergestellt hat, höhrt sich das für mich stimmig an. Im Anhang noch ein PDF das die Programmier Schnittstelle das EM6580 beschreibt, falls der sich wirkklich darunter verbergen sollte. Walter meinte das er dazu keine Informationen hat.
> Welche Frequenzen sind das denn?
CPU-Takt? Der rennt mit max 800KHz (interner Osc), was auch die lange
Verarbeitungszeit erklären könnte.
Hallo, Es müsste sich um diese Frequenzne handeln: http://inet4you.dyndns.org/inet2/index.php/amateurfunk-welt/6-frequenzen/170-wetterdirekt--wettervorhersage-frequenzen.html Gruß Thomas
@uzi: gute Idee. Ich hab's gleich ausprobiert. Leider ist die Zeit immer die gleiche (nahe zu, variiert nach oben und unten), ca. 290,420 us. Aber: ich habe keinen Chip der korregiert. Sobald ich da einen aufgetrieben habe, mach ich den Test nochmal. @LuckyLuck: danke für die AN. Das steht leider "nur" drin wie man den Chip mit dem Elnec Programmer verbindet, nicht die Befehle für das ICSP. Ich brauch also einen Programmer - und er kostet. Danke trotzdem ;-) Neue Idee: Wenn die ersten 12 Bit wirklich eine Prüfsumme (in welcher Form auch immer) über den Rest des Telegramms sind dann sollte ich die passende Prüfsumme für ein selber erstellte Telegramm doch finden lassen. 12 Bit -> 4096 Möglichkeiten Wartezeit zwischen den Versuchen: ca.40 Sekunden => Um alle Kombinationen durchzuprobieren: 40 *4096 = 163840 Sekunden (etwa 45,5 Stunden). Ich werde das gleich mal anschmeißen. Walter
@Walter >gute Idee. Ich hab's gleich ausprobiert. Leider ist die Zeit immer die >gleiche (nahe zu, variiert nach oben und unten), ca. 290,420 us. Hattest du nicht mal erwähnt, dass zumindest bei den Alarmbits die Reaktionszeit des Dekoders wesentlich kürzer ist ??? Welche Zeit hast du denn gemessen ? (Start/Stop Triggerpunkt?)
im Anhang noch ein paar Infos zum Programmer für den EM6850. Scheint ein USB Teil mit FTDI Chip drin zu sein. Leider keine ISP Kommandos dabei :-(
Ja, bei Bit 7 (beim reintakten) ist die Zeit deutlich kürzer als bei den anderen Bits. Daraus habe ich geschlossen, dass das Bit 7 verworfen wird. Sonst habe ich leider keine Auffälligkeiten gesehen. Aber vielleicht ist das bei einem Decoder-Chip mit Fehlerkorrektur anders... Der Programmer sieht interessant aus ;-) Mal sehen, ob ich den irgendwo bekomme.
@Walter
Schau dir doch bitte mal die Zeit an, zwischen eintakten eines Bits und
der dazugehörenden Clock-Out Flanke als Reaktion des Dekoders.
Variiert diese Zeit vielleicht in Abhängigkeit der eingeclocken Bits
('0'/'1' bzw gültig/ungültiges Bit) ??
Ich kann mir nicht vorstellen dass hier so viel Wert darauf gelegt wurde
das Timing so auszutüfteln, dass daraus kein Angriffspunkt gemacht
werden kann.
Möglicherweise resultiert die feste Zeit bis zur Ausgabe der dekodierten
Bits nicht aus der Dekodierung selbst, sondern ist ein
Verschleierungsversuch mit Hilfe eines angehängten Delays.
Mit welcher Taktfrequenz arbeitet denn der PIC vermutlich?
Ich meine das irgendwo hier oder im alten Thread gelesen zu haben, habs
aber bisher noch nicht gefunden.
Kannst du mal einen sagen wir mal 10 Ohm Widerstand in die pos oder neg.
Spannungsversorgungsleitung legen, um die Stromaufnahme während des
Ein-clockens Dekodierens Ausgabe der Daten mit dem Oszi zu
beobachten?
Achtung, die ungeschirmte Masseleitung des Oszi-Tastkopfes so kurz wie
möglich machen! Vielleicht kann mann an der schwankenden Stromaufnahme
erkennen, wann der Dekoder rechnet und wann er sich nur langweilt...
@uzi, das wurde hier schon im ansatz gemacht, siehe alten thread, die stromaufnahme messen: Beitrag "Re: AVR: Wetterinformationen über DCF77" aAuch in dem NAchfolgenden posts...
@Thomas ja, ich weiss dass die Stromaufnahme schon mal gemessen wurde, aber ich habe keine Bilder für den gesamten Dekodierprozess gefunden! Falls ich die übersehen habe,gib mir bitte Bescheid wo die stehen. Ausserdem möchte ich damit eventuell rausbekommen, wann der Dekoder tatsächlich mit rechnen beschäftigt ist und wann er eventuell nur in einer Zeitschleife wartet. Wenn man in einem zweiten Schritt dann an einem gültigen Daten Block jeweils nur eine Bitposition verändert und sich dann den Verlauf der Stromaufnahme hierzu ansieht (Korrelation) läßt sich eventuell ableiten, in welchen Bits sich Daten, Keys oder Prüfbits verstecken.
Sodala, gestern habe ich den Chip ausgelötet... Er wacht alle 2,4 Sekunden auf, das sieht man daran, dass Ack und Busy für 20 µs hoch gehen. Das Reinladen der 82 Bits kann sehr schnell gehen, ich nehme Clc-Low 10 µs und Clk-Hi 21µs, * 82 = 2,542 ms. Nur beim ersten Bit warte ich ein bisschen länger, da der Controller aufwachen muss (auch hier gehen Ack und Busy 20µs hoch) Unterschiedliche Reaktionszeiten habe ich leider nicht feststellen können. Bei Bit 0 und 7 sind es etwa 15µs, sonst 27. Muss aber nochmal genau messen. Die Zwangspause ist 36 Sekunden lang (15 x die o.g. 2,4 Sekunden). Busy wird alle 2,4s für 20µs low, Ack weiß ich gerade nicht. Es spricht einiges dafür, dass es ein 12C509A ist. Der erste ausgeführte Befehl ist 3FF: MOVLW FA (0CFA), komisch, denn die unteren beiden Bits des OscCal sollten 0 sein. Das mit dem Signed habe ich nicht verstanden, ist jetzt FC volle oder mittlere Geschwindigkeit? Der nächste 000: GOTO 060 (geht in den nicht mehr sichtbaren Bereich) Habe den Code mal im Simulator laufen lassen, schaut nicht schlecht aus. Die Frage ist, ob es ein Honeypot ist. Auf jeden Fall werden die Bits ordentlich durcheinandergewürfelt, da ist nichts mehr mit "scharf ansehen und durch Probieren draufkommen". Autor: aaaaa (Gast) Datum: 18.04.2011 13:18: hat es ja schon mal beschrieben. > Was macht das? Speicherzelle auf 0 setzen durch XOR mit sich selbst? Nein, Speicherstelle 13 wird mit W gexort. Allerdings weiß ich noch nicht, in welcher Reihenfolge die Bits im Array stehen. Übrigens: Es gibt nur drei lizensierte Hersteller: IROX, Hideki IDT-Oregon. Alle andere (TFA ...) vermarkten nur. www.meteotime.com/Web/de/ProductsLicencees/Lizenznehmer.htm Der Schweizer Langwellenzeitdienst HBG (75 kHz) http://www.metas.ch/ wird Ende 2011 abgestellt, da die anstehende Renovierung unrentabel ist.
ok, dann müssen wir uns echt ran halten ;-) So, mein Test ist durchgelaufen: Ich habe das letzte Bit in einem Telegramm gekippt und die ersten 14 Bit (mit Bit 0 und 7 immer 0) durchlaufen lassen (4096 Möglicheiten), hat etwa 2,5 Tage gedauert -> leider nix ! Im nachhinein: Mete-on 3 kann kan scheinend 1 Bit korregieren, wenn der Fehler in den ersten 42 Bit liegt, also nicht im Zeitstempel (und da habe ich das Bit gekippt). Also könnte es sein, dass die ersten 12 Bit zwar Korrekturbits für die Cipherbits sind, aber nicht von jedem Baustein ausgewertet werden (können). 42 -2 (0 Bits, 0 und 7) - 12 (Korrekturbits) - 22 (Cipherbits) = 6 Es blieben also dieser Theorie nach 6 Bit für eine Fehlererkennung über alle Nutzdaten übrig. Im alten Thread schrieb Poul-Henning --------------- cut ---------------------- Autor: Poul-Henning Kamp (Gast) Datum: 15.04.2007 15:17 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 ---------------- end cut ----------------------- Er erwähnte, dass in den ersten 12 Bit (Bit 0 und 7 mal weggelassen) zwischen den Bits 1-8, 2-9,3-10,...6-13 ein Zusammenhang bestünde. @eProfi: hast Du ne Möglichkeit, Ströme zu messen (1K in Vcc rein und ne Stromkurve beim Decodieren aufzeichnen - s.Vorschlag von "uzi") ? Ich glaube, dass ist dann doch der bessere Ansatz. Chris hatte mal geschrieben, er hätte einen Monitorprogramm gebaut, dann man ein den bestehenden ersten 64 Worten unterbringen kann. Leider hat er es nicht online gestellt - das klang auch sehr vielversprechend. Ich werde mich trotzdem mal wieder mit der Hardware beschäftigen: Data remanence wurde hier schon mehrmals genannt - da muß ich mal ein bisschen experimentieren ;-) So weit zu meinem missglückten 12 Bit Versuch. Walter.
@eProfi: in meiner Wetterstation habe ich den Decoder IC in einem 8 Pin Gehäuse, dass von den Abmessungen dem MSOP vom PIC12F509 entspricht (0.65 Pin Pitch). Den PIC12C509x scheint es in diesem Gehäuse nicht zu geben sondern nur eine Nummer größer (1.27 Pin Pitch). Im Rahmen meiner geplanten Tests werde ich einen Decoderbaustein (versuchen zu) löschen, da wird es sich ja dann herausstellen ob C oder F ;-)
Hallo Walter, stimmt, Gehäuse MSOP8 spricht für den PIC12F508-I/MS. Genauso die Tatsache, dass er sicherer ist (löscht mehr nach einem Reset). Außerdem lädt meiner beim Reset den OscCal-Wert FA (11111010), d.h. Bit 1 ist gesetzt. Beim C wäre das Bit not used. Habe ein wenig simuliert, weiß aber nicht, in welcher Reihenfolge die 80 Bits gespeichert werden. Der Code ist echt tricky. Du hast Post.
würde mich aber nicht wundern, wenn es trotzdem ein 509er ist, zumal da auch ja hkw581 druf gedruckt
@Micha: klar würde das helfen, besonders, wenn man als Referenz dazu einen "echten" PIC12F509 röntgt. Das wäre schon mal ein erster Hinweis. Schöner allerdings wäre, das Teil "funktionsfähig zu öffnen" (Salpetersäure), dann würde man es ganz genau sehen. Walter.
Ja, PIC12F509-I/MS wollte ich schreiben. >zumal da auch ja hkw581 druf gedruckt Du meinst 8+1=9 ?? Was steht bei Dir genau drauf? An Röntgen dachte ich auch schon. Meinst Du, um Details des DIE zu sehen oder um ihn zu löschen / anzulöschen? Die Bits wird man leider auf dem Bild nicht sehen. > Ich habe das letzte Bit in einem Telegramm gekippt und die ersten 14 ... Welches erste Bit genau? Im Patent / Wiki-Artikel steht doch, dass 42 Datenbits in den ersten beiden Minuten und 40 Prüfbits in den letzten beiden Minuten gesendet werden. Zur Simulation: bin gerade dabei, herauszufinden, wie sich das zurückgekoppelte Bit berechnet.
ok, ich habe eine WM5000 aber noch nicht nachgeschaut welcher Chip oder Klecks da drinnen ist. Als Referenz hab ich leider blos einen PIC12C509P Röntgen könnte ich warscheinlich nächste Woche.
Beim Röntgen meine ich das man etwas von dem Chip erkennen könnte, wird er dadurch gelöscht oder beschädigt ? Bei Bildern im Internet von geröntgen Chips sieht man nicht soviel von der Die man sieht vielleicht die Bondingdrähte und wo die hingehen, bei einer gleichen Die könnte man vielleicht trotzem mit einem 509er vergleichen.
Angehängte Dateien:
-
CRC.png
967 Bytes
@eProfi, bei dem Codeausschnitt handelt es sich um ein 80 Bit Schieberegister mit 14 Abgriffen. Ablauf: Adressen 0005 - 0011: Es wird einmal nach rechts geschoben (Bit 0 springt dabei in Bit 79) Adressen 0012 - 0020: Es werden die Rückkopplungsbits geholt und XOR auf Bytebreite verknüpft Adressen 0021 - 002F: Die 8 Bit werden miteinander XOR verknüft und mit Bit 0 XOR verknüpft Ab Adresse 0032: Mit dem Bit 0x04,5 wird zwischen 2 Registerbänken umgeschaltet Nachdem der erste Befel "bcf 0x04,5" ist gehe is davon aus, dass bisher auf Register Bank 1 gearbeitet wurde. Es wird also auf Register Bank 0 umgeschaltet, ein Byte geholt und mit "bsf 0x04,5" wieder auf Bank 1 zurückgeschaltet. Das zuvor aus Bank0 geholte Byte wird mit dem korrespondierenden Schieberegister Byte XOR verknüpft. Das wird in dem für uns sichtbaren Bereich für die ersten 4 Byte es Schieberegisters durchgeführt, geht wahrscheinlich nach Byte 0x40 weiter. Pro Byte werden 4 Befehle benötigt. Wenn man jetzt weiterrechnet und das für alles Bytes des Schieberegisters fortsetzt (2 + 6 x 4 = 26 -> 0x1A) und den Sprungbefehl vom Anfang an Adresse 0x60 als Obergrenze berücksichtigt, so bleibt noch für 6 Befehle Platz, z.B.: decfsz 0x10,f goto 0003 ret der Code könnte also ab Adresse 0x40 so aussehen: 003e 04a4 bcf 0x04,5 003f 0215 movfw dcf+3 0040 05a4 bsf 0x04,5 0041 01b5 xorwf dcf+3,f 0042 04a4 bcf 0x04,5 0043 0216 movfw dcf+4 0044 05a4 bsf 0x04,5 0045 01b6 xorwf dcf+4,f 0046 04a4 bcf 0x04,5 0047 0217 movfw dcf+5 0048 05a4 bsf 0x04,5 0049 01b7 xorwf dcf+5,f 004a 04a4 bcf 0x04,5 004b 0218 movfw dcf+6 004c 05a4 bsf 0x04,5 004d 01b8 xorwf dcf+6,f 004e 04a4 bcf 0x04,5 004f 0219 movfw dcf+7 0050 05a4 bsf 0x04,5 0051 01b9 xorwf dcf+7,f ... 005x 02f0 decfsz 0x10 005x 0a03 goto 0003 ... 005F .... retlw .. Kann aber auch sein, dass auf Bank 0 gearbeitet wird, dann der Momentanzustand des Schieberegisters mit Daten auf Bank1 XOR verknüpft. In der Patentschrift ist von einem Schieberegister die Rede, dass (Laut Patentschrift) bekannt sein darf, würde ja passen, da diese Teil der SW sichtbar ist. Walter PS: Post gelesen, Post beantwortet ;-)
Zu den 42 Bit: ja, die kommen von den 3x 14 Bit auf DCF77. Anmwerkung: Ich zähle die Bit von 0 bis 79 und ich entferne die Bit 0 und 7 aus meinen Betrachtungen, gehe also von 80 Bit aus. Wie sich aber bei den Antwortzeiten des Decoderchips gezeigt hat, wird zumindest auf Bit 7 (ich zähle die Bit von 0 an) sehr schnell reagiert. Man kann auch Bit 0 und Bit 7, die normalerweise immmer auf 0 stehen auch auf 1 setzen, ändert nichts am Ergebnis. Daher gehe ich davon aus, dass diese beiden Bits verworfen werden (Werden soweit ich das verstanden habe für Katastrophenalarm verwendet). Es bleiben also 40 Bit Daten und 40 Bit Zeit. Die Zeit (also die hinteren 40 Bit) kann man klar zuordnen, da ist auch keine Prüfung drin. Ich habe das letzte Zeitbit (Obersters Bit von der Jahreszehnerstelle) gekippt, also das Jahr 2089 eingestellt. Das letzte Bit deshalb, da ich in den ersten 12 Bit eine CRC vermutet habe. Die CRC wird gebildet, indem der CRC Wert um ein Bit geschoben wird und ne 1 rausfällt wird nen XOR mit dem Generatorpolynom gemacht. Wenn ich nun das letzte Bit von 0 auf 1 setze und die CRC von dem Original Telegramm habe (letztes Bit 0), kann ich die beiden Werte XOR verknüpfen und habe das Generator Polynom (so in etwa, evtl. nochmal schieden). @Micha: man sollte zumindest die Chip (DIE) -Größe erkenn und ob ggf. noch ein EEPROM drangeflanscht ist (war glaube ich bei den 12CE509 so). Von der Struktur wird man eher nix sehen. Walter. PS: nochmal zu den Telegrammen: Nach diversen Vergleichen und Zählungen zeigt sich, dass sich die ersten 12 Bit irgendwie anders verhalten als die folgenden 28 Bit. Beim Vergleichen habe ich keine Telegramme gefunden, die in den ersten 40 Bit weniger als 3 Abweichungen haben. Ich habe aber Telegramme gefunden, die in den ersten 12 Bit keine Unterschiede aufweisen, genauso andere Telegramme, die in den folgenden 28 Bit keine Unterschiede aufweisen. Somit sind die ersten 12 Bit genau wie die folgenden 28 Bit anscheinend abhängig von den 40 Zeitbits.
Bonddrähte und Chip kann man durchaus auf Film auflösen, man sieht sogar die Pads auf dem DIE an die die Drähte angeschlossen sind. Der Zahnarzt hilft ;-)
ja ich geh zum Kumpel dem Zahnarzt, leider bekommt er das 3D Röntgen erst im August.
Der Chip kann allerdings dabei schaden nehmen, eine SD-karte mag zumindest kein Röntgenlicht.
@Walter Kannst du mal deinen Versuch wiederholen und über Brute-Force versuchen die ersten 12 Bit (Prtüfbit ?) zu ermitteln, indem du eine gültigen 80Bit Frame heraussuchst, der möglicht viele '0' im Chipher-Teil hat und dann im Chipher-Teil nur 1 Bit z.B. das Erste in einem größeren '0'-er Block kippst. Wenn unsere Vermutungen stimmen, und die ersten 12 Bit die Prüfbits sind, dann könnte das funktionieren. @Thomas Falls Walter mit seinem Versuch Erfolg hat, könntest du dann ein Programm bauen, dass deine beiden am PC hängenden Dekoder in der freien Zeit dafür benutzt weitere Brute-Force Angriffe auf die Prüfbits mit leicht veränderten gültigen Frames macht. So könnte man schneller gültige Frames erzeugen und versuchen zu ermitteln, wie sich einzelne Bits des Chipherteils auf die Prüfbits auswirkt. uzi
das bezweifle ich, das die Geräte schaden nehmen. Sowas wird doch ständig beim Flughafen geröngt und nimmt keinen schaden, die strahlen sind m.W. stärker als die der medizinischen Röntgengeräte. Nachtrag @ Uzi, Machbar ist vieles, nur da die Decoder hier über eine ASP.NET Webanwendung angesprochen werden kann ich diese nicht ohne weiteres in einer anderen anwendung nutzen. Wenn ich eine Datei bekomme mit Telegrammen, kann ich diese (nach abänderung meiner decoder-anwendung) durch die beiden Decoder laufen lassen.
@Thomas ok, dann warten wir mal ab, ob Walter fündig wird. Dann können wir uns abstimmen wie so eine Datei aussehen soll. uzi
Die Dosisleistung der Geräte am Flughafen ist wesentlich geringer als die eines Diagnostischen Röntgengerätes. Auserdem arbeitet man nicht im gleichen Wellenlängenbereich. Beim Röntgen der feinen Strukturen im Chip ist es auserdem erforderlich andere Verstärkerfolien/Sintilatoren einzusetzen. Auch zum Diagnostischen Röntgen gibt es eine Bandbreite an unterscheidlich empfindlichen und auflösenden Verstärkerfolien um die Exposition wenn möglich gering zu halten.
Langsam verliere ich jede Übersicht ;-) Bin damit vermutlich nicht der
Einzige.
Darf ich das mal zusammenfassen? Wenn Walter auf der richtigen Spur ist,
sind also nur noch 6 Code-Bytes('Wörter') auf sinnvollen Inhalt zu
bringen und es bleibt dann als letzte Unbekannte: Die Frage, wie der
Initialisierungsvektor fürs Schieberegister aus den Zeitdaten gewonnen
wird?
Ist das so richtig?
Das Röntgen wird wenig bringen. Kenne solche Fotos. Problem ist auch, das die Hersteller gerne mal die Chiptechnologie updaten, das Die damit kleiner wird, aber der Chip ansonsten laut Spec gleich bleibt. Neue Features, wie das Abdecken der Fuse-Bits, werden dabei gerne mal verschwiegen. Von daher ist selbst ein Größenvergleich des Die nicht sehr aussagekräftig. Aber laß dich nicht aufhalten.
Hallo, seid mir nicht böse, wenn ich dumme Fragen stelle, aber ich habe einiges noch nicht verstanden: I) Woher weiß die Wetterstation (der Dekoder), wann gerade welches der 3 Wetter-Datenpakete angekommen ist? Einen Startpunkt gibt es ja jede Minute (Bit 59), aber nicht zusätlich jede dritte Minute. Aus dem Log von gestern erkennt man zum Beispiel, dass das Paket 1 erst ab der ersten Minute, nicht schon ab der nullten beginnt. Wird das erste Wetterpaket dann verworfen, oder gehört das zu letzten Tag? II) Woher wisst ihr eigentlich, welche Zeitinformation zu den 3 Wetterpaketen angehängt wird? Im log ist stets die Zeitinfo des 2.Paketes angehängt worden. Warum nicht die des 3.Paketes, das wäre doch einleuchtender? III) DCF77 sendet folgende Zeitinfo-Reihenfolge: Minute - Stunde - Tag - Wochentag - Monat - Jahr. Der Dekoder bekommt aber laut dem der Logdateien folgende Reihenfolge: Minute - Stunde - Tag - Monat - Wochentag - Jahr. Warum? Tauscht das der Hauptprozessor der Wetterstation um? IV) Der Dekoder bekommt 82 Bit. 3*14 Bit = 42 Bit Wetterinformationen. Desweiteren: 7 Bit Minuten (ohne Prüfbit), 6 Bit Stunden (ohne Prüfbit), 6 Bit Tag, 5 Bit Monat, 3 Bit WoT, 8 Bit Jahr (auch ohne Prüfbit) = 35 Bit Zeitinfo. Warum werden aber bei Minute, Stunde und Tag Nullen bis sie 8 Bit lang sind angehängt? Hängt der Hauptprozessor das an? Bitte helft mir das zu Verstehen. Grüße PG.
http://service.gmx.net/de/cgi/g.fcgi/mail/index?folder=inbox&first=0&extsearch=&sfid=&allfolders=&header_query=&sid=babhdde.1304686269.2913.0wqjemzgd1.73.dec 1. Es ist genau festgelegt, wann welches Paket kommt. 2. Ich vermute, dass die Daten nach der 14. Sekunde der 3. Minute an den DCIC übertragen werden. Da ist die Zeitinfo der 3. Minute noch nicht vorhanden. 3. Warum ?? k.A. Ja, der Hauptprozessor sammelt die Daten und übergibt sie. 4. Ja, es werden Nullen eingefügt. Zuerst dachte ich, es würde das Parity mit übertragen, scheint aber nicht der Fall zu sein. k.A. Weil es einfacher ist, wenn Byte-weise übertragen wird? @Abdul: nein, das ganze beruht nur auf Vermutungen. Wir haben nur die ersten 64 lesbaren Worte disassembliert und analysiert. Es kann genauso gut sein, dass der Code nur zur Verwirrung der Hacker dient (=Honeypot) und nie ausgeführt / zur Dekodierung verwendet wird. Außerdem: wenn der Code so kurz wäre, hätten sie einen 508er (512 Words) verwendet. Der 509 hat 1024. Hat jemand eine Cresta oder IROX ? Scheinbar ist Cresta MT-03 = Irox Mete-On7 CRESTA PMT-980 = Irox Pro-X2 @Thomas: danke! Klartext HKW581 725268 oder 7252G8 Hast Du extra eine Platine gemacht? Respekt! > ok, dann müssen wir uns echt ran halten ;-) Ja, der momentan gültige DCF77-Vertrag läuft auch bald wieder mal aus, aber die Wahrscheinlichkeit ist groß, dass er verlängert wird. Es gab schonmal ernsthafte Gedanken, ihn abzuschalten. Ja, Strom habe ich auch gemessen, man sieht schon was, aber worauf soll ich achten? Ich glaube, dass er die ca. 276 ms voll durchrechnet. Das falsch dekodierte Telegramm (12.01.2010 17:00) 000000000011011100010011 lautet richtig dekodiert 011011100010011011011010 6 e 2 6 d a 01101110 0010011 ist also um 9 Bits verschoben und abgeschnitten. was ich noch bemerkt habe: das Busy wird "eine Runde" (2,4s) inaktiv, wenn man mehr als 24 Bits abfragt. Allerdings bleibt die Zwangspause. Gerade nochmal probiert: Wenn man bei Busy ein korrektes Telegramm reinschickt, kommt das not-valid-Ergebnis 100000000000000000000100 zurück. Galep 3: IC-Richtung beachten, nicht wie aufgedruckt, sondern Kerbe nach oben. Zu den Schieberegister-Abgriffen: 1b: 19 00011001 18: 06 00000110 17: d4 11010100 14: 08 00001000 13: 3c 00111100 -------- BitZahl 11133311
1 | 3c 08 00 00 d4 06 00 00 19 |
2 | 00111100 00001000 00000000 00000000 11010100 00000110 00000000 00000000 00011001 |
3 | |
4 | Zu der Wertigkeit / Reihenfolge der Bits: |
5 | Das erste Bit dürfte Wertigkeit 1 haben, da das Schieberegister rechts schiebt. |
6 | Kann aber auch sein, dass das Empfangsschiebregister links herum arbeitet und / oder die Bytes verdreht. |
7 | |
8 | 00 3c 08 00 00 d4 06 00 00 19 |
9 | 00000000001111000000100000000000000000001101010000000110000000000000000000011001 links = Bit7 |
10 | 00000000001111000001000000000000000000000010101101000000000000000000000010011000 links = Bit0 |
11 | 01234567012345670123456701234012012345670123456701234567012345670123401201234567 |
12 | 0123456789abcd0123456789abcd0123456789abcd0123456701234567012345670123401201234567 |
13 | 111111111111112222222222222233333333333333mmmmmmm0ssssss00tttttt00mmmmmwttjjjjjjjj |
Ich habe den Thread nicht komplett durchgelesen, weiß daher nicht ob dieses Dokument schon bekannt ist, die Informationen darin erscheinen jedenfalls interessant für alle Dekodierungsversuche: http://www.hkw-elektronik.de/pdf/DB%20W-Protokoll-V%201.pdf (es ist direkt von Wikipedia aus verlinkt)
Jeder Schmeisst hier diese PDF rein, Die ist doch schon ein alter Hut, und bringt leider garnix.. @eProfi, Ich habe 4 Platinen machen lassen, 2 sind noch unbestückt. und ich habe einen Prototypen (Umgebauter USB Serial Converter, in Heißkleber eingegossen) Und ich weiß beim besten Willen nicht wieso da doch so viele fehlerhafte Datenätze sind...
@ Arno Nyhm: danke, das PDF ist seit 31.01.2007 09:02 bekannt und wurde inzwischen 17 mal genannt. Du hättest nur nach www.hkw suchen brauchen, nicht lesen. @ Thomas: kann es sein, dass Du mit der Abfrage des Ergebnisses zu lange wartest, so dass ein 2,4s-WakeUp stattfindet, der die Synchronisation durcheinander bringt? Dann gehen alle Ausgänge für 20µs auf High (falls sie einen PullUp haben ??). Ich war auch sehr verwundert, als ich diese Spikes sah. An Walter: Wie kommst Du voran? Beachte, dass das End-Programming evtl. bei bulk-erase nicht wirkt (internal timing)! --> Vdd (und alle anderen Pins) abschalten. Bin gerade dabei, das asm in C zu konvertieren. Die ersten 4 Runden laufen schon, aber die outer Loop (64 mal ???) hakt noch. Ich denke, sie sollte nor ca. 10 - 20 mal laufen (4*10=40, 4*20=80).
Zu Simulation / Timing: Die inner Loop dauert 4 * 46 = 184 µs Die outer Loop dauert 64 * 227 = 14,53 ms Das Dekodieren dauert 276 ms, / 14,53 = 19 Genug Zeit, andere beliebig komplizierte Verwürfelungen zu bewerkstelligen. An Walter: Opfere den HKW581 erst, wenn es mit den Mustern sicher klappt. Was mich noch interessiert: Ob die Entwickler von unserem Treiben hier wissen und wie sie darüber denken? Ob sie sich denken: hätte nie gedacht, dass die Hacker so weit kommen, oder ob sie sich inf Fäustchen lachen, wie stümperhaft wir hier agieren (seit 4,25 Jahren). Ich bin guter Dinge, dass der 581 in den nächsten Wochen sein Geheimnis preisgibt.
eProfi schrieb: > @ Thomas: > kann es sein, dass Du mit der Abfrage des Ergebnisses zu lange wartest, > so dass ein 2,4s-WakeUp stattfindet, der die Synchronisation > durcheinander bringt? Dann gehen alle Ausgänge für 20µs auf High (falls > sie einen PullUp haben ??). Ich war auch sehr verwundert, als ich diese > Spikes sah. Ich warte darauf, das CLK_OUT auf High_pegel wechelt und dann lese ich die daten aus. es kann sein das der Pegel dort durch den WDT kurzzeitig auf HIgh geht und deshalb schon vorher mit dem auslesen angefange wird. Der gesamte vorgang (Daten Reinschieben, dekodieren, daten rausholen) dauert weniger als eine sekunde. Ich warte nach dem einlesen der daten maximal 5s, wenn der decoder den ausgang nicht auf high schaltet, dann wird von meinem geschriebenen Modul 111111111111111111111100 Zurückgegeben, als Zeichen das etwas nicht stimmt.
Habs herausgebracht, wie das Rückkopplungsbit aus den 14+1 Bits berechnet wird. Das Carry geht nicht mit ein! Die Zeile oben hat einen Fehler in Bit 50:
1 | 00000000001111000001000000000000000000000010101101000000000000000000000010011000 links = Bit0 |
2 | richtig: |
3 | 00000000001111000001000000000000000000000010101101100000000000000000000010011000 links = Bit0 |
Bietet jemand auf die 330558388822 Wetterstation Meteotime weiß, Funk gesteuert mit? Nicht dass wir uns gegenseitig hochbieten.
Hallo Leute, ich habe mal den aus dem HKW Chip frei auslesbaren Code- Schnippsel (die ersten 64 Byte der Code-Sektion) in C umgesetzt. Ihr könnt ja mal etwas damit rumspielen, wenn ihr Ideen habt, wie der kodierte input-Datenstrom in den Algorythmus eingesetzt werden könnte. Achtung, der Algorythmus ist natürlich unvollständig, da ja nur die ersten 64 Byte des Programms bekannt sind! ------------------------------------------------------- Hier noch eine Idee wie wir dem Entschlüsselungsalgorythmus weiter auf die Spur kommen könnten: Wir brauchen einen HKW Chip, einen PIC 12F509 und ein Oszilloskop. Wir nehmen nun den bekannten Code-Schnipsel und ergänzen ihn so, dass er immer wieder durchlaufen wird und jeweils am Ende eines Durchlaufs ein Pin getogged wird. Diesen Code lassen wir in einem PIC12F509 mit gleicher Frequenz (4MHz ?) laufen und messen mit dem Oszilloskop hochauflösend die Stromaufnahme z.B. indem ein 10 Ohm Widerstand in die Spannungsversorgung des Pic eingeschleift wird und darüber die Spannung zum oszillografieren abnehmen. Durch den toggle-Pin haben wir einen definierten Trigger und haben nun einen Strom-Fingerabdruck des Code-Schnippsels. Jetzt machen wir die gleiche Messung am HKW-Chip, während er einen Datenblock entschlüsselt. Wenn wir Glück haben, erkennt man den Fingerabdruck des Codeschnippsel wieder und es lässt sich möglicherweise abzählen wie oft er durchlaufen wird. Damit könnte man dann die noch offene Anzahl der Schleifendurchläufe dieses Codeschnippsels ermitteln.
Mal ganz blöd gefragt, als jemand, der davon nicht so wirklich eine Ahnung hat: Wenn ich jede mögliche Kombination von nullen und einsen in den Chip schiebe, und jede Kombination im Ausgang dazu gegenüberstelle, dann erhalte ich ja eigentlich unterm Strich eine komplette Logik, welche ich dann in einem FPGA nachbilden kann. Oder sehe ich das falsch?
Martin Schwaikert schrieb: > Wenn ich jede mögliche Kombination von nullen und einsen in > den Chip schiebe Prinzipiell ja, aber das Problem liegt darin, dass - wie Du selbst schreibst - "jede mögliche Kombination von nullen und einsen" ziemlich viele sind. Sehr viele sogar! Dazu kommt, dass die Zeit ja auch mit drinnensteckt, das heißt eine Rainbow-Table aus der Vergangenheit bilden wird das Problem auch nicht lösen. MfG P.Wassi
um mal die Menge an möglichen Kombinationen zu verdeutlichen: selbst wenn du eine MILLIARDE Kombinationen PRO SEKUNDE (1GHz) rein schiebst, macht das bei 64 Bit ganze 584 Jahre, die man damit beschäftigt ist das ganze durchzugehen. und bei 80 Bit sind das nochmals 2^16mal so viel. dann mal viel Spaß :)
Uzi, das gibt es doch nicht, warum haben wir ausgerechnet heute exakt
das selbe gamacht?
btw.
{
if(lfsr[0] & 0x01) //Ergebnisbit der vorherigen Runde...
{
carry_in=1;
}
geht einfacher und richtger:
carry_in = lfsr[0] & 0x01;
Du setzt es nämlich nicht auf 0 (das wäre der else-Fall).
Im Anhang meine Version. Der Simulator berechnet exakt die selben
Ergebnisse.
Die Idee mit der Strommessung ist gut. Ob sie auch funktioniert?
An Martin:
das Problem sind die 36 Sekunden Zwangspause bei jedem Durchlauf.
Hallo Ich lese auch schon eine Weile interessiert mit, auch wenn ich mehr oder weniger nur Bahnhof verstehe. Was mir hier aufgefallen ist, dass ihr zwar die Daten hin und her verschickt, als Anhang usw, aber habt ihr denn auch alle den selben Regionscode ? Denn sonst koennen die Daten ja garnicht uebereinstimmen. Je nach Regionscode, haette man ja ein anderes Ergebnis. Wie fliesst dieser Regionscode ueberhaupt ein ? Gibt es da schon naeheres. Wenn ich es ueberlesen haben sollte, sry, aber der Thread ist ja nun wirklich schon unglaublich lang, da kann man nicht alles behalten.
@IchBins Tut mir leid das ich das nun so Schroff sage, aber du hast wirklich nur Bahnhof verstanden. Zu bestimmten Zeiten werden Bestimmte Regionen Übertragen, das hat die Fa. Meteotime irgendwanneinmal so festgelegt, Schau dir mal die Logdatei an, dort kannst du sehen wann was übertragen wird. http://www.dcf77logs.de/ViewLog.aspx?mode=meteo&file=DCFLog01035.log Das ist jeden Tag gleich. Dazu muss man sagen das es nur Unterschiede bei Sommer und Winterzeit gibt. Die Aufteilung der Regionscodes funktioniert nach UTC.
Hi, ist doch voellig okay, ich habe ja gefragt und schroff finde ich Deine Antwort garnicht. Es ist halt nicht so einfach, sich in ein Thema einzuarbeiten, von dem man ueberhaupt keine Ahnung hat, es aber verstehen moechte. Da muss man halt manchmal dumme Fragen stellen, weil gerade hier ist es ja nun wirklich sehr komplex geworden.
Zum besseren Verständnis die Zuordnung der d.c[] zu den Ram-Adressen: zuerst wollte ich 3 longints für die 80 Bits verwenden (96-80=16 Bits wären not used). Dann kam mir die Idee, 5 longints zu verwenden und pro longint nur 16 Bits zu verwenden, und die 5 Carrys in Bit16 zu speichern. Auch möglich wäre: unsigned int u[10], d.h. pro Byte ein uint zu verwenden und das Carry in Bit 8 zu speichern. Dann bräuchte man die union nicht, aber man müsste 10 mal Carry extrahieren und schieben. u.c[19] not used \ u.c[18] Carry von Ram12:0 \ = u.l[4] u.c[17] Ram1b / u.c[16] Ram1a / u.c[15] not used \ u.c[14] Carry von Ram1a:0 \ = u.l[3] u.c[13] Ram19 / u.c[12] Ram18 / u.c[11] not used \ u.c[10] Carry von Ram18:0 \ = u.l[2] u.c[ 9] Ram17 / u.c[ 8] Ram16 / u.c[ 7] not used \ u.c[ 6] Carry von Ram16:0 \ = u.l[1] u.c[ 5] Ram15 / u.c[ 4] Ram14 / u.c[ 3] not used \ u.c[ 2] Carry von Ram14:0 \ = u.l[0] u.c[ 1] Ram13 / u.c[ 0] Ram12 / d^=u.c[17]&0x19;//12 Ram1b d^=u.c[12]&0x06;//15 Ram18 d^=u.c[ 9]&0xd4;//18 Ram17 d^=u.c[ 4]&0x08;//1b Ram14 d^=u.c[ 1]&0x3c;//1e Ram13 Die Routine von 21 - 2e berechnet die gerade Parität von d (=Ram1c). Ich habe den Eindruch, dieses Codeschnipsel ist nicht (nur) die Dekodierroutine, sondern (auch) die Prüfung, ob ein Telegramm gültig ist. Was ist mit unserem Walter? Seit 2 Tagen kein Post von ihm...
Thomas Berends schrieb: > um mal die Menge an möglichen Kombinationen zu verdeutlichen: > selbst wenn du eine MILLIARDE Kombinationen PRO SEKUNDE (1GHz) rein > schiebst, macht das bei 64 Bit ganze 584 Jahre Thomas, du machst einen Gedankenfehler, du gehst von einem singulären System aus, welches die Lösung errechnen könnte. Ich weiss zwar nicht, wieviele Hobbyisten und Möchtegernwetterfrösche hier mitlesen, aber während im Internet tausende ihren Rechner im Verbund zur Verfügung stellen, um die Wahrscheinlichkeit der Existenz von Fröschen auf anderen Sonnensystemen zu berechnen, könnten wir doch unsere geballte Rechenleistung auf dieses Problem loslassen. Das wäre denn auch ein Interessenbarometer für dieses Forum. Notwendig dazu wäre nur jemand, der die Jobs dazu vergibt. Sozusagen ein Administrator. Sorry, aber die Idee kam mir (wie kann es anders sein ;-) auf'm Klo... "Im Mai 1999 wurde das Projekt SETI@home von der UC Berkeley gestartet, das die Daten von SERENDIP IV benutzt. Dieses Projekt benutzt die Rechenleistung von vielen Computern im Internet, die von Benutzern freiwillig zur Verfügung gestellt wird." Quelle: http://de.wikipedia.org/wiki/Search_for_Extraterrestrial_Intelligence
@eProfi, ich bastel noch ein meinem Programmer rum. Hab noch ein paar kleine Schwierigkeiten...bin aber dran.
meinereiner schrieb: > ...aber während im Internet tausende ihren Rechner im Verbund zur Verfügung > stellen...., könnten wir doch unsere geballte Rechenleistung auf dieses > Problem loslassen. Das wäre denn auch ein Interessenbarometer für dieses > Forum. Nicht nur fuer dieses Problem. Also ich bin dabei, so lange es auch auf Linux laeuft. Die Idee finde ich gut, vielleicht sollte mal jemand einen neuen Thread dazu starten. Nein, ich nicht, ich habe keine Ahnung davon.
Editieren ging nicht mehr. Ich habe eben mal nach Seti@home gesucht und bin auf BOINC gestossen. Damit laesst sich das Vorhaben eigentlich recht einfach ralisieren.
Es gibt/gab auch schon einige Kryptografieprojekte auf Boinc, siehe http://de.wikipedia.org/wiki/Liste_der_Projekte_verteilten_Rechnens Aber man muss halt auch ein wenig "Werbung" für sein Projekt machen um aktive Teilnehmen zu bekommen...
Im Anhang zwei Dateien, die beide 64*4 Durchläufe (nach der Dekodierung leerer) Wetterdaten enthalten. jede 5. Zeile zeigt den Inhalt von Ram32-3b und den Countdown. Ich kann beim besten Willen keine Übereinstimmung erkennen. Die Verwürfelung kann beliebig kompliziert sein. Z.B. habe ich oben bei der Zeitberechnung gesagt, es wäre genug Zeit, 19 solcher "files" zu erzeugen. D.h. wenn jetzt aus irgendeiner Zeile jeweils nur ein Bit herausgenommen wird, könnte so das Ergebnis (es sind 22+2 Bits) erzeugt werden. Da hat man einfach keine Chance. Ich sehe nur eine Möglichkeit: den Chip mit Glitches o.ä. zu kitzeln, um an den Code zu kommen.
@eProfi & uzi: ich fürchte, Ihr habt beide den hinteren Teil der "outer loop" falsch implementiert: Im PIC wird zuerst auf Bank 0 umgeschaltet, ein Byte geholt und wieder auf Bank1 (zurück ?) geschaltet und mit dem Schieberegister verknüpft. Es liegen also anscheinend Daten auf Bank0 die nach jedem 4.Schieben mit dem Schieberegister verknüpft werden und nicht umgekehrt. Hier könnten wir die Idee von Chris (den RAM Monitor) gut gebrauchen, damit könnte man ein bischen unter den Rock schauen. Mit dem Programmer: das mit dem "Anschreiben" scheint nicht weiterzuführen. Wenn ich nach ca. 3us das Schreiben abbreche sind nur einzelne Bits gekippt - ich sehe aber keinen Zusammenhang mit dem ursprünglichen Inhalt. Ich glaube, die Sache mit den Glitches ist da besser. Mal sehen...
@Walter ich hab mir den Code nochmal angesehen und du scheinst recht zu haben, es wird auf Bank 0 umgeschaltet, dort ein Wert geholt zurück auf Bank1? geschaltet und dort das Schieberegister mit diesem Wert ge-XOR-t. Liegt hier auf der Bank0 vielleicht ein geheimer Schlüssel (Zeit/Datum, Prüfbits oder sonstiger Schlüssel ??) Wie sieht es mit deinen Brute-Force-Versuchen mit den 12 Prüfbit aus? Bist du weiter gekommen? Hast du mal den Vorschlag aus meinem Post vom 06.05.2011 19:40 ausprobieren können?
@uzi, walter hat die 12 Bit durch, ohne ergebnis, siehe: Beitrag "Re: Was ist aus dem Thread der MeteoData geworden?"
@Thomas ja, das hab ich gesehen, aber er hat meines Erachtens das manipulierte Bit ungünstig gewählt, indem er ein Bit im Zeitstempel manipuliert hat.Ich vermute dass man nur die Wetterdaten (chiper-Bits) manipulieren darf und mit den geeigneten Prüfbits und der entsprechenden Zeit-Info einen gültigen Frame erzeugen kann. Denn wenn man die Zeitinformation manipuliert, ist keine Dekodierung möglich. Jedoch wenn man die Chipher-Bits manipuliert, gibt es anscheinend Dekoder die mit hilfe der Prüfbits den "Fehler" korrigieren können. Dies legt die Vermutung nahe, dass die Prüfbits im wesentlichen den Chipher-Bereich abdecken und ggf noch vielleicht ein paar wenige Bit als Parity o.ä den gesamten 80Bit-Frame abdecken.
@Thomas bestände die Möglichkeit einen Webservice, z.B. WSDL oder per HTTP-GET für deine Decoder zu implementieren, sodass man nicht alles per Hand in das Textfeld eintragen muss? Wobei die Priorität auf dem Webfrontend liegen sollte. Wenn Du dafür Hilfe benötigst, melde dich.
Mach doch einfach alles per ftp-Freigabe. Kommt eine neue Datei rein, wird sie abgearbeitet als CSV oder so. IE hat übrigens einen ftp-Client bereits integriert.
Ihr habt vielleicht Wünsche ;) eine FTP-Freigabe scheint wohl das einfachste zu sein, zumal ich keinen blassen dunst von wsdl habe... Zur Info, die ganze Webseite ist in c# geschrieben, .NET 4.0 basis. ftp -> Datei reinschrieben -> abarbeiten jede zeile 82 Bit (Bit 0 und Bit 7 bitte drinne lassen) Ich habe diese Woche jedoch wenig zeit, von daher kann es sein das ich erst am Wochenende dazu komme. Zugangsdaten für den FTP gibts erst wenn ich fertig bin. Gruß Thomas
So ich könnte Heute den Chip röntgen lassen. Ich möchte aber nicht das er davon kaputt geht. Damit die Leiterbahnen nicht stören löte ich ihn aus. Habe nur bedenken beim Röntgen, hat das schonmal wer gemacht und dabei einen Löschbaren Chip nicht gelöscht ?
Hi Micha, gute Idee mit dem Runterlöten. Ich denke nicht, dass der Chip oder die SW im Flash Schaden nehmen. Der Chip wird sicher nicht mehr als 1 Sekunde den Strahlen ausgesetzt werden. Zum Vergleich: unter UV muß man nen Eprom ein paar Minuten liegen lassen, bis es gelöscht ist. Walter.
Thomas Berends schrieb: > umal ich keinen > blassen dunst von wsdl habe Geht auch ohne Ahnung ;) http://www.codeproject.com/KB/webservices/myservice.aspx
Angehängte Dateien:
-
mega8.jpg
19 KB -
12c509-hkw581.jpg
33 KB
So hier nun die Bilder, wir sind durch den HKW aie auch bei dem 12c509 niuccht richtig durchgekommen auch bei der stärksten Einstellung. Zum testen noch ein Mega8, da gings ganz gut. Man kann jedoch schemenhaft die DIE erkennen, im vergleich zu einem 12c509 ist die vom hkw viel kleiner. Ober noch geht werde ich sehen, hab leider nur eine Uhr zum testen im Moment.
Wenn ich die Schatten in dem Bild richtig deute, ist der kleine Chip stark asymmetrisch gebondet, es sieht fast so aus, als wären die beiden rechten Pins unbelegt. Die Frage ist, ob es vom 12C509 verschiedene Revisionen gibt, die sich in der Die-Größe unterscheiden.
Der 12c509 soll ja sowiso nicht dem hkw entsprechen, es müsste ein 12f508 sein habe ich aber nicht. Der PIC von mir ist auch schon sehr alt, also älter als 2006 sicher.
Angehängte Dateien:
-
PIC12F509.png
310 KB
@Micha: danke für die Arbeit ich habe keinen C-Typen zum Vergleich, hab aber mal nen PIC12F509 aufgeschliffen, das kommt schon hin von der Größe. Unten drunter ist ein Shield oder eine Groundplane, von oben denke ich kann man den DIE sehen, ca. 3x3 mm, also ähnlich wie im HKW. Der PIC12C509 ist EPROM und älter, also wahrscheinlich eine größere Struktur. Beim F-Typen hat evtl. ein Shrink stattgefunden. Ausserdem gibt es den C-Typen anscheinend nicht im MSOP Gehäuse, den F-Typen schon (der C -DIE würde da ja auch garnicht reinpassen).
Was denn nun jetzt? Da verliert man ja jede Übersicht! Soll das heißen, ein am Markt nicht bekannter Chip weil Bauform nicht paßt?
Und wie kommt es dann zur Behauptung, es wäre ein 508 ?
Es wird hier immer wieder zwischen 508 (kleiner Speicher) und 509
("großer" Speicher) hin und hergesprungen.
Die lesbaren Adressen im HKW (movlw ... an 0x3FF und configword an
0x7FF, backup des oscillator Korrekturwertes...) deuten auf den 509 hin
und schließen den 508 aus.
Es muß den Chip auch schon Anfang 2008 gegeben haben (da habe ich meine
Wetterstation gekauft), das schließt neuere Typen aus.
Aha, danke. Und dann gibts noch den EMx. Bei dem wohl noch nichts ausgelesen wurde.
Ich werde heute mit der Bearbeitung der Weboberfläche beginnen, Ich habe entschieden dies per HTTP-Upload zu realisieren, wann ich damit fertig bin kann ich nicht sagen. Ich nutze diesen post als Ankündigung das ich nun beide Decoder zu Entwicklungszwecken nutze. Falls jemand noch Datensätze dekodieren möchte, bitte ich dies innerhalb der nächsten 90min zu tun. thomas
wollte keine Verwirrung schaffen ich weiß nicht ob es ein 508 oder 509 ist, ich habe nur nach der Bezeichnung in dem Thread gesucht und das was ich gefunden hab war ein 508. Also meine Vermutungen bzgl. Typ ignorieren. Leider ist mir das zu spät eigefallen wie man evtl. doch ein besseres Bild bekommen könnte. Nicht nur einmal schießen auf den Film sondern 2-3 mal dann wäre vielleicht der Kontrasst besser geworden.
@Abdul K.: ja, der EM6580 ist anscheinend in meiner DV323 verbaut. Dort ist ein unbestückter Footprint, anscheinend eine alternative Möglichkeit für den auf meiner Platine vorhandenen "schwarzen Klecks". Habe keinen anderen Controller gefunden, der auf diesen Footprint passt. Auch sind die Timings etwas anders als bei dem vermutlichen PIC. Der EM6580 hat soweit ich weiß keinen Ausleseschutz. Allerdings setzt der Hersteller auf "Security by Obscurity" indem er die Befehle für das InCircuitProgramming nicht offenlegt. Dies lässt sich aber vermutlich durch das Mitschneiden bei einem offiziellen Programmer herausfinden. Eine weitere Hürde in meinem Fall ist, dass der Testpin nicht aus dem Klecks herausgeführt ist. Somit lässt sich der Controller nicht in den Programming Mode versetzen. Evtl. kann man das Ding aber röntgen o.Ä. und dann geziehlt ein Loch in den Klecks bohren, um an den Testpin zu kommen (theoretisch ;-) Walter
Bei mir sind zwei Barigo MT300 eingetrudelt, ziemlich riesige Teile. http://www.barigo.de/module/uploads/download_file_20.pdf Hinten sind 6 Schrauben, aber ich kann sie trotzdem nicht öffnen. Sind auf der Vorderseite hinter dem Chromrahmen weitere Schrauben? Ich vermute, es ist die MeteOn3 oder MeteOn7, die DIET aus dem alten Thread schon untersucht hat. Autor: Didi Barth ({diet}) Datum: 16.03.2007 10:49 Beitrag "Re: AVR: Wetterinformationen über DCF77" "noch einer" hat sie evtl. auch. Sie hat auf der Rückseite den Deckel, hinter dem sich der 2x8=16-polige Wannenstecker verbirgt. Leider sind die Fotos nicht mehr online, hat die jemand?
Angehängte Dateien:
-
METE-ON3-DCF77.jpg
47 KB -
METE-ON3-Platine.jpg
78 KB -
METE-ON3-Stecker1.jpg
39 KB -
METE-ON3-Stecker2.jpg
42 KB
@eProfi, wie es der Zufall will, Ja... Ich habe damals zur Sicherheit den kompletten Thread inklusive der Verlinkten Dateien gespeichert, zumal das mit der Begründung geschlossen wird, das es vielleicht rechtlich nicht ganz okay ist.. Anbei die Bilder... thomas
ElectronicMarin (EM) hat µC (dürfte noch ein 4-Bitter sein) als "Flash" für die Entwicklung des Programms, für die Serie wird dann ein Maskenprogramm verwendet. Letzteres kann nicht ausgelesen werden. Für geringe Stückzahlen ist die Flashversion sicher sinnvoll, ab einer Stückzahl, ich schätze ein paar k, wird die Maskenversion deutlich günstiger. Die Einmalkosten für die ROM-Maske sind gar nicht so hoch, man darf sie aber nicht vergessen. Die aktuellen Preise muß man erfragen. Wenn ich mein Programm schützen möchte, würde ich ggf. auch bei kleineren Stückzahlen zur Maskenversion tendieren. Natürlich: Ein Bug, neue Maske (=Einmalkosten) wird fällig! Ob das Spielchen Maskenversion auch beim PIC möglich ist weiß ich nicht, dafür kenne ich die Teile zu wenig.
Danke, Thomas. Hab es endlich geschafft: im Gehäuse ist ein schwarzer Rahmen, der mit der Vorderseite verschraubt ist. Mit der Hinterseite ist er nur geklipst. Diese Clip-Verbindung muss man trennen, dann geht es ganz leicht. Ich hatte versucht, den Rahmen von der Vorderseite zu trennen. Es ist die Hideki DV323, die auch Walter hat. Nach einem Reset zeigt sie SW V1.2 und DB V0.5 an. U1: Spannungsregler U2: kleiner Klecks U3: nicht bestückt (Alternativ-Bestückung zu U4) U4: ATMEL 702 24C512N 5U27 A U5: nicht bestückt (Alternativ-Bestückung zu U2) großer Klecks mit 4*26=144 Pins (Platine sagt 141) Der Temp- und Feucht-Sensor ist mit SHT01L beschriftet. Es sind 8 Platinen: 1: E-PC-D323-0F0V0 DV323-MAIN-PCB REV:0.1 07.6.13 (13.06.2007) 2: E-PC-6015-0F0V0 REV 0.2 060829 DCF-HBG-Empfänger mit IROX-Logo 3: E-PC-D323-2-0V0 DV323-LED-PCB mit 4 blauen LEDs 4: SV2 für 16-pol-Programmieradapter 5: Sensorplatine SHT01L 6: E-PC-T530-2F0V0 433RX-100M REV0.3 433MHz-Empfänger 7: E-PC-D323-1-0V0 DV323-KEY-PCB REV 0.0 07.5.18 8: E-PC-R820-2-0V0 Licht-Taster RC82-SNZ REV: 0.1 020427 51 TestPunkte 6 gelötete Jumper Micha (Gast) Datum: 13.05.2011 20:41 Schau auf den Wiki-Artikel DCF77 Wetterinformationen .
8 Platinen, kommt mir persönlich etwas viel vor.. Das mit der Seite zum Dekodieren von ganzen Sätzen an Daten verzögert sich etwas, u.A. familiäre Gründe... Gruß Thomas
Angehängte Dateien:
-
Busy_high.png
2,8 KB -
Busy_high_2.png
2,6 KB -
Busy_low.png
3,1 KB
das mit den 8 Platinen kann ich bestätigen, zu mindest in etwa: DCF77, 433MHz, Feuchtesensor sind bei mir auch auf eingenen Platinen, Hauptplatine und eine Platine für die Tasten (hinten). Habe jetzt auch 2 Chips parallel laufen ;-) Hab nochmal nen 2ten Test mit den ersten 12 Bit gemacht, dieses Mal habe ich weiter vorne ein Bit gekippt - leider auch keinen Erfolg. Mit ist noch etwas bei dem PIC aufgefallen: Wenn Pin5 high ist (busy) geht er ca. alle 2-3 Sekunden für ca.11us auf low, 2us vorher kommt er anscheinend von hochohmig (Busy_high.png, Busy_high2.png) Umgehekrt: Wenn Pin 5 low ist (nicht busy) geht er ca. alle 2-3 Sekunden für ca 13 us auf high, dann kommt ein wieder ein Knick und ca.2us später geht er auf low. (Busy_low.png). Ich werde mir jetzt eine Mete-On3 besorgen, da kann der Chip angeblich korregieren - vielleicht bringt uns das weiter.
Schau ins Datenblatt und finde dort heraus, wann Pins automatisch hochohmig werden. WDT, Sleep usw. wären abzuklappern. Eventuell bekommst du dadurch Querinformationen.
bei PIC12F509: man kann den Speicher an den Adressen 0x405-0x43F beschreiben. Im Datenblatt sind sie als "reserved" gekennzeichnet. Leider ist es mir (noch) nicht gelungen, den Code an dieser Stelle auszuführen. Wäre dies möglich, so wäre es ein Leichtes den von Chris vorgeschlagenen RAM-Monitor zu implementieren. Weiß jemand, wozu dieser reservierte Bereich gedacht ist ? Das Bit PA1 scheint nicht implementiert zu sein. Ein "goto" verhält sich so, als ob PA1 gleich 0 ist. Der PIC scheint alle 2,3 Sekunden (WDT) aufzuwachen. Dann schaltet er PIN5 (Busy) für ca. 12us auf invertierten Zustand: wenn er Busy ist (PIN5 normal high) -> low, wenn er Telegramme decodieren kann (PIN5 normal low) -> high. Es wurde im alten Thread von einem Testmodus berichtet in welchem man (zumindest bestimmte) Telegramme wesentlich häufiger zum DCIC schicken kann als im "normalen" Betrieb.
Vielleicht war das eine Option, damit der Entwickler selber seinen Code effizienter testen konnte? Vielleicht hat er einen vorgefertigten Pack von Wetterdaten häufiger durchgeschickt... Kann mich allerdings nicht an einen Testmode erinnern. Beschreibbare Bereiche benutzt man z.B. für Seriennummern. Eventuell gibt es auch noch einen Encoder-Mode? Z.B. weil der Entwickler seinem Kunden Meteo-Time den Algorithmus nicht geben wollte...
'nabend allerseits, Beim encodermode müsst man dann aber wetterdaten und Zeittelegramm sinnvoll reinschieben, wobei hier keinerlei infos zu finden sind... möglich wäre das der Decoder dann automatisch in diesen "modus" wechslet ... ich bezweifle das jedoch... An der Decoder-seite bin ich bei, vermutlich werde ich morgen oder sonntag fertig sein... Dann könnt ihr ganze dateien hochladen, maximal 10MB am stück, das sollte reichen, aber dann auch sehr lange dauern... 2 Decoder, mehr hab ich nicht zur freien verfügung, der dcf-reciever muss ja auhc noch seine daten dekodieren.
Walter Freywald schrieb: > bei PIC12F509: > man kann den Speicher an den Adressen 0x405-0x43F beschreiben. Im > Datenblatt sind sie als "reserved" gekennzeichnet. > Leider ist es mir (noch) nicht gelungen, den Code an dieser Stelle > auszuführen. > > Wäre dies möglich, so wäre es ein Leichtes den von Chris vorgeschlagenen > RAM-Monitor zu implementieren. > > Weiß jemand, wozu dieser reservierte Bereich gedacht ist ? Hallo Walter, ich vermute das sind Testregister, die dazu dienen nach der Produktion den Chip zu testen. Sie sind für den internen Gebrauch bei der Produktion gedacht. Code kann man da vermutlich nicht ausführen. Du kannst ja mal etwas mit den einzelne Bits in diesen Testregistern spielen, vielleicht gibt der Chip ja ein Geheimnis preis....;-)
ist der 12f509 debugfähig? wenn ja, kann man dann nicht den chip mehr oder weniger sein geheimnis, zumindest bruchstückhaft entlocken, indem man in alle register definierte werte schreibt, und dann den instruction-pointer immer per hand um 1 erhöht und dann nachschaut was da ausgeführt wird (änderung der register) natürlich kann man dann nicht alle befehle herausholen, aber manches sollte möglich sein, sofern das teil debugfähig ist...
Thomas Berends schrieb: > 'nabend allerseits, > > Beim encodermode müsst man dann aber wetterdaten und Zeittelegramm > sinnvoll reinschieben, wobei hier keinerlei infos zu finden sind... > möglich wäre das der Decoder dann automatisch in diesen "modus" wechslet > ... > ich bezweifle das jedoch... > Ich eigentlich auch :-) Wäre untypisches Vorgehen des Entwicklers. Eher so wie ich es mache - ich bin ja nicht normal. Es war nur als Hinweis für folgendes gedacht: 1. Warum ist der PIC größer als vermutlich notwendig? 2. Eventuell ist das gefundene freiliegende Schieberegister das welches encodiert.
Guten Abend, Ich habe soeben die neue Seite online gestellt, es gab ziemliche viele Probleme, hoffe dass es nun einigermaßen stabil ist... An diesn Post habe ich eine Beispieldatei angehängt, wie eine Datei aussehen muss damit die Verarbeitet wird. alles wichtige steht auf der Seite selbst. Die Angehängte Beispieldatei habe ich dort zum Testen hochgeladen, damit ihr das Ergebnis anschauen könnt wie das aufgebaut ist. Bevor ihr eine Datei hochladet, achtet auf den Dateinamen, damit dieser Sinnvoll ist und Ihr den nachher auhc wiederfinden könnt. Ich weiß ja nicht wie groß der Ansturm ist. Doppelte Dateiname sind kein problem, da die Anwendung intern mit GUIDs arbeitet. Desweiteren gibt es noch kleine Probleme mit dem Zeichensatz in der Ausgabedatei. Darum keine Umlaute, sonderzeichen etc. verwenden. Ansonsten gibts Zeichensalat (Siehe ergebnisdatei im anhang). Sollten noch Fragen sein, einfach schreiben. Wenn Datensätze schonmal dekodiert wurden, werden diese aus der Datenbank genommen, um die Dekoder nicht unnötig zu belasten. Dann wird ein Kommentar vor dem Datensatz hinzugefügt, der darauf hinweist. Der Link bleibt wie gehabt: http://www.dcf77logs.de/DecoderAccess.aspx
nochmal zum PIC: ich habe das jetzt mal mit einem "normalen" PIC12F509 probiert: (VCC bleibt immer an) - SW1: schreibt Daten ins RAM - Baustein löschen - SW2 reinprogrammieren: liest das RAM und gibt den Inhalt sync seriell aus Ergebnis: der RAM Inhalt bleibt auch nach dem Flash löschen erhalten Das bedeutet: man könnte den PIC z.B. nach Einlesen der Daten mittels Reset anhalten, mit der ReadRam neu flashen und das RAM auslesen. Oder beim dem ominösen Schieberegister am Anfang eine Endlosloop (mit WDT reset) einbauen. Dann hätte man die Daten, die man vorher reingeschoben hat in der korrekten Form im SR liegen und auf Page 0 würde man die Daten bekommen, die XOR nach jedem 4.Schieben auf das SR abgebildet werden. Der PIC ist danach allerdings tot (also (vorerst ;-)) nicht mehr als DCIC zu gebrauchen)... Also sollte wohl überlegt werden, welche Daten reingeschoben werden und wann die Kiste angehalten und ausgelesen wird.
Aja. Soviel zur Sicherheit eines PIC. Also nun den Schlachtplan für ein möglichst effektiven Angriff.
Thomas, Du hast Post (Formular und snail). Weitere Möglichkeit: Nach einem Reset wird nach 3ff gesprungen. Dort steht ein MOVLW mit dem Calibrierwert. Diesen Befehl kann man ändern / einen NOP draus machen. D.h. man sieht die oberen 6 Bits des W zu dem Augenblick, bevor der Reset ausgelöst wurde, anhand der Frequenz, mit der der µC dann läuft. Man kann nun eine Schaltung bauen, die den DCIC immer wieder mit den selben Daten füttert und dann sukzessive einen Zyklus später resettet. Wir wissen also, was in 0x060 steht: MOVW OscCal Ausgänge konfigurieren, da sie durch den Reset/WDT Eingänge wurden Entscheiden, ob es ein POR oder ein WDT war Alternativ könnte man die sichtbare Routine so ändern, dass sie W und die zu schiebenden Daten seriell ausgibt, das Geschiebe ein externer µC übernimmt und wieder seriell zurückschreibt (ähnlich wie Chris' Ansatz). Damit hätte man alle 8 Bits von W. Wir schaffen es !
Hallo eProfi, guter Vorschlag. Das W-Register wird beim Reset tatsächlich nicht verändert (ich habs ausprobiert - ich hätte es nicht gedacht !). Sollte funktionieren, sofern der Wert wirklich ins OSCCAL Register geschrieben wird. PA5 im Statusregister (zur Auswahl der RAM Page) wird beim Reset wohl auf 0 gesetzt - zumindest laut Datenblatt. Das mit dem Monitor habe ich schon mehrfach versucht - ich bekomme es einfach nicht hin - will aber nicht ausschließen, dass es möglich ist. Chris hatte ja angedeutet, dass er es geschafft hätte. Ich habs immer noch nicht aufgegeben, Software im Bereich 0x405+ auszuführen. Beschreiben kann ich den Bereich ja und der Program Counter ist 12 bit breit, sollte das also abdecken. Und ich werde mal nach "versteckten" ICSP Befehlen suchen. Evtl. gibt es da etwas, was uns weiterbringt (z.B. Read RAM ;-) Für mich zeigt sich zumindest immer mehr, dass dieser PIC nicht wirklich gut für Sicherheitsanwendungen geeinet ist. Walter. PS: klar - wir bekommen das hin.
eProfi schrieb: > Ob die Entwickler von unserem Treiben hier wissen und wie sie darüber > denken? Ob sie sich denken: hätte nie gedacht, dass die Hacker so weit > kommen, Wie weit denn? Ihr ratet herum, aber rausgekommen ist dabei genau nichts. eProfi schrieb: > oder ob sie sich inf Fäustchen lachen, wie stümperhaft wir hier > agieren (seit 4,25 Jahren). Wir liegen schon alle auf dem Boden vor Lachen. Wenn ihr so weitermacht, habt ihr in 10 Jahren immer noch nichts.
Jungs, wir sind wieder dabei: ich sag nur: ISP cmd 0x00 ;-) I'll be back soon ! PS: security by obscurity - das geht einfach in die Hose...
Also: ich habe ein bisschen herumprobiert mit den ICSP Befehlen. Dokumentiert sind: 0x02: load data (um sie danach zu schreiben) 0x04: read data 0x06: inc PC 0x08: start programming 0x0E: end programming 0x09: bulk erase ich habe eine Komnination gefunden, mit welcher ich Code im Bereich 0x405+ ausführen kann. der Bereich dort sie so aus: 0400 00F 00F 00F 00F C32 FFF FFF FFF CDF 002 A0A FFF FFF FFF FFF FFF 0410 FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF 0420 FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF 0430 1D7 01B E4A 00D FFF FFF FFF FFF FFF FFF 003 FFF CFE C32 C24 AF0 ab 0x40B habe ich also 37 worte "frei", wenn ich den beschriebenen Bereich mit "0" überschreibe komme ich sogar auf insgesamt 47 Worte. Meine momentane RAM-Read Routine hat 24 Worte, pass also gut rein (s.Anhang). Ich kann damit also den Controller an "beliebiger" Stelle anhalten (/MCLR -> Vpp) und dann mit einer kleinen Befehls-Sequenz den Code ausführen um das RAM auszulesen. Der Baustein sollte weiterhin funktionieren, evtl. muß ich noch den Watchdog während des Auslesens zurücksetzen (2 Worte mehr, passt aber immer noch). Somit kann ich z.B. das RAM direkt nach dem reinclocken anschauen oder während des Rausclocken oder sonst wo. Ich habe das ganze allerdings bisher nur mit "normalen" PIC12F509 probiert, weiß also nicht sicher, ob das auch mit DCIC funktioniert. Hat jemand hier einen PIC InCiruit debugger. Evtl. lassen sich da noch ande Befehle herausfinden (messen). Da kann man das ganze ggf. noch einfacher gestalten. Bevor ich das mit dem DCIC probiere hätte ich gerne ein paar Meinungen dazu gehört. Danke schon mal im Voraus. Walter.
Viele neue Gedanken: ist es schon mal jemandem gelungen, einen neuen (=nicht gesendeten) gültigen Datensatz zu finden? Meine Überlegung war folgende: An jedem Datum muss jede Wetterinfo codiert werden können. d.h. aus den ersten 40 Bits werden 22, d.h. Korrektur und Verifizierung auf Gültigkeit sind 40-22=18 Bits Ich habe 2**12=4096 Datensätze (gleiches Datum) decodieren lassen, d.h. die Wahrscheinlichkeit ist 1/ 2**(18-12) = 1/64, dass ein gültiger Datensatz dabei ist. Und tatsächlich gibt es bereits einen Treffer:
1 | 111111111111112222222222222233333333333333mmmmmm08ssssss20tttttt21mmm01wt5jjjjjj11 |
2 | 0011000000000100010101011000000101000111000001000000000100100001001000010110001000 000000000000000000000010 2011'0121:2008 |
3 | 0011000000000100010101011010011001011000000001000000000100100001001000010110001000 101110000001000100111010 2011'0121:2008 neu! |
4 | o00000o000111111112222222233333333444444445555555566666666777777778888888899999999 |
5 | o00000o000001111000001000000000000000000000010101101100000000000000000000010011000 |
6 | 0 0 c 3 8 0 0 0 0 0 4 d 6 0 0 0 0 0 9 1 |
7 | o00011o001000000000000000000000110110101000000000000000000000010000011110000000000 |
8 | 1 9 0 0 0 0 0 6 d 4 0 0 0 0 0 8 3 c 0 0 |
> guter Vorschlag. Das W-Register wird beim Reset tatsächlich nicht > verändert (ich habs ausprobiert - ich hätte es nicht gedacht !). > Sollte funktionieren, sofern der Wert wirklich ins OSCCAL Register > geschrieben wird. Ich habe damals, als ich Argumente sammelte, ob es ein 12C oder 12F ist, mir notiert, dass dieses Vorgehen beim 12F nicht funktionieren würde. Momentan fällt mir der Grund jedoch nicht ein. Zur Mete-On7: Laut ei08_09_064.pdf ist sie baugleich mit der Hideki DV323, die ich habe. Bisher dachte ich, dass die 3 Hersteller Origon, IROX und Hideki jeweils eigene Produkte fertigen würden, aber wie mir scheint, stecken zumindest die beiden letzten unter einer Decke (in der Hideki DV323 sitz ein IROX-Empfänger). Ist jetzt auf einer Mete-On3 ein Chip (wie ist er beschriftet?) oder ein Klecks? Moment mal, der OscCal hat beim 12F ja 7 Bits (bei 12C sind es 6). Bei den späteren (z.B. 12F628) kam man davon ab, evtl. weil es bekannt wurde, dass das eine Sicherheitslücke ist. 12F510 hat nicht mehr Speicher, sondern ADCs. > Das bedeutet: > man könnte den PIC z.B. nach Einlesen der Daten mittels Reset > anhalten, mit der ReadRam neu flashen und das RAM auslesen. Daran dachte ich auch schon. Brainstorm: 60 rekonstuieren und WDT schneller machen, um die Wartezeit zu verkürzen OPTION ist nach Reset FF 1 = Prescaler assigned to the WDT OscCal: in welchem Frequenz-Bereich trimmbar? Erratum: Bits <7:2> of W register contain oscillator calibration values due to MOVLW XX instruction at top of memory. Muss <7:1> heißen Walter: Zum Cmd 0 und anderen Cmds habe ich in der Programieranleitung für die 12f6xx DS41204D (page 11) was gefunden: Load Configuration x x 0 0 0 0 0,(14),0 Da dürfte es einige Analogien geben. Deine neuen Erkenntnisse führe ich mir gleich mal zu Gemüte.
Es klingt zwar alles gut, aber scheinbar können nur noch PIC-Enthusiasten mitmachen. Was hat ein Oszillator-Trimmregister mit der Sicherheit zu tun? Kannst du das mit dem Datensatzbeispiel nochmal simpler erklären? Zumindest bei der Kodierung muß man ja kein PIC-Kenner sein.
@Abdul: Der Pic hat ne Zwangspause nach dem Dekodieren, damit man keinen BruteForce durchführen kann. Reduziert man die Werte, muss man nicht mehr so lang warten... @all: Idee: Man könnte in den bereits dekodierten Datensätzen suchen, ob irgendwelche Wetterinfos "0" oder "1" (0000000000) sind. Damit wäre der Schlüssel quasi sichtbar, da man den Anfangswert kennt!
Du willst die Zeit verringern mit Trimmen? Von 40 Sekunden auf 38 Sekunden? Versteh ich nicht ganz. Ist doch nicht die Mühe wert. Oder kann man das Teil durch illegale Einstellungen komplett verbiegen? Was ich über deinen zweiten Absatz denken muß, ist mir auch nicht so recht klar. Vielleicht bin ich einfach zu spät und bettreif. Sorry.
Hallo Abdul, Aus den am 21.01.2011 versehentlich gesendeten Leerdatensätzen habe ich mir einen (20:08) herausgesucht, weil er nur 22 gesetzte Bits hat. Von diesem habe ich Byte 3 und 4 geändert: einfach von 0000 - 0fff alles durchprobiert (momentan läuft gerade 1000 - 1fff). Ein Wert hat eine gültige Antwort geliefert. Dadurch, dass ich die anderen Bits gleichgelassen habe, ist der Schlüssel (zumindest teilweise) der selbe wie im Original-Datensatz. Das mit dem OscCal ist eine PIC-Eigenart: Beim Reset wird der ProgramCounter auf 3ff gesetzt. Dort steht von Hersteller reinprgrammiert ein MOVLW (Lade Accu = W = WorkRegister) mit einem individuellen Wert, der bei Herstellertest die 4 MHz RC-Frequenz ergab. Diesen Wert kannst Du im Anwenderprogramm in die Speicherstelle OscCal schreiben (oder auch nicht). Die Adresse 3ff ist nicht geschützt, d.h. man kann z.B. einen NOP (00) reinprogrammieren. Wenn die Entwickler diesen Wert (gutgläubig, es sei der ausgemessene Wert) ins OscCal reinschreibt, W wurde aber nicht mit dem MOVLW geändert, sondern der NOP hat ihn nicht verändert, spiegelt die Frequenz, mit der der µC dann läuft, den W zum Zeitpunkt vor dem Reset hatte, wider. Man muss die Frequenz nur hinreichend genau messen, um den Wert (die obersen 7 Bits) von W zu wissen. Nun liegt es an Dir, wann Du einen Reset auslöst. Jede Änderung des Strobe-Einganges (zumindest während der Wartezeit) löst einen PinChange-Reset aus (der F509 hat keinen PinChange-Interrupt). > Der Pic hat ne Zwangspause nach dem Dekodieren, damit man > keinen BruteForce durchführen kann. Reduziert man die Werte, > muss man nicht mehr so lang warten... Das ist eine andere Baustelle. Deswegen habe ich oben gefragt, um wieviel man den RC trimmen kann. Ich vermute, dass man die Frequenz und damit die Wartezeit um 50% ändern kann. > Oder kann man das Teil durch illegale Einstellungen komplett verbiegen? Da sind wir gerade dran.
Und wenn ihr es geschafft habt? Schmunzeln und Schweigen? Taucht die Dekodierroutine irgendwo auf? Wird auch dieser Thread gesperrt?
von geschafft sind wir noch weit, weit entfernt. Wenn das mit dem RAM Monitor funktionieren sollte (das ist noch nicht sicher), dann haben wir ein Mittel an der Hand mit dem wir dem DCIC ein bisschen unter den Rock schauen können (hier können die MCU-Nerds den Crypto-Nerds mal helfen ;-) Sorry, mal etwas "off-topic": Und daher auch an dieser Stelle die Bitte an die "Verantwortlichen": Anhand dieses Threads lässt sich durchaus lernen, wie man "es nicht macht". Auf der anderen Seite wir hier deutlich, dass trotz "popligem PIC", vermutlich properitärem Crypto und haufenweise Datensätzen es dennoch nicht mal eben so "geknackt" werden kann (auch wenn hier vermutlich nicht die Crypto-Experten unterwegs sind und keiner Vollzeit daran arbeitet...) Und: es geht hier um Wetterdaten (hallo: es sind nicht die Lottozahlen oder die Launchcodes für Atomraketen - obwohl...;-) - Man kann diese Daten nur sinvoll in Europa nutzen (siehe Karten der Wetterstationen) - das ganze ist Patentgeschützt -> kommerziell lässt es sich nicht legal nutzen, auch wenn man "den Schlüssel" hat Ich denke daher, die Gefahr ist nicht sehr groß, dass hier jemand geschädigt wird. Und wie eingangs erwähnt: es ist noch ein weiter Weg. Walter.
Walter Freywald schrieb: > Anhand dieses Threads lässt sich durchaus lernen, wie man "es nicht > macht". Auf der anderen Seite wir hier deutlich, dass trotz "popligem > PIC", vermutlich properitärem Crypto und haufenweise Datensätzen es > dennoch nicht mal eben so "geknackt" werden kann (auch wenn hier > vermutlich nicht die Crypto-Experten unterwegs sind und keiner Vollzeit > daran arbeitet...) Sobald wir verstanden haben, wie die Crypt funktioniert, können wir unsere eigenen Systeme bauen, welche genauso geschützt sind. Immerhin gehts ja nicht darum Meteo zu knacken, sondern aus dem Schutzmechanismus zu lernen, da er offenbar sehr gut funktioniert...
Ehrlich gesagt Walter, ich habe es nicht im Detail verstanden. Aber in etwa den Sinn dahinter. Danke. Die leeren Datensätze sind also die, die mal gesendet wurden als offenbar keine Daten online von Meteo verfügbar waren. Richtig? Für eine eigene unabhängige Verwendung des Systems für eigene Projekte benötigt man aber dann einen einen neuen Schlüssel UND die Verschlüsselungsroutine. Dafür lohnt der Aufwand sicherlich nicht und man findet bestimmt genug Ideen im Internet. Ansonsten ist es aber ein echter Elektronik-Krimi. Ganz ohne Blut, nur Schweiß ;-)
Angehängte Dateien:
-
mete_on3_w1.jpg
40 KB
Bei ebuy.at ist ein Posten MeteOn3 Mete-On 3 aufgetaucht für 5490+980. Ich würde eine Sammelbestellung machen, da geht bestimmt was mit dem Preis. Wer hat Interesse? Ist eine weitere Uhr mit korrigierendem Decoder bekannt? Gute Nachricht: Thomas baut demnächst 2 weitere Decoder an seinen Rechner --> doppelte Decodierrate --> halbe Wartezeit. Außerdem besteht eine gute Chance, dass die Wartezeit übersprungen werden kann. Dann schaffen wir sicher deutlich mehr als 7200 Sätze pro Stunde (momentan 3600/36*2=200, bald 3600/36*4=400). Der oben genannte gefundene gültige Datensatz war wohl ein Glückstreffer, bisher sind über 10000 Sätze decodiert, kein weiterer Hit. Autor: Katzenschreck! (Gast) Datum: 27.05.2011 09:31 > Und wenn ihr es geschafft habt? Schmunzeln und Schweigen? Taucht > die Dekodierroutine irgendwo auf? Wird auch dieser Thread gesperrt? Das verbietet die Hacker-Ethik. Abdul: > Die leeren Datensätze sind also die, die mal gesendet wurden als > offenbar keine Daten online von Meteo verfügbar waren. Richtig? Es wurden schon Datensätze geliefert, denn es sind ja gültige Daten, aber es wurde vergessen, Wetterdaten in den ENCODER zu füttern.
> Autor: Katzenschreck! (Gast) Datum: 27.05.2011 09:31 >> Und wenn ihr es geschafft habt? Schmunzeln und Schweigen? Taucht >> die Dekodierroutine irgendwo auf? Wird auch dieser Thread gesperrt? > Das verbietet die Hacker-Ethik. Was verbietet die Hacker-Ethik?
@eprofi: danke für den Hinweis. Ja, bin dabei - eine für mich bitte. Mit dem RAM-Monitor dauert es leider noch ein bisschen - ich will mir den Chip nicht zerschießen. Hab mir nen Microchip-Debugger geordert, evtl. finde ich darüber etwas mehr heraus und es ist ggf. garnicht mehr nötig, den PIC zu beschreiben. Ich hoffe auf einen Debugger Befehl wie "Read RAM" o.ä. Wenn jemand mitexperimentieren will: folgende Fakten gibt es: - RAM Inhalt und W-Register bleiben nach einem Reset erhalten - man kann den PIC anhalten und in den Programmier Modus (Debugmodus ?) wecheseln, indem man /MCLR von VCC auf VPP zieht. Senkt man /MCLR wieder von VPP auf VCC ab läuft der PIC (anscheinend) an gleichen Stelle weiter - es scheint undokumentierte Befehle im ICSP zu geben (Bedarf noch näherer Untersuchung, z.B mitschreiben beim Debugger) - Wenn man den PIC anhält kann man den Programcounter versetzten und den PIC weiterlaufen lassen. Damit ist es möglich, Code an 0x405+ auszuführen. Der Code dort liest dann z.B. das RAM aus oder ändert den "Watchdog Counter" ;-) Die Idee ist folgende: Es sieht so aus, dass der PIC 15x auf einen WDT Reset wartet, danach ist er bereit, einen Datensatz zu decodieren und setzt anscheinend den Counter wieder auf 0. Wenn man also einen Datensatz decodieren will läuft das etwa so: - PIC laufen lassen (für init, etc.) - PIC anhalten, Code an 405+ ausführen -> der setzt den WDT counter auf den richtigen Wert und lässt den WDT einmal kommen - PIC ist bereit (Counter Wert stimmt ja) -> Telegram decode. Damit käme man auf ca. 5 Sekunden pro Telegramm. Soweit die Theorie. Das Problem, dass ich noch habe, ist, dass ich 2 Byte RAM für Bitcounter und Datenwort brauche, diese Positionen kann ich also nicht auslesen. Habe für den ersten Test die Adressen 0x0f und 0x0e verwendet. Diese kann ich in einem 2.Schritt auf andere Adressen setzen (1 -> 0 schreiben geht immer), z.B. 0x08 und 0x07. Hat jemand einen PICKIT oder ähnliches an dem er ein bisschen mitschneiden kann (ICSP Befehle) ? Walter.
Angehängte Dateien:
-
Decoder_auf_der_Platine.JPG
430 KB -
Decoder_am_Server.JPG
610 KB
So, erstmal vielen dank an eProfi, für die 2 Decoder. Diese habe ich nun soweit an den Server dran, und seine Verbesserungsvorschläge umgesetzt. Ich weiß aber jetzt nicht in wie weit die Prognose passt, wann das ganze fertig ist. Müsste man mal schauen. Ich habe das nämlich etwas einfach berechnet, ich nehme pro Datensatz 38s Wartezeit an und teile dies durch die Anzahl der dekoder. Ein DCIC war etwas Problematisch weil die Pins etwas verbogen waren, habe es aber hinbekommen. Sollten noch Fehler auf der Seite sein, also das z.b. Der Status da falsdch angezeigt wird, oder irgendwas anderes nicht stimmt, einfach mailen -> Kontaktformular oder PN Anbei ein paar fotos vom Aufbau. Gruß Thomas
Micha schrieb: > So hier nun die Bilder, wir sind durch den HKW aie auch bei dem 12c509 > niuccht richtig durchgekommen auch bei der stärksten Einstellung. > Zum testen noch ein Mega8, da gings ganz gut. > Man kann jedoch schemenhaft die DIE erkennen, im vergleich zu einem > 12c509 ist die vom hkw viel kleiner. > Ober noch geht werde ich sehen, hab leider nur eine Uhr zum testen im > Moment. Ich könnte auf der Arbeit Bilder mit einem Elektronenmikroskop machen, wenn mir jemand den Chip und etwaige vergleichsmodelle zur Verfügung stellt.
Walter Freywald schrieb: > - Wenn man den PIC anhält kann man den Programcounter versetzten und den > PIC weiterlaufen lassen. Damit ist es möglich, Code an 0x405+ > auszuführen. Der Code dort liest dann z.B. das RAM aus oder ändert den > "Watchdog Counter" ;-) Mal eine Frage als PIC-unkundiger: Kann man da nicht vielleicht auch Code unterbringen der das Program Memory ausliest? Oder geht das wegen irgendwelcher Protection-Features nicht? Viele Grüße, Simon
Hallo Simon, gute Idee, aber: Soweit ich weiß (also offiziell) geht das nicht. Das hat keine Protection- sonder eher Bus- oder Architektur-Gründe. Der Adressraum ist beim PIC12F509 nicht linear. RAM und Flash hängen an unterschiedlichen Bussen. Man kann also keinen Zeiger verbiegen und das Flash auslesen. Auch ist der RAM 8Bit breit, der Flash 12 Bit. Walter
Walter Freywald schrieb: > Hallo Simon, > > gute Idee, aber: Soweit ich weiß (also offiziell) geht das nicht. > Das hat keine Protection- sonder eher Bus- oder Architektur-Gründe. > > Der Adressraum ist beim PIC12F509 nicht linear. RAM und Flash hängen an > unterschiedlichen Bussen. Man kann also keinen Zeiger verbiegen und das > Flash auslesen. Auch ist der RAM 8Bit breit, der Flash 12 Bit. Beim AVR gibt es spezielle Assembler-Instruktionen um auf das Program-Memory zuzugreifen, bei denen ist das auch kein einheitlicher Adressraum. Ich würde vermuten, dass das auch bei PICs gehen sollte. Nutzdaten ins Program-Memory zu speichern, die man zur Laufzeit irgendwann ins Ram lädt um sie weiterzuverarbeiten ist ja durchaus eine sinnvolle Anwendung... Ist natürlich die Frage, ob man den Code in die paar verfügbaren Zellen reinpacken kann... Viele Grüße, Simon
Simon, die PICs haben eine strenge Harvard-Architektur, es gibt keine Verbindung zwischen Programm- und Datenbus (bis auf die MOVLW, RETLW- etc. Befehle). To begin with, the PIC12F508/509/16F505 devices use a Harvard architecture in which program and data are accessed on separate buses. This improves bandwidth over traditional von Neumann architectures where program and data are fetched on the same bus. Separating program and data memory further allows instructions to be sized differently than the 8-bit wide data word. Instruction opcodes are 12 bits wide, making it possible to have all single-word instructions. > Beim AVR gibt es spezielle Assembler-Instruktionen um auf das > Program-Memory zuzugreifen, bei denen ist das auch kein > einheitlicher Adressraum. Hat der PIC nicht. Habe gerade versucht, vom Programm aus in den 400er-Bereich zu springen, indem ich vor dem GOTO mit BSF STATUS,6 das undokumentierte Program Page Preselect bit PA1 setze. Geht nicht! Gestern habe ich den Trimmbereich des interen RC-Oszillators (Original-OscCal war 0x22) getestet, geht von 800ns bis 1600ns Befehlszeit (entspricht 2,5 - 5 MHz). d.h. eine Anderung um 1/128 (7 Bits) bewirkt geschätzte 3-6 ns, muss ich noch genauer messen, ist nicht linear. Aber: der WDT hat einen eigenen RC-Oszillator, ob der mitgetrimmt wird? Thomas: die 4 Decoder arbeiten fleißig. Vielen Dank, dass Du die Erweiterung so schnell umgesetzt hat! Leider ist bisher kein neuer gültiger Datensatz aufgetaucht, habe gerade nachgeschaut. Kannst Du noch eine Spalte einbauen, wie viele gültige Datensätze enthalten sind? Wenn ein Satz aus der DB entnommen wurde, reicht es z.B. in die 4 Spaces DB reinzuschreiben, ohne extra Kommentarzeile. Walter, welchen Debugger hast du bestellt? Bei ibuy gibt es ein Pickit1 für 39,99 und ein Pickit3 für 59,95 (bei MC-direct kostet es 44 USD). Versuche bitte mal, mit OPTION den Prescaler des WDT zu ändern. Insider: >Ich könnte auf der Arbeit Bilder mit einem Elektronenmikroskop > machen, wenn mir jemand den Chip und etwaige vergleichsmodelle > zur Verfügung stellt. Kannst Du damit durch das Gehäuse schauen (Röntgenblick) oder muss das Gehäuse entfernt werden? Was interessant wäre, die CodeProtection-Fuse zu löschen. Wird aber nicht so einfach sein, weil wir 1. nicht wissen, so sie ist, und 2. sein kann, dass sie abgedeckt ist.
Um Gültige Datensätze hinzuzufügen msus ich die Webseite eingie minuten vieleicht eine stunde anhalten, damit ich das so ohne weiteres umsetzen kann, damit ich in der Datenbank keine inkonsistenzen habe. Machbar ist es aber. Ich weiß nicht ob ich das heute schaffe. Gruß Thomas
@eProfi, das mit PA1 hatte ich auch erst probiert - wie Du schon sagst, geht leider nicht. Ich habe mir das PICKIT2 bestellt - dauert aber wohl noch etwas. MDT prescaler: Abdul K. hatte so richtig geschrieben: "Ansonsten ist es aber ein echter Elektronik-Krimi. Ganz ohne Blut, nur Schweiß ;-)", Tote gibt es aber trozdem. RAM Monitor habe ich soweit fertig. Habe aber bei einem DCIC das erste Wort gelöscht (by accident) und beim anderen läuft anscheinend der WDT nicht mehr. Hab aber noch ne Wetterstation, die wird heute noch geschlachtet ;-) Bisher habe ich folgendes gesehen: - die Daten werden anscheinend im Bereich 0x36-0x3F abgelegt. - der Zähler für den WDT liegt anscheinend bei 0x0E oder 0x0F (Murphy, genau da habe ich die beiden Byte für den Bitcounter und das zu sende Wort platziert ;-) - der Kalibratorwert für den OnChip Oscillator wird eingetragen (war ich mir nicht sicher) Beim Thomy im Forum werde ich mal die Details bezüglich des PIC und 0x405+ einstellen, ist hier doch etwas "off topic". Das mit dem WDT prescaler ist eine gute Idee, werde ich ausprobieren, solbald ich wieder einen DCIC am Laufen habe. Ich fürchte allerdings, dass es nicht funktiert, weil: - Das OPTION Register wird laut Datenblatt (ja, ich bin vorsichtig geworden) nach einem Reset auf 0xFF gesetzt - GPIO,2 wird als Ausgang (Busy) verwendet. Dazu muß aber OPTION.5 auf '0' gesetzt werden. Daraus schließe ich, dass das OPTION Register nach einem Reset (auch nach einem WDT Reset) neu gesetzt wird und damit auch der WDT Prescaler. Ich verspreche mir mehr davon, den Zähler für die WDT resets so zu setzen, dass er nach dem nächsten WDT Reset wieder bereit ist. Walter.
Ui, was sehe ich, wenn ich den von Walter ausgelesenen 400er-Bereich scharf ansehe: 0400 00F 00F 00F 00F C32 FFF FFF FFF CDF 002 A0A FFF FFF FFF FFF FFF 0410 FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF 0420 FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF FFF 0430 1D7 01B E4A 00D FFF FFF FFF FFF FFF FFF 003 FFF CFE C32 C24 AF0 00f 00f 00f 00f sind die User-ID-Locations C32 ist eine Kopie des OscCal-Wertes. jetzt wird es interessant: 0408 0CDF movlw 0xDF (bin 1011 1111) 0409 0002 option 040A 0A0A goto 0x0A disable GPWU: Enable Wake-up on Pin Change bit (GP0, GP1, GP3) enable GPPU: Enable Weak Pull-ups bit (GP0, GP1, GP3) Walter, du müsstest 3e ins OPTION schreiben, um die WDT-Zeit zu halbieren. 0430 01D7 addwf 0x17,W (dez 35) 0431 001B sleep 0432 0E4A andlw 0x4A (bin 0100 1010) 0433 000D tris porta 0434 0003 sleep 043A 0003 sleep 043B 0FFF xorlw 0xFF 043C 0CFE movlw 0xFE (dez 254 / -2) 043D 0C32 movlw 0x32 (dez 50 043E 0C24 movlw 0x24 (dez 36) 043F 0AF0 goto 0xF0 Die Entwickler wissen, dass man in 400 Code ausführen kann.m
Ich bin noch nicht ganz funktionsfähig: 0408 0CDF movlw 0xDF (bin 1011 1111) --> 0408 0CDF movlw 0xDF (bin 1101 1111) disable GPWU: Enable Wake-up on Pin Change bit (GP0, GP1, GP3) disable GPPU: Enable Weak Pull-ups bit (GP0, GP1, GP3) T0CS: Timer0 Clock Source Select bit not Pin T0CKI, sondern 1MHz 040A 0A0A goto 0x0A das kann auch 020A sein, wenn PA0 gesetzt 0430 01D7 addwf 0x17,W (dez 35) --> 0430 01D7 addwf 0x17,W (dez 23) > Daraus schließe ich, dass das OPTION Register nach einem Reset > (auch nach einem WDT Reset) neu gesetzt wird und damit auch der > WDT Prescaler. Das stimmt leider. > - der Zähler für den WDT liegt anscheinend bei 0x0E oder 0x0F > (Murphy, genau da habe ich die beiden Byte für den Bitcounter > und das zu sende Wort platziert ;-) Habe ich nicht 1E und 1F vorgeschlagen? Nochwas, Walter, Hast Du die DV323 schonmal decodieren lassen? Kann die korrigieren? Es ist ja vermutlich (wg. Pinout) kein PIC, und ich vermute, dass der Nicht-PIC decodieren kann. Thomas: wenn es so großer Aufwand ist, lass es. Wäre ein NiceToHave gewesen.
> Walter, du müsstest 3e ins OPTION schreiben, um die WDT-Zeit > zu halbieren. Das muss nicht 3E, sondern 5E (ohne PullUp) oder 1E (mit PullUp) heißen. Ist eh momentan hinfällig. > Nicht-PIC decodieren kann. --> korrigieren kann. 0431 001B sleep sagt mein altes MPLAB, sleep ist normal 03 > Habe ich nicht 1E und 1F vorgeschlagen? Mist, habe ich gestern bereits getippt, dann ist mein PC abgeschmiert. Walter: Kannst Du bitte einen MemDump posten? Welche Reihenfolge haben die 80 Bits?
@eProfi, ich habe es nun umgesetzt, kann aber nicht garantieren ob die Werte von den bereits hochgeladenen Dateien korrekt sind. Neue Dateien, oder welche die noch nicht bearbeitet wurden dürften keine Probleme bereiten. die Kommentare, das ein Datensatz von einer datenbank stammt wurde rausgenommen, stattdessen ist nun " DB " zwischen Cipher und Plain.. Ich habe das ganze nun anders Umgesetzt als ich es eigentlich vor hatte. Daher gings schneller... gruß Thomas
Sehr schön, Respekt! Wenn der Platz knapp wird, kannst Du das Wort "Datensätze" (3. Spalte trennen, damit es zweizeilig wird. Was noch praktisch wäre, wenn man auch die Original-Dateien runterladen könnte, damit man sieht, was als nächstes auf der Todo-Liste steht. Der neue Treffer in Byte34-3000-3fff.txt ist der Original-Wert mit dem Plain 000000000000000000000010. Im Anhang mein 25-Zeiler, der die Datensätze generiert. >> Autor: Katzenschreck! (Gast) Datum: 27.05.2011 09:31 >>> Und wenn ihr es geschafft habt? Schmunzeln und Schweigen? Taucht >>> die Dekodierroutine irgendwo auf? Wird auch dieser Thread gesperrt? >> Das verbietet die Hacker-Ethik. >Was verbietet die Hacker-Ethik? Ich bitte darum, dass keine Details veröffentlicht werden, damit andere (Außendstehende) Schaden anrichten können. > Beim Thomy im Forum werde ich mal die Details bezüglich des PIC > und 0x405+ einstellen, ist hier doch etwas "off topic". Wo? URL?
eProfi schrieb: > damit andere > (Außendstehende) Schaden anrichten können. Welcher Schaden? Durch die Entschlüsselung von Wetterdaten werden keine Menschenleben oder wessen auch immer Sicherheit gefährdet. Allenfalls wird das Geschäftsmodell von Meteodata kaputt gemacht.
@eProfi: [ URL entfernt auf Wunsch des Forenbetreibers ] Auf das bin ich gerade gestoßen (s.Anhang). Bin ja mal gespannt, was da so kommt. Nachdem ich gerade den 3.DCIC gerillt habe (SW-Fehler...Schei*e !) brauche ich jetzt glaube ich ein bisschen Abstand. Werde mich jetzt mal wieder auf das PIC debug Interface konzentrieren... Walter.
eProfi schrieb: > Autor: Katzenschreck! (Gast) Datum: 27.05.2011 09:31 >> Und wenn ihr es geschafft habt? Schmunzeln und Schweigen? Taucht >> die Dekodierroutine irgendwo auf? Wird auch dieser Thread gesperrt? > Das verbietet die Hacker-Ethik. > Der Thread hier wird sicherlich auch bald stehen. Hatten wir ja schonmal. > > Abdul: >> Die leeren Datensätze sind also die, die mal gesendet wurden als >> offenbar keine Daten online von Meteo verfügbar waren. Richtig? > Es wurden schon Datensätze geliefert, denn es sind ja gültige Daten, > aber es wurde vergessen, Wetterdaten in den ENCODER zu füttern. Uih. Kann mich nicht erinnern es gelesen zu haben. Interessant. Danke.
@eProfi: eProfi schrieb: > Die Entwickler wissen, dass man in 400 Code ausführen kann.m nein, der Code ist bei diversen PIC12F509 der gleiche (steht schon drin, wenn man ihn kauft. Bislang habe ich keine Möglichkeit den Code 0x405+ ohne /MCLR = VPP auszuführen. (Näheres: s. Thomys Forum, Link weiter oben.) eProfi schrieb: > Nochwas, Walter, > Hast Du die DV323 schonmal decodieren lassen? Kann die korrigieren? > Es ist ja vermutlich (wg. Pinout) kein PIC, und ich vermute, dass der > Nicht-PIC decodieren kann. ja, hab ich schon getestet -> leider nein. Eine Mete-On3 ist aber auf dem Weg zu mir, die kann wohl korregieren. Soweit ich weiß ist da ein Chip drin, keine Bare DIE (Klecks). Bin mal gespannt, was das für einer ist. Wie oben schon erwähnt habe ich mittlerweile 3 DCICs gegrillt (nein, die schmecken nicht !) und sitzte zur Zeit von dieser Seite auf dem Trockenen (vielleicht kann mir jemand den Hex-Code mailen, dann kann ich sie neu flashen...haha). @Thomy: Danke für die Arbeit ! Walter.
@Walter, kein Problem es heißt übrigens korrIgieren ;) gruß Thomas
> nein, der Code ist bei diversen PIC12F509 der gleiche (steht schon > drin, wenn man ihn kauft. Also meine waren bis auf 3ff und 0404 ganz leer. Ich habe damit gemeint, dass sie es zu Debug-Zwecken (mit Vpp) verwenden. Lohnt es sich, sich im o.g. Forum anzumelden? Oder kommt man da ohne Regisitrierung rein? Wer ist da mit im Boot? > Eine Mete-On3 ist aber auf dem Weg zu mir, die kann wohl korregieren. Was ist mit der Sammelbestellung - bleibt Deine "Bestellung"? > Walter: > Kannst Du bitte einen MemDump posten? > Welche Reihenfolge haben die 80 Bits? Oder mir mailen? Abdul: > Uih. Kann mich nicht erinnern es gelesen zu haben. Interessant. Danke. siehe Autor: Thomas Berends (thomy-pc) Datum: 21.01.2011 23:13 Was ist eigentlich mit den Herren aus dem alten Thread (Diet, Dexter, Iranian, ...) wo stecken die? Wissen die überhaupt, dass wir hier weitermachen, nachdem der alte Thread geschlossen wurde.
Das Oben genannte Forum hatte ich eingerichtet, um den alten Thread fortzuführen. Wer jetzt ausser Walter und mir davon noch aktiv ist weiß ich so ausm Kopf nicht. Registrierung ist Pflicht, es ist ein geschlossenes Forum und es wird nicht jeder hinein gelassen. Gruß Thomas
@eProfi: Dump hängt an, sind aber ggf. Bitkipper drin, wie gesagt, ich hatte noch Probleme mit dem Timing. Aber man kann etwa sehen, wo die Bits liegen. Das letzte Bit habe ich (soweit ich mich erinnere) nicht eingeschoben, zu einem definierten Zeitpunkt anhalten zu können. Also evtl. alles um 1 Bit verschoben. Beachte bitte auch, dass Bit 0 und Bit 7 nicht ausgewertet werden (das könnte dann z.B. die 0x95 an Adresse 0x3B sein. Nur um sicherzugehen: wie hast Du den Bereich > 0x404 ausgelesen ? Ich habe eine Hand voll PICs bei Reichelt bestellt. Die haben alle dieses Muster, auch die 3 DCIC hatten das. Deswegen bin ich davon ausgegangen, dass das bei jedem drin ist. Lasse mich aber gerne eines Besseren belehren ;-) Ein paar Dumps von meinen Controller habe ich auch mit reingeschrieben. Hier sollten alle Bits stimmen. Walter.
habe ich gerade gesehen: Meteotronic La Crosse Wetterinfo Center by TFA bei Amaz*n für 8,46 Euro ;-) Hab mir mal nen Schwung geordert, hoffe, da ist auch nen PIC drin, dann hab ich wieder was zum Grillen... Gruß, Walter. PS: nicht dass der niedrige Preis ein Zeichen für das baldige auslaufen des Systems ist...
eProfi schrieb: >> Eine Mete-On3 ist aber auf dem Weg zu mir, die kann wohl korregieren. > Was ist mit der Sammelbestellung - bleibt Deine "Bestellung"? Ja, prinzipiell schon. Kommt auf den Preis drauf an. Beim Am*zon kostest das teil ca.59 Euro. Gruß, Walter.
Wenn das System ausläuft wirds langweilig^^, nur dann stehen viele leute ohne Wetterdaten da, und dann kann man die Teile auch wieder vergessen. Wenn du die Stationen hast, kannst mal eben Bescheid geben ob die Platine identisch zum TFA Meteotronic Start/Pro ist? Das Display ist ja schonmal identisch zum Start. PS.: Schickt mir bitte keine weiteren ICs, ich habe keine Platinen mehr wo ich die Dinger drauflöten könnte, bevor mir jemand weitere ICs schickt. Gruß Thomas
Wau, dass wir das nicht eher gesehen haben. Gibt es schon seit Januar. Witzig, dass Amazon die baugleiche WM5100 für 25,95 verkauft. Die Pro gibt es für 49,89 und für 57,50. > PS.: Schickt mir bitte keine weiteren ICs, ich habe keine Platinen > mehr wo ich die Dinger drauflöten könnte, bevor mir jemand weitere > ICs schickt. Walter kann jetzt welche brauchen ;-) Ich warte mit der Mete-On3-Bestellung, bis Walter sagen kann, was drin ist. > PS: nicht dass der niedrige Preis ein Zeichen für das baldige > auslaufen des Systems ist... Die Stationen sind generell billiger geworden. Die Bewertungen sind ja auch nicht gerade berauschend. Meteotime hat ja noch große Pläne, klingt nicht nach Auslaufen. > Nur um sicherzugehen: wie hast Du den Bereich > 0x404 ausgelesen ? Ich habe 10 St. vom Bürklin mit einem GQ-4X-Programmer ausgelesen, der kann mit dem Config-Menü und DDM? (direct memory access?) jede Adresse lesen und schreiben. Allerdings wird der Bereich 405 - 43f nicht gelöscht. Wie machst Du das?
@eProfi: zum Löschen des oberen Bereiches setze ich den PC auf 0x400 (erste ID) und start dann Bulk Erase. Laut Datenblatt unterscheidet der PIC zwischen: - PC zeigt auf Config Word (0x7FF) -> wird nur Config und Programm gelöscht - PC zeigt auf ID0 (0x400) -> wird alles gelöscht @Thomy: Ich sag Bescheid, sobald ich die Teile habe. Walter.
Walter Freywald schrieb: > Wie oben schon erwähnt habe ich mittlerweile 3 DCICs gegrillt (nein, die > schmecken nicht !) und sitzte zur Zeit von dieser Seite auf dem > Trockenen (vielleicht kann mir jemand den Hex-Code mailen, dann kann ich > sie neu flashen...haha). > Laß sie liegen. Nun hast du einen Grund für deine Arbeit ;-) Wichtig dabei ist, daß du dir alles genauestens dokumentierst. Hinterher kann man sich sonst nicht mehr erinnern und Zusammenhänge schreibt man meist nicht auf...
Angehängte Dateien:
-
DSCF0061-1.jpg
280 KB -
DSCF0064-1.jpg
240 KB
Hallo, >habe ich gerade gesehen: >Meteotronic La Crosse Wetterinfo Center by TFA bei Amaz*n für 8,46 Euro >;-) Es ist ein HKW581 verbaut, ziemlich kleines Gehäuse. Gruß Rene
das ist die gleiche Platine wie in Meteotronic start und meteotronic pro, Außer das unten noch Tasten sind...
Hallo, @Thomas Berends: hatte mich in deinem Board registriert, man hört aber so garnichts. Hat jemand die Anschlußbelegung vom HKW518? Dann kann ich den LA eingepackt lassen. Gruß Rene
und schwups kostet das Teil jetzt 9,56 Euro ;-) Hab nur schnell mal nen Test gemacht und den Chip ausgelesen. Sieht identisch zu meinen bisherigen aus...
Das Gehäuse müsste ein SSOP8 sein! Ich glaub ich kauf mir auch so ne Wetterstation (bzw zwei! Eine zum experimentieren, die Andere für meine Wand/Tisch)
Im reinraum das IC-Gehäuse oben mit Salpetersäure benetzen, auf 80-90°C anwärmen und dann das angelöste Gehäuse im Ultraschallbad oben ablösen. Wenn es Bonddrähte aus Gold und nicht z.B. aus Kupfer sind, bleiben die genauso intakt, wie der Die selbst. -> Fuses ausfindig machen und irgendwie überbrücken? Dann regulär auslesen? -> Flash/ROM-Interface kontaktieren und die Zugriffe plus Inhalt tracen? Keine Chance?
Wenn Bonddrähte aus Kupfer o.ä., vorher röntgen. Bonddrähte und Kontaktierungsstellen werden identifiziert. Danach mit neuen Bonddrähten wieder kontaktieren.
u7pid8ef schrieb: > Fuses ausfindig machen und irgendwie überbrücken Das ist kein LKW, da kann man nicht mit Muttis Haarnadel schnell mal ne Sicherung überbrücken!
Zumal die Fuses offensichtlich sogar mittlerweile in der allgemeine Matrix versteckt werden und mehrfach sind. Also nicht gaaaanz so einfach. Ich glaub, dieser Weg ist nicht der günstigste.
Ich bin nicht der Meinung, dass der µC-Hersteller die Fuses absichtlich versteckt. Meiner Meinung nach sieht der Hersteller keine Notwendigkeit, die Fuses absichtlich zu verstecken oder die gleiche Funktionalität auf mehrere Fuses zu verteilen (immer auch Sicht des Schutzes heraus gesehen). Lediglich das Finden der Fuses auf dem Die mag etwas schwer werden, vielleicht durch einen Vorher-/Nachher-Vergleich des selben Dies (der µC scheint ja schon identifiziert worden zu sein). Nebenbei kann man gleich noch verifizieren, ob es sich tatsächlich um den vermuteten µC handelt. Ich bin mir nicht sicher, ob es Mikro-Nadeln gibt, mit denen man auf dem Die entsprechende Stellen kontaktieren kann.
Ich würde es nicht schreiben wenn ich es nicht gelesen hätte. Warum wird das angezweifelt? Komische rhetorische Kommentiererei! Einzig kann ich nicht mehr sagen, ob es für den PIC bzw. welchen PIC überhaupt, beschrieben war. Es waren auch Die-Fotos dabei.
Eine Möglichkeit um die Fuses zu löschen ist hier beschieben: [[http://www.bunniestudios.com/blog/?page_id=40]] Dies könnte vielleicht auch beim PIC12F509 klappen... Weitere Infos zu FUSES und DIE-Fotos zu verschiedene Microchip PICs sind z.B. hier zu finden: [[http://www.flylogic.net/blog/?cat=1]]
Übrigens, die großen regelmäßigen Flächen auf den DIEs sind oft RAM oder ROM (FLASH). Wenn man es schafft diese Flächen z.B. mit einem kleinen Stück schwarzem Tape zu bedecken, und dann Versuche macht UV-Licht in verschiedenen Winkeln auf den DIE auftreffen zu lassen sind die Chancen die FUSES mittels Streulicht zu löschen und den FLASH-Inhalt intakt zu lassen vielleicht gar nicht mal so schlecht ...
Naja. Das brauch viel Erfahrung oder viele Module.
In diesem Dokument [[http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf]]sind auf Seite 20 die Position der Fuses eine 12C508 angegeben. Bei einem 12F509 sollten die wohl nicht wesentlich anders liegen... ;-)
Sorry, Link hat nicht ganz funktioniert. Jetzt sollte es gehen... [[http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf]]
Moin zusammen! eProfi schrieb: > Was ist eigentlich mit den Herren aus dem alten Thread (Diet, Dexter, > Iranian, ...) wo stecken die? Wissen die überhaupt, dass wir hier > weitermachen, nachdem der alte Thread geschlossen wurde. Seit gerade eben weiß ich es - danke für den Hinweis von eProfi ;-) Leider fürchte ich, daß ich derzeit nicht allzuviel beitragen kann. Mir fehlt einfach die Zeit, mich mit dem Schätzchen (METE-ON 3) zu beschäftigen - außerdem ziert es unser Wohnzimmer ... Aber sehr interessant, was Ihr inzwischen schon alles herausbekommen habt! Gruß, Didi
1. Didi war so nett, mir die Original-Fotos zu schicken, und was sehe ich auf dem Decoder im SO8-Gehäuse? 6580001 811800 R1A6G klingelt es bei Euch? ^^^^ 2. > und schwups kostet das Teil jetzt 9,56 Euro ;-) und schwups nochmal +0,10 = 9,66 - geht der Preis mit der Nachfrage ? Noch 15 Stück da. Walter, 1. wie viele hast Du genommen? 2. Ist die Mete-On 3 schon da? 3. Rene: > Hat jemand die Anschlußbelegung vom HKW518? > Dann kann ich den LA eingepackt lassen. Ja kannst Du, Protokoll etc. ist alles bekannt (und einfach). siehe Datum: 30.04.2011 15:50 und im alten Thread. Ich habe es noch einfacher gemacht: ohne Handshake, funktioniert zuverlässig. 4. Vorgestern gab es einen weiteren Treffer, es sind jetzt 3:
1 | 0011000000000100010101011000000101000111000001000000000100100001001000010110001000 22 000000000000000000000010 01 2011'0121:2008 |
2 | 0011000000000100010101011010011001011000000001000000000100100001001000010110001000 23 101110000001000100111010 10 2011'0121:2008 neu! |
3 | 0011000000000100010101011000110011110010100001000000000100100001001000010110001000 25 011110000111010100001110 12 2011'0121:2008 neu! |
4 | 12 3 4 5 6 780123456789abcdef 9 0 1 2 3 4 56 7 0123456 78 9abc d ef |
Die Zahlen dazwischen geben die Zahl der Einsen an. beim 2. und 3. sind 14 der 22 Bits (63,6%) identisch. 5. Thomas, bitte korrigiere den Kommentar im File 9000-9fff, es steht 8000-8fff drin. Vielleicht willst Du die eine nicht decodierte Zeile aus 4000-4fff einfach ins File einfügen. In den ganzen Logfiles gab es ab und zu Empfangsstörungen. Eine 2008'1231 habe ich mir herausgepickt und rekonstruiert. Kannst Du auch ins Original-File als rekonstruiert eintragen. Vielen Dank an Alle, die mittüfteln. Es macht riesig Spass.
h65a7ie3 schrieb: > Meiner Meinung nach sieht der Hersteller keine Notwendigkeit, > die Fuses absichtlich zu verstecken oder die gleiche Funktionalität > auf mehrere Fuses zu verteilen (immer auch Sicht des Schutzes heraus > gesehen). Die Fuses werden von den Chipherstellern mittlerweile als Hauptangriffspunkt angesehen und entsprechend geschützt.
@eProfi: hab mir Sicherheitshalber 10 Stück geordert ;-) Mete-on3 dauert wohl noch 2 Wochen. Bitte für mich noch mal langsam: Welche Bit probierst Du durch ? Ich hatte es mit den ersten 12 gemacht und bin zu keinem Ergebnis gekommen. Du arbeitest mehr im hinteren Teil. Auch hier geht es weiter: Der RAM Monitor läuft. Ich kann dem Teil jetzt beim "denken" zuschauen. Ist ja alles prima soweit. Nur scheint der wirklich die 270ms zu rechnen, also ca.270'000 Befehle. Momentan gehe ich so vor: PIC starten -> Daten reinschieben -> delay (einstellbar) -> RAM auslesen. Leider kann ich den PIC nach dem RAM Auslesen nicht weiterlaufen lassen, da ich ein paar Sachen verändern muß. Also starte ich jedes mal neu und verlängere das Delay zur Zeit immer um 2us. Wenn sich im RAM was geändert habe bekomme ich das dann entsprechend angezeigt. Ein paar Ergebnisse: Wie schon mal vor längerer Zeit gefunden: nach einem Reset wird an Adresse 0x33 ein Zähler auf 0x0F (15) gesetzt, der bei jedem Watchdogreset um eins verringert wird. Die Daten werden in die letzten 10 Byte im Speicher eingeschoben. Dabei werden (wie bereits vermutet) Bit 0 und Bit 7 verworfen. Der Cypher (Bit 0-42 \0,7) liegt von 0x3B bis 0x3F, die Zeit von 0x36 bis 0x3A. Dann werden alle Byte von 36-3F nach 16-1F umkopiert. Jetzt kommen anscheinend immer wieder 5Byte Schieberegister zum Einsatz. Dazu kann ich aber noch nichts festes sagen. Die 0x40 an Adresse 0x30 (oder 0x10) und die 0x04 an Adresse 0x31 (oder 0x11) (wie im Disassembly der ersten 64 Worte) habe ich bisher noch nicht gesehen. Ein weiterer Ansatz ist die Suche nach "RETLW xx". Das ist der übliche (und meines wissens einzige) Weg um Look-Up Tables im PIC12F509 zu realisieren. Dazu packe ich wieder etwas SW in den oberen Flash Bereich. Diese SW nimmt eine Adresse entgegen und führt einen "CALL" dahin aus. Befindet sich dort ein RETLW, so wird sehr schnell wieder in meine SW verzweigt. Meldet sich meine SW innerhalb einer gewissen Zeit nicht, gehe ich davon aus, dass dort kein RETLW steht und ich fahre mit der nächten Adresse fort. Vielleicht geben uns diese Informationen noch mehr Hinweise. Und noch ein Ansatz, um das Ausprobieren zu beschleunigen: PIC starten, anhalten und 0x33 auf 1 (oder 0, wird sich zeigen) setzen und auf den Watchdogreset warten. Dann sollten sich die Telegramme sehr schnell reinschieben lassen. Hab ich bisher aber noch nicht versucht. Walter.
Habs mal die Nacht durchlaufen lassen. Anfangs funktioniert der Monitor noch ganz gut. Wenn das Delay länger wird (100ms) wird der Jitter anscheinend zu groß, sprich nach nächste RAM Abbild liegt teilweise "vor" dem vorherigen Abbild. Ich werde einen Weg finden müssen, PIC Zyklen zu zählen oder einen Single-Step zu machen etc. Aber wenigstens Snapshots sind möglich ;-) So wie es aussieht ändern sich bisher (ca.100ms) nur folgende Bytes: 0x07-0x0E 0x10-0x1E 0x10: schein oft als Zähler verwendet zu werden 0x12-0x14 wird (soweit ich das bisher gesehen habe) das Ergebnis berechnet (3x8 = 24 Bit) 0x16-0x1F: stehen die 80 Bit 0x0F, 0x1F und 0x30-0x3F bleiben bisher gleich. (0x20-0x2F sind nicht physikalisch vorhanden, 0x00-0x0F wird da reingespiegelt). Walter.
Walter Freywald schrieb: > Ich werde einen Weg finden müssen, PIC Zyklen zu zählen oder einen > Single-Step zu machen etc. Oder Du findest eine Möglichkeit, den Takt langsamer zu machen? Viele Grüße, Simon
uzi schrieb: > Sorry, > Link hat nicht ganz funktioniert. > Jetzt sollte es gehen... > > [[http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.pdf]] Genau das Dokument meinte ich. Fuse-Architektur bspw. mit dem restlichen FLASH verschmolzen. Wenn der hier betreffende Chip wirklich genau dem Foto entspricht, wäre es natürlich sehr schön (einfach). Manchmal werden Chips aber neu designet und unter der gleichen Bezeichnung weiterverkauft.
Walter ist ja voll der Held! Gratulation. Da wirste bald externe Aufträge bekommen ;-) Zur Sicherheit dieser PICs muß man wohl nichts mehr sagen.
DU BIST GENIAL! o_O Zu deinem Timingproblem: Ich habe mit einem Atmega mal Versuche gemacht wo ich ihn heruntergekühlt und beheizt habe und die Frequenz des internen RC-Oszillators änderte sich dabei deutlich. Wird prinzipbedingt beim PIC nicht anders sein (oder?). Evtl. kannst du die Temperatur stabilisieren (Nachts sinkt sie weil Heizungsabschaltung/Abkühlung, Tags steigt sie, weil sonne) und somit die Differenz noch minimieren. Zum Clock-Cycles zählen noch eine Idee: Lässt sich da evtl. was über die Versorgungsspannung machen? Stromverbrauch über 10Ohm Widerstand abgreifen, zwischendrin noch nen Komparator und dann an den Zählereingang legen und beim gewünschten Zählerstand reseten. Wenns dir zu viel wird bei der Analyse der Daten die du bekommst, dann wäre ich bereit dich zu unterstützen.
eProfi schrieb: > Insider: >>Ich könnte auf der Arbeit Bilder mit einem Elektronenmikroskop >> machen, wenn mir jemand den Chip und etwaige vergleichsmodelle >> zur Verfügung stellt. > Kannst Du damit durch das Gehäuse schauen (Röntgenblick) oder muss das > Gehäuse entfernt werden? Was interessant wäre, die CodeProtection-Fuse > zu löschen. Wird aber nicht so einfach sein, weil wir 1. nicht wissen, > so sie ist, und 2. sein kann, dass sie abgedeckt ist. Offen muss er schon sein, ist aber unproblematisch.
Es gibt übrigens einen zweiten Elektronenstrahl, zumindet EPROMs kann man damit bitweise löschen.
@aaaaa: Eventuell kann man diesen PIC auf externen Clock umstellen. Vermute, es geht nicht. Ein Komparator zur Strommessung: Vergeß es schnell. Mach eine FFT auf deinem Scope des Stromes und du siehst, wieviel Rauschen da vorhanden ist. Allenfalls aus Sleep startend, geht das. @all: Aber es wurden ja schon Ansätze gebracht: 1. Clock-Trim Register ändern. 2. WDT Post-Teiler Speicheradresse preloaden auf nahe dem Endwert. Sodaß neue Daten gleich nach der letzten internen Berechnung neu geladen werden können. 3. Externe Temperaturänderung (Heizung/Peltier). Eine Idee wäre noch einen Timer fest an den Clock zu koppeln und diesen auszugeben als Timingreferenz bzw. Interrupt-Quelle. Pins sind wohl nur schlecht verfügbar (Kann man irgendwas von der normalen Funktion umbiegen, z.b. die gerade beim Debuggen nicht benötigten I/O-Pins die das Ergebnis an den anderen Chip weitergeben?. Wird ja momentan nicht gebraucht.), aber interner Interrupt ist sicherlich machbar. Ich kann leider nicht mitmachen, aber vielleicht bringt euch eine meiner Ideen weiter. Viel Spaß!
Glückwunsch, Walter! Nicht nur RETLW lassen sich so finden, auch normale RETURNs sollten zu erkennen sein. Wenn man alle RETURNs im Programm gefunden hat, kann man rückwärts anfangen zu analysieren. Man springt genau einen Befehl vor dem RETURN an und sollte nach 3 Zyklen wieder zurück sein. Dann kuckt man, was sich verändert hat und errät so den Befehl vor dem RETURN. Und das Ganze iteriert sollte das Geheimnis lüften. Ist hochinteressant und in der Umsetzung nicht trivial. Hätte total Lust selbst mitzumachen. Welche Wetterstation muss ich denn nun kaufen, wo ein PIC drin ist, den man gut kontaktieren kann? PIC-Entwicklungswerkzeuge sind vorhanden. Gruß HerrSchrader
Hallo HerrSchrader, Dieser PIC hat nur 2 Stack-Ebenen. Ich denke mal, da wird es nicht all zu viele Unter-Routinen geben :-( Ausserdem lassen sich bei diesem PIC nur Routinen aufrufen (über call oder PCL-Modifizierung) bei deren Startadresse Bit 8 gelöscht ist (Bit 0-7 kommen vom Befehl, Bit 8 wird 0 gesetzt, Bit 9 kommt von STATUS,PA0,..und Bit 10, wenn man > 0x3FF arbeitet, von STATUS,6) Aber unter diesem Aspekt hatte ich das noch garnicht gesehen. Meine Hoffnung war vielmehr, LookUp-Tabeles zu finden. Der PIC ist z.B. in der Meteotronic LaCrosse bei Amazon für ca. 10 Euro zu haben. Die Teile habe ich mir "auf Halde" gelegt, ich habe nämlich leider noch keinen Weg gefunden, den Bereich 0x400-0x4FF getrennt zu löschen (ja, laut Datenblatt geht das nicht, aber lauf Datenblatt geht ja so einiges nicht ;-) Interessant wäre, beim Debuggen eines PIC mal mitzuschneiden, was da für Befehle zum Einsatz kommen, z.B. SingleStep ;-) Walter.
Hallo Walter unter folgendem Link gibt es den Source-Code zum PICkit2, vielleicht findest du dort etwas passendes bezüglich SingleStep etc. [http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1960&fragment3_NextRow=1] Ich habe mir mal den Code angesehn, vielleicht ist die Funktion "CoreInstruction" interessant. Ich habe aber keine Ahnung, ob das mit dem 12F509 geht. Ebenso scheint es einen Programmiermode ohne BulkErase zu geben. Stichwort Begin Programming (Externally Timed).
Was ist denn bisher an Sachen möglich die du ausführen kannst? Also wenn ichs jetzt richtig verstanden habe machst du folgendes: Du hast einen Bereich des PICs so überschrieben, dass er das macht was du willst. Du lässt den Code ein paar µs laufen und unterbrichst dann und liest den RAM aus? Inwiefern "arbeitet" der Chip noch korrekt? Kommen da auch dekodierte Daten raus? Kannst du sonst noch auf was zugreifen wie den Stackpointer, Programcounter, Register, Flags? Was bestimmt interessant wäre, das wäre der Zustand des RAMs in dem Augenblick, kurz bevor die Daten ausgegeben werden. Dann könnte man sehen ob die Daten weiterhin im Datenbereich des Schieberegisters stehen oder anderweitig erzeugt werden, da noch ein anderer Algorithmus nachgeschalten ist. Kannst du selbst an Stellen springen? Also einen CALL auf eine Adresse machen die du willst? Wird nach dem Reset sofort deine Funktion aufgerufen? Falls ja könntest du ja mal sowas machen wie: PIC starten, an Adresse springen, 1 Befehl ausführen lassen, RAM inhalt auslesen. Damit könnte man evtl. schon einige Stellen/Befehle erraten. Nur so meine Ideen ;-)
> Dieser PIC hat nur 2 Stack-Ebenen. Ich denke mal, da wird es nicht all > zu viele Unter-Routinen geben :-( Stimmt. Vielleicht nur RETFIE. Schade. > Ausserdem lassen sich bei diesem PIC > nur Routinen aufrufen (über call oder PCL-Modifizierung) bei deren > Startadresse Bit 8 gelöscht ist (Bit 0-7 kommen vom Befehl, Bit 8 wird 0 > gesetzt, Bit 9 kommt von STATUS,PA0,..und Bit 10, wenn man > 0x3FF > arbeitet, von STATUS,6) Aber GOTO an eine beliebige Adresse sollte doch gehen? Man muss dann eben den PIC nach 1 us wieder anhalten und nach Veränderungen suchen. Wenn man vorher das RAM mit aussagekräftigen Mustern beschreibt, lassen sich auf jeden Fall Register-Veränderungen gut erkennen. Schwierig sind sicherlich Veränderungen am PC und Stack, weil die sich nicht auslesen lassen. > Der PIC ist z.B. in der Meteotronic LaCrosse bei Amazon für ca. 10 Euro > zu haben. Danke für die Info. > ich habe nämlich leider noch keinen Weg gefunden, den Bereich 0x400-0x4FF > getrennt zu löschen Das heißt, du kannst den Bereich nur ein einziges Mal beschreiben (und später nur noch Bits von 1 auf 0 kippen)? Das bedeutet, der RAM-Monitor muss auf Anhieb fehlerfrei sein? > Interessant wäre, beim Debuggen eines PIC mal mitzuschneiden, was da für > Befehle zum Einsatz kommen, z.B. SingleStep ;-) Ist der 12F509 überhaupt debug-fähig? SingleStep funktioniert m.W. so, dass in einem speziellen Debug-Register ein Bit gesetzt wird. Nach einem RETURN im Debug-Modus führt der PIC genau einen normalen Befehl aus und geht dann wieder in den Debug-Modus.
Weiss jemand, ob man mit dem MPLAB ICD2 oder ähnlichen Debuggern den PIC12F509 überhaupt im SigleStep betreiben kann ?
Sorry, hatte den Thread noch offen aber nicht aktualisiert. Hatte nicht gesehen dass jemand die Frage nach der SingleStep-Möglichkeit beim 12F509 schon gestellt hatte.
Hallo Walter, Gute Nachrichten: Der PIC12F509 ist debugfähig! (Sigle Step, Breakpoint,..) Ich habe das in der Help zum MPLAB ICD3 gefunden. Siehe angehängte Datei
Hier noch ein paar Infos zum Debuggen von Pics: Beim MPLAB ICD2 wird ein kleines "Zusatzprogramm" zusätzlich zur eigentlichen Applikations in den PIC geladen und dann der Debug-Mode aktiviert und das Zusatzprogramm angesprungen. (Entnommen aus der Hilfe zum MPLAB ICD2) Das "Zusatzprogramm" und ein paar weitere Files befinden sich in der angehängten Zip-Datei. Soweit ich das verstanden habe funktioniert das aber nicht mit Code-Protection :-(( Wird uns also vermutlich nicht viel weiter bringen. Es sei den der Debug-Mode lässt sich trotzdem irgendwie sinvoll nutzen...
Hier noch zwei Ideen: 1. Wars nicht so, daß ein RESET nicht das RAM löscht? Also könnte man ihn an einem beliebigen Zeitpunkt unterbrechen und nach dem RESET das RAM lesen mittels Walters Monitor auf 0x400 . 2. Es gibt aus Fernost noch diverse PIC-Clones, die wohl mehr oder weniger kompatibel sind. Es könnte also sein, das die Uhr so einen besitzt und dieser vielleicht im Bereich Code-Schutz anders/schlechter geschützt ist. @eProfi: Kannst du das auflösen? Was soll da klingeln? Eine Typennummer?: 1. Didi war so nett, mir die Original-Fotos zu schicken, und was sehe ich auf dem Decoder im SO8-Gehäuse? 6580001 811800 R1A6G klingelt es bei Euch? ^^^^
@Abdul, ich glaub da handelt es sich um den EM6580 bin mir aber nicht sicher...
Das Ding scheint keine Codeprotection zu haben, zumindest gibt das Datenblatt nichts dazu her. Wenn es Codeprotection hätte, dann würden die es schon groß draufschreiben ;-) Zum Programmieren muss man an einen Pin 15 Volt anlegen soweit ichs jetzt gelesen habe. Mehr Details gibts leider nicht. Hab mal gesucht welche Programmer man da verwenden kann. Hab eine Seite gefunden wo es offenbar auch ein Softwareupdate zu den Programmern gibt: http://www.elnec.com/download/ Da offenbar immer wieder neue Chips dazukommen, müssen die Ansteuerdaten im Programm integriert sein. Mal schaun ob man da was rausziehen kann. So kompliziert kann das ja nicht sein das Programmieren... Nur ein paar Ideen, vorrausgesetzt es ist wirklich ein EM6580...
Schreibt bitte in Zukunft zum Posting auf welchen Controller es sich bezieht. Die Sache ist eh schon sehr unübersichtlich geworden und der Thread zu lang. Wollen wir einen neuen aufmachen? Zeit zum Speichern des Threads...
Ich denke das wäre das Beste wenn man da einen neuen Thread erstellt, und den LInk dahin am besten hier postet, damit nicht all wieder neue Fragen aufkommen, wo ist das denn und so weiter. Nundenn, ich mach dann mal Feierabend, Gute Nacht!
ich hab die Idee mit dem Auslagern mal Aufgegriffen und hier einen neunen Thread angefangen für alles was den PIC12F509 angeht: Beitrag "PIC12F509 hidden features und "High Flash"" Ich habe da nochmal zu Beginn alles zusammengefasst, was bisher so bekannt ist. Sonst wird es hier wirklich zu unübersichtlich. Wir könnten auch mal damit anfangen, die RAM-Dumps zu analysieren. Auch dafür habe ich mal einen neuen Thread angefangen: Beitrag "Meteotime Crypt" In der Mete-On3 ist ein "großer" 8 Pinner drin (Bezeichnung wurde oben schon erwähnt). Nach der Lage von VCC und GND scheint es wirklich der EM6580 zu sein. Ich hatte EM Microelektronik schon mal auf die Codeprotection angesprochen. Die meinten, es gäbe keine. Der Controller hat keine direkte möglichkeit, das Flash auszulesen. Dazu wird eine SW in das RAM geladen und ausgeführt. Diese kann dann das Flash auslesen. Wie es in der Maskenversion (ROM, also kein Flash) aussieht, weiß ich nicht. Den Elnec-Programmer hatte ich mir auch schon mal angeschaut. Kostet aber so im die 1000 Euro. Ist mir dann doch zu teuer. Aber es dürfte keine Problem sein, die Progrmmierung mitzuschneiden und zu analysieren. Walter.
"Der Controller hat keine direkte möglichkeit, das Flash auszulesen. Dazu wird eine SW in das RAM geladen und ausgeführt." Ist das eine Auskunft der Sekretärin? Wie sollte eine Software OHNE CPU das Flash auslesen? Gibts da einen Spezialbefehl, der nur im RAM ausführbar ist. Bei Harvard geht das aber nicht. Das kann so nicht stehenbleiben!
Abdul K. schrieb: > "Der Controller > hat keine direkte möglichkeit, das Flash auszulesen. Dazu wird eine SW > in das RAM geladen und ausgeführt." > > Ist das eine Auskunft der Sekretärin? Wie sollte eine Software OHNE CPU > das Flash auslesen? Gibts da einen Spezialbefehl, der nur im RAM > ausführbar ist. Bei Harvard geht das aber nicht. > Das kann so nicht stehenbleiben! Es geht um den EM6580 ? Ich bezweifle ebenfalls dass es so einfach ist an den Flash/ROM Inhalt zu kommen. Die Assemblerbefehle des EM65xx scheinen auf den ersten Blick keinen Zugriff auf Flash/ROM zu ermöglichen. Ausserdem schaut es laut der AppNote "Programming an EM6540" so aus als ob kein Zurücklesen des programmierten Codes möglich ist sondern lediglich die Checksumme des Codes abgefragt werden kann. Ob es undokumentierte Möglichkeiten gibt um an den Flash/ROM Inhalt zu kommen ist natürlich ein anderes Thema.
Eventuell schreiben die einen Key ins RAM, den die CPU beim Reset abprüft. Nach dem Test des Chips, wird der Key wieder gelöscht und niemand kann ihn finden und mißbrauchen. Dazu zweigt die CPU beim Reset erstmal in ein internes Schatten-ROM. Sowas in der Art ist z.B. beim Cypress PSoC1 wohl vorhanden. Wenns so wäre, wäre obige Aussage der 'Sekretärin' die halbe Wahrheit.
Hab mir mal das ELNEC-Programm installiert. Dann auf DEMO gegangen und den Chip ausgewählt. Bei den Details steht: "General Info: This device can not be blank checked. It is not allowed to read Sector1. Read operation (F7): read CRC of Sector1, data on the last address of Sector1 and read Sector2. Verify operation (F8): check CRC of Sector1 and verify Sector2. Program operation (F9): program of device. ..."
Das gibt bei diversen anderen Controller auch. Der Controller hat einen Bootloader oder ähnliches. Dieser hat Befehle um das Flash zu schreiben, eine Checksumme zu bilden etc. aber keinen Befehl um das Flash zu lesen. Mit den Befehlen des Bootloaders ist es direkt nicht möglich, Code aus dem Flash zu lesen. Also muss man SW schreiben, sie ins RAM (oder auch ins Flash laden) und ausführen. Die SW liest dann das Flash aus und gibt die Daten nach aussen weiter. Ich kenne dieses Vorgehen bei ST Controllern. Wenn man den Code nicht direkt ausführen kann, kann man evtl. den Stackbereich beschreiben und dadurch den Code ausführen. Muss man bei einigen Controllern so machen. Der Controller (also die Assemblerbefehle) muß grundsätzlich (also anders als beim PIC12F509) auf den Programm Speicher zugreifen können.
Nicht ganz. Man könnte sich per Stack einen geeigneten Befehl im Hauptprogramm indizieren und diesen dann beim RET ausführen lassen. Allerdings kommt nach diesem Befehl ja ein weiterer und was wird der dann machen?? Also schwierig und ineffizient. Den Stack gezielt überlaufen zu lassen, fällt mir noch ein. Was macht die CPU, wenn sie am Ende des Flash angelangt ist. Geht sie auf Adresse 0 ? Ist das der Reset-Startpunkt?
Walter Freywald schrieb: > Der Controller (also die Assemblerbefehle) muß grundsätzlich (also > anders als beim PIC12F509) auf den Programm Speicher zugreifen können. Warum muss er das ? Bei den Befehlen des EM66xx ist kein Befehl dabei der Daten aus dem Programm-Speicher lesen kann (oder ich habe etwas übersehen). Und wenn man sich anschaut wie beispielsweise die Seriennummer in Sektor 2 des Flash realisiert ist (Befehlscode, der die Seriennummer in den RAM überträgt) dann spricht das ebenfalls dafür dass es keine Befehle gibt die auf den Programm-Speicher zugreifen können (zumindest keine dokumentierten).
Würde die folgende Methode nicht funktionieren? - Gewünschtes Ziel auf den Stack pushen - RET - Einen Befehl warten - RESET - RAM ansehen und schauen was der Befehl gemacht hat Man könnte zumindest schonmal ein paar Sachen rausfinden. ein shift müsste man erkennen, ein schreiben ins RAM auch, die RAM-Adresse würde man rausfinden. Was man nicht finden würde sind Sprünge, RET(?) und CALL(?) Oder hab ich da drinnen noch nen denkfehler?
Abdul K. schrieb: > Den Stack gezielt überlaufen zu lassen, fällt mir noch ein. Was macht > die CPU, wenn sie am Ende des Flash angelangt ist. Geht sie auf Adresse > 0 ? Ist das der Reset-Startpunkt? Laut Doku ist der EM66xx ein wirklich sehr einfacher 4-Bit Mikrocontroller. Der Stack hat maximal 3 Ebenen, die nicht im RAM liegen. Verändert wird der Stackpointer durch Befehle wie CALL und RET, direkte Manipulation des Stackpointer oder Stack gibt es nicht (zumindest nicht dokumentiert).
Ich denke, diese Ideen gelten für beide Controller. Sind beides Harvard-Maschinen. eProfi hat den Trick mit dem Stack hier schon erklärt: Beitrag "Re: PIC12F509 hidden features und "High Flash""
Abdul K. schrieb: > Ich denke, diese Ideen gelten für beide Controller. Sind beides > Harvard-Maschinen. Ein grundsätzliches Problem beim EM66xx mit ROM Maske, also ohne Flash: wie soll man dort eigenen Code hineinbekommen und ausführen ? Ist bekannt welche Variante verbaut wurde ? Vermutlich aus Kostengründen die ROM Variante...
Hm. Eventuell erscheint das RAM über dem ROM gespiegelt? Bin jetzt aber zu faul im DB zu forschen.
eProfi schrieb: 1. Didi war so nett, mir die Original-Fotos zu schicken, und was sehe ich auf dem Decoder im SO8-Gehäuse? 6580001 811800 R1A6G klingelt es bei Euch? ^^^^ Das Datenblatt schreibt: 21.1 Package Marking 8-pin SOIC marking: First line: 6 5 8 0 0 1 Second line: P P P P P P Third line: R 1 A Y Where: PP…P = Production identification (date & lot number) of EM Microelectronic-Marin SA Y = year of assembly Walter schreibt: => Baujahr 2006, Flash Version ;-)
Hallo leute, Kurze Info: Gerade kommt bei uns ein ganz dickes Gewitter an, ich werden gleich die Telefonleitung kappen, Also bitte keine Panik schieben wenn dcf77logs.de nicht erreichbar ist. Gruß Thomas
Angehängte Dateien:
-
6580.jpg
64 KB
Moin! Walter Freywald schrieb: > Das Datenblatt schreibt: Exakt das wollte ich auch gerade schreiben ;-) Vielleicht noch als Ergänzung der Link zum Datenblatt: http://www.dataman.com/Datasheets/Emmarin/EM6580.pdf Und einen Ausschnitt des Fotos vom IC hab ich auch noch rangehängt. Jetzt bin ich nur mal gespannt, ob man den Flash-Inhalt aus dem Teil tatsächlich irgendwie rausbekommt. Auch ich hab keinerlei Infos dazu gefunden - nur zum Programmieren des Flashs. Gruß, Didi
Ich bin noch auf der suche nach dem "Instruction set" des EM6580 (EM66xx Kern ?). Ich dachte, das hätte ich schon mal gehabt - hab mich da aber wohl geirrt. Habe auch in den AppNotes keinen Befehl gefunden der einen Zugriff auf das Flash zuälsst - will aber nix heissen. In der Entwicklungsentgebung ist ein Disassembler integriert - also das Hex- (oder Bin-) File ließe sich analysieren. Walter.
eProfi: Third line: > First line: 6 5 8 0 0 0 1 R 1 A 6 G Walter: > First line: 6 5 8 0 0 1 R 1 A Y > Walter schreibt: > => Baujahr 2006, Flash Version Woher leitest Du die Flash-Version ab? Habe mir gerade 8 St. von Amazon geordert, der Preis ist auf 9,44 gefallen, ist ja wie an der Börse. Autor: h65a7ie3 (Gast) Datum: 01.06.2011 14:24 > Ich bin nicht der Meinung, dass der µC-Hersteller die > Fuses absichtlich versteckt. > Meiner Meinung nach sieht der Hersteller keine Notwendigkeit, > die Fuses absichtlich zu verstecken oder die gleiche > Funktionalität auf mehrere Fuses zu verteilen (immer auch > Sicht des Schutzes heraus gesehen). Tut mir leid, da täuschst Du Dich gewaltig. > Ich bin mir nicht sicher, ob es Mikro-Nadeln gibt, mit denen > man auf dem Die entsprechende Stellen kontaktieren kann. Gibt es, nennt sich micro probing. Such mal nach dem Russen-Pdf "breaking code protection on microcontrollers". Da ist haargenau beschrieben, wie es geht.
@eProfi: Du hast Recht. Sorry, da hab ich mich geirrt (vor lauter Freude die 3. Null übersehen ;-) Lauf Datenbaltt habe ich aber verstanden, dass die EM6580 die Flash-, die EM6680 die ROM-Version ist. Walter.
Moin zusammen! Zum EM6580 habe ich noch folgendes gefunden: On the ELNEC programmers, you are able to select 2 programming modes. • First one is called "sector 1" : read-back the flash sector 2 (trimming information) + erase both sectors + write the sector 1 + re-write the previous trimming information in the sector 2. • Second mode is called "sector1 + sector 2" : both sectors are erased and replaced by the content of the programmer buffer (Caution : with this mode the trim values are lost). (Auszug aus AppNote 26: http://www.emmicroelectronic.com/webfiles/Product/MCU/an/AN26.pdf ) Könnte also ein Problem geben, den "sector 1" mit dem gesuchten Programmcode auszulesen. Zumindest ist diese Möglichkeit nirgends dokumentiert. Gruß, Didi
Hallo Ich habe mal eine allgemeine Frage zu den Wetterempfaengern. Ich habe mir drei von diesen Amazon Dingern fuer 9.- besorgt, die ich auch schon eine Weile habe. Meteotronic WM 5000 Wenn ich die Geraete starte dauert es etwa drei Minuten bis die Zeitanzeige & Datum kommen. Dann, und das ist mir in mehreren Versuchen aufgefallen, dauert es MINDESTENS einen Tag, oft 36h bis alle Wetterdaten da sind. Empfang ist bei mir sehr gut, daran liegt es nicht. Besonders aufgefallen ist mir dabei das die Daten immer in der selben Reihenfolge kommen, was auch immer mehrere Stunden dauert. Heute: Hoechste Temperatur Tag 2: Hoechste Temperatur Tag 3: Hoechste Temperatur Tag 4: Hoechste Temperatur Heute: Niedrigste Temperatur Tag 2: Niedrigste Temperatur Tag 3: Niedrigste Temperatur Tag 4: Niedrigste Temperatur Weiter ist mir aufgefallen, dass wenn ich drei Uhren in einem Abstand von 3h Starte (passte mir zeitlich gerade so in den Kram) sie sich exakt gleichzeitig aktualisieren. Also: Uhr 1 hat schon die Hoechstwerte von HEUTE und TAG 2. Dann kommt ja der Hoechstwert fuer Tag 3 und im SELBEN Moment auf der zweiten UND dritten Uhr auch ein Wert dazu. Druecke ich auf Location und gehe die mal durch, sind alle Werte die fuer meine Region gelten, also meinetwegen HEUTE und TAG 1 auch fuer alle anderen 59 Regionen da. Sie werden also abgespeichert. Wann die Wetterdaten auf den naechsten Tag umspringen habe ich noch nicht getestet, da ich selten bis 24h aufbleiben kann. Heute werde ich einmal darauf achten was genau passiert. Meine eigentliche Frage ist also: Warum dauert es so immens lange bis die Daten komplett da sind, wenn doch die Wetterdaten jede Minute mit uebermittelt werden ? Und warum kommen die Daten in so einer komischen Reihenfolge ? Nein, das muss jetzt nicht beantwortet werden, aber Kleinigkeiten helfen oft und vielleicht ist das ja noch nicht wirklich aufgefallen. Das sind so meine ersten Erfahrungen mit diesem Geraet und ich hoffe das es vielleicht irgendwo weiter helfen kann. Morgen werde ich dann mal ran setzen und beide Threads gruendlich lesen und mal den Loetkolben anwerfen. Nebenher. Waere es nicht klueger diesen Thread mal zu beenden und einen neuen anzufangen, es wird doch sehr unuebersichtich hier.
Hallo Peter, es gibt bereits zwei neue Threads: http://www.mikrocontroller.net/topic/goto_post/2211071 http://www.mikrocontroller.net/topic/goto_post/2211105 Im ersteren geht es speziell um den verwendeten PIC und dessen undokumentierten "High Flash" in dem auch der RAM-Monitor läuft Der zweite Thread geht um "Meteocrypt", also der Verschlüsselung der Daten. Deine Versuchsergebnisse sind übrigens soweit richtig, aber schon lange bekannt. Es werden jeden Tag zur selben UTC-Zeit die Daten für ein Gebiet übertragen. Daher dauert der Sync so lange bis die Daten eben übertragen werden die zu DEINER Region gehören. Deine Uhren müssten sich also immer zur selben Zeit auf das neue Wetter einstellen.
Danke fuer die Antwort, kam genau zum richtigen Zeitpunkt. Denn eben habe ich mal darauf geachtet, wann genau die Wetterdaten umschalten. Das passiert GENAU um 12:01:30 bei allen drei Uhren. Und das fuer alle 60 Regionen, jedenfalls so schnell ich blaettern konnte. Das es bereits bekannt war wusste ich nicht, denn wie gesagt, die Threads sind extrem lang und viele davon sind fuer den "Normalanwender" unbrauchbar, da es viel zu sehr in's Detail geht. Ich versuche da mitzuhalten, was mir aber ehrlich gesagt ziemlich schwer faellt da man sich vieles erst ergoogeln muss und weil die "Freaks" einfach voraussetzen das man versteht was die meinen. Ich fuer meinen Teil blicke nicht durch wie es wirklich funktioniert trotz Wiki und Verfolgung dieser Threads. Nun gut, ich habe auch nicht alles wirklich gelesen und erst recht nicht verstanden. Wenn ich aber morgen mal eine Uhr zerlege und dann alles ausprobieren und lesen kann, hoffe ich, zumindest einen Teil verstanden zu haben. Es interessiert mich ja schon sehr wie man sowas angeht. Die Wetterdaten selbst interssieren mich dabei eigentlich kaum. Ich wohne in Koeln (Im Rheingebiet ist das Wetter eh anders) und die naechte Region ist Duisburg. Macht also von den Wetterdaten her ueberhaupt keinen Sinn. Internetdienste sind da wesentlich genauer. Danke fuer die Links. Die werde ich mir morgen alle mal zu Gemuete fuehren.
Hallo, Ich habe soeben noch einen Vorschlag umgesetzt, was die Massendekodierung angeht. Jetzt können dateien Priorisiert werden. So können Dateien mit hoher Priorität schnell zwischendrin eingeschoben werden, während zum Beispiel sehr größe Dateien die Viel Zeit beanspruchen pausiert werden. vor allem jetzt an eProfi: Du kannst nun mehr als 4096 Datensätze pro datei reinschieben, wenn jemand anderes was dekodiert haben möchte kann dieser das auf hohe Priorität stellen. Große Datensatzdateien möglichst niedrige, sehr kleine hohe Priorität, und wenn das egal ist, einfach auf Standard stellen. Die Dateien werden Vorrangig nach Priorität, dann nach Hochladezeit zuerst bearbeitet, frühere Dateien zuerst. und dann zum Abschluss noch den link http://www.dcf77logs.de/DecoderAccess.aspx
Mal ausgerechnet, wie lange es dauert bis alle bisherigen Datensätze durchgewurschtelt sind?
Bisher wurden rund 124.000 Datensätze dekodier, Ich habe Pro Datensatz 38s angenommen, das passt sehr gut, (ich mache die Fertigstellungsprognosen damit) Demnach würde das mit einem Decoder gerundet 54 Tage, 12 Stunden dauern. Gruß Thomas
Du meinst in 14 Tagen hast du alle deine bisher aufgezeichneten Datensätze durch? 4 Dekoder.
Wäre es nicht sinnvoll bereits dekodierte Daten vor dem Decoder zu schützen, falls zwei Leute das gleiche dekodieren möchten? Also quasi eine "hab ich schon"-Routine einfügen?
Alex W. schrieb: > Wäre es nicht sinnvoll bereits dekodierte Daten vor dem Decoder zu > schützen, falls zwei Leute das gleiche dekodieren möchten? > > Also quasi eine "hab ich schon"-Routine einfügen? So wie ich die Website verstehe, gibt es so etwas bereits.
Gibt es. Alles was bereits Dekodiert wurde, wird aus der Datenbank entnommen um die Decoder nicht unnötig zu beschäftigen.
Nehmen wir mal an ich habe herausgefunden wie man die Wetterdaten decodiert, das wäre doch wahrscheinlich nicht legal, wenn ich veröffentlichen würde, wie ich das gemacht habe... Meteotime wäre womöglich "not amused" Oder wie sieht der gesetzliche Aspekt dazu aus?
@ ein unbekannter (Gast) : Möglicherweise kann man eine Idee ohne Lösung schildern, die im weiteren Sinne zum Nachdenken anregt.
das wurde doch schon mindestens 200x diskutiert ! Ausserdem ist es eh schon veroeffentlicht.
jo, ist gebrochen und funktionierender code wurde veröffentlicht... seit dem ist ruhe mit diesen threads und meteotime findets bestimmt nicht gut.
ein unbekannter schrieb: > Nehmen wir mal an ich habe herausgefunden wie man die Wetterdaten > decodiert, das wäre doch wahrscheinlich nicht legal, wenn ich > veröffentlichen würde, wie ich das gemacht habe... Meteotime wäre > womöglich "not amused" Der Schlüssel ist gebrochen und es existiert sogar einen Sourcecode dafür. [...] Da der Schlüssel aber gebrochen wurde, macht es kein Spaß mehr damit zu experimentieren. Ben _ schrieb: > jo, ist gebrochen und funktionierender code wurde veröffentlicht... seit > dem ist ruhe mit diesen threads und meteotime findets bestimmt nicht > gut. Ruhiger auch nur deshalb weil das "Geheimnis" gelüftet wurde! Oder weil fasst jeder nun nebenberuflich ATTiny-Meteotime-Decoder über eBay an die Chinesen verkauft?
> Da der Schlüssel aber gebrochen wurde, macht es kein Spaß mehr damit > zu experimentieren. Naja, der gepostete Code enthielt ja den kompletten Satz Schlüssel. Experimentieren brauchste also nicht mehr. Irgendwie hast Du aber Recht, ich hab mir den Code damals erstmal auf die Platte geknallt, werde ich aber wahrscheinlich mangels Interesse eine DCF-Uhr zu bauen nie nutzen...
Thread beobachten
Seitenaufteilung abschalten