Andreas Lang wrote:
> Pinbelegung steht im hier etliche Male verlinkten Datenblatt zum> Decoder.
...
Also die Datenblätter, die hier verlinkt waren, haben ein hübsches
Bildchen von einem 8-Pin SOIC, aber da stehen nur Nummern auf den Pinnen
und ein hübsch buntes Blockschaltbild. Aber keine Zuordnung der Pinne zu
den im Blockschaltbild genannten Signalen. DB 20DC-IC-deut.pdf heißt das
Doc dazu.
Im Datenblatt wird weiterhin auf Signale an X5 und M1 bezug genommen,
was aber mit den Ziffern 1..8 am IC nichts gemein hat.
Das witzige an dem Datenblatt ist, dass sie zu jedem Lizenzvertrag einen
Manuel liefern... Der arme Kerl.
Gruß, Ulrich
hmmm...blubb
stimmt auffallend.
Der Bus ist wohl irgendein SPI-Verschnitt.
Saftung sollte einfach zu finden sein, für den Rest gibt es auch nur
wenige möglichkeiten. Wenn man erst mal den Clock gefunden hat, sollte
der Rest simpel sein. Ich nehme mal an, dass der Master zuerst den
chiffrierten Kram reinblubbert und der Chip dann irgendwann mit dem
Statuspin mitteilt, dass er fertig ist. Dann wird vermutlich noch einmal
ein Transfer gestartet und der Master liest den Kram zurück.
Moin!
Dirk W. wrote:
> @No.1: Den Standort wird der Besitzer wohl selbst einstellen müssen.
Den Standort stellt der Besitzer selbst ein. Allerdings werden wohl
Daten für alle Regionen empfangen und die Standort-Einstellung wirkt
sich nur auf die Anzeige aus.
Leider habe ich keinen (bevorzugt mehrkanaligen) Datenlogger verfügbar,
sonst könnte ich mich da mal dranmachen.
Gruß, Didi
Da bin ich nochmal ...
Habe gerade gesehen, daß in dem METE-ON 3 eine Art
Programmierschnittstelle vorgesehen ist, die über einen kleinen Deckel
auf der Unterseite des Gerätes auch von außen zugänglich ist. Habe mal
zwei Bilder davon gemacht:
http://diet.gmxhome.de/pics/METE-ON3-Stecker1.jpghttp://diet.gmxhome.de/pics/METE-ON3-Stecker2.jpg
Die Pin-Bezeichnungen lauten VPP, DATA, GND, MODE und VDD. Kann sein,
daß man da drüber die Firmware updaten kann.
Außerdem noch ein Bild von der Platine samt Decoder-Chip (hinter dem
Elko):
http://diet.gmxhome.de/pics/METE-ON3-Platine.jpg
und eins vom DCF77-Empfänger:
http://diet.gmxhome.de/pics/METE-ON3-DCF77.jpg
Gruß, Didi
PS: Bilder übrigens sind mit einem Sony Ericsson P990i Smartphone im
Makro-Modus aufgenommen und von 1600x1200 auf 640x480 runtergerechnet.
Gut - die Schärfe (bzw. den Autofocus-Punkt) kann man noch optimieren,
aber ich bin so schon ganz begeistert ;-)
Schicke Fotos!
Kannst Du nicht mal versuchen, ein Foto möglichst senkrecht auf den
Decoder Chip zu machen. Aus dem Layout sollte sich doch wenigstens die
Pinbelegung teilweise ermitteln lassen. Nett ist doch, dass sie zur
Ankopplung von Debuggern und Logicanalyzern direkt Messpunkte vorgesehen
haben.
Das erleichtert die Arbeit doch ungemein :)
Gruß, Ulrich
Hallo Ulrich,
muß ich mal ausprobieren ein besseres Foto zu machen. Ist etwas
schwierig wegen der Kabel, die recht kurz sind. Bei Gelegenheit probier
ichs mal und bei Erfolg setze ich das Foto hier rein.
Gruß, Didi
Wetterstationen liefern beim Auslesen keine der
APRS-Protokoll-Spezifikation für Wettermeldungen entprechenden
Datenstrings. Insofern ist für die Darstellung in gängigen
APRS-Anwendungen (z.B. UI-View) oder auf dem TH-D7, TM-D700 eine
Umwandlung der Daten erforderlich.
Im stationären Betrieb kann eine entsprechende Umwandlung der Daten
durch das Programm "UI-Weather" erfolgen. Die hier fragliche
Wetterstation WS-2300 wird unterstützt. UI-Weather liest die Datei
"curdat.lst" des beigefügten Wetterprogrammes "HeavyWeather" aus und
generiert eine Datei "wx.txt". Hier findet sich der APRS-WX-String.
UI-View32 greift wiederum auf diese Datei zu und versendet entsprechende
Wetterbaken.
Problematisch ist der Betrieb hingegen, wenn ein Netzanschluss zur
Versorgung eines Notebooks nicht verfügbar ist. Hier greifen komerzielle
Hardwarelösungen wie "WX-Trak" von Byonics. Jedoch sind die
unterstützten Wetterstationen in Deutschland schwerlich zu erwerben.
Ziel ist es mithin, unter Verwendung der Wetterstation WS-2300 und eines
TNC, einen APRS -konformen Wetterstring zu erzeugen und als APRS-Bake
auszusenden. Der Teil-String soll im Bakentext wie folgt aussehen:
_202/000g000t071r000p000b10180h46
Im Beispiel entspricht "b10180" einem Luftruck von 1018.0 hpa.
Zusätzlich sollen außerdem im "Statusfeld" weitere telemtrische Daten
(z.B. Spannung, Helligkeit, etc.) übertragen werden.
Lösung:
Zur Lösung wurde von Joachim (DF4IAN) zunächst eine Platine für die
Hardware-Kopplung des Einganges an die Wetterstation WS-2300 erstellt.
Vermittels der WS.CON-Software (geschrieben mit Microchip MPLAB
C18-Compiler in C) werden die über die erste serielle Schnittstelle bei
der WS-2300 abgefragten Daten im integirierten PIC-18 F 252 verarbeitet.
Der PIC-18 F 252 beinhaltet 32kByte Flash-ROM, 1.5kByte RAM, 256Byte
EEPROM, AD-Wandler, Pulsweitenmodulator, serielle Schnittstellen, sowie
mehrere Zeitgeber. Der Software-Kern für die Abfrage der Wetterdaten der
WS-2300 besteht dabei in aus einer stark modifizerten Version von
Kenneth Lavrsen’s (OZ1IDD) open2300-Software.
Die Software von Joachim unterstützt in der aktuellen Version aber zudem
eine Analogwert-Aufbereitung mehrerer Kanäle, d.h es ist neben der
eigentlichen Konversion der Wetterdaten auch ein Übertragen von
Analogwerten wie z.B. U, I, Einstrahlleistung/m2, sowie uv-Strahlung
möglich.
Am Ausgang werden die softwaremäßig im APRS-Format aufbereiteten
Datenstrings, welche mit einem Zeitstempel der DCF-77 Uhr der
WS-2300versehen sind, über die zweite serielle Schnittstelle an den
Aux-Eingang des TNC 2 (mit UI-Digi 1.9 b3 Firmware) übergeben. Die Form
der APRS-Protokoll kompatiblen Strings und die Formatierung weiterer
telemetrischer Sensor-Daten im Statusfeld des APRS-Strings, läßt sich im
Parametriermodus flexibel über eine seriell verbundene Eingabeeinheit
gestalten.
In der aktuellen Version versteht Joachim das Modul ws.con, über die
ursprüngliche Aufgabenstellung hinaus, als flexiblen Technologieträger,
bei dem die unterschiedlichsten Eingangsdaten aufbereitet und in ein
beliebiges Übertragungsformat umgesetzt werden können.
Hallo,
ich habe was gefunden was vielleicht auch nützlich ist:
bei Conrad gibt es jetzt eine Uhr, die auch für 50 Regionen
Wettervorhersagen macht, allerdings soll die eine "satellitengestützte
Funkwetterstation" sein.
Ist da vielleicht auch so eine die über DCf die daten holt? Sie kostet
49€, für Experimente dann eigentlich eher erträglich als die
ELV-Variante.
luxx
I have collected the DCF77 data stream for some time and a brief
analysis of the new bits shows one + six correlations which give a
strong hint about the encoding:
Collect bits 1-14 of the DCF77 timegram for periods of three minutes at
a time and you get 42bit "meteotime" datagrams, ie: collect for minute
00-02, 03-05, 06-08, ...57-59.
In these 42 bits, the first bit and the eight bit are always zero.
Given their respective probabilities for being set, the second and ninth
bit are different 10% too often.
The same goes for 3rd+10th, 4th+11th, 5th+12th, 6th+13th, and 7th+14th.
It is not very often that all the first seven such pars are different,
but it happens, and some cases even look as suspicious as this one:
-######-------####----##-#--##-#--##---#--
The format documented in the pdf, will by nature of weather generally
being pleasant at this time of the year, be heavy on zeros in the front
end of the datagram, that could cause the above.
All this leads me to venture the guess that the datagrams are scrambled
with a seven bit tapped shift-register based scrambler.
The shift register is obviously preloaded with some "magic" content at
the start of each datagram, because otherwise the first N-ish bits would
leak through and they clearly don't.
The other thing is that there is no such correlation for bits outside
the first block of 14 bits of the 42 bit datagram, this could strongly
indicate that the entire sequence of DCF77 bits are run through the
scrambler, not just the meteotime bits.
The next logical step, is to get a "known plaintext". With an
"official" meteotime clock, it should be possible to "encode" the
displayed values into a datagram, and if we know when the display
updated, the immediately preceeding datagram is likely to be the one we
want.
XOR'ing the "known plaintext" against the received datagram should give
us the scrambler output for the 3 minute window, and a simple
brute-force attack should be able to uncover the taps on the
shiftregister and the value at the start of the 3 minute window.
Happy Hacking :-)
Poul-Henning
Hallo,
Es kommt hier in einigen Postings so rueber, als ob das hier gilt:
(1) Dinge wie CBC sind in diesem Szenario nicht anwendbar
=>
(2) Zu jedem Plaintext existiert GENAU NUR EIN Ciphertext.
(1) ist korrekt: CBC geht nicht, da die Empfaenger ja nicht synchron
starten und jederzeit aussetzen und wieder-einsteigen koennen muessen.
ABER
(2) ist falsch: Zum dem selben Plaintext koennten sehr wohl identische
Ciphertexte existieren. Und zwar ganz ganz simpel:
Cipher := SymmetricEncrypt(Masterkey, Wetter + Zufallsstring)
('+' bezeichne hier lediglch eine Bitstring-Aneinanderkettung.)
Somit gibt es zu zwei identischen Plaintexten (Wetterdaten) NIE der
selbe Cipher, weil sie mit unterschiedlichen Bits "gesalzen" sind!
Der Zufallsstring muss ja auch nicht besonders lang sein, um voellig
unterschiedliche Ciphers zu identischen Plains hervorzurufen.
(vorrausgesetzt der symetrische Verschluesselungsalgorithmus ist
halbwegs stark. Derartige Alorithmen sind allerdings auch durchaus auf
kleinerer Hardware lauffaehig).
Die Information, auf welchen Standort sich die Wetterdaten beziehen
muessen nicht verschluesselt gesendet werden (bei 14 CipherBits gilt es
ja alles einzusparen was geht), sie sind ja aus Stunde:Minute ableitbar.
Fazit: Wenn der Hersteller auch nur wenige "Salt"-Bits mit einstreut,
ist auch ein Known-Plaintext-Angriff sinnlos, und es laesst sich keine
Tabelle
"Ciphertext <-> Plaintext" aufzubauen!
Falls es so implementiert ist schliesst das leider natuerlich auch nicht
aus, dass zB Protokollbefehle der Art existieren, welche die Empfaenger
dazu veranlassen, auf einen neuen Masterkey umzuschalten, wenn der alte
kompromittiert ist.
Der neue Masterkey wuerde dann natuerlich nicht over air gehen, sondern
nur gesagt "nehmt den 2. Masterkey aus eurer internen,
werksseitig-initialisierten Tabelle".
Es bleibt natuerlich zu hoffen, dass das nicht so implementiert wurde
...
@Poul-Henning
hi Poul-Henning, i know you wrote CRC. CBC was mentioned above here in
#495856.
let's hope they encrypted the weather data using a shift register as you
estimate (or some similar security-by-obscurity stuff) - and not some
AES.
Wie steht's denn mittlerweile mit Mittschnitten von DCF, angezeigten,
und den zwischen den ICs ausgetauschten Daten?
Läßt sich vielleicht 'schon mal' die Zuordnung Region-Zeit ermitteln,
ohne daß die Kodierung bekannt ist?
Z.B.: Sendet der Host-Controller dem meteo-chip den eingestellten
Standort?
Woher bezieht meteotime die Wetterdaten / sind die übermittelten Daten
auf anderem Weg uz erhalten? (sind angezeigte Daten auf der Uhr
identisch zu einer Wetter-Seite im Netz?)
Sind die Uhren die ganze Zeit auf Empfang?
> Achtung: ist nur ca. 3 min aktiv
vs.
> ELV Uhr 24/7 auf Empfang ist
Ich bin wirklich gespannt, ob das zu knacken ist. Angesichts der
vorhergehenden Bemühungen der PTB und anderer, ein Warnsystem zu
implementieren (diese Informationen findet man eher, als etwas über den
Wetterdatendeal..) ist es unverhältnismäßig, daß man für den
Empfänger(bau) eine Lizenz kaufen muss, und das Geschäft ein Di-pol
(schweizer Unternehmer / HKW) ist.
Das ist vielleicht ja der Grund für den abrupten Abriss der Diskussion..
Schön wäre dann aber ein Hinweis aus dem Kreis der Eingeweihten.. Wenn
es nämlich möglich ist, würde ich es auch mal probieren.
Hallo!
Unter http://www.meteomarkt.ch/shop/catalog/index.php?cPath=2_16 gibt's
den Wecker für mittlerweile ca. 55 EUR - das ist schon eher ein Preis,
den ich mir vorstellen kann um ein "Referenzobjekt" zu erwerben.
Aber einen Haken gibt's: Versand nach .DE für 22,-- EUR - da stößt sich
wohl die schweizer Post an den dt. Kunden gesund :-(
Gut dass ich diesen Thread gefunden habe!
Hier in Mainz gibt es seit einigen Monaten mit der großen Bahnhofsuhr am
Bahnhofsgebäude. So wie es aussieht, lässt diese sich auch durch die
Meteotime-Daten aus dem Tritt bringen. Fakt ist, dass sie nach einem
Neueinschalten der Stromversorgung immer ein paar Tage läuft, bis wohl
in den Bits 1-14 ein so unglückliches Muster auftritt, das sie aus dem
Takt bringt. Dann bleibt sie einfach stehen.
Der Betreiber der Uhr, die Firma Hevert Arzneimittel (die Uhr gehört
eigentlich zu einer Leuchtreklame) hat bereits mehrfach Techniker kommen
lassen, die die Uhr überprüft haben, aber keinen Fehler gefunden haben
(wie auch - das Uhrwerk ist in Ordnung). Sie haben dann immer die
Stromversorgung unterbrochen und neu eingeschaltet, woraufhin die Uhr
wieder ca. 1 Tag lief (ist sowas wie ein "Stadtgespräch" in Mainz,
mittlerweile ist es schon fast eine fortlaufende Story in der
Tageszeitung ;)
Nun, jedenfalls hat mich dieser Thread darauf gebracht, dass es
vielleicht was mit diesen Meteo-Daten zu tun hat (vllt. wartet die uhr
nicht brav 14 Sekunden, sondern interpretiert das erste Bit was 1 ist
als erstes Datenbit oder so). Ich werde jedenfalls mal die Firma Hevert
darauf hinweisen, ich weiß nicht ob die das mit dem Meteotime schon
wissen. Vielleicht kann man der Uhr ja eine neue Firmware verpassen oder
auch den DCF-Dekoder austauschen.
Diese Bahnhofsuhr war in den letzten Jahren morgens meine zuverlässigste
Zeitquelle... ;)
Gruß Fabian
Stehe ich jetzt komplett auf dem Schlauch? Soll das Problem tatsächlich
an den Meteo Daten liegen?
Wie werden DCF-Dekoder ohne µC gebaut? Mit Schieberegister und solchen
Sachen? Gibt es da eine technischen Grund die ersten 14 bits als "0"
anzunehmen und dann ab dem 15. zu dekodieren?
Wenn nicht: Stümper!
Ich glaube auch, dass die "Programmierer" (Entwickler, Hersteller)
dieser Bahnhofsuhr stümperhaft gearbeitet haben.
Aber die Wetterdaten sind ja jetzt erstmal da, also muss an der Uhr
irgendwas geändert werden. Neuer Chip oder was auch immer, jedenfalls
finde ich die Erklärung gar nicht so unplausibel dass es irgendwas mit
den Meteodaten zu tun hat. Schließlich trat das erste Problem mit der
Uhr genau dann auf, nachdem die Firma Meteotime diese 14 Bit "gekauft"
hat...
Ich habe mal die zwei Tage lang geloggten Daten
(dcf_log_2Tage_59Ticks.txt)
so umgewandelt dass in einer Zeile immer die zusammengehörenden 3
Minuten stehen. Vielleicht hilft das beim Entschlüsseln.
Hallo Gemeinde,
ich möchte nur etwas hinzufügen. Nach Poul-Henning Kamp (Gast)
Datum: 15.04.2007 15:17 ist jedes erste und achte Bit des ersten 14 Bit
Satzes gleich 0. Es geht bei Minute 1 los und stellt sicherlich den Kopf
dar.
Wenn das erste und achte Bit null sein soll, dann habe ich das oben
falsch zusammengesetzt. Ich hätte um 00:01 Uhr anfangen müssen. Hier ist
nochmal die richtige Version.
Ich habe mir nochmal den Beitrag von Poul-Henning Kamp durchgelesen.
Ich finde wir sollten so vorgehen wie er es beschreibt. Einmal mit einer
Meteo-Uhr die abgelesenen Daten in Bits mithilfe des PDFs von Meteotime
umwandeln. Dabei die Uhrzeit des Datenempfangs der eingestellten Region
rausfinden. Dann die mitgeloggten DCF-Daten für diese Uhrzeit mit den
Klartextdaten vergleichen und dabei den verwendeten
Schieberegister-Algorithmus ermitteln und den Initwert bestimmen.
Oder man macht es einfacher und wartet bis irgendeiner von euch mit den
Entschlüsselungs-ICs was rausfindet.
Hi codebreakers,
Here are some infos abut the "dechiffrier-IC", discovered with an IROX
Mete-On 3 hooked to a logger.
Without the details on the hardware, lets see the structure of
communication:
MO3 -> DCIC (82 bits at all):
-----------------------------
0-13 (14) - first data packet (minute 1, 4, 7...)
14-27 (14) - second data packet (minute 2, 5, 8...)
28-41 (14) - third data packet (minute 3, 6, 9...)
42-49 (8) - minute (bcd)
50-57 (8) - hour (bcd)
58-65 (8) - day (bcd)
66-70 (5) - month (bcd)
71-73 (3) - weekday (bcd)
74-81 (8) - year (bcd)
Time data is the actual time. The decoding begins immediately after the
last bit of the third packet received, so this is the time with the
second packet transmitted.
DCIC -> MO3 (24 bits at all):
-----------------------------
0-21 - plain weather data (as described in "DB W-Protokoll-V 1.pdf",
with a minor difference described below)
22-23 - unknown, most of the time (99%) '10', sometimes '11'
The temperature and rain data shown on the MO3 display matches exactly
to the logged data decoded with the protocol in the pdf file.
The weather icon data is decoded as follows:
transmitted - shown
1 - 1
2 - 2
3 - 3
4 - not discovered yet
5 - 11
6 - 9
7 - not discovered yet
8 - not discovered yet
9 - not discovered yet
10 - 7
11 - 8
12 - not discovered yet
13 - 10
14 - not discovered yet
15 - not discovered yet
Other data can't be verified with the MO3, because it can display
weather icon, temperature and rain forecast data only, and only for the
actual day and night.
Attached You will find a log parsed with the infos above, it will make
clear this mess.
Happy hacking,
Dexter
Hi
Ich bin neu hier.
Tag zusammen .
Das Thema interessiert mich brennend.
Vieleicht könnt ihr mit dieser Info was anfangen.
***********************************************************
Zeit (UTC): Prognose:
22:00 - 03:59 Aktueller / kommender Tag (TODAY im Display)
04:00 - 09:59 Folgender Tag (DAY 1 im Display)
10:00 - 15:59 Darauffolgender Tag (DAY 2 im Display)
16:00 - 18:59 Darauffolgender Tag (DAY 3 im Display)
19:00 - 21:59 30 Zusatzregionen mit 2-Tages-Prognose
***********************************************************
Quelle:
http://www.wetterstationen.info/mete-on-1.php
Karl
Zunächst einmal: Klasse, dass jemand am IC mitgelogged hat.
Das ist sicher schon mal ein Schritt in die richtige Richtung.
Leider gelingt es mir nicht weitere Regelmässigkeiten zu finden.
Die Idee der XOR-Verknüpfung mit dem Ausgang eines rückgekoppelten
Schieberegisters kann man allerdings in der einfachen Form
ausschliessen:
es gibt Datensätze die decodiert identisch sind. Wenn man jeweils zwei
solche nimmt sollten die Eingangsdaten für diese XOR verknüpft
Rückschlüsse auf das Schieberegister zulassen. Dazu passen die Daten
aber nicht (oder das Schieberegister ist länger als 16 bits)
Deutlich mehr Eingangsdaten könnten ein wenig helfen.
Viel wichtiger wäre aber, dass jemand mal untersucht, wie das IC
bei veränderten Eingangsdaten reagiert. Dafür ist es nötig,
dass jemand das IC entsprechend mit modifizierten Daten ansteuert.
Damit könnte man die folgenden Fragen klären:
Es gibt 82 Eingangsbits mit bis zu 42 frei wählbaren Datenbits.
Am Ausgang sind es aber nur 24 bits. Wozu dienen die restlichen bits?
a) Fehlerkorrektur b) zusätzliche Steuerdaten c) Zufallsdaten
Dazu sollte man jeweils ein Eingangs-bit ändern: wieviele/welche bits
ändern sich in den Ausgangsdaten?
Wenn sich bei einem bit noch nichts ändert, gibt es eindeutig einen
Fehlerschutz für die Daten. Dann sollte man weitere bits ändern und das
mapping vom Eingang auf den Ausgang feststellen.
Gibt es eine Abhängigkeit von vorausgegangenen Daten oder ist jeder
3-Minuten Abschnitt einzeln decodierbar?
Dazu sollte man die Reihenfolge der Eingangsdaten verändern und
beobachten,
ob sich das auf das Decodierergebnis auswirkt.
Ein letzter Kommentar:
Aktuell gibt es widersprüchliche Angaben dazu, wann die Daten für eine
bestimmte Region übertragen werden:
Dexter:
00:00 - 02:59 Today-Day
03:00 - 05:59 Today-Night
http://www.wetterstationen.info/mete-on-1.php :
22:00 - 03:59 Aktueller / kommender Tag (TODAY im Display)
welche sind nun die richtigen, bzw. was ist die Quelle für die Angaben
von Dexter?
Hi "noch einer Gast",
I am working now on this "data altering project": A microcontroller will
emulate the DCIC for the MO3 to send different plaintexts to discover
some weather icon codes not seen yet. The same controller will also hook
the DCIC to a PC to test different input streams:
- already received (and known as good) packets with some bits altered to
test the error detection/correction,
- simple test packets (all zeros, all ones, etc...) to analyze the
coding scheme.
The logs will be available soon(?)... :)
And the time problem:
Both times are the same, therefore right, because 22:00 - 03:59 is in
UTC. Our local time (transmitted by DCF77) is UTC+2: one hour + is the
time zone, and the another one is "daylight saving time" used in summer.
The log shows practically the local time.
Happy hackning,
Dexter
PS: Sorry for the bad english, but my deutsch is even worse, close to
nothing... :(
Hi
Möglicher Lösungsansatz : ! ?
Die Signale von der "Antenne" (Simulierte Teildaten) an ein
Anzeigegerät senden. (Z.B. nur 3 x 14 Bit alle 3 Miuten und sonst
KEINE Daten mehr.
Beabbachten was die Anzeige macht ! ?
Nur mal so mein Gedanke.
P.S. Manchmal findet auch ein Blindes Huhn ein Korn.
Vielleicht hilft es euch, ansonsten dschnell wieder vergessen.
Hallo Jungs !
Lasst uns ein Wettercode Buch erbeuten und nichts wie ab nach Bletchley.
kleiner Spass.
Aber vom Prinzip her war England im 2.WK trotz des besitzes einiger
Enigmas
nicht in der Lage ohne erbeutete Unterlagen mitzulesen.
dh. der Algor. war bekannt ,doch der war nutzlos ohne die Tages-
schlüssel.
Das Problem ist ähnlich hier:
Ich denke auch nicht ,das Keys über die Luft übetragen werden.
Die Masse an Intelligenz sitzt im IC.
Grundsätzlich muss man erstmal rausfinden ob jeweils der selbe
Input auch immer den selben Output erzeugt (an verschiedenen Uhrzeiten)
Dazu wird man wohl eien DCF77 Geber aufbauen müssen .(AVR)
Geber mit den Logfiles füttern und guggen was passiert.
Jetzt kann man das Logfile verändern und schaun.
und so weiter
Ich mach mit.
Gruss Andreas
Nur so mal gefragt: Hat sich das niemand patentieren lassen ? Wenn ja,
muß doch in der Patentschrift stehen, wie die ganze Sache funktioniert
oder kann man soetwas als Firma einfach 'geheim' halten ?
Selbstverständlich, kann eine Firma ein "Betriebsgeheimnis" haben, z.B.
Cola Rezept, der rühmliche "09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88
C0" key, auch glaub ich nicht das die Zusammensetzung von Chanel No.5
irgendwo in einem Patent steht.
War jetzt der eigentlichen Sache nicht sonderlich dienlich, aber ich
finds irrsinnig spannend, hoffentlich knackt ihr das. ;) -wiebel
Hi
Face --> Bringt uns NICHT weiter.
Habt ihr eine "Uhr" , bei der mann Informatieonen auslesen kann.
Ich denke so an ein Uhrmodul, das damals Conrad-Elektronik für ca. 10
Euro hatte.
Da der Link nicht funktioniert, kann ich nicht schauen, was für ein
Modul es ist (nächstes Mal bitte einfach die Bestellnummer posten) aber
die Wetterbits empfängt prinzipiell jeder DCF77-Empfänger. Das Problem
ist aber nicht das Empfangen, sondern das dekodieren der
Wetterinformation.
Hallo
Habe mir aus nem AVR ne Uhr gebaut.
Wo liegen genau die Wetterbits?
von Sekunde Anfang 01 bis Ende 14 oder schon von Sekunde 00-14.
Gruss Andreas
> Wo liegen genau die Wetterbits?> von Sekunde Anfang 01 bis Ende 14 oder schon von Sekunde 00-14.
Kennst du http://www.dcf77.com/deutsch/kodierung.htm ?
Es müssten die ersten 14 Bit nach der Minutenmarke sein...
Nur zur Info:
Hier in Hessen ist eine Meteotime Uhr im Real Prospekt vom Wochenende
aufgetaucht. 59€ soll das Teil kosten, dass auch ein Meteotime Logo
trägt. Ist zwar nicht so schick, wie das große Vorbild aus der Schweitz,
abere dafür auch erheblich leichter zu bekommen. Kann man nur hoffen,
dass es auch mit dem fragwürdiegn Chip bestückt ist und dieser nicht
bereits integriert wurde.
Gruß, Ulrich
> Hier in Hessen ist eine Meteotime Uhr im Real Prospekt vom Wochenende> aufgetaucht. 59€ soll das Teil kosten, dass auch ein Meteotime Logo> trägt.
Daten gibt's hier:
http://tinyurl.com/38e5w8
Hallo
Habe mal bei Dexters Text Datei gleiche Outputs gesuchtund habe
festgestellt das nichtmal Ansatzweise die Inputs übereinstimmen.
Das wird wohl schwierig
Mfg Andreas
aber dann müsste man ja wenn man in den chip "falsche" daten
reinschiebtm also immer gleiche uhrzeit etc auch immer das gleiche
rausbekommen?! dann würde man sehen obs so ist oder nicht
@Luxx:
> aber dann müsste man ja wenn man in den chip "falsche" daten> reinschiebtm also immer gleiche uhrzeit etc auch immer das gleiche> rausbekommen?! dann würde man sehen obs so ist oder nicht
Dexter hat geschrieben, dass er's ausprobieren möchte.
@Mobifu:
> Kennt ihr das Cryptool 1.4.10
Ist das ein hint? Leider hab' ich das falsche OS installiert :-(
Das Cryptool befördert erstaunliches zu Tage.
Wenn man die Autokorrelations Funktion über einen Mitschnitt
laufen lässt der keine Uhrzeit enthält also nur die 42 Bits von ein paar
Stunden.
dann gibt es eine Periodizität mit schlüssellänge 1 ??????
Schlüssel 30 Hex
schaut mal selber .
gruss Andreas
Hi
>dann gibt es eine Periodizität mit schlüssellänge 1 ??????>Schlüssel 30 Hex
Äh, kannst du das näher erklären!
Heißt das Input + Hex 30 (-30H) ?
>schaut mal selber .
Wo ?
Fehlt da zur Vollständigkeit, und um es auch ohne Cryptool
nachvollziehen zu können, nicht noch die Information welches der 42
Input-Bits zu welchem de 24 Output-Bits gehört? Denn bei einem einfachen
XOR müßten ja input und output gleich lang sein.
Das sind doch nur statistische Betrachtungen im Bitmuster und keine
Dekodierung der Inputs. z.B tauchen in der Autokorr. Fkt. 3 Spitzen
im Abstand von 42 Bits auf. Komisch ? 1 und 8 Bit ist klar aber das
dritte?
Mfg Andreas
Ich will ja keinen entmutigen, aber die Dateien mit den Daten in ASCII
Darstellung in ein Tool zu laden und auf Wunder zu hoffen
wird wohl wenig bringen.
Bisher kommt ja auch nur das heraus was vorher schon bekannt war:
-Die verschlüsselten Daten sind 42 bit lang
-Davon sind 2 bits mit Abstand 7 konstant 0
Daraus folgt, dass die Autokorrelationsfunktion periodische hohe Peaks
im Abstand von 42 bekommt und nochmal etwa halb so hohe im Abstand von
+/-7 um die hohen Peaks herum. (daher also 3 Peaks)
Die Vigenère Analyse spricht einfach auf diese periodische Wiederholung
an. Und solange man Vigenère nur auf '0' und '1' anwendet, bleibt das
sowieso eine einfache XOR Verknüpfung. Man müsste erstmal überlegen,
wieviele bits zu einem Symbol zusammengehören, bevor das sinnvoll
anwendbar wird.
Die oben erwähnten 0x30 als XOR Schlüssel ergeben sich wohl einfach
daraus, dass '0'=0x30 das häufigste Zeichen ist, wenn man die Daten als
ASCII '0' und '1' darstellt.
Trotzdem gibt es in den ersten 14 bit noch mehr Regelmässigkeiten als
nur die beiden Werte, die konstant 0 sind. Das lässt zumindest darauf
schliessen, dass nicht alle bits perfekt verschlüsselte Daten sind.
Zum anderen läst sich nur mit den Daten aus Dexters Datei 20070716.txt
einen Analyse durchführen. Denn dort sind Cyphertext und entsprechender
Klartext vorhanden.
Aber ich würde mal abwarten bis Dexter den Dekoder-IC mit eigenen Daten
gefüttert hat. Besonderst das Ergebniss von speziellen Bitmustern wie
alles 0 und alles 1 usw. wäre hier interessant.
noch ein paar konstruktive Informationen:
Zu dem Thema gibt es zwei passende Patente bzw. Gebrauchsmuster:
DE 20 2006 017 739 U1
"Einrichtung zum Empfang verschlüsselter Informationen"
-Schlüssel wird nicht übertragen, sondern aus der Uhrzeit abgeleitet
-Beispiel: AES Verschlüsselung
-Daten und Schlüssel können bis zur Blocklänge aufgefüllt werden
-beliebige Operationen können auf die Zeitdaten angewendet werden, um
den Schlüssel zu erzeugen
DE 20 2005 019 853.6 / EP 1798612
"Datenübertragungen in langsamen Übertragungssystemen, wie durch
Zeitzeichensender"
22 Nutzbits + 20 Prüfbits = 42 bits
Übertragung in 3 Minuten
Minute n : 14 Nutzbits
Minute n+1: 8 Nutzbits + 6 Prüfbits
Minute n+2: 14 Prüfbits
Die genauere Nutzung der 22 Nutzbits zu den verschiedenen Tageszeiten
ist auch beschrieben.
Die oben beschriebene Aufteilung der Nutz und Prüfbits auf die Minuten
kann ich allerdings in den Daten bisher nicht finden.
Es würde wirklich sehr helfen, wenn jemand das IC mal mit modifizierten
Eingangsdaten füttern könnte, und die Ergebnisse berichten würde...
http://www.zorc.breitbandkatze.de/crc.html
habe ich gefunden .
wenn man bischen mit spielt könnte man vermuten die ersten acht bits
gehören zu einem CrC
meine Einst. CRC Order 8/CRC Poly 4/nächsten beiden 0.
Data länge 34/ sodas der enstehende voran gestellte Rest
vorne und hinten immer eine Null enthält.
mfg Andreas
> -Schlüssel wird nicht übertragen, sondern aus der Uhrzeit abgeleitet> -Beispiel: AES Verschlüsselung
Das kann man doch sicherlich ausschließen. Dann sollten die Daten doch
etwas mehr "rauschen" und nicht so systematisch sein, wie bereits in
anderen Postings gezeigt wurde...
Hi codebreakers,
I have done more tests with DCIC. It was feed with a data packet from an
early log, but some bits were altered to test error correction. The
results are the following:
- First of all, the meaning of the last two (22 and 23) bits of the
output data is now clear:
00 - decoding failed
10 - decoding passed
11 - decoding passed, but error correction was made
- Any single bit error in the time data used as key (bits 42 to 81 of
the input) makes the decoding impossible.
- Any single bit error in the cipher text (bits 0 to 41 of the input)
will be detected, corrected and signed in the output by DCIC.
- Double bit errors in the cipher text make the decoding impossible.
- The 0. and 7 . bits of the input data, which are always '0', are
treated a little different: One or both of them can be inverted, the
DCIC does not care about it and will decode the packet without the sign
"error correction was made". But if these don't care bits (one or both
of them) are changed with any other bit, then the DCIC will treat this
as double bit error, and will not decode the packet.
- If the decoding fails, then the output will show a fixed value of
<1000000000000000000001 00> regardless of the input, so there isn't any
chance to test the structure of the cipher algorithm with different
tricky inputs.
Happy hacking,
Dexter
> So there isn't any chance to test the structure of the cipher algorithm> with different tricky inputs.
Is there any speed limit?
So you may input a fixed time and fuzz around the weather bits -
brute-force checking for valid data.
As we know all three parts:
key: time
decoded: weather data
encoded: on air transmitted data
there must be a chance.
May be one should ask in sci.crypt for help...
With 22 data bits + 20 bits redundancy and single bit error correction:
for every valid data word there are 42 additional ones that would be
decoded with the same result (plus error correction indication).
If you just chose random data you should have a correct data word
on average every 2^20 tries i.e. one out of one Million.
If you also take the corrected into account that would be one out of
~ 25.000 tries.
Normal use could require:
5 cities 4 days 2 (day+night) = 40 decoding actions per day.
So to get one hit you would have on average an load of the decoder
equivalent to 600 days of usage. With an increased speed at least one
test every 3 seconds should be feasible.
The 3 seconds is just the value from the decoder datasheet.
This would give a hit on average every 21 hours. It would be interesting
to hear which speed can be obtained in reality.
The good news: the PIC 12F509 (this is at least the decoder
in the Mebus version of the device) to my understanding
does not have any means to permanently store any information.
There is only the program EEPROM but no data EEPROM. Correct?
After a power cycle it should all be the same as before again.
So if someone can try this, it would be interesting to get a collection
of valid input data words for the same key=timestamp.
To keep this synchronized, I would suggest to start with the first
timestamp of the Dexter trace as we than already have a known correct
data word.
Having this collection of samples should allow to understand how the
error protection is working in detail.
After that one could try different timestamps...
There are very hard time limits. The decoding itself takes 1.25 seconds,
and after every decoding (or after power up) You must wait a little more
than 30 seconds, so the overall decoding time of one packet is about 32
seconds.
Dexter
Hallo,
der PIC 12F509 hat keinen Daten EEPROM nur 1K Programm mit 41 Byte
Variablen. Also ohne Spannung kein Datenerhalt. Interessant wäre die
OSC-Beschaltung der PIN 2/3 da die Verarbeitungszeit relativ hoch ist.
Sicherlich beabsichtigt wird der Chip in den Sleep-Modus zum Strom
sparen geschickt.
MfG Chip
Chip wrote:
> [...] nur 1K Programm [...]
Hat schonmal jemand, der so eine Uhr hat, versucht, das Programm
auszulesen? Ich nehme zwar schwer an, daß die Dinger mit Code-Protection
geflasht werden, aber es schadet ja nicht, das mal zu überprüfen... ;)
> [...] da die Verarbeitungszeit relativ hoch ist.
Die Verzögerungen könnten auch bewußt eingebaut worden sein, um das
Reverse-Engineering zu erschweren.
Die lange Verzögerung dürfte definitiv dazu dienen, das Reverse
Engineering zu erschweren. 30s - so lang kann nicht mal ein PIC brauchen
um in Wallung zu kommen.
Deshalb die Frage nach dem Takt OSC-Beschaltung der PIN 2/3, es geht von
außen z.B. über den vorh. Uhrenquarz 32.. kHz oder über INTOSC intern
mit 4 MHz.
Wenn der von außen langsam getacktet ist könnte man den Pic mit max. 4
MHz takten also 125x schneller. Das würde das Reverse-Engineering enorm
beschleunigen.
Ich habe mal die Pins des 12F509 der Beschriftung der Testpunkte
auf der Platine der Wetterstation gegenüber gestellt.
Es handelt sich um die Mebus Wetterstation mit Meteotime Empfang von
Real.
IC5 ist der Decoder:
VDD 1* 8 VSS
GP5/OSC1/CLKIN TP38 2 7 TP35 GP0/ICSPDAT
GP4/OSC2 TP36 3 6 TP37 GP1/ICSPCLK
GP3/MCLR/VPP 4 5 TP39 GP2/T0CKI
alternativ könnte noch ein anderes IC bestückt werden.
Dies hätte dann folgende Beschaltung:
TP37 1 8 VDD
TP38 2 7 MCLR/VPP
TP36 3 6 TP39
TP35 4 5 VSS
Folgende Signale sind an den Testpunkten zu finden:
TP35 clock in (high ~850us, low ~30ms)
TP36 clock out
(während des Reintaktens der Daten:
wie clock in, nur einige Microsekunden verzögert
während der Datenausgabe:
invertiert zu clock in,etwas vor clock in)
TP37 data out (24 bits)
TP38 data in (82 bits)
TP39 control/status
Eingabephase: low
Ausgabephase:high
Nachher: 45s high, alle 3s für 20us low
Die Daten ändern sich jeweils wenige Mikrosekunden vor der steigenden
Flanke auf clock in.
Der MCLR/VPP Pin ist mit einem Kondensator verbunden, der an GND geht.
Da Pin 2 die Eingangsdaten bekommt, ist eine Verwendung als Takteingang
ausgeschlossen.
Signale am IC:
-MCLR/VPP hat im Betrieb den gleichen Pegel wie Vdd
(kein externer Reset im Betrieb?)
-wenn der Dekoder nicht genutzt wird, sind alle anderen Signale auf low
-alle 3 Minuten werden Daten zum Dekoder und zurück geschickt
unabhängig davon, welche Städte gewählt worden sind
Es gibt einen Testmodus (Testtaste während des Resets gedrückt halten
und dann mehrmals ^)
In diesem Testmodus lässt sich auch der Dekoder mit einem festen Muster
testen:
Eingang: 01000010100011
01101010100111
10011000011000
10100000 Minute: 5
01001000 Stunde: 12
11001000 Tag: 13
00100 Monat:4
001 Wochentag: 4
01100000 Jahr: 06
Ausgang: 01011 10010 01010 11111 1110
Generell ist das Timing etwa folgendermassen:
82 Eingangsbits mit jeweils ~31ms: 2.5s
250ms 'Denkpause'
24 Ausgangsbits mit jeweils ~31ms: 0.7s
danach schliesst sich eine Phase an, die im Normalbetrieb 45s Sekunden
dauert
In dieser 45s Phase ist TP39 noch auf High Pegel (mit kurzen
Unterbrechungen von ~20us)
Die Phase kann aber offensichtlich vorher abgebrochen werden.
Im Testmodus war eine Wiederholung alle 15s möglich, da man nicht viel
schneller durch die Punkte des Testmenüs kommt (EEPROM
lesen/schreiben...)
Mit externer Ansteuerung sollte man also schon deutlich schneller werden
können als bisher angenommen. Ob man auf die 3.5 Sekunden der
eigentlichen Datenübertragung runterkommt oder die noch abkürzen kann,
kann ich allerdings nicht sagen.
Kurze Info noch zum EEPROM auf der Platine:
es handelt sich um ein 24C512. Die 64kByte Daten werden im Wesentlichen
wohl zum Speichern der Städtenamen, Menütexte etc., der Wetterdaten und
Einstellungen für den Hauptprozessor verwendet. Programmcode des
Hauptprozessors ist hier wohl nicht zu finden.
Es werden alle Daten komplett im EEPROM gespeichert. Es wird aber nur
alle 3 Stunden ein neuer Satz geschrieben und auch die Anzeige
angepasst. Wer also vor Ablauf der 3 Stunden einen Reset auslöst oder
die Batterien entfernt, bekommt gar keine Daten angezeigt.
Die Zeiten sind aktuell 02:59:17 MESZ und dann alle 3 Stunden.
Eigentlich müssten die Zeiten UTC basiert sein (00:59:17 UTC) und sich
im Winter eine Stunde nach vorne verschieben.
Die I2C Leitungen zum EEPROM finden sich praktischerweise direkt am 16
Pin Stecker hinter der Abdeckung.
@jupp
die 12 uhr angabe ist richtig gewesen mit 010010,
auch die 0 am ende der stundenreihe ist zu streichen.
und die 00 am ende von der tagesreihe ist auch unverständlich.
die frage ist - sind die nullen tatsächlich dabei gewesen,
oder sind die versehentlich bei der abschrift dazu gekommen ?
folgend ein paar, mit meiner pc-soft aufgezeichnete pakete.
1,5v funkwecker dcf-signale am gameport abgefragt.
http://dcf.cya.de
die soft für unten stehendes paketformat ist noch nicht verfügbar.
Ich kram diesen alten Thread mal wieder nach oben. Ich habe nicht mehr
verfolgt, ob jemand das Protokoll selbst gehackt hat, aber wie ich grade
beim Einkaufen gesehen habe, steht wohl im aktuellen EAM-Magazin 7/2007
(http://www.eam-magazin.de/) ein Artikel mit der Aufschlüsselung des
Protokolls drin. Eventuell interessiert das ja noch jemanden.
Wenn du die Zeitschrifst kaufst, wirst du dich ärgern: Da steht
sinngemäß drin, dass es keine Nachbauanleitung zu einer DCF Uhr mit
Wetteranzeige geben wird. Es werden nur die bereits dekodierten Bits
beschrieben.
Das passt.
Man verprellt seine Geschäftspartner (=Lizenznehmer) nicht,
indem man ihnen die Grundlage des Geschäftsmodells nimmt.
Noch läuft die Geldmaschine und es besteht keine Veranlassung,
sie durch vorzeitige Offenlegung des Protokoll kaputt zu
machen.
Aber kauft euch mal schön alle das Heft EAM.
Die anderen Artikel sind vielleicht auch interessant. ;-)
Micha wrote:
> Hm, ich hab im Kiosk nur kurz reingeschaut und den Artikel gesehen. Sah> so aus, als wäre es komplett. Sorry für die "Falschmeldung"
Ging mir anfangs auch so. In der Mitte des Artikels ist ein Kästchen wo
relativ deutlich steht, dass die das Protokoll nicht veröffentlichen
dürfen. Es hätte mich auch gewundert, wenn die jetzt doch das Protokoll
komplett abdrucken.
Also wie, jezt? Der Artikel sagt, dass nur bekanntes aus den Bits
dekodiert wird, aber er sagt auch, dass er was dekodiert, und dann doch
wieder nicht.
Also ist das lediglich eine DCF-Uhr ohne Wetterinfos, weil die sind ja
kodiert und damit unzugänglich. Kann das mal jemand aufklären, bevor
alle an den Bahnhof rennen ( der ist hier 25km weit entfernt!)
Oder um mich flo anzuschließen: Dekodiert die HEX nun irgendwas außer
der Uhrzeit oder nicht?
Räzelnd, Ulrich
Die Ausgabe enthält zwei Artikel, die sich mit DCF77 befassen.
Der zum Thema Wetterdaten ist eigentlich Werbung für eine bei Conrad für
(IIRC) knapp 300 Euro erhältliche Wetter-Uhr und beschreibt nebenbei das
bereits bekannte Format der Wetterdaten nach der Entschlüsselung.
Die Hex-Datei gehört schätzungsweise zum zweiten Artikel, der dem Titel
nach zu schließen eine Bauanleitung für einen "normalen"
DCF77-Funkwecker enthält, also ohne Auswertung der Wetterbits.
Mit anderen Worten: Die sind auf dem gleichen Stand wie wir. Dann kann
man sich den Kauf sparen. Und DCF77-Uhren gibt es einige hier in der
Codesammlung.
Gruss
Jadeclaw.
hallo,
bin gerade ganz neu hier bei,
und zufällig auf eure fleissige arbeit gestoßen,
habe nur nach näheren informationen zu den 14 bits geforscht,
da ich aktuell dran bin mit mit einem pic, ein dcf test signal sender zu
programieren, da wäre es dann natürlich auch nützlich, sinvolle
wetterdaten mit einbinden zu können.
zur dekodierung, fände ich es auch erstmal interesant eine komerzielle
version von so einem chip zu haben, hat jemand schonmal die
wetterstation bei elv gekauft ?
und kann mir sagen ob da so ein "loser" chip mit anzapfungs
möglichkeiten verbaut wurde ?
ich meine die für 39,95, also die nr: 68-761-48 (WFC 300)
wenn da so ein ding drin ist, würde ich mir gerne mal eine bestellen,
bitte um rückmeldung, möchte nicht das ding jetzt bestellen und dan
nacher zurück schicken müssen.
dann was in eigener sache, mache auch gerne bei interesse ein eigenen
thread auf.
zu meinem programieren von dem sender,
wenn jemand mit interesse dran hat, mehme immer gerne hilfe an !
hänge aktuell an der FM modulierung der pseudo zahlen,
wie muss ich das genau mit dem Phasenhub von ±10 Grad auf den 77,5 kHz
verstehen ?
also ich takte den pic mit einem 18,228 MHz, was dann heißt, das 4557000
takte einer sekunde endsprechen, bei 77,5 khz und eine schwingung der
77,5 khz gleich 58,8 takte, was sich ja gerade zu anbietet, für eine FM
modulation.
wie muss ich mir den phasenhub vorstellen, das ich eine abweichung von
+- 7,75 khz vornehmen muss, zwichen einem 0 und 1 bit ?
also bei interesse, komme aus dem großraum mannheim/ludwigshafen
danke im vorraus
kiwi_
hallo Marco,
also wenn ich das nicht falsch verstehe,
sagen aber viele webseiten was anderes:
http://de.wikipedia.org/wiki/DCF77#PZF.2FPM
"...seit Juni 1983 diese Information auch über eine Phasenmodulation des
Trägers mit einer Pseudozufallsfolge (PZF) in einer Länge von 512 Bit
übertragen. ..."
gruß
kiwi_
Da hier immer mal wieder nach dem Decoder IC und hinsichtlich der
Lizenzbestimmungen/-kosten gefragt wird.
Die jährliche Basis-Lizenzgebühr (geht an Meteotime) für das erste
angedachte Anwendungsgebiet kostet 60 Kilo-Euro, jeder weitere
Applikationsbereich (es gibt insgesamt 9) kostet 20 Kilo-Euro
zusätzlich.
Zum Verständnis: Ein Applikationsbereich wäre z.B. der Bereich
"Wetterstationen", ein weiterer Bereich "Analoge Armbanduhr" und ein
dritter z.B. "Digitale Armbanduhr"
Die Lizenzgebühr pro Chip (geht an Meteotime) hängt von der verbauten
Stückzahl ab und beträgt zwischen 3 und 17 Euro. Dieser Betrag wird
gegen die Jahres-Gebühr verrechnet, bis diese aufgebraucht ist.
Die Kosten für den Chip selbst der über hkw (=nominated Supplier)
vertrieben wird, ist mit denen mengenabhängig direkt auszuhandeln und
nahezu vernachlässigbar (kleiner 3 Euro/St.)
Erst mal muss es den "erfolgreichen" Hacker geben...
Wenn jemand die Informationen anonym irgendwo zur Verfügung stellt, hier
auch nur einen Link dazu postet dann verbreitet sich das so schnell das
selbst das löschen der Info oder des Links zu spät kommt.
Solltest du der erfolgreiche Hacker sein wäre es eine Schande mit der
Info hinterm Berg zu bleiben. Die kommerzielle Aufmachung des Projekts
schreit ja schon förmlich nach Reverse Engineering.
Naja, wenn Jemand Informationen anonym posten will, dann kann er das
auch. Zur not halt aus einem Internet-Cafe, oder an einem öffentlichen
WLAN-Accesspoint.
Moin!
Florian ...... wrote:
> Und schon ist die WFC300 vergriffen :) Hat sie hier Jemand im Forum> gekauft?
Nein, aber seit ein paar Tagen steht hier eine WFC500 ;-)
Nettes Gerätchen für den Preis, wenn man das mit der METE-ON 1
vergleicht. Gut, deren Design ist vielleicht etwas schicker, aber sonst
kann sie auch nicht mehr ...
Jetzt ist übrigens meine METE-ON 3 (dieser Funkwecker mit Wetterempfang
und Vorhersage für den aktuellen Tag und die kommende Nacht) übrig.
Etwas weiter oben hatte ich Bilder von der Platine verlinkt. Es ist der
Decoder-Chip drin - also das richtige Gerät, um damit Decodier-Versuche
zu machen :)
Gruß, Didi
Mit der "DCF77-Zeit" darf doch jeder Anstellen, wonach ihm der Sinn
steht. Aber was wird eigentlich in der Bedienungsanleitung der am Markt
erhältlichen "Wetter-Uhren" über die Nutzung der empfangenen Daten
ausgesagt?
Man könnte doch auf die Idee kommen, die 22 (bzw. 24) dekodierten
Datenbits aus dem Decoder einer solchen Uhr kontinuierlich in einen PC
einzuspeisen und dort so sämtliche aktuellen Wetterdaten round-robin
vorzuhalten.
Der PC könnte diese dann dem Internet zur Verfügung stellen; ein ganz
simpler deamon könnte den kompletten Datenpool (und einen "Zeiger" auf
den Datensatz, der zuletzt empfangenen wurde, i.e. die auf 3min genaue
Uhrzeit) auf eine Anfrage hin "raw" ausliefern.
Die 480*3Byte passen bei gängiger MTU ja sogar noch in ein Paket, sodaß
man aus Effizienzgründen sogar UDP verwenden könnte.
Einen Anzeige-Client kann dann jeder nach seinem Geschmack entwickeln.
Dexter: How to connect such a clock with a pc in a cheap and simple way?
One may attach such a clock on his home pc and use a commmon hosted
"root server" as a distributing proxy.
Hi!
Also das in den Patenten beschriebene Cryptoverfahren macht ein reverse
Engineering doch recht schwer. Es ist ja nicht nur, dass der Schlüssel
ganz oder teilweise aus der übertragenen Uhrzeit erstellt werden könnte,
sondern dass aus dieser Zeit ein Index auf eine Schlüsseldatenbank
erstellt werden könnte. D.h. aber, dass es in dem PIC eine COde-Tabelle
geben kann, oder sogar Teile oder der ganze Code des PIC als Tabelle
selbst dienen könnte.
Das bedeutet, dass man, wenn man einen Schlüssel hat, mit diesem am
nächsten Tag schon nichts mehr anfangen kann. Die Errechnung des
Schlüssels muss also für einen unbestimmt langen Zeitraum geschehen.
Dann muss man aus den geknackten Schlüsseln auch noch eine Beziehung zur
Uhrzeit ableiten.
Zudem nennt das Patent auch eine Option den Schlüssel, bzw. seinen Index
aus einer Zeitdifferenz zu bilden... Möglicherweise steckt da also noch
mehr Sicherung dahinter.
Alles in allem also ein recht mühseliger Weg, wenn man das reverse
Engineeren möchte.
Gruß, Ulrich
Einkaufstipp:
Falls sich wirklich mal jemand für die Mete-On 1 interessiert und
zufällig nach Helgoland kommt - ich hab meine dort im Oktober für 150
Euro gekauft. Dank Zoll- und MwSt-Freiheit der Insel :)
Hat da mitlerweile jemand was neues rausgefunden?
Hab mich schon bei Wikipedia durch ein paar Korrekturverfahren gewühlt
und werd mich demnächst mal hinsetzen udn mal stumpf n bischen was
durchrechnen, welches Verfahren in Frage kommen könnte.
Alternativ hilft der Matheprof evtl. auch weiter, der auch
Kryptologievorlesungen anbietet. Vielleicht hat der mal ne Stunde Zeit
nach den Prüfungen ^^
Dank dexter wissen wir ja nu jetzt, welche Daten anscheinend fürs Wetter
und für die Fehlerkorrektur sind.
Evtl. dackel ich auch mal zum Mediamarkt und besorg mir sone Uhr, wenns
die da noch gibt.
Meine zukünftige Nixie soll mir schließlich das Wetter vorhersagen
können ;)
Hallo, ich habe mir den thread nun in über 3 Stunden durchgelesen und
finde es schade das es noch niemand herausgefunden hat.
Denn ich habe nämlich ein Programm geschrieben (für windows) womit man
die DCF-Zeitdaten auswerten kann und die systemuhr dementsprechend
stellt und diese Daten loggt, ich hb da mal eine Datei angehängt (leider
haben wir hier nicht so guten empfang, daher sind zuletzt auch viele
Fehler drin)
Ich habe leider keine aktuelle datei, denn dafür ist der empfang zu
schlecht in den letzten Tagen.
Ich wollte mein Programm so umschreiben, dass ich auch wetterdaten
anzeigen lassen könnte aber das ist schade das es noch keine lösung
gibt...
gruß thomy_pc
Thilo M. wrote:
> Hier 'n Link zum Thema Wetterinformationen:> http://www.hkw-elektronik.de/pdfdeutsch/DB%20W-Protokoll-V%201.pdf>> Schön beschriebener Aufbau des Signals. :-)
Das nützt nix. Die Daten werden verschlüsselt übertragen. Das zu
dechiffrieren ist die eigentliche Kunst, die noch keiner hinbekommen
hat.
Willivonbienemaya .. wrote:
> Das nützt nix. Die Daten werden verschlüsselt übertragen. Das zu> dechiffrieren ist die eigentliche Kunst, die noch keiner hinbekommen> hat.
Weil die Leute sich auch immer wieder Saudumm anstellen.
Entweder gibt es Logs von den 14 Bits oder von den 14 Bits + Zeit/Datum
oder von den 14 Eingangs und Ausgangs Bits.
Aber jemand der alle Eingangsbits(Wetter und Zeit) und die dazugehörigen
Ausgangsbits postet fehlt noch immer.
Genauso wie der, der selber generierte Daten in den Decoder schickt und
schaut was rauskommt (ok, bis auf Dexter).
Achja und ab und an kommt so ein Spaten wie Thilo M. vorbei, der wieder
diesen Tollen Signalaufbau postet...
Hallo,
ich hätte den Vorschlag, dass man nur die Wetterdaten EINES Standortes
über mehrere Tage loggt und diese mit der Wettervorhersage vergleicht,
dann könnte man schauen, was sich an den Ausgangsbits ändert, wenn man
bekannte Eingaben hat.
Zur Verschlüsselung:
Ich glaube, dass hier das Datum mit drinhängt, das bedeutet, jeder Tag
anderer Schlüssel und damit ganz schwer nachvollziehbar.
Das könnte man mit dem täglichen loggen herausfinden.
P.S. habe leider keinerlei Ausstattung mit der ich das machen kann,
interessant finde ich es trotzdem.
Das beste wäre wirklich, wenn jemand mal so eine Uhr besorgen könnte,
hat das inzwischen mal jemand geschafft?
Wenn man den Chip direkt ansprechen kann, duerfte das Knacken
tatsaechlich nicht mehr so schwer sein..
Ich glaube auch nicht, so wie manche vermutet haben, dass der eine stark
eingeschraenkte Taktrate hat..
Wow, ich hatte mir nur mal "just for fun" so eine DCF77 Empfangsantenne
gekauft ohne mir vorher gross gedanken drueber zu machen. Als ich dann
das Protokoll bei wikipedia nachgelesen hab, bin ich auf die
verschluesselte Wetterinfo aufmerksam geworden und bin nach einer
Websuche dann hier gelandet.
Ich habe nun in ueber 3h den gesamten Thread gelesen und muss sagen "Hut
ab!". Ich werde jetzt erstmal nen uC an die Antenne haengen und ne Uhr
bauen. Spaeter kann ich dann das ganze auch evtl. mal mitloggen und
hierbei helfen.
Habt ihr vielleicht schon daran gedacht, das die Daten auf die 100ms bzw
200ms Sekunde Moduliert werden wie bei einem Radiosender?
http://de.wikipedia.org/wiki/Amplitudenmodulation
Vermutlich wird auf die 77.5kHz Trägerwelle das Nutzsignal Moduliert, da
am Anfang schon erwähnt wurde, das die ersten 14 Bit Amplitudenmoduliert
sind.
Hallo,
DCF77 ist Amplitudenmoduliert, schon immer...
Eine Trägerabsenkung bei den Sekundenimpulsen ist eine AM.
Die Impulsfolge auch in den ersten 14 Sekunden muß eingehalten werden,
sonst kommt keine übliche Funkuhr mehr klar.
Gruß aus Berlin
Michael
Außerdem sieht der Wecker gar nicht mal so schlecht aus
http://www.swisswetter.ch/mall/irox-mete-on-3.htm
Das einzige was mich jedoch bei allen Funkweckern stört ist:
Mit dem Funksignal wird die Uhrzeit, das Datum und der Wochentag
gesendet.
Ist es nicht möglich einen Funk-Wecker zu machen, den man einstellen
kann das er nur von Montag bis Freitag um 06:00 Weckt und am Samstag und
Sonntag nicht, ohne das jeden Freitag die Weckfunktion von Hand
auszuschalten und Sonntag Abend wieder einzuschalten?
Gottfried S. wrote:
> Ist es nicht möglich einen Funk-Wecker zu machen, den man einstellen> kann das er nur von Montag bis Freitag um 06:00 Weckt und am Samstag und> Sonntag nicht, ohne das jeden Freitag die Weckfunktion von Hand> auszuschalten und Sonntag Abend wieder einzuschalten?
Gibt es zuhauf, meiner macht das z.B., man kann mehrere Weckzeiten
programmieren und zu jeder die Tage festlegen.
@Gottfried: Ich glaube das mit der Phasenmodulation wurde bereits
ausgeschlossen.
Und wenn es denn Phasenmodulation waere, dann koennte man das doch nicht
mit den normalen DCF77 Empfaengern empfangen, oder? Weil die geben das
ja binaer aus.
Toller Krimi hier!
Phasenmodulation kann auch binär sein, heißt dann PSK. Hier wird aber
nur AM verwendet, damit der Empfänger möglichst billig wird. Für PSK
braucht es einen sauberen und genauen Quarzoszillator.
Da das Wetterprotokoll offensichtlich laut einer der Patentschriften:
1. zum Katastrophen-System kompatibel sein soll, und
2. das Katastrophen-Protokoll anscheinend erheblich einfacher
strukturiert ist/war
vermute ich eines der inaktiven Bits als simplen Unterscheider, welcher
Art das übertragene Datenpaket ist. Eine 1-Bit Unterscheidung würde auch
die sofortige Alarmierung ermöglichen. Das Wetterprotokoll zieht sich
ja mindestens über 3 Minuten hinweg.
Bleibt dran! Sollte doch mit eine paar Krypto-Experten leicht knackbar
sein. In einen 1K PIC paßt selbst in Assembler nicht sonderlich viel
Code rein.
Wer hat eigentlich wie den genauen PIC-Typ herausgefunden?
Gruß -
Abdul
> Bleibt dran! Sollte doch mit eine paar Krypto-Experten leicht knackbar> sein. In einen 1K PIC paßt selbst in Assembler nicht sonderlich viel> Code rein.
Mutige These... Ich glaube schon, dass man eine AES Entschlüsselung in
1k Code unterbringen könnte. Außerdem ist nicht gesagt, dass es exakt
ein bestimmter und bekannter PIC ist, es kann auch ein ASIC auf Basis
eines PIC sein. Es kann aber auch ein komplettes ASIC mit einem zufällig
PIC ähnlichen Pinning sein.
Ich baue zwar jede Art von Algorhythmus in C oder Assembler, aber
Cryptographie ist leider (noch) nicht meine Stärke. Aber ich arbeite
daran :)
Gruß, Ulrich
Kann da nicht mal jemand eben den chip auf-ätzen und rein schauen was es
ist? Eventuelle lock-bits lassen, sich wenn man den chip erstmal offen
hat ja leicht entfernen.
Das mit dem Pic, dachte ich war ja bestätigt?
Ich würde rückgekoppelte Schieberegister für recht wahrscheinlich
halten, mit irgendwelchen Bits uas den letzten drei Zeitinfos als IV.
Man bräuchte da ja in erster linie erstmal viele Datenblöcke und müsste
die auch dekodiert vorliegen haben. Dann kann man ja mal schaun, ob da
Auffälligkeiten drin sind.
MfG
Andreas
Obs ein PIC oder mir wegen ein ASIC basierend auf PIC ist, könnte man
durch einen Programmer für PICs eingrenzen. Der sollte zumindest den
PIC-Typ aktiv erkennen können wenn man das IC als PIC ranhängt. Hier
sind die PIC-Experten gefragt. Kenne mich mit den Dingern nicht aus.
Weiter oben wurde was von Fehlerkorrektur erwähnt. Das wurde ja
gemessen. Effiziente Korrektur ist mit Turbo-Codes möglich. Aber auch da
bin ich nicht Experte :-(
Vielleicht sollte man nochmal mit dem Crypto-Tool experimentieren.
Wieviel RAM hat der PIC? Er muß ja wohl mindestens 3 Minuten
zwischenspeichern und dann noch Platz für die Berechnung haben. Und wenn
man obigen Beobachtungen glauben darf, wird der Datenblock nach
Bearbeitung als ganzes ausgegeben. Macht also nochmal Platz für einen
kompletten Block.
Stromverbrauch und Spannungsabhängigkeit können den Prozessor weiter
eingrenzen.
Gruß -
Abdul
Finde das ja alles sehr interessant,
Bloß wieso machen die dat nich kostenfrei?
Naja,
Ich hab an meinem Server nen DCF-Empfänger dran, isn Billigteil von
Conrad,
Darum is leider nicht alles in Ordnung was die Daten angeht, aber sollte
reichen, da könnt ihr genug verschlüsselte Daten rausholen:
http://thomy-pc.homeip.net/dcflogs.php?file=DCFLog00059.log
Noch ein schönes Wochenende,
gruß
thomy_pc
Wow. Ordentliche Arbeit! Für eine harte Kryptoanalyse ist eine
Fehlerrate von 93% allerdings wohl ziemlich knapp.
Wer hat einen besseren Epmfänger für ihn?
Auffallend sind die Schwankungen im Tastverhältnis einiger Bits im
Wetterbitstrom. Entweder da wird eine Information übertragen, oder der
Empänger hat Baselinewander-Probleme.
Schön das es weitergeht.
- Abdul
Naja, ein neuer Empfaenger sollte wohl nicht das Problem sein. Die gibts
ja schon fuer 5 EUR.
Aber so ein Problem mit der zuverlaessigkeit habe ich momentan auch. Ich
habe in meinen Daten auch sehr viele Fehler drin und wenn ich z.B. den
Loetkolben neben die Antenne halte, spielt das Ausgangssignal von dem
Empfaenger verrueckt.
Weiss da einer ob das am Empfaenger selbst liegt oder an irgendeiner
fehlenden abschirmung? Die Verbindung vom Ausgangspin zum
Mikrocontroller ist bereits so kurz wie moeglich.
Es würde helfen, wenn du die Art des Lötkolbens und ein Bild des
Empfängers zeigen würdest.
Eigentlich sollte einem guten Empfänger selbst das Geknackse eines alten
Weller-Lötkolbens nichts ausmachen.
Aber vielleicht wohnst du auch sehr weit weg vom Sender?
Gibt übrigens gerade auch bei Pollin Empfänger mit digitalem Ausgang.
Vermutlich die Standard-Billigschaltung.
Man könnte natürlich auch einfach drei parallel betreiben und
mehrheitlich entscheiden lassen...
Oder den Empfänger abgesetzt betreiben. Im Dachstuhl des Hauses oder so.
Mit Auswertung der Fehlerrate könnte man nahe Gewitter detektieren...
- Abdul
> wenn ich z.B. den Loetkolben neben die Antenne halte,> spielt das Ausgangssignal von dem Empfaenger verrueckt.
Na nimm Dir einfach mal ein Radio, daß Langwellenempfang zuläßt, dann
hörst Du die Störungen etc.
Es handelt sich um eine induktive Antenne mit Richtwirkung, die generell
keine zu nahem Metallteile mag - die Antenne wird dadurch verstimmt.
Pack dem Empfänger in ein Kunstoffgehäuse mit paar Meter abgeschirmtem
Kabel dran, plaziere ihn weit weg vom allem Gerät und achte auf die
Ausrichtung der Richtung FFM. Dann sollte der Empfang besser werden.
So siehts im Moment aus:
http://img183.imageshack.us/img183/3884/dsc00781vb8.jpg
Der Loetkolben hat 30W und ist von Bosbach und ich wohne ca. 250km vom
Sender weg.
Es ist der Empfaenger von Pollin.
Wie muss ich die Antenne denn ausrichten? In Laengsrichtung zum Sender
oder quer? Und besser stehend oder liegend?
senkrecht zur Längsachse sollte nach FFm zeigen .. bedenke, dein
Steckbrett beinhaltet Metall als Verbindungsschienen .. sehr ungünstiger
Antennenort!
Du solltest die Antenne mit der dazugehörigen Platine in ein
Plastikgehäuse ... s.o.
Ich habe bei einem Test des Pollin Teils einen fehlerfreien Empfang über
einige Stunden gehabt. Richtig ausgerichtet muss allerdings schon sein,
und ist vielleicht auch besser wenn ein paar cm drumherum nicht viel ist
was Strom oder Magnetfeld leitet.
Das Display dürfte wegen dem Multiplexen auch recht bestialisch stören.
Empfänger samt seiner Platine weiter weg stellen. Dazwischen einfach das
dreipolige Kabel mit dem Digitalsignal. Idealerweise in einer
abgeschirmten Audioleitung. Oder ein Koaxkabel mit Phantomspeisung.
Das sollte helfen.
Die Ferritantenne darf nicht senkrecht (nach oben) stehen, sondern
waagerecht liegend! Frankfurt ist dann die Winkelstelle, an der die
wenigsten Störungen detektiert werden. Es gibt davon auf dem Vollkreis
immer zwei Stellen im Abstand von 180°, weil die Antenne symmetrisch
ist.
- Abdul
Gast wrote:
>> Aber so ein Problem mit der zuverlaessigkeit habe ich momentan auch. Ich> habe in meinen Daten auch sehr viele Fehler drin und wenn ich z.B. den> Loetkolben neben die Antenne halte, spielt das Ausgangssignal von dem> Empfaenger verrueckt.>> Weiss da einer ob das am Empfaenger selbst liegt oder an irgendeiner> fehlenden abschirmung? Die Verbindung vom Ausgangspin zum> Mikrocontroller ist bereits so kurz wie moeglich.
Hi, die Güte des DCF-Signals/Empfangs ist neben dem Empfänger von ganz
vielen anderen Faktoren abhängig:
-- Wetterlage
-- Tageszeit (Sonnenstand)
-- PC/Laptop in der Nähe (sollte > 2m sein)
-- Monitor in der Nähe (Röhre, TFT, ... dito für den Abstand)
-- nicht zu nahe an der Schaltung (µC, geMUXtex Display, ... > 30cm)
-- Schaltung nicht mit einem Schaltnetzteil versorgen, sondern mit
einem normalen Trafo. Bei einem SNT gibt's übelste und hartnäckige
Störungen, die DCF unbrauchbar machen. Was das für Störungen sind, weiß
ich net, zumindest scheinen sie nicht übern Äther zu kommen sondern über
VCC. Entstörmassnahmen (Drosseln im Stromweg, LC-Filter, ...) erwiesen
sich als nutzlos, das einzige was dann hilft ist dann Erdung der
Schaltung.
Zumindest sind das meine Erfahrungen mit DCF-Empfang. Ich nutze das
641138 vom Conrad in mehreren Uhr-Projekten.
>> http://thomy-pc.homeip.net/dcflogs.php
Abdul K. wrote:
> Wow. Ordentliche Arbeit! Für eine harte Kryptoanalyse ist eine> Fehlerrate von 93% allerdings wohl ziemlich knapp.
93% wurden korrekt empfangen :-)
Eine Fehlerrate von 7% bedeutet bei 45 auswertbaren Bits eine Fehlerrate
f_b von 0.16%
Wenn man davon ausgeht, dass die Fehler unabhängig voneinander sind, hat
man nämlich
Sind die Wetter-Bits von der gleichen Fehlerrate betroffen, dann sind in
den "korrekten" Datensätzen 2.3% der Wetterblöcke unwissentlich falsch
empfangen worden.
Ich hab auch mal n bisschen mitgeloggt, formatiert als C-Initializer
http://www.gjlay.de/dcf_2008-05-18.txt
Fehlerhafte Datensätze (0:26, 3:37, 3:43) sind nicht dargestellt. Die
dargestellten Datensätze sind geprüft auf
-- Parity
-- Bitlängen
-- Konsistenz
Grüß, Georg-Johann
p.s.
Die dritte Zahl im Initializer stellt die unteren 16 Bits dar, das
zweite Element sind die DCF-Bits (Bit 0 zuerst).
Hi,
ich hab es jetzt geschafft das Signal deutlich zu verbessern. Meine Uhr
laeuft nun schon seit >18 h und das ohne einen einzigen Bitfehler.
Demnaechst werde ich dann noch eine Schnittstelle zum PC implementieren
und dann kann ich auch mit logs dienen. :)
Ich habe grade allerdings auf der Homepage der PTB noch was gefunden was
eine Frage aufgeworfen hat:
"Die Wahrscheinlichkeit dafür, Schaltsekunden auslassen zu müssen, ist
gering, die technischen Einrichtungen am Sender lassen es jedoch zu."
Quelle: http://www.ptb.de/de/org/4/44/442/dcf_kode.htm (unten)
Was meinen die mit Schaltsekunden auslassen?
Gruss
Hallo,
> "Die Wahrscheinlichkeit dafür, Schaltsekunden auslassen zu müssen, ist> gering, die technischen Einrichtungen am Sender lassen es jedoch zu."> Quelle: http://www.ptb.de/de/org/4/44/442/dcf_kode.htm (unten)>> Was meinen die mit Schaltsekunden auslassen?
Da das Jahr eben nicht genau 365 Tage lang ist, wird nötigenfalls die
letzte Stunde des 30.6. oder 31.12. um 1s auf 61s "gestreckt" -- dann
hat das DCF77-Signal 59 Bits! Dies wird während der Stunde, an deren
Ende es passieren wird, mit dem "Ankündigungsbit" angekündigt.
Das PTB kann solche Schaltsekunden also scheinbar auch "weglassen".
Gruß
Fred
Fein!
Vermutlich hast du aber keine Information darüber, ob in den ersten
14/15 Bits ein Fehler auftrat??
Deine Aussage bezieht sich wohl nur auf die Prüfbits im originalen
Zeit-Btstring.
Bezüglich deines Zitats der PTB zu Schaltsekunden:
Diesen Aspekt hatte ich bislang auch nicht wahrgenommen. Stimmt, da kann
ja mal eine Minute länger als 60 Sekunden sein! Da die Schalterei mit
den per se vorlaufenden Bahnhofsuhren kompatibel sein muß, würde ich
sagen es ist so zu interpretieren:
Diese Minute wird einfach eine Sekunde länger. Die normalerweise letzte
(59.) Sekunde wird NICHT ausgesetzt, dagegen in der nachfolgenden
zusätzlichen Sekunde WIRD der Puls ausgesetzt.
Sollte noch mal jemand anderer verifizieren. Ob das so wirklich jeder
Chinawecker verkraftet? Mir kommt da gerade so ein ungutes Gefühl auf.
Wann ist die nächste Schaltsekunde angedacht?
Oder du fragst die PTB mal an. Darüber werden sie sicher Auskunft geben.
Eine andere Frage ist auch, wie die Bevölkerungswarnungen im Datenstrom
untergebracht werden sollen:
1. Durch Unterscheidung z.B. anhand es ersten Bits einer Minute, oder
2. Durch freie Bitstring-Kombinationen in den Meteodaten. Also
Bitstrings, die von der Meteo-Codierung nicht ausgenutzt werden.
Man sollte also mal die Meteo-Bits dahingehend untersuchen, ob
irgendwelche Kombinationen niemals auftreten, oder besser gleich welche
Bitkombinationen wie oft auftreten.
Gruß -
Abdul
> Was meinen die mit Schaltsekunden auslassen?>
Ich nehme an, Du weiß, daß all n Jahre ein Jahr um eine Sekunde
verlängert werden muss. (/ genaues findest DU auch bei der PTB )
Diese "Schaltsekunde" wird angekündigt und gesendet.
Und nun KANN es halt passieren, daß dies Info ausfallen muss bzw kann.
Das ist damit gemeint
ist ja auch nicht so schlimm, denn nach spätestens einer Minute( Wenn
Dein Programm jede Minute auswertet ) bist DU ja wieder auf dem
Laufenden
Hanns
Erklärt aber nicht, wieso eine Schaltsekunde "ausfallen" kann. Ich
könnte mir ein möglichen Grund vorstellen: Die Verbindung zwischen
Braunschweig und dem Sender in Mainflingen ist irgendwie gerade gestört.
Vielleicht sind die Atomuhren in Mainflingen nicht zur Erkennung einer
Schaltsekunde in der Lage und die Sender-Steuerung bekommt diese Info
offline aus Braunschweig irgendwann rechtzeitig vorher und "webt" das
dann ins Nutzsignal ein.
Übrigens gibt es bei der PTB ein Dokument, wo die Verlängerung der
Minute genau so beschrieben ist, wie ich es oben vorstellte. War also
meine Vermutung richtig.
Gruß -
Abdul
"Fein!
Vermutlich hast du aber keine Information darüber, ob in den ersten
14/15 Bits ein Fehler auftrat??
Deine Aussage bezieht sich wohl nur auf die Prüfbits im originalen
Zeit-Btstring."
Doch, die habe ich.
Bei meiner Uhr laeuft das so: Jeder Puls wird auf seine Laenge geprueft.
Mein Empfaenger hat da leichte Abweichungen aber die kurzen Pulse kommen
bei 1Mhz auf einen Zaehlerstand von etwa 93 +- 3 (mit vorteiler 1024)
und die langen auf 190 +-3. Also etwa 93 und 190 ms.
Ich habe da die Toleranzen eng gesetzt, sodass alles mit einer Laenge
von 83-103 als 0 erkannt wird und alles von 180-200 als 1. Kommt ein
Puls mit einer anderen Laenge an gibt das Programm den Wert 2 zurueck.
Die Fehlererkennung basiert alleine darauf zu pruefen ob in den Daten
eine 2 drin ist. So wird jedes Bit getestet.
Das einzige was dabei passieren koennte ist das ein kurzer Puls
zufaellig in die 180-200 faellt oder ein langer aus irgendeinem Grund
kuerzer wird und in die 83-103 faellt. Allerdings finde ich das die
wahrscheinlichkeit doch sehr gering waere. Und da die Uhr schon seit
ueber 20 Stunden laeuft und noch nicht ein einziger Fehler aufgetaucht
ist, kann ich mit an Sicherheit grenzender Wahrscheinlichkeit sagen das
alles richtig lief.
Ah, ich dachte du hast eine billige Biterkennung. Bei deiner Methode
sieht die Sache besser aus. Die Prifbits benutzt du gar nicht?
Allerdings ist die Aussage, es wäre in den 20 Stunde noch nie zu einem
Fehler gekommen, mit Vorsicht zu genießen:
1. Entweder es war so wirklich, oder
2. Deine Fehlererkennung funzt nicht.
Ich zweifele nicht an deinen Fähigkeiten. Wollte es nur erwähnen.
Vielleicht einfach mai einen eigenen DCF77-Bitstring generieren und
einspeisen. Man weiß ja nie.
In der Schweiz sollen übrigens die gleichen Meteo-Daten über den Äther
gehen. Stimmt das?
Nebenbei:
Hat mich doch wirklich erstaunlicherweise zwei Tage Arbeit gekostet, mir
einen DCF77-Empfänger zu basteln mit dem ich dann meinen Referenzquarz
für den angedachten Frequenzzähler ziehen möchte. Allerdings wohne ich
auch 500km vom Sender entfernt.
- Abdul
Sagt mal, da ist was, was mir ganz gewaltig zum Hals raus hängt:
Wer bezahlt letztlich die PTB und ihren Funknippel? Richtig. Der
Steuerzahler. Und welche gottverdammte Drecksfirma verdient nun mit
irgendwelchen verfluchten Lizenzen ihr Geld?
Sorry, aber sowas stinkt doch zum Himmel?!
Nene, die Lizenz ist beim Schweizer Wetterdienst.
http://www.meteotime.com/web/
Der benutzt die ersten 14 Bit für seine Informationen und verkauft
Lizenzen an Die Hersteller der Wetterstationen.
Die Gebühr für die Nutzung der ersten 14 Bit geht an die PTB und
entlastet somit den Steuerzahler.
Nein, die Pruefbits verwende ich (noch) nicht. Das werde ich aber noch
implementieren um noch sicherer zu sein. Die Schaltung und der Code ist
zu 95% jetzt am Wochenende entstanden, daher noch nicht ganz
vollstaendig.
Die Fehlererkennung funktioniert ;)
Ich habs schon getestet indem ich mal was metallisches neben die Antenne
gehalten hab. Da ich noch eine LED dran habe die die Pulse optisch
darstellt habe ich auch eindeutig den Fehler gesehen den die Zange
erzeugt hat und der wurde dann auch gezaehlt.
Thilo M. wrote:
> Nene, die Lizenz ist beim Schweizer Wetterdienst.> Der benutzt die ersten 14 Bit für seine Informationen und verkauft> Lizenzen an Die Hersteller der Wetterstationen.> Die Gebühr für die Nutzung der ersten 14 Bit geht an die PTB und> entlastet somit den Steuerzahler.
War mal wieder vorschnell... hab nix gesagt^^ Aber warum zum Geier
müssen die dann immer noch verschlüsselt sein? Ich mein, so nen toller
Code, dass die Verschlüsselung Lizenzen nötig macht, kann es wohl net
sein.
Sven Pauli wrote:
> Thilo M. wrote:>> Nene, die Lizenz ist beim Schweizer Wetterdienst.>> Der benutzt die ersten 14 Bit für seine Informationen und verkauft>> Lizenzen an Die Hersteller der Wetterstationen.>> Die Gebühr für die Nutzung der ersten 14 Bit geht an die PTB und>> entlastet somit den Steuerzahler.>> War mal wieder vorschnell... hab nix gesagt^^ Aber warum zum Geier> müssen die dann immer noch verschlüsselt sein? Ich mein, so nen toller> Code, dass die Verschlüsselung Lizenzen nötig macht, kann es wohl net> sein.
Naja, überall wo man Geld verdienen kann, kann der Schlüssel nicht gut
genug sein!
Ich habe daran auch sehr großes Interesse (Solarthermische Anlage mit
'vorausschauender' Steuerung).
Vielleicht sollte man ein Preisgeld für das Knacken aussetzen. Wäre auch
was für den rührigen CCC.
Ich denke solange das zumindest vereinzelte Interesse nicht nachläßt,
wird wohl auch die Verschlüsselung bald geknackt werden.
Darf man sowas überhaupt knacken oder ist das hier bereits die
Aufforderung zu ungesetzmäßigen Handeln?
Vielleicht hat es auch schon jemand geschafft und er hat entwder Angst
es zu veröffentlichen bzw. möchte daraus ein eigenes Geschäftsmodell
entwickeln.
Es fällt zumindest auf, das einige der früheren Poster sich nicht mehr
dazu melden.
Gruß -
Abdul
Naja, wenn daraus einer ein 'Geschäftsmodell' ohne Lizenz macht, ist es
mit Sicherheit strafbar.
Aber nur des Knackens wegen, ohne daraus Profit zu schlagen, dürfte kein
Problem sein. ;)
Leider fehlt mir die Zeit und die Kenntnis über
Verschlüsselungstechniken um mich intensiv damit zu beschäftigen. :(
Hm Thilo -
Das war aber jetzt ne Ansage: Zu denken es wird kein Problem sein und
dann zu behaupten, du kannst es nicht.
Ich leider auch nicht :-()
Man sollte ein paar Leute der Kryptoanalyse auf diesen Thread hier
aufmerksam machen. Vielleicht würde der eine oder andere derer nur kurz
Lachen und dann posten.
Mathematica ist auch nicht schlecht für DES-Schlüssel
auseinanderzunehmen. Ich bin aber eher Hardwaremensch und versteh nicht
viel davon.
OK, ich gebs zu. Einmal habe ich auch einen Code geknackt. Der
Hersteller meinte, sein Dongle wäre nicht knackbar. Das reizte mich...
Meteodaten ist halte ne nette Spielerei. Ich vermute, der Vertrag wird
nicht verlängert und die Bits werden in ein paar Jahren neue
Beätigungsfelder suchen...
Gruß -
Abdul
>Das war aber jetzt ne Ansage: Zu denken es wird kein Problem sein und>dann zu behaupten, du kannst es nicht.
Ich meinte, es wäre wohl rechtlich kein Problem, sachlich steht auf
'nem anderen Blatt ...
Abdul K. wrote:
> Man sollte ein paar Leute der Kryptoanalyse auf diesen Thread hier> aufmerksam machen. Vielleicht würde der eine oder andere derer nur kurz> Lachen und dann posten.
Ich würd mein Boppes verwetten, dass es keiner schafft, den Wetter-Code
zu knacken.
Hier sind zwar sehr viel Leute mit hellem Oberstübchen unterwegs, aber
ohne Idee, was da abgeht, hat man einfach keine Chance. Und selbst
wenn...
Georg-johann L. wrote:
> Abdul K. wrote:>> Man sollte ein paar Leute der Kryptoanalyse auf diesen Thread hier>> aufmerksam machen. Vielleicht würde der eine oder andere derer nur kurz>> Lachen und dann posten.>> Ich würd mein Boppes verwetten, dass es keiner schafft, den Wetter-Code> zu knacken.>> Hier sind zwar sehr viel Leute mit hellem Oberstübchen unterwegs, aber> ohne Idee, was da abgeht, hat man einfach keine Chance. Und selbst> wenn...
Jupp, wie ich oben shcon schrieb, die Sicherheit eines Cryptosystms
basiert nicht auf der Geheimhaltung des Verfahrens.
Und wenn die nicht doof sind (was ich mal nicht vermute die wollen ja
Geld dafür) dann hat man auch mit "loggen" keine Chance.
Läubi Mail@laeubi.de wrote:
> Jupp, wie ich oben shcon schrieb, die Sicherheit eines Cryptosystms> basiert nicht auf der Geheimhaltung des Verfahrens.
Es sollte nicht davon abhängen. Nicht selten tut es das aber.
Das ist doch eine gute Anwendung von Verschlüsselung. Da steckt gerade
soviel Geld drin, dass es sich eben nicht lohnt den originalen Chip zu
sezieren...
Solange man es nicht probiert, weiß man recht wenig! Gut, man kann
warten bis andere zuerst Entdeckerfreuden haben...
Vielleicht wäre die Sezierung des Chips ein guter Schritt. Heiße 95%
Schwefelsäure oder Salpetersäure reichen zur Entfernung des Kunststoffs.
Danach unters Mikroskop. Die meisten Hersteller haben Logos drauf. Den
vermuteten Chip nachkaufen und auch diesen behandeln und dann
vergleichen. Sehen wir mal von Revisionen des Chipdesigns ab, ist der
Chip damit gut eingekreist. Aber hatte nicht irgendwo oben jemand
bereits was von PIC erzählt?
Ich würde momentan auf einen stinknormalen PIC setzen: Ist billig, weit
verbreitet, reicht vermutlich technisch völlig aus.
Das war der Hardware-Ansatz. Die Kryptofreaks sollten sich die Logs
vornehmen...
- Abdul
> Das war der Hardware-Ansatz.>
...Naja, Das das ein PIC ist schon klar. Aber da war doch mal was mit
Protect-Bits löschen direkt auf dem Chip. Dafür wird Ausrüstung einer
Preisklasse benötigt für die im Nutzen für den Angreifer nicht genug
Geld steckt.
Was wäre denn, wenn man den Original Chip blind mit Daten füttert und
das Ergebnis aufzeichnet. Wenn ich das richtig gesehen habe gehts ja um
14 Bit.
D.h. man hat 2^14 Möglichkeiten (16384) So hat man zu jedem Eingangs-
ein Ausgangsmuster...
Nicht ganz... Es sind 3x 14 Bit. Jede Minute wird nur ein drittel
übertragen, für mehr ist einfach kein Platz.
Das heisst in der Summe sind es 42 Bit.
Dazu kam noch, dass oben jemand gepostet hat, dass der Chip nur in
gewissen Zeitabständen überhaupt arbeitet. Das Intervall weiß ich jetzt
grad allerdings nicht mehr aus dem Kopf. Ansonsten kommt einfach keine
Antwort. Wahrscheinlich um genau solchem rumprobieren vorzubeugen.
Andreas wrote:
> Das heisst in der Summe sind es 42 Bit.
Der Decoder bekommt nicht nur jeweils die ersten 14 Bit, sondern den
kompletten Datenstrom des DCF77-Signals und es steht die Vermutung im
Raum, daß er aus den Zeit-Bits jeweils den Schlüssel für die Wetterdaten
berechnet.
Das wurde aber alles weiter oben im Thread schon ausführlich diskutiert.
Reinhard Max wrote:
> Andreas wrote:>> Das heisst in der Summe sind es 42 Bit.>> Der Decoder bekommt nicht nur jeweils die ersten 14 Bit, sondern den> kompletten Datenstrom des DCF77-Signals
selbst mit "nur" 42 bit bräuchte man dann eine Tabelle mit 512GB um alle
ein/ausgabe kombinationen zu speichern.
Und wie gesagt ich hätte es so gemacht: Die Zeit ist der
Initialisierungsvektor (darf ja bekannt sein) und schon purzelt da nur
zufälliges aus dem Encoder --> no chance.
Und das werden dir auch die "crypto freaks" sagen, die haben das nämlich
erfunden ^_^
Also ich denke nicht das es so kompliziert wird. Man muesste sich mal so
eine Uhr mit diesem Chip kaufen und die Ein- und Ausgabe davon loggen.
Soweit ich mich errinnern kann steht hier Thread was davon das nur 42
bit reingehen. Also schonmal keine zusaetzliche Zeit die als Schluessel
dienen kann. Aber das laesst sich ja mit einem Oszi auch nochmal testen.
Das die Zeit als Schluessel dient faellt auch aus dem Grund raus das die
Wetterdaten fuer eine Region immer zur gleichen Zeit gesendet werden.
Wenn man nun die Eingabe in den Chip mitloggt, und auch ein log vom DCF
signal hat dann kann man also rausfinden zu welcher Zeit der Bitstring
der da reingeht uebertragen wurde. Man weiss somit wann die Daten zur
eingestellten Region gesendet wurden.
Aussserdem hat man massig Ein- und Ausgabedaten womit die crypto leute
doch was anfangen koennen sollten. Ein wechselnder Schluessel wurde ja
auch bereits ausgeschlossen weil ausgeschaltete Uhren den ja dann nicht
mitbekommen wuerden.
Die Art des Chips ist damit eigentlich voellig egal.
Sorry Gast, Das simple Loggen von Ein und Ausgabe wäre naiv. Du könntest
zb einfach die 14 Bits mit denen der ersten 14 Bit der Zeitinformationen
XOR erknüpfen und schon sehen die 14 Eingabe und 14 Ausgabebits schön
chaotisch aus. Dieses XOR wäre natürlicht trotzdem leicht knackbar und
dient hier nur als Beispiel.
Die c't hatte doch letztens einen Artikel in dem gezeigt wurde wie sie
RFID Karten geknackt haben Karte in Säure aufgelöst, dann Schicht für
Schicht die Metallayer wegpoliert und mit einem guten Mikroskop +
Digicam hochaflösende Fotos gemacht und so dann den Schaltplan
rekonstruiert. Bei elektrischen Ladungen (Flash) müsste man sicherlich
anders vorgehen da man die wohl nicht unter einem Mikroskop "sehen"
kann.
Soweit ich das verfolgt habe, waren ja die Zeitdaten durchaus Teil des
Systems, also quasi der IV. Ich würde jetzt mal empfehlen, so rund 64
Testmuster mit bekanntem Plaintext zu nehmen und da mal alle Bits in den
Zeitdaten zu toggeln, eins nach dem anderen.
Wenn der Chip das bei keinem der COdes merkt, dan ist das Bit vermutlich
garnicht verwendet. Persönlich vermute ich, dass das wohl rückgekopplte
Schieberegister, implementiert auf dem PIC sind. Einfach und
vergleichsweise effektiv. GSM verwendet das ja z.B. auch.
MfG
Andreas
Also mal ehrlich:
Dieses Datenblatt beschreibt - Wetterdatenprotokoll, Datenblock 1,
Datenblock 2, Datenblock 3, ...
... kann auch bedeuten, das es mehr als 3 Blöcke benötigen kann.
Mal etwas anderes, wie würdet ihr verfahren wenn ihr so eine
Verschlüsselung von Daten machen müsstet?
Ich würde es folgendermaßen bewerkstelligen wenn wenig Ressourcen zur
Verfügung stehen und dennoch einen "relativ" sicher die Daten schütze.
1. Die Daten werden in Blöcke geteilt mit einigen Bits als Erkennung um
welchen Datenblock es handelt.
2. Beim Senden der Daten auch sinnlos generierte Daten zwischen den
Blöcken schieben
3. Transposition der gesendeten Datenblöcke - Block 4, Nichtsbedeutend,
Block 1, Nichtsbedeutend, Nichtsbedeutend, Block 3 ...
4. Transposition der gesendeten Bits
5. Prüfsumme ob die Daten richtig angekommen sind
6. Sind alle Daten eingelangt, so wird eine Zeit abgewartet - wer würde
daran denken, das die Daten die gerade aus dem Chip kommen schon vor
"Stunden" empfangen wurden?
Wenn ich etwas mit so wenig Bits verschlüsseln müßte, dann würde ich
zeitliche Verschiebungen in Betracht ziehen.
Lohnt es sich bei der grobgliedrigen Wettervorhersage überhaupt dafür
einen Euro auszugeben? Da ist doch jeder Blick aus dem Fenster genauer.
Oszi40 wrote:
> Lohnt es sich bei der grobgliedrigen Wettervorhersage überhaupt dafür> einen Euro auszugeben? Da ist doch jeder Blick aus dem Fenster genauer.
Wenn du uns noch erzählst, wie du dem µC beigebracht hast, aus dem
Fenster zu sehen und das Wetter zu erkennen, dann bist du der Held.
Gruß
Rolf
Gottfried S. wrote:
> Mal etwas anderes, wie würdet ihr verfahren wenn ihr so eine> Verschlüsselung von Daten machen müsstet?
----
1. Mit einem simplen Algoritmus wie etwa quisci verschlüsseln. Als
Schlüssel dienen ein fest einprogrammierter Schlüssel (evtl aus einer
Schlüsseltabelle) sowie die Zeit
2. Zu jedem Datensatz einen Fehlerkorrektur-Code erstellen. Das kann
sinnvollerweise nur auf den verschlüsselten Daten gemacht werden
3. Den Datensatz in 3 Happen zerlegen
4. Bits permutieren
----
2. und 3. können natürlich auch vertauscht werden
Unsinnige Daten würde ich keine einstreuen, weil ich ja der Krypto-Held
bin und die Bandbreite nicht so berauschend ist. 4. würde ich mir
wahrscheinlich sparen (aus gleichem Grund, zudem bringt's nicht wirklich
zusätzliche Sicherheit).
Guten Abend,
nachdem ich diesen Thread mehr oder weniger komplett durchgelesen habe,
muss ich sagen: hut ab, es scheint doch noch angagierte Reverse
engenieure zu geben. Ich selber hatte bis jetzt nicht die zeit und die
nötigen Gerätschaften um mich selber mal aktiv mit der Materia
auseinander zu setzen.
Doch das hat sich heute geändert. Ich habe soeben meinen Wecker "TFA
meteotronic star"bekommen, und direkt zerlegt, wer detailfotos haben
will kann mich ansprechen, wobei hier eingentlich schon alles sehr gut
beschrieben ist, ich konnte alles bezüglich verschaltung und aufbau
verifizieren.Generell würde mich mal interessieren, ob dieser thread nur
etwas eingeschlafen ist, oder ob ihr alle die offnung verloren habt?
Ich selber bin noch bis hinter beide Ohren motiviert, wobei es mir
wirklich um den Sportlichen Ehrgeiz geht.....
Hallo Thorsten -
Wohl etwas eingeschlafen, aber es lesen noch genug mit. Wirst du den PIC
mit manipulierten Daten füttern und schauen was er draus macht? Oder was
hast du dir vorgestellt?
Gruß -
Abdul
Bis jetz habe ich nur ein paar ideen gesammelt und werde mal schaun, was
sich davon umsetzen lässt:
zunächstmal wollte ich den pic ein wenig bei der Arbeit beobachten,
obwohl das hier eigentlich auch schon hinreichen dokumentiert ist. Dabei
wollte ich mir mal Gedanken darüber machen, mit welchen neuen Ansätze
zum Thema Reverseengeneering mann evtl was ausrichten könnte(Nein ich
will nichts neu erfinden, nur Sachen probieren, die hier noch ausser 8
blieben); Aber da muss ich mich auch noch ein bisschen mehr einarbeiten.
Ein Zweiter Ansatz wäre es mal einen separaten µC zu bemühen, der sowohl
den Dateneingang, als auch die Ausgabe des Dechiffrier IC überwacht.
Meine vision sag, dass er beides separat mitloggen soll, und z.b. auf
einer SD karte speichern. Der Ganze aufbau kommt dann an einen Ort
meiner Wahl mit geeigneten Empfangsbedingungen. Das würde meiner Meinung
nach eine wirkliche Effektive Langzeitbeobachtung ermöglichen. Dazu muss
ich aber sagen, dass ich eigentlich auch noch andere hobbies habe, und
sich das ganze daher wohl noch etwas hinziehen, bzw einfrieren, wird.
Die dritte und letzte Möglichkeit für mich wird es sein, den Versuch zu
unternehmen ein geeignetes Interface zu entwerfen, welches es einfach
macht den IC mit beliebigen Daten zu füttern, und seine Ausgabe
auszulesen. Diesen Aufabau werde ich dann einem guten(freund und
kryptologen) zum speiel geben : ) Gesetz dem Falle, dass keine der
erwähnten Methoden fruchtet, werfe ich den komischen Wecker aus dem
Fenster...
Och, zum Rauswerfen ist es noch zu früh und sicherlich würdest du auch
einen Abnehmer finden. Eher geht er durch die Bastelei in die ewigen
Elektronengründe.
Dein Freund ist Kryptoanalytiker? Wenn er dann auch von der praktischen
Fraktion ist, wäre das interessant.
In den PIC (wenn er denn richtig identifiziert wurde) paßt nur 1KByte
ROM und die paar Byte RAM lassen eine große Verzögerung auch nicht zu.
Außerdem ist der Hersteller des ICs keine High-Tech Schmiede. Ist die
Frage, ob sie den Auftrag für diese Software selber friemelten oder an
einen "Experten?" rausgaben...
Es klingt so, als hättest du schwierige Empfangsbedingungen?? Darf man
fragen wie weit weg du von Mainflingen wohnst? Daß die Antenne richtig
ausgerichtet werden muß und keine Bildröhre in 1-2 Meter Abstand sein
darf, weißt du schon?
Ich kenne deinen Wecker nicht. Vermute aber er hat ne Ferritantenne wie
alle anderen auch.
Interessant wäre auch, ob es vielleicht andere Funkwecker gibt, die
nicht genau diesen PIC haben, sondern über Lizenz von HKW eine eigene
Implementation. Diese müßte ja kompatibel sein und ist eventuell
leichter hackbar.
Gruß -
Abdul
Das Die kann man untersuchen, das Programm wirst du so jedenfalls nicht
ohne weiteres rauslesen können. Seit vielen Jahren legen die
Chiphersteller genau dafür extra Aluminiumlagen über den Flash-Bereich.
Eine elektrostatische Abtastung ist dadurch unmöglich. Man müßte das Die
abtragen.
Außerdem müßtest du aufwändig rauskriegen, welcher Platz im Flash wo auf
dem Die zuzuordnen ist.
Ist sicherlich letztendlich machbar und es gibt dafür auch einschlägige
Firmen, aber das wird beyond this group sein.
Zur Mifare Karte kann ich wenig sagen. Das war wohl eine hardcodierte
simple Karte mit einem inneren Drahtlayout.
Gruß -
Abdul
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten
