mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Was ist aus dem Thread der MeteoData geworden?


Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: MagIO (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na ich weiß ja nicht ...
Wenn es um das knacken eines kommerziellen Datenstroms geht gibt es 
sicherlich rechtliche Probleme.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Timo Beil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zitat:
Hinweis: Die Wetterdaten werden über einen Dekodier-Chip (HKW581)
aus einer Wetterstation, angeschlossen über einen FTDI232BM an den 
Server, dekodiert!

Autor: Timo Beil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochwas:

Dazu ist auch dasda sehr interresant. 
http://imperia.mi-verlag.de/imperia/md/content/ai/...

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Timo S. (kaffeetas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was war denn der letzte Thread?

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, den hatte ich gefunden, der ist ja aber doch recht alt.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf Degen (rolfdegen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bitte in diesem Thread keine Schlüssel oder urheberrechtlich geschützten 
ROM-Dumps o.ä. hochladen, siehe 
Beitrag "Re: AVR: Wetterinformationen über DCF77".

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Anbei noch eine Aktualisierte Liste der Daten,

Gruß thomy_pc

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomy_pc,

kann es sein, dass Du die letzen beiden Bit in Deinen decodierten Daten 
abgeschnitten hast ?

Gruß,
Walter

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...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

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 "_"

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wilhelm Landberger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meteo-data ist doch ein Wetterdienstleister. Gehört diese Software zu 
dieser Firma? Wo kann man diese erwerben? Danke für Infos

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Furrer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ichhhhh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es schon neuigkeiten?

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: willy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ist doch witzlos wenn man netzwerk hat

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
wie darf es denn aussehen?
so wie in den Logdateien?
so wie in den geparsten zips?
Ich werd mein bestes tun,
Gruß
Thomas

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
vorher 2.5MB
HTTP/1.1 200 OK
Server: WeSeiKon 3, Version: 3.0.1.0
Date: Thu, 22 Apr 2010 07:56:46 GMT
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/plain; charset=utf-8
Connection: Close
Content-Length: 2585150


Nachher: ~240kb
HTTP/1.1 200 OK
Server: WeSeiKon 3, Version: 3.0.1.0
Date: Thu, 22 Apr 2010 07:55:44 GMT
X-AspNet-Version: 2.0.50727
Content-Encoding: gzip
Cache-Control: private
Content-Type: text/plain; charset=utf-8
Connection: Close
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

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm doch das Format in dem auch torrentfiles vorliegen: 
http://en.wikipedia.org/wiki/Bencode das ist recht einfach und 
universell.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Degen (rolfdegen)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf Degen (rolfdegen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum sind in deiner Datei eigentlich keine 480 Zeilen? 24h/60min*3

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm. Könnte sein.
Bau einfach passenden Code in deine Auswertung rein.

Du bist der Held!

Benutzt oder plant das jemanden zu nutzen?

Autor: Rolf Degen (rolfdegen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abdul K. schrieb:
> Benutzt oder plant das jemanden zu nutzen?

Zog ich mal in Erwägung ...
Nu nicht mehr.
:-/

Autor: Rolf Degen (rolfdegen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&f...
ebenso hier:
http://www.dcf77logs.de/logfiles.aspx?mode=sdimg&f...

Gruß
Thomas

Nachtrag:

Das war offenbar der erste Datensatz, wo es schon probleme gab:
0 00000000000000 001001 10000001 0001100 101001 111 00100 000010000  So, 25.04.10 18:01:00, SZ 
0 01000010100000 001001 01000001 0001100 101001 111 00100 000010000  So, 25.04.10 18:02:00, SZ 
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bisher hat sich noch niemand bei mir gemeldet

Gruß
Thomas

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm. Wie auch immer. Es ist eine gute Gelegenheit für die Dekodierer.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&f...

Gruß
Thomas

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ihr könnt es lassen, die scheinen Pleite zu sein....

http://www.intern.de/news/4194.html

Autor: egberto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok, war Quatsch, da gab es wohl mal eine Firma gleichen Namens.....

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die firma die hier die Wetterdaten bereitstellt heißt meteotime,
meteodata ist eine andere...

Gruß
Thomas

Autor: Deschutes (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klingt interessant! Na da werd ich gleich mal schauen.

Guten Rutsch! Die ersten Raketen gingen gerade weg...

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
<------------------------------
IN:  - Datenpaket 1.....................: 00110010101101
     - Datenpaket 2.....................: 01101101010010
     - Datenpaket 3.....................: 01001000000010
     - Minute...........................: 10011010      59
     - Stunde...........................: 11101000      17
     - Tag..............................: 10000100      21
     - Monat............................: 10000         01
     - Wochentag........................: 101            5
     - Jahr.............................: 10001000      11

OUT: - Tag..............................: 0000           0         0 - --
     - Nacht............................: 0000           0         0 - --
     - Wetterextreme....................: 0000           0        Keine
     - Niederschlagswahrscheinlichkeit..: 000            0        0%
     - Wetteranomalie...................: 0                       Nein
     - Temperatur.......................: 000000        0         <-21°C
     - Dekoderstatus....................: 10     
-------------------------------
Verschlüsselte Daten...: 0011001010110101101101010010010010000000101001101011101000100001001000010110001000
Dekodierte Daten.......: 000000000000000000000010
Uhrzeit................: 17:59
Region.................: 17:59 Region: 19 (Höchstwerte, 4. Tag)
                                       19 - D - Bremerhaven, Bremen (Nordseeküste)
                         
                                       
------------------------------>

Hier ist die Logdatei:
http://www.dcf77logs.de/ViewLog.aspx?mode=meteo&fi...
und die grafik zur logdatei, dort ist es sehr gut zu sehen:
http://www.dcf77logs.de/LFGraphic.aspx?mode=meteo&...

vielleicht hilft das ja bisschen beim entschlüsseln... leere datensätze

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
(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?

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aaaaa (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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/applic...
Seite 5

Autor: ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich schon jemand das hier angeschaut?

http://www.wetterdirekt.com

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh sry, das war auf folgende Datei bezogen mit den 010...

http://www.dcf77logs.de/ViewLog.aspx?mode=meteo&fi...


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.

Autor: huiuiuiuii (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sebastian

google übersetzung sagt: irgendein puzzle spiel bzw mathe rätsel

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: huiuiuiuii (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: huiuiuiuii (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man müsste nur Kunde bei dir werden;) Dann geht es:)

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!)

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,
Na endilch passier tmal wieder was ;)

Ich ahbe die ganzen Leeren wetterdaten hier einmal zusammengefasst:
http://www.dcf77logs.de/ViewLog.aspx?mode=specialm...

Sorry das es Fehler 500 gab, Mysql macht probleme..

Gruß Thomas

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: JDat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_Wett...

Patent Info kann auch hilfreich sein, auf Bits: 
http://www.mikrocontroller.net/articles/DCF77_Wett...

PS: Sorry, mit Google von meinem schlechten Englisch übersetzt.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leave it in english version. Most people can understand it successful.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 !

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Register kann sich doch aus dem Datenstrom des DCF synchronisieren.

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aaaaa (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter W. (Firma: Huddel und Brassel Ltd.) (jaffel) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Max (Gast)
>dann den gesperrten PIC genauso entsperren und auslesen -> fertig

Und mit dem ausgelesenen HEX stellst du dann genau was an ?

Autor: Gibts Ne (schneeblau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Max


ev. findet sich hier was oder wir fragen die mal lieb:P


http://www.flylogic.net/blog/

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ;-)

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter W. (Firma: Huddel und Brassel Ltd.) (jaffel) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit dem richtigen Debugger durchaus machbar. Bis auf textuelle Labels 
und Kommentare, ist das Programm dann wieder da.

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&...
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerd T. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Paritätsbit fließt nicht in die 80 Bit Eingangsdaten mit ein!
IN:  - Datenpaket 1.....................: 01100100010111 
     - Datenpaket 2.....................: 01101111101010 
     - Datenpaket 3.....................: 10010100010001 
     - Minute...........................: 01000000      02 // 8 Bit Minuten
     - Stunde...........................: 00000000      00 // 8 Bit Stunde
     - Tag..............................: 10011000      19 // 8 Bit Kalendertag
     - Monat............................: 00100         04 // 5 Bit Monat
     - Wochentag........................: 010            2 // 3 Bit, ergibt mit Monat 8 Bit
     - 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.

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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&...
Hier sind es 13 minuten:
http://www.dcf77logs.de/ViewLog.aspx?mode=special&...

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

Autor: 64er Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noch ein Link zum Thema Chip Gehäuse 
öffnen.http://cms.diodenring.de/en/electronic/mikrocontro...

Scheint nicht so ein abwägiger Weg zu sein.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
würde ich gerne ausprobieren - wo bekomme ich NHO3 mit 90% her ;-)

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur Not in der Apotheke.

Gruß
Thomas

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 64er Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Säure muss wasserfrei sein!

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Nachtrag:

Ich habe doch entschlossen den Link allen zur verfügung zu stellen,
http://www.dcf77logs.de/DecoderAccess.aspx

Gruß
Thomas

Autor: Alexander Schmidt (esko) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: eProfi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@chris,

könntest Du mir bitte den Patch zukommen lassen, hatte damals leider 
nicht geklappt. Würde damit gerne ein bisschen herumexperimentieren.

Danke.
Walter.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: ikorb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: temp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: aaaaa (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ?

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ;)

Autor: me (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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???

Autor: Peter W. (Firma: Huddel und Brassel Ltd.) (jaffel) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: eProfi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lehrmann Michael (ubimbo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: .?. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lehrmann Michael schrieb:
> Ihr kennt das ?

Witzbold!

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: No Body (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: Dirk W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)...

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ?

Autor: Lucky Luck (rantanplan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lucky Luck (rantanplan)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Anhang vergessen.

Autor: Gibts Ne (schneeblau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welche Frequenzen sind das denn?

Autor: Waldmeister (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> Welche Frequenzen sind das denn?
CPU-Takt? Der rennt mit max 800KHz (interner Osc), was auch die lange 
Verarbeitungszeit erklären könnte.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Es müsste sich um diese Frequenzne handeln:
http://inet4you.dyndns.org/inet2/index.php/amateur...

Gruß
Thomas

Autor: Gibts Ne (schneeblau)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meinte die Pagerfrequenzen...danke:)

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?)

Autor: uzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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 :-(

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ;-)

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
würde es helfen so einen Chip zu röntgen ?

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
würde mich aber nicht wundern, wenn es trotzdem ein 509er ist, zumal da 
auch ja hkw581 druf gedruckt

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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 ;-)

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rubbermaid (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@eProfi,
hkw581,
siehe angefügtes Foto

thomas

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja ich geh zum Kumpel dem Zahnarzt, leider bekommt er das 3D Röntgen 
erst im August.

Autor: Torsten W. (wirehead)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Chip kann allerdings dabei schaden nehmen, eine SD-karte mag 
zumindest kein Röntgenlicht.

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Torsten W. (wirehead)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: PG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://service.gmx.net/de/cgi/g.fcgi/mail/index?fo...

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
   3c       08       00       00       d4       06       00       00       19
00111100 00001000 00000000 00000000 11010100 00000110 00000000 00000000 00011001
 
Zu der Wertigkeit / Reihenfolge der Bits: 
Das erste Bit dürfte Wertigkeit 1 haben, da das Schieberegister rechts schiebt.
Kann aber auch sein, dass das Empfangsschiebregister links herum arbeitet und / oder die Bytes verdreht.

   00      3c      08      00      00      d4      06      00      00      19
00000000001111000000100000000000000000001101010000000110000000000000000000011001  links = Bit7
00000000001111000001000000000000000000000010101101000000000000000000000010011000  links = Bit0
01234567012345670123456701234012012345670123456701234567012345670123401201234567
0123456789abcd0123456789abcd0123456789abcd0123456701234567012345670123401201234567
111111111111112222222222222233333333333333mmmmmmm0ssssss00tttttt00mmmmmwttjjjjjjjj

Autor: Arno Nyhm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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).

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
00000000001111000001000000000000000000000010101101000000000000000000000010011000  links = Bit0
richtig:
00000000001111000001000000000000000000000010101101100000000000000000000010011000  links = Bit0

Bietet jemand auf die 330558388822 Wetterstation Meteotime weiß, Funk 
gesteuert mit?  Nicht dass wir uns gegenseitig hochbieten.

Autor: uzi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin Schwaikert (sirnails)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: P. Wassi (wassipaul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß :)

Autor: eProfi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: IchBins (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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&fi...
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.

Autor: IchBins (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: meinereiner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_Extraterre...

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@eProfi,

ich bastel noch ein meinem Programmer rum. Hab noch ein paar kleine 
Schwierigkeiten...bin aber dran.

Autor: Peter W. (Firma: Huddel und Brassel Ltd.) (jaffel) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter W. (Firma: Huddel und Brassel Ltd.) (jaffel) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerald *. (pyromane)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt/gab auch schon einige Kryptografieprojekte auf Boinc, siehe
http://de.wikipedia.org/wiki/Liste_der_Projekte_ve...

Aber man muss halt auch ein wenig "Werbung" für sein Projekt machen um 
aktive Teilnehmen zu bekommen...

Autor: eProfi (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@uzi, walter hat die 12 Bit durch, ohne ergebnis, siehe:
Beitrag "Re: Was ist aus dem Thread der MeteoData geworden?"

Autor: uzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Urk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ?

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas Berends schrieb:
> umal ich keinen
> blassen dunst von wsdl habe

Geht auch ohne Ahnung ;)
http://www.codeproject.com/KB/webservices/myservice.aspx

Autor: Micha (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Chip geht noch :)

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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).

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
soll heissen, der PIC12F509 im MSOP-Gehäuse passt.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wie kommt es dann zur Behauptung, es wäre ein 508 ?

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Abdul K. (ehydra) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha, danke. Und dann gibts noch den EMx. Bei dem wohl noch nichts 
ausgelesen wurde.

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter Freywald (mrhanky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In welcher Uhr ist denn so ein Klechs ?

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas Berends (t5b6_de) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: EM-Fan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: eProfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 .

Autor: Thomas Berends (t5b6_de)