Meteotime Crypt

Poste doch mal deine RAM-Dumps, dann können andere auch drüber 
nachdenken.

Viele Grüße,
Sebastian

Wäre auch sehr an den RAM-Dumps interessiert!
Schreib aber noch bitte dazu mit welchen Inputdaten du das probiert 
hast. Setzt der PIC seinen RAM eigentlich kurz nach dem Start auf 0x00, 
0xFF oder macht der da gar nichts?

Im Anhang mal als Beispiel ein Dump.
Ein paar Anmerkungen:

- im ersten Dump wurde zuvor ein Null Telegramm geladen und der 
Controller noch ein paar Zyklen laufen lassen (umkopieren)
- ab dem 2.Dump sind die "echten" Daten geladen
- die Zahl vor dem Doppelpunkt stellt die Wartezeit in ca.800ns 
Schritten nach dem Laden des Telegramms dar
- es werden nur Dumps angezeigt, wenn sich im RAM etwas geändert hat
- ein Jittern ist daran zu erkennen, dass sich mehr als ein Byte im RAM 
geändert hat. Ist meiner Meinung nach in einem Zyklus nicht möglich
- es wird mit dem Telegram laden nicht gewartet, bis der Chip bereit 
ist. Es handelt sich um das Test Telegram aus dem 1.Thread. Das kann 
anscheinend sofort nach einem Reset geladen werden
- für jeden Dump wird der Controller neu gestartet und das Telegram 
erneut geladen, da das mit dem Unterbrechen und weiterlaufen lassen zwar 
klappt, nur ist es mir noch nicht gelungen, das RAM "non invasiv" 
auszulesen (W-Reg, Status, TRIS, GPIO, FSR werden geändert. Zudem 
brauche ich noch 2 Byte für Bit Count und das zu sendende Byte - aber 
ich arbeite dran ;-)
- die Marken oben und rechts geben Zeile und Spalte an, in denen sich 
was geändert hat
- der Strich in der Mitte steht zwischen Byte 7 und Byte 8 der aktuellen 
Zeile um das Zählen zu erleichtern
- Daten von 0x20-0x2F fehlen, da dieser Bereich physikalisch nicht 
implementiert ist und 0x00-0x0F wiederspiegelt

Nochmal zum ungefähren Ablauf am Anfang:
- Daten werden geladen nach 0x36-0x3F
- Daten werden umkopiert nach 0x16-0x1F
- 0x36 und 0x37 werden gelöscht
- 0x37 wird auf 1 gesetzt
- Bit 0x3B.0 (erstes Telegram Bit) wird auf Null gesetzt (oder 
invertiert)
- das gleiche in der Kopie an Adresse 0x1B
- dann werden die Daten "verarbeitet"
- Byte 0x10 wird immer mal wieder von 5 nach 0 heruntergezählt
- Byte 0x11 wird von 0x0F heruntergezählt
- Bytes 0x13-0x17 hängen irgendwie zusammen (Ergebnis, Teilergebnis ?) 
und werden immer mal wieder auf 0 gesetzt
- kurz davor werden die Bytes 0x07-0x0E geändert

Das mal als erster Wurf.

Ich arbeite noch daran vor jedem Telegram den Zähler an Adresse 0x33 
(momentan immer 0x0F) auf 1 zu setzen ohne das RAM oder die Flags zu 
verändern um so den Chip "Glauben zu machen", die 15 Watchdog Resets 
seien bereits durch. Das hätten wir das ganz "real".

Walter.

Danke für den Upload!

Sehe mir gerade die ersten 150 Stück an.
Das ganze sieht nach Schieberegistern aus die durch den Carry schieben. 
Das rausgeschobene Bit wird oft an das nächste Schiebebyte vorne 
angehängt.

Am Ende eines Schleifendurchlaufs wird noch irgendwas anderes mit den 
Daten gemacht, evtl. per AND ne Maske drüber und dann per XOR mit einer 
anderen Speicherstelle verknüpft?
Sieht ähnlich zu diesem Code aus: 
http://www.mikrocontroller.net/attachment/42711/Meteo1.asm

Ganz exakt ist ers aber offenbar nicht, oder?
Ich such jetzt einfach mal weiter...
Meine Hoffnung ist es, dass wir irgendwo eine Schleife finden die ein 
paar hundert mal durchläuft und uns so VIEL Analyse sparen können.

//EDIT:

Eine Erklärung für das Ändern mehrerer Bits hab ich jetzt aber auch 
nicht... Besonders nicht wenn das in EINEM Clock stattfindet

zu Ändern mehrerer Bytes:

Das kommt daher, das für jedes RAM-Dump der Controller neu gestartet 
wird.
Wenn die Zeit sehr kurz ist, hat man gute Chancen jeden Zyklus zu 
treffen.
Z.B nach 10us wird es mit ziemlicher Sicherheit der 10. Befehl sein.
Aber nach 1000us kann es durchaus bei einem Durchlauf der 995., beim 
nächsten mal der 1003. Befehl sein.

Ich habe in den Dumps bisher nichts gefunden, das zu dem ausgelesenen 
Code passt. Dort werden 10 Byte "am Stück" rotiert (ob jetzt 0x12-0x1B 
oder 0x32-0x3B). Zudem werden die Schleifenzähler geladen:

0x10 (oder 0x30) = 0x40
0x11 (oder 0x31) = 0x04

Habe mir bisher aber auch nur die ersten ms angeschaut.

Als nächstes steht bei mir das "Find-RETLW" auf dem Programm. Ich hoffe, 
das bringt uns nochmal weiter.

Walter.

war nicht angemeldet... ;-)

Ich habe das Testtelegramm genommen, da dieses wie gesagt anscheinend 
nach einem Reset immer akzeptiert und decodiert wird.

Wenn ich ein anderes Telegramm sende, wird dieses im Speicher ausgenullt 
und dann der Decodierprozess gestartet, wenn ich das richtig gesehen 
habe.

Es steht folgendes auf dem Plan:

1)
Non-Invasiver Monitor: es wird im RAM nichts verändert (ausnutzen von 
konstanten RAM Werten). Dann sollte es möglich sein, das Telegramm 
wirklich nur einmal zu senden und den Controller beliebig oft zu 
unterbrechen und das RAM auszulesen.

2)
Alternativ könnte vor jedem Telegramm der WDT Counter an 0x33 auf 1 
gesetzt werden, so dass beim nächsten WDT Reset der Counter auf Null 
gesetzt wird.
Dabei ist zu beachten, dass das Bit FSR.5 auf 1 gesetzt werden muß, da 
sich das Bit 0x33 in RAM Bank 1 befindet und ich nicht weiß, auf welcher 
Bank der Controller zum Zeitpunkt der Unterbrechung war. Also muß ich 
dieses Bit sichern und den Zähler auf 1 setzten. Dabei darf sich aber 
auch nichts anderes ändern (W, Z-Flag, C-Flag etc.) oder muß gesichert 
werden.

3)
Der Vorschlag von Abdul K., dass beim Hochsetzen von /MCLR von VCC auf 
VPP eine Art Interrupt ausgelöst wird klingt plausibel. Das wäre das 
wahrscheinlich taktsynchron. Es gilt noch zu klären, ob der aktuelle 
Befehl noch abgearbeitet wird (so kenne ich das normalerweise) oder 
abgebrochen und nach dem Interrupt nochmal ausgeführt wird (soll es wohl 
auch geben). Des weiteren muß geklärt werden, ob es einen spziellen 
Stack (interes Register) für den Programm Counter gibt oder ob der 
Standart Stack verwendet wird (dann würde es ein Problem geben, wenn der 
Stack schon voll ist -> Überlauf)

Walter.

@Johannes:
16x5=80 Lassen wir mal die Frage nach der Null weg. Dabei müssen dann 
alle Bits um eine Position verschoben werden.
Waren wohl 40 Bits im Telegramm. Oder meinst du mit der 5 bereits das 
Shiften der 40 Bits?
Wie auch immer, das ist ne Menge! Zumal nach jedem Shift des vollen 40 
Bit Wortes jedes der Bytes vermutlich mit XOR und/oder AND bzw. OR 
verknüpft werden.
Das ist doch das typische Prozedere für 'asymmetrische' Verschlüsselung. 
Bei Wiki werden diese Verfahren sicherlich ausführlicher zu finden sein. 
Das XOR ist symmetrisch, das AND/OR aber nicht! Irgendwo kommen die 40 
Bits dafür her.
Das könnte z.B. ein 40-Bit Wort generiert aus der aktuellen Zeit sein.

Da es nur ein schnöder 8-Bitter ohne Barrelshifter ist, würde ich 
schonmal die 250ms als echte abgelaufene Zeit ansetzen.


Wird denn der Code nahe Null WANN ausgeführt? Also gehört er zu 
Time-Bits oder Wetter-Bits?

@Walter
Schonmal üvberlegt ob der Testdatensatz garnicht dekodiert wird, sondern 
einfach ein ausgabewort ausgegeben wird, gut der PIC mag wohl viel im 
Speicher rühren, aber wäre es nicht denkbar, das ein "echter" Datensatz 
anders verarbeitet wird?

Gruß
Thomas

Ein Fake-Ausgabe ist natürlich überall möglich.

Anders herum gedacht natürlich:
Woran merkt der decoder das es ein Testdatensatz ist?
Vielleicht gibt es ja mehrere, wenn das ein echter Datensatz ist, der 
auch wirklich dekodiert wird, und nicht irgendwie generiert, dann dürfte 
man doch mal ausprobieren ob es dort noch einige mehr gibt, und da kann 
man schön mit Bruteforce dran gehen, so viele wie möglich in kurzer zeit 
durch den Decoder schicken.

Ja, die Idee ist mir auch schon gekommen :-(
Laut LOG vergehen ca.18 Zyklen, bevor mit dem umkopieren begonnen wird.
Wenn ein anderer gültiger Datensatz eingeschoben wird solange 0x33 !=0 
ist wird dieser ausgenullt und zwar direkt im Anschluß an das 
Reinschieben.
In 0x30 zählt während des Einschiebens ein Zähler rückwärts von 0x82 bis 
0x00. Sonst ändert sich, soweit ich das gesehen habe nix. Ich gehe 
deshalb davon aus, dass in W eine Checksumme während des Einschiebens 
gebildet wird und am Ende es Einschiebens mit einem (oder mehreren) 
Werten verglichen wird. Wenn dieser Wert nicht stimmt, wird genullt. 
Vielleicht kann der RAM-Monitor erweitert werden, so dass auch das 
W-Register sichtbar wird.
Ich hänge meinen aktuellen Monitor nachher mal an, evtl. hat ja jemand 
ne Idee...auch wegen "nicht invasiv".

@Johannes O.:
0x00-0x06 sind die Config Register des PIC:

0: INDF (nicht Physikalisch sondern der Inhalt der Zelle auf die FSR 
zeigt)
1: Timer
2: ProgramCounter bit 0-7 (PCL)
3: STATUS Register
4: FSR (s.oben)
5: OSCAL (zum Trimmen des internen Oszillators)
6: GPIO (E/A Port)

Am Ende der letzten Steinzeit brachte jemand die Aussage, es könne 
bereits der nächste Datensatz während der Dekodierung reingeschoben 
werden. Vielleicht geht deine Beobachtung in diese Richtung.

Fies wäre es, wenn der Chip auch die Plausibilität einer Serie von 
Datenblöcken überwacht. Obwohl es wohl bislang dafür keinen Hinweis 
gibt, wenn ich mir so eure Versuche ansehe.
Damit zusammenhängend, könnte es ja noch Ersatz-Keys geben. Falls einer 
schmutzig wird. Das hatte ich schonmal bemerkt zu Beginn der Eisenzeit.

Danke für die Erklärung mit den Bytes von 0x00 bis 0x06

Ich habe bisher auch nie bemerkt, dass die Datenblöcke untereinander 
verglichen werden. Zumindest hatte ich noch nie einen unerwarteten 
Dekodierungsfehler. Das wäre auch sehr schwer für den Chip 
festzustellen, denn der RAM scheint ziemlich ausgenutzt zu sein und es 
ist sehr gut möglich, dass bei einem ungünstigen Standort der Uhr, 
einfach die Hälfte der Daten nicht richtig ankommt. Dann will man ja die 
andere Hälfte sicher auch nicht verlieren.

Hatte noch eine Idee bzgl. Jitter und Timingproblemen beim Reset:
Soweit ich das sehe wird der interne Timer doch nicht verwendet, oder? 
Kannst du den eigentlich selbst starten und mitlaufen lassen? Falls ja, 
könnte man sehr exakt Timen, da der Timer ja an den internen Oszillator 
gekoppelt ist? Wenn man den hernach ausliest wüsste man recht genau an 
welcher Stelle man gestoppt hat. Sollte das klappen, so würde die 
Genauigkeit vermutlich knapp über die Gesamte Rechenzeit ausreichen? Im 
Worst-Case würde man eine Verschiebung von mehr als 0xFF haben, was man 
ja erkennen müsste, da dann viele Bits gekippt sein müssten.
Das Statusregister überlebt aber nicht, und W wird noch nicht 
ausgelesen, oder? Bei meinen aktuellen Versuchen hatte ich immer das 
Problem, dass ich oft nicht weiß was der im Statusregister und im W 
stehen hat. Manchmal löscht er das Carry bevor er SHIFT macht. Und viel 
wird auch nur in W gemacht und nur endgültig in den Speicher 
zurückgeschrieben.

Ist nur mal so als Anregung gedacht, evtl. bringts dich ja auf ne neue 
Idee! Ich werd morgen mal testen, ob man irgendwie die Clocks an der 
Versorgungsspannung messen kann. Hab zwar erstmal leider nur nen Atmega 
da weil ich nichts mit PICs mache, aber evtl. bringts ja eine 
Erkenntnis!

Es ist eigentlich recht üblich, dass man Informationen, die gesichtert 
übertragen werden müssen, bei denen es aber auf die Echtzeitigkeit nicht 
ankommt, über mehrere Pakete inweg verteilt.
Auf einer CD stehen die Audio-Daten ja auch nicht sequenziell, sondern 
immer um x Sektoren versetzt. Jeder Sektor beinhaltet aber 
Redundanzinformationen für die Sektoren davor.
Man kann also aus den Resten eines Sektors + die Red-Infos aus den 
nachfolgenden Sektoren wieder ein fehlerfreies Audiosignal generieren.

Wenn ich Meteotime wäre, würde ich genau das auch so machen, denn 
Störungen sind mit hoher Wahrscheinlichkeit Peaks, die nur einzelne Bits 
vernichten. Übertrage ich aber die Informationen gemischt mit 
Redundanzinformationen in zeitversetzten Paketen, dann kann ich Fehler 
korrigieren.

Was jetzt mal wichtig wäre ist, ob vorangegangene Daten immer im 
Speicher bestehen bleiben. Ich vermute, dass es da einen unterschied 
zwischen den beiden schon gefundenen Chips gibt, die ohne 
Fehlerkorrektur und die mit.
Wenn ich weiter oben lese, dass der Chip den FIFO oben im RAM löscht, 
einschiebt und dann komplett umkopiert, dann wird der vermutlich keine 
Fehlerkorrektur haben.
Aber auch das kann man nicht genau sagen, denn der Chip kann ja nur die 
Wetterdaten für eine Zone anzeigen. Also wird er auch nur die 
Wetterdaten für eine Zone zwischenspeichern. Und vermutlich ist das 
Protokoll + Redundanzinfo so ausgelegt, dass er nicht komplette 
Telegramme, sondern nur den für sich relevanten Teil speichern muss.

Die Redundanzinformationen für Zone x könnten ja mit einem Offset in den 
Daten für Zone y versteckt sein. Das Papier über die Zoneninformation 
legt zwar nahe, dass diese Informationen in irgend einer Form auch so in 
den Verschlüsselten Informationen vorhanden sein muss, aber das muss 
eigentlich garnix miteinander zu tun habe.

Das nur mal als Anregung.

Gruß, Ulrich

Eine Anregung ist immer gut, aber es scheint mir doch du hast wenig 
Übersicht über die Sache hier. Bist wohl gerade eingestiegen?

Daher zwei Punkte von mir:
1. Es wurde bereits dargestellt, das der Chip verdammt wenig RAM hat. 
Man erkauft bessere Fehlerkorrektur IMMER mit mehr notwendigen lokalen 
Speicher und einer erhöhten Durchlaufzeit (wenn man von gleicher 
algorithmischer Stärke ausgeht, also jeweils den gleichen Grundansatz 
benutzt).
2. Fehlerkorrektur basiert IMMER auf der Erweiterung der Information auf 
mehrere Bits. Anders kann es überhaupt nicht funktionieren. Ob diese 
Bits im gleichen Datenframe oder etwas davon entfernt sind, ist erstmal 
für den Algorithmus unerheblich. Es macht nur für die zeitliche 
Verteilung der Fehlerwahrscheinlichkeit einen Unterschied. Den Burst als 
Beispiel einer typischen lokalen Verringerung des S/N hast du bereits 
genannt. Daher fittet man den Algorithmus auch an die jeweilige 
Problemstellung, also die typischen Fehlereigenschaften des Kanals.


Mir ist keine Verschlüsselung bekannt, die sowohl verschlüsselnd und 
gleichzeitig fehlerkorrigierend ist. Mag sein, daß es sowas gibt.
Ich tippe eher auf einen klassischen zwei Ebenen Ansatz:
3. Fehlerkorrektur und danach erst
4. Entschlüsselung

Wobei das Protokoll natürlich von vonherein die Option für die 
Fehlerkorrektur besitzen muß (also dies auf Senderseite implementiert 
sein muß). Was aber auch bedeutet, das ein nichtkorrigierender Empfänger 
eine Möglichkeit zur Überprüfung auf Korrektheit haben muß. (Das wurde 
ja auch beobachtet)

Es ist auch klar, das solange die Verschlüsselung NICHT gleichzeitig 
verschlüsselnd und fehlerkorrigierend ist, auf jeden Fall Punkt 3 und 4 
nicht vertauscht werden können (zumindest nicht ohne Informationsverlust 
in den Nutzdaten).

Ich habe unsere Freunde von der FPGA Front mal angetriggert. Daten haben 
wir ja genug.
Beitrag "Re: Bitcoin-Mining mit FPGA?"

Abdul K. schrieb:
> Eine Anregung ist immer gut, aber es scheint mir doch du hast wenig
> Übersicht über die Sache hier. Bist wohl gerade eingestiegen?

Ne, nicht wirklich. Bin eigentlich von Anfang an dabei, aber mehr passiv 
lesend da ich nicht eine entsprechende Uhr habe und im vergangenen Jahr 
auch keine Zeit dafür übrig war.

Abdul K. schrieb:
> Mir ist keine Verschlüsselung bekannt, die sowohl verschlüsselnd und
> gleichzeitig fehlerkorrigierend ist. Mag sein, daß es sowas gibt.
> Ich tippe eher auf einen klassischen zwei Ebenen Ansatz:
> 3. Fehlerkorrektur und danach erst
> 4. Entschlüsselung

Also wenn man die Informationen mit Redundanzen versieht und diese dann 
auf mehrere Pakete verteilt bzw. die Redundanzen an verschiedene Stellen 
packt, dann brauchts keine Verschlüsselung sondern nur noch eine geheime 
Prüfsumme und / oder eine geheime Verscchiebung der Information um die 
Telegramme
a) völlig unzusammenhängend erscheinen zu lassen
b) sich gegen Fake-Telegramme zu schützen.

