AVR: Wetterinformationen über DCF77

Hallo,

auch ich habe die Meteotronic Start Wetterstation und habe festgestellt 
das dort die Pinbelegung etwas anders aussieht als oben beschrieben. Das 
Protokoll ist allerdings das selbe.

Ein paar Kommentare zu den Erkenntnissen hier im Thread:

Das die letzten beiden Bits der Ausgabe des Chips als Indikator fuer die 
Fehlerkorrektur dienen kann ich nicht bestaetigen. Die Bits waren 
gestern z.b. IMMER_ 11 und heute waren sie bis jetzt _IMMER 10. 
Scheint also eher was mit dem Datum zu tun zu haben, wobei die Frage ist 
warum der Chip das an die Station weitergibt. Die kennt das Datum ja 
ohnehin schon.

Was hier bisher noch gar nicht zur Sprache kam ist das es 3 Lizenzen 
fuer den Empfang der Daten gibt (daher wohl die unterschiedlichen 
ICs!?). Naemlich eine a-Lizenz mit der man die Daten fuer Tag1 
entschluesseln kann, eine b-Lizenz mit der man die Daten fuer Tag1 und 2 
entschluesseln kann und noch eine c-Lizenz fuer alle vier Tage (siehe 
http://www.meteotime.com/data_access/meteotime/downloads/meteotime_doc_25_9_06.pdf 
). Es muss also davon ausgegangen werden das die Daten fuer Tag1 anders 
verschluesselt sind wie die fuer Tag2 und diese dann wiederum anders wie 
die fuer Tag3 und 4.

Die Meteotronic Start Wetterstation gibt von 0:00 Uhr - 2:59 Uhr, von 
6:00 Uhr - 8:59 Uhr und von 9:00 Uhr - 11:59 UHR (alle Zeiten MESZ) 
ALLE Wetterdaten an den Chip weiter. Es findet also alle drei Minuten 
eine Kommunikation statt obwohl die Daten gar nicht gebraucht werden. 
Ziemlich merkwuerdig, oder? Kann sich da einer einen Reim drauf machen?

Gruss

ups. Die letzte Zeitspanne muesste "12:00 Uhr - 14:59 Uhr" lauten, nicht 
"9:00 Uhr - 11:59 Uhr".

Also so:

#########       #########       #########
-----------------------------------------------------------------
0  3  6  9  12  15  18  21  0

Die "#" zeigen Zeiten an wo alle drei Minuten eine Kommunikation 
stattfindet.

Es kann auch nicht daran liegen das es Tagesdaten sind. Mein erster 
Gedanke war naemlich das die Station schon an den verschluesselten Daten 
erkennt ob es sich dabei um Tages- oder Nachtdaten handelt. Dagegen 
spricht aber das das ganze zwischen 18:00 Uhr und 20:59 Uhr nicht 
passiert obwohl auch da Tagesdaten gesendet werden.

Sorry fuer den triple-post. Hier das ganze nochmal anders formatiert. 
Hoffe so klappts:

#########       #########       #########
-----------------------------------------------------------------
0       3       6       9      12       15      18      21      0

Das mit der Übertragung NUR zu vordefinierten Zeiten (wie es ja selbst 
in der Protokollbeschreibung steht) glaube ich inzwischen nicht mehr. Es 
mag vielleicht für "aktualisierte" Daten gelten, aber ansonsten gehe ich 
davon aus, daß die Wetterdaten permanent übertragen werden.

Anders kann ich mir nämlich nicht erklären, daß eine bei Penny um 17 Uhr 
neu gekaufte DCF-Wetterstation (von TFA) bereits um 21 Uhr des gleichen 
Abends den ersten Wetter-Wert im Display (Nachttemperatur für Tag 3) 
anzeigt. Bis zur kompletten Anzeige aller Daten hat es allerdings 24 
Stunden gedauert.

Das interessante an diesem Modell ist übrigens, daß es absolut keine 
Pufferspeicher besitzt. Sobald man die Batterien rausnimmt, hat die 
Station alles vergessen, was sie je wußte und der Synchronisationsprozeß 
neu beginnt. Gleiches gilt für einen Wechsel der Vorhersage-Zone - es 
werden keinerlei Daten vorgehalten sodaß auch dabei die vollständige 
Synchronsation 24 Stunden dauert.

Im Gegensatz dazu speichert meine Mete-On-1 die Wetterdaten sämtlicher 
Zonen, sodaß die Werte bei einem Zonenwechsel sofort zur Verfügung 
stehen.

Wenn du sie um 17 Uhr aufgestellt hast und eine Region >40 gewaehlt hast 
dann kommt die Nachtinformation fuer Tag3 noch zwischen 17 und 18 Uhr 
MESZ. Ist also nicht ungewoehnlich.

ich hatte die Station in Region 12 benutzt.

Falls es jemanden interessiert, die METE-ON-1 gibt es aktuell bei 
www.reichelt.de für 179,90 Euro unter der Artikel Nr. WS METE-ON 1

Hallo,
ich lese nun auch schon einige zeit mit und möchte mal meine gedanken 
dabei zur diskussion stellen.

1. kauf einer wetterstation: wenn es leute geben die es geschafft haben 
für nur 30euro soetwas zu kaufen, wieviel kostet soetwas dann wenn man 
eine sammelbestellung tätigt? mir fehlt leider die erfahrung und die 
kontakte, aber vielleicht geht es genau "dir" anders? ;-)

2. wann kommt was: gut, alle 3 minuten scheint eine neue 
wetterinformation zu kommen (welche auch und für welche region auch 
immer), doch welche info zu welcher zeit kommt bleibt dabei ja noch 
offen. wenn man nun jeden tag zur gleichen zeit die batterie entfernt, 
kommt dann immer wieder die gleiche wetterinformation als erstes? also 
z.b. immer zuerst eie temperatur für tag 2? wo ich dann auch stutzig 
geworden bin ist die message von "Gast"

>Wenn du sie um 17 Uhr aufgestellt hast und eine Region >40 gewaehlt hast
>dann kommt die Nachtinformation fuer Tag3 noch zwischen 17 und 18 Uhr
>MESZ. Ist also nicht ungewoehnlich.

woher weiß man das >region 40 die infos zu der uhrzeit bzw. in dem 
fenster kommen? hab ich etwas verpasst?

3. wenn also ein zeitfenster hat, in dem sich eine gewisse info 
einstellt, dann könnte man den input doch mitloggen und anschließend 
noch mal seperat in den chip schieben und so genau den bitstream 
erkennen der die info auslöst.

also, was sagt ihr dazu?

Irgendwo las ich mal den Satz "Wir sind alle Simulanten"

Wann welche Region gesendet wird ist kein Geheimnis. Das steht sogar in 
dem Patentblatt was auch hier im Thread und in dem Wiki-Artikel verlinkt 
ist.

Die Uebertragung der Tagesdaten fuer Tag1 beginnt um 0:00 Uhr MESZ 
(10:00 Uhr UTC) mit Region 0. Um 0:03 Uhr kommen die Tagesdaten fuer 
Tag1 fuer Region 1, dann Region 2, 3, 4, usw.

Ab 3:00 Uhr das gleiche mit den Nachtdaten fuer Tag1.
Ab 6:00 Uhr das gleiche mit den Tagesdaten fuer Tag2.
...
Ab 18:00 Uhr das gleiche mit den Tagesdaten fuer Tag4.

Von 21:00 Uhr bis 23:59 Uhr kommen dann noch die vier Uebertragungen 
fuer die 30 restlichen Regionen. Also Tages und Nachtdaten jeweils 1,5h 
versetzt.

Die moegliche Uebertragungsrate ist somit vollstaendig ausgeschoepft.

> Also sollte es für die drei Lizenzvarianten drei verschiedene
> ROM-Versionen geben? Mir erschließt das mit den Lizenzen nicht so recht.

Es koennte auch sein das die Hersteller der Stationen einfach Chips 
bekommen mit einer Software drauf die einfach keine Daten ausgibt wenn 
eine falsche Uhrzeit eingegeben wird. Mit "falsch" meine ich eine 
Uhrzeit zu der Daten gesendet werden die mit dieser Lizenz nicht 
freigeschaltet sind.

> Es besteht keinerlei Möglichkeit, abundzu andere Vektoren in die
> Datenübertragung einzuschieben? z.B. um uns zu verwirren oder den
> Dechriffrierer auf einen anderen Schlüssel umzuschalten?

Nein. Die Sache mit dem Schluessel uebertragen faellt sowieso flach weil 
sonst eine Station nach dem einschalten erstmal auf einen neuen 
Schluessel warten muesste.

----

