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.
Gast
#520365
@No.1: Den Standort wird der Besitzer wohl selbst einstellen müssen.
Moin!
Dirk W. wrote:
> @No.1: Den Standort wird der Besitzer wohl selbst einstellen müssen.
Den Standort stellt der Besitzer selbst ein. Allerdings werden wohl
Daten für alle Regionen empfangen und die Standort-Einstellung wirkt
sich nur auf die Anzeige aus.
Leider habe ich keinen (bevorzugt mehrkanaligen) Datenlogger verfügbar,
sonst könnte ich mich da mal dranmachen.
Gruß, Didi
Da bin ich nochmal ... Habe gerade gesehen, daß in dem METE-ON 3 eine Art Programmierschnittstelle vorgesehen ist, die über einen kleinen Deckel auf der Unterseite des Gerätes auch von außen zugänglich ist. Habe mal zwei Bilder davon gemacht: http://diet.gmxhome.de/pics/METE-ON3-Stecker1.jpg http://diet.gmxhome.de/pics/METE-ON3-Stecker2.jpg Die Pin-Bezeichnungen lauten VPP, DATA, GND, MODE und VDD. Kann sein, daß man da drüber die Firmware updaten kann. Außerdem noch ein Bild von der Platine samt Decoder-Chip (hinter dem Elko): http://diet.gmxhome.de/pics/METE-ON3-Platine.jpg und eins vom DCF77-Empfänger: http://diet.gmxhome.de/pics/METE-ON3-DCF77.jpg Gruß, Didi PS: Bilder übrigens sind mit einem Sony Ericsson P990i Smartphone im Makro-Modus aufgenommen und von 1600x1200 auf 640x480 runtergerechnet. Gut - die Schärfe (bzw. den Autofocus-Punkt) kann man noch optimieren, aber ich bin so schon ganz begeistert ;-)
Schicke Fotos! Kannst Du nicht mal versuchen, ein Foto möglichst senkrecht auf den Decoder Chip zu machen. Aus dem Layout sollte sich doch wenigstens die Pinbelegung teilweise ermitteln lassen. Nett ist doch, dass sie zur Ankopplung von Debuggern und Logicanalyzern direkt Messpunkte vorgesehen haben. Das erleichtert die Arbeit doch ungemein :) Gruß, Ulrich
Hallo Ulrich, muß ich mal ausprobieren ein besseres Foto zu machen. Ist etwas schwierig wegen der Kabel, die recht kurz sind. Bei Gelegenheit probier ichs mal und bei Erfolg setze ich das Foto hier rein. Gruß, Didi
Gast
#526424
Wetterstationen liefern beim Auslesen keine der APRS-Protokoll-Spezifikation für Wettermeldungen entprechenden Datenstrings. Insofern ist für die Darstellung in gängigen APRS-Anwendungen (z.B. UI-View) oder auf dem TH-D7, TM-D700 eine Umwandlung der Daten erforderlich. Im stationären Betrieb kann eine entsprechende Umwandlung der Daten durch das Programm "UI-Weather" erfolgen. Die hier fragliche Wetterstation WS-2300 wird unterstützt. UI-Weather liest die Datei "curdat.lst" des beigefügten Wetterprogrammes "HeavyWeather" aus und generiert eine Datei "wx.txt". Hier findet sich der APRS-WX-String. UI-View32 greift wiederum auf diese Datei zu und versendet entsprechende Wetterbaken. Problematisch ist der Betrieb hingegen, wenn ein Netzanschluss zur Versorgung eines Notebooks nicht verfügbar ist. Hier greifen komerzielle Hardwarelösungen wie "WX-Trak" von Byonics. Jedoch sind die unterstützten Wetterstationen in Deutschland schwerlich zu erwerben. Ziel ist es mithin, unter Verwendung der Wetterstation WS-2300 und eines TNC, einen APRS -konformen Wetterstring zu erzeugen und als APRS-Bake auszusenden. Der Teil-String soll im Bakentext wie folgt aussehen: _202/000g000t071r000p000b10180h46 Im Beispiel entspricht "b10180" einem Luftruck von 1018.0 hpa. Zusätzlich sollen außerdem im "Statusfeld" weitere telemtrische Daten (z.B. Spannung, Helligkeit, etc.) übertragen werden. Lösung: Zur Lösung wurde von Joachim (DF4IAN) zunächst eine Platine für die Hardware-Kopplung des Einganges an die Wetterstation WS-2300 erstellt. Vermittels der WS.CON-Software (geschrieben mit Microchip MPLAB C18-Compiler in C) werden die über die erste serielle Schnittstelle bei der WS-2300 abgefragten Daten im integirierten PIC-18 F 252 verarbeitet. Der PIC-18 F 252 beinhaltet 32kByte Flash-ROM, 1.5kByte RAM, 256Byte EEPROM, AD-Wandler, Pulsweitenmodulator, serielle Schnittstellen, sowie mehrere Zeitgeber. Der Software-Kern für die Abfrage der Wetterdaten der WS-2300 besteht dabei in aus einer stark modifizerten Version von Kenneth Lavrsen’s (OZ1IDD) open2300-Software. Die Software von Joachim unterstützt in der aktuellen Version aber zudem eine Analogwert-Aufbereitung mehrerer Kanäle, d.h es ist neben der eigentlichen Konversion der Wetterdaten auch ein Übertragen von Analogwerten wie z.B. U, I, Einstrahlleistung/m2, sowie uv-Strahlung möglich. Am Ausgang werden die softwaremäßig im APRS-Format aufbereiteten Datenstrings, welche mit einem Zeitstempel der DCF-77 Uhr der WS-2300versehen sind, über die zweite serielle Schnittstelle an den Aux-Eingang des TNC 2 (mit UI-Digi 1.9 b3 Firmware) übergeben. Die Form der APRS-Protokoll kompatiblen Strings und die Formatierung weiterer telemetrischer Sensor-Daten im Statusfeld des APRS-Strings, läßt sich im Parametriermodus flexibel über eine seriell verbundene Eingabeeinheit gestalten. In der aktuellen Version versteht Joachim das Modul ws.con, über die ursprüngliche Aufgabenstellung hinaus, als flexiblen Technologieträger, bei dem die unterschiedlichsten Eingangsdaten aufbereitet und in ein beliebiges Übertragungsformat umgesetzt werden können.
Hallo Don Schön und gratuliere! Aber was genau hat dein Beitrag mit diesem Thread zu tun? LG Michael
Hallo, ich habe was gefunden was vielleicht auch nützlich ist: bei Conrad gibt es jetzt eine Uhr, die auch für 50 Regionen Wettervorhersagen macht, allerdings soll die eine "satellitengestützte Funkwetterstation" sein. Ist da vielleicht auch so eine die über DCf die daten holt? Sie kostet 49€, für Experimente dann eigentlich eher erträglich als die ELV-Variante. luxx
Gast
#531673
das ist unter http://www.wetterdirekt.com/?key=konzept beschrieben. also über das Pager-Netz. Nix DCF77.
Für mich ist das eine manuelle Wettervorhersage, die über Satelit verbreitet wird.
Gast
#540298
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
...
Gast
#544372
I wrote "CRC", not "CBC". Poul-Henning
@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.
Gast
#550870
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.
Gast
#551941
Nur mal ne blöde Frage: Sagen wir mal einer hätte den Code geknackt, wäre es dann nicht illegal das zu veröffentlichen??
Gast
#551948
Das ist vielleicht ja der Grund für den abrupten Abriss der Diskussion.. Schön wäre dann aber ein Hinweis aus dem Kreis der Eingeweihten.. Wenn es nämlich möglich ist, würde ich es auch mal probieren.
Ich würde mich auch mal über ein paar Infos über den Fortschritt des Loggens und Vergleichens freuen!
Gast
#552090
Kurze Info von T-Systems, die den Sender betreiben: http://www.t-systems.de/tsi/de/92946/Startseite/UeberTSystems/Best-Practice-Online/Ausgabe-01-2007/Projects:%20Zeitzeichen/Projects-KM-2007-01-05-Zeitzeichen
Gast
#560441
Hallo! Unter http://www.meteomarkt.ch/shop/catalog/index.php?cPath=2_16 gibt's den Wecker für mittlerweile ca. 55 EUR - das ist schon eher ein Preis, den ich mir vorstellen kann um ein "Referenzobjekt" zu erwerben. Aber einen Haken gibt's: Versand nach .DE für 22,-- EUR - da stößt sich wohl die schweizer Post an den dt. Kunden gesund :-(
vlt. gibts hier ja einen aus der Schweiz, der das für dich übernehmen kann? Vlt. hätten ja sogar mehr als eine Person interesse...
@all: Wie ist denn eigentlich der Status der Signaldekodierung? Ist da schon irgendjemand weitergekommen?
Gast
#581677
So Leute, Hosen runter! Wieso schreibt ihr nichts mehr?? Aufgegeben? Ich will wissen, ob man das Rätsel lösen kann! Los!
Gast
#586638
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
Gast
#586639
Mist, in meinem ersten Satz fehlt das Wort "Probleme" nach dem 8. Wort. ;-D
Gast
#586642
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!
Gast
#586645
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...
Gast
#589182
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.
Gast
#589183
Kann ich keine Anhänge schicken?
Gast
#589464
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.
Gast
#590166
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.
Gast
#606497
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
Gast
#614305
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?
Gast
#614679
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.
Gast
#615862
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
Gast
#616168
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
Gast
#616726
> Dazu wird man wohl eien DCF77 Geber aufbauen müssen .(AVR) Geht auch standalone: https://erlangen.ccc.de/index.php/DCF77
Hi Das hier ist eindeutig ein Face ;-)
> Das hier ist eindeutig ein Face ;-)
aber ein hüsches...
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.
Gast
#621948
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
Gast
#622339
> 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
Gast
#623931
> 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
Gast
#625540
Hallo Habe mal bei Dexters Text Datei gleiche Outputs gesuchtund habe festgestellt das nichtmal Ansatzweise die Inputs übereinstimmen. Das wird wohl schwierig Mfg Andreas
Ich würde sagen die Zeit und das Datum spielen ins Decoding mit rein. Beides ändert sich in jedem Datenblock und ist niemals (wieder) gleich.
aber dann müsste man ja wenn man in den chip "falsche" daten reinschiebtm also immer gleiche uhrzeit etc auch immer das gleiche rausbekommen?! dann würde man sehen obs so ist oder nicht
Ja genau. Aber das muss eben erst mal jemand ausprobieren. Soweit ich bisher mitgelesen habe hat es noch niemand probiert.
Gast
#626154
Kennt ihr das Cryptool 1.4.10 mfg andreas
Gast
#626197
@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 :-(
Gast
#626469
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 ?
Gast
#626483
Na Cryptool runterladen und los Schlüssel 30Hex mit XOR auf die Inputdaten. Gruss Andreas
Fehlt da zur Vollständigkeit, und um es auch ohne Cryptool nachvollziehen zu können, nicht noch die Information welches der 42 Input-Bits zu welchem de 24 Output-Bits gehört? Denn bei einem einfachen XOR müßten ja input und output gleich lang sein.
Gast
#626590
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
Gast
#627037
Für die "nicht Windowsnutzer" im Anhang eine PDF von Mobifu's Anregungen
Gast
#627052
Interessant auch die automatische Vigenère Analyse: Ermittelte Schlüssellänge: 42 Ermittelter Schlüssel: 101010010101001111100110110011111111111010 Näheres zu Vigenère: http://de.wikipedia.org/wiki/Polyalphabetische_Substitution Aus den Daten in http://www.mikrocontroller.net/attachment/20863/dcf_log_2Tage_59Ticks.txt wird damit: 00001100011010 10111011010111 00011100100110 10101111111101 11101111011000 01100111001100 11001000110001 10001011111010 11101010101010 11101011001110 11101111111011 01111110010010 11000001101101 10111011000001 11111100111001....
Gast
#627153
Wenn ich den diesen Text damit analysiere erhalte ich eine Keylänge von 35 Zeichen . Komisch ? Andreas
Gast
#627504
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.
Gast
#627508
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...
Gast
#627557
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
Gast
#629165
> -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...
Gast
#639157
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
Gast
#640871
> 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...
Gast
#641528
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...
Gast
#642291
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
Gast
#646499
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.
Gast
#647678
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.
Gast
#650725
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.
Gast
#657958
berichtigung: 1010000 0 Minute: 5 010010 0(0) Stunde: 12 << fehler ?! 110010 0(0) Tag: 13 00100 Monat:4 001 Wochentag: 4 01100000 0 Jahr: 6 ###################################### höher als 8 stellen ohne parität gehts im zeitsignal nicht ! minute -1 parität = 7 stellen = 1010000 = 5 stunde -1 parität = 6 stellen = 010010 = 10 ! <<< tag = 6 stellen = 110010 = 13 wo. tag = 3 stellen = 001 = 4 = Donnerstag jahr -1 parität = 8 stellen = 01100000= 6 die geklammerten nullen sind auch zuviel.
Gast
#657967
sorry, monat vergessen: minute -1 parität = 7 stellen = 1010000 = 5 stunde -1 parität = 6 stellen = 010010 = 10 ! <<< tag = 6 stellen = 110010 = 13 monat = 5 stellen = 00100 = 4 wo. tag = 3 stellen = 001 = 4 = Donnerstag jahr -1 parität = 8 stellen = 01100000= 6 bei stunde ist eine null zuviel und beim tag sind am ende 2 nullen zuviel. stimmts nun ?
Gast
#658521
@jupp die 12 uhr angabe ist richtig gewesen mit 010010, auch die 0 am ende der stundenreihe ist zu streichen. und die 00 am ende von der tagesreihe ist auch unverständlich. die frage ist - sind die nullen tatsächlich dabei gewesen, oder sind die versehentlich bei der abschrift dazu gekommen ? folgend ein paar, mit meiner pc-soft aufgezeichnete pakete. 1,5v funkwecker dcf-signale am gameport abgefragt. http://dcf.cya.de die soft für unten stehendes paketformat ist noch nicht verfügbar.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
Moin zusammen! Habe schon ewig nicht mehr hier reingeschaut. Hut ab! Da geht ja echt was in Sachen Decodier-/Dechiffrier-Versuche! Wer selbst noch eine günstige Meteotime-fähige Uhr sucht: bei ELV gibts inzwischen eine für 39,95 EUR mit Vier-Tages-Vorhersage: http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=19148 Das nächstgrößere Modell kostet 59,95 EUR und zeigt noch etwas mehr Daten an (Wind-Vorhersage ...): http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=19151 Sehr günstig, wenn man das mit der Mete-on 1 für 279 EUR vergleicht ... Hier alle "WetterDatenStationen" bei ELV: http://www.elv.de/output/controller.aspx?cid=74&detail=1&detail2=440 Happy hacking, Didi
Gast
#670620
Und schon ist die WFC300 vergriffen :) Hat sie hier Jemand im Forum gekauft?
Gast
#680321
habe einen link gefunden: http://mitglied.lycos.de/gunman0275/dcf77.html
Gast
#692064
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.
Gast
#692102
Das Geschäft mit der Lizenz-Verkauf wurde aufgegeben? Donnerwetter...
Gast
#692107
http://www.eam-magazin.de/download/PIC_DCF_(7-07).HEX wo kann man die zeitschrift kaufen?
in den Bücherläden am Bahnhof gibt es die immer.
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.
Gast
#692134
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. ;-)
Gast
#692144
Ich hätte natürlich erstmal reingesehen.. Auf der meteotime homepage steht nichts von einer aufgabe des lizenzgeschäftes..
Gast
#692166
Hm, ich hab im Kiosk nur kurz reingeschaut und den Artikel gesehen. Sah so aus, als wäre es komplett. Sorry für die "Falschmeldung"
Micha wrote: > Hm, ich hab im Kiosk nur kurz reingeschaut und den Artikel gesehen. Sah > so aus, als wäre es komplett. Sorry für die "Falschmeldung" Ging mir anfangs auch so. In der Mitte des Artikels ist ein Kästchen wo relativ deutlich steht, dass die das Protokoll nicht veröffentlichen dürfen. Es hätte mich auch gewundert, wenn die jetzt doch das Protokoll komplett abdrucken.
Kann der PIC in der Schaltung den verschlüsselte Datensatz von DCF77 entschlüsseln?
Gast
#692353
Also gibt es ein HEX-Datei für einen Pic der das decodieren kann?
Also wie, jezt? Der Artikel sagt, dass nur bekanntes aus den Bits dekodiert wird, aber er sagt auch, dass er was dekodiert, und dann doch wieder nicht. Also ist das lediglich eine DCF-Uhr ohne Wetterinfos, weil die sind ja kodiert und damit unzugänglich. Kann das mal jemand aufklären, bevor alle an den Bahnhof rennen ( der ist hier 25km weit entfernt!) Oder um mich flo anzuschließen: Dekodiert die HEX nun irgendwas außer der Uhrzeit oder nicht? Räzelnd, Ulrich
Die Ausgabe enthält zwei Artikel, die sich mit DCF77 befassen. Der zum Thema Wetterdaten ist eigentlich Werbung für eine bei Conrad für (IIRC) knapp 300 Euro erhältliche Wetter-Uhr und beschreibt nebenbei das bereits bekannte Format der Wetterdaten nach der Entschlüsselung. Die Hex-Datei gehört schätzungsweise zum zweiten Artikel, der dem Titel nach zu schließen eine Bauanleitung für einen "normalen" DCF77-Funkwecker enthält, also ohne Auswertung der Wetterbits.
Mit anderen Worten: Die sind auf dem gleichen Stand wie wir. Dann kann man sich den Kauf sparen. Und DCF77-Uhren gibt es einige hier in der Codesammlung. Gruss Jadeclaw.
Gast
#693194
hallo, bin gerade ganz neu hier bei, und zufällig auf eure fleissige arbeit gestoßen, habe nur nach näheren informationen zu den 14 bits geforscht, da ich aktuell dran bin mit mit einem pic, ein dcf test signal sender zu programieren, da wäre es dann natürlich auch nützlich, sinvolle wetterdaten mit einbinden zu können. zur dekodierung, fände ich es auch erstmal interesant eine komerzielle version von so einem chip zu haben, hat jemand schonmal die wetterstation bei elv gekauft ? und kann mir sagen ob da so ein "loser" chip mit anzapfungs möglichkeiten verbaut wurde ? ich meine die für 39,95, also die nr: 68-761-48 (WFC 300) wenn da so ein ding drin ist, würde ich mir gerne mal eine bestellen, bitte um rückmeldung, möchte nicht das ding jetzt bestellen und dan nacher zurück schicken müssen. dann was in eigener sache, mache auch gerne bei interesse ein eigenen thread auf. zu meinem programieren von dem sender, wenn jemand mit interesse dran hat, mehme immer gerne hilfe an ! hänge aktuell an der FM modulierung der pseudo zahlen, wie muss ich das genau mit dem Phasenhub von ±10 Grad auf den 77,5 kHz verstehen ? also ich takte den pic mit einem 18,228 MHz, was dann heißt, das 4557000 takte einer sekunde endsprechen, bei 77,5 khz und eine schwingung der 77,5 khz gleich 58,8 takte, was sich ja gerade zu anbietet, für eine FM modulation. wie muss ich mir den phasenhub vorstellen, das ich eine abweichung von +- 7,75 khz vornehmen muss, zwichen einem 0 und 1 bit ? also bei interesse, komme aus dem großraum mannheim/ludwigshafen danke im vorraus kiwi_
Bei DCF gibt es nur die Amplituten-Modulation oder die Phasen-Modulation. Es gibt keine Freqeuenz-Modulation die braucht zuviel Bandbreite.
Gast
#693215
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_
Gast
#703042
Da hier immer mal wieder nach dem Decoder IC und hinsichtlich der Lizenzbestimmungen/-kosten gefragt wird. Die jährliche Basis-Lizenzgebühr (geht an Meteotime) für das erste angedachte Anwendungsgebiet kostet 60 Kilo-Euro, jeder weitere Applikationsbereich (es gibt insgesamt 9) kostet 20 Kilo-Euro zusätzlich. Zum Verständnis: Ein Applikationsbereich wäre z.B. der Bereich "Wetterstationen", ein weiterer Bereich "Analoge Armbanduhr" und ein dritter z.B. "Digitale Armbanduhr" Die Lizenzgebühr pro Chip (geht an Meteotime) hängt von der verbauten Stückzahl ab und beträgt zwischen 3 und 17 Euro. Dieser Betrag wird gegen die Jahres-Gebühr verrechnet, bis diese aufgebraucht ist. Die Kosten für den Chip selbst der über hkw (=nominated Supplier) vertrieben wird, ist mit denen mengenabhängig direkt auszuhandeln und nahezu vernachlässigbar (kleiner 3 Euro/St.)
Autsch! 60kEuro Einstiegsgebühr ist schon heftig. Damit will man sich wohl Kleinbetriebe und Bastler vom Hals halten. Gruß Jadeclaw.
Das gibt eine Orientierung, mit welchen Schadensersatzforderungen der erfolgreiche Hacker zu rechnen hat, wenn er sein Wissen öffentlich preisgibt...
Erst mal muss es den "erfolgreichen" Hacker geben... Wenn jemand die Informationen anonym irgendwo zur Verfügung stellt, hier auch nur einen Link dazu postet dann verbreitet sich das so schnell das selbst das löschen der Info oder des Links zu spät kommt. Solltest du der erfolgreiche Hacker sein wäre es eine Schande mit der Info hinterm Berg zu bleiben. Die kommerzielle Aufmachung des Projekts schreit ja schon förmlich nach Reverse Engineering.
Dank Vorratsdatenhaltung wäre das bereits jetzt ein unkalkulierbares Risiko.
Gast
#704557
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.
Gast
#704596
Ich habe einige Informationen destilliert: http://www.mikrocontroller.net/articles/DCF77_Wetterinformationen Vielleicht mögen die, die sich besser auskennen, das noch ergänzen / besser formatieren. Eine Übersicht gibt evtl. neue Ideen..
Moin! Florian ...... wrote: > Und schon ist die WFC300 vergriffen :) Hat sie hier Jemand im Forum > gekauft? Nein, aber seit ein paar Tagen steht hier eine WFC500 ;-) Nettes Gerätchen für den Preis, wenn man das mit der METE-ON 1 vergleicht. Gut, deren Design ist vielleicht etwas schicker, aber sonst kann sie auch nicht mehr ... Jetzt ist übrigens meine METE-ON 3 (dieser Funkwecker mit Wetterempfang und Vorhersage für den aktuellen Tag und die kommende Nacht) übrig. Etwas weiter oben hatte ich Bilder von der Platine verlinkt. Es ist der Decoder-Chip drin - also das richtige Gerät, um damit Decodier-Versuche zu machen :) Gruß, Didi
Gast
#710147
wie kommt man an patent DE 20 2006 017 739 U1 "Einrichtung zum Empfang verschlüsselter Informationen" heran?
Man sucht hier: http://publikationen.dpma.de/DPMApublikationen/qry_pat_beg.do Gib bei Dokumentinformation die Nummer ein.
Gast
#710181
ohne session: http://dpma.de/suche/patentdatenbanken.html
Gast
#710188
jede seite einzeln als pdf.. vielleicht geht der link hier: http://publikationen.dpma.de/DPMApublikationen/pdf_any_pgd.do?hitlistCurrent=2&docId=DE202006017739U1¤tDocId=DE202006017739U1&docDate=29.03.2007&id=8760568&hitlistAll=32
Na dann wißt ihr jetzt, daß der Schlüssel nicht konstant ist, sondern aus der Zeit berechnet wird...
Gast
#710200
genau ihr "böswilligen Nachahmer", und zwar in etwa so: http://publikationen.dpma.de/DPMApublikationen/pdf_any_pgd.do?hitlistCurrent=1&docId=DE3139852¤tDocId=DE3139852&docDate=09.01.1986&id=3383703&hitlistAll=1 Schöne Schrift! Doof wird man davon nicht, auch wenn es dem Entschlüsseln vermutlich nichts nützt..
Gast
#710203
man kann übrigens auch auf 'full document' klicken, wenn man es gefunden hat.
http://de.wikipedia.org/wiki/Kryptoanalyse#Angriffsszenarien Unterüberschrift Known Plaintext... Ihr müßt also die chiffrierten Telegramme und deren Sendezeit sammeln, die dieselbe Anzeige auf dem Display erzeugen.
> http://publikationen.dpma.de/DPMApublikationen/pdf...
1981 angemeldet? Wird wohl kaum speziell für die Wetterdaten erstellt
worden sein.
Gast
#710970
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.
Gast
#710995
aber wo ist der vorteil gegenüber z.b. flughafenwetterdaten, die sich auch so parsen lassen?
Hi! Also das in den Patenten beschriebene Cryptoverfahren macht ein reverse Engineering doch recht schwer. Es ist ja nicht nur, dass der Schlüssel ganz oder teilweise aus der übertragenen Uhrzeit erstellt werden könnte, sondern dass aus dieser Zeit ein Index auf eine Schlüsseldatenbank erstellt werden könnte. D.h. aber, dass es in dem PIC eine COde-Tabelle geben kann, oder sogar Teile oder der ganze Code des PIC als Tabelle selbst dienen könnte. Das bedeutet, dass man, wenn man einen Schlüssel hat, mit diesem am nächsten Tag schon nichts mehr anfangen kann. Die Errechnung des Schlüssels muss also für einen unbestimmt langen Zeitraum geschehen. Dann muss man aus den geknackten Schlüsseln auch noch eine Beziehung zur Uhrzeit ableiten. Zudem nennt das Patent auch eine Option den Schlüssel, bzw. seinen Index aus einer Zeitdifferenz zu bilden... Möglicherweise steckt da also noch mehr Sicherung dahinter. Alles in allem also ein recht mühseliger Weg, wenn man das reverse Engineeren möchte. Gruß, Ulrich
Gast
#712995
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 ;)
Gast
#757275
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
Gast
#790229
Hier 'n Link zum Thema Wetterinformationen: http://www.hkw-elektronik.de/pdfdeutsch/DB%20W-Protokoll-V%201.pdf Schön beschriebener Aufbau des Signals. :-)
Thilo M. wrote: > Hier 'n Link zum Thema Wetterinformationen: > http://www.hkw-elektronik.de/pdfdeutsch/DB%20W-Protokoll-V%201.pdf > > Schön beschriebener Aufbau des Signals. :-) Das nützt nix. Die Daten werden verschlüsselt übertragen. Das zu dechiffrieren ist die eigentliche Kunst, die noch keiner hinbekommen hat.
Gast
#790333
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...
Gast
#790415
>so ein Spaten wie Thilo M.
ich bin kein Gartengerät! ;)
Gast
#797408
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..
Gast
#841013
Wow, ich hatte mir nur mal "just for fun" so eine DCF77 Empfangsantenne gekauft ohne mir vorher gross gedanken drueber zu machen. Als ich dann das Protokoll bei wikipedia nachgelesen hab, bin ich auf die verschluesselte Wetterinfo aufmerksam geworden und bin nach einer Websuche dann hier gelandet. Ich habe nun in ueber 3h den gesamten Thread gelesen und muss sagen "Hut ab!". Ich werde jetzt erstmal nen uC an die Antenne haengen und ne Uhr bauen. Spaeter kann ich dann das ganze auch evtl. mal mitloggen und hierbei helfen.
Habt ihr vielleicht schon daran gedacht, das die Daten auf die 100ms bzw 200ms Sekunde Moduliert werden wie bei einem Radiosender? http://de.wikipedia.org/wiki/Amplitudenmodulation Vermutlich wird auf die 77.5kHz Trägerwelle das Nutzsignal Moduliert, da am Anfang schon erwähnt wurde, das die ersten 14 Bit Amplitudenmoduliert sind.
Hallo, DCF77 ist Amplitudenmoduliert, schon immer... Eine Trägerabsenkung bei den Sekundenimpulsen ist eine AM. Die Impulsfolge auch in den ersten 14 Sekunden muß eingehalten werden, sonst kommt keine übliche Funkuhr mehr klar. Gruß aus Berlin Michael
Die kodierte Zeitinformation wird wie bisher als Amplituden- und Phasenmodulation übertragen http://www.ptb.de/de/aktuelles/archiv/presseinfos/pi2006/pitext/pi061212.htm Lässt sich das mit der Phasenmodulation bewerkstelligen? Dabei würde die bisherigen AM-Empfänger nicht beeinflusst werden? http://de.wikipedia.org/wiki/Phasenmodulation Diese Technik befindet sich doch auch in den aus der Mode gekommenen Modems
Außerdem sieht der Wecker gar nicht mal so schlecht aus http://www.swisswetter.ch/mall/irox-mete-on-3.htm Das einzige was mich jedoch bei allen Funkweckern stört ist: Mit dem Funksignal wird die Uhrzeit, das Datum und der Wochentag gesendet. Ist es nicht möglich einen Funk-Wecker zu machen, den man einstellen kann das er nur von Montag bis Freitag um 06:00 Weckt und am Samstag und Sonntag nicht, ohne das jeden Freitag die Weckfunktion von Hand auszuschalten und Sonntag Abend wieder einzuschalten?
Gottfried S. wrote: > Ist es nicht möglich einen Funk-Wecker zu machen, den man einstellen > kann das er nur von Montag bis Freitag um 06:00 Weckt und am Samstag und > Sonntag nicht, ohne das jeden Freitag die Weckfunktion von Hand > auszuschalten und Sonntag Abend wieder einzuschalten? Gibt es zuhauf, meiner macht das z.B., man kann mehrere Weckzeiten programmieren und zu jeder die Tage festlegen.
Hab einen gefunden :) http://www.corner-shop.de/junghans/cgi-bin/junghans_deta.pl?refnr=150400100 Funktionen: Einzelalarm, Wochenalarm Mo-Fr Währe nett auch mit Wetterdaten alles in einem Gerät, aber man kann vermutlich nicht alles haben
Gast
#841191
@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
Gast
#868786
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
Gast
#868793
Sorry, Der korrekte Link ist: http://thomy-pc.homeip.net/dcflogs.php 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
Gast
#869444
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.
Gast
#869514
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).
Gast
#871610
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
Gast
#871631
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
Gast
#871666
"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
Gast
#871689
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?!
Gast
#871691
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.
Gast
#871692
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.
Gast
#871695
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.
Gast
#871698
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
Gast
#871749
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
Gast
#871855
>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.
Gast
#872190
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
Gast
#872534
ich werde im nächsten semester mal einen meiner prof´s zum thema interviewen .....sonst hab ich für so spielchen grade leider keine zeit ...
Gast
#872603
> 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...
Gast
#872651
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 ^_^
Gast
#872756
Also ich denke nicht das es so kompliziert wird. Man muesste sich mal so eine Uhr mit diesem Chip kaufen und die Ein- und Ausgabe davon loggen. Soweit ich mich errinnern kann steht hier Thread was davon das nur 42 bit reingehen. Also schonmal keine zusaetzliche Zeit die als Schluessel dienen kann. Aber das laesst sich ja mit einem Oszi auch nochmal testen. Das die Zeit als Schluessel dient faellt auch aus dem Grund raus das die Wetterdaten fuer eine Region immer zur gleichen Zeit gesendet werden. Wenn man nun die Eingabe in den Chip mitloggt, und auch ein log vom DCF signal hat dann kann man also rausfinden zu welcher Zeit der Bitstring der da reingeht uebertragen wurde. Man weiss somit wann die Daten zur eingestellten Region gesendet wurden. Aussserdem hat man massig Ein- und Ausgabedaten womit die crypto leute doch was anfangen koennen sollten. Ein wechselnder Schluessel wurde ja auch bereits ausgeschlossen weil ausgeschaltete Uhren den ja dann nicht mitbekommen wuerden. Die Art des Chips ist damit eigentlich voellig egal.
Sorry Gast, Das simple Loggen von Ein und Ausgabe wäre naiv. Du könntest zb einfach die 14 Bits mit denen der ersten 14 Bit der Zeitinformationen XOR erknüpfen und schon sehen die 14 Eingabe und 14 Ausgabebits schön chaotisch aus. Dieses XOR wäre natürlicht trotzdem leicht knackbar und dient hier nur als Beispiel. Die c't hatte doch letztens einen Artikel in dem gezeigt wurde wie sie RFID Karten geknackt haben Karte in Säure aufgelöst, dann Schicht für Schicht die Metallayer wegpoliert und mit einem guten Mikroskop + Digicam hochaflösende Fotos gemacht und so dann den Schaltplan rekonstruiert. Bei elektrischen Ladungen (Flash) müsste man sicherlich anders vorgehen da man die wohl nicht unter einem Mikroskop "sehen" kann.
http://www.hkw-elektronik.de/pdfdeutsch/DB%20W-Protokoll-V%201.pdf hilft das evtl weiter oder schon bekannt? vermute ich mal...
Soweit ich das verfolgt habe, waren ja die Zeitdaten durchaus Teil des Systems, also quasi der IV. Ich würde jetzt mal empfehlen, so rund 64 Testmuster mit bekanntem Plaintext zu nehmen und da mal alle Bits in den Zeitdaten zu toggeln, eins nach dem anderen. Wenn der Chip das bei keinem der COdes merkt, dan ist das Bit vermutlich garnicht verwendet. Persönlich vermute ich, dass das wohl rückgekopplte Schieberegister, implementiert auf dem PIC sind. Einfach und vergleichsweise effektiv. GSM verwendet das ja z.B. auch. MfG Andreas
Also mal ehrlich: Dieses Datenblatt beschreibt - Wetterdatenprotokoll, Datenblock 1, Datenblock 2, Datenblock 3, ... ... kann auch bedeuten, das es mehr als 3 Blöcke benötigen kann. Mal etwas anderes, wie würdet ihr verfahren wenn ihr so eine Verschlüsselung von Daten machen müsstet? Ich würde es folgendermaßen bewerkstelligen wenn wenig Ressourcen zur Verfügung stehen und dennoch einen "relativ" sicher die Daten schütze. 1. Die Daten werden in Blöcke geteilt mit einigen Bits als Erkennung um welchen Datenblock es handelt. 2. Beim Senden der Daten auch sinnlos generierte Daten zwischen den Blöcken schieben 3. Transposition der gesendeten Datenblöcke - Block 4, Nichtsbedeutend, Block 1, Nichtsbedeutend, Nichtsbedeutend, Block 3 ... 4. Transposition der gesendeten Bits 5. Prüfsumme ob die Daten richtig angekommen sind 6. Sind alle Daten eingelangt, so wird eine Zeit abgewartet - wer würde daran denken, das die Daten die gerade aus dem Chip kommen schon vor "Stunden" empfangen wurden?
7. Eine vereinfachte Darstellung der Auswertung um diejenigen, die zu entschlüsseln versuchen in die Irre zu leiten
Gast
#874411
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
Gast
#900167
Man könnte von dem Encoderchip das Die freilegen und mitm Mikroskop den Schaltplan ausfindig machen. (So ähnlich mit mit der Mifare Karte in der c't)
Gast
#900168
Man könnte von dem Encoderchip das Die freilegen und mitm Mikroskop den Schaltplan ausfindig machen. (So ähnlich wie mit der Mifare Karte in der c't)
Das Die kann man untersuchen, das Programm wirst du so jedenfalls nicht ohne weiteres rauslesen können. Seit vielen Jahren legen die Chiphersteller genau dafür extra Aluminiumlagen über den Flash-Bereich. Eine elektrostatische Abtastung ist dadurch unmöglich. Man müßte das Die abtragen. Außerdem müßtest du aufwändig rauskriegen, welcher Platz im Flash wo auf dem Die zuzuordnen ist. Ist sicherlich letztendlich machbar und es gibt dafür auch einschlägige Firmen, aber das wird beyond this group sein. Zur Mifare Karte kann ich wenig sagen. Das war wohl eine hardcodierte simple Karte mit einem inneren Drahtlayout. Gruß - Abdul
aber weiso nicht einfach das die freilegen, lockbits löschen(UV o.ä.), auslesen und ab in den disassembler?