Am Beispiel der vielen gehackten Funk-Termometer Protokoll kann man das 
recht schön nachvollziehen:
Es werden immer mehrere Telegramme mit einer Information versendet. 
Anhand eines Mehrheitsentscheids kann man die korrekte Information auch 
bei Störungen von einem oder mehreren Paketen (nur bei Störungen an 
verschiedenen Stellen) zurück rechnen.
Die Prüfsummen sind in diesen Telegrammen an mehreren Stellen aufgeteilt 
zu finden und jeweils nur für einen Bereich zuständig.

Zurück zum Problem:
Ich habe übrigens nirgendwo gelesen, dass das Protokoll linear die 
Informationen für alle Vorschautage beinhaltet. Es sind beliebig viele 
Kombinationen möglich. Die Verschlüsselung ist überhaupt nicht nötig, so 
lange niemand den Algorhythmus kennt, mit dem die richtigen Bits aus dem 
Telegrammstrom gezogen werden. Den wiederum kann ich dann auch noch aus 
der Zeit generieren, denn zum einen schaut die eh im Telegramm mit 
vorbei und ich kann sie grob selber nachhalten. Und das ganze passt 
wunderbar in den kleinsten Controller.

Einfache Tests um das mal zu eruieren sind:

Ohne Bastelei: Hat die Uhr immer zum exakt gleichen Zeitpunkt die 
aktuellen Wetter-Infos nach dem einschalten? Sind also die Städte an 
eine feste Uhrzeit gebunden?
Tauchen die Wetter-Infos für Tag, Tag+1... Tag+n immer gleichzeitig oder 
immer in gleicher Reihenfolge oder zufällig auf?

Bislang liest man hier nur, dass er sich das komplette Telegramm in den 
Speicher lädt und dann irgendwo hin umkopiert. Es müsste aber auch einen 
Speicher geben, wo das auszugebende Telegramm erzeugt wird. Baut sich 
dieser Speicher aus dem einen richtigen Telegramm oder aus verschiedenen 
Telegrammen auf? Verändert sich der Speicher auch in die richtige 
Richtung, wenn einzelne Bits gestört werden?
Letzteres wäre eine Bestätigung dafür, dass die Infos für einen Ort in 
mehreren Telegrammen geshuffelt sind.

Ich meine dass das alles sehr viel über die Stellen verrät, an denen man 
suchen kann.

Ach ja und dass das HKW Datenblatt sagt, dass die Telegramme um Uhrzeit 
+ X Täglich mehrfach zur Verfügung stehen heißt auch genau nur das. Da 
steht nicht, dass sie auch dann ausgestrahlt wurden. Sie sind vielleicht 
auch erst dann wirklich vollständig.

Gruß, Ulrich

Ulrich P. schrieb:
> Einfache Tests um das mal zu eruieren sind:
>
> Ohne Bastelei: Hat die Uhr immer zum exakt gleichen Zeitpunkt die
> aktuellen Wetter-Infos nach dem einschalten? Sind also die Städte an
> eine feste Uhrzeit gebunden?
> Tauchen die Wetter-Infos für Tag, Tag+1... Tag+n immer gleichzeitig oder
> immer in gleicher Reihenfolge oder zufällig auf?

In einem Dokument steht, um welche Uhrzeiten für welche Regionen die 
Wetterdaten gesendet werden. Es liegt daher eine feste Bindung vor.

Es liegt definitiv eine Feste Bindung vor, diese ist an die UTC 
gebunden.

Ich habe mal ein Screenshot von meinem dokument angehängt. Das Dokument 
darf ich aus urheberrechtlichen Gründen jedoch nicht öffentlich 
verfügbar machen.

Es handelt sich um eine Zusammenfassung aller Fakten und Daten, viel ist 
auhc aus der HKW-Pdf kopiert.

Ich habe heute mal Versuche wegen den Timingproblemen gemacht. Also bin 
ich an der Uni an ein Oszi und hab mal ein wenig gemessen. Probiert hab 
ichs mit einem Atmega16, nachdem ich keine PICs habe. Der Takt war auf 
1MHz (intern) gestellt.
Mir ist klar, dass dies nur Anhaltpunkte gibt und sich nicht komplett 
auf den PIC übertragen lässt. Es ging mir nur um die Machbarkeit!

Zum Messaufbau:
Der Atmega wird mit 5V versorgt, Abblockkondensatoren wurden BEWUSST 
weggelassen (mit ihnen funktioniert es NICHT). Die Leitungen wurden auch 
etwas verlängert. Die Versorgungsleitung wurde um irgendeine Spule 
(50µH) AUßEN herumgeführt, da ich keinen Ringkern finden konnte mit dem 
man sowas normalerweise macht. An die Spule selbst ist an das Oszi 
angeschlossen.
Bild 1: Dort ist dies zu sehen.

Bild 2: Oszi ist auf 200mV/Div eingestellt. Das Signal ist ca. 0.75V 
stark. Die Schatten die zu sehen sind, sind die Unterschiede in der 
Stromaufnahme je nach Befehl (hier z.B. RJPM im Vergleich zu vielen 
NOPs). Interessant ist, dass das Signal 2MHz hat. Fallende und Steigende 
Flanke die jeweils einen Impuls verursachen?
So ein Sinus kommt nur raus, wenn man die Spule dafür anpasst. Das muss 
man einfach ausprobieren. Bei mehr Windungen wurde das Signal deutlich 
schlechter! Ebenfalls bei weniger Windungen. (der genaue Verlauf ist ja 
nicht wichtig, sondern nur die Frequenz sollte deutlich sein, daher ist 
ein Sinus besser geeignet als das was "wirklich" passiert).

Bild 3: Rausgezoomt. Man sieht einzelne Peaks. Das sind die RJMP und die 
kleineren Dinger sind die NOPs. Ich konnte dies Verifizieren indem ich 
verschiedene Befehle ausgeführt habe, die jeweils zu anderen Bildern 
führten. Dazu konnte ich auch die NOPs zählen (bei anderer Zeitbasis).

Bild 4: Nochmal direkt (violett) am Mikrocontroller abgegriffen. Man 
sieht dass sich über die Spule nicht irgendwas anderes eingekoppelt hat, 
sondern dass es sich wirklich um den Strom handelt. (man beachte auch 
die Empfindlichkeit: 10mV/div zu 200mV/div, man erhält also mit der 
Spule schöne Spannungen).


Meine Folgerung: Auch wenn dies nur ein Atmega ist der auch etwas mehr 
Strom zieht: Ich denke dieses Vorgehen würde sich auch auf den PIC 
übertragen lassen.
Ein schneller OPV sollte die Spannung um einen kleinen Faktor 
verstärken, einen Komparator müsste man nachschalten der beim 
Nulldurchgang umschaltet und dann könnte man einen Timer hochzählen 
lassen bei jeder steigenden Flanke. Die genaue Formel zur Umrechnung 
Flanken/Clocks muss man noch ermitteln (hat der PIC nicht einen internen 
Taktteiler von 4?), wird daher also entweder 4 oder 8 sein. Verstärken 
müsste man beim PIC vermutlich auch mehr, da er weniger Strom zieht. 
Evtl. könnte man auch die Spule anpassen. Nach ein paar Minuten und 2 
Versuchen hatte ich das Optimum gefunden, geht also recht flott.

So könnte man dann die einzelnen Take DIREKT zählen ohne Probleme mit 
dem Jitter oder so zu bekommen.

@Ulrich:
Ich finds gut wenn jemand neue Ansätze bringt. Eventuell dreht man sich 
sinnlos im Kreis. Allerdings kann ich momentan keinen Hinweis auf deine 
Ideen sehen.
Verschlüsselung ist ein weiter Begriff. Darunter stelle ich mir auch 
Vertauschen, Verzögern, XORen usw. vor. Klar, echte Kryptos sehen das 
sicherlich anders.
Es hängt auch sehr davon ab, ob man weiß was man sucht. Ist der 
Plaintext bekannt (so wie hier), wird die Sache viel einfacher! Anderes 
Beispiel wäre die Enigma im W2, wo die Engländer nur wußten es gibt 
gültige sinnvolle Botschaften, aber nicht welche!

@Johannes:
Mit der Spule hast du eine Resonanz erzeugt. So Stabkerne haben meist 
die ersten Resonanzen bei einigen 10MHz.
Könnte mir vorstellen, man findet mit dieser Methode zumindest den 
exakten Takt des PIC. Mehr wird aber nicht drin sein. Höchstens noch 
Pausen oder kleine Loops.
Die exakte Taktfrequenz könnte man nutzen, ja. FFT und feertisch.

Der Flash-Speicher dieses PIC kann maximal 512 Instruktionen beinhalten, 
da dieser einfache Mikrocontroller noch nicht einmal seinen eigenen 
Speicher lesen kann, würden abgelegte Werte pro Byte ebenfalls eine 
Instruktion groß sein (die RETLW-Anweisung).

64 Instruktionen sind offenbar ungeschützt und auf einfachste Art und 
Weise auslesbar. Das wäre bereits ein Achtel der gesamten Speichergröße.

Gäbe es jetzt noch eine Wertetabelle für AND/OR-Verknüpfungen, wie schon 
vermutet wurde, würde noch weniger Platz für den eigentlichen Code 
bleiben. Stellenweise wurde ja bereits angemerkt, dass diese 
Schieberegisteranordung nur zur Täuschung implementiert sein könnte, 
dies würde den verbleibenden Speicher nochmals reduzieren.

Dann besitzt der Controller nur einen zweistufigen Hardware-Stack und 
das Programm kann selbst den "Program Counter" nicht manipulieren. Das 
spricht meines Erachtens nicht für einen allzu komplexen Algorithmus. 
Größere, umfangreiche, Verzweigungen sind daher eigentlich so gut wie 
ausgeschlossen - also nichts à la "switch case"-Äquivalente.

Weiterhin scheint der Arbeitsspeicher sehr knapp bemessen, viel mehr als 
die eingeschobenen Daten und wenige Bytes Zähler können also auch hier 
nicht existieren.

Ich bin daher skeptisch, ob man hier tatsächlich etwas vermuten sollte, 
was gemeinhin als "Verschlüsselung" verstanden wird. Ich tendiere stark 
dazu anzunehmen, dass hier eine Art "Verschleierung" stattfindet, welche 
anscheinend gut genug gemacht ist, dass wirkliche Experten seit Monaten 
grübeln...

Wenn man im Internet sucht, findet sich nichts - außer diesen Beiträgen 
hier - die den Hersteller dieses Dekodier-Controllers in Verbindung mit 
Verschlüsselungen bringt. Ich kann mir nicht vorstellen, dass man so 
viel "Know-How" (falls es wirklich eine komplexe Verschlüsselung wäre) 
nur für Wetterdaten nützen würde.

Thomas Berends schrieb:
> Es liegt definitiv eine Feste Bindung vor, diese ist an die UTC
> gebunden.

Ok mit Teilen meiner These gebe ich mich geschlagen. Ist zu warm um sich 
an alle Details zu erinnern. Trotzdem kann es immer noch ein einfacher 
Shift sein, der die Infos aus verschiedenen Telegrammteilen anhand der 
Zeit zusammen sucht ohne, dass diese im mathematischen Sinne 
verschlüsselt sind.

Aber das werden dir Tests zeigen, wenn man das RAM anhand des aus der 
Stromversorgung gewonnenen Taktes analysiert. Irgendwo baut sich da dann 
der dekodierte Datenstrom zusammen. Dann tauchen irgendwo auch in einem 
byte Teile des Stroms auf und das zuletzt (im Carry) verschwundene Bit 
taucht im nächsten Schritt im Decoder auf. Und irgendwo wird der dazu 
passende Zähler mitlaufen.

Gruß, Ulrich

Ps: Den Auszug oben böse interpretiert heißt doch, dass der Decoder 
diese Informationen zu dem Zeitpunkt ausgibt. Es sagt nix aus, wann er 
diese Info empfangen hat. Gezielte Desinformation als Verschlüsselung?
Aber der uC ist zu klein, sich für 80 Orte Teilinfos zu merken.

Anhand der Wetterdaten selbst kann man nicht ermitteln zu welcher Region 
der dekodierte Datensatz gehört. Das ist nur möglich durch die Aktuelle 
Urzeit, inkl. der Flags für die Aktuelle Zeitzone (MESZ, MEZ).
Und da hat die Wetterstation selbst eine Art Tabelle oder Formel, mit 
denen die Region berechnet wird. Ich hatte da mal eine kleine Formel 
aufgestellt, welche ich im DCF-Receiver nutze.

Jeder einzelne Wetterdatensatz (82 Bit) ist ein für sich abgeschlossenes 
Telegramm.
Wenn dem nicht so wäre könnte man mit Sicherheit nicht alle Daten in 
zufälliger Reihenfolge eingeben und was Sinnvolles herausholen...

Ich denke auch, die Unabhängigkeit von vorhergehenden Datenblöcken wurde 
hier wohl schon genug getestet. Das würde sonst einfach auffallen.

Wir haben nun eine Menge Baustellen, hm.

Das Problem bei der Stromaufnahme ist, daß man nicht erkennen kann ob 
z.B. Bit 7 oder Bit 0 intern gekippt wurde. Das ist in beiden Fällen in 
etwa der gleiche typische CMOS Strompeak. Und es sind viele sehr 
viele(!) Bits, die der Controller auch nur innerhalb eines Befehls 
kippt!!!

Kann man nicht die FPGA Jungs irgendwie beschäftigen? Wie macht man so 
einen Angriff? hab da keine Ahnung. Was wir haben sind endlos viele 
verschlüsselt und passend unverschlüsselte relativ kurze Datenpakete.

Jep. Simply to much!


Aber was ich gerade sah: Microchip bietet eine Krypto-Lib an! Ob das 
verwendet wurde? Läuft die auf einem der kleinen PICs??

(Ja, ich weiß. Kommt man technisch nicht weiter, gehts eben über 
Mülleimergucken und Social Engineering weiter...)

Thomas Berends schrieb:
> Wenn dem nicht so wäre könnte man mit Sicherheit nicht alle Daten in
> zufälliger Reihenfolge eingeben und was Sinnvolles herausholen...

Was gegen meinen Anlauf spricht...

Tabellen fallen ja wohl auch flach, da der PIC bzw. der andere Chip 
keine Daten aus dem eigenen FLASH lesen können. Also bleibt nur das 
ewige BitShift und ein wenig XOR.

Es ist doch wohl so, dass der Chip jeden Datensatz dekodiert und der 
Display-Teil der Uhr dann anhand der Uhrzeit weiß, wann er die Daten für 
seine Region bekommt. Jemand der die Daten direkt abgreift kann also 
rein theoretisch alle Daten für alle Regionen lesen. Im Datenblatt stand 
was von unterschiedlichen Lizenzen, je nachdem wie weit in die Zukunft 
man Daten anzeigen möchte. Diese Daten machen keinen zusätzlichen 
Schlüssel erforderlich sondern werden einfach Vertraglich in der Lizenz 
geregelt.

Alle Ortsdaten kommen immer zu einer spezifischen Zeit. Als 
Crypto-Variable kommt die Zeit also nicht in Frage, nur das Datum. Als 
Konstante kann noch was im Controller sein.

Im Grunde müsste man jetzt mal ein paar Sequenzen vergleichen in denen 
für einen Ort bei gleichbleibenden Wetter an verschiedenen Tagen die 
gleiche Info gesendet wurde. Ist das Bitmuster weitestgehend gleich, 
fällt vielleicht sogar das Datum als Variable raus.
Dann müsste man die Bits mal so vertauschen, bis die Wetter-Info stimmt.
Dann einen weiteren Datensatz mit anderen Wetterdaten nehmen und dessen 
Bits nach gleichem Muster tauschen. Wenn die Daten dann stimmen, voila 
:)

Kann aber immer noch sein, dass die Uhrzeit als Konstante für die 
Bitverschiebung mit einfließt, aber für jeden Ort eben gleich.

... Ich habe aktuell einfach zu wenig Zeit, aber ich verfolge Eure 
beachtungswerte Arbeit.

Gruß, Ulrich

Zur Stromaufnahme: War auch erstmal nicht so gedacht, dass man die 
Befehle rausliest, sondern sich auf den Takt synchronisiert.

Zur letzten Antwort bzgl. Verschlüsselung:
Es steht mittlerweile ziemlich sicher fest, dass sowohl Zeit als auch 
Datum als Schlüssel(teil) verwendet werden, oder aus ihnen der Schlüssel 
berechnet wird. Wurde eigentlich alles schon in den beiden alten Threads 
durchprobiert.
Egal welches Bit man kippt, es gibt nen Fehler! (ausnahme wären bit 0 
und bit 7, aber die werden ja eh nicht beachtet und neueren 
erkenntnissen zufolge schon während des einlesens in den µC verworfen).

Ähnliche Datensätze findest du viele: Da gabs mal ein paar Stunden wo 
immer nur 0000... entschlüsselt rauskam. Die verschlüsselten Daten waren 
aber generell hier sehr unterscheidlich.
Bei Zeitumstellungen sieht man auch noch ähnliche Sachen, wenns z.B. 
zwei mal an einem Tag 02:30 Uhr gibt d.h. da wird der gleiche Key 
verwendet.