Noch was zur Spannungsversorgung. In dem im Thread verlinkten Datenblatt 
zu dem Dechiffrier-IC steht eine max. Spannung von 3,6V. Bei der 
Meteotronic Start haengt der Chip allerdings direkt an der 
Batteriespannung (3x 1,5V = 4,5V). Ich hab die Station mal testweise mit 
3,0V laufen lassen, aber da erscheint schon die anzeige "Bat". Das 
koennte allerdings auch mit den unterschiedlichen ICs zusammenhaengen.

Das was mir am meisten erfolgsversprechend erscheint ist das Mitloggen 
von Eingangs- und Ausgangsdaten von diesem ominösen Chip. Das dürfte 
kein großer Aufwand sein und kann automatisiert ablaufen. Das sollte 
über mehrere Tage gemacht werden, um z.B. festzustellen ob auch Datum 
bzw. Uhrzeit Einfluss auf den Entschlüsselungsalogrithmus haben. Wenn 
man dan genug Daten hat könnte man vielleicht den Schlüssel 
herausfinden.
Jetzt kenn ich mich aber in Kryptografie überhaupt nicht aus. Ich weiß 
nur dass es nicht einfach sein wird den Schlüssel herauszubekommen. Ich 
denke das die Ingenieure, die das Protokoll entworfen haben, schon ein 
bisschen Gehirnschmalz hineingesteckt haben.

Wie genau kommen die Daten eigentlich raus? Seriell?

Hmm... Natürlich seriell ;) War ein wenig schnell eben.
Aber in welchem Timing? Nachdem der Prozessor die Daten der ersten 
Minute bekommen hat, kommt da schon was raus? Oder wartet der die 
kompletten 3 Minuten, dann wird berechnet und dann kommen Daten raus?

Aber in welchem Timing? Genau so, wie das DCF Signal? Oder jagt der die 
decodierten Daten einfach in gewissen Abständen raus?

Der Pic benötigt pro Instruction 4 Taktcykeln, anhand des 
Stromverbrauchs, mit einem schnellen Oszi gemessen lässt sich 
fetsstellen welche Befehle er gerade abarbeitet. Jeder Befehl hat eine 
charakteristische Stromfunktion....
Deshalb ist der PIC auch nicht für Sicherheitsanwendungen einsetzbar. 
Wer Lust hat kann ja mal messen, sofern der Typ bekannt ist ließe sich 
mit etwas Geschick die laufende Software analysieren....

Mit 4MHz getaktet macht das 1.000.000 Befehle pro Sekunde!
Da kommt bestimmt eine Menge Daten zusammen!

Der Algo wird so einfach sein das es durch die 3sek. Wartezeit 
unmoeglich wird den in endlich langer Zeit durch Inp/Oup zu knacken oder 
es ist ein Designfehler und es werden alle "3??" Nachrichten gebraucht. 
Sollte man mal abtesten.

Auf alle Fälle wird versucht durch wustes Bitgewackel den gemeinen 
Datenlogger vom knacken abzuhalten.....

;-)

Die Wartezeit ist nur ca. 250 us und das auch nur einmal alle drei 
Minuten. Waeren also "nur noch" 250.000 Befehle.

Wäre das hier eine Option?
http://microblog.routed.net/2008/07/15/how-to-write-an-ic-friday-post/

Hat eigentlich schon jemand herausgefunden, zu welcher Zeit welche Zone 
übertragen wird?

Denn zum Beispiel der Zeitbereich "22:00 - 03:59    Aktueller / 
kommender Tag (TODAY im Display)" Verfügt über genau 120 * 3 minuten

Da es aber nur 60 Zonen gibt, bleibt genau die Hälfte übrig. Oder wird 
alles doppelt übertragen?

Nicht doppelt. Aber zu jedem Tag gehoeren zwei Pakete. Eins fuer den Tag 
und eins fuer die Nacht. Die Infos zur Wetterlage sind bei beiden 
gleich, allerdings werden z.b. im Nacht-Paket Winddaten uebertragen und 
im Tagespaket an gleicher stelle Infos zu schwerem Wetter.

Ah stimmt ja, das habe ich übersehen. Weißt du zufälligerweise auch, wie 
das dann gemacht wird?
Zone 0 Tag
Zone 0 Nacht
Zona 1 Tag
Zone 1 NAcht.....

oder

Zone 0 Tag
Zone 1 Tag
...
Zone 0 NAcht
Zone 1 NAcht

Unbd wie sieht es mit dem Day 3 aus? der kann für jede Zone nur ien 
Packet übertragen.

mfg
Sevi

Es ist so wie deine zweite Aufzaehlung. Also erst Tag fuer alle Zonen, 
dann Nacht. Das ist wohl einfacher fuer die Wetterstation weil sie dann 
nur alle 3 Stunden ein Paket auswerten muss. (bzw. fuer Zonen >59 alle 
1,5h)

Am Tag 4 fehlt einfach das Nachtpaket. Meine Station zeigt da allerdings 
auch eine Nachttemperatur an. Wie sie darauf kommt weiss ich aber nicht. 
Evtl. errechnet sie einen Erwartungswert aus den Nachttemperaturen der 
anderen drei Tage.

Hallo,

habe seit 3 Tagen einen DCF77-Empfänger, will einen ATMEGA8 dafür 
programmieren und bin heute hier hereingestrauchelt.

Zum Bit 1 und 8, die im 1 von 3 Blöcken immer 0 sind: das sind die 
Alarmbits des Katastrophensignals, die aus Kompatibilitätgründen 0 
bleiben müssen.

Daraus ergibt sich ein Nutzsignal von 12 + 2x14 = 40 bits, nicht wahr ?

Gibt es eigentlich bereits nwnder, die ihren controlller mit einem 
offiziellen Decoder aufgemotzt haben ?

Also z.B. DCF77->Decoder->AVR->PC, um im Pc die kompletten Wetterdaten 
zu haben ?

Gruss,
Michael

...würde mich auch interessieren.
Speziell ob ein Chip aus einer "einfachen" Uhr, d.h. ohne Anzeige der 
erweiterten Werte diese dann auch richtig dekodiert!?

Moin

@Michael: Wo hast du die Info für das Katastrophenalarmsignal her?

MfG
Andreas Lang

@Andreas Lang:

Quellen:
http://www.nafuo.din.de/sixcms_upload/media/2609/Vortrag%20INS%20Bevoelkerungswarnung%20Hannovermesse%202008.pdf

und

http://de.wikipedia.org/wiki/DCF77#Bit-Struktur_DCF77-Alarmsignal_des_Feldversuches

siehe http://www.freepatentsonline.com/EP1798612.html

Ist doch alles nichts Neues.

Hallo zusammen,

habe den Thread mal durchgelesen.
Die Dechiffrierung scheint (noch) nicht (öffentlich) möglich zu sein.
Der Ansatz von Dexter schein mir am vielversprechensten zu sein. Um die 
Bits der Wetterdatenbits varieren zu können müßte aber die 
Paritätsprüfung der Wetterdaten bekannt sein. Denn der Chip dekodiert 
die Wetterdaten anscheinend nur bei gültiger Parität.
-Hat hierzu schon jemand einen funktionierenden Ansatz?
-Sind noch Leute aktiv die das entsprechende Equipment und eine 
funktionierende Wetterstation haben?

Mein Interesse an dem Thema ist natürlich rein akademischer Natur.

Habe seit heute einen Attiny2313 der mir die einzelnen Bits ausgibt. 
(Scheint auch gut zu funktionieren)

Hallo,
Ich habe aufgrund der empfangsschwierigkeiten einen neue 
Spannungsversorgung an den empfänger angeschlossen, so wie es scheint 
wird scheint es nun mit dem empfang besser zu sein.
Die ganzen anderen Log-Dateien habe ich verschoben, wer sie haben 
möchte, soll sich melden:
http://www.thomy-pc.de/?site=kontakt

Die neuen Logdateien sind dann hier:
http://www.thomy-pc.de/serverstatus/dcflogs.php


Übrigens, die Fehler die dort reinkommen sind zu 99,999% Fehlimpulse 
oder fehlende Impulse.
Bitfehler sind äußerst selten.

gruß
thomy_pc

Mal rein zu Übersicht:
Sind die übertragenen Wetterdaten die gleichen wie bei Kachelmannwetter? 
Dann lohnt der ganze Aufwand eh nicht. Nach meiner Beobachtung sind 
deren Wettervorhersagen meistens ziemlich daneben. Ein Blick an den 
Himmel mit Prüfung der Windgeschwindigkeit ist genauso aussagekräftig. 
Ich wohne praktisch direkt neben einer seiner Wetterstationen und 
vergleiche deren Online-Wetterprognose mit dem, was dann hier ankommt. 
Oftmals schwanken die Vorhersagen innerhalb Stunden drastisch! Ziemlich 
unrealistisch.


