Ich starte hier mal einen Crypt-Thread. Im Meteotime-Thread wird es
mittlerweile zu unübersichtlich.
Um es gleich vorweg zu sagen:
Es geht hier um eine exemplarische Untersuchung eines unbekannten Crypt
am Beispiel des Meteotime Algorithmus.
Es wurde dieser Algorithmus gewählt das er anscheinend mit wenig
Resourcen auskommt und einigermassen sicher zu sein scheint.
Die ganze Untersuchung dient Lernzwecken. Soweit bekannt besteht ein
Patentschutz auf das Meteotime Verfahren. Selbst wenn die Daten nicht
verschlüsselt wären dürfte demnach kein Gerät gebaut und vertrieben
werden, dass den Empfang und die Darstellung dieser Daten ermöglicht.
Zum Thema:
Im Bereich 0x00-0x06 liegen die Funktionsregister des Controllers
(Timer, Program Counter etc.) Der Stack ist in Hardware implementiert
und nicht im RAM dargestellt. Der RAM Bereich geht somit von 0x07-0x3F.
Dabei ist der Bereich von 0x20-0x2F eine Spiegelung von 0x00-0x1F.
Der Controller verwendet RAM Banking da zur Adressierung nur 5 Bit zur
Verfügung stehen.
Es gibt also
Bank0: 0x00-0x1F
Bank1: 0x20-0x3F
Nach Abzug von ConfigRegistern und Spiegelbereich bleiben also 41 Byte
übrig.
Es gibt inzwischen kontiniuerliche RAM-Dumps (zumindest von den ersten
Millisekunden) dank der "erweiterten Funktionalität" des verwedeten
Mikrocontrollers.
Der Ablauf sieht etwa so aus:
80 Bit (40 Bit Crypt und 40 Bit Zeitstempel) werden eingelesen (10 Byte)
Diese liegen an den Adressen 0x36-0x3F (Crypt: 0x3B-0x3F, Time:
0x36-0x3A)
Im nächsten Schritt werden die Daten nach 0x16-0x1F umkompiert.
Anscheinend ändern sich die Daten von 0x30-0x3F danach erstmal nicht
mehr. Es wird hauptsächlich im Bereich 0x07-0x1E gearbeitet.
Am Ende, nach ca. 270ms fallen 22 Nutzbits mit der Wetterinformation und
2 Statusbits heraus. Die Statusbits kennzeichnen anscheinend folgende
Zustände:
00: Fehler in den Daten
10: alles ok
11: Daten wurden korregiert
Es schein Controller zu geben, die einen Bitfehler in den Bits 0-39
(Crypt) korregieren können.
Nun werden gibt es mindestens 1 Rückgekoppeltes Schieberegister (5 Byte)
ab Adresse 0x12
Die Adressen 0x10 und 0x11 werden immer wieder als Zähler verwendet.
Soweit zum Start.
Walter.
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.
Zur Info:
Der von Walter verwendete Datensatz 2006'0413Do:1205 ist der von der
Mebus-Station von "noch einer" verwendete Datensatz im Testmodus:
Autor: noch einer (Gast) Datum: 09.09.2007 18:31
Beitrag "Re: AVR: Wetterinformationen über DCF77"
x 6 x 0 8 8 a 6 0 a 8 3 8 0 0 2 1 2 1 a 1 1 0 0 0 0 0 4
Können wir uns darauf einigen, als Datensatz den 2011'0121:2008 zu
verwenden?
Er ist markant, da er nur 22 gesetzte Bits hat und das 3xNull-Ergebnis
liefert.
Der Code an den Adressen 12-2E um das Ram-Byte 1C berechnet das
zurückgekoppelte Bit:
es ist die gerade Parität der zu einem Byte zusammengexorten 14 Bits.
Hat ein wenig gedauert, bis ich am 08.05.2011 den Code verstanden hatte.
Walter:
meines Erachtens bringt es mehr, Wort für Wort auf den Code zu
schließen:
Successive die Adressen anspringen und nach einem Cycle wieder anhalten,
schauen was sich im RAM geändert hat und damit auf den Befehl der
ausgeführt wurde, schließen.
Ewig lange Delays mögen interessant sein, den Algorythmus zu verstehen,
das ist aber eine andere Aufgabe als den Flash-Inhalt zu erkunden.
Den Code verstehen können wir, wenn wir eine Memory-Map haben.
Welchen µC verwendest Du, um den DCIC anzusteuern? Wie ich Dich kenne,
auch ein PIC ;-) Bei mir: atMega32 @ 16 MHz leider mit Software-SPI, da
die Hardware-SPI nur (Vielfache von) 8 Bits versenden kann.
eProfi schrieb:> Der Code an den Adressen 12-2E um das Ram-Byte 1C berechnet das> zurückgekoppelte Bit:> es ist die gerade Parität der zu einem Byte zusammengexorten 14 Bits.> Hat ein wenig gedauert, bis ich am 08.05.2011 den Code verstanden hatte.
Kannst du das mal näher erläutern. Ich kann dir hier nicht ganz folgen.
Von welchem Code sprichst du und welche 14 Bit werden wie
"zusammengexort" ?
Gruß
uzi
Ich denke er meint die folgende Datei:
http://www.mikrocontroller.net/attachment/42711/Meteo1.asm
Gestern und heute habe ich mir die RAM-Dumps sehr genau angesehen.
Ich finde darin eine Art doppelte Schleife die außen von 16 bis 0(?)
läuft und innendrin glaub ich von 5 bis 0. Was da drinnen passiert ist
nur teils zu erkennen. SHIFT lässt sich leicht finden, genauso die
Steuerung der Schleife (Zählvariable decrementieren und ähnliches). Auch
das umherkopieren von Daten im Speicher sieht man gut.
Ein Problem sind aber die Spielereien wo einzelne Bits gesetzt/gelöscht
werden. Wenn z.B. 0x61 zu 0x60 wird, dann sinds viele Möglichkeiten was
es sein könnte: DEC, AND 0xF0, AND 0xF2, AND 0x64, oder auch ein AND mit
einer anderen Speicherzelle oder ein XOR mit einer anderen Speicherzelle
usw.
Wenn man sich den oberen Assemblercode ansieht, dann sieht man, dass
nahezu alle diese Möglichkeiten in Betracht kommen müssen.
Wenn diese Stelle mehrmals durchlaufen wird kann man einige Sachen meist
ausschließen.
Naja man kommt ja dem Ziel schon näher ;-)
Wenn es klappt verschiedene Programmstellen gezielt anzuspringen bzw.
einzelne Befehle/Abstände findet, dann kann man nochmal mehr
ausschließen.
Mich würds auch wundern, wenn der µC wirklich die ganzen 250ms
durchrechnet, denn bei DIESEM Code, den er ausführt, wäre das insgesamt
wirklich sehr aufwendig. Evtl. läuft ja mehrmals das gleiche durch oder
so. Gibts schon erkenntnisse darüber wieviel voll ist von dem PIC?
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?
mit den 16 und den 5, meinte ich die Zählvariablen der Schleife die
runtergezählt werden.
Der PIC braucht so 800ns für einen befehl, das wären dann ca. 300.000
befehle in den 250 ms.
Damit könnte man jedes des 80 Bits viele hundert male mit irgendwas
verknüpfen. Evtl. wäre ein speicherdump mit ein paar zwischenständen
interessant. da schleifen lange dauern und die zählvariablen meist in
0x10 und 0x11 liegen könnte man diese schleifen leicht finden. evtl.
kann man dann auch die art der verschlüsselung bestimmen, sofern es
keine eigenbastelei ist.
Was könnte das eigentlich im bereich 0x00 bis ca. 0x0F sein? sind das
interne sachen oder programmram? könnte das eine art schlüssel oder so
sein?
@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
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).
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.
Abdul K. schrieb:>Was wir haben sind endlos viele> verschlüsselt und passend unverschlüsselte relativ kurze Datenpakete.
Try to google for forensic methods. Google offers much information about
this.
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
Ich verfolge das hier am Rande so mit, da ich es recht interessant
finde.
Mein Vorschlag:
Aus den RAM-Dumps mal eine Animation erstellen, also ein kleines PC
Programm schreiben, welches die Dumps einliest und Binär darstellt,
eines nach dem anderen wie in einem Film. ggf. mit wählbarer Aufteilung
der verschiedenen Bytes.
Durch die Binäre Animation würde man ggf. Schieberegister und eventuelle
Rückkopplungen recht gut erkennen können, wahrscheinlich viel besser als
im Hexcode.
Falls das schon probiert wurde, habe ich das in der Länge des Threads
wohl übersehen.
Ansonsten:
Viel Glück!
Ich bin gerade dabei Walter's RAM_dump zu analysieren und zu
kommentieren.
Parallel dazu versuche ich ein C-Programm zu schreiben, das die Daten
genauso verarbeitet. Es gibt viele Bereiche, bei denen ziemlich klar
ist, wie die Daten im RAM aufbereitet werden(kopieren, Shift,AND, etc).
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.
Vielleicht hat der eine oder andere ja noch ein paar gute Ideen
hierzu...
@Walter
kannst du noch weitere Fortsetzungen des RAM-Dumps liefern um den Algo
weiter zu entschlüsseln ?
Gruß uzi
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
Ulrich:
> 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.
Du musst einfach nochmal alles durchlesen und verstehen.
Ich meint wohl, da werden nur ein Paar Bits verdreht oder so.
Wir analysieren die Daten schon seit geraumer Zeit und haben nur eine
vage Vorstellung davon, wie aus den 80 Bits die 22 entstehen.
Bin gerade dabei, den Stromverbrauch zu analysieren.
Was man klar sieht, ist der Ruhestromverbrauch von 0,2mA und Spikes von
unterschiedlicher Höhe (1,7 - 8,0 mA) mit 4MHz. Das Spikemuster ist sehr
unterschiedlich für verschiedene Befehle, aber die einzelnen Höhen
hängen von vielen Faktoren ab, z.B. wieviele Adress- und Datenleitungen
ihren Pegel ändern.
Der Peak von Q2 nach Q3 (siehe Figure 3.3 auf S. 16/98 im DS41236B) ist
mit 1,7 - 2,2 mA immer am niedrigsten.
Was auf jeden Fall klappt: den Takt aus dem Stromverbrauch abzuleiten,
d.h die Taktzyklen mitzuzählen, damit man weiß, wo man ist.
Hihi, meine 8 Stationen sind da! Muss gleich mal den Schraubenzieher
zücken und den Löti anheizen.
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.
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
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.
abdul: nein es gibt durchaus daten mit dem selben zeitstempel! dachte
ich zuerst auch nicht... hatte mehr dazu im alten Thread geschrieben:
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.
Frank: nein so kann man das nicht betrachten. die zeit ist festgelegt
und kann nicht gewählt werden. das mindert die Anzahl erheblich, dennoch
ist sie noch sehr groß.
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?
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).
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.
Man sieht den Kopiervorgang nach dem Reinschieben auch recht schön.
Es wird wirklich die ganze Zeit (ca. 275 ms) gerechnet.
Walter, hast Du schonmal herausbekommen, ob der sichtbare Code
ausgeführt wird?
Noch was ist mir aufgefallen:
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:>
> 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
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?) ;-)
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.
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.
Zuerst mal meine Anerkennung für die bisher geleistete Arbeit,
finde ich echt prima.
Wenn ich das richtig verfolgt habe ist das "Verfahren" patentiert.
Dazu müssen mindestens die Ansprüche beschrieben sein, läßt sich denn
da gar nichts herauslesen? Sicherlich steht der Code nicht im Patent,
gleichfalls glaube ich nicht daß die Verschlüsselung so geheim ist,
daß sie niht veröffentlicht werden darf.
Bitte einfach mal als Denkanstoß betrachten und nicht gleich
niedermachen,
(von den "Aktiven" erwarte ich das sowieso nicht)
Gibt es einen Link auf das Patent?
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.).
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 mir das 1C-Problem auch mal angesehen und komme zu dem
Ergebnis,
dass die Einzelnen Bit-Stellen von 1C keine direkte Kopie eines Bits aus
irgend einer anderen Bitstelle des datzugehörigen RAM-Dumps sind.
Wie Walter schon vermutet hat baut es sich wohl aus SUB/ADD/XOR und
ähnlichem zusammen.
Zusätzlich kommen aber wohl noch einzelne Bits aus unterschiedlichen
Adressen hinzu, denn sonst könnte man das Ergebnis aus ADD/SUB/XOR etc
direkt komplett nach 1C schreiben, es wird aber immer nur ein Einzelnes
Bit draufge-oder-t. Vermutlich wird für jede Bitposition von 1C ein
Rechenvorgang Ausgeführt der als Ergebnis 1 Bit hat, welches dann auf 1C
ge-oder-t wird.
Allerdings könnte das 1C-Bit 2^0 direkt von Adresse $0B Bit 2^0 stammen.
Hier habe ich eine Übereinstimmung gefunden, allerdings ist die
Stichprobe mit 7 Dumps aus "making_of_1C.txt" wohl etwas zu gering um
absolute Gewissheit zu haben.
Sehe ich das richtig, dass für die Berechnung der Werte die z.B. nach
$12
ge-oder-t werden jeweils nur 1-2 Takte benötigt werden?
Dann kann es sich doch eigentlich nur um eine Folge aus BTFSC-Befehlen
mit nachfolgendem IORWF-Befehl, der ggf. übersprungen wird handeln.
Oder habe ich da was übersehen ???
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 Freywald schrieb:> 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 %....)
Bezüglich des "1C-Problems" und der anderen Stellen, an denen die
einzelnen Bits nacheinander auf eine Speicherstelle drauf ge-oder-t
werden, könnten datensätze, beidenen immer nur 1 Bit gesetzt ist und in
aufeinanderfolgenden datensätzen durchgeschoben wird weiterhelfen die
Abhängigkeiten zu klären.
Soweit ich mich erinnere werden ungültige datensätze zumindest in den
ersten millisekunden gleich behandelt und nicht sofort aussortiert.
Somit sollten wir mit diesen datensätzen weiter kommen können.
@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?
Thomas Berends schrieb:> 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?
Nicht überspringen!
sondern genauer ansehen, das liefert Hinweise auf die Art der
Checksummen/Prüfbit Berechnung. Wenn wir die
Checksummen/Prüfbit-Berechnung kennen, können wir eigene GÜLTIGE Packete
zusammenbauen, um gezielt z.B. das $1C-Problem anzugehen.
Meldung aus der "Core Group":
es ist gelungen, mit Hilfe der RAM Dumps den Algorithmus zu
rekonstruieren.
Folgende Fakten:
- es handelt sich um einen DES mit 40 Bit
- Bit 0 und Bit 7 werden verworfen (wie bereits vermutet)
- es gibt keine Korrekturdaten
- ein gültiges Telegram wird an einem festen (16 ?) Bit Wert erkannt
- der PIC rechnet den Algorithmus 41 Mal durch (40 mal mit jeweils einem
Bit gekippt, einmal mit dem original Telegram).
- trotzdem (kann ?) der PIC nicht korregieren
- woher die "statistische Anomalie" der ersten 12 Bit kommt ist noch
nicht klar (in den ersten 4 Bit liegen Wetter Daten, dann folgen 16 Bit
feste Daten, dann wieder Wetterdaten)
- ob die ersten 64 Befehle des PIC (die bereits ausgelesen wurden)
ausgeführt werden ist nicht klar, benötigt werden sie aber nicht
Decrypt und Encrypt ohne Chip ist möglich (die Algorithmen wurden für
den PC nachprogrammiert (werden aber unter keinen Umständen
veröffentlicht !)
Offen ist jetzt vor allem die Frage, wie hoch die Sicherheit des
gesammten Systems ist, wenn nun zwar der Algorithmus und der Schlüssel
bekannt sind, SBoxen, P-Box, Kompressions- und Expansionsmethoden aber
geheim bleiben.
Proof of concept:
--- ZITAT ---
001000101001001110111000011110100001010111111010100110001001001110101001
1010011110
Crypt: 0x62728717EA
Key: "WFrey"
Plain: 0x123456
--- ZITAT ENDE ---
Firma Meteotime schrieb:> Archimedes schrieb:>> Heureka !!!>> Wohl kaum.
Aber jetzt !
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...
Gratulation. Auch wenn die Ergebnisse jetzt nicht veröffentlicht werden,
wäre es toll den gesamten Werdegang, jedoch ohne endgültige auflösung
der Verschlüsselung, hier als Artikel rein zu stellen. Dabei kann man
sicher legal bleiben. Wir wolen Meteotime ja nicht schaden ;-)
>Offen ist jetzt vor allem die Frage, wie hoch die Sicherheit des>gesammten Systems ist, wenn nun zwar der Algorithmus und der Schlüssel>bekannt sind, SBoxen, P-Box, Kompressions- und Expansionsmethoden aber>geheim bleiben.
Die S-boxen bei DES sind im Original so modifiziert worden, dass sie
heute bekannten statistischen Angriffsversuchen widerstehen. Sie mit
anderen Inhalt zu füllen, kann die Sicherheit also massgeblich
beeinträchtigen. Solange der komplette Inhalt der Sboxen geheim ist,
sind es auch die Daten.
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.
Johannes O. schrieb:> 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.
Ohne deine edlen Motive in Frage stellen zu wollen:
Ihr Leute von der 'Core Group' habt also mit viel Sachverstand und
Geduld den Code gebrochen. Und nun sitzt da irgendwo ein Oberguru und
freut sich ganz allein in seinem Kämmerlein, den Algorithmus zu kennen?
Oder wie ist das zu verstehen?
Hast du mal 'Stirb langsam 4' gesehen, also der mit dem Firesale?
Billiger kommt man eigentlich nicht an qualifizierte Entwickler :-)
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.
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.
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.
Johannes O. schrieb:> 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.
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). Wie viele Leute haben wie viele
Stunden gebraucht um den Algorithmus zu knacken ? Wenn man hier die
üblichen Stundensätze nehmen würde dürfte es wahrscheinlich teurer
sein. Für jemanden der damit Profit machen möchte ist der Aufwand
also kalkulierbar. Da die Wetterdaten aber nur in sehr wenigen Ländern
genutzt werden können ist es relativ einfach rechtlich gegen unerlaubte,
kommerzielle Nutzung vorzugehen also sollte das sowieso kein Thema
sein.
Unabhängig davon, ihr solltet darüber nachdenken zumindest den Weg
wie ihr vorgegangen seit zu dokumentieren, vielleicht auch in
Form eines Vortrags (z.B. auf den diversen CCC Veranstaltungen).
Das Ganze ist bestimmt auch für andere interessant, hier in dem
Thread ist es nicht unbedingt einfach nachvollziehbar.
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...
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!
Diese Aussage ist etwas pauschal: Für welche Projekte ist er nicht
sicher ? Welche Art von Code/Algorithmus soll damit geschützt werden ?
Welcher Schaden entsteht wenn der Code/Algorithmus bekannt ist ?
So gesehen ist keiner der "normalen" Mikrocontroller sicher, die
Kosten fürs Auslesen des Flash/ROM liegt für Bausteine ohne besondere
Sicherungsmassnahmen in der selben Größenordnung. Besser wird es dann
bei speziellen "Security"-Controllern wie sie z.B. bei SmartCards
verwendet werden. Aber auch hier ist ein Auslesen möglich, der
Aufwand/Kosten dafür ist halt höher.
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
Wenn der Algorithmus bekannt ist, wenigstens dem der ihn gehackt hat
kann derjenige alleine entscheiden, ob er den Veröffentlicht oder nicht.
Ich bin kein Jurist, denn ein solcher würde sicher die Frage beantworten
können, ob die Veröffentlichung des gehackten Algorithmus das
Urheberrecht
verletzt oder nicht, ebenso ob das Hacken des selben Strafbar ist oder
nicht, oder ob es hier eine schöpferische Tätigkeit geht, und der Hacker
das Urheberrecht an seiner Version hat.
Solange keine Rechtssicherheit herrscht verstehe ich daß nicht
veröffentlicht wird.
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).
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.
Carsten Sch. schrieb:> 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.
Danke fürs Update der Kosten, ich ging von Zahlen von vor ein paar
Jahren aus. Sogesehen sind das ja schon Preise wo man gar nicht mehr
überlegen sollte ob man sich wirklich ein paar Tage hinsetzt um
herauszufinden was ein Chip macht ;-)
> Allerdings wird es dann auch schnell noch teurer bis hin zu unmöglich> bei ganz aktuellen High Security Bausteinen...
Die teuren Suecurity Bausteine werden ja auch nicht so oft eingesetzt,
sie sind ja oft entsprechend teur. "Unmöglich" würde ich vielleich in
"zur Zeit unmöglich" umformulieren.
> 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:> 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?
Anders sieht es mit dem Knacken eines "geschützten Werks" aus, das
dürfte unter §108b UrhG fallen.
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
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 eigenerPIC (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!
(Ich gehe jetzt mal davon aus der Algorithmus wurde tatsächlich
geknackt, kann stimmen oder auch nicht.)
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 "anonym" muss man in Zeiten von Vorratsdatenspeicherung und Co.
erstmal hinbekommen...
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...)
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. Das ist ein bisschen wie wenn man
schöne rote Äpfel anbaut mit dem Wissen sie niemals anfassen oder essen
zu dürfen (parallelen zur Bibel sind rein zufällig, ich halte nichts von
Religion) oder irgendwas ähnliches?
Mir stellt sich zwangsläufig folgende Frage: Warum wurde der ganze
Aufwand überhaupt betrieben? 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. Ich wundere mich schon dass die ganzen
Threads überhaupt noch leben und es nicht bereits Abmahnungen usw. gegen
Andreas und andere Personen gehagelt hat. Ging es hier vielleicht gar
nicht um das Zeigen "Es ist möglich" oder das sportliche
Auseinandersetzen mit Kryptographie und Ähnliches sondern war es
schlicht eine Person die den Algorithmus für ein privates Projekt
braucht welche mit solchen Argumenten die Community die Arbeit machen
lassen wollte? Bitte nicht falsch verstehen, ich will niemandem
irgendwas unterstellen, aber es stellt sich halt die Frage: Warum wurde
überhaupt angefangen?
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?
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.
>Was wir haben sind endlos viele>verschlüsselt und passend unverschlüsselte relativ kurze Datenpakete.
Eine Analyse der Gleichverteilung der verschlüsselten Daten kann
zumindest eine Aussage darüber machen, ob wirklich DES zum Einsatz
kommt. Dazu müssten alle verschlüsselten Pakete in eine Datei
geschrieben werden. (Am besten binär). Es dürfen nur die Pakete in die
Datei, deren zugehöriger Klartext nicht doppelt ist.
Walter Freywald schrieb:> 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:
Eine Frage zum Prinzip: habt ihr den Algorithmus komplett durch Analyse
des RAM Dump geknackt oder gab es weitere Lücken im PIC die z.B.
das Auslesen des Code ermöglichen ? Solche Dinge wären es auf jeden
Fall wert veröffentlicht zu werden, das ist auch unabhängig vom
eigentlichen Algorithmus.
> - DES-40 wird mit bekanntem Einmal-Schlüsseln (von dem her in gewisser> Weise "One-Time-Pad") aber geheimen Parametern angewendet. Ist das> geschickt ?
Welche Alternativen hat man sonst noch ? Ein statischer Key im
Controller ist ebenfalls nicht wirklich hilfreich. Da die
Wetterstation die Daten entschlüsseln muss sind alle Informationen
dazu im Controller. Man kann also nur den Aufwand fürs Auslesen
entsprechend hoch ansetzen (Secure Microcontroller), viel mehr
Möglichkeiten hat man nicht.
> - 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).
Was meinst Du mit "normaler" Betrieb ?
> - Wie stark ist DES mit 40 Bit anstelle von 56 Bit ?
Ein 40-Bit Key ist nicht sicher. Wenn man allerdings den Algorithmus
nicht kennt wird es dennoch ziemlich aufwaendig. 56-Bit DES ist
relativ problemlos zu knacken, dazu braucht es keinen grossen
Aufwand. Würde also beispielweise der Standard DES 56-Bit verwendet
und ein statischer Key so hätte man den Key auch ohne Auslesen
mit vertretbarem Aufwand finden können.
Walter Freywald schrieb:> 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.
Mich interessiert die Prognose auch herzlich wenig, Meteotime auch
nicht.
Ich hab nur hier von vielen Leuten gelesen, die Datensätze gesammelt
haben, nachgedacht haben und so weiter. Ein Mitglied des Core-Teams hat
sich geäußert, den fertigen Decoder garnicht gesehen zu haben.
Geht das den anderen Mithelfern auch so, und wussten die auch alle
vorher, als sie rangeklotzt haben, dass sie den funktionierenden Decoder
nie zu Gesicht bekommen werden?
Ich möchte dir - bitte - nichts unterstellt haben. Aber falls die es
tatsächlich nicht vorher wussten, dann hast du da eine verdammt clevere
Art gefunden, kostenlose Freelancer anzuheuern...
@Sven P.
Deine Theorie hat was, aber ich gehe in miener Vermutung noch einen
Schritt weiter, damit dass die "Core" Gruppe zwar ein Stück weit
gekommen ist, aber letztendlich wurde jedem einzelnen soviel Druck
gemacht, dass sie ganz schnell die Finger davon gelassen haben. Und zum
Schutz wird hier im Forum behauptet, dass es geschafft wurde. Es ist
natürlich klar das niemand den Code gesehen hat.
@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.
@Walter
Ich kann den Gedankenvon Meteo teilen, aber eines ist viel einfacher:
Ihr habt in euere Gruppe per Zufall einen Datensatz gefunden der korrekt
dekodiert wird.
Walter Freywald schrieb:> 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.
Das möchte ich dir auch mitnichten unterstellen, schrieb ich ja auch.
Ich bewundere, mit wie viel Fingerspitzengefühl du und das Core-Team den
Kram aufgedröselt haben, falls das so ist.
Es wirkt halt auf mich als Außenstehenden und offenbar auch auf andere
etwas sonderbar. Es wirkt auch, zugegebenermaßen, untypisch auf mich,
viel anzukündigen und zu diskutieren und dann kein Ergebnis zu
präsentieren. Mit den gleichen Einschränkungen meinerseits, ich hab
keinen Einblick in euer Tun und beschreibe nur, was ich von außen sehe.
Das mag alles durchaus falsch sein.
Walter Freywald schrieb:> Beide Weg sind sehr mühsam und es steckt viel Arbeit dahinter.
Danke für die Info, mich hat interessiert ob es eventuell eine
weitere "Hintertür" im PIC gab. Den Algorithmus alleine per
RAM-Dump zu analysieren ist sicher eine mühsame Arbeit und eine
respektable Leistung wenn man es nur damit schafft.
> 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).
Ihr erwähnt "DES" im Zusammenhang mit 40-Bit: Meines Wissens gab es
eine 40-Bit Export-Version von DES, diese basiert aber auf dem
"normalen" 56-Bit DES, es sind lediglich 16 Bit des Keys auf einem
festen Wert.
So wie ich eure Beschreibung verstehe hat der Algorithmus von Meteotime
nicht mehr viel mit DES zu tun weil wohl u.A. die S-Boxen anderst
aussehen, er gehört zwar zur selben Klasse (Feistel-Netzwerk) aber ist
eben nicht mehr DES. Hier wäre es interessant zu untersuchen ob der
Algorithmus komplett neu ist oder vielleicht ein weniger bekannter
Algorithmus als z.B. DES ist.
> 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.
Wenn ihr eine Analyse wollt müsst ihr wohl den Algorithmus
veröffentlichen oder einen Experten finden der es interessant
genug findet Zeit in die Analyse zu stecken ohne am Ende
weitere Details veröffentlichen zu können.
> 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)
Ein Beispiel wie es mit relativ wenig Aufwand gelingt 56-Bit DES
zu knacken:
http://events.ccc.de/congress/2010/Fahrplan/events/4203.en.html
OK, am Ende sind es ähnliche Kosten als wenn man gleich den
Chip auslesen laesst (wenn man nur die Hardware ohne Arbeitszeit
rechnet). Dafür hat man dann aber Hardware die man auch noch für
diverses andere nutzen kann.
@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.
Ich stimme Paolo Luca zu, wenn es wirklich "nichts besonderes" ist,
spricht alles für die Veröffentlichung. Und nur mit einer
Veröffentlichung erntet die "Core"-Gruppe den Ruhm den sie momentan
meinen zu besitzen.
Es gibt genügend Mittel und Wege (eineige wurden schon erwähnt) wie der
Code veröffentlicht werden kann, ohne dass jemand hier entwas zu
befürchten hätte.
Sven P. schrieb:> Walter Freywald schrieb:>> 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.>> Mich interessiert die Prognose auch herzlich wenig, Meteotime auch> nicht.> Ich hab nur hier von vielen Leuten gelesen, die Datensätze gesammelt> haben, nachgedacht haben und so weiter. Ein Mitglied des Core-Teams hat> sich geäußert, den fertigen Decoder garnicht gesehen zu haben.>
Zumindest ich habe den fertigen Code nicht gesehen (also alles komplett
drinnen).
> Geht das den anderen Mithelfern auch so, und wussten die auch alle> vorher, als sie rangeklotzt haben, dass sie den funktionierenden Decoder> nie zu Gesicht bekommen werden?
A bisserl stößt mir das ja auch auf. Wir haben Infos reingeschoben und
bekommen nichts wirklich zurück.
Andererseits habe ich nicht nächtelang drangesessen. Ehre wem Ehre
gebürt.
>> Ich möchte dir - bitte - nichts unterstellt haben. Aber falls die es> tatsächlich nicht vorher wussten, dann hast du da eine verdammt clevere> Art gefunden, kostenlose Freelancer anzuheuern...
Da muß ich dir leider zustimmen. Mich tröstet aber, daß ich mein Wissen
nicht mit ins Grab nehme und ich auch keine wirkliche Verwendung für die
Wetterdaten, das Übertragungsformat oder die PIC-Sicherheit habe. So no
Prob. Man weiß aber nie, was noch kommen wird.
Warum schreibt von den ganzen "Kritikern" niemand als angemeldeter
Benutzer? Alles nur Namen die man kaum bis überhaupt nicht sonst im
Forum kennt...
Und nein: Gekauft wurde von Meteotime keiner von uns, es gab auch gar
keine Kontaktaufnahme.
Am sinnvollsten wärs, wenn Thomy nen Encoder online stellt, wo jeder der
Zweifler z.B. einmal pro Stunde einen Datensatz VERschlüsseln lassen
kann. Wer eine solche Uhr hat kanns hernach ja einfach nachprüfen obs
passt.
Denn wie es bei DES so ist: Wenn man Entschlüsseln kann, ist das
Verschlüsseln auch relativ einfach möglich. (das gilt auch andersrum).
Damit wärs wohl möglich die Zweifler zu überzeugen, oder?
Walter Freywald schrieb:> 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 ;-)>
Am Schluß finde ich bei MeteoTime zwei Dinge sehr interessant:
- Das die aktuelle Uhrzeit/Datum als kaum angreifbarer Schlüssel
verwendet werden kann.
- Durch Einfügen einer festen (von dir so genannten) 'Kennung' eine
Fehlerkorrektur innerhalb des Entschlüsselungsalgorithmus durchgeführt
werden kann. Bislang konnte ich mir eine Fehlerkorrektur NACH
Entschlüsselung nur theoretisch vorstellen. Mein Kenntnisstand war
vorher, daß Fehlerkorrektur praktisch immer nur VOR der Entschlüsselung
möglich ist. Hier wurde bewiesen, es geht auch anders! Wenngleich der
Weg dann sehr kurios ist: Ich weiß nicht ob das schon genau beschrieben
wurde und ob dies gewünscht ist, daher lasse ich es.
Paolo Luca schrieb im Beitrag #2240899:
> Diese> "Ich-sitzte-hier-und-geile-mich-daran-auf-etwas-zu-haben-was-alle-wollen
-ich-ihnen-aber-nicht-gebe"
> Mentalität scheint irgendwie typisch deutsch zu sein.
Noe, typisch Deutsch ist das was DU machst. Alles fuer Lau haben wollen
und nichts dazu tun. Am Besten noch ohne einmal Danke zu sagen, weil man
ja anonym ist. 95% der Bettler hier sind nicht mal eingeloggt, warum
bloss ?
Die Threads haben so schoen angefangen und nun versaut Ihr alles.
Walter sag es doch, Du bist gekauft und alle haben ihre Ruhe.
Du sagst es steht alles in den drei Threads, dann lehne Dich doch
zurueck und rechtfertige Dich hier nicht. Hast Du doch garnicht noetig.
Besser noch, lass ihn schliessen. Es hat doch keinen Sinn mehr, sieht
das denn niemand ?
Johannes O. schrieb:> Warum schreibt von den ganzen "Kritikern" niemand als angemeldeter> Benutzer? Alles nur Namen die man kaum bis überhaupt nicht sonst im> Forum kennt...
Also ich habe beispielsweise als angemeldeter Benutzer geschrieben. Ich
bin seit mehreren Jahren hier angemeldet. Lars R. ist auch mein Name im
echten Leben...
Darf ich mich in diesem Beitrag nicht äußern, nur weil ich nicht
dutzende Beiträge jeden Tag verfasse?
Vielleicht geht es nicht nur mir so, aber in dieser
Internet/Elektronik/Linux-Geschichte usw. ist es normalerweise üblich,
Code bereitzustellen - fast immer ohne finanzielle Gegenleistung, nur
aus Überzeugung am "Open Source"-Gedanken.
Du verwendest sicherlich auch Open-Source-Software, ohne dass du an
dieser mitgearbeitet hast oder dich an den anfallenden Kosten beteiligt
hättest.
Diese Einstellung in diesem Beitrag momentan passt einfach nicht zum
Charakter dieser Diskussionsplattform mit Wiki, Forum, Codesammlung usw.
Ich bin überzeugt davon, dass auch andere Mitleser sich hier viele
Gedanken gemacht haben und dafür Zeit investiert haben, die nun unterm
Strich für andere Dinge wohl besser aufgehoben gewesen wäre.
Nur weil diese Leute nicht am "fertigen Produkt" mitgeholfen haben, sie
auszuschließen vom Erfolg, führt nur dazu, dass künftig so eine
Beteiligung hier nicht mehr in diesem Maße zu finden sein wird.
So kann man auch etwas kaputtmachen. Ich werde diese Angelegenheit hier
jedenfalls so schnell nicht vergessen.
Warum sollten wird den Thread wegen ein paar anzweifelnden Spinnern
schließen lassen? Das ist doch genau das was sie wollen!
Wenn Walter irgendwas zugeben würde, würde als nächstes der Preis
verhandelt. Wieviel bekam er dafür? Wie beschämt ist er? Was macht er
damit? Will er nicht teilen? Blödsinn!
Die Sicherheit der Uhrzeit als Schlüssel ist damit begründet, dass man
aus ihr, mit einem bisher unbekannten Algorithmus, eine Art echter
Schlüssel ermittelt. Solange man diesen Algorithmus nicht kennt kann man
auch einfach eine hochlaufende Zahl verwenden.
Ist ähnlich wie bei RC4/WEP: Dort gab es auch IV
(initialisierungsvektoren), die waren glaub ich 3 Byte breit und wurden
auch nach jedem Paket einfach erhöht, damit man einen anderen Schlüssel
bekommen hat.
Findet die Fehlerkorrektur wirklich erst nach der Entschlüsselung statt?
Das ist doch eher eine Fehlererkennung. Die eigentliche Korrektur mit
diesen naiven Ansatz einfach alle Bits der Reihe nach durchzukippen
findet davor statt.
Abdul K. schrieb:> - Durch Einfügen einer festen (von dir so genannten) 'Kennung' eine> Fehlerkorrektur innerhalb des Entschlüsselungsalgorithmus durchgeführt> werden kann. Bislang konnte ich mir eine Fehlerkorrektur NACH> Entschlüsselung nur theoretisch vorstellen. Mein Kenntnisstand war> vorher, daß Fehlerkorrektur praktisch immer nur VOR der Entschlüsselung> möglich ist. Hier wurde bewiesen, es geht auch anders! Wenngleich der> Weg dann sehr kurios ist: Ich weiß nicht ob das schon genau beschrieben> wurde und ob dies gewünscht ist, daher lasse ich es.
Weiter oben stand, dass es keine Fehlerkorrektur gäbe. Nun sagst du,
dass es doch eine solche gäbe, willst aber auch hierzu nichts weiter
sagen.
Da habt ihr wirklich tolle Arbeit geleistet... Respekt!
Lars R. schrieb:> So kann man auch etwas kaputtmachen. Ich werde diese Angelegenheit hier> jedenfalls so schnell nicht vergessen.
Also Leute, merkt Euch. Keine Projekte mehr einstellen, nur noch
mitlesen und im Kabueffchen bleiben. Bloss nichts sagen ! Sonst wird
man hier an die Wand gestellt.
Mir kommt das hier vor wie beim jackpot. Einer gewinnt und ploetzlich
tauchen 100.000 "Freunde" auf.
Ich sage nichts dazu, weil es nunmal nicht von mir entdeckt wurde und
ich Walter erstmal respektiere.
Es bringt bei mir absolut nichts, direkt oder indirekt, zu 'bohren'.
Die Fehlerkorrektur ist nicht Syndrombasierend. Der untersuchte PIC kann
1-Bit Fehler letztendlich korrigieren.
Den EM-Marin haben wir ja ganz unterschlagen...
Peter W. schrieb:> Also Leute, merkt Euch. Keine Projekte mehr einstellen, nur noch> mitlesen und im Kabueffchen bleiben. Bloss nichts sagen ! Sonst wird> man hier an die Wand gestellt.> Mir kommt das hier vor wie beim jackpot. Einer gewinnt und ploetzlich> tauchen 100.000 "Freunde" auf.
Interessant ist, dass nun die, die der Kritik ausgesetzt sind, auch noch
beleidigt reagieren.
Es geht nicht um einen Jackpot. Ginge es um "echte Werte" würde hier
sicherlich nicht so viel Unmut herrschen.
Es geht vielmehr um die Inkonsequenz. Keiner muss etwas frei zur
Verfügung stellen. Aber warum musste hier verbreitet werden, dass man
dahinter gekommen sei, dann aber sein Ergebnis nicht teilen will?
Hätte man nicht einfach still sein können?
Ich ging die letzten Tage davon aus, dass dieses Thema eventuell doch zu
komplex gewesen sein könnte und dass deshalb der Beitrag "eingeschlafen"
sei. Damit hätten sicherlich viele der jetzigen Kritiker "leben" können.
Aber so ein "Ende" war niemals in Aussicht gestellt worden. Keiner hat
kommuniziert, dass man alles für sich behalten will. Nachträglich die
Spielregeln zu ändern gehört sich nicht.
Wer "Falk O." ist, das ist mir nicht bekannt. Vermutlich aber keiner von
den aktiven Leuten. Zumindest hatte keiner vor aus der "core-Gruppe"
hier sowas zu posten, soweit ich das weiß.
> Hätte man nicht einfach still sein können?
Was man nicht weiß, macht einen nicht heiß... oder wie war das? ;-)
Noch was interessantes: In den ersten 64Byte (die man auslesen kann weil
es dort keine Code-Protection gibt), ist auch einiges an Code drin.
Ausgeführt wird er aber offenbar nicht, nach aktuellem Stand. Es wird ja
vermutet dass es ein Honeypot ist.
Am Ende des Bereichs wird folgendes mit den Bytes 0x12 bis 0x14 gemacht:
Zuerst wird ja immer ein Byte geladen, dann XOR gemacht und dann wirds
wieder zurückgeschrieben. Danach ist der auslesbare Bereich zu Ende,
also was passiert danach?
Eine interessante Sache die aber dagegen spricht, dass es wirklich ein
"normaler" Honeypot ist: Im Bereich ab 64 (wo er nicht mehr auslesbar
ist) geht der Code nämlich mit dem gleichen Prinzip weiter: Also auch
wieder Bytes laden, XOR und zurückschreiben. Und zwar wird das bei allen
Bytes von 0x12 bis 0x1b gemacht.
Also: Es gibt noch genügend zu tun und genügend Ruhm zu ernten für alle
die sich jetzt übergangen fühlen.
(herausgefunden mit einer Methode die sowohl Abdul als auch ich
unabhängig voneinander vorgeschlagen hatten. ist also nix geklaut!).
Leute... Falls sie die Verschlüsselung wirklich geknackt haben, dann
können das auch andere. Die meisten Menschen die sich Zeit nehmen so ein
Vorhaben umzusetzen sind teil der opensource Gemeinde. Daher wird
irgendwann eine frei verfügbare Möglichkeit kommen die Meteotime Daten
zu nutzen.
Ich finde es sehr schade das der Allgemeinheit der Entschlüsselungsalgo
nicht zugänglich gemacht wird. Aber wie ich schon schrieb: Was die
können das können auch andere. Also bildet doch eine Taskforce unter dem
Einverständnis das Ergebnis am Ende zu veröffentlichen.
Lars R. schrieb:> Weiter oben stand, dass es keine Fehlerkorrektur gäbe. Nun sagst du,> dass es doch eine solche gäbe, willst aber auch hierzu nichts weiter> sagen.
Wieso, das ist doch aus der Beschreibung hier klar:
* der Klartext enthält eine feste Bitfolge an einer definierten Stelle
* bei einem fehlerhaften Cyphertext wird diese im Ergebnis nicht
erscheinen
* für die Fehlerkorrektur wird neben dem empfangenen Cyphertext auch
noch
jeweils "testweise" an jeder Position ein Bit gekippt
* wenn bei diesen Entschlüsselungen irgendwann die gewünschte Bitfolge
auftaucht, dann kann man das Ergebnis verwenden.
Also quasi "Brute-Force-Fehlerkorrektur"... :)
(Nein, ich bin kein Core-Team-Mitglied, ich kann da auch danebenliegen)
> Da habt ihr wirklich tolle Arbeit geleistet... Respekt!
Dem schließe ich mich an.
Viele Grüße,
Simon
Walter Freywald schrieb:> 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.
Ein schnelle PC schafft 384 Millionen Schlüssel pro Sekunde [1], das
bedeutet er hätte einen 40Bit Schlüssel in unter einer Stunde errechnet.
2^40 / 384e6/s = 0,8h
[1]http://events.ccc.de/congress/2010/Fahrplan/attachments/1801_27C3%20-%20Distributed%20FPGA%20Number%20Crunching%20for%20the%20Masses.pdf
Gratulation an den Codebrecher. Und meine Hochachtung zum Auslesen des
RAMs, sowie der Rekonstruktion des Algorithmus daraus.
Die Gründe den Code nicht zu veröffentlichen kann ich gut
nachvollziehen, ich hätte es auch so gemacht. Auch wurde vorher nicht
behauptet ihn zu veröffentlichen.
Es ist wirklich schade, dass nun ein paar Miesepeter mit schlechten
Manieren auftauchen und die Früchte ernten wollen, die sie selbst nicht
gesät haben.
Das Brechen des Schlüssels in unter einer Stunde ist natürlich mehr
akademischer Natur, weil der Algorithmus unbekannt war. Den Schlüssel
hätte man durch den RAM-Dump dann ebenso erhalten.
und gerne nochmal:
Open Source schön und gut. Aber hier sehe ich nicht das öffentliche
Interesse. Es ist eine Firma, die damit Geld verdient. Wenn der "genaue"
Algorithmus hier stünde, würde das etwas kaputt machen. So sehe ich das
zumindest.
Anders ist das, wenn es z.B. um WPA oder Geldkarte oder sonst was geht,
dass uns alle betrifft, da wäre ich der Letzte, der hier nicht jedes
Detail veröffentlichen würde. Mir geht es hier nicht um Ruhm oder sonst
was. Ich will einfach Meteotime nicht schaden - bitte versteht das
einfach.
Ich habe euch im Detail erklärt, wie das Ding funktioniert. Nur die
letzen Feinheiten, die man zum exakten Nachbau braucht habe ich genau
aus diesem Grunde weg gelassen - nicht um hier der Held zu sein, der was
weiß, das andere nicht wissen, sonder wie gesagt: der Rechtinhaber -
glaubt es oder lasst es bleiben.
Anbei nochmal das Ganze nochmal grafisch aufbereitet und zusammen
gefasst. Nein, da ist nichts Neues drin, alles wurde hier bereits
erwähnt.
Ich weiß von drei weiteren Leuten / Grüppchen, dass sie schon sehr weit
sind und mit Sicherheit in nächster Zeit den vollständigen Alogrithmus
haben werden. Vielleich sehen die das Ganze lockerer...
Und dann wird es sicher noch einmal spannend - die verfolgen nämlich 2
verschiedene Ansätze -> also dran bleiben !
Walter.
Manfred Freise schrieb im Beitrag #2241497:
> Das ist wirklich dein Ernst? Dir wäre es wirklich lieber wenn kriminelle> Millionen erbeuten könnten als wenn sich einige wenige Hobbybastler eine> DCF-Uhr mit Wetterfunktion bauen? Was soll man dazu sagen...
Genau das wollte ich vorhin auch schreiben, als ich das las. Aber ich
habe lieber das Notebook zugeklappt...
Wenn man großen Softwarefirmen wie Microsoft, Apple und Co. Zeit lässt
einen sicherheitsrelevanten Fehler zu beheben, bevor man etwas
veröffentlicht, dann ist das verantwortungsvoll und - ich finde - auch
richtig.
Aber wieso man hier lieber Informationen veröffentlichen will, die
Kriminelle schamlos ausnutzen könnten, verstehe ich beim besten Willen
nicht.
Die Wetterdatenfirma braucht keine Zeit, da sie ihre Controller
nachträglich sowieso nicht mehr sicherer machen kann. Daher verstehe ich
hier die Aufregung nicht.
Ich glaube auch kaum, dass eine andere Firma eine illegale Wetterstation
für weniger als 9 Euro verkaufen könnte. Der Wetterdatenfirma gingen
dadurch keine Euros verloren. Der Elektronikfreund, welcher das
Verfahren ausnutzen möchte, würde sicherlich nicht den Umsatz der Firma
so verringern, dass diese in Schulden unterginge.
Für mich sind es andere - mir unbekannte - Motive, die hier
ausschlaggebend sind. Vermutlich ist es einfach nur die Angst vor
Strafverfolgung. Ob dies geschehen könnte, weiß ich nicht, denn ich bin
kein Jurist.
Aber hier wurden ja bereits Vorschläge gemacht, wie man andere Stellen
mit den Informationen versehen könnte, so dass man ohne Sorge davon
käme.
Alles sehr unrühmlich und enttäuschend was man momentan zum Thema lesen
muss...
Vielleicht sind die anderen Mitstreiter an diesem Projekt
gemeinschaftlicher eingestellt. Man kann ja noch hoffen.
> Walter Freywald schrieb:>> Anders ist das, wenn es z.B. um WPA oder Geldkarte oder sonst was geht,>> dass uns alle betrifft, da wäre ich der Letzte, der hier nicht jedes>> Detail veröffentlichen würde.>> Das ist wirklich dein Ernst? Dir wäre es wirklich lieber wenn kriminelle> Millionen erbeuten könnten als wenn sich einige wenige Hobbybastler eine> DCF-Uhr mit Wetterfunktion bauen? Was soll man dazu sagen...
Ich denke er meint mit veröffentlichen in dem Kontext, dass er es es den
betroffenen Institutionen in jedem Detail zukommen lässt.
Eine komplette Veröffentlichung wäre hier erst zu einem Zeitpunkt wo die
Sicherheitslücke geschlossen wird verantwortbar.
Der einzige Schaden der durch Offenlegung des Algos hier entstehen würde
wäre, dass mehr Geld in die Suche nach Produkten von Herstellern ohne
Lizenz investiert werden müsste.
Der Anfang dieses Threads war wirklich spannend zu lesen. Ich hatte/habe
leider zu wenig Zeit, mitzumachen. Interessant ist vor allem, wie
geschafft wurde, ein RAM-Dump auszulesen. Daraus einen Algorithmus
abzulesen ist mehr als eine Fleißarbeit. Der wichtigste Punkt ist aber
sicherlich, zu erkennen, dass es DES ist. Anhand dieser Kenntnis kann
man den RAM-Dump sicherlich noch besser lesen und versteht auch mehr.
Ich glaube schon, dass der Algorithmus "geknackt" wurde. Der Code aber
sicherlich nicht - aber das ist eher zweitrangig.
Was würde es schon bringen, den Algorithmus (oder gar den Code) zu
kennen?
Ja, ich könnte einen eigenen Decoder bauen. Naja, ich kann auch eine
Wetterstation kaufen und den eingebauten Decoder verwenden.
Das interessiert mich aber nicht, da die Vorhersageauflösung einfach zu
gering ist. Bei uns ist das Wetter im Nachbarort (4km!) komplett
verschieden.
Also bringt mir MetoTime nichts. Mein Wetterschätzeisen (welcher
aufgrund der Temperatur und des Luftdruckverlaufes eine Prognose
erstellt) ist ungefähr genauso hilfreich.
Die zweite Variante wäre es, einen eigenen Encoder zu bauen, diesem mit
genaueren Wetterdaten aus dem Internet zu füttern und auf einer
gekauften Wetterstation anzuzeigen. Nee, das macht keinen Sinn. Entweder
müsste die Wetterstation umgebaut werden, damit sie statt DCF meine
Wetterdaten annimmt; oder ich muss einen eigenen DCF-Sender bauen
(letzteres würde meinem Nachbarn ggf nicht gefallen).
Es bringt mir also nichts, den Algorithmus oder gar den Code zu kennen.
Aus diesem Grund mache ich auch kein Gewese darum, ob der Code nun
wirklich geknackt wurde oder ob hier eine Verschwörung am Werke ist.
@Walter Freywald
Eine Frage hätte ich noch.
Ist der RAM-Dump, aufgrund dessen der Algorithmus durchschaut wurde,
hier im Thread zu finden oder ist er "geheim"?
Christian H. schrieb:> Ich glaube schon, dass der Algorithmus "geknackt" wurde. Der Code aber> sicherlich nicht - aber das ist eher zweitrangig.>
'Code'? DES, Implementation (im pdf zu finden), Daten der SBoxen,
Binärcode. Was will man mehr? Was fehlt sind noch Bytes die die
Decodierung anscheinend nicht benutzt. Daran wird gearbeitet.
> Was würde es schon bringen, den Algorithmus (oder gar den Code) zu> kennen?>> Ja, ich könnte einen eigenen Decoder bauen. Naja, ich kann auch eine> Wetterstation kaufen und den eingebauten Decoder verwenden.>> Das interessiert mich aber nicht, da die Vorhersageauflösung einfach zu> gering ist. Bei uns ist das Wetter im Nachbarort (4km!) komplett> verschieden.> Also bringt mir MetoTime nichts. Mein Wetterschätzeisen (welcher> aufgrund der Temperatur und des Luftdruckverlaufes eine Prognose> erstellt) ist ungefähr genauso hilfreich.>
Sehe das genauso.
> Die zweite Variante wäre es, einen eigenen Encoder zu bauen, diesem mit> genaueren Wetterdaten aus dem Internet zu füttern und auf einer> gekauften Wetterstation anzuzeigen. Nee, das macht keinen Sinn. Entweder> müsste die Wetterstation umgebaut werden, damit sie statt DCF meine> Wetterdaten annimmt; oder ich muss einen eigenen DCF-Sender bauen> (letzteres würde meinem Nachbarn ggf nicht gefallen).>
Du kannst schon einen lokalen DCF77 Sender bauen. Gibt ja Anleitungen
dazu. Du kommst damit nicht sonderlich weit. Den Nachbarn erwischt es
vielleicht, wenn du in einem der Menschen-Hühnerställe wohnst
(Hochhaus).
Du kannst dir also dein lokales Schätzeisen nehmen und damit einen
lokalen DCF77 Sender betreiben. Wenn er richtig stark ist, könntest du
deine nächsten Nachbarn mitversorgen. Die würden es noch nicht einmal
merken.
> Es bringt mir also nichts, den Algorithmus oder gar den Code zu kennen.>> Aus diesem Grund mache ich auch kein Gewese darum, ob der Code nun> wirklich geknackt wurde oder ob hier eine Verschwörung am Werke ist.>
Gute Einstellung.
>> @Walter Freywald> Eine Frage hätte ich noch.> Ist der RAM-Dump, aufgrund dessen der Algorithmus durchschaut wurde,> hier im Thread zu finden oder ist er "geheim"?
Er ist wohl geheim und wie gesagt, nicht vollständig - was aber den
ausgeführten Code nicht betrifft.
Walter hat gemeint, er wolle sich den Streß hier weiterzuposten nicht
mehr antun.
Abdul K. schrieb:> 'Code'? DES, Implementation (im pdf zu finden), Daten der SBoxen,> Binärcode. Was will man mehr? Was fehlt sind noch Bytes die die> Decodierung anscheinend nicht benutzt. Daran wird gearbeitet.
Als 'Code' meine ich den "kompletten" Originalquellcode im PIC.
Mich würde jedenfalls interessieren, ob das ebenfalls gelungen ist.
Entsprechende Ansätze scheinen ja da zu sein - also einen geschützten
PIC ohne Zerstörung trotzdem auszulesen (keine Angst, will ich nicht
anwenden, mich interessiert nur, ob es gelungen ist).
Das PDF habe ich erst später entdeckt. Ist jedenfalls ebenfalls
interessant. Zumindest macht das ganze Lust, sich mit dem
DES-Algorithmus genauer auseinander zu setzen. Bisher habe ich ihn nur
als fertige Bibliothek verwendet, ihn aber nie verstanden, geschweige
denn es versucht.
>> @Walter Freywald>> Eine Frage hätte ich noch.>> Ist der RAM-Dump, aufgrund dessen der Algorithmus durchschaut wurde,>> hier im Thread zu finden oder ist er "geheim"?>> Er ist wohl geheim und wie gesagt, nicht vollständig - was aber den> ausgeführten Code nicht betrifft.
Es sind also nicht die Teile, die bereits hier im Thread veröffentlicht
wurden.
Ich frage nur, falls ich mal Lust habe, mich ebenfalls an dem "knacken"
des Algorithmus zu wagen (ohne gleich eine Wetterstation zu kaufen,
auseinader zu reissen, PIC-Programmer besorgen, ...); also auf Basis der
hier erbrachten Vorarbeiten aufzusetzen.
> Walter hat gemeint, er wolle sich den Streß hier weiterzuposten nicht> mehr antun.
Kann ich verstehen.
Nein, den Code kann man nicht ohne Decoderchip herausfinden. Zum
Experimentieren brauchst du nen PIC-Programmer und nen PIC12F509.
Dann ne Wetterstation mit HKW-Chip wo man den RAM-Monitor draufläd.
Ohne diese Ausrüstung sollte es nicht möglich sein, außer man geht nen
anderen Weg und versucht es über die ganzen Plain/Crypt-Paare die Thomy
mitgeloggt hat. Ob das möglich ist? Ich denke eher nicht...
Ich möchte an dieser Stelle einmal "Danke" an die Freaks sagen!
Ich lese schon ziemlich lange mit und habe sehr interessiert verfolgt,
wie an die Sache herangegangen wurde.
Als die "Nulldatensätze" Anfang des Jahres gesendet wurde, war auch mein
Forscherdrang geweckt und ich bastelte mir eine MySQL-Datenbank, um
Regelmäßigkeiten zu erkennen und ein wenig mit den Codes zu jonglieren.
Bevor damit irgendwas anzufangen war, wurde es im Forum hektisch und nur
Tage später wart ihr viel weiter als ich.
Bei allen folgenden Themen fiel es mir schwer, euch noch zu folgen, bald
drauf kam ich gar nicht mehr mit.
Die Schlussphase war hochspannend und ich habe täglich ins Forum
geschaut, ob es geschafft wurde.
Jetzt werde ich mir noch nächtelang das PDF studieren...
Vielen Dank für "die Unterhaltung" und die gewonnenen Erkenntnisse. Ich
glaube nicht, die irgendwann mal "verwursten" zu können, obwohl das
ursprünglich mal mein Ziel war.
1. Bitte hier keinen Code oder Schlüssel veröffentlichen.
2. Beiträge von "Manfred Freise"/"Meteo"/"Paolo
Luca"/"Bossman"/"Fragezeichen"/"Michael Meier"/"Martin H."/"Harry
K."/"Jimmi Bondi"/"Ob ama"/"Nick" wurden gelöscht, da selbe Person.
Thread beobachten
Seitenaufteilung abschalten