Eine Frage die noch nicht geklärt ist: Wie berechnet sich eigentlich die 
Prüfsumme? Und wird sie VOR der Entschlüsselung berechnet oder erst 
DANACH? Das könnte man doch evtl. mit einem RAM-dump herausfinden, oder?
Es spricht mehr dafür, dass die Prüfsumme VOR der Entschlüsselung 
bestimmt wird. Denn es soll angeblich Chips geben, die einen 
1-Bit-Fehler korrigieren können. Und da die Bits untereinander mit 
AND/OR/XOR zusammenhängen, würde sich ein Fehler während er 
Entschlüsselung auf viele andere Bits übertragen. Also ist eine 
Korrektur nur VOR der Entschlüsselung möglich.
Die Häufigkeit von 0 und 1 ist auch nicht ganz gleichmäßig, besonders 
nicht bei den ersten Bits. Der genaue Algorithmus für die Prüfsumme ist 
aber unbekannt. Evtl. hat ja jemand von euch ne gute Idee...

Johannes, du erinnerst dich an meinen Punkt 3 und 4 und der notwendigen 
Reihenfolge? Wenn nicht, oben nachlesen.

Die Idee von Ulrich, das das Lizenzmodell nur rechtliche Aspekte 
betrachtet, technisch aber keinen Unterschied macht, finde ich sehr 
interessant! Das könnte so sein. Meteotime könnte das leicht mit einem 
DCF77 Testsender und einem Muster der Uhr des Lizenznehmers und einem 
entsprechenden Datensatz prüfen und schlicht bei zu guter Dekodierung 
Klagen gehen.

Wie ich schonmal schrieb, wird die PTB schlicht Bitmengen verkaufen. 2 
sind für Zivilschutz vergeben. Meteotime hat eben einige weitere 
lizenziert. Irgendwo postete einer das Verkaufsmodell von Meteotime(?), 
in dem man sehen kann, das auch noch andere Dienste verhökert werden 
sollen.

Also zuerst muss ich dann noch mal eine Frage los werden:
Warum... warum kopiert man den kompletten Datensatz im Speicher an eine 
zweite Stelle, wenn der Speicher doch so knapp bemessen ist?

Kann es sein, dass alle Chips eine Prüfsumme haben, die sich aus dem 
vorhandenen Eingangs-Telegramm generieren lässt, diese aber bei der 
ersten Generation nicht funktioniert hat? Wozu sonst eine Kopie anlegen?

Könnte es sein, dass man den einfachen Prozessor auch nur dazu nutzt mit 
simplen 8-Bit Shifts das Telegramm zu entschlüsseln und für die Anzahl 
der Shifts werden Daten aus dem Roh-Telegramm verwendet?

Ist schon spät und ich wollte die Ansätze nur mal los werden.

Gute Nacht!

Ulrich P. schrieb:
> Warum... warum kopiert man den kompletten Datensatz im Speicher an eine
> zweite Stelle, wenn der Speicher doch so knapp bemessen ist?

Weil man die Originaldaten evtl. irgendwann nochmal braucht bzw. sie 
mehrfach in das Resultat eingehen lassen möchte. Guck Dir die von Walter 
beschriebene Speicheraufteilung nochmal an. Eine dieser "Kopien" wird 
bearbeitet und modifiziert.

> Kann es sein, [...]

> Könnte es sein, [...]

> [...] Ansätze [...]

Pardon, aber das sind keine Ansätze, das sind wilde Spekulationen ohne 
Faktengrundlage.

Viele Grüße,
         Simon

Ja stell bitte den RAM-Dump hier rein! Ich hab auch meine eigene 
kommentierte Version und werde meine Erkenntnisse dann einfügen. Ich hab 
zwar auch schon recht viel raussen, aber genauso wie du hab ich einige 
Stellen die mir noch unklar sind ;-)

Gerade teste ich noch, welche Fehlererkennung/Korrektur verwendet werden 
könnte und lasse dazu ein paar Sachen durchlaufen. Ich habe ein 
korrektes Paket um 1 Bit geändert (Daten, nicht Zeit!) und versuche 
jetzt per BruteForce die richtige Prüfsumme zu erzeugen (die vermutlich 
am Anfang steht in den 14 Bits?)
LÄuft noch bis heute Nacht, dann schreibe ich Ergebnisse. Auch wenn dies 
nicht geklappt hat: Ich hätte eine Begründung dafür!

uzi schrieb:
> Ebenso gibt es auch viele Stellen, bei denen Daten auftauchen, deren
> Herkunft/Erzeugung mir im Moment noch vollkommen unklar sind.
> Wenn ich mit dem Ersten Dump durch bin werde ich meine Analyse mal hier
> posten, wer Lust hat kann ja versuchen die ungeklärten Stellen zu
> entwirren.

Ein Ansatz könnte sein, zu jeder Veränderung im Ram eine Menge von 
Tupeln aus Assembler-Befehl+Argument zu bilden, die genau dieses 
Ergebnis an dieser Stelle haben könnten. Das wird typischerweise eine 
ganze Menge von Befehlen sein.

Der Witz ist aber, dass man dies dann mit vielen verschiedenen 
Eingabetexten machen kann und anschließend den Durchschnitt zwischen den 
jeweiligen Befehlsmengen bilden kann und so die Menge an möglichen 
Assemblerbefehlen drastisch reduziert.

Das ganze geht natürlich nur dann gut, wenn man sich halbwegs sicher 
ist, dass gerade der gleiche Assemblerbefehl ausgeführt wird. Und wenn 
man die Ermittlung dieser Mengen von Hand machen muss, dann ist das 
sehr zeitaufwendig...

Hm. Ich bin mir gerade nicht sicher, ob klar ist, was ich meine. Mal ein 
triviales Beispiel mit vier Speicherzellen m[0] bis m[3]:

Beobachtete Veränderung bei Durchlauf 1:
0x10 0x33 0x50 0x87  -->   0x10 0x33 0x50 0x10

z.B. mögliche Kandidaten für den abgearbeiteten Befehl:
  { m[3] := m[0] , m[3] := m[1] & m[2] , m[3] := 0x10 , ...}


Beobachtete Veränderung bei Durchlauf 2:
0x77 0xef 0xf1 0x87  -->  0x77 0xef 0xf1 0x10

Mögliche Kandidaten:
  { m[3] := m[3] - m[0] , m[3] := 0x10 , m[3] := ~m[1] , ...}

Jetzt bilden wir den Durchschnitt zwischen diesen beiden Mengen und 
schließen daraus, dass wenn da der gleiche Assemblerbefehl 
abgearbeitet wurde, dass dann der Befehl wohl "m[3] := 0x10" war.

Ich kenne den PIC-Assembler nicht und bin nicht sicher, ob die RAM-Dumps 
jeweils die Register beinhalten. Aber wenn das ein vergleichsweise 
überschaubarer Befehlssatz ist und die Veränderungen im RAM für 
verschiedene Eingabetexte jeweils in der gleichen Abfolge an den 
gleichen Positionen stattfinden, dann könnte das ein brauchbarer Ansatz 
sein.

Ok, viele Wenns - es kann auch ein hoffnungsloser Wust an nutzloser 
Information werden...   :-)

Viele Grüße,
        Simon

eProfi schrieb:
> Du musst einfach nochmal alles durchlesen und verstehen.
> Ich meint wohl, da werden nur ein Paar Bits verdreht oder so.

Glaube mir, das habe ich. Natürlich kann die Zeit mit eingehen, aber es 
ist für jeden Ort immer die gleiche Zeit, d.h. seine Zeit-Werte gehen 
immer gleich ein.

Ich halte den Vorschlag von Dir, das RAM Dump mit dem aus dem Strom 
rekonstruierten Takt zu synchronisieren zusammen mit der Idee aus den 
RAM Dumps ein Bit-Dump und dieses als Sequenz darzustellen, immer noch 
für die beste Möglichkeit ein Gefühl für das zu geben, was da passiert.

Und wenn ich dann ganz penetrant noch mal vorschlage, dass man diese 
Bit-Videos auf einen einzelnen Ort, also die gleiche Uhrzeit ansetzt, 
dann sollten sich die Bit-Bewegungen gleichmäßiger verhalten, als wenn 
man einfach nur die Originalsequenzen durchlaufen lässt.

Gruß, Ulrich

Simon Budig schrieb:
> Pardon, aber das sind keine Ansätze, das sind wilde Spekulationen ohne
> Faktengrundlage.
>
> Viele Grüße,
>          Simon

Sorry to say, aber mal ehrlich, Ihr habt schon viel getan und viele 
Ideen zur Ideenfindung erarbeitet aber wirklich aus der 
Spekulationsphase ist das ganze noch nicht raus. Also mach mir es nicht 
zum Vorwurf, wenn ich auch ein bisschen mit spekuliere.
Manchmal ist es eben so, dass ein 'Depp' kommt und sagt, habt Ihr 'das 
da' schon gesehen und alle Fachmänner schlagen sich vor den Kopf und 
sagen 'Nee, das war zu einfach!'.

Nicht böse sein, Simon

Die Spekulationsphase ist schon halb verlassen. Sieht eigentlich nicht 
schlecht aus.

Die Idee mit dem Video kenne ich aus uralten Zeiten um RAM-Fehler zu 
finden. Problem nur: Die Verschlüsselung verschmiert die Bitinhalte über 
große Bitmengen.

Durch den RAM-Monitor ist aber auch ne Menge Auswertearbeit entstanden. 
Bis das alles durchgekaut wurde, das dauert.

Schade das die Stasi nicht mehr beschäftigt werden kann lol Die waren 
sehr effektiv. Turing ist auch schon lange tot.

Mein Test ist durchgelaufen.
Folgendes habe ich probiert:
Ich habe einen normalen Datensatz genommen und 1 Bit in den Daten 
gekippt. Danach habe ich alle Möglichkeiten der 12 ersten Bits (also bis 
14, da 2 bits ja nicht beachtet werden) durchprobiert.
Ergebnis: KEIN EINZIGES richtiges Paket dabei. Jedes Paket MUSS aber 
eine gültige Prüfsumme besitzen (muss so sein, da man sich die 
verschlüsselten Daten nicht raussuchen kann und die Prüfsummenfunktion 
daher mit jedem Paket arbeiten können muss. Und für jedes Paket gibt es 
daher eine gültige Prüfsumme)
Dafür gibt es mehrere Möglichkeiten was sein könnte:
1. Der Bereich vorne ist nicht die Prüfsumme oder hinten sind nicht die 
Daten. Ist aber eher unwahrscheinlich wenn man sich die Verteilung 0/1 
ansieht.
2. Es ist ein doppeltes System vorhanden: Erst haben wir eine 
Fehlererkennung mit Fehlerkorrekturmöglichkeit. Hierbei ist die 
Prüfsumme über die verschlüsselten Bits.
Nach der Entschlüsselung wird nochmal ein Test durchgeführt, z.B. 
irgendwas sehr einfaches wie ein CRC drüber.
Platz dafür wäre da! Insgesamt sind es 40 Bit an verschlüsselten Daten, 
22 Bit kommen danach raus. Die ersten 12 Bits sind schonmal die 
Prüfsumme. Bleiben noch 28 Bit übrig. Würde nochmal 6 Bit für eine 2. 
Prüfsumme machen.
Ein weiterer Grund der dafür spricht: Die meisten Fehlererkennungen 
können keine Mehrbitfehler sicher erkennen. Ich hatte aber bisher noch 
keinen Fall wo ein Mehrbitfehler nicht erkannt worden wäre.

Was meint ihr so dazu?

Hm. Schwierig eine Antwort zu geben. Vor allem deinen letzten Satz kann 
ich so nicht stehenlassen. Du beziehst dich wohl auf die 
Wahrscheinlichkeit einer fehlerhaften Korrektur?!

Ich bring mal ein Beispiel von dem ich mehr verstehe:
Bei Radio-RDS sind die Nutzdaten 16Bit. Denen werden 10Bit 
Korrektursyndrom zugesetzt. Übertragen werden demnach 26Bit.
Zur Synchronisierung auf die Framelänge von 26Bit werden einige 
unbenötigte 26Bit(!) Frames separat erkannt und anhand deren kann der 
Dekoder einige separate Datenpakettypen unterscheiden. Die Typen sind 
diversen Funktionen zugeordnet (Gibt 5 bzw. 6 verschiedene).

Es gibt keine Prämbel! Macht ja auch Sinn, denn der das Radio 
einschaltet, kommt irgendwann in den kontinuierlichen Datenstrom rein. 
Eine Prämabel würde nur Bandbreite verschwenden.

Der Dekoder kann:
1. 1 und 2 Bit Fehler erkennen und korrigieren (Macht nur Sinn in den 
16Bit Nutzdaten). Beide Bits dürfen an beliebiger Stelle liegen. Also 
auch voneinander getrennt.

2. 5 Bit Burst korrigieren. Also Fehler in bis zu 5 aufeinanderfolgen 
Bits.
Ich habe auch ne Beschreibung, in der steht der Algorithmus könne dies 
bis zu 11 Bit, aber ich fand bislang nirgends ein Beispiel wo das jemand 
real geschafft hat. Vielleicht stimmt es also nicht.

Beachte: Die zur Synchronisation verwendeten 5/6 Frames erhalten keine 
Fehlerkorrektur. Das deckt sich auch mit der Theorie der 
Nachrichtenübertragung in gestörten Kanälen, wonach für Sync ein höheres 
S/N anzusetzen ist als für Datenbits.

Der RDS-Algorithmus ist auf dem damals modernen Stand von ca. 1980.


Bei uns hier wird über den Minutenzähler synchronisiert. Ein Datenpaket 
besteht aus 40 Bits Meteotime, 2 Bits Alarm Zivilschutz UND den normalen 
DCF77 Zeitcode Bits, wobei diese wegen der drei Minuten hintereinander, 
nicht voneinander unabhängig sind. Wir wissen aber nicht, wieviel von 
der möglichen Information in den Zeitcode Bits wirklich genutzt wird! 
Das nur zur Erinnerung.

Johannes O. schrieb:
> 2. Es ist ein doppeltes System vorhanden: Erst haben wir eine
> Fehlererkennung mit Fehlerkorrekturmöglichkeit. Hierbei ist die
> Prüfsumme über die verschlüsselten Bits.
> Nach der Entschlüsselung wird nochmal ein Test durchgeführt, z.B.
> irgendwas sehr einfaches wie ein CRC drüber.

Ich persönlich befürchte so etwas auch. Hier wurde ja schon 
ausführlichst darüber diskutiert, ob die Plausibilitätsprüfung (wie 
immer die aussehen mag) vor oder nach der Entschlüsselung stattfindet. 
Es wurde überzeugend argumentiert, dass es eine Plausiblitätsprüfung vor 
der Entschlüsselung geben muss. Das schließt aber eine weitere Prüfung 
nach der Entschlüsselung nicht aus. Und das macht das ganze verdammt 
schwierig...

EDIT:

Es werden ja bekanntermaßen 80 Bits auf 22 Bits "eingedampft". Da stellt 
sich bei mir direkt die Frage:

  "Gibt es zwei verschiedene 80-Bit-Zahlen, die nach der Entschlüsselung
  dieselbe 22-Bit-Zahl ergeben?"

Ich glaube: Nein. Das heißt: Der Großteil der möglichen 80-Bit-Zahlen 
ist für den Decoder "unplausibel", nämlich 2^68 minus 2^22 
Kombinationen. Das ist eine verdammt große Zahl. Mit dem Versuch des 
"Bitkippens" wird man da nicht weiterkommen.

Nachtrag zum EDIT: Ich meinte 2^80 minus 2^22 ungültige Kombinationen. 
Die Zahl ist noch um ein Vielfaches höher :-(

Es gibt jedes Datum nur einmal! Selbst wenn wir einen Datenblock 
generieren, der unterschiedlich ist in den Meteodatan und gleich im 
Datum, haben wir nichts gewonnen!

Ich glaube, meine obige Überlegung im EDIT, ob es dieselben 
22-Bit-Zahlen bei 2 unterschiedlichen 80-Bit-Zahlen geben kann, ist 
falsch. Natürlich kann heute und morgen an einem Standort das Wetter 
absolut gleich sein. Ich muss mich also korrigieren. Es gibt jede Menge 
80-Bit-Zahlen, die nach der Entschlüsselung denselben 22-Bit-Wert 
haben...

Sorry,

Frank

Vielleicht bringt es was, wenn wir mal nach gleichen Wetterdaten bei 
unterschiedlichen Datecodes suchen??

Abdul K. schrieb:
> Vielleicht bringt es was, wenn wir mal nach gleichen Wetterdaten bei
> unterschiedlichen Datecodes suchen??

Das halte ich für vielversprechender. Was ist denn mit den berühmten 
000...-Daten, die mal über mehrere Stunden aufgrund einer Störung 
erzeugt wurden? Hier werden sie erwähnt:

http://www.mikrocontroller.net/articles/DCF77_Wetterinformationen#Verschl.C3.BCsselung

Das halte ich immer noch für den besten Angriffspunkt. Da gab es 
offenbar eine Vielzahl von 80Bit-Zahlen, die allesamt zur 22-Bit-Zahl 
000... decodiert wurden.

johannes o. schrieb:
> bei der zeitumstellung gibt es 20 zeitstempel doppelt. also einmal im
> jahr 20 stück. aber viel gebracht hat das auch nicht.
> evtl.fallen dir ja zusammenhänge auf.

Ich habe mal gerade in die Logdatei für den 31.10.2010 reingeschaut, 
also den Zeitpunkt der Umstellung auf Winterzeit im letzten Jahr.

Da stimmt was nicht in der Datei MeteoLog_DCFLog00844.log. Ich bekomme 
die Daten, die sich in der Zeit zwischen 2 und 3 Uhr wiederholen 
sollten, nicht übereinander.

1. Uhrzeit 02:02: Region: 40
2. Uhrzeit 02:02: Region: 00

Das müsste doch dieselbe Region sein? Kann es sein, dass die 
LogServer-Software bei der 2. Stunde bei Umschaltung auf Winterzeit 
einen Fehler hat? Aber die decodierten Wetterdaten (22 Bits) passen da 
auch nicht übereinander. Mache ich da vielleicht einen Denkfehler?

eProfi schrieb:
> Frank, die Rechnung mit den Wahrscheinlichkeiten habe ich schon hier
> ausgeführt:
> Beitrag "Re: Was ist aus dem Thread der MeteoData geworden?"
> d.h. es muss ja zu jedem Timestamp jede Wetterinfo gesendet werden
> können.
> So ist die Wahrscheinlichkeit 1:2^(40-22)=1:262144, dass ein 40-Bit-Satz
> gültig übersetzt wird. Beim fehlerkorrigierenden Chip sogar 1:2^17.
> Das deckt sich in etwa mit den Ergebnissen auf Thomys Decoderseite.
> Bisher haben wir etwa 100000 Sätze dekodiert und 2 Treffer gefunden.
>
> Wenn wir jetzt unsere Decodierleistung verhundertfachen könnten, wäre
> bald genug Datenmaterial da, das man kryptographisch verwerten könnte:
> gleicher Schlüssel (Bit 41-79), verschiedene Paare (Bit0-39) und
> (22Bit-Ergebnis).
>

Die Verkürzung durch Zappen des WDT-Registers sollte doch machbar sein, 
oder Walter?

Wieviel Datenpakete wurden eigentlich jemals gesendet? Der Code muß ja 
einen so großen Wertebereich haben, das zu allen Zeiten niemals die 
Verschlüsselung wiederholt wird. Hm.


>
> Bin gerade dabei, den Stromverbrauch während des Reintaktens der 80 Bit
> zu analysieren, das ist hochinteressant. Bei manchen Bits wird zwischen
> den Bits unterschiedlich heftig gerechnet, bei anderen nichts gemacht.
>
> Nur ändern sich die Positionen, an denen gerechnet wird.
> Sie hängen vom Bitmuster ab.

Könnte sein, das sind Stellen an denen in Abhängigkeit eines Bit-Wertes 
gesprungen wird oder nicht.


> Man sieht den Kopiervorgang nach dem Reinschieben auch recht schön.
>
> Es wird wirklich die ganze Zeit (ca. 275 ms) gerechnet.
>

Immer exakt gleich lang? Das wäre dann aber komisch, außer da ist 
Füllcode zur Verschleierung der restlichen Zeit drin (Wenn es so wäre 
wie ich gerade im Absatz vorher schrieb).


>
> Walter, hast Du schonmal herausbekommen, ob der sichtbare Code
> ausgeführt wird?
>
> Noch was ist mir aufgefallen:
>

1

> 111111111111112222222222222233333333333333mmmmmm08ssssss20tttttt21mmm01wt5jjjjjj11

2

> 0011000000000100010101011000000101000111000001000000000100100001001000010110001000

3

> 22 000000000000000000000010 01 2011'0121:2008

4

> 0111000010100100000000100100100010111000100100000001000100100001001000010110001000

5

> 24 000000000000000000000010 01 2011'0121:2202

6

> = ====== = ====== = =     == ==          == = =====

7

> ==============================    ========================

8

>  0      1 2      3 4 56789  a  bcdefghijk  l m     n

9

>

> Das Datum unterscheidet sich an 3 Stellen (l, m, n), und vorne ist ein
> 5er- und ein 10er-Block genau invertiert.

Hm. Geht das nicht in Richtung: Die Bibel ist in der Zahl e enthalten? 
Was prinzipiell wahr sein muß, aber nicht jedem verständlich. 
Lustigerweise ist die Bibel dann aber auch in der Zahl pi enthalten, und 
das obwohl beide Zahlen unterschiedlich sind. <transzendente Zahlen>

Es könnte aber auch eine weak Stelle in der Verschlüsselung sein. Die 
Verschlüsselung ist ja nicht überall in der möglichen Matrix aller Tupel 
gleich stark.

eProfi schrieb:
> Frank, die Rechnung mit den Wahrscheinlichkeiten habe ich schon hier
> ausgeführt:
> Beitrag "Re: Was ist aus dem Thread der MeteoData geworden?"

Danke für den Hinweis, tut mir leid, wenn ich angesichts der Fülle von 
Beiträgen über mehrere Threads hinweg nicht alles im Kopf habe :-)