- Abdul

Momentan glaube ich nicht, daß es jemand knacken und auch publizieren 
wird. Lasse mich aber gerne vom Gegenteil überzeugen. Das Interesse hat 
offensichtlich sehr nachgelassen.

Ob es rechtlich ein Problem ist, weiß ich nicht. Meinst du?

Ich wollte nur die Leute vorwarnen, die die Daten dann irgendwie für 
sich nutzen wollten. Z.B. für die eigene Haussteuerung.

Eine Verwendung für eigene Projekte zu verschlüsseln, könnte ich mir 
schon vorstellen! Das akademische Interesse darf also bestehen bleiben.


Grüße -
Abdul

Zur Fehlerkorrektur:
Nach etwas Google Recherche bin ich auf den Hamming (7,4) code gestoßen.
Dieser erlaubt in jedem 7 Bit Wort einen Fehler. Rechnerisch würde das 
heißen
6 Worte zu je 4 Bit davon gehen 2 Bit weg da diese für die PTB verwendet 
werden d.h. es werden 22 WetterBits übertragen die natürlich noch 
verschlüßelt sind.
Problem die Hamming Matrix ist wählbar. Um die verschlüßelten Wetterbits 
zu erhalten müßte man erst die Hamming Matrix herausfinden.
ALs ersten Vorschlag würde ich Vorschlagen dass die erste Spalte der 
Hamming Matrix (1 0 0 0) ist was gleichbedeutend mit dem ersten Datenbit 
ist. Dadurch ließe sich steuern dass das erste Zeichen des Hammingwortes 
gleich null ist wenn das erste Zeichen des Datenwortes auch 0 ist. 
(wichtig für PTB Bits).

Dagegen spricht:

Prinzipiell sind max 6 Bitfehler korrigierbar anscheinend wird aber nur 
einer korrigiert. (siehe DEXTER)

Quelle zu Beispielimplementation Hamming Code:

http://michael.dipperstein.com/hamming/index.html

Was halten die Experten davon?

Hallo,

auch ich habe mich vor einiger Zeit an diesem Wettercode versucht. Hatte 
eine Wetterstation gekauft und die Kommunikation abgezapft und am PC 
mitgeloggt und analysiert. Es sind einige Stunden da reingeflossen und 
rausgekommen ist letztendlich nichts.

Ich habs dann nachher aufgegeben aus folgenen Gruenden:
-Man bekommt (genauere) Wetterdaten einfacher von irgendwelchen 
Webseiten. Einen Parser dafuer zu schreiben ist weit einfacher als die 
Verschluesselung zu knacken.
-Die Zukunft dieser Art der Wetteruebertragung ist ungewiss. Die 
Vertraege laufen afaik noch bis 2012, was dann passiert weiss keiner. 
Dann waere also die ganze Muehe nur fuer ~4 Jahre.

Ich weiss, es geht nicht nur darum die Wetterdaten zu bekommen, sondern 
auch darum den Ehrgeiz zu befriedigen und ich will auch niemanden hier 
entmutigen. Aber denkt einfach mal drueber nach.

Gruss

>Einen Parser dafuer zu schreiben ist weit einfacher als die
>Verschluesselung zu knacken.

Schon.
Nur habe ich einen Heizungsregler, der auch die Beladung des 
Pufferspeichers steuert, in dem ist 'ne DCF77-Uhr integriert (Eigenbau).
Da ich den Puffer nicht gerne belade, obwohl zwei Stunden später die 
Sonne 'rauskommt, wären die Informationen über das Wetter am kommenden 
Tag schon hilfreich, und das ganz ohne Hardwareänderung.

@ Thilo M.

Genau dieser Gedanke verfolgt mich schon seit ewigkeiten...


Gruß,
Tubie

Der Threadstarter hat sich nicht noch einmal gemeldet.

Hallo,
Mich würd das ganze schon interessieren, denn mit dem Programm mit dem 
ich die Daten logge, welches ich mit einem weiterem Empfänger an meinem 
Stand-PC nutze, würde ich die Daten gerne dekodieren sodass ich 
persönlich da wetterdaten anzeigen lassen kann,
leider habe ich nicht die mittel (und auch kein Geld, da Schüler) diese 
daten zu loggen wenn ich solch eine wetterstation hätte, die erfahrung 
solche daten zu entschlüsseln, oder zumindest einen Ansatz zu finden.
Nunja, ansonsten ich hab für euch Logdateien bereitgestellt (der link is 
in meinem Letzen Posting..

gruß
thomy_pc

Hallo zusammen,

bei Aldi(Süd) gibts ab nächster Woche ein Funkwetterstation mit 
Wettervorhersage durch Symbole.

http://www.aldi-sued.de/de/html/offers/2867_8765.htm

Kann jemand von euch abschätzen ob hierzu die DCF77 Wetterdaten genutzt 
werden oder lediglich die Temperaturen / Tendenzen.

Grüße

Da steht ja auch schon das der Sensor 100m Reichweite hat. Wenns per 
DCF77 gehen wuerde braeuchte man ja keinen Aussensensor. Ich gehe also 
auch davon aus dass es nicht per DCF77 geht.

Der Preis ist allerdings nicht so unglaublich guenstig fuer ne 
Wetterstation die ueber DCF77 geht. Bei ebay gehen die fuer ~25 EUR weg.

>Auch wenn ich im Cipher irgendein Bit (bis auf das erste) ändere,
>bekomme immer die obige Antwort.

Eine schlichte Checksumme dürfte die wahrscheinliche Ursache dafür sein.

Versuch mal, den Chip zu resetten in dem Du kurz die Versorgungsspannung 
unterbrichst. Evtl. reicht nur ein kurzer Impuls um einen evtl. 
vorhandenen Brown-Out-Detector zu triggern.

Dann könnte man viel schneller Cipher-Telegramme senden.

Grundsätzlich ist nur gesichert, was man auch überprüft hat. Fehler 
werden überall gemacht, also muss man überprüfen ob man über ein 
Power-Down den Chip resetten kann.

Aber anyway: Ich habe den Thread erst kürzlich gefunden und nur 
quergelesen; habe keine Lust mir Hardware zu besorgen; habe aber 
Interesse am dekodieren.

Um es nochmals klarzustellen:

Du hast ein Setup, bei dem Du die verschlüsselten Daten, die in den Chip 
reingehen, und die entschlüsselten Daten, dir aus dem Chip rauskommen, 
mitgeschnitten werden kann?

Werden da minütlich irgendwelche Daten entschlüsselt? Wenn ja, könntest 
Du hier mal ein Tages-Log der Bits reinhängen?

Hast Du schon systematisch Tests gemacht, wie z.B. verschiedene Anzahl 
von Bits kippen/setzen/löschen? Was ist mit vertauschten Bitpositionen? 
Hast Du schon Datenbits verschiedenere Datensätze gemischt etc.?

Die 45ms kommen mir als power-up timer verdammt bekannt vor,
kenne sie von 2 verschiedenen Prozessortypen.
Ist es möglich, eine Verbrauchmessung während des Resets sowie bei
Verbrauch zu machen ? mit ozi. Weiters, ob unterschiedliche know error 
bit mittels differenzial-korrelazion erkannt werden kann.

Ist es möglich, die 6 TestPunkte zu identifizieren.
Komisch, daß es 6 sind, hätte gedacht, 4 würden reichen.

Dachte auch an EM-teile, das sind PIC-clone´s, zumindest die 8-bitter,
und natürlich billiger.

Eine AN mit einer Programmieradapter kann man sich für ICSP von der
Website downloaden.

@ Walter:
Dein Ehrgeiz ist im Moment anscheinend riesengroß. Weiter so!
Was allerdings zu bedenken ist: du brauchst erstmal eine Platine, auf 
der der entsprechende IC bestückt ist. Kann natürlich sein, dass unter 
dem "schwarzen Klecks" ein ebensolches versteckt ist; ich glaubs nicht; 
muss man aber auf jeden Fall ausprobieren.
Also weiterhin viel Spaß mit der Sache! :-)

Nochmal zur Klarstellung: Hatte oben irgendwo nicht jemand den genauen 
PIC indentifiziert? Ist der EM zu diesem zumindest vom Pinout was 
Stromversorgung angeht, kompatibel?

Zu Marin kann nicht nicht viel sagen, da noch nie verwendet. Es ist aber 
eine Firma aus dem Bereich Uhren und die Verwendung eines Chips von 
denen wäre hier dann naheliegend.