> d.h. es muss ja zu jedem Timestamp jede Wetterinfo gesendet werden
> können.

Ja, das leuchtet ein.
> Wenn wir jetzt unsere Decodierleistung verhundertfachen könnten, wäre
> bald genug Datenmaterial da, das man kryptographisch verwerten könnte:
> gleicher Schlüssel (Bit 41-79), verschiedene Paare (Bit0-39) und
> (22Bit-Ergebnis).

Konzertierte Aktion durch 100 Leute, die mitmachen? Dann würde ich mir 
doch glatt überlegen, mir eine Wetterstation zuzulegen ;-)

Einer müsste das dann koordinieren und die zu durchforstenden 
Zahlenbereiche unter den Leuten aufteilen. Ich weiß zum Beispiel gar 
nicht, wie man den Decoder-Chip anzapft und mit eigenen Daten füttert. 
Ideal wäre eine Anleitung über den Artikel im Wiki, wie was 
zusammenzulöten ist und wie man da dann mit einem Brute-Force-Programm 
drangeht.

Achja, ich habe da was zu den legendären 0000-Datensätzen. Ich habe mir 
mal die verschlüsselten Daten (also ohne die Timeinfo) dazu in eine 
Text-Datei Zeile für Zeile kopiert, die 0en durch Blanks ersetzt und die 
1en durch ein kleines 'o'. Man sieht dann interessanterweise Muster, die 
sich teilweise wiederholen (aber nicht exakt). Und zwar laufen da 
diagonale Gruppen von Blanks quer durch die Datei - und zwar 
spiegelsymmetrisch: einmal von links oben nach rechts unten und von 
rechts oben nach links unten, so dass das Muster wie ein 'X' aussieht.

Hier mal ein Beispiel:

o o o   o oo oo       oooooo oo o  o    o
  o       o ooo   o o o  o  o  o     oo  oo
 ooo o   o o ooo o o o oooo oo o   oo o o
 oo o o   ooo   o o ooo ooo o     oo o   oo
 o  ooo  o ooooooooooo  oo  o o o  o oooo
 ooooo       o    oo    o    o oo o  ooo oo
 o oo o oo  ooo o oooo oooo oo ooo o ooooo
  oo oo    o  oo oo    o  o  oo o  ooooo oo
 o oo o  o   o    o oo ooo o oooooo     o
     o   ooooo  o  oo   o o  ooooo   ooo oo
 o    o   oo oo    oo oo o  oooooo  oo   o
  ooo o   o ooooo    ooo   o  oooooooo  ooo
   ooo  o     oo oo oooooooo   o  o  oo
  ooo   ooo ooo  oo  o    o  oo  ooo oooo o
 oo o o o  o o  o o oo  ooo       o o oooo
 oo oo    o      oo    ooooooo o oooo ooooo
 o o oo   o ooo ooo  o  ooooo    o   ooo o
 ooo  o  o o  o oooooo  ooo  o o        o o
   o oo o  o   oo o  o  o o o ooo ooo o o
  o o         o  o o oooo   o ooo o    o oo
   oo   ooooooo o oooo oo ooo     o  oo  o

Ich habe hier einfach mal wirkürlich ein paar Datenzeilen aus den 
insgesamt 479 000er Datensätzen rausgezogen. Diese X-förmigen 
Leerstellenmuster ziehen sich aber durch die komplette Datei, aber nicht 
immer sitzt das X so schön zentriert wie hier im Beispiel.

Für mich sieht das so aus, dass abhängig von dem Datum verschieden oft 
geschoben wird, es also alle 3 Minuten einen Versatz gibt. Dabei wird 
die erste Hälfte einer jeden Zeile mit fortschreitender Zeit nach rechts 
geschoben, die rechte Hälfte nach links. Dann treffen sich beide in der 
Mitte und kreuzen dann. Ich werde das mal weiterverfolgen...

Ich weiß nicht, ob man das hier gut sehen kann. Wenn ich die 479 Zeilen 
im Text-Editor durchrollen lasse, läuft das aber wie bei einem Film ab, 
dass die Leerstellengruppen "wandern".

Gruß,

Frank

Interessant. Das ist auf jeden Fall ein weiterer Ansatz! Sieht nach 
einer Schwachstelle aus.

Nachtrag:

Ich habe mal alle Leerstellengruppen von mehr als 4 Blanks durch X 
ersetzt, die übriggebliebenen o's ebenso durch Blanks. Dann sieht man 
die X-Struktur noch besser:

               XXXX                 XXXX
   XXXX                         XXXX

                             XXXX

      XXXX    XXXX  XXXX XXXX

       XXXX        XXXX
              XXXX                 XXXX
XXXX
  XXXX         XXXX
                 XXXX
         XXXX
                      XXXX
                           XXXX
      XXXX XXXX    XXXX
                             XXXX
                                XXXXXXXX

     XXXXXXXX                      XXXX
                             XXXX


Da "läuft" auf jeden Fall was von links oben nach rechts unten durch, 
ebenso von rechts oben nach links unten. Diese Dinger "wandern" durch 
sämtliche 479 Datensätze. Ist fast wie Game-of-Life (kennt das noch 
jemand?) ;-)

Diese "wandernden" Bitmuster decken sich übrigens mit der Erwähnung im 
Artikel unter

http://www.mikrocontroller.net/articles/DCF77_Wetterinformationen#Verschl.C3.BCsselung

"Es finden sich teile von Paketen auch in anderen Paketen wieder. Zufall 
oder Schwäche?"

Versuch mal die Muster umzusortieren, sodaß gleiche Muster nun 
unterschiedliche DCF77 Datecodes haben. Nun vergleiche die Datecodes auf 
Regelmäßigkeiten.

Ich hab nochmal nen RAM-Dump in einem weiteren Stadium angehängt (um die 
100 ms nach Einschalten). Der erste ging von 0 bis ca. 2ms.
Der Jitter macht sich hier aber schon stark bemerkbar. Das sieht man 
daran, dass mehrere Byte gleichzeitig geändert werden und teilweise der 
alte Zustand nach dem neuen Zustand kommt.

Walter.

@uzi, Johannes O.:
schaut mal wieder im Thomy-Forum vorbei (analyse).

ich habe mir gerade den 2.Dump nochmal durchgeschaut.
Prinzipiell schaut das aus, wie der erste. Nur das Timing ist wirklich 
grauenvoll. Ich mach das nochmal. Bitte nicht verwirren lassen.

Walter.

beim Analysieren bin ich auf folgendes Problem gestossen:

es wird immer wieder für Register 0x1C ein Wert berechnet und ich komme 
nicht drauf, wie. Die Berechnung dauert ca.16 Zyklen. Es kommen wohl 
Befehle wie ADD und SUB dazu, da das DC (Hilfscarry) geändert wird.

Ich habe mal die relevanten Stellen zusammengefasst und angehängt.
Vielleicht fällt ja jemandem was auf.

Die Zahl rechts vom Block (0x..) ist der Wert von 0x1C vor der Änderung.

Walter.

eine weitere unklare Stelle ist folgende:

es werden für die 4 oberen Bits von R0D und alle 8 Bits von R0E die Bits 
in Abhängigkeit von anderen Bits gesetzt (das gleiche kommt dann auch 
nochmal für R12-R15. Dabei werden die Bits zuerst gelöscht und dann nach 
Bedarf gesetzt.
Ich habe auch hier mal die relevanten Stellen angehängt.

Rechts vom jeweiligen Block stehen zuerst die 4 Bit, die in diesem Block 
für R0D gesetzt werden, danach die 8 Bit, die für R0E gesetzt werden.

Die Idee ist jetzt für jedes Bit zu suchen, welche der Bits im Block 
gesetzt sind, wenn das gewälte Bit gesestzt ist.

z.B.                         v
für den 1. Block: 60, 38 (0110, 00111000)
für den 2. Block: 50, 20 (0101, 00100000)
                             ^
Bit0 für R0D (^ und v) ist einmal gesetzt und einmal gelöscht.
Also suche ich alle Bits, die ersten Block gestzt und im 2. Block 
gelöscht sind. Das ganze mache ich mit allen Blöcken. Es sollte 
letztendlich nur 1 Bit übrig bleiben. Das ganze kann natürlich auch 
invertiert sein, im schlimmsten Fall sogar gemischt.

Walter.

Walter Freywald schrieb:
> beim Analysieren bin ich auf folgendes Problem gestossen:
>
> es wird immer wieder für Register 0x1C ein Wert berechnet und ich komme
> nicht drauf, wie. Die Berechnung dauert ca.16 Zyklen. Es kommen wohl
> Befehle wie ADD und SUB dazu, da das DC (Hilfscarry) geändert wird.
>
> Ich habe mal die relevanten Stellen zusammengefasst und angehängt.
> Vielleicht fällt ja jemandem was auf.

Eventuell die vermutete extra Checksum-Berechnung? 1 Byte Länge würde 
für ca. 20 Bits Nutzdaten völlig reichen. 16 Zyklen kommt auch hin.

Wenn du Glück hast, wird dieses Byte dann irgendwann gegen irgendwas 
(evenutell auch Null!) verglichen und daran dann der Ausgangsstatus in 
der bekannten Form generiert (Paket ok, defekt. etc.).

Hier noch ein interessant erscheinender Beitrag zu Variaten der 
Berechnung der CRCs:
Beitrag "Re: CRC-16 Prüfsumme (serielle Übertragung)"

Dieser Block braucht ca. 14 Zeiteinheiten und es sind auch ähnlich viele 
Befehle.
Man sollte beachten, dass ein PIC keinen konstanten Wert DIREKT 
schreiben kann. Darum werden sie die Speicherstelle erst auf 0 setzen 
und dann die einzelnen Bits die sie brauchen per OR setzen. Warum man 
das dann allerdings in so vielen Schritten macht anstatt in einem ist 
mir noch ein Rätsel.
Es werden auch nicht jedes mal alle dieser Bits gesetzt.
Besonders merkwürdig ist hier, dass da nichtmal ein BTFSC Platz hätte da 
jeder Befehl 1 Takt braucht und pro geschriebenem Wert offenbar auch nur 
einer verwendet wird? Oder ist die Zeit an der Stelle so ungenau, dass 
man die 2 Befehle nicht sieht?

Anbei ein paar Dateien zu meinen bisherigen Erkenntnissen anghängt.
Anstelle einer Beschreibung habe ich das ganze als C-Programm 
formuliert.
Es stellt nur eine Beschreibung dar und ist nicht lauffähig.

Zum groben Ablauf:

- die Daten werden eingelesen
- danach werden die eingelesenen Daten einzel "angefasst" nach W geladen 
(ja, ich habe den Monitor erweitert), danach wird W wieder zu 0, so als 
ob ein Vergleichswert davon abgezogen werden würde (als Vergleich)
[...]

Die Eingangsbits  0-19 werden nach R08,R09 und die unteren 4 Bit von R0A 
kopiert.
Die Eingangsbits 20-39 werden nach R0B,R0C und die unteren 4 Bit von R0D 
kopiert und geschoben

[...]

Dann kommen 16 Runden:
[LOOP]

- die Zeit (R16-R1A) wird eins nach rechts rotiert
- dann wird R0E ganz und die oberen 4 Bit von R0D gelöscht
- anschließend werden die einzeilnen Bits in Abhängigkeit von anderen 
Bit im RAM gesetzt (s.Datei Bitabhängigkeiten...erste Abschätzung)
- R12-R15 werden gelöscht
- anschließen werden auch hier die einzelnen Bit in Abhängigkeit von 
anderen Bits gesetzt (s.auch hier die Datei im Anhang)
- R0B-R0E werden mit R12-R15 XOR verknüpft und in R12-R15 abgelegt
- die oberen 4 Bit werden gelöscht
- R15 wird nach R1B kopiert
- R14 nach R15

jetzt kommt eine innere Schleife mit 5 Durchläufen:

- in jeder geraden Runde wird R12 "geswappt" (untere 4 Bit mit oberen 4 
Bit getauscht)
- dann werden die unteren 4 Bit von R15 gelöscht
- R1C wird berechnet (ist mir noch völlgig unklar...)
- in jeder geraden Runde (4.,2.,0) wird R13 nach R12, R14 nach R13, R1E 
nach R1D und R1C nach R1E kopiert
- R1B und R15 werden 2 nach rechts geschoben (R1B.0 -> R15.7)

Nach dieser Schleife werden R12-R14 wieder gelöscht
wiederum werden Bits in R12-R14 gesetzt

Dann kommt ein "Dreieck":
- R12-R14 XOR mit R08-R0A
- R0B-R0D wird nach R08-R0A kopiert
- R12-R14 wird nach R0B-R0D kopiert

Dann geht's wieder oben (LOOP) weiter...
Soweit meine ersten Erkenntnisse

Nach den 16 Runden wird wieder ein bisschen was gemacht, dann kommen 
wieder 16 Runden.

Kennt jemand einen solchen Algorthmus.

Ist wohl so eine Art Feistel, mehrere Runden und immer wieder werden die 
Seiten getauscht...
S-Boxen werden keine verwendet.

Schieben und XOR in mehreren Runden, keine S-Boxen.
Wenn man die Blockgröße mal ausser Acht läßt, was könnte da passen ? RC5 
?

Bisher verwende ich immer noch das Testmuster.
Nächster Schritt ist die Verwendung eigener Muster um herauszufinden, 
wie und wann ein gültiges Telegramm erkannt wird.


@uzi, Johannes:

zuerst bitte beachten: die Zählerangaben (Lange forlaufende Zahl vor dem 
Doppelpunkt) gibt nicht wirklich die Taktzyklen im PIC an. Ich arbeite 
noch daran, die Abstände kürzer zu machen, damit man wirklich jeden 
Befehl auflösen kann.

Das mit 12-15:
So bin ich da auch ran gegangen.
Wie Johannes schon sagt werden die Bits in Aufsteigender folge gesetzt. 
Es sind genug Taktzyklen für jedes Bit da (glaube ich...).
Ich habe daraufhin ein kleines Programm geschrieben, welches mir für 
jedes Bit diejenigen Bits im RAM herausfiltert, die mit den gesuchten 
Bit kippen.
z.B. R012.0: welche Bits sind sowohl "1" wenn dieses Bit "1" ist und 
auch "0" sind, wenn dieses Bit "0" ist.

Für einige Bits habe ich kein Ergebnis gefunden, sie werden aber 
trotzdem ab und zu gesetzt. Evtl. läuft der Mechanismus (teilweise) auch 
invertiert: Das Bit wird gesetzt, wenn ein anderes gelöscht ist und 
umgekehrt. Werde ich geleich nochmal ausprobieren.

Auch habe ich für einige Bit mehrere Möglichkeiten gefunden (s. Anhang)

Zu R1C habe ich wirklich noch keine Idee. Da der Monitor jetzt aber das 
W-Register (Akku des PIC) in Adresse 0x33 speichert kann man jetzt sehr 
schön mitlesen (ich komme aber bisher trotzdem nicht drauf...).

Ich habe nochmal einen Dump angehängt, dieses Mal über etwas mehr als 
die ersten 16 Runden und W in 0x33

Walter.

Warum willst du den Algorithmus jetzt schon wissen? Es würde doch 
reichen, wenn du einfach alle Befehle rausbekommst. Damit ist das Ding 
geknackt! Als Fingerübung könnte man dann noch nach der mathematischen 
Seite des Programms suchen und eventuell auf einen 
Standard-Verschlüsselungsalgorithmus kommen. Es könnte aber auch Custom 
sein.

Ein weiterer Schritt wäre danach die Erzeugung des Encoders auf 
Senderseite.

Wie gesagt und schon bestimmt vergessen: 2013 kannst du es eventuell 
nicht mehr live testen :-)

Ich hab jetzt den RAM Monitor so modifiziert, dass W nach 0x33 
geschrieben wird. Der Inhalt von 0x33 scheint sich bis zur Ausgabe der 
Klartext Daten nicht zu ändern.

Des weiteren kann ich den WDT Counter auf 1 vor jeder Anfrage auf "1" 
setzen, so dass er beim nächsten WDT Reset auf 0 heruntergezählt wird 
und die Anfrage durchkommt.

Ich habe auch noch versucht, den WDT Prescaler auf 1:1 zu setzen (jetzt 
dauert jede Anfrage ca. 6 Sekunden (dauert halt bei 300000 Anfragen...), 
damit kommt er aber garnicht klar (wird niemals READY). Das Problem ist, 
dass ich das OPTION Register nicht lesen kann. Ich weiß also nicht, an 
welchen Bits es hängt. Dass ich das W-Register ändere, stört den PIC 
nicht.

Ich kann jetzt also auch "echte" Telegramme im 6 Sekunden Takt 
reinschieben und bekomme gültige Antworten - schon mal ein Fortschritt.

Ich habe mal ein gültiges Telegramm reingeschoben und das gleiche mit 
Bit 2 gekippt. Die ersten 200 Zyklen habe ich keine Unterschiede im 
grundsätzlichen Ablauf festellen können.

Jetzt ist die Frage: Was für Telegramme soll ich reinschieben, um 
möglichst viel über den Ablauf herauszubekommen ? Wir wissen ja jetzt in 
etwa, wo die Daten hingeschrieben werden und was damit gemacht wird (zu 
mindest am Anfang in den ersten 5 ms....-> ca.1.8 %....)

Walter.

Warum 0x33? Auf den RAM-Dumps sieht es so aus als würde sich das ganz 
oft ändern.
Kannst du bitte die aktuelle Version hochladen dann schaue ich mal 
drüber ob mir was auffällt. Beim OPTION-Register scheints ja viele 
Einstellungen zu geben. Wie genau hast dus deaktiviert? Prescaler ganz 
vom WDT weg oder nur auf 1:1 gestellt?

TLDR: Kurzfassung: Abhängigkeiten der Bits getestet. Fast nichts neues 
rausgefunden, außer dass die ersten 14 Bits und der Zeitstempel 
voneinander abhängen. Der Rest scheint statistisch nicht relevant zu 
sein und sieht "perfekt" aus.

(Die Datei bitte im Firefox oder Internetexplorer aufmachen, im Forum 
wird sie nicht korrekt dargestellt)
-----------------------------------
Hab jetzt nochmal ein wenig die Daten an sich betrachtet. Ein paar 
kleine Statistikfunktionen hab ich noch geschrieben und die mal 
drüberlaufen lassen.
Im Anhang ist eine Datei in welcher stochastische Abhängigkeiten 
aufgelistet sind.
Kurze Erklärung dazu:
Das Script berechnet die bedingte Wahrscheinlichkeit dafür, dass wenn in 
Bit A eine 0 steht, auch in Bit B eine 0 steht.
Sofern die Wahrscheinlichkeit, dass in B eine 0 steht GLEICH IST zur 
Wahrscheinlichkeit, dass in B eine Null steht wenn schon in A eine Null 
steht, so sind die beiden stochastisch unabhängig. (in Wikipedia ist es 
glaub ich schöner erklärt...).

Die Zeilen entsprechen dem Bit B, die Spalten dem Bit A.
In den Zellen steht der Betrag des Unterschieds (in %) zwischen der 
berechneten bedingten Wahrscheinlichkeit und dem "normalen" Wert der bei 
stochastischer unabhängigkeit rauskommen müsste. Werte über ca. 0.5 bis 
1% deuten auf eine Abhängigkeit hin.
Bei Zellen mit - drinnen sind die Daten nicht representativ, da dieses 
Bit z.B. nahezu dauerhaft auf 0 oder 1 war (irgendeine stelle beim jahr 
zum Beispiel). Die Zellen auf der Diagonale sind nicht weiter 
interessant oder relevant.

Folgendes Ergebnis habe ich erhalten für ca. 200.000 Datensätze die ich 
verwendet habe:

- Die ersten Bits 0-13 (ohne die 0-Bits, bei denen machts natürlich 
keinen Sinn) sind nicht nur ungleichmäßig verteilt, sie sind auch nahezu 
alle abhängig voneinander. Nur Bit 8 und Bit 10 beeinflussen sich nicht 
gegenseitig.
- Auch die Zeitbits sind voneinander abhängig, das ist auch normal so 
und wäre beweisbar, dass es so sein muss.
- Die restlichen Bits zeigen keine größeren Auffälligkeiten. Die 
einzelnen Felder mit etwa 0.4 sind zwar leicht erhöht, aber ich bin mir 
nicht sicher ob das ganze nur eine Ungenauigkeit ist die auftritt. 
Interessant ist aber dennoch, dass Bit 12 und Bit 13 offenbar häufiger 
irgendwie mit den verschlüsselten Daten zusammenhängen.


Was zeigt dieses Ergebnis?
- Bei den ersten 14 Bit muss es sich definitiv um irgendwas anderes 
handeln als in den Bits danach. Prüfsumme könnte möglich sein, aber mir 
fehlt dazu das Wissen um Beurteilen zu können, inwiefern die 
Abhängigkeit untereinander was damit zu tun aht.
- Die Verschlüsselung arbeitet ziemlich perfekt. Wenn die das wirklich 
selbst entwickelt haben, dann müssen da Profis am Werk gewesen sein. 
Keine sichtbaren Abhängigkeiten untereinander, fast perfekte 
Gleichverteilung von 0 und 1 usw.

Neues scheint es aber kaum zu bringen. Oder fällt irgendwem etwas auf?
Bitte beachtet auch, dass hier noch ungültige Datensätze vorhanden sind 
die das Ergebnis leicht verfälschen können!

-----------------------------------------------

Walter: Wir haben da doch noch das $1C Problem und andere 
einzelne-Bits-gesetzt Probleme. Das W-Register könnte uns hier sehr 
behilflich sein. Es ist doch sicher möglich nur diese Bereiche (den 
Zeitpunkte kennen wir ja) inkl. W zu betrachten, oder? Schiebe 
verschiedene Daten rein, das sollte Klarheit bringen was gemacht wird.

@Walter,
Wenn ich mich recht ereinnere werden ungültige Datensätze nach dem 
einschieben irgendwann ausgenullt, wäre es möglich diesen schritt mit 
deinem Codeschnipsel zu überspringen, um zu sehen was der Decoder mit 
einem Ungültigen Datensatz anstellt?

Gruß
Thomas

Vielleicht werden in den ersten ms die Daten nur irgendwie 
'entschleiert'?

Jedenfalls ne interessante Tabelle.


Hier, das ist gerade reingekommen:
"Any enterprise large enough to have an IT deparment needs
precise timing.  The cheapest stratum one source is GPS.

I work at a Research II university and have several in our network.

The time is the public key for our routers that send encrypted
routing table updates to each other."

Das entspricht doch genau dem Patent von HKW?! Ob das vielleicht auf ein 
Standardverfahren hinweist, was irgendwo dokumentiert ist?

Falk O. schrieb:
> Meldung aus der "Core Group":
>
> es ist gelungen, mit Hilfe der RAM Dumps den Algorithmus zu
> rekonstruieren.

Glückwunsch :)
Ich hatte den Thread immer gespannt mitverfolgt, auch wenn es zeitweise 
ein wenig unübersichtlich wurde.

Nick schrieb im Beitrag #2239839:
> Und was nützt es dann? Wenn der Algorithmus nicht veröffentlicht wird
> ist das Ganze doch witzlos.
>
> Nö. Immer noch nicht. Ohne veröffentlichung bleibt der Chip genauso
> sicher wie vorher.

Finde das jetzt ehrlich gesagt auch schade.

Hätte eigentlich erwartet, dass man auch die Allgemeinheit sich an den 
Ergebnissen freuen lässt.

Ich selbst habe auch gerne in den Beiträgen mitgelesen.

Für das "Experten-Forum" zum Thema hatte ich mich zwar versucht 
anzumelden, doch nie eine Bestätigung erhalten. So kann man auch 
verfahren...

Gibt es denn keine Meteotime Produkte wo man den dekodier Chip 
ausschlachten kann? Ich denke hier hätte keiner ein Problem damit 
Meteotime für den Chip zu bezahlen, aber dass sie uns im Regen stehen 
lassen ist was jedem Frust bereitet. Falls der Chip vergossen ist müsste 
man die Leiterbahnen drum herum eben "anzapfen" um ihn anzusteuern... 
ohne Datenblatt :(

Falk O. schrieb:
> Meldung aus der "Core Group":
...
> Decrypt und Encrypt ohne Chip ist möglich (die Algorithmen wurden für
> den PC nachprogrammiert (werden aber unter keinen Umständen
> veröffentlicht !)

OK, und ich habe AES geknackt, sage aber niemanden wie ich das gemacht 
habe. ;)

Solche Informationen gehören sich auf einen USB-Stick in einen Braunen 
Umschlag und an die Redaktion der Datenschleuder (CCC) geschickt. Die 
kümmern sich dann darum, dass das vernünftig veröffentlicht wird.

Im Prinzip kann es ja Meteotime egal sein ob das Verfahren öffentlich 
ist oder nicht. Die kommerziellen Anbieter können die problemlos 
Abmahnen und verklagen.

Jetzt muss ich mich auch mal aus der "Core-Gruppe" melden:
Ja es stimmt, der Algorithmus ist geknackt. Ich habe ihn zwar nicht 
selbst laufen sehen, es wurden aber Beweise erbracht dass es so ist.

Aber auch im internen Forum wurde der komplette Code NICHT 
veröffentlicht und das wird auch nicht passieren.
Warum? Genau aus diesem Grund: Er wird verbreitet werden und das wird 
keine positiven Folgen für HKW haben.

Es ging nie darum den Code zu veröffentlichen, sondern nur darum, 
herauszufinden wie sicher das ganze System ist.
Wir wollen HKW nicht schaden. Es gibt keinen Grund den Code zu 
veröffentlichen. Es ist weder moralisch noch rechtlich in Ordnung. Das 
ist ihr System, sie haben dort sicherlich viel Geld reingesteckt.
Wer das System nutzen will um z.B. in sein Projekt eine Wettervorhersage 
einzubauen, der soll sich eine Wetterstation kaufen und den Chip 
ausbauen.

Wenn euch der Code interessiert, dann müsst ihr in selbst herausfinden. 
Ich hab ihn auch nicht, aber bin zurzeit mit jemand anderem dabei den 
Code zu ermitteln. Aber ohne viel Geduld und Herumprobieren wird das 
nichts.

Jo Ka schrieb:
> Ich denke hier hätte keiner ein Problem damit
> Meteotime für den Chip zu bezahlen, aber dass sie uns im Regen stehen
> lassen ist was jedem Frust bereitet.

Mal eine blöde Frage, wozu? Wenn Du die Wettervorhersage haben willst, 
die bekommst Du anders auch billiger, beispielsweise aus dem Internet 
oder über Kurzwelle.

Christian Berger schrieb:
> Jo Ka schrieb:
>> Ich denke hier hätte keiner ein Problem damit
>> Meteotime für den Chip zu bezahlen, aber dass sie uns im Regen stehen
>> lassen ist was jedem Frust bereitet.
>
> Mal eine blöde Frage, wozu? Wenn Du die Wettervorhersage haben willst,
> die bekommst Du anders auch billiger, beispielsweise aus dem Internet
> oder über Kurzwelle.

Es gibt homebrew Projekte die um weniger komplex zu werden auf eine 
Internet Anbindung verzichten.

Johannes O. schrieb:
> Aber auch im internen Forum wurde der komplette Code NICHT
> veröffentlicht und das wird auch nicht passieren.
> Warum? Genau aus diesem Grund: Er wird verbreitet werden und das wird
> keine positiven Folgen für HKW haben.
>

HKW interessiert sich nicht für uns. Jedenfalls kam bislang kein 
Statement.


> Es ging nie darum den Code zu veröffentlichen, sondern nur darum,
> herauszufinden wie sicher das ganze System ist.

Das ist deine nun vorgeschobene Meinung. Damit wird aber haarscharf an 
der Ursache-Wirkungs-Grenze manövriert!
Ich habe vor Äonen hier geschrieben, es wäre eine Verwendung für eigene 
Projekte möglich:
- Fehlerkorrektur
- Verschlüsselung


> Wir wollen HKW nicht schaden. Es gibt keinen Grund den Code zu
> veröffentlichen. Es ist weder moralisch noch rechtlich in Ordnung. Das
> ist ihr System, sie haben dort sicherlich viel Geld reingesteckt.
> Wer das System nutzen will um z.B. in sein Projekt eine Wettervorhersage
> einzubauen, der soll sich eine Wetterstation kaufen und den Chip
> ausbauen.
>

Im Prinzip akzeptiere ich das(!!), allerdings nicht das HKW resp. 
MeteoTime auch nicht das Interesse der Bastler akzeptiert, einen Chip 
kaufen zu wollen. Eine Hand wäscht die andere!


Ich persönlich habe keine Interesse am Code (Begründung: Ich habe 
besseres für meine Projekte). Es ging mir nur darum, es klar 
darzustellen.


Für mich ein interessanter Elektronik-Krimi über lange Zeit. Es sah ja 
öfters sehr nach Durststrecke aus.

Abdul K. schrieb:
>> Es ging nie darum den Code zu veröffentlichen, sondern nur darum,
>> herauszufinden wie sicher das ganze System ist.
>
> Das ist deine nun vorgeschobene Meinung. Damit wird aber haarscharf an
> der Ursache-Wirkungs-Grenze manövriert!
> Ich habe vor Äonen hier geschrieben, es wäre eine Verwendung für eigene
> Projekte möglich:
> - Fehlerkorrektur
> - Verschlüsselung

Mir geht es speziell um die Veröffentlichung des Codes. Das wollte 
bisher keiner Machen was auch gut so ist. Und nicht nur mir geht es 
darum rauszufinden wie sicher das ist. Das habe ich auch schon von 
anderen gehört.
Eine ALLGEMEINE Aussage habe ich an keiner Stelle getroffen. Dass es 
Leute gibt die das anders sehen ist natürlich klar.


Habt ihr eigentlich schonmal bei HKW angefragt gehabt ob man so einen 
Chip kaufen könnte? Aber das Argument zieht auch nicht mehr wirklich, 
nachdem der Preis für die Wetterstationen schon etwas länger am fallen 
ist. Außerdem zwingt euch ja niemand dieses System zu benutzen: 
Wetterberichte im Internet müssten eigentlich eine Ähnliche Qualität 
haben, auch die lassen sich auslesen.


HKW interessiert sich nicht für uns? Mag sein. Evtl. lesen sie ja mit. 
Bis vor 2-3 Wochen hat es ja wirklich schon so ausgesehen als wäre das 
ganze Ding sicher. Hat ja 3 Jahre gedauert bis es geknackt war.

Falk O. schrieb:
> Meldung aus der "Core Group":
>
> es ist gelungen, mit Hilfe der RAM Dumps den Algorithmus zu
> rekonstruieren.

Ebenfalls herzlichen Glückwunsch!
Ich lese jetzt seit knapp nach dem Anfang vom ersten Thread passiv mit, 
und muss sagen, das ganze Projekt ist auch für Unbeteiligte sehr 
lehrreich!
Dokumentiert ist das ganze ja schon weitgehend "Live" in den beiden 
Threads - sollte man unbedingt mal irgendwo absichern.

Mal davon abgesehen habe ich nicht wirklich damit gerechnet, dass am 
Ende der Code im Forum landet, und finde das auch okay. Ansonsten könnte 
jedes Geschäftsmodell das auf die Vorhaltung nicht-öffentlicher Daten 
setzt sowieso gleich einpacken. Ich beschäftige mich zwar auch mit 
reverse engineering und schaue gern hinter die Kulissen, aber ob die 
Ergebnisse veröffentlicht werden sollten ist halt immer die Frage. Eine 
gehackte Firmware für eine Spielekonsole oder einen MP3-Player eröffnet 
neue und ungeplante Möglichkeiten, das Knacken eines Transportstroms 
dagegen eigentlich nur den Zugriff auf (im Wortsinn) "wertvolle" Daten. 
Wenn der Hersteller sich um Bastler nicht schert ist das zwar echt 
ärgerlich, aber ob es zum massenhaften "Einbruch" berechtigt...naja. Ob 
ihr euren Code jetzt für euch selbst verwendet oder nicht ist allerdings 
recht gleich, ihr habt ja schließlich eh schon genug Decoder für eine 
Kleinstadt gekauft;-)

Danke für den interessanten Exkurs jedenfalls, wirklich fast ein echter 
"Krimi"! Schön, dass ihr's geschafft habt.

Anton Wert schrieb:
> Ich glaub nicht dass was geknackt wurde.
> Im "Spezial-Forum" wird keiner reingelassen, auf Nchrichten wird seit
> Wochen nicht reagiert. Und auch hier im Forum verschwinden Beiträge.
> Meine Theorie: Die Webseitenbetreiber haben Ärger bekommen, und
> versuchen nun auf diese Weise aus der Nummer rauszukommen.

@Anton,

Es wurde geknackt,

Es werden nur benutzer hineingelassen, welche auch aktiv am Thema 
mitarbeiten, und dieses auch in Zukunft tun. Das ist jetzt aber 
hinfällig, deshalb wird nun Keiner mehr hineingelassen. Registrierungen 
laufen ins Leere.

Ich habe keinen Ärger bekommen.

Ebenso habe ich keine Emails bekommen.

Gruß Thomas

Johannes O. schrieb:
> Abdul K. schrieb:
>>> Es ging nie darum den Code zu veröffentlichen, sondern nur darum,
>>> herauszufinden wie sicher das ganze System ist.
>>
>> Das ist deine nun vorgeschobene Meinung. Damit wird aber haarscharf an
>> der Ursache-Wirkungs-Grenze manövriert!
>> Ich habe vor Äonen hier geschrieben, es wäre eine Verwendung für eigene
>> Projekte möglich:
>> - Fehlerkorrektur
>> - Verschlüsselung
>
> Mir geht es speziell um die Veröffentlichung des Codes. Das wollte
> bisher keiner Machen was auch gut so ist. Und nicht nur mir geht es
> darum rauszufinden wie sicher das ist. Das habe ich auch schon von
> anderen gehört.
> Eine ALLGEMEINE Aussage habe ich an keiner Stelle getroffen. Dass es
> Leute gibt die das anders sehen ist natürlich klar.
>