Vielleicht gibt es mehrere Generationen, eventuell mit unterschiedlichen 
Controllern??

Obacht! Eventuell bringt der Chip absichtlich Müll raus, wenn er in 
einem zu offensichtlichen Timing angesteuert wird!

Wenn wirklich nur ein Bit als Fehler erkannt und korrigiert werden kann, 
dann wuerde als Fehlererkennung ja ein einfaches parity-bit ausreichen.

Man konnte dann versuchen das parity-bit zu aendern und noch ein 
beliebiges weiteres. Dann sollte er den Fehler nicht mehr erkennen 
koennen und evtl. kommt dann wieder was richtiges raus.

Problem an der Sache ist die Position herauszufinden. Wenn mans 
systematisch macht sollte das aber selbst manuell kein grosses Problem 
sein.

Wenn ein CRC mitgeht, dann kann man ihn auch korrigieren, dauert halt.
Ich mache das mit 8bit crc, da kommt ein 7bit wert raus, hänge das 
Parity-bit ran, und so ist 1 bit corrigierbar, langsam aber platzsparend 
und
effektiv.

Ich bin kein ECC-Freak, aber soweit ich weiß gibt es diverse Klassen bei 
den CRCs. Manche davon können auch zur Fehlerkorrektur verwendet werden, 
was vor allem von der Blocklänge abhängt.
Man könnte sich an Henning Paul wenden. Der kennt sich damit aus und 
spricht deutsch.

Vielleicht brauch der Chip die 45 sec. einfach zum Rumrechnen?

Und er bekommt dann jede Minute ein neues Datenpaket ist dann wieder 45 
sec. beschäftigt...
Blieben also 15 sec. über, um die Toleranzen eines onchip RC-Oszillators 
abzufangen?! Würde gut passen.
Diese Zeitspanne wurde dann offensichtlich gleich als "BLOCKzeit" 
verwendet. Was ja naheliegend ist.

Das man den EM-Code einfach zu auslesen kann, würde mich wundern. 
Protection ist heute Standard.

Gibt der Chip nach dem Einschalten von alleine irgendwas aus?

Da er jederzeit synchronisieren können muß, wird er wohl nicht 
sonderlich auf die sequentiell richtige Datenreihenfolge am Eingang 
achten. Er könnte es aber!


Gruß

Wenn deine Vermutung stimmt, was einleuchtend ist, dann würde ich
nicht auf einen ECC tippen, sondern auf block encryption, welche
mittels eines Schlüssels verschlüsselt ist, eventuell auch in recursiver
function, neues Datenpaket wird mit letztem unencrypted datenpaket 
xor´ed oder so. Das würde eher einleuchten, und da wird es dann 
schwerer.
Tea, Xtea, Bluefish, ... fallen mir spontan ein.

Bezieht Chris sich auf Abdul?

Der Chip hat nur begrenzte Resourcen. Kann man diese Verfahren dort 
überhaupt unterbringen?

Sein RAM ist auch sehr begrenzt. Ist die Frage, ob er überhaupt 
irgendwelche Daten aus dem jeweils vorherigen Datenpaket 
zwischenspeichern kann. Außerdem geht das nur begrenzt gut, da er 
jederzeit eingeschaltet werden kann und dann zeitlich irgendwo im 
Datenstrom aufsetzen muß!


Gruß

Ja, hatte mich auf Abdul bezogen.
Ja, TEA, XTEA usw werden bevorzugt eingesetzt, weil sie mit begrenzten
resourcen auskommen, sei es RAM, wie Rechenzeit.
Normalerweise dauert sowas ca 20-30ms bei 1Mhz taktzeit (pic), bei 32khz
würde das 8 sekunden heissen.

Das mit dem Datenstrom irgendwie aufsetzten, wenn es 64 stationen gibt,
dann beginn mit der 1sten und warte bist die kommt, und fang dort an.
Nimm eventuell die Uhrzeit als init, von der 1st station,
verwirf das Ergebnis, bzw behalte es intern, und dann fangen die 64 an. 
Die 64 sind jetzt nur fiktiv.

Wenn es "ein wenig funktionieren soll", dann müßte er mindestens so viel 
zwischenspeichern können, daß er ein kaputtes Impulstelegrann für einige 
Zeit verkraften kann?

Die Information wird ja genügend oft gesendet, rechne mal aus, wie oft
das gesendet wird.

Das denke ich bezieht sich nur auf die einzelne Wetterinformation vom
Flughafen, der sie alle <30min ändert. Wenn dem wirklich so wäre,
dann dürfte es im 24stunden Zeitraum nur ca 500 telegramme mit 
Wetterinfos geben.

Habe in der Spec nachgeschaut, alle 3 Minuten wird die Wetterinfo einer 
Region (vorhersage + aktuell) gesendet, sprich alle 3 Minuten wird sie 
wiederholt.

puhh... die letzten posts glaenzen aber extrem mit falschem Halbwissen. 
Das muss ich mal etwas aufraeumen.

1. Es kann nicht sein das der Chip 45s rechnet. Die Station sammelt die 
Daten ueber drei Minuten und gibt sie dann dem Chip als seriellen 
Datenstrom. Dieser antwortet dann sofort (wenige ms delay). Also kaum 
Rechenzeit.

2. Die Wetterdaten werden pro Region genau einmal pro Tag gesendet. Das 
sind 7 Pakete. 3x Tag und Nacht von heute bis Uebermorgen und 1x Tag vom 
4. Tag.

3. Das die Pakete mit dem Klartext vom Vorherigen verschluesselt sind 
kann auch nicht sein. Die Station uebergibt nicht alle drei Minuten 
Daten an den Chip, sondern (teilweise) nur die relevanten, also nur 
EIN Paket aus drei Minuten.

Bevor hier Leute ernsthaft mitreden wollen, sollten sie lieber einmal 
die specs. lesen, ansonsten kommt hier alles durcheinander.

Hier eine Idee von mir, vielleicht ist sie nützlich:

Früher, beim C64, konnte man im Lautsprecher des angeschlossenen 
Fernsehers 'Mithören' was der Prozessor gemacht hat. Die Schaltvorgänge 
der CPU haben sich ganz leise in das Audio-Teil reingekoppelt.

Man konnte gut hören, ob die CPU grad eine Warteschleife durchlief oder 
intensiv was rechnete. Sogar ISR-Routinen konnte man raushören, da diese 
periodisch wiederholt wurden.

Vielleicht kann man den Controller über einen Widerstand (27 Ohm oder 
so) betrieben und daran einen empfindlichen Verstärker hängen (oder eine 
Spule an den Controller halten) Wenn der Controller keine 
Schutzmassnahmen dagegen hat, stehen die Chancen gut, dass man raushören 
kann, ob der Controller während der 45 Sekunden intensiv rechnet oder 
nur eine Warteschleife durchläuft.

Das menschliche Gehör ist hier besser geeignet als ein Oszi, mit dem man 
das vielleicht viualisieren könnte!

Damit kann man vielleicht auf die komplexität des Verschlüsselungsalgos 
rückschliessen!

Viel erfolg, ist sehr spannend der Thread!

Laut meinen infos hat es keine code-protection, wohl aber eine
checksum. Entweder, es ist nicht möglich, den Code auszulesen, daß
nur die checksum ausgerechnet wird, und ausgegeben, oder man kann ihn
auslesen. Aber achtung, sollte das Epoxy ein Wafer sein, ist 
warscheinlich,
nicht sicher, daß es keine flash, sondern eine rom version ist.

Die VPP beträgt 15V, bei 3V vdd, nach dem proggen, kann die checksum 
nachträglich ausgelesen werden, waveformen der pins sind in den an´s,
die icsp-befehle leider nicht.

Hallo zusammen,

schön zu sehen dass wieder Leben in den Thread kommt. Die letzten Posts 
lassen allerdings die Unkenntniss der bereits weiter oben im Thread 
diskutierten Tatsachen erkennen. Deshalb nochmal zusammengefasst:

 - 60 Regionen mit 4 Tagesprognose
 - 30 Regionen mit 2 Tagesprognose

Jede Prognose benötigt 42/40 Bit aus dem DCF77 Signal d.h alle 3min 
kommt eine Prognose. Was bedeueted das die jede Prognose nur einmal 
gesendet wird.
Die Sendezeiten der jeweiigen Regionen sind festgelegt und stehen weiter 
oben im Thread.

Zur Entschlüßelung werden 3*14 Bit Wetterdaten und die Zeit/Datum Daten 
des zuletzt gesendeten Wetterdatenblocks an den DCIC gesendet (Dexter / 
Walter Freywald 4.11.08)

Der DCIC gibt dann den Entschlüßelten Datenstrom mit 24Bit aus von denen 
2 Bit anscheinend Statusinfo (Fehlererkennung/Fehlerkorrektur) zum 
entschlüßelten Datenstrom sind.

Ich hatte weiter oben mal die Vermutung geäußert dass es sich um einen 
Hamming(7,4) Code handeln könnte. Statistische Untersuchungen haben 
gezeigt dass die Daten in unterschiedlichen Zusammensetzungen sehr 
gleichmäßig verteilt sind. Deshab sind die untersuchten 
Zusammensetzungen meiner Ansicht kein Hamming Code.

Grüße

Leider ist die Übersichtlichkeit des Threads komplett hinüber. 
Vielleicht findet sich jemand und macht für jeden neu überarbeiteten 
Punkt ein paar Sätze auf einer extra HTML-Seite? <Nein, ich habe dafür 
keine Zeit>

Dann multiplizieren wir mal die 800kHz (??) mit 270ms und bekommen die 
mögliche maximale Prozessorbefehlszahl, die er überhaupt abarbeiten 
kann. Müßte noch jemand klären, wieviele Zyklen der Chip pro Befehl im 
Durchschnitt brauch.
Damit hätten wir ein Maß für die mögliche Komplezität der 
Verschlüsselung.
Abzüglich der Zeit aus dem Hörtest :-)


Gruß

es gibt doch bereits ne seite im wiki darueber. die koennte mal jemand 
erweitern.

Hei, habe begonnen den Thread mal mehr durchzulesen.
Bin darauf gestoßen, daß es eine Uhr mit  PIC 12F509 gibt.
Da holt man die FW einfach raus, ist die beschaffbar ?

Es könnte ein Pic sein, muß es aber nicht.
Ev. könnte ich den Pic auslesen, sollte der beschaffbar sein.

Pic becommt man über microchipdirect auch mit ander Bezeichnung 
gelasert.
Auch ich würde ein Pic vermuten, abgesehen von VPP, würde eine 
Pin-Messung mit 5V, bei 3V VCC z.B. nicht den reset-pin von einem i/o 
pin unterscheidbar machen ? oder besser ohne vcc, und an vcc messen ?
Mittels Power-Glitch 50mV oder 10V für die alten typen, lassen das
copy-protection verschwinden, ohne das Flash zu löschen.
Ich vermute mal stark, daß die Daten in Form von 
http://de.wikipedia.org/wiki/DCF77#Bit-Struktur_DCF77-Alarmsignal_des_Feldversuches 
sind, sowie eine xor/scrambling mit dem Zeitsignal besitzen.

Hier der Link zum Wiki, falls (sich) jemand die Mühe/Ordnung machen 
möchte:
http://www.mikrocontroller.net/articles/DCF77_Wetterinformationen

Vpp, würde nicht über 5V gehen, 3V vcc sowie 5V testspannung, damit
kann nichts passieren. Bei 2V VCC könnte bei 5.5V der pic schon in den
icsp modus gehen, aber 5.5V ist bei neueren technologien schon zuviel.

Power-Glitsching, geht problemlos, gleich nach dem ICSP-command
erase-all ein glitch von von 0.7-2ms (bei den meisten) geben, und
das Löschen des Flashes wird übersprungen.
Da sieht man, wie wichtig Abblockkondensatoren sind.

OT: http://www.cl.cam.ac.uk/~sps32/mcu_lock.html
Die genaue Technik für Pic war mal in einem PDF desselbigen Authors.
Habe es selbst auch ausprobiert, es funktioniert problemlos.
Der Witz ist, daß sie ein Problem hatten, mit 10V, dann einen 
Spannungsdektor deswegen extra eingebaut haben, in den A versionen,
und dann klappt es mit 50mV. Trotzdem sind die Pic´s billig und ich
setzt sie immer noch ein, kann aber schon mal vorkommen, daß ich den
VPP Pin durchbrennen lasse, wenn ich einen Prototypen zu einem neueren 
Kunden rausgebe, sowie Bootloader mit Verschlüsselung.

Das würde den Verdacht bekräftigen, daß es sich um ein Pic handeln 
könnte.

Würde folgendes vorschlagen, IC auslöten, auf protoboard mit condensator 
sowie ICSP eines pic´s. dann bitpattern testen. Gleichzeitig kann man 
auch die Strohmaufname, sowie diese beim Einschalten testen, und mit 
einem Pic vergleichen. Sollte die
stimmen, kann man mit sehr hoher Warscheinlichkeit einen Pic vermuten 
und
einen Programmieradapter anlegen.

Was kostet die Uhr ?

Solltest du einen pic programmierer haben, wäre folgendes von interesse:
VCC 2V (restliche uhr ausgeschaltet) und VPP über 47k Wiederstand an 
5.5V,
denn VCC+3.5V müßten schon den PIC in den Programmiermodus setzen. 
Eventuell auch 5.6V oder 1.9V VCC, wenn der PIC dann läuft.

Auch wenn es kein PIC ist, schadet es dem IC nicht, zumindest >99%.
wenn kein 47k, einfach größer gleich 10k, aber unter 50k.
Wichtig, VPP muß vor VCC anliegen.

Kann die 28€ Uhr auf Bolzano / Bozen eingestellt werden ?
Wenn ja, wie heisst die ? und wo hast du sie gekauft ?

Vielleicht von Interesse:
http://www.scribd.com/doc/2412336/DataRem-CHES2005

Hallo Leute,

ich habe mir mal die statistische Verteilung der '1' und '0' Bits 
bezogen auf die jeweilige Bitposition innerhalb des 42-bittigen 
Wetterdatenblocks angesehen und bin bei der Auswertung eines Logs über 
einen kompletten Tag zu folgendem Ergebnis gekommen:

Wahrscheinlichkeit für eine '1' an den Bit-Positionen des 
verschlüsselten Wetterdatenblocks :

Bitposition   Block1   Block2   Block3
Bit Pos 01:   0.00     0.50     0.50
Bit Pos 02:   0.54     0.51     0.50
Bit Pos 03:   0.44     0.51     0.50
Bit Pos 04:   0.55     0.49     0.50
Bit Pos 05:   0.40     0.50     0.50
Bit Pos 06:   0.52     0.50     0.50
Bit Pos 07:   0.54     0.51     0.50
Bit Pos 08:   0.00     0.51     0.51
Bit Pos 09:   0.46     0.50     0.50
Bit Pos 10:   0.43     0.51     0.50
Bit Pos 11:   0.46     0.50     0.50
Bit Pos 12:   0.44     0.50     0.50
Bit Pos 13:   0.51     0.50     0.49
Bit Pos 14:   0.61     0.50     0.50

Meine Schlüsse hieraus:

Da im Block 2+3 annähernd alle Bits mit der gleichen Wahrscheinlichkeit 
'0' als auch '1' sind, vermute ich, dass sich an diesen Stellen die 
verschlüsselten Wetterdaten (22 Wetterbits + 6 Füllbits) befinden.
Durch die Verschlüsselungsmethode wird die Häufigkeit des Auftretens 
einer '1' genauso groß wie für eine '0'.

An der Position 1+8 des 1.ten Blockes steht immer eine '0' => Alarm-Bit, 
wie bereits weiter oben im Thread erwähnt.
Die restlichen 12 Bits des 1.ten Blockes tendieren in ihrer Häufigkeit 
je nach Bitposition eher zu einer '0' bzw '1'.
Deshalb vermute ich, dass es sich bei diesen Bits im 1.ten Datenblock um 
eine Checksumme, Fehlerkorrekturbits oder ähnliches handelt.

Gruß
uzi

Wieviele Wetterdaten hast du in diese Berechnungen einbezogen? Ich hatte 
das mal mit 120 Wetterbloecken (mit je 42 Bits) gemacht und habe keine 
so schoene Verteilung bekommen (siehe Bild im Anhang).

Da der Chip sowohl Clock (müßte nicht unbedingt so sein) als auch 
enschlüsselte Daten (logisch) mit einem nachmeßbaren Timing rausschiebt, 
kann man daraus die wahrscheinlichsten Clock-Frequenzen des Chips leicht 
bestimmen.

Offenbar werden wohl diverse Chip-Generationen verbaut. Die Pinbelegung 
ist ja selbst für die Versorgungsanschlüsse unterschiedlich.

Interessant wäre es auch noch mit einem Spektrumanalysator oder 
Amateurfunkempfänger an der Versorgung des Chips nach auffälligen 
Frequenzen zu suchen. Dafür würde ein einfacher Ferritübertrager in 
Reihe zum VCC-Pin als Auskopplung reichen.