Hab ich jetzt nicht verstanden. Welche ALLGEMEINE Aussage?

Du weißt aber schon, daß ich mittlerweile die Mittel habe den Code 
komplett auszulesen. Es würde mir nur einige maximal Wochen Arbeit 
machen.


>
> Habt ihr eigentlich schonmal bei HKW angefragt gehabt ob man so einen
> Chip kaufen könnte? Aber das Argument zieht auch nicht mehr wirklich,
> nachdem der Preis für die Wetterstationen schon etwas länger am fallen
> ist. Außerdem zwingt euch ja niemand dieses System zu benutzen:
> Wetterberichte im Internet müssten eigentlich eine Ähnliche Qualität
> haben, auch die lassen sich auslesen.
>

Ich persönlich hatte nie dort gefragt. Soweit ich mich erinnere, waren 
hier zwei Personen die nach Chips fragten und eine Abfuhr bekamen.

Gut, eine Firma muß nicht Geschäfte eingehen, aber wir müßten auch nicht 
den Code geheimhalten.


>
> HKW interessiert sich nicht für uns? Mag sein. Evtl. lesen sie ja mit.
> Bis vor 2-3 Wochen hat es ja wirklich schon so ausgesehen als wäre das
> ganze Ding sicher. Hat ja 3 Jahre gedauert bis es geknackt war.

Vermutlich saßen sie bislang auf dem hohen Roß - sitzen wir nicht alle 
gerne dort?


@Thomas:
Absagen hättest du schon können.

Bei den Meisten Benutzern, welche sich registriert haben habe ich mit 
einer Email angefragt, im Betreff stand "Zulassungsbeschränkung für ..."

Da habe ich ein paar Fragen gestellt, leute die nicht auf die Email 
genantwortet haben, haben von mir keine weitere Antwort bekommen,

Diejenigen die geantwortet haben, bekamen eine Freundliche Antwort.

Problematisch ist nur der Moment gewesen nachdem der Link zum Forum 
gepostet wurde, es gab weit über 100 Registrierungsversuche, und allen 
eine mail zu schreiben ist nicht so schön, zumal ich zur Zeit mitten im 
Prüfungsstress stecke.

Gruß
Thomas

> Hab ich jetzt nicht verstanden. Welche ALLGEMEINE Aussage?
Ich dachte du meintest, dass ich das auf alle beziehe? Naja auch egal, 
haben wir vermutlich aneinander vorbeigeredet ;-)

Hört sich aber interessant an, dass du mit ein paar Wochen arbeit den 
Code auslesen könntest. Hab jetzt aber selbst ne Methode gefunden wo ich 
zumindest Teile des Codes indirekt herausfinden kann. Also ich könnte 
z.B. sagen dass sich da der Stelle 0x123 im Flash ein RRF 0x12 oder so 
befindet. Ist aber ne andere Technik wieder, baut aber auf den aktuellen 
Methoden auf.


Ok das mit den Chips wusste ich noch nicht. Aber wie du schon schreibst: 
Eine Firma muss nicht Geschäfte eingehen.
Das ist ja auch keine HKW-Sache, dass dies die einzige wären die sich so 
verhalten. Bei vielen größeren Firmen kann man nur schwer als 
Privatperson irgendwas bestellen.


>> HKW interessiert sich nicht für uns? Mag sein. Evtl. lesen sie ja mit.
>> Bis vor 2-3 Wochen hat es ja wirklich schon so ausgesehen als wäre das
>> ganze Ding sicher. Hat ja 3 Jahre gedauert bis es geknackt war.

>Vermutlich saßen sie bislang auf dem hohen Roß - sitzen wir nicht alle gerne 
dort?

Ehrlich gesagt: Ich habs auch nicht geglaubt dass das irgendwann mal 
geknackt wird. Hätte mir also auch Gedacht: Ja lass die mal basteln das 
wird eh nix ;-)

Thomas Berends schrieb:
> Bei den Meisten Benutzern, welche sich registriert haben habe ich mit
> einer Email angefragt, im Betreff stand "Zulassungsbeschränkung für ..."
>
> Da habe ich ein paar Fragen gestellt, leute die nicht auf die Email
> genantwortet haben, haben von mir keine weitere Antwort bekommen,
>
> Diejenigen die geantwortet haben, bekamen eine Freundliche Antwort.

Das liest sich ja noch ganz gut.

Thomas Berends schrieb:
> Problematisch ist nur der Moment gewesen nachdem der Link zum Forum
> gepostet wurde, es gab weit über 100 Registrierungsversuche, und allen
> eine mail zu schreiben ist nicht so schön, zumal ich zur Zeit mitten im
> Prüfungsstress stecke.

Das nicht.

Ich hätte auch gerne eine E-Mail von dir erhalten. Lieber hätte ich auch 
eine Absage erhalten als überhaupt keine Reaktion.

Man kann nicht einerseits hingehen und Interesse wecken, die Leute Zeit 
investieren lassen und dann nichts zurückgeben.

Die Obergrenze war 1000 Euro von einem deutschen Anbieter (Zumindest 
vertreibt er das Angebot). Arbeitszeit war sicherlich insgesamt sehr 
weit drüber, je nachdem man rechnet, könnte man die 100K erreichen.

Ein recht brutaler Weg den sozusagen exakten Wert zu beziffern, wäre 
natürlich dieser: HKW fragen, was sie bereit sind zu zahlen für eine 
Nichtveröffentlichung. Dagegen könnten sie nicht wirklich was machen.


Für mich sieht es so aus, das man nicht allzuviel vom interessanten Weg 
veröffentlichen kann. Der Rest hatte sich fast automatisch entwickelt. 
Jeder draußen würde nun mehr oder weniger genauso vorgehen. Damit wäre 
der Code offengelegt - letztendlich.
Eines möchte ich aber abschließend sagen: Dieser PIC ist für eure 
Projekte NICHT SICHER!

Hi,

Dieter schrieb:
> Die "Obergrenze" des Aufwands um die Sicherheit des Systems zu brechen
> war schon sehr früh ziemlich klar: Man kann sich von diversen Anbietern
> den Flash/ROM einen Mikrocontrollers auslesen lassen, egal ob EM6580
> oder PIC12F509, Grössenordnung um die 10.000 USD (das ist eine
> Größenordnung, kein genauer Preis).

Da bist du aber mindestens eine Zehnerpotenz daneben...
Für "normale" 08/15 µC liegt der Preis für ein Auslesen mit invasiven 
Methoden mittlerweile bei unter 1000 Dollar. Teilweise unter 500 USD.
Die 10K Euro sind da schon eher der Bereich der speziell geschützten µC 
mit interner Verschlüsselung des Programmspeichers wo noch deutlich mehr 
aufwand betrieben werden muss als nur das GEhäuse zu öffnen und die CP 
Fuse geziehlt zu löschen (bzw. zu brücken wenn nötig) bzw. den Flash 
speicher direkt mit Mikroprobes auszulesen.
Allerdings wird es dann auch schnell noch teurer bis hin zu unmöglich 
bei ganz aktuellen High Security Bausteinen...

Aber ein 08/15 12F509 von dem Microchip ja selber sagt das er nur eine 
mäßige Programmsicherheit bietet, das ist für jede Firma die das 
regelmäßig macht eine kleine Fingerübung.

Letztendlich ist es ja egal


Davon Abgesehen:
Ob man jetzt glaubt das wirklich ein oder zwei Leute den WEg jetzt 
ausserhalb HKW kennen oder man annimt das es nur eine Nebelkerze ist um 
die Überlegungen hier zu stoppen...

Wer mit dem jetzigen Ergebniss nicht zufrieden ist kann ja einfach 
weitermachen. Es gibt ja durchaus mehrere die entsprechende Fähigkeiten 
haben. Ganz unabhängig ob jetzt in dem internen Forum dabei oder nicht.
ICh habe mir mittlerweile auch zwei 9 Euro Uhren besorgt und werden wenn 
dann mal etwas mehr zeit ist meine Angriffsideen durchprobieren.

Daher würde ich sagen:
Meldung zur Kenntniss genommen und der REst macht unbeirrt weiter im 
Text.
Evtl. lassen sich die genannten Details auch nutzen, wenn man aber die 
Möglichkeit einer Nebelkerze in Betracht ziehen würde, dann muss man 
natürlich auch in betracht ziehen das die Falsch sind.
Wir -rest- wissen es nicht und müssen uns daher beide optionen weiter 
offen halten.

Gruß
Carsten

Anton Wert schrieb:
> Ich hatte versucht michzu registrieren, eine Antort kam nie. Weder als
> Frage noch in irgendeiner anderen Form.
>
> Es ist also ganz klar dass es sich um eine Schutzbehauptung der "Gruppe"
> handelt, da sie nun durch ihre Arbeit ärger bekommen haben.
>
> Das keine neuen Leute reingelassen werden zeigt auch ganz deutlich dass
> dahinter nix ist, was damit rauskommen würde...

Quatsch. Zuviele Köche verderben den Brei. Allein schon das Risiko der 
Unterwanderung ist viel zu groß. Sowas in DE zu hosten, ist schon ein 
Risiko. Da kommt die einstweilige Verfügung vom planlosen Richter und 
weg ist erstmal ALLES!

Einen Beweis können wir so nicht darstellen, tut mir leid. 2013 läuft 
allerdings die Lizenz erstmal aus. Vielleicht ergibt sich danach eine 
Möglichkeit. Weiß ich nicht.

Hm. Da kommt mir eine Idee:
Aufsetzen eines Online-Encoders zum Selberprobieren. Das wäre doch eine 
gute Idee. Was halten die Mitstreiter davon?

Abdul K. schrieb:
> Eines möchte ich aber abschließend sagen: Dieser PIC ist für eure
> Projekte NICHT SICHER!

DAS ist ja bekannt, Die Sicherheit dieser µC ist genauso wie die von den 
AVR und den meisten ARM nur eher Mittelmäßig und hält einem mit einigen 
KnowHow geführtem Angriff nicht dauerhaft stand.

Das schreibt Microchip aber selbst in den Datenblättern. WEr eine hohe 
Sicherheit will muss halt in spezielle High Security Architekturen 
investieren die es auch gibt.
Aber in den meisten Fällen spielt das eh keine Rolle weil der Großteil 
der µCs doch in einer einer Umgebung eingesetzt wird wo das 
neuprogrammieren einer Software anhand des Wissens um die benötigte 
Funktion geringerer Aufwand ist als das brechen des Kopierschutzes.

Und mal ehrlich: Für jemanden der Kommerziell von dem Klau fremder Ideen 
profitieren will sind 1000Euro ein Witz...

Nur in Umgebungen wo es auf absoluten SChutz des Inhalts ankommt, z.B. 
bei PayTV reicht es nicht den weg steinig zu machen. DA muss man eine 
Menge aufwand betreiben um eine nahezu absolute Sicherheit zu bekommen. 
Eine "Sky" Karte komplett auszulesen würde sich viele Anbieter viel mehr 
kosten lassen als nur 10K-Euro da damit dann ein deutlich größerer 
GEwinn zu machen wäre. (Komerzeille Nutzung, ja sogar verwendung des 
Produktes natürlich höchst illegal!)

GRuß
Carsten

Abdul K. schrieb:
> Die Obergrenze war 1000 Euro von einem deutschen Anbieter (Zumindest
> vertreibt er das Angebot). Arbeitszeit war sicherlich insgesamt sehr
> weit drüber, je nachdem man rechnet, könnte man die 100K erreichen.
>
> Ein recht brutaler Weg den sozusagen exakten Wert zu beziffern, wäre
> natürlich dieser: HKW fragen, was sie bereit sind zu zahlen für eine
> Nichtveröffentlichung. Dagegen könnten sie nicht wirklich was machen.
>
>
> Für mich sieht es so aus, das man nicht allzuviel vom interessanten Weg
> veröffentlichen kann. Der Rest hatte sich fast automatisch entwickelt.
> Jeder draußen würde nun mehr oder weniger genauso vorgehen. Damit wäre
> der Code offengelegt - letztendlich.
> Eines möchte ich aber abschließend sagen: Dieser PIC ist für eure
> Projekte NICHT SICHER!

Das wäre Erpressung und sicher nicht ratsam.

> Eine patentierte Sache darf ich für mich nachbauen ohne Patentstreitig-
keiten zu bekommen, nur KOMMERZIELL nutzen darf ichs es nicht.
(KEIN Rechtsrat, nur meine Meinung).

Problem ist: Du darfst dann davon noch nicht einmal berichten! Denn wenn 
du es machst, ermöglichst du es anderen das (eventuell 'leichter') 
nachzubauen und das kann den Gewinn des Patentinhabers mindern. Er hat 
aber einen Anspruch auf allen Gewinn aus seinem Patent. Damit haben 
sie dich an der Kandare!
Das is sozusagen die Metaebene des Verkaufs.


@Ja Ka:
Bzw. Nötigung. Ist aber wurscht, wenn die Anfrage aus China kommt.

a) Es gibt Institutionen wie beispielsweise den CCC die liebend gerne 
das Risiko übernehmen. Siehe beispielsweise die Veröffentlichungen zum 
Fahradmietsystem der Bahn. Die haben auch eine "Ethikhotline".

b) Solch ein System kann niemals sicher sein. In der Kryptographie 
spricht man häufig von der Senderin Alice und dem Empfänger Bob. Die 
Angreiferin ist dann meistens Malice. Nur haben wir es hier mit einem 
System zu tun bei dem Bob gleich Malice ist. Bob muss die Daten bekommen 
können, darf sie aber nicht bekommen, da er Malice ist. Das ist 
unlogisch und somit kann das nicht funktionieren. Das Geschäftsmodell 
basiert nicht auf der Technik, es basiert auf Vertrauen. Beim Pay-TV ist 
es ja ähnlich.

Abdul K. schrieb:

> Hm. Da kommt mir eine Idee:
> Aufsetzen eines Online-Encoders zum Selberprobieren. Das wäre doch eine
> gute Idee. Was halten die Mitstreiter davon?

Von meiner Seite kein Problem, ich könnte die Deocder-Access soweit 
umbauen, das die Datenbank nicht mehr genutzt wird, Decoder werden vom 
Server abgesteckt, und dann dürfen die leute da gerne mal merhere 
tausend datensätze dekodieren lassen,
Es lässt sich dann leicht erkennen ob es über den Algorythmus geht, oder 
über einen Decoder, denn der Decoder würde stunden/Tage brauchen, je 
nach Menge.

Wann ich das Realisiert bekomme kann ich nicht sagen, wie gesagt -> 
Prfungsstress

Patentkenner schrieb:
> Abdul K. schrieb:
>> Problem ist: Du darfst dann davon noch nicht einmal berichten! Denn wenn
>> du es machst, ermöglichst du es anderen das (eventuell 'leichter')
>> nachzubauen und das kann den Gewinn des Patentinhabers mindern. Er hat
>> aber einen Anspruch auf allen Gewinn aus seinem Patent. Damit haben
>> sie dich an der Kandare!
>
> So ein Quatsch! Patentschriften werden vom Patentamt offengelegt und
> sind sogar online recherchierbar. Wie sollte jemand auch sonst wissen,
> ob er das Patent eines anderen verletzt?
>

Ob jemand das Patent kennt, ist völlig ohne Belang. Es ist genauso wie 
mit Gesetzen. Die Unkenntnis schützt nicht vor Bestrafung.

Ich habe selbst ein Patent angemeldet. Mußte mich mit den 
Gepflogenheiten auseinandersetzen.

Du kannst ohne Problem von der Kenntnis eines Patents berichten, aber 
mußt vermeiden seine Anwendung darzustellen.

Christian Berger schrieb:
> a) Es gibt Institutionen wie beispielsweise den CCC die liebend gerne
> das Risiko übernehmen. Siehe beispielsweise die Veröffentlichungen zum
> Fahradmietsystem der Bahn. Die haben auch eine "Ethikhotline".
>

Wer bezahlt bei CCC denn?
Und was ist, wenn in dem Rechtsverfahren dann rauskommt, das der CCC 
nicht der Urheber der Infos ist? Dann kommen sie nämlich HIER an und 
bohren!


> b) Solch ein System kann niemals sicher sein. In der Kryptographie
> spricht man häufig von der Senderin Alice und dem Empfänger Bob. Die
> Angreiferin ist dann meistens Malice. Nur haben wir es hier mit einem
> System zu tun bei dem Bob gleich Malice ist. Bob muss die Daten bekommen
> können, darf sie aber nicht bekommen, da er Malice ist. Das ist
> unlogisch und somit kann das nicht funktionieren. Das Geschäftsmodell
> basiert nicht auf der Technik, es basiert auf Vertrauen. Beim Pay-TV ist
> es ja ähnlich.


Bislang war es sicher, außer jemand kann einen früheren Zeitpunkt 
glaubhaft machen.

> Von meiner Seite kein Problem, ich könnte die Deocder-Access soweit
> umbauen, das die Datenbank nicht mehr genutzt wird, Decoder werden vom
> Server abgesteckt, und dann dürfen die leute da gerne mal merhere
> tausend datensätze dekodieren lassen,
> Es lässt sich dann leicht erkennen ob es über den Algorythmus geht, oder
> über einen Decoder, denn der Decoder würde stunden/Tage brauchen, je
> nach Menge.

Ich hatte den umgekehrten Weg verstanden:
> Aufsetzen eines Online-Encoders
>                        ^^^^^^^^

D.h. die User können sich selbst verschlüsselte Pakete mit individuellen 
Wetterinfos erstellen lassen. Das würde alle Zweifel (von Seiten der 
User) ausschließen; diejenigen, die sich wirklich damit beschäftigen 
können den generierten Ciphertext ja problemlos in einen Decoder 
füttern.

MfG
P.Wassi