Dann wäre noch die Sache mit der minimal möglichen Versorgungsspannung 
und für die Charaktierisierung des internen Oszillators eine 
Temperaturmeßkurve genau obiger Frequenzen.

Gruß

Hallo 'Gast'

für meine Berechnung der Wahrscheinlichkeit einer '1' bzw '0' für die 
entsprechende Bitposition habe ich die Logs von 11 Tagen also ca. 5200 
Datensätze zu je 42 Wetterdatenbits ausgewertet.

Gruß
uzi

Hallo Leute,

um bei der Sache hier ewas weiter zu kommen,
halte ich die folgenden Dinge für hilfreich:

1. Wo befinden sich in den 42Bit (bzw 40 Bit + 2 Alarmbit) der
   verschlüsselten Wetterdaten die eigentlichen Nutzdaten
   und wo die Prüfbits für die Fehlerkorrektur ?

   Hierzu habe ich ja bereits vor einiger Zeit meine
   Untersuchungsergebnisse bekannt gegeben.
   Gibt es hierzu vielleicht noch andere Meinungen /
   Widersprüche / Bestätigungen ???

2. Thomas (Thommy_PC) hat ja auf seinem Server bereits einige
   Logfiles mit den über DCF übertragenen Daten bereitgestellt.

   =>  Ist jemand in der Lage diese Logfiles zum Dechiffrier-IC
   zu senden und die dazu passenden dekodierten Wetterdaten
   mitzuloggen?

   Je mehr komplette Datensätze bestehend aus den
   verschlüsselten Wetterdaten + dazugehörige
   Datum/Zeitinformationen + dekodierten Wetterdaten vorhanden
   sind, umso besser.

   Hierraus könnte dann ggf. eine "Known Plaintext" Attacke
   durchgeführt werden, um der Verschlüsselung bzw. dem
   Prüfbit-Mechanismus auf die Spur zu kommen.

3. Kennt sich hier einer etwas besser mit Kryptographie bzw.
   Kodierungstheorie aus ?

Was haltet ihr davon ?

Gruß
uzi

Der schnellste Kryptographische Ansatz waere eine
differential power analysis. Man braucht dazu einen 12bit ADC.

Wie gesagt, erster Ansatz, "differential power analysis".
Sollte da nicht ordnungsgemaess programmiert worden sein, so kann man
damit den Crypto in die Knie zwingen.

12 Bit ADC, man misst die Spannung/Strohmaufnahme des uC.
Dazu reduziert man auch die Entstoerkondensatoren, sowie fuerht ein
Wiederstand dazwischen ein.
Nun fuetter man den uC mit source-dateien, und loggt es mit.
Dann fuettert man ihn mit modifizierten source-dateien, auch geloggt.
Sieht man unterschiede, so kann man z.B. evaluieren, welche bits 
zusammengehoeren, wie der Algorithmus ist usw. z.B. kann man so 
problemlos
passwoerter herausbekommen. Ein Beispiel von korrekt und inkorrekter 
Programmierung.

char *password="test";

for(i=0;*pw;i++)  if (pw[i]!=password[i]) return 0;
...

richtig

char r;
for(r=i=0;*pw;i++) if (pw[i]==password[i]) r++;
if (r!=strlen(password)) r=0;
if (!r) fake(); else doit();
return r;


Das ist nur ein einfaches Beispiel, wenn bits zusammengeklaubt werden 
usw, ist das noch viel kritischer, wie z.B. bei crypto-keys.

Man muß bedenken es wird ein Pic mit 1k oder 0.5k Speicher eingesetzt.
200 gehen mit dem Interfacing drauf, also bleiben ca 300 Instruktionen
uebrig, inkl jeglicher Tabelle.

Weiter oben im Thread, pic12f509 , pic12f508 (von anderen quelle).

Prozessoren haben meist während jedem Befehl eine andere Stromaufnahme. 
Das kann man Auswerten.

Strohm/Spannungsmessungen.
Generell wird 12bit gebraucht, ev mit 1kohm wiederstand geht auch 
weniger.
Es wird der Unterschied von guten und falschen Mustern ausgewertet.
So bekommt man z.B. mit, welche bits wohin gehören (scrambling), bevor
crc drankommt, sowie bekommt man eine Idee, wie kompliziert der 
Crypto-code ist und auch, ob eventuell verschiedene Bits abgearbeitet 
werden.

Z.B. muesste es problemlos feststellbar sein, ob 4 bytes gleichzeitig
mit demselben Alghorithmus (normaler blockcifer) abgearbeitet wird,
oder vielleicht was einfaches, einfach nur xor mit ein paar lookups.

Mal ein ganz einfacher vielleicht auch aussichtloser Ansatz ...

Der Dekoder IC ist ein PIC12F509, wieso laden wir uns die firmware nicht 
einfach herunter?

Gibt es eigentlich auch Log mit
Vorher -> Nachher

oder gibts nur die Rohdaten vonner Antenne?

Die Firma, die das Produkt auf den Mark gebracht hat, hat vermutlich 
diesen Thread angeschoben (der Threadstarter hat nur einen Beitrag 
geschrieben), um zu sehen wie sicher das Design ist.

Die Firma kann ganz beruhigt sein, in den Händen dieses Forums ist das 
Geheimnis gut geschützt.

Hmm, wenn es wirklich "nur" 14 bits wären, könnte man das sogar tun, 
würde dann wohl rund 12 Tage dauern.

MfG
Andreas

ne kleine Idee zur Ideensammlung: Von den Fuse-Bits hab ich nicht so den 
Peil - aber löschen lässt es sich anscheinend nicht so direkt. Kann man 
denn eine neue Firmware einspielen?

Wenn man später mal den Decoder-IC mal "nicht mehr sooo dirngend" 
braucht, vielleicht könnte man ja auch ein Proggi schreiben was uns die 
Daten aus dem EEPROM preisgibt, sodass wir anhand derer evtl die 
vermutete Decoder-Tabelle finden?

Zum vermuteten Zufallsgenerator: Ich gebe eine Kombi X rein und bekomme 
eine Kombi Y raus. Kombi X wieder rein, Kombi Y wieder als Ausgabe. Ist 
ja alles statisch - wozu benötige ich dann einen Zufallsgenerator?

cu,
olly...

Was mich wundert ist der Xor mit dem Ram in bank1.
Entweder ist das eine alte Kopie derselben Strings, oder
es gibt wirklich eine S-Box, oder eventuell mit alten Daten von 
vorherigen
decodierrunden (anderen Inputdaten), würde ich ev. machen.

Sollte ich eine möglichkeit finden, den chip zu patchen, würdest du das 
machen ?

Gibts eigentlich ne plausible Erklaerung dafuer das nur die ersten 40 
Woerter ausgelesen werden koennen? Das klingt fuer mich irgendwie sehr 
merkwuerdig, habe allerdings mit PICs nix zu tun.

Kannst du bitte ein 16F509 Sample von Microchip organisieren, sofern 
erhältlich, eventuell auch 2.

Das ist normal bei den 12er cores, das wird für Konfigurationsdaten 
genutzt, anstatt eines nicht vorhanden EEproms.
z.B. sensordaten eingelesen / gemessen und dann alten Konfiguration in 
ein NOP unwandeln, und neuen Wert einprogrammieren.

Ist das nicht illegal? Was würde passieren, wenn einer wirklick die 
Kodierung hackt?

ATxmega wrote:
> Ist das nicht illegal? Was würde passieren, wenn einer wirklick die
> Kodierung hackt?

Benutzen oder Verkaufen ist sicher illegal, Hacken ohne Veröffentlichung 
meines Wissens nicht.

Ich sag mal so: Die Kodierung benutzt eine Pearson-Hashfunktion...

ich weiss grad nicht wie ein Zufallsgenerator auszusehen hat, aber ist 
es vielleicht die lange Schleife am Anfang (~30 Sekunden), nach der man 
erst Zeichen sendne kann?

die Idee mit dem 40-Byte-Proggi gefällt mir... genial einfach!

cu,
olly...

abo

Gast wrote:
> Ich sag mal so: Die Kodierung benutzt eine Pearson-Hashfunktion...

Woher weißt du das?

Der 509 hat kein EEprom. Anstatt eines EEprom, können die 40 byte Flash 
auch nach der code-protection umprogrammiert werden.

Genau, das Ram ausgeben würde gehen, dazu braucht es jedoch einen 
externen uC, damit das Ding weiterhin funktioniert.
Was ev. auch gehen würde, ware den code um 8x zu beschleunigen.

Noch als Zusatz.
Entweder die Entwickler haben das mit den 40bytes übersehen,
hatten keinen Speicherplatz, daß sie gezwungen waren, es so zu tun,
oder das ist nur ein Fake.
Daß es ein Fake ist, bezweifle ich, da der Code handgeschrieben sowie
Speicherplatzoptimiert ist.
Mich verblüfft es eigentlich, daß die Entwickler sich so in die Karten
schauen lassen. Ich an ihrer Stelle hätte z.B. den Interfacecode in 
diesen
Bereich gestellt, sowie andere kleinigkeiten, welche A nicht wichtig 
bez. Cryptografie sind, B sowieso ersichtlich sind, wie z.B. serielle 
code-ein und Ausgabe, C den Code dazu getimed, sowie ev den Ram zuvor 
gesäubert,
daß RAM-auslesen nichts bringt.

>Ich konnte den bisherigen Antworten nicht genau entnehmen, ob es nun
>möglich ist, die ersten 40Bytes durch eigenen Code zu ersetzen oder
>nicht.
Es ist möglich, 1er bits durch 0er bits zu ersetzten.
Sprich Code Patchen, oder Konfigurationsdaten ersetzen oder einfügen,
sollte der Code das vorsehen. Ein NOP hat opcode 0, deswegen kann
ein wert durch ein Nop ersetzt werden, und ein Wert dahinter 
reingeschrieben werden. Z.B. ist es so möglich, Sensoren 
nachzuconfigurieren, Code auf verschieden Subsysteme anzupassen usw, 
ohne ein EEprom zu nehmen. Diese uC kosten ca 30-50 Cent schon in 
wenigen Stückzahlen.

>Falls ja, dann macht es für mich durchaus sinn, hier wichtigen Code
>hinzusetzen:
Falsch. Z.B. gibt der Code aufschluß auf die Zyklen sowie art der 
Verschlüsselung. Wenn nun z.B. gewisse bits gepatcht werden, und man 
vergleicht die Resultate, bekommt man unweigerlich dei 
Verschlüsselung/Schlüssel raus.

es sind nicht 40 Befehle, sondern 65 Befehle.

>Da der Watchdogtimer an ist, muss das ganze
>vermutlich auch noch in der gleichen Zeit passieren als beim
>Orginalcode.
WDT hat zimlich hohe tolleranzen,insgesamt eine Varianz von 27ms.
Zudem kann man den WDT problemlos abstellen.


>Wenn dagegen die IO Routinen an dieser stelle stehen würden, dann wäre
>es viel zu einfach diese so anzupassen, dass irgendwelche anderen RAM
>Inhalte ausgegeben werden.
Einfach Werte einlesen, verarbeiten, restliches RAM rücksetzen, Werte 
ausgeben. Ist nicht Sicherheitskritisch. Code-Teile des Algorithmus inkl 
Zyklen ist sehr kritisch, da es den Alg verrät, bez auch Angreifbar 
macht.

Mit dem Glitch, zuerst an Pic testen.
Bringe bitte in Erfahrung, welcher typ das ist, soweit möglich.
Es gibt meines Wissens 5 Revisionen des Chips, nicht A sowie 4 
verschiedene A versionen, A0-A3.
Bevor du das mit dem Glitch testen solltest, würde ich auch im Angesicht
der versch. Versionen einen Patch austesten.
Weiters wäre vorher zu ergründen, ob ev nicht doch eine recursive 
Verschlüsselung verwendet wird. Das sollte auf alle Fälle zuvor 
ausgetestet werden.

Warscheinlich ist es möglich, einen Patch zu schreiben, der einen 
Ram-Dump
nach jedem Befehl macht. Dazu bräuchte ich die genaue GPIO-zuordnung 
sowie
deren Funktion und ev. Mitschnitte wenn möglich.

Frage:
Soll ich diesen Weg weiter Verfolgen, nur SW support, habe keine HW.

>Frage:
>Soll ich diesen Weg weiter Verfolgen, nur SW support, habe keine HW.

Auf jeden Fall! Jeder kompetente Kommentar und das Fachwissen im 
Hintergrund sind hilfreich! Vielen Dank für deine Unterstützung!

Vermutlich ist das ein PIC den man nur einmal brennen kann!

Ja, das war ein Chip, der nur einmal programmiert werden kann.
Da er jedoch immer noch rasend Absatz findet, speziell der 12c505,
hat microchip ihn in neuerer Technologie neu aufgelegt, und daraus ist
die F(lash) variante gekommen, der dann auch noch zu allem Überfluß das
Debug-Silicon verpasst wurde sowie andere Kleinigkeiten. Also das
Config-Word hat noch andere Einstellungsmöglichkeiten.

Zurück zum DCF77, ich hätte dieses Wochenende Zeit, den Patch zu machen,
unter der Woche eher nicht. Dazu müßte ich aber verlässlicherweise die 
Beschaltung wissen.

Zum Code, das Xor an Stelle 0 ist ein Platzhalter für ein Goto/Call,
das ev. zusätzliche Features bereitstellt, umschaltet, oder eventuell
verschiedene Hw-interfaces, bereitstellt, oder auch z.B. den 
Alarmausgang
oder dergleichen handeln kann, jedenfalls in die Richtung. Anders ist
dieses Xor nicht zu erklären. Kann aber auch nur ein Bitset/clr sein.

Risiko beim Patch: Sollte der Code getimed sein, geht der Chip nicht 
mehr.
Getimed heißt, daß z.B. der Timer zu einem bestimmten Zeitpunkt 
initialisiert wird und dann zu fixen, also reproduzierbaren Zeiten 
dessen
Wert mit dem Key oder ev. Daten gexort oder addiert wird.
Wie seht ihr das ?

Da das hier sich sehr in die Länge ziehen wird, poste ich mal die 
Befehlsliste des pic´s. Da kann man dann sehen/nachschauen, daß man z.B.
aus einem RRF sehr schön ein movf sowie ein movwf machen kann, um Ram 
auszugeben.  Man kann lediglich 1er in 0er verwandeln, nicht umgekehrt.

f=file_register, l=literal, d=direction (f=1 / W=0), b=bit, a=address

 xorlw  1111 llll llll
 andlw  1110 llll llll
 goto  110a aaaa aaaa
 call  1001 aaaa aaaa
 iorlw  1100 llll llll
 movlw  1100 llll llll
 retlw  1000 llll llll
 btfsc  0110 bbbf ffff
 btfss  0111 bbbf ffff
 incfsz  0011 11df ffff
 decfsz  0010 11df ffff
 incf  0010 10df ffff
 comf  0010 01df ffff
 movf  0010 00df ffff
 rlf  0011 01df ffff
 rrf  0011 00df ffff
 swapf  0011 10df ffff
 bcf  0010 bbbf ffff
 bsf  0011 bbbf ffff
 xorwf  0001 10df ffff
 addwf  0001 11df ffff
 andwf  0001 01df ffff
 iorwf  0001 00df ffff
 subwf  0000 10df ffff
 movwf  0000 001f ffff
 decf  0000 11df ffff
 clrf  0000 011f ffff
 clrw  0000 0100 0000
 clrwdt  0000 0000 0100
 sleep  0000 0000 0011
 option  0000 0000 0010
 tris  0000 0000 0fff
 nop  0000 0000 0000

Seid ihr sicher dass es sich um einen PIC12F5xx handelt und nicht um 
einen PIC12C...?

Wenn es nämlich der C ist ist es ein nur einmal programmierbarer IC ...

Wäre eigentlich sinnvoll beim Produktionseinsatz da diese One Time 
Programmable Controllers viel günstiger sind als die Löschbaren!

@Cagara
Ja, den C type gibt es nähmlich nicht mehr, und hat es auch nie im
150 mil soic Gehäuse gegeben, nur im viel breiteren.

Auch wenn es der C type wäre, die Sache wäre identisch, da auch dieser
gepatcht würde. Partielles FW-Löschen geht halt nicht.

@Walter Freywald
Patch:
es geht hier um den Code nach dem Reset.
Wenn hier eine Routine eingeschleußt werden könnte, welche den Ram 
ausliest, sowie den Ram modifizieren kann, dann wären 2 Sachen möglich.
1) Die orginal Routine mittels externem uC simulieren
2) Ram ausgeben.

Stell dir weiters vor, daß der externe uC die Resetleitung kontrolliert.
Somit wäre es möglich, nach jedem Befehl einen Dump des Ram-Inhaltes
zu bekommen, da der Ram ja bei einem Reset nicht verändert wird.