Thomas Berends schrieb:
> Abdul K. schrieb:
>
>> Hm. Da kommt mir eine Idee:
>> Aufsetzen eines Online-Encoders zum Selberprobieren. Das wäre doch eine
>> gute Idee. Was halten die Mitstreiter davon?
>
> Von meiner Seite kein Problem, ich könnte die Deocder-Access soweit
> umbauen, das die Datenbank nicht mehr genutzt wird, Decoder werden vom
> Server abgesteckt, und dann dürfen die leute da gerne mal merhere
> tausend datensätze dekodieren lassen,
> Es lässt sich dann leicht erkennen ob es über den Algorythmus geht, oder
> über einen Decoder, denn der Decoder würde stunden/Tage brauchen, je
> nach Menge.
>
> Wann ich das Realisiert bekomme kann ich nicht sagen, wie gesagt ->
> Prfungsstress

Hm. Deine Vorstellung wäre auch eine Idee. Einfach den Software-Decoder 
schneller machen als das Original. Das kann man aber wieder anzweifeln. 
Kommt bestimmt einer, der behauptet, du hättest eh schon praktisch alle 
Datensätze in der Datenbank.
Ich schrieb von Encoder! Der große Meister könnte dir den Code liefern 
und die Leute können z.B. "Hanswurst" codieren lassen und mit dem von 
dir bereits bekannten Online-Decoder decodieren lassen.
Oder den entstehenden Datenstream auf ihren eigenen Wecker einschleusen 
und dort den PIC decodieren lassen. Das ist doch glaubwürdiger.

> "Hanswurst" codieren lassen und mit dem von
> dir bereits bekannten Online-Decoder decodieren lassen.

En- und Decoder aus einer einer Hand ist aber auch anzweifelbar ;-)

MfG
P.Wassi

Ups, Sorry, hab da falsch gelesen...

En und De Coder ist ja auch nicht viel Unterschied ;)

Aber meine Meinung dazu bleibt die gleiche.

Abdul K. schrieb:

> Wer bezahlt bei CCC denn?

Ich und etwa 3000 weitere Mitglieder mit ihren Mitgliedsbeiträgen.

> Und was ist, wenn in dem Rechtsverfahren dann rauskommt, das der CCC
> nicht der Urheber der Infos ist? Dann kommen sie nämlich HIER an und
> bohren!

Für den CCC arbeiten auch Juristen. Die sind nicht doof. Und die haben 
solche Sachen auch in der Vergangenheit gemacht. Die stecken ja auch 
hinter Verfassungsbeschwerden wie die gegen die Vorratsdatenspeicherung 
oder Wahlcomputer.

> Bislang war es sicher, außer jemand kann einen früheren Zeitpunkt
> glaubhaft machen.

Nein, Du konntest schon immer die Daten einfach von der "Wetterstation" 
auslesen, beispielsweise über das Display, und an andere Leute 
weitergeben.

P. Wassi schrieb:
>> "Hanswurst" codieren lassen und mit dem von
>> dir bereits bekannten Online-Decoder decodieren lassen.
>
> En- und Decoder aus einer einer Hand ist aber auch anzweifelbar ;-)
>

Wenn du weitergelesen hättest, würde da die Option eigener PIC (bzw. 
der EM-Marin Chip) in deiner Uhr stehen!

Also leg nach!

Thomas Berends schrieb:
> Ups, Sorry, hab da falsch gelesen...
>
> En und De Coder ist ja auch nicht viel Unterschied ;)
>
> Aber meine Meinung dazu bleibt die gleiche.

Der große Meister hat doch ein Encoder - wurde zumindest berichtet.

Michael Meier schrieb im Beitrag #2240117:
> Abdul K. schrieb:
>> Einen Beweis können wir so nicht darstellen, tut mir leid. 2013 läuft
>> allerdings die Lizenz erstmal aus. Vielleicht ergibt sich danach eine
>> Möglichkeit. Weiß ich nicht.
>
> Wenn der Algorithmus oder eine Beschreibung davon anonym auf Pastebin
> auftaucht, wird euch niemand dafür belangen können. Das Problem ist nur
> das selbe wie bei vielen anderen: Ihr würdet auf diese Weise keinen
> "Ruhm" ernten. DESHALB wollt ihr nichts veröffentlichen.

Oh je. Der beste Ruhm sieht so aus: Ich verkaufe dir einen 
programmierten PIC! Da HKW keine verkaufen will, zu einem überhöhten 
Preis. Denn du sparst damit das Entlöten des PICs. Würdest ihn sogar 
gerne als _DIP fürs Steckbrett bekommen.

Nachgedacht? Offensichtlich nicht.

Hi

Sollte es wirklich entschluesselt sein, dann

RESPEKT

und ein Danke an all diejenigen die hier einen sehr interessanten Thread 
erstellt haben.

Und ICH persoenlich finde es voellig in Ordnung nichts zu 
veroeffentlichen oder irgendwelche Infos rauszuruecken. Wer es selbst 
nicht kann, soll es lernen und wer dazu zu faul ist, soll nicht meckern. 
Denn wie ueblich im Internet, will wieder jeder alles fuer Lau ohne auch 
nur ein bisschen sein eigenes Hirn anzustrengen.

Danke fuer diesen schoenen Thread.

Christian Berger schrieb:
> Abdul K. schrieb:
>
>> Wer bezahlt bei CCC denn?
>
> Ich und etwa 3000 weitere Mitglieder mit ihren Mitgliedsbeiträgen.

'Bezahlt' bezog sich auf Haftung.
HKW könnte kommen und das wohlmöglich potentiell verlorene Geld 
einklagen.


>
>> Und was ist, wenn in dem Rechtsverfahren dann rauskommt, das der CCC
>> nicht der Urheber der Infos ist? Dann kommen sie nämlich HIER an und
>> bohren!
>
> Für den CCC arbeiten auch Juristen. Die sind nicht doof. Und die haben
> solche Sachen auch in der Vergangenheit gemacht. Die stecken ja auch
> hinter Verfassungsbeschwerden wie die gegen die Vorratsdatenspeicherung
> oder Wahlcomputer.
>

Aha. Naja, mir ist es egal.


>> Bislang war es sicher, außer jemand kann einen früheren Zeitpunkt
>> glaubhaft machen.
>
> Nein, Du konntest schon immer die Daten einfach von der "Wetterstation"
> auslesen, beispielsweise über das Display, und an andere Leute
> weitergeben.

Gutes Argument!

Ist wie fremdes Tagebuch lesen. Mehr wohl nicht.
Bei einem echten Krimi mit Toten, wirste ja auch nicht zum Mörder. Je 
nach Ausrichtung freust du dich am Ende über die wiederhergestellte 
Gerechtigkeit lol oder über die Finesse des Mörders *wenn ich nicht so 
blöde wäre, dann könnte ich genauso den Chef loswerden*

Letztlich geht es also um Betrug und Lüge. Die machen Spaß.

gelegentlicher Mitleser schrieb:

> Vorab: Ich persönlich hab exakt 0,0 Interesse an dem Algorithmus, den
> Wetterbericht hole ich ganz bequem, kostenlos und völlig legal aus dem
> Internet. (Außerdem stimmt er eh nicht...)

Sehe ich genau so.

> Jetzt haben also ein paar Personen (oder eine einzige?) einen
> Algorithmus auf der Festplatte den sie nicht veröffentlichen dürfen,
> nichtmal für all die die selber viel Zeit (und Geld - Wetterstationen)
> in die Sache gesteckt haben, richtig? Was bekommen all die Personen die
> geholfen haben schlussendlich? Nichts.

Und ? Diejenigen die geholfen haben, haben sicherlich einiges gelernt. 
Also NICHTS haben sie ganz sicher NICHT bekommen. Und die Vielen die 
hier mitgelesen haben, ebenfalls.

> Mir stellt sich zwangsläufig folgende Frage: Warum wurde der ganze
> Aufwand überhaupt betrieben?

Um zu lernen, um Ehrgeiz zu fordern, ich kann das, ich will das, ich 
schaff' das. ...irgendwann.

Ich weiss nicht warum sich hier alle so aufregen. Es hat doch niemand 
gesagt das da auch was bei raus kommt. Wenn sich alle nun hunderte von 
Uhren gekauft haben und nur darauf gewartet haben "Hier ist er" dann 
kann ich nur sagen, ARM.

gelegentlicher Mitleser schrieb:
^
> Es war doch von vorne herein klar dass das
> Ergebnis nicht veröffentlicht werden kann ohne das die Person die das
> tut eine Menge Ärger riskiert.

Das ist falsch! Selbsterbrachtes Wissen zu teilen kann man nicht rügen! 
Das ist auch der Grund warum Unis einen Code knacken dürfen, ohne das 
etwas passiert (siehe COPACOBANA). Denn das was hier gemacht wird ist 
schlicht weg das Wissen zu erweitern. Alles andere sind 
Fadenscheinigkeiten.

Ich glaube das festgestellt wurde, das der Aufwand zu groß íst, und man 
lediglich das Gesicht waren möchte. Oder es kam Geld geflossen, das man 
den Mund hält. Ich habe ja damals den Meteo-Thread ins leben gerufen, 
aber selbst für mich gabs keine Infos. Und für mich war es nur "Sport" 
um das Wissen zu erweiter. Soetwas kann man nicht verfolgen! Wir sind ja 
schließlich nicht mehr in 1943.

Abdul K. schrieb:
> Christian Berger schrieb:
>> Abdul K. schrieb:
>>
>>> Wer bezahlt bei CCC denn?
>>
>> Ich und etwa 3000 weitere Mitglieder mit ihren Mitgliedsbeiträgen.
>
> 'Bezahlt' bezog sich auf Haftung.
> HKW könnte kommen und das wohlmöglich potentiell verlorene Geld
> einklagen.

Wie schon gesagt, im Gegensatz zu so vielen anderen sind die nicht doof. 
Wie wissen genau was man wie veröffentlichen kann ohne juristisch 
angreifbar zu sein. Wobei das mit dem verlorenen Geld albern ist. Die 
verlieren ja nichts dabei.

Oder natürlich die "Pastebin" Lösung über Tor. Das ist trivial einfach 
und der Aufwand das nachzuvollziehen liegt wohl im Milliardenbereich. 
Man müsste dann genau die richtigen Rechner beschlagnahmen (verteilt 
über die ganze Welt) und noch irgendwie dann den RAM-Inhalt von dem 
damaligen Zustand rekonstruieren. Ich glaube nicht, dass jemand den 
Aufwand betreiben wird.

Hm. Wann ist es eigentlich strafbar einen Code zu knacken? Bin da echt 
überfragt. Es war schließlich alles eigene Arbeit. Niemand wurde 
erpreßt, oder in seinen Unterlagen zuhause gewühlt.

Ob Geld floß oder nicht, ich weiß es nicht. Aus der Psychologie ist aber 
bekannt, daß allein die Erwähnung von Geld das Belohnungssystem stark 
anregt und JETZT KOMMTS das Sozialverhalten, von einem selbst unbemerkt, 
abwürgt.
Klar, wen wunderts wenn man so erzogen wurde: 'Oma gibt eine Mark, wenn 
du sie küßt.' Das ist dann doch klar. Mir zumindest.

Christian Berger schrieb:
> Wie schon gesagt, im Gegensatz zu so vielen anderen sind die nicht doof.
> Wie wissen genau was man wie veröffentlichen kann ohne juristisch
> angreifbar zu sein. Wobei das mit dem verlorenen Geld albern ist. Die
> verlieren ja nichts dabei.
>

Kann man drüber diskutieren. Mich interessierst aber nicht sonderlich.

Ich weiß auch nicht ob der CCC was positives ansich ist.


> Oder natürlich die "Pastebin" Lösung über Tor. Das ist trivial einfach
> und der Aufwand das nachzuvollziehen liegt wohl im Milliardenbereich.
> Man müsste dann genau die richtigen Rechner beschlagnahmen (verteilt
> über die ganze Welt) und noch irgendwie dann den RAM-Inhalt von dem
> damaligen Zustand rekonstruieren. Ich glaube nicht, dass jemand den
> Aufwand betreiben wird.

Wie landet dann die Info beim gemeinen Benutzer?

Abdul K. schrieb:
> Hm. Wann ist es eigentlich strafbar einen Code zu knacken? Bin da echt
> überfragt. Es war schließlich alles eigene Arbeit. Niemand wurde
> erpreßt, oder in seinen Unterlagen zuhause gewühlt.
>
> Ob Geld floß oder nicht, ich weiß es nicht. Aus der Psychologie ist aber
> bekannt, daß allein die Erwähnung von Geld das Belohnungssystem stark
> anregt und JETZT KOMMTS das Sozialverhalten, von einem selbst unbemerkt,
> abwürgt.
> Klar, wen wunderts wenn man so erzogen wurde: 'Oma gibt eine Mark, wenn
> du sie küßt.' Das ist dann doch klar. Mir zumindest.



Ich mein das es erst strafbar ist, wenn dadurch Straftaten begangen 
werden, wie z.B. Erschleichung von Dienstleistungen (knacken von PayTV 
etc.)

Das ist es meiner Meinung nach hier auch. Die Daten sind zum Schutz 
Verschlüsselt. Man muss sich ein Gerät kaufen um an die Wetterdaten 
heranzukommen. Jedoch ist das hier etwas anders, Es wird eher davon 
geredet, das Hersteller von Geräten Lizenzgebühren an meteotime zahlen, 
das in meinen Augen wieder sagt, das nicht jeder solche Geräte 
herstellen soll.

Man kann es interpretieren wie man will.

Gruß
Thomas

Interessiert das den CCC ueberhaupt ?

Ich meine es ist ja nun kein Wunderwerk, auch wenn viel Arbeit und Zeit 
drin steckt und das koennen wohl nur die Mitleser hier beurteilen.
Ein ueblicher Podcast bei CCC dauert etwa eine Stunde. Es waere 
vielleicht mal Erwaehnenswert "ach so, nebenher..." Aber mal ehrlich, 
wen interessiert das Ergebnis denn wirklich so sehr, dass man da gleich 
eine Sendung draus machen muss, oder der CCC es irgendwie 
veroeffentlichen sollte ?
Da hat der CCC wirklich interessanteres zu bieten.

Ich kenne einige Podcasts vom CCC. Die sind teils auch recht langweilig 
und langatmig.
Also, eine Stunde kann man damit problemlos füllen. Alleine die 
Tatsache, das man den PIC ansich in die Tonne treten kann, wird einigen 
recht ungemütlich aufstoßen.

Macht was ihr wollt. Das Internet bietet mehr Infos als man je lesen 
oder verdauen könnte.

Abdul K. schrieb:
> Alleine die
> Tatsache, das man den PIC ansich in die Tonne treten kann, wird einigen
> recht ungemütlich aufstoßen.

Holst Du da nicht etwas zu weit aus ? Ich bin zwar kein PIC - Fan, aber 
angenommen da waere ein AVR drin gewesen, ich bin mir sicher da waere 
das gleiche bei raus gekommen und es haette geheissen...

*Tatsache, das man den AVR ansich in die Tonne...*

Die Hersteller haetten es schlauer anstellen koennen und einen relativ 
unbekannten Chip nehmen koennen, dann waere es deutlich schwieriger 
geworden.

> Also, eine Stunde kann man damit problemlos füllen.

Ja, aber ob sich das auch jemand anhoert, dass war meine Frage... Das 
wird dann wieder so ein langweiliger langatmiger... Na Du weisst schon.

Peter W. schrieb:
> Interessiert das den CCC ueberhaupt ?
>...
> Ein ueblicher Podcast bei CCC dauert etwa eine Stunde. Es waere
> vielleicht mal Erwaehnenswert "ach so, nebenher..."

Naja, für einen Vortrag auf dem Congress oder dem Camp würde das locker 
reichen. (fürs Camp wäre es aber schon zu spät) Dann gibts ja auch noch 
die "Datenschleuder" das wissenschaftliche Fachblatt von denen.

Nebenbei dauert Chaosradio 2 Stunden und Chaosradio Express 
typischerweise 2-4 Stunden.

Oder man kannst es auch in 2600 veröffentlichen. Das ist ein 
amerikanisches Magazin. Dafür bekommt man dann ein T-Shirt und ein 
Jahresabo.

Beide nehmen anonyme Informationen entgegen, und mit beiden kann man 
reden. Allerdings ist das beim CCC oft ziemlich langsam, die machen das 
ja hauptsächlich in ihrer Freizeit.

Peter W. schrieb:
> Abdul K. schrieb:
>> Alleine die
>> Tatsache, das man den PIC ansich in die Tonne treten kann, wird einigen
>> recht ungemütlich aufstoßen.
>
> Holst Du da nicht etwas zu weit aus ? Ich bin zwar kein PIC - Fan, aber
> angenommen da waere ein AVR drin gewesen, ich bin mir sicher da waere
> das gleiche bei raus gekommen und es haette geheissen...

Ich erweitere meine Aussage gerne um weitere Typen. Warum nicht?!

Ich bin mit Mitglied im Core-Club und kenne daher viel mehr Details. 
Werde aber keine verraten. Es wurde wirklich unglaublich geschlampt.


>> Also, eine Stunde kann man damit problemlos füllen.
>
> Ja, aber ob sich das auch jemand anhoert, dass war meine Frage... Das
> wird dann wieder so ein langweiliger langatmiger... Na Du weisst schon.

Ich denke schon. Allein 100 wollten sich anmelden!

Christian Berger schrieb:
> Naja, für einen Vortrag auf dem Congress oder dem Camp würde das locker
> reichen. (fürs Camp wäre es aber schon zu spät) Dann gibts ja auch noch
> die "Datenschleuder" das wissenschaftliche Fachblatt von denen.

> Oder man kannst es auch in 2600 veröffentlichen. Das ist ein
> amerikanisches Magazin. Dafür bekommt man dann ein T-Shirt und ein
> Jahresabo.
>

Vom 2600 habe ich noch nie gehört. Befürchte aber, das es europäische 
Leser nicht erreicht bzw. am strikt europäischen System scheitert. In 
den USA wird das keine Sau interessieren. Höchstens vielleicht den 
PIC-Sicherheits -Anteil.

Wenn du Mitglied beim CCC bist, frag mal ob sie den Encoder-Programmteil 
auf ihre Website stellen würden.

Abdul K. schrieb:

> Wenn du Mitglied beim CCC bist, frag mal ob sie den Encoder-Programmteil
> auf ihre Website stellen würden.

Ich nimm daran nur passiv teil.

So allgemeine Sachen kannst Du an mail (at) ccc.de schicken. Das ist 
eine Mailingliste an der einige im CCC mitlesen, da solltest Du relativ 
schnell eine Antwort bekommen.
ds (at) ccc.de ist direkt die Datenschleuderredaktion, die sind aber im 
Moment anscheinend nicht so aktiv.

Im Allgemeinen kann es im Moment wahrscheinlich länger dauern, weil das 
Camp ansteht. Streams werden kurz vorher in diesem Wikki bekanntgegeben 
http://events.ccc.de/camp/2011/

Christian Berger schrieb:
> Abdul K. schrieb:
>
>> Wenn du Mitglied beim CCC bist, frag mal ob sie den Encoder-Programmteil
>> auf ihre Website stellen würden.
>
> Ich nimm daran nur passiv teil.

Ich ebenso was den Encoder angeht.


>
> So allgemeine Sachen kannst Du an mail (at) ccc.de schicken. Das ist
> eine Mailingliste an der einige im CCC mitlesen, da solltest Du relativ
> schnell eine Antwort bekommen.
> ds (at) ccc.de ist direkt die Datenschleuderredaktion, die sind aber im
> Moment anscheinend nicht so aktiv.
>

Ich werde dorthin nicht mailen. Aber die Code-Besitzer können es ja in 
Erwähnung ziehen.

Rechtlich kann evtl. auch das bereitstellen eines Webencoders ein 
Problem darstellen. Damit würden "choosen-plaintext" Angriffe möglich 
und damit dann eine differenzielle Kryptoanalyse. Würde ich auf jeden 
Fall vor der Bereitstellung juristisch abklären lassen. Hier kann evtl. 
der CCC helfen.

Wenn man aber die vorhandenen Daten zusammenfasst, kann man aber auch so 
feststellen:

- Der Schlüßel ist in den Zeitdaten versteckt bzw wird aus ihnen 
generiert. Im einfachsten Fall sind es die Zeitdaten selbst (IMHO 
ebenfalls 40Bit). Folgerung da verschiedene Crypts zum selben Klartext 
führen (siehe 0 Panne).

- Aufwändige, geprüfte (nichtlineare) S-Boxen sind unwahrscheinlich da 
z.B. der EM Chip nur sehr eingeschränkt Tabellen im Flash ablegen kann.

--> Es ist nur noch eine Frage der Zeit bis jemand ausserhalb des 
"core-teams" den Code knackt (und auch veröffentlicht) und damit den 
"Ruhm" einheimst. Sollte es stimmen das "schlampig" implementiert wurde, 
kann das sehr schnell gehen.

schönen abend noch....

Abdul K. schrieb:
>>> Also, eine Stunde kann man damit problemlos füllen.
>>
>> Ja, aber ob sich das auch jemand anhoert, dass war meine Frage... Das
>> wird dann wieder so ein langweiliger langatmiger... Na Du weisst schon.
>
> Ich denke schon. Allein 100 wollten sich anmelden!

Lach, ja, es koennte was umsonst geben was andere nicht haben, ob man 
was damit anfangen kann oder nicht. Sammlertrieb.

Timo S. schrieb:
> --> Es ist nur noch eine Frage der Zeit bis jemand ausserhalb des
> "core-teams" den Code knackt (und auch veröffentlicht) und damit den
> "Ruhm" einheimst.

Sicher ist das "knackbar" wie man sieht, aber vielleicht braucht jemand 
von Ausserhalb nochmal 3 Jahre :o)
Wenn der/diejenige dann stolz drauf ist, auf diesen "Ruhm". Also wie 
gesagt ich verstehe die Aufregung zu dem Ganzen hier nicht. Es ist doch 
nur ein Schluessel zu einer Tuer die sowieso offen steht.

Timo S. schrieb:
> Sollte es stimmen das "schlampig" implementiert wurde, kann das sehr schnell
> gehen.

Ja wozu denn besser machen ? Die Daten sind doch nicht geheim, da haette 
auch ein ABC Schluessel ausgereicht. Hauptsache ist doch das man was 
lizensieren und damit verkaufen kann. Da kann man von schlampig kaum 
reden. Und so schlampig kann es ja nicht sein, denn wenn man mal guckt 
wie lange es gedauert hat... Wer weiss ob meteotime ueberhaupt damit 
gerechnet hat, so lange Wetterdaten senden zu duerfen / koennen.
Und wie oben schon x-Mal geschrieben wurde, was bitte will man mit 
diesem Schluessel oder gar dem fertigen Programm dann anstellen ? Man 
kann es NUR fuer sich brauchen, da kommt doch eine komplette Uhr 
billiger.

Abdul K. schrieb:
> Ich bin mit Mitglied im Core-Club und kenne daher viel mehr Details.
> Werde aber keine verraten. Es wurde wirklich unglaublich geschlampt.

Darauf hatte ich mich bezogen mit "schlampig".

Falk O. schrieb:
> --- ZITAT ---
>
> 001000101001001110111000011110100001010111111010100110001001001110101001 
1010011110
>
> Crypt: 0x62728717EA
> Key: "WFrey"
> Plain: 0x123456
>
> --- ZITAT ENDE ---

Ist die obige Bitfolge ein gültiger Wetterdatensatz?

Ja ist es.

Gruß
Thomas

Thomas Berends schrieb:
> Ja ist es.

Also (fast) auschließlich "security through obscurity"! Das ist sehr 
traurig und gleichzeitig unglaublich frech.

Fragezeichen schrieb im Beitrag #2240425:
> Abdul K. schrieb:
>> Wie landet dann die Info beim gemeinen Benutzer?
>
> Durch lesen natürlich. Wie sonst?

Dann ist eine festdefinierte IP vorhanden und aus ist es mit Tor.

Jungs, macht Euch mal locker.

Also, der Algorithmus wurde herausgefunden. Dass hier nicht alle Details 
veröffentlicht werden dient zum größten Teil dem Zweck (wie schon einige 
Male genannt), daß das Geschäftsmodel von Meteotime nicht angegriffen 
werden soll. Die hatten ne lustige Idee, ich will sie denen nicht kaputt 
machen (die rechtliche Seite mal ganz ausser 8 gelassen) Es ging einfach 
darum herauszufinden, wie die Daten verschlüsselt werden.

Was wollt Ihr denn mit dem vollständigen Algorithmus ? Die meißten hier 
haben ja anscheinend noch nicht einmal eine Wetterstation geschweige 
denn sich mit dem System näher befasst. Da finde ich es doch sehr 
vermessen hier nach Beweisen und vollständiger Offenlegung des Codes zu 
fragen. Alles was man dazu braucht wurde hier bereits öffentlich 
diskutiert.

Wenn das "Core Team" seine einzelnen Schritte nicht im Detail 
veröffentlichen will dann hat das auch damit zu tun (und damit spreche 
ich jetzt einfach mal nur für mich) dass, wie bereits ein paar Beiträge 
vorher erwähnt, manch einer meint, er bekomme hier alles für Lau. 
Mitlesen reicht, ein bisschen warten - die anderen werden es schon 
richten...

Wenn einer das ganze nachvollziehen will stehe ich gerne mit Rat zu 
Seite.

Was wollt Ihr denn noch für Details ? Es wurde doch schon alles genannt. 
Welche Relevanz haben denn bitte für Euch die SBoxen oder die 
Key-Kompressionsvorschift ? Das Prinzip bleibt das Gleiche.

Und ja: ich sitze im stillen Kämmerlein und freue mich und bin verdammt 
stolz, das ich das geschaft habe. Und das reicht mir.
Und nein: ich bekomme nichts dafür - und ich will auch nichts dafür. Das 
es einfach mal nicht um Profit geht scheinen einige nicht zu begreifen.

Meteotime wird das Ganze vielleicht intern interessieren - z.B. das 
nächste Mal, besonders im Hinblick auf Meteotime2 einen Secure 
Controller verwenden. BTW: Ich mag den PIC (weil er so leicht zu knacken 
ist) - nein, im Ernst, für kleine Steueraufgaben ist der Prima. Aber 
Secure...

Deren Verfahren ist patentrechtlich geschützt, DCF77 ist hautsächlich in 
Deutschland empfangbar, die Wetterprognosen beziehen sich eh nur auf 
Zentraleuropa. Also was soll passieren ? Wer von Euch stellt denn bitte 
Wetterstationen her ? Der Verkauf in Europa wäre (quasi) nicht möglich, 
da illegal. Und dass der Kinees her geht, das Teil nachbaut (oben hatte 
schon jemand erwähnt: Chip auslesen für < 1K Dollar, hätte er also schon 
längst machen können) - und dann hier verkauft (über ibei oder wie ???) 
- ich kann's mir echt nicht vorstellen.

Ich kann mir daher nicht vorstellen, dass die M-Jungs deswegen 
schlechter schlafen. Der ganze "Security by obscurity"-Krams ist halt 
nicht der Knaller (s.Kerkhoffs) - das zeigt sich immer wieder.

Leider gehen hier die Diskussionen stark in die Richtung "ich will den 
kompletten Code" "ich will Beweise" etc. anstelle mal das Prinzip, das 
wir ja nun herausgefunden haben zu diskutieren:

- DES-40 wird mit bekanntem Einmal-Schlüsseln (von dem her in gewisser 
Weise "One-Time-Pad") aber geheimen Parametern angewendet. Ist das 
geschickt ?
- Ist das sicherer als der "normale" Betrieb ? (PS: ich gehe davon aus, 
dass die SBoxen etc. unter Berücksichtigung der Designregeln auf 40 Bit 
angepasst wurden).
- Wie stark ist DES mit 40 Bit anstelle von 56 Bit ?

Ausserdem: wenn die Analyse nicht erfolgreich gewesen wäre und wir uns 
hier nur wichtig machen wollen, woher kommt dann der oben genannte 
Datensatz ? Schaut doch mal auf den Key und den Plain (macht beides 
keinen Sinn im Meteotime Kontext und doch decodiert es der 
Chip...(einizige andere Möglichkeit, die ich hier sehe: ich bin 
Meteotime - nein, eher nicht, ich kenne mich).

Also Ihr Volk der Dichter und Denker (oder was davon übrig geblieben 
ist): Gedichtet wurde hier ja schon so einiges, vielleicht gehen wir mal 
zum Denken über.

Walter.

Walter Freywald schrieb:
> Also Ihr Volk der Dichter und Denker (oder was davon übrig geblieben
> ist): Gedichtet wurde hier ja schon so einiges, vielleicht gehen wir mal
> zum Denken über.

Super.

Darf ich den Spruch bei Gelegenheit mal in anderen Foren nutzen ? :o)

Fragezeichen schrieb im Beitrag #2240492:
> Abdul K. schrieb:
>> Dann ist eine festdefinierte IP vorhanden und aus ist es mit Tor.
>
> Es geht ja auch nur darum den Veröffentlicher zu schützen, nicht den
> Leser. Die IP des Lesers ist zur Ermittlung des Posters kaum zu
> gebrauchen...

Schon wahr. Nur ist es dasselbe wie illegal Musik downzuloaden. Da gibts 
auch viele die zahlten...


Aber klärt mich mal auf, was "Kerkhoffs" ist? Der Begriff fiel schon 
mehrmals.

Abdul K. schrieb:
> Schon wahr. Nur ist es dasselbe wie illegal Musik downzuloaden. Da gibts
> auch viele die zahlten...

Wieso denn das ? Man kann doch Musik downloaden so viel man will, Radio 
z.B. Yotta-Byte weise. Nur verteilen oder anbieten darf man sie nicht 
und das ist der Haken z. B. bei den P2P Netzwerken.
Man kann sich z.B. auf Youtube die Videos saugen und dann die Musik vom 
Video trennen. Voellig legal. Wohl gemerkt, NUR fuer den Eingengebrauch.

Aber lasst uns doch damit aufhoeren das Forum vollzumuellen. Es wird 
nichts hochgeladen und gut.

@Dieter:
es wurden (und werden noch) 2 Wege beschritten (alles, soweit ich weiß, 
ich will nicht ausschließen, dass andere Leute noch anders arbeiten):
1) Analyse ausschließlich basierend auf den RAM Dumps. So habe ich 
gearbeitet, von 2 weiteren Leuten weiß ich, dass sie ebenfalls nach 
diesem Konzept vorgehen.
2) Flash Inhalt rekonstruiere: ein weiß von einem, der diesen Weg 
beschreitet.

Die Grundlage für beide Methoden ist aber eine, sagen wir "Eigenschaft" 
des PIC, nämlich der "RAM Monitor". Soweit ich weiß haben wir alle 
unseren eigenen geschrieben, das Prinzip ist aber das gleiche. Nach 
Methode 1 wird der Code eingeschoben und eine Zeit Td gewartet, dann 
wird der Controller angehalten und der RAM Inhalt ausgegeben. Der 
Controller wird dann neu gestartet und Td um ca. 1us verlängert. Nach 
ca. 8000 Schritten ist der DES einmal durchgelaufen. Bei der 2.Methode 
werden geziehlt Adressen von 0 bis Ende angesprungen, der Controller 
eine kurze Zeit laufen gelassen (um einen Befehl auszuführen), dann 
wieder angehalten und auch der RAM Inhalt ausgelesen. An Hand des 
Ergebnisses wird auf den Befehl geschlossen (dieser Ansatz stammt nicht 
von mir, ich will mich hier nicht mit fremden Federn schmücken).

Beide Weg sind sehr mühsam und es steckt viel Arbeit dahinter.

zum DES:
mit "normaler Weg" meine ich: nur der Schlüssel ist geheim. Alles andere 
ist bekannt (und kann daher als sicher angesehen werden, da vermutlich 
ein Haufen Krypto-Fachleute drüber geschaut haben und der DES ja an sich 
sicher ist (der Schlüssel ist halt mittlerweise zu kurz).

Richtig ist natürlich, dass, wenn man dieses System von Meteotime nicht 
kennt und nur Input und Output hat man auch nicht weiß, dass es sich um 
den DES handelt, woher der Schlüssel kommt etc.
Im nachhinein wäre aber eine Analyse interessant, wie sicher dieses 
System ist.

Und 40 Bit ist in der heutigen Zeit sich sehr wenig, aber die beiden 
großen "Schlüsselberechnungen" von ender der 90er Jahre (Deep Crack mit 
88 Illiarden Keys/Sekunde) und ich glaube von 2006 (Copacabana, ca. 65 
Milliarden Keys/Sekunde) wurden von Spezialmaschienen durchgeführt, 
nicht mit einem "home PC" zu vergleichen. Ich denke, es muß immer noch 
einiges aufgefahren werden - sooo einfach hebt man den DES dann doch 
nicht aus. Und gebrochen wurde der DES ja wohl bisher noch nicht (ich 
lasse mich aber sehr gerne eines besseren belehren)

Walter

Kurz eine Antowrt an Sven P. geben, besonders, was die "kostenlosen 
Freelancer" angeht:

Zähl mal mit, wieviele Leute ich im vorhergehenden Beitrag genannt habe. 
Dann schau Dir bitte mal diesen Thread und den Thread über die "Hidden 
Features des PIC" an und lies bitte nach, wer hier welche Ideen 
eingebracht hat und wer welche Methoden aufgedeckt hat (undoc. ICSP CMD, 
RAM Monitor, RAM Dumps etc.)...ja, das ist jetzt alles ein bisschen 
häßlich, zugegeben. Aber ich habe wirklich verdammt viel Arbeit hier 
reingesteckt. Da möchte ich mir wirklich nicht unterstellen lassen, von 
der Arbeit anderer profitiert zu haben und nun die Sahne für behalten zu 
wollen.

Wenn Du einmal abschätzt, wie viele Leute hier "mitreden" und viele 
Leute dann wirklich mal Arbeit reinstecken. Ich weiß es wie gesagt nur 
von ein paar Leuten (s.oben), Thomas nicht zu vergessen, der eine riesen 
Arbeit auf der PC Seite geleistet hat.

Zugegeben, die ursprüngeliche Idee des RAM Monitor stammte von Chris aus 
dem allerersten Thread. Da kam aber leider nichts mehr. Seine Idee war, 
den RAM Monitor in den ersten 64 Befehlen unterzubringen. Hat aber 
soweit ich weiß, nie jemand geschafft (auch wenn Chris das behauptet 
hat). Ich immer noch nicht sagen, ob dieser Code dort überhaupt jemals 
ausgeführt wird (sicher nicht während der 41 * 16 Runden, das kann ich 
bestätigen (s.RAM-Dumps).

Anton Wert schrieb:
> Und zum
> Schutz wird hier im Forum behauptet, dass es geschafft wurde. Es ist
> natürlich klar das niemand den Code gesehen hat.

Und an alle anderen, die das Anzweifeln:

Erklärt doch bitte mal das oben genannte Telegramm. Ich bin gespannt !

Walter.

@Sven P.

es ist letzendlich alles veröffentlicht. Der DES ist der DES, den Code 
findet man vielfach im Netz.
Dieser hier ist eben nur auf 40 angepasst (nicht nur der Schlüssel 
sondern konsequent der ganze Algorithmus), das ist alles. Da müssen 
natürlich die internen Vorschriften wie z.B. die S-Boxen (5 statt 8) 
angepasst werden. Ansonsten ist alles identisch.

Ich habe keinen Code aus dem Controller ausgelesen sondern alles über 
die RAM-Dumps rekonstruiert. Dabei habe ich anfangs nicht gewußt, dass 
es sich um den DES handelt. Das habe ich erst am Schluß festgestellt. Es 
hat sich sehr schnell gezeigt, dass es sich um eine Feistelchiffre 
handelt, wegen der XOR Verknüpfung und der anschließenden Vertauschung 
der Seiten. Allein schon die Infos, dass es sich um einen DES handelt 
und der Schlüssel öffentlich ist sind schon wichtige Punkte.

Wozu braucht hier denn jemand eine vollständige SW ? Um es 
nachzuvollziehen - prima, das kann ich verstehen. Und sonst ? Wichtig 
ist doch das Prinzip. Das wollte ich von Anfang an heraus finden - und 
das habe ich hier auch veröffentlicht. Und mal ganz ehrlich: Alle 
Werkzeuge und das Vorgehen sind hier beschrieben. Die SBoxen sind 
wirklich leicht zu finden, Kompression, Expansion und P-Box sind ein 
bisschen fummelig - aber machbar.

Ob mir das jetzt jemand glaubt oder nicht....das muß jeder selber wissen 
(vielleicht haben sie mich ja wirklich unter Druck gesetzt oder 
gekauft....wie im Fernsehen ;-)

Noch was zur Wahrscheinlichkeit: Johannes O. hat recht, wenn er sagt 
durch Variation von 12 Bit wurden schon ein paar Datensätze "erraten". 
Nur habe ich komplette 80 Bit frei gewähl: 40 Bit Plain (22 Bit 
Wetterdaten + 16 Bit Kennung +2 Bit 0) + 40 Bit Schlüssel - also mit 
Erraten schaut's da eher finster aus ;-)

Walter.