Um das zu bewerkstelligen, muß warscheinlich das movlw von pos 3 durch
ein NOP ersetzt werden, um so an 64 Runden zu kommen, 4 sind
warscheinlich zuwenig. Das heißt auch, wenn der code getimed ist, sprich
der Inhalt des Timers0 in die Codierung einfließt, die Sache nicht 
funktioniert. Das ist unwarscheinlich, aber möglich, zudem der Timer
warscheinlich nicht genutzt wird. Das ist das Risiko.
Ansonsten, wenn man den Ram-Inhalt herausbekommt, nach jedem Befehl,
ist es leicht, den Code zu Knacken. Warscheinlich werden die RRF in
movwf und movfw umgewandelt, um den Inhalt des Rams rauszubekommen.
Wie genau das geht, muß ich mir noch überlegen, da auch die 
Portinitialisierung (tris) gemacht werden muß, sowie input und output
der variablen, die der Code normalerweise macht, damit das Ganze trotz 
patch funktioniert, mittels externem uC.

Revision:
Date-Code und nachfragen/nachschauen. Ev Datum von Error-sheets usw 
lesen.

Hallo, ich noch mal,

im Link unten versucht gerade jmd die Löschroutine aufzurufen, dann den 
Chip während des Löschens mit "Unterspannung" zu versorgen, damit das 
Löschen nimmer funktioniert um direkt nach dem Löschen die Spannung 
wieder zu normalisieren und die LOCK- oder FUSE-Bits zu verändern. Auch 
ein sehr interessanter Ansatz.

Allerdings hab ich was von 32 kHz gelesen, was schnell zum Timen wann 
die Spannung wieder erhöht werden muss, oder?

Beitrag "PIC code protection gesetzt! Muss man den PIC erst löschen, oder kann man direkt überschreiben?"

cu,
olly...

Ja, das geht, wurde früher auch gemacht, was Daniel schriebt, jedoch
das sind neuauflagen. Mehr als 64 bytes kann man ohne Microprobing nicht
auslesen. Microchip hat einen Designfehler gemacht, demnach Microprobing 
problemlos geht, aber das ist ein anderes Thema.
Wenn du dir das Hex ansiehst, sind da nur 0x40 words oder 64 words 
ausgelesen,
wobei je 12bit in 16bit reingepackt wurden, weshalb das dann auch die 
addresse
0x80 vorkommt, danach ist Schluß, wie man auch dem Datasheet entnehmen 
kann,
daß die restlichen Code-Words lediglich als 0x00 ausgelesen werden, wenn 
der
Copierschutz an ist.

Ps.
Daniel, deine infos sind falsch, aber im Prinzip ist es richtig, was du 
sagst.

@Walter Freywald

wäre es möglich, den NC Pin genauer zu untersuchen.
Laut Datenblatt hat er keinen pull-up, somit kann/darf er nicht NC sein.
Ändert sich da was, z.B. error_correction_aktiv, wenn man den anderst 
beschaltet.

@Walter Freywald

wäre es möglich, den NC Pin genauer zu untersuchen.
Laut Datenblatt hat er keinen pull-up, somit kann/darf er nicht NC sein.
Ändert sich da was, z.B. error_correction_aktiv, wenn man den anderst 
beschaltet.

Im Prinzip braucht man sowieso einen uC, am besten einen Pic,
welcher mit 16Mhz oder 20Mhz getakted wird, sowie alle Pins an den 
targed pic
angeschlossen hat. Weiters wäre rs232 nicht schlecht, sowie wenn die 
pins der
Uhr an denselben angeschlossen wären. Was hast du da ? Man kann auch 
einen
AVR nehmen, nur da bin ich in ASM wegen Timinggenauen Abfragen nicht 
fit.

die 2.3 Sekunden nominelle Zeit passen zum WDT. Es ist kein 1:8 teiler,
sondern ein 8bit prescaler, wobei der 3bit einfach der Index eines 
Multiplexers ist, welcher die verschiedenen bits des 8bit prescalers
durchschalten. 111 ist als 18ms x 128 = 2.3 sek.

Welche Ströhme misst du eigentlich. Sleep modus braucht nur uA, der rest 
mA.

wenn ich mir den Code anschaue, komme ich auf ca 245 uS auführungzeit 
nur
in den ersten 64 Befehlen.

Ich möchte mangels PIC-Kenntnisse nochmal was zur Theorie beitragen. 
Vielleicht kann ich da etwas Übersicht und interessante Anhaltspunkte 
liefern:

1. Die Datenbits um die es hier im minütlichen DCF77 Uhrzeit-Telegramm 
geht, werden von einer externen Firma, nicht der PTB zur PTB 
angeliefert. Das klingt erstmal harmlos und uninteressant. Ich gehe 
darauf aber weiter unten weiter ein.

2. Die meisten hier werden wohl auch der Meinung sein, daß irgendeine 
uhrzeitabhängige Verschlüsselung stattfindet. Die aktuelle Uhrzeit ist 
sehr gut geeignet, weil sie:
2a. Immer nur einmal auftritt
2b. Sowieso übertragen wird, also keine extra Bandbreite brauch

3. Es scheint nach bisherigen Kenntnisstand wohl ein der billigsten 
Mikrocontroller für die Entschlüsselung verwendet zu werden. Vermutlich 
sind es mehrere Plattformen/Generationen von Chips evenutell 
unterschiedlicher Hersteller. Das läßt ein reiches Feld von Versuchen 
offen und das benutzte Feature-Set der beteiligten Controller kann nur 
die Schnittstelle derer aller Funktionalität sein!


Mengt man nun obige Punkte zusammen, dann fällt mir spontan ein:
Es ist für die externe Firma gar nicht sooooo einfach, die aktuelle 
Uhrzeit zur Verschlüsselung zu nutzen, weil:
4a. In der Uhrzeit Redundanzen vorhanden sind in Form von BCD-Kodierung, 
Paritätsbits (Die man nur zur Kontrolle oder Korrektur, aber nicht zur 
Schlüsselraumerweiterung (Kein weiterer Informationsinhalt möglich) 
nutzen kann), eventuell mehr.
4b. Die nächste_ Uhrzeit für das _nächste Telegramm nicht immer 
eindeutig a priori bestimmt werden kann. Man denke an Schaltsekunde und 
die Informationen in den zusätzlichen Statusbits wie "aktive Antenne, 
heute Alarmierungsbit für PTB-Mitarbeiter" usw. (Kenne die jetzt nicht 
alle auswändig). Soll sagen: Man wird nicht alle Zeitbits zur 
Verschlüsselung benutzen!! Ich schließe vor allem die Paritätsbits und 
sich nur langsam ändernde Stellen wie die Jahresdaten aus!
Fragt sich, wie die externe Firma mit der PTB datentechnisch verknüpft 
ist. Liefert die PTB eventuell die _nächste(n)_ Uhrzeit(en) an diese 
Firma per Datenleitung ab?? Das wäre für uns die schlechteste Annahme, 
da dann die Firma praktisch alle Datenbits für den Schlüssel benutzen 
kann.

In Anbetracht dessen, das der Mikrocontroller nicht sonderlich 
resourcenreich ist, würde ich daher trotzdem erstmal von einer relativ 
einfachen Verschlüsselung ausgehen.

Die Frage wäre also:
5. Welche Bits des Uhrzeitstrings werden wirklich benutzt?
6. Wie sind diese permutiert ("verwürfelt")?

Und ja, ich vermute momentan eine einfache XOR-Verknüpfung im Kern der 
Entschlüsselungsroutine. Mögen die Eingangsdaten zu dieser auch 
irgendwie 'asymmetriert' werden... z.B. durch eine einfach 
AND-Verknüpfung der Uhrzeitbits.


Ihr könnt nun gerne meckern, wie unsäglich stümperhaft mein Gesülze ist, 
aber laßt es euch mal durch den Kopf gehen! Und sei es nur als Anregung.


7. Zu guter Letzt möchte ich noch darauf hinweisen, daß vermutlich schon 
jetzt Mitarbeiter von HKW-Elektronik bzw. der Entwickler der Software 
hier mitlesen und eventuell sogar unter Pseudonym Fehlinformationen 
einschleusen...


Sonnigster Gruß -
Abdul

setze Schnittstelle => Schnittmenge!

Sorry

Ps, nach dem WDT ist ein 10uS langer DTR timer aktiv.

Abdul:
Gut, dann gehe doch bitte mal von dem ausgelesenen Xor-generator aus,
welcher einen 32bit Bereich, nähmlich die ersten 32 bits der 84 bit
Daten mittels Xor verknüpft. Dies könnte 64 mal wiederholt werden,
wobei dann allerdings noch Code vorhanden ist, der warscheinlich eine
Addition bzw Subtraktion beinhaltet.

Was natürlich auch sein könnte, als Seed könnten die 84 bit DCF
Signal genutzt werden, da der Seed komischerweise 84bits ist, welcher
auf  88 bits aufgeweitet wird.