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.
Ich denke, dass es möglich ist, die bislang geheimen Informationen durch
Kryptoanalyse herauszubekommen. Der Algorithmus ist ja nun bekannt.
Außerdem können wir "Chosen Cipher Text" und "Chosen Key" gleichzeitig
machen, was ein selten auftretender Fall ist (wenn wir eine Uhr haben,
in die wir Daten hineinschicken können). Zumindest die geheime P-Box
lässt sich so ermitteln (Stichwort "Weak Keys")
Ohne Uhr, nur mit den Datensätzen die bisher gesendet wurden, wird es
schwierig. Ich glaube, es sind zu wenig Daten mit nie den gleichen
Schlüsseln (weil ja die Zeit immer weiterläuft).
Na, mal sehen.
Frank Schrader schrieb:> Ich denke, dass es möglich ist, die bislang geheimen Informationen durch> Kryptoanalyse herauszubekommen. Der Algorithmus ist ja nun bekannt.> Außerdem können wir "Chosen Cipher Text" und "Chosen Key" gleichzeitig> machen, was ein selten auftretender Fall ist (wenn wir eine Uhr haben,> in die wir Daten hineinschicken können). Zumindest die geheime P-Box> lässt sich so ermitteln (Stichwort "Weak Keys")>
Schlug ich schonmal vor. Wurde aber gesagt, das sei nicht so einfach
möglich.
> Ohne Uhr, nur mit den Datensätzen die bisher gesendet wurden, wird es> schwierig. Ich glaube, es sind zu wenig Daten mit nie den gleichen> Schlüsseln (weil ja die Zeit immer weiterläuft).
Die Uhrzeit ist im Prinzip ein One-Time Pad, wenn der Übergang von
vorhersehbarer Time zu einem internen Abbild davon kryptografisch gut
gemacht ist.
Ein (groß genuges) One-Time Pad wäre im Prinzip unknackbar. Lange Zeit
wurden so Regierungsbotschaften transportiert.
Sollten mehrere unterschiedliche Times zu einem gleichen internen
Abbild führen, dann ist das eine Einbruchsstelle.
Abdul K. schrieb:> Sollten mehrere unterschiedliche Times zu einem gleichen internen> Abbild führen, dann ist das eine Einbruchsstelle.
Anders geht es doch gar nicht, wenn aus den zur Verfügung stehenden
Zeitbits nur eine Auswahl als Schlüssel genutzt wird.
Ist schon komisch, wie ursprünglich die Sache sofort geblockt wurde,
obwohl
klargestellt wurde, daß nur legale methoden verwendet werden.
Auf dem anderen Server ging es dann weiter und blieb auch eine Zeit lang
legal, dann auf dem dritten Serverwurde nachdem der Sourcecode
dort gepostet wurde hatte ich das nicht mehr weiterverfolgt, war jedoch
verwundert, daß der Thread hier weiterging und nun plötzlich geduldet
wurde.
Lars R. schrieb:> Anders geht es doch gar nicht, wenn aus den zur Verfügung stehenden> Zeitbits nur eine Auswahl als Schlüssel genutzt wird.
wenn Du den oben geposteten Proof of Concept anschaust, wirst du
feststellen dass alle "ZeitBits" als Schlüßel genutzt werden. In der
Praxis sind aber nicht alle Bits unabhängig so dass die echte
Schlüßellänge wieder kürzer als 40Bit ist.
Lars R. schrieb:> Abdul K. schrieb:>> Sollten mehrere unterschiedliche Times zu einem gleichen internen>> Abbild führen, dann ist das eine Einbruchsstelle.>> Anders geht es doch gar nicht, wenn aus den zur Verfügung stehenden> Zeitbits nur eine Auswahl als Schlüssel genutzt wird.
Doch schon, der Time-String muß nur mehr Möglichkeiten besitzen als die
Laufzeit der MeteoTime-Lizenz. Das reicht dann aus!
??? schrieb:> Ist schon komisch, wie ursprünglich die Sache sofort geblockt wurde,> obwohl> klargestellt wurde, daß nur legale methoden verwendet werden.> Auf dem anderen Server ging es dann weiter und blieb auch eine Zeit lang> legal, dann auf dem dritten Serverwurde nachdem der Sourcecode> dort gepostet wurde hatte ich das nicht mehr weiterverfolgt, war jedoch> verwundert, daß der Thread hier weiterging und nun plötzlich geduldet> wurde.
Ich kenne nur zwei Server mit jeweils mehreren Threads. Ein dritter
Server mit dem kompletten Source-Code? Maile mir mal den Link.
Abdul K. schrieb:> Ich kenne nur zwei Server mit jeweils mehreren Threads. Ein dritter> Server mit dem kompletten Source-Code? Maile mir mal den Link.
Das würde mich aber auch einmal interessieren.
Ich habe intensiv nach diesem Thema im Internet gesucht, aber außer
Mikrocontroller.net nichts gefunden, wo es wirkliche Hinweise und auch
konstruktive Ideen gab.
Die Threads im anderen Forum kenne ich mangels Zugriffsmöglichkeit dort
nicht.
Lars R. schrieb:> Ich habe intensiv nach diesem Thema im Internet gesucht, aber außer> Mikrocontroller.net nichts gefunden, wo es wirkliche Hinweise und auch> konstruktive Ideen gab.
Es gab ein von einem Mitglied hier im Forum gegründetes privates Forum,
zu dem in dem ersten Thread (von 2008) auch ein Link existierte.
Ich war dort auch Mitglied, konnte aber wg. Zeitmangels wenig beitragen.
Jetzt bekomme ich aber keinen Zugang mehr zu dem Forum. Letzten Monat
konnte ich mich noch dort einloggen.
Timo S. schrieb:> Lars R. schrieb:>> Anders geht es doch gar nicht, wenn aus den zur Verfügung stehenden>> Zeitbits nur eine Auswahl als Schlüssel genutzt wird.>> wenn Du den oben geposteten Proof of Concept anschaust, wirst du> feststellen dass alle "ZeitBits" als Schlüßel genutzt werden. In der> Praxis sind aber nicht alle Bits unabhängig so dass die echte> Schlüßellänge wieder kürzer als 40Bit ist.
Das ist richtig - die 40 Zeitbits gehen komplett als Schlüssel in den
Algorithmus (s.auch PDF).
Dann werden aus diesen 40 Bit 30 Bit ausgewählt (Kompression).
Auf der "R"-Seite wird aus den 20 Bit 30 Bit gemacht (Expansion)
Dann werden diese beiden 30 Bit Werte XOR Verknüpft und aus dem
resultierenden 30 Bit Wert wird aus jeweils 6 Bit 4 Bit gemacht: S-Boxen
(das Ganze 5 mal, also 30 Bit werden wieder zu 20 Bit).
So gesehen werden aus dem Schlüssel erst einmal nur 30 Bit verwertet.
Von der Plain Seite kommen eigentlich nur 20 Bit dazu.
Durch die S-Boxen gehen aber alle 30 Bit in das Ergebnis ein.
Ich verstehe das so, dass von 40 Bit nur 30 genutzt werden, also gibt es
2^10 = 1024 gleiche Schlüssel.
Das gilt allerdings nur pro Runde.
Dadurch, dass es 16 Runden gibt kommen alle Bits des Schlüssels zum
Einsatz.
Es gibt aber Schlüssel, die wiederholte Muster enthalten (im
schlechtesten Falle alles 1 oder alles 0), die gleiche Rundenschlüssel
erzeugen. Das ist eine bekannte Schwäche des DES.
Walter
Abdul K. schrieb:> Dann gibt es offensichtlich zwei 'Untergrund'-Organisationen. Wenn das> Schäuble wüßte.
Seit dem er im Finanzministerium ist, scheint es um seine
Verfolgungsangst besser geworden zu sein...
Ich wusste, dass ich etwas mit 30 Bits aus 40 Bits gelesen habe. Dass
dies allerdings für jede Runde gilt, habe ich wohl verdrängt.
Der dritte Server war ein Subdomain von narod.ru , läuft jetzt aber
nicht
mehr, ist auch viel Zeit vergangen. Wurde mittels PM vom zweiten Server
eingeladen. Nur closed user sowie nicht über Websuche zu finden.
Der SW-decoder läuft ohne probleme auf dem router seitdem.
Es gabt auch ein Demoprogramm für den PC welche die geloggten Datensätze
von diesem Forum decodiert incl. Sourcecode in C welches von Chris zur
Verfügung gestellt wurde. Dasselbe Programm läuft auch auf dem Avr.
Der Sourcecode wurde einfach mittels eines Avr sowie Labornetzteil und
9V Batterie ausgelesen.
Normale VCC wurde über einem I/O Pin gespeist. Alle Anschlüsse mittels
Led-Vorwiderstand. VPP = Batteriespannung + 0.5V sowie Batterie manuell
an VCC zum richtigen Zeitpunkt aufgeschaltet. Wie an dieses Programm
rankommen, keine Ahnung. Ich hatte immer den Verdacht, daß es eigentlich
der
Betreiber des extra dafür eingerichteten Forums war, welcher die
Diskussion
für das Auslesen des Bausteins auf einen nicht deutschen Server
umgeleitet
hatte. Schick ihm mal eine Mail, seine Kontaktdaten müssten ja noch im
ersten Thread vorhanden sein.
Was meinst du genau? Hatten die den Code schon?
Wenn ja, mit welche Methode? Hört sich ein wenig nach Power-Glitches
usw. an, aber scheint eher ne Holzhammermethode zu sein ;-)
Ja, war die übliche power glitch methode welche auch bei smart-card
verwendet wurden bzw bis 2004 funktionierte.
Der Benutzer welcher den Code ausgelesen hatte besaß
kein pic progger und nur ein einfaches Labornetztgerät und so wurde halt
mittels 9V Batterie ausgeholfen. Mit einem richtigen Pic Programmer
würde
ein Labornetzteil reichen.
Zur Info, diese Methode funktioniert noch bei allen Pics, welche keinen
internen Komparator haben. Bei den A-Modellen mit integriertem
Komparator
funktioniert diese nicht mehr.
Walter Freywald schrieb:> So gesehen werden aus dem Schlüssel erst einmal nur 30 Bit verwertet.> Von der Plain Seite kommen eigentlich nur 20 Bit dazu.> Durch die S-Boxen gehen aber alle 30 Bit in das Ergebnis ein.
das habe ich nicht gemeint, so gesehen werden bei DES-56 ja auch nur
48Bit pro Runde verwendet. Bei DES56 ist der Schlüßel 64Bit lang,
beinhaltet aber 8 Parity Bits die nicht in die wirksame Schlüßellänge
eingehen.
Hier ist es ähnlich (Ausschnitt aus dcf77logs):
<------------------------------
IN: - Datenpaket 1.....................: 01110110000001
- Datenpaket 2.....................: 10011101111110
- Datenpaket 3.....................: 00001111001100
- Minute...........................: 00101000 14
- Stunde...........................: 00000000 00
- Tag..............................: 10100100 25
- Monat............................: 01100 06
- Wochentag........................: 011 6
- Jahr.............................: 10001000 11
Laut wikipedia sind für die Minute 7Bit+Parität reserviert. Für die
Stunde "nur" 6Bit + Parität während hier offensichtlich 8Bit übertragen
werden. Für den Tag werden 2 Bit komlett mit 0 aufgefüllt.
Anscheinend werden auch alle Paritybits mit 0 übertragen.
Bei den verwendeten Schlüßeln sind also faktisch "nur" 35 Bit wirksam.
Die Parity wird nicht mit 0 übertragen, die wird dort weggelassen.
warum sollte man dort noch die parity übertragen?
glaube kaum das zwischen decoder und µProzessor der Wetterstation
übertragungsfehler auftreten.
Gruß
Thomas
Timo S. schrieb:> Hier ist es ähnlich (Ausschnitt aus dcf77logs):> <------------------------------> IN: - Datenpaket 1.....................: 01110110000001> - Datenpaket 2.....................: 10011101111110> - Datenpaket 3.....................: 00001111001100> - Minute...........................: 00101000 14> - Stunde...........................: 00000000 00> - Tag..............................: 10100100 25> - Monat............................: 01100 06> - Wochentag........................: 011 6> - Jahr.............................: 10001000 11>
Minute = 6 Bit
Stunde = 5 Bit
Tag = 5 Bit
Monat = 4 Bit
Wochentag = 3 Bit
Jahr = 7 Bit
Wenn man das aufsummiert kommen man auf 30 bits.
Jahr sind 8 bit!
Die Zahlen werden in BCD Dargestellt.
99 entspricht 10011001
Minute sind 7 Bit
stunde sind 6 Bit
Tag sind ebenfalls 6 bit
wochentag ist soweit korrekt
Monat sind 5 Bit
Macht zusammen 35.
Die Rechnung von Timo S. ist soweit richtig
BCD schon, aber der Crypt wird ja binär gemacht und da sind dann 0-99
nur
7bit. BCD=40bit . Diese werden mittels "Kompression" (BCD->BIN) auf
30bit
reduziert und somit harmonisiert.
Hallo,
Wenn der Schlüssel wirklich auf 30 bit reduziert wird, müsste dann nicht
bei einigen Schlüsseln bei gleichem plain der gleiche Cipher
herauskommen?
http://www.dcf77logs.de/DecoderAccess.aspx
Siehe datei "einsen im schlüssel einzeln.txt".
Die Datensätze haben alle den Selben klartext.
Ja. Nur kann offensichtlich keiner von uns die entsprechende Mathe dazu.
Einfaches XOR ist es eben nicht. Es hat sich nie jemand gemeldet, der
dazu das Rüstzeug hätte. Mein Vorschlag eines kompetenten
Ansprechpartners wurde nicht weiter diskutiert. Daher gehe ich auch
davon aus, es ist nicht erwünscht.
In Rußland ist alles viel einfacher.
Der Schlüssel geht mit 40 Bin in den DES ein.
Dort wird er in 2x 20 Bit aufgeteilt.
In jeder Runder werden diese 20 Bit jeweils um ein oder 2 Bit rotiert
(je nach Runde, siehe auch Meteo_Crypt.c).
Aus den 2x 20 Bit werden insgesammt 30 Bit abgegriffen und für die
weitere Verarbeitung verwendet (Rundenschlüssel). Durch die Rotation
sehen die 30 Bit aber immer anders aus (eigentlich: sollten immer anders
aussehen).
Hier liegt das Problem: einige Schlüssel, und das kann man leicht
nachvollziehen produzieren mehr oder weniger viele gleiche
Rundenschlüssel und beeinträchtigen dadurch die Sicherheit. Worst-case
ist wie schon gesagt alles 1 oder alles 0, da kommen immer die gleichen
Rundenschlüssel raus.
So wie ich das verstanden habe ist die Sicherheit höher, wenn es keine
doppelten Rundenschlüssel gibt.
Voraussetzung ist aber, dass man weiß, dass ein DES dahinter steht und
dass der Schlüssel so verarbeitet wird. Ist die Sicherheit wirklich
schlechter, wenn der Angreifer <u>nicht</u> (zefix, das mit dem
Underline bekomme ich nicht hin, aber ihr wißt, was ich meine...) weiß,
dass des der DES ist ?
Walter.
PS: immer her mit dem Experten (entschludige bitte die saloppe
Forumlierung). Wäre sicher nicht schlecht, wenn uns hier ein Fachmann in
Sachen Kryptologie ein wenig auf die Sprünge helfen würde.
Mich würde auch sehr interessieren, wie die Sicherheit des DES bei
dieser "Anwendungsform" - also Schlüssel ist bekannt, ist. Ich finde es
schwierig, da eigentlich alles unbekannt ist. Wenn man sich jetzt nur
Eingang und Ausgang anschaut und eignetlich garnicht weiß, dass es ein
DES ist und dass der Schlüssel ein Teil der Eingabedaten ist, ganz zu
schweigen von den S-Boxen etc. Wäre sicher Sinnvoll, einen Experten
dabei zu haben, der auch gewillt ist mit kryprografischen Laien zu
diskutieren (ich hoffe, ich trete jetzt keinem auf die Füße).
Somit @Abdul: ich bin dafür ;-)
Die Sicherheit steckt hier einzig und allein in der Geheimhaltung des
Algorithmus. Der Schlüssel wird ja jedesmal mitübertragen. Der Angreifer
steht also nicht vor der klassischen Aufgabe, zu einem bekannten
Algorithmus anhand von etwas Klartext+Schlüsseltext den Schlüssel zu
erraten, sondern er muß einen zu den Daten passenden Algorithmus finden.
Daher sind auch "weak keys" kein Problem: die geben in einem ganz
anderen Szenario Klartext preis, verraten aber nicht viel über den
Algorithmus.
Es hätte hier also jeder Algorithmus getan, der nicht trivial
durchschaubar ist. Ein angepaßter DES ist Overkill, aber dann ist man
wenigstens auf der sicheren Seite.
Ich kann die Entwickler bei HKW sehr gut verstehen. Sie standen vor
einer Aufgabe die kryptographisch im Grunde nicht sicher zu lösen geht
weil die Rahmenbedingungen das vorgaben. Sie haben 80 Nutzbits in einem
stark störbaren Datenkanal und müssen für die Zukunft, falls sie das
Ganze in Uhrenchips/DCF77 Chips integrieren lassen auch noch mit enorm
wenig Rechenpower auskommen.
Kryptographisch standen sie vor dem Dilema den richtigen Cipher
auswählen zu müssen. Heutige Cipher haben aus Sicht der Performance zwei
Flaschenhälse, 1. den Cipher Algo. selber und 2. das Keysetup und
Keyshedulling. Desweiteren gilt das man den Schlüssel regelmäßig
wechseln muß.
Nun, sie wollen einen PIC benutzen, ohne EEPROM Zugriffe und das heist
das Daten quasi im Code hinterlegt werden müssen. Also haben die HKW
Leute pragmatisch gedacht:
1.) Schlüssel wird in den 80 Nutzbits mit übertragen
2.) nur DES Cipher wird im PIC implementiert, das ist ein Feistel
Netzwerk das auch auf dem PIC ganz gut umsetzbar sein sollte (das sie
die S-BOX geändert haben ist problematisch dabei)
Vorteile:
- Schlüssel wird ständig gewechselt per Zufall
- kein Keysetup (DES ist da aufwendiger so das Experten schnell stützig
worden und erkannten das es gute und schlechte Schlüsel geben muß was
dem geplanten Brechen vom DES entgegen kam). Nur dieses originale
Keysetup ist unsicher nicht der Feistel-Cipher-Kern.
- da der Schlüssel zufällig ist kann man auch mit einer festen Signatur
in den Daten eine Prüfsumme einbauen. Wie ich es hier gelesen habe ist
diese 16 Bit.
Wir haben 80 Bits, davon 22 Nutzbits, 16 Bit Signatur, Rest
Zufallsschlüssel. Diese Signatur im Zusammenhang mit DES stellt also
eine 16Bit Prüfsumme von 80 Bits dar. Das ist in meinen Augen evntl.
mathm. überdimensioniert.
Bei unbekanntem Verfahren und Dateninhalten (80 Bits sind lächerlich
normalerweise sollte ein symmetrischer Schlüssel heute 128 Bits haben)
verhält sich dieses HKW System mit Zufallsschlüssel, der größtenteils
die 80 Bits aufbraucht, fast wie ein OTP. Dh. aus meiner Sicht ist das
was die HKW Leute gemacht haben, unter der Prämisse der Geheimhaltung,
noch das Beste was man überhaupt tun konnte. Die verschl. Daten zu
sniffen wird nicht viel bringen da sie bei unbekannten Verfahren
statistisch zufällig sind so lange das DES Feistelnetzwerk korrekt
implementiert wurde.
Betrachtet man den finanziellen Aufwand einen PIC physikalisch zu
brechen so sollte man in diesem Fall auch nicht mehr als 1 Tag eines
Entwicklers in diese Aufgabe investieren.
Das System wird auf Grund der Rahmenbedingungen niemals im Kontext
sicherer Systeme einstufbar sein. Das geht einfach nicht da die
nutzbaren Bandbreite unterhalb der für sichere System notwendigen
Bandbreite liegt.
Sehr viele krypo. Systeme sind mehrstufig, dh. sie benötigen zwingend
Acknowledge zwischen den Kommunikationspartnern. Auch dies geht bei
DCF77 nicht und somit gibt es keine Chance für den Designer die 80 Bit
Bandbreite virtuell durch Mehrfaktorprotokolle besser abzusichern.
Die Packetgröße von 80Bits noch weiter aufzubauen bedeutet das die
"Alles oder Nichts" Entschlüsselung wie sie hier benutzt wurde, immer
störanfällig wird. Auf Grund vom DES Schlüssellänge + Prüfsumme +
Nutzdaten + Stückelung im DCF77 Paketen, haben sich diese 80 Bits als
kürztmögliche Kodierung ergeben. Sie länger zu machen würde die
Wahrscheinlichkeit des Scheiterens der Alles oder Nichts Entschlüsselung
inkrementieren aber keinen krypto. relevanten Nutzen mehr bringen da mna
sich ja für die Übertragung der Schlüsselbits entschiedenen hat.
Das System basiert also auf zwei Annahmen:
1.) Geheimhaltung des Verfahrens
2.) Sniffen muß absolut zufällige Daten bringen die mit statischen
Methoden der Kryptoanalyse nicht knackbar sind. Besonders nicht mit
modernen Formen wie der differentiellen Kryptoanalyse die in diesem Fall
statistische Ungleichheiten im Ciphertext über mehrere Wetterpakete
betrachtet arbeiten würde. Wenn wir Punkt 1.) vorausetzen können dann
heist dies der Schlüssel muß immer zufällig gewählt werden. Das würde
ich persönlich noch nicht mal fordern sondern statt dessen mit einer
HAsh Funktion sowas wie einen S/KEY OTP erzeugen laasen. Dh. alle
Schlüssel sind von einander abhängig, pseudozufällig und können nur
gebrochen werden wenn das Masterpasswort für den S/KEY OTP Algorithmus
der die Schlüssel errechnet bekannt ist. Statt also unbeweisbaren echten
Zufall zu benutzen wird krypto. sicherer Pseudozufall erzeugt dessen
Sicherheitsschranken math. nachweisbar sind. Denn wichtig ist niczht nur
das der Schlüssel zufällig ist sondern auch das jeder Schlüssel nur
einmalig verwendet werden darf, Regeln eines OTP (One Time Pad).
Punkt 1.) ist aber nicht zu garantieren, jeder hier weiß das, deshalb im
Rahmen sicherer Kryptographie unsicher.
Übriges jedes Sytsem das nur einseitigt sicher vor Sniffen ist, also in
diese Fall der Sender, der Empfänger ist aber nicht unter Kontrolle von
HKW, muß kryptographsich immmer unsicher sein. Es gibt kein krypto.
System dieser Art das sicher wäre. Das kann man übertragen auf: DRM,
HD-TV, Lizenzschlüssel usw. All diese Sytseme sind brechbar wenn man die
Hardware brechen kann. Wenn man es ganz genau betrachtet so ist die
Kryptographie eine sehr demokratische Angelegenheit die was
anti-demokratisches (einseitige Geheimhaltung) umzusetzen versucht. Denn
wenn man es richtig machen möchte dann muß mna die Daten mit einem
Passwort verschlüsseln das dem Empfänger bekannt ist. Beide Sender und
Empfänger wählen ein zufallspasswort und speichern es nur in ihren
Hirnen. So lange das Hirn nicht knackbar ist ist das sicher.
Kryptographie bevorzugt also Systeme bei denen sich Sender und Empfänger
gut stehen und benachteiligt Systeme bei denen der Sender den Empfänger
übervorteilen möchte, wie eben DRM, HD-TV, Lizenzsysteme usw.
Gruß
Ah vergessen: geht man davon aus das die Wetterdaten mehrfach versendet
werden um evntl. Datenübertragungsfehler ausschließen zu können (die
Robustheit des Systemes zu steigern) dann wird es immer wichtiger die
Schlüssel per Zufall ständig zu wechseln. Gerade solche Systeme wurden
in der Vergangenheit auf Grund fehlender Schlüsselwechsel gebrochen.
Gruß
Ah und: das Keysetup vom DES zu entfernen und statt dessen
Zufallsschlüssel für den Rest zu benutzen macht DES sicherer, wenn eben
die Schlüssel (pseudo)zufällig sind und nur einmalig verwendet werden.
Der Verzicht auf das Keysetup ist hier also besser.
Je länger ich dadrüber nachdenke je mehr komme ich zu Überzeugung dass
HKW sich fachlich gut beraten lassen hat.
Bleiben noch die veränderten S-BOX'en. Sie zu ändern war überflüssig im
Rahmen des krypto. Gesamtkonzeptes. Einzige Rechtferigung meinerseits
wäre das man mit geänderten S-BOX die Performance der Lösung verbessern
konnt (weniger Code usw.) Aber die S-BOX'en sind integraler Bestandteil
des Feistel Netzwerkes und somit ein wichtiger Bestandteil der
Methematik die den DES erst sicher macht. Es gibt für DES, Blowfish,
TWofish usw. verschiedene S-BOX'en, sei es auf Grund falscher
Interpretationen der Programmierer die diese System umsetzen sollten
oder einfach weil die Designer sich selbst nicht so sicher waren. Auch
für DES habe ich schon meherere S-BOXen gesehen. Eventl. ist eine dieser
nicht standadkonformen S-BOXen verwendet wurden.
Gruß
>Nur das in diesem Fall der Schlüssel vorhersehbar ist,>die letzten 40 bit der 80 Gesendeten Bits.>Korrigiert mich wenn ich das Falsch verstanden habe.
Wenn die Geheimhaltung, Punkt 1.), gegeben ist und Punkt 2.) immer
Zufallsschlüssel benutzt werden dann ist das nicht mehr vorhersehbar
noch irgendwie mit statistischen Methoden von echtem Zufall, über alle
80 Bits betrachtet, zu unterscheiden. Gibt es keine statistischen
Ungereimtheiten mehr so kann man alles und garnichts mehr machen. Man
kann versuchen einfach so drauflos zu experimentieren aber die 80 Bits =
2^80 Möglichkeiten, verhindern das man in irgendeiner praktikablen Zeit
zu einem Ziel kommt (Brute Force Attack). Da man weiß das das Verfahren
auf Geheimhaltung basieren muß ergeben sich effizientere
Angriffsmöglichkeiten:
1.) Erpressung und Folterung der beteiligten Personen
2.) Annektierung der DCF77 Sendestation in der meiner Vermutung nach
diese Daten kodiert werden. Denn das Syetem ist einfach auf Senderseite
umsetzbar.
3.) Invasives Hardware Reverse Engineering
Man weiß das es auf Geheimhaltung basieren muß weil:
1.) die Bandbreite des Übertragungskanales nicht ausreichend ist. 128
Bit sind mindestens erforderlich für symmetrische Verschlüsselungen und
die Zukunft wird das noch inkrementieren auf > 128 Bit.
2.) der Übertragungskanal ist unidirektional dh. Mehrfaktorprotokolle
die ein Acknowledge benötigen sind nicht umsetzbar. Mit diesen ließe
sich die Bandbreite inkrementieren.
3.) der Übertragungskanal ist störanfällig und auf Grund von 2.) können
Störungen nicht erkannt werden. Daraus folgt eine Mehrfachübertragung
gleicher Datenpakete und daraus folgt die Anwendung eines
Zufallsschlüssel genaugenommen eines OTPs, One Time Pad, zufälliger
Einmalschlüssel. Du darfst das nicht so eng sehen mit der Trennung von
Daten und Schlüsseln. Math. ergibt sich der Unterschied nicht auf Grund
ihrer Benamung sondern auf Grund ihrer Verwendung. Hier wird der
"Schlüssel" nicht als Schlüssel verwendet sondern als Daten die anders
in DES eingerechnet werden um den Rest der Daten zu dekodieren und das
auf eine Art und Weise die aus den zufällig wirkenden Datenpaketen nicht
reproduzierbar ist. Hier wird DES also eher als eine HASH-Funktion
eingesetzt um die Datenauthentizität sicherstellen zu können.
4.) Rechenpower ist stark begrenzt und Features der gewählten Plattform
ist stark eingeschänkt (wenig Speicher, geringe Taktrate, schlechter
Speicherzugriff)
5.) es gibt nicht viele Cipher die mit so kurzen Daten umgehen können,
die meisten modernen sym. Cipher arbeiten intern mit 128,256 Bit
Datenblöcken und >= 128 Bit Schlüsseln. Ergo: bleibt wirklich nur der
DES, genaugenommen Single DES 40Bit der zumindestens kryptographischen
Anforderungen genügt, wie Verbreitung, Alter, zur Verfürgung stehenden
Kryptoanalysen usw. DES Feistel Netzwerk ist der Vater aller dieser
Netzwerktypen, mit DES war das die Neuerung vor tja was weiß ich 30-40
Jahren.
Egal wie man es dreht, ansich ist das das System mit dem dem besten
Kompromiss. Exakt das ist die praktische Arbeit die man als Kryptograph
dann erledigt, entgegen dem was man sich wünschen würde was notwendig
wäre.
Gruß
Gehen wir vom 40Bit DES aus dann heist dies:
- weniger als 40 Bit Daten sind Verschwendung
- mehr als 40 Bit an Daten macht es angreifbarer in der Kryptoanalyse
- exakt 40Bit an Daten mit einem 40 Bit Zufallsschlüssel ist das logisch
betrachtete Optimum. Dieses stellt sicher das nicht zu wenige
Informationen aber auch nicht zu viele Informationen übertragen werden.
Also die Aufteilung in 40Bit Zufallsschlüssel und 40Bit Daten ist ideal
und wäre auch meine Wahl gewesen. In den 40Bit Daten müssen 16Bit
Signatur und 22Bit Wetterinformationen rein passen. Das tut es. Der
einzige anerkannte Cipher den ich kenne der mit so kurzen Schlüsseln und
Daten "sicher" zurecht kommt ist Single DES 40Bit.
Also alles eine absolut logische und richtige Wahl die die HKW Designer
hier getroffen haben wenn man von 80Bits ausgeht, ein OTP-like Protokoll
fahren muß weil man Merhfachübertragungen der gleiochen Nutzbits nicht
ausschließen kann um damit die Robustheit des Systemes zu
inkrementieren.
Gruß Hagen
@Walter, kannst du hier ev. mal Antworten. "PIC12F509 hidden features
und "High Flash"
Ich denke nicht, daß es DES ist. Es ist eher FEAL, Skipjack, ... .
Des würde reinpassen, und ca 4.5ms brauchen.
Skipjack z.B. braucht 2.6ms.
Angenommen der Algorithmus wird 41 mal durchlaufen was ja stark sinn
macht.
Ein Watchdog Timeout ist 18ms. Laut Ramdump sind es 15 also 260ms.
Wie lange braucht der Pic um das Ergebnis auszuspucken. (Zeit -
260ms)/41.
Da es 15 Watchdogeinheiten sind, liegt es nahe, daß 1x gerechnet wird,
und dann nach dem WDT die Prozedur 15 mal wiederholt wird, also 16
iterationen. Oder sind es 15 Watchdogeinheiten für jede 41 iterazionen.
Wurde das schonmal getestet (oszilloscop) wieviele Sleep-zyklen
vorhanden
sind. Braucht der decoder unterschiedlich lange bei einem Paket mit und
ohne
Fehlerkorrektur. Wurde der Pic mit der VCC der Uhr ausgelesen ?
20uS Option Initialisierung lässen ca 8 Befele vermuten.
Wenn Du Dir das PDF mal anschaust, kannst Du eigentlich ganz gut sehen,
dass der Algorithmus wie ein DES arbeitet, nur eben mit 40 anstelle von
64 Bit Blockgröße und einem 40-Bit anstelle eines 56 Bit Schlüssels.
Ich habe FEAL uns SKIPJACK nur kurz überflogen und mir sind da keine
Ähnlichkeiten aufgefallen (ausser dass alle Feistel-Runden haben).
Das ganze scheint 41 mal durchgerechnet zu werden. Dafür gibt es zwei
"Zähler": einer enthält ein 8-Bit "Invertier-Muster", der zweite scheint
der Byte-Zähler zu sein (0-4). Am Schluß steht der Zäher auf 5. Es wird
also 40 mal ein Bit invertiert und einmal mit dem Original-Telegram
gerechnet. Dabei wird von Bit 0 bis Bit 39 bei jedem mal ein Bit
invertiert (jemand hatte hier so schön und treffend
"Brute-Force-Fehlerkorrektur" geschrieben).
Der Watchdog bekommt einen Prescaler mit 128 vorgesetzt. Bei ca. 18ms
WDT Grundzeit kommt man auf die 2,3 Sekunden.
Im Strombild ist das auch gut zu sehen.
Der Controller geht in den Sleep und wird durch den WDT-Reset "geweckt".
Dann prüft er anscheinend, ob er vom WDT geweckt wurde (ein wake-up über
Pinchange ist anscheinend auch möglich, da kann man dann das
"Test-Telegramm" schicken). Wenn ja, wird ein Zähler von ursprünglich 15
dekrementiert. Wenn dieser Zähler 0 ist wird ein ggf. Eingeschobenes
Telegramm decodiert (15x 2,3 Sekunden = ca.35 Sekunden, die
"Zwangspause").
Hier habe ich auch angesetzt, um die Wartezeit in Kombination mit dem
RAM Monitor zu verkürzen: ich habe den Zähler auf 1 gesetzt und den
Controller anschließend wieder Schlafen gelegt. Nach dem nächsten WDT
Reset ging der Busy-Pin auf low und ich konnte ein Telegramm
einschieben.
Der Decoder braucht immer die gleiche Zeit, egal, wie das Telegramm
aussieht (in der "Sperrzeit" scheint es ein kleines bisschen anders zu
sein: ein Test-Telegramm braucht ca. 10 Befehle länger, da am Anfang
wohl jedes Byte verglichen wird um festzustellen, dass es sich um das
Testtelegramm handelt. Wenn in der Sperrzeit ein "Nicht-Test"-Telegramm
eingeschoben wird, wird dieses erst ausgenullt, dann wird aber ganz
nochmal gerechnet. Am Schluß wird festgestellt, dass das "Prüfwort"
nicht enthalten ist und eine "Fehlermeldung" ausgegeben. Aber das
Ausnullen braucht auch wieder Zeit...). Der gesammte Decodiervorgang
brauch immer ca. 270 ms.
Der "andere" Chip (EM6580), der in der Mete-On 3 anscheinend
Fehlerkorrektur kann ist ein 4-Biter und hat anscheinend auch einen
anderen Systemtakt. Somit schwer zu vergleichen. Der PIC macht ja im
Prinzip eine Fehlerkorrektur (er rechnet jeden möglichen 1-Bit-Fehler in
den ersten 40 Bit durch) trotzdem funktioniert es nicht (ich, und soweit
ich weiß auch kein anderer hier konnte das erfolgreich testen).
Walter
Danke für die Zusammenfassung.
Ich nahm an, daß der prescaler dem timer zugeordnet war, da die dumps
welche ich überflogen hatte immer dieselben Timerwert anzeigten.
Vorsicht bitte bei den RAM-Dumps für den Bereich 0x00-0x06.
W sichere ich nach 0x33, Status-Register wird nicht gesichert, FSR auch
nicht, brauche ich aber selber - daher nicht der original Inhalt.
Ich verwende das Timer Register als Bit Counter. Daher ist dieser Wert
nicht repräsentativ (s.auch RAM-Monitor im Beitrag #2217744, "PIC12F509
hiden features...").
Der Timer läuft anscheinend nicht im Debug-Modus.
Walter.
e4j89asz schrieb:> Ist das Thema jetzt durch und der Thread geschlossen?
nein, sonst könnte hie keiner mehr Posten.
Es gibt erst mal nichts zu sagen bis irgendjemand neue Erkenntnisse
vorweisen kann.
Das beigefügte Bild zeigt den Silizum Chip des HKW581 Dekoder IC.
Dass es sich bei dem Baustein um einen Chip von MICROCHIP handelt,
läßt sich am Logo rechts oben am Chip-Rand erkennen.
Der größte Teil des Chip ist mit einer Metall-Streifen-Maske bedeckt,
unter der die eigentliche Strucktur versteckt ist. Vermutlich handelt es
sich bei diesem Baustein um die "verbesserte" A-Version des PIC12F509.
Das finden und löschen der CP-Fuse wird durch die Metall-Maske
erschwert.
Zu der Legitimität dieses Angriffes:
Entweder das Geschäftsmodell der Firma basiert auf der Technik, dann
kollidiert es aber mit der Realität, da jeder ja die Daten am Ausgang
des Chips abgreifen kann (oder zur Not vom Display abschreiben kann) und
ins Netz stellen kann, unabhängig davon, ob das Verfahren öffentlich
bekannt ist, oder nicht.
Oder das Geschäftsmodell basiert darauf, dass man Leute die keine Lizenz
zahlen verklagen kann. Das ist ebenfalls unabhängig davon, ob das
Verfahren öffentlich bekannt ist.
Wäre ich "Produktpirat", so würde ich einfach ein paar Exemplare von dem
Chip an eine Spezialfirma geben, die mir die CP-fuse rücksetzen damit
ich einfach den Code auslese. Diesen Code würde ich auf einen identisch
aussehenden Chip packen. Das ist im Vergleich zu den Kosten die die
Spritzform für das Gehäuse kostet, geradezu billig. (Spritzform mehrere
tausend Euro, Fuse rücksetzen bis zu tausend Euro)
Das Knacken des Verfahrens ist eine rein akademische Angelegenheit ohne
reale Konsequenzen. Auch für die Hobbybastler bringt das wenig, da man
die selben Daten woanders her kriegt. (z.Bsp. über den Videotext, Pager,
Internet, etc)
rzjfz schrieb:> Das beigefügte Bild zeigt den Silizum Chip des HKW581 Dekoder IC.> Dass es sich bei dem Baustein um einen Chip von MICROCHIP handelt,> läßt sich am Logo rechts oben am Chip-Rand erkennen.> Der größte Teil des Chip ist mit einer Metall-Streifen-Maske bedeckt,> unter der die eigentliche Strucktur versteckt ist. Vermutlich handelt es> sich bei diesem Baustein um die "verbesserte" A-Version des PIC12F509.> Das finden und löschen der CP-Fuse wird durch die Metall-Maske> erschwert.
Ist ja super! Wo hast du diese Bilder her?
Jo Ka schrieb:> rzjfz schrieb:>> Das beigefügte Bild zeigt den Silizum Chip des HKW581 Dekoder IC.>> Dass es sich bei dem Baustein um einen Chip von MICROCHIP handelt,>> läßt sich am Logo rechts oben am Chip-Rand erkennen.>> Der größte Teil des Chip ist mit einer Metall-Streifen-Maske bedeckt,>> unter der die eigentliche Strucktur versteckt ist. Vermutlich handelt es>> sich bei diesem Baustein um die "verbesserte" A-Version des PIC12F509.>> Das finden und löschen der CP-Fuse wird durch die Metall-Maske>> erschwert.>> Ist ja super! Wo hast du diese Bilder her?
Habe ich bei einem Kollegen machen lassen.
Chris schrieb:> Kennst du das hier ? http://www.bunniestudios.com/blog/?page_id=40
Ja
Johannes O. schrieb:> Ist dein Chip noch funktionsfähig? Die Bondingdrähte scheinen ja noch> dran zu sein.> Hast du schon ne Idee wo die Fuses sein könnten?
Leider wurden bei dem Versuch 2 Bonddrähte am Anschlußbeinchen weggeäzt,
der Baustein ist somit nicht mehr funktionsfähig.
Wegen der Metall-Abdeckung habe ich noch keine richtige Idee wo die
Fuses sein könnten. Hat jemand ne Idee wo sich welche Funktionsblöcke
befinden könnten ?
Es gibt ein Youtube-Video, welches den Software-Dekoder demonstriert.
Das ist zwar nicht wirklich was neues, aber vielleicht ein kleiner
Tropfen auf dem heißen Stein:
http://www.youtube.com/watch?v=gYOoHv3vuOI
-----
Der DCF77Freak
Ich glaube dem Core-Fredie kein Wort!!
Hallo,
ich bin selbst MC-Entwickler und beobachte den Thread von der
Seitenlinie - übrigens nicht um irgend etwas "abzugreifen", sondern aus
Wissensdurst. Aus Zeitgründen kann ich nicht selbst mitmachen. Auch muss
gestehen, dass es hier Leute gibt, die einfach besser sind als ich.
Glückwunsch.
So wie ich das sehe, scheint die Entschlüsselung kurz vor der Vollendung
zu stehen. Oder ist das Werk bereits vollbracht und ich hab‘s überlesen?
Doch nach dem Auftauchen dieses dubiosen Mitglieds der CORE Group
(in deutscher Sprache ???)
scheint die Motivation gegen Null gesunken zu sein. Das Wettkampf
scheint entschieden, warum soll man also weitermachen?
Ich kann nur eins sagen:
Ich glaube dem Core-Fredie kein Wort!! Der hat das (ganz nebenbei)
alleine geschafft und sitzt nun einsam zu Hause und freut sich über den
dummen Rest der Welt.
Ich kenne solche Typen: Da ist kein Gramm Wahrheit dran.
Selbst das Video, das die Datei "DCF-Wetterdecoder.exe" im Einsatz
zeigen soll, steckt voller Ungereimtheiten, auf die ich hier nicht
eingehen möchte.
Ich kann nur alle Beteiligten ermuntern, weiter zu machen. Das Ziel ist
nah.
Weitermachen.
Da hast du was überlesen: Es wurde bereits geschafft die Verschlüsselung
zu knacken.
Meines Wissens nach gibt es aktuell 3 Untergruppen die ihre (jeweils
einige Version) des Codes haben. Denn auch in der Core-Gruppe wurde
bisher kein Programmcode ausgetauscht, d.h. jeder ders geschafft hat,
musste das selbst tun.
Das Video ist übrigens echt, ich sehe keinen Grund weshalb es gefälscht
sein sollte. Zumindest verläuft das Entschlüsseln bei mir ähnlich. Die
Geschwindigkeit ist auch realstisch, der Algorithmus ist ja nicht so
aufwendig.
Johannes O. schrieb:> Meines Wissens nach gibt es aktuell 3 Untergruppen
Und wo sollen diese Gruppen aktiv sein. Etwa hier im Board?
Wie kann man mit denen in Kontakt treten?
>Ich kenne solche Typen: Da ist kein Gramm Wahrheit dran.>Selbst das Video, das die Datei "DCF-Wetterdecoder.exe" im Einsatz>zeigen soll, steckt voller Ungereimtheiten, auf die ich hier nicht>eingehen möchte.
Ich möchte da zustimmen! Ich hab Kontakt mit einigen, die bestätigen das
der Code nicht geknackt wurde. Offenbar kam ein großer Hammer von oben,
der die "CORE Group" in einzellne Körnchen zerbröselt hat. Ist wie in
der NS-Zeit, einfach mal Angst schüren um das Problem zu beseitigen...
Es gab auch zu Adolfs Zeiten welche die ihn toll fanden, oder vom ihm
profitierten. Welchen Vorschlag der Zweifler hatte ich übersehen?
Persönlich glaube ich nicht dran, das Druck gemacht wurde.
Wer es selber knacken will, dem sind hier genug Tipps gegeben wurden um
allein durch Fleiß in absehbarer Zeit ans Ziel zu kommen.
Rein meine Meinung.
@Georg Wichmann: Diese Gruppen sind nicht völlig eigenständige Gruppen,
sondern gehören sozusagen zur "Core-Gruppe" die in einem
(nicht-öffentlichen) Forum aktiv sind. Wie gesagt: Es gibt
Zusammenarbeit, aber dennoch wurde kein Code zwischen den jeweiligen
Teams ausgetauscht. Es besteht auch kein Konkurrenzgedanke oder
ähnliches.
Zum Kontakt: Wenn du Fragen hast, dann schreib sie einfach hier rein!
Sofern es vertretbar ist (Fragen nach Code werden NICHT beantwortet!),
schreib ich dir auch gerne eine Antwort.
Ich selbst gehöre auch einer dieser Gruppen an, wir haben den Code
ebenfalls selbstständig geknackt und das Entschlüsseln klappt bei mir in
100% der Fälle.
@Roffelkartoffel: Dann bist du schlecht informiert und hast falsche
Informationen. Wie geschrieben: Der Code ist geknackt! Und nein, es
wurde bisher nicht mit uns von offizieller Seite her Kontakt
aufgenommen. Es gab also definitiv keine Drohungen/Abmahnungen oder
ähnliches.
@Abdul: Ja das stimmt, die Infos hier sind ausreichend. Bis auf eine
Tabelle (eine Art S-Box) kann man dem kompletten Code allein aus den
öffentlichen Infos hier im Forum herausfinden! Wird zwar relativ
aufwendig, aber defititiv machbar! Nur für die Tabelle braucht man noch
nen original Chip und einige Tricks ;-) (habs ungefähr auf diese Art und
Weise auch selbst durchgeführt!).
An die Zweifler: Was wollt ihr denn noch alles, dass ihr uns mal glaubt?
Es gibt jetzt ein Video, es gibt verschlüsselte (beliebige!) Nachrichten
usw.
(Wichtig: Ich spreche hier NICHT stellvertretend für die sogenannte
"Core-Gruppe", dies hier sind nur meine Ansichten/Meinungen!)
Ich fasse mal zusammen:
Angeblich soll es sein:
1. Es soll 3 Untergruppen geben, die zur "Core-Gruppe" gehören.
2. Diese drei Gruppen sind in nicht-öffentlichen Forum aktiv.
3. Jeder der 3 Sub-Gruppen har die Chiffrierung geknackt.
4. Jeder Teilnehmer der Gruppen musste den Algorithmus selbst
entwicklen, da
5. zwischen den jeweiligen Teams kein Code ausgetauscht wurde.
6. Alle Mitglieder der Gruppen haben sich stillschweigend und freiwillig
auf das ritterliche Ziel geeinigt, Code und Informationen niemals zu
veröffentlichen.
7. Und jojo_2 schreibt: "Zumindest verläuft das Entschlüsseln bei mir
ähnlich". Damit behauptet er, er könne die Daten bei sich entschlüsseln,
obwohl er am 30.07.2011 18:40 noch völlig im Dunkeln tappte und auf der
anderen Seite kein Code zwischen den Gruppen ausgetauscht wurde.
Frage: Und wer soll das glauben?
Antwort: Niemand.
Nicht die zweifler schulden den Beweis, sondern die "Core Gruppe".
Solange kein EXE o.ä. veröffentlicht wurde, gehört die ganze Geschichte
in den Bereich der Fabeln. Schön, dass wir darüber geredet haben.
Und falls der unwahrscheinliche Fall eingetreten sein sollte, dass
tatsächlich einer (und nicht drei Sub-Guppen zeitgleich), also einer das
Ding geknackt hat, dann ist es nur eine Frage der Zeit, dass ihn der
selbstzerfleischende Ergeiz dazu bringt, das Ergebnis online zu stellen.
Alles nur eine Sache der Ehre.
So George für dich nochmal genauer:
1. JEIN. Nicht so genaunehmen mit den 3 Untergruppen. Es hat sich eben
so ergeben: Walther war der erste ders geschafft hatte, danach hats noch
ein(?) anderer geschafft (bin mir nicht sicher ob er hier genannt werden
will) und schließlich ich mit einem anderen Bastler zusammen.
2. Ja. Wenn du dir die Beiträge durchliest, dann dürfte es dir mal klar
werden dass nicht alles hier öffentlich besprochen wird.
3. JEIN. Natürlich musste es einen Durchbruch geben, das waren die
RAM-Dumps bzw. die ganze Methode dazu.
4. ja, wobei der algorithmus an sich eher simpel ist, also viel
"entwickeln" muss man da nicht, es geht eher ums "verstehen".
5. Nur soweit ich weiß. Aber Hinweise, Tipps usw. wurden natürlich
ausgetauscht.
6. Weshalb sollten wir den Code freigeben? Wir sind keine
Script-Kiddies. Würden wir etwas veröffentlichen wäre das SEHR riskant
(rechtlich) und auch für die Meteo-Firma keinesfalls positiv. Und wir
wollen dieser Firma auch nicht schaden!
7. Am 30.07. habe ich nur nachgefragt ob sie beim Löschen der Fuses
schon weitergekommen sind. Wie gesagt: Es liegt uns nicht der
originalcode vor, sondern nur eine eigene Implementation. Es gibt
speziell im Flashbereich von 0 bis über 0x40 aufwärts Code der offenbar
nicht benutzt wird. Was es damit auf sich hat? Eines der ungelösten
Rätsel!
Eine Lauffähige Version meiner Implementierung habe ich schon DEUTLICH
länger (einige Wochen).
G. Wichmann schrieb:> Und falls der unwahrscheinliche Fall eingetreten sein sollte, dass> tatsächlich einer (und nicht drei Sub-Guppen zeitgleich), also einer das> Ding geknackt hat, dann ist es nur eine Frage der Zeit, dass ihn der> selbstzerfleischende Ergeiz dazu bringt, das Ergebnis online zu stellen.
Du scheinst mir der gleiche User zu sein der hier schonmal vor ein paar
Wochen rumgesponnen hat und unbedingt den Code haben wollte?
Wenn du unbedingt Beweise sehen willst: Wäre die nächsten Tage mal in
München. Schreib mir ne PM wann du Zeit hast...
Gäbe es denn rein hypotetisch eine Person, welche einen Briefkasten zur
Verfügung stellt für grüße aus Russland und dann die Sachen
veröffentlicht ?
Ich glaube nicht, bzw kann mich auch irren.
G. Wichmann schrieb:> Alle Mitglieder der Gruppen haben sich stillschweigend und freiwillig> auf das ritterliche Ziel geeinigt, Code und Informationen niemals zu> veröffentlichen.
Dann haben sie den Begriff "Ritterlich" aber sehr eigenwillig
interpretiert. Ritterlich sein bedeutet eigentlich den schwachen zu
helfen. Das zwanghafte geheimhalten des Codes würde ich eher als das
genaue Gegenteil von "Ritterlich" bezeichnen. Denn sie helfen nicht, sie
provozieren nur.
@jojo_2:
Erst mal Danke für die ausführliche Antwort. Ich wollte Dir nicht zu
nahe treten oder Dich angreifen. Ich bin eben ein kritischer
Zeitgenosse. Da ist nichts zu machen.
> Du scheinst mir der gleiche User zu sein der hier schonmal vor ein paar> Wochen rumgesponnen hat...
Nein Sir: Ich spinne nicht, weder heute noch vor ein paar Wochen.
Bitte merken! Auch bin ich hier im Forum weder anonym noch unter anderem
Namen unterwegs.
> ... und unbedingt den Code haben wollte?
Nein, ich will keinen Code haben. Mich interessiert natürlich brennend,
wie es funktioniert. Ein PC-Dekoder für meinen DCF-Empfänger würde
natürlich eine schöne Sache.
Das ist bei mir so rein wissenschaftlich und ohne kommerzielle
Ambitionen. Wenn ich etwas erforscht habe, dann wird es im gleiche
Augenblick uninteressant. Kann man das vestehen? Ich hab schon einige
ähnlich gelagerte Probleme gelöst. Danach wurde das Zeug archiviert und
nie mehr angefasst. Und schon gar nicht vekauft oder weitergegeben. So
bin ich eben.
> Wäre die nächsten Tage mal in München. Schreib mir ne PM wann du Zeit hast.
Würde ich gern machen, aber München ist derzeit so gar nicht auf der
Tagesordnung. Vielleicht ein anderes Mal.
Ich werd mich gelegetlich mal per PM bei Dir melden.
Gruß
Georg
Ich habe leider im Laufe der Zeit auch die 100%ige Übersicht verloren,
es ist Sommer (naja teils), und ich habe einige andere anstrengende
Projekte, die mir viel wichtiger sind, aber ist es nicht so das man den
Beweis jederzeit selbst haben kann, indem man Daten verschlüsselt läßt
durch die mittlerweile zugängliche Software und dann diese Daten in
einen selbszukaufenden und zu verdrahtenden Wetterdatenchip einspeist
und den Klartext wieder rausbekommt? Wozu also ein "Beweis" in Form von
Veröffentlichung?
Es ist kein Beweis für "wir haben diesen Chip geknackt", aber ist der
Nachweis eines äquivalenten Systems!
Johannes O. schrieb:> Würden wir etwas veröffentlichen wäre das SEHR riskant> (rechtlich) und auch für die Meteo-Firma keinesfalls positiv. Und wir> wollen dieser Firma auch nicht schaden!
Nun, CSS, AACS und BD+ wurden auch geknackt und veröffentlicht. Der Code
für CSS wurde damals sogar auf T-Shirts gedruckt verbreitet. Der
wirtschaftliche Schaden für die Filmindustrie dürfte da um einiges
größer gewesen sein als ein hypothetischer Schaden durch Hobbybastler,
die ihre selbst gebaute DCF-Uhr mit ein Paar Wetterinfos aufpeppen
wollen. Und bei anonymer Veröffentlichung wäre das Risiko auch bei Null
anzusetzen.
rzjfz schrieb:> Wegen der Metall-Abdeckung habe ich noch keine richtige Idee wo die> Fuses sein könnten. Hat jemand ne Idee wo sich welche Funktionsblöcke> befinden könnten ?
Bist Du schon weiter gekommen mit den Fuses?
Eine Idee hätte ich. Schreib mir mal eine PM.
Die Frage stellte sich bei CSS, AACS und BD+ aber auch! Auch wenn sie
offensichtlich keiner damals stellte.
Der CCC hat sicherlich ne postalische Adresse. Da muß man nicht in
Berlin hausen.
rzjfz schrieb:> Das beigefügte Bild zeigt den Silizum Chip des HKW581 Dekoder IC.
Noch eine Frage. Wurde der Chip von oben oder unten geöffnet?
Ich hab gerade einige Chips geordert. Es wäre dumm einen Chip zu opfer,
nur weil ich von der falschen Seite rangeht.
Bei CSS u. ä. Sachen war es vertretbar, das zu veröffentlichen. Als
Linux-Nutzer hätte man sonst extreme Schwierigkeiten gehabt, DVDs zu
schauen, die man legal gekauft hatte. Das erschien vielen ungerecht,
deshalb gab es zumindest in der Szene keinerlei Diskussionen, ob man den
Algorithmus veröffentlichen sollte oder nicht.
Bei Meteotime stellt sich das aus meiner Sicht anders dar. Ich habe auch
den Code, aber nicht die geringste Absicht, den zu veröffentlichen.
Interessant war für mich nur, ob (und wie) es gehen würde, den PIC
auszulesen. Antwort: Es geht und ist nach Walthers Vorarbeit nicht so
schwer.
Was bringt der Code? Antwort: Nichts. Man kann bloß die selbe Funktion
in Software nachbilden, die der Chip macht. Wenn man aber die Daten in
einer PC-tauglichen Version haben will, klemmt man einfach einen
Original-Chip aus einer Wetterstation an den PC und liest das Ergebnis
mit den öffentlich bekannten Methoden aus. Das ist eine einmalige
bescheidene Investition und man hat die Wetterdaten digital vorliegen.
Der benutzte Algorithmus ist nicht besonders interessant und noch dazu
hier bereits in groben Zügen vorgestellt worden.
Mit anderen Worten: Es gibt keinen Grund, den genauen Algorithmus
rauszugeben.
Mit der gleichen Logik könnte ich verlangen, daß meine Tchibo-Wetteruhr
AUCH Wetterdaten von Meteotime lesen könnte.
Man ist nicht gezwungen Linux zu nehmen. Selbst wenn es so wäre...
vermutlich wäre das für einen Richter auch uninteressant.
Es bleibt eben ein Restrisiko. Keine Ahnung, ob der CCC dieses
übernehmen würde.
Frank Schrader schrieb:> Bei CSS u. ä. Sachen war es vertretbar, das zu veröffentlichen.
Mir ist es egal ob ihr den Code veröffentlichen wollt oder nicht - aber
macht euch bitte nicht mit solchen idiotischen Argumentation lächerlich!
CSS ist ein Algorithmus der für die Filmindustrie Milliarden wert
gewesen sein dürfte. Ausserdem war das öffentliche Interesse an CSS
sicherlich nicht nur wg. Linux SEHR_HOCH sondern auch deswegen, weil
damit JEDER, weltweit, plötzlich DVDs (natürlich illegal) kopieren
konnte.
Gerade deswegen würde ich sagen ist es unvertretbar gewesen CSS zu
veröffentlichen - man hat damit der Filmindustrie definitiv geschadet
(ob man das gut oder schlecht findet sei mal dahingestellt).
Du vergleichst das mit dem Meteocrypt Alogrithmus, der - wenn überhaupt
- nur innerhalb von Europa von Interesse ist ... und wo wahrscheinlich
kaum jemand weiß, dass Wetterdaten im DCF Signal sind ... und selbst von
denen die es wissen, gibt es vermutlich nicht viele, die das dann
sinnvoll auswerten könnten ...
Daher würde ich behaupten wäre es deutlich vertretbarer den neugierigen
Forenlesern den Algorithmus zu geben - als CSS der Welt in die Hand zu
geben ...
> Als> Linux-Nutzer hätte man sonst extreme Schwierigkeiten gehabt, DVDs zu> schauen, die man legal gekauft hatte.
Was natürlich primär die Frage aufwirft warum jemand was kauft, was er
technisch gar nicht nutzen kann ...
ich denke das hat schon einer geschrieben: Es zwingt niemand die Leute
Linux zu benutzen - es ist eine bekannte Tatsache, dass manche Sachen
unter Linux halt nicht gehen ... Diese Beschränkungen mit illegalen
Mitteln zu umgehen kann's aber eigentlich auch nicht sein!
> Bei Meteotime stellt sich das aus meiner Sicht anders dar. Ich habe auch> den Code, aber nicht die geringste Absicht, den zu veröffentlichen.
dann würde ich euch (die, die den Code haben), einfach drum bitten hier
im Forum nicht mehr zu schreiben! Dann stirbt dieser Thread wie so viele
andere auch ...
Wie ihr schon gemerkt haben dürftet tuen sich andere Leute schwer eurer
Argumentation zu folgen (was evtl. darin liegt, dass sie vielleicht
wirklich etwas "komisch" ist) - wenn ihr immer wieder mit solchen
Argumenten kommt wird das hier nie enden!
Christian H. schrieb:>> Als>> Linux-Nutzer hätte man sonst extreme Schwierigkeiten gehabt, DVDs zu>> schauen, die man legal gekauft hatte.>> Was natürlich primär die Frage aufwirft warum jemand was kauft, was er> technisch gar nicht nutzen kann ...>> ich denke das hat schon einer geschrieben: Es zwingt niemand die Leute> Linux zu benutzen - es ist eine bekannte Tatsache, dass manche Sachen> unter Linux halt nicht gehen ... Diese Beschränkungen mit illegalen> Mitteln zu umgehen kann's aber eigentlich auch nicht sein!
Es ist nicht die Frage, ob mich jemand zwingt, Linux einzusetzen. Es ist
meine freie Entscheidung dies zu tun. Die allgemeine Handlungsfreiheit
ist ein außerordentlich wertvolles Gut und könnte noch mehr Menschen
brauchen, die sich dafür einsetzen.
Es ist auch keine Tatsache, daß manche Sachen unter Linux nicht gehen.
Alles geht unter Linux, sobald dies implementiert ist. Genau dasselbe
gilt übrigens auch alle anderen Betriebssysteme.
Und die Mittel sind auch nicht illegal. Die sogenannte
Rückwärtsentwicklung ist ein rechtlich zulässiges Mittel, um
Interoperabilität und damit einen erwünschten Wettbewerb zu ermöglichen.
Also einmal davon abgesehen, daß die konkreten Aussagen einfach falsch
sind, sind auch die Implikationen widersprüchlich. Es gäbe
beispielsweise keinen Fortschritt in der Softwareentwicklung, wenn
Systeme nicht genutzt würden, nur weil etwas zu einem bestimmten
Zeitpunkt nicht möglich ist.
Ich weiß nicht, ob ich in der Diskussion etwas misverstanden habe, aber
es hat doch keiner geschrieben, daß der CCC den Code veröffentlichen
will. Sie haben nur Interesse daran geäußert, vielleicht nur fürs
Archiv...
Bernhard M. schrieb:> Ich weiß nicht, ob ich in der Diskussion etwas misverstanden habe, aber> es hat doch keiner geschrieben, daß der CCC den Code veröffentlichen> will. Sie haben nur Interesse daran geäußert, vielleicht nur fürs> Archiv...
Äh, soweit ich das sehe hat hier niemand vom CCC "Interesse geäußert".
Hier haben sich nur ein paar Leute vorstellen können, dass der CCC ein
nützliches Werkzeug sein könnte.
Ich sehe spontan nicht, warum der CCC hier von sich aus aktiv werden
sollte. Mal ein neuer geknackter Code ist sicherlich nicht
uninteressant, aber ansonsten ist das doch für irgendein "großes" Bild
total unspannend.
...Man kann den Code ja mal bei Openleaks reinstellen... >:->
Viele Grüße,
Simon
Simon Budig schrieb:> Ich sehe spontan nicht, warum der CCC hier von sich aus aktiv werden> sollte. Mal ein neuer geknackter Code ist sicherlich nicht> uninteressant, aber ansonsten ist das doch für irgendein "großes" Bild> total unspannend.
Sehe ich genauso. Aber der Weg dahin ist spannend, nämlich dass der PIC
trotz Lock-Fuses geknackt werden konnte. Das ist auf jeden Fall auch für
den CCC interessant. Was da letztendlich im PIC an Software drin
steckte, ist dabei nebensächlich.
Frank Schrader schrieb:> Ich habe auch den Code,> aber nicht die geringste Absicht, den zu veröffentlichen.
Es ist doch sehr auffällig:
Wie viele Kollegen hier den "Code" besitzen, obwohl kein Austausch
zwischen den Gruppen stattfand!
Und jeder, der den Code besitzt, soll diesen auch selbst programmiert
haben, mit ähnlich großem Aufwand:
- Hardwarebau eines Spezial-Programmiergeräts
- Programmierung eines RAM-Monitors
- Interfaceschaltung zum Betrieb des RAM-Monitors
- Anfertigen von RAM-Logs
- "intelligentes Erraten" des Algorithmus
usw. usw. usw.
Wenn einer so viel Hard- und Software-Skills besitzt, o.g. Prozedere
durchzuführen, der Rest konnte das sicher nicht. Natürlich habt ihr
untereinander Codes getauscht.
Und nun spielt Ihr Euch zum "Richter Gnadenlos" auf. Erlasst eigene
Gesetze, fühlt euch stark, wissend und mächtig.
Vielleicht habt ihr einfach den Beruf verfehlt. Wärt besser Polizist
geworden. Jedenfalls interessant ist das Phänomen aus psychologischer
Sicht allemal. Kennt man doch den Mechanismus Eurer Projektion nach dem
Motto:
"Ich weiß was, was du nicht weißt. Aber ich sagt nicht. Nie, Ätsch"
Das kenn ich doch irgenwo her, ähm, ähm, wo hab ich das schon erlebt.
Ach ja, jetzt fällt es mir ein.
Das ist lange her. Das war im Kindergarten.
----------------------------------------------------------------
Und nun mal Butter bei de Fische, Tacheles.
----------------------------------------------------------------
Wir, die "Open Secret Group", haben uns am 28.07.2011 formiert und
kommunizieren (natürlich) in einem "nicht öffentlichem Forum" :-).
Unser Ziel ist: Auslesen und Analyse der HKW581-Firmware. Weitere
Projekt sind bereits in Planung.
Stand jetzt haben wir:
- mehrere funktionierende HKW581-Chips und
PIC 12F509-I/P bzw. PIC 12F509-I/SN decapped.
- Spezialhardware für verscheidene Szenarien ist im Bau.
- Zugang zu mehreren Labors (Elektronik, Reflow, Chemie etc.)
- Zugang zu Mikroskopen (inkl IR), Micromanipulators,
Probe Tips, etc.
Wir erwarten, dass der Chip bis Ende September 2011 vollständig
ausgelesen ist. Für die Analyse haben wir einen weiteren Monat
veranschlagt.
----------------------------------------------------------------
Fest steht: Wir werden spätestens am 01.11.2011 unsere Erkenntnisse in
einschlägigen Foren über One-Click-Hoster veröffentlichen werden.
----------------------------------------------------------------
Mag sein, dass Ihr dann noch was lernen könnt, denn in Euren Analysen
sind einige Fragen noch ungeklärt.
;-), stay tuned.
raccoon schrieb:> Und die Mittel sind auch nicht illegal. Die sogenannte> Rückwärtsentwicklung ist ein rechtlich zulässiges Mittel, um> Interoperabilität und damit einen erwünschten Wettbewerb zu ermöglichen.
Aha. Und was für CSS galt, soll für Meteotime nicht gelten? Sorry, aber
das ist eine ziemlich flache Ausrede. Bei Meteotime ruft ihr alle: Kauft
euch einen Chip und baut den ein. Was wäre gewesen, wenn man allen
Linuxusern bei CSS nur gesagt hätte: Kauft euch Windows und installiert
das. Das die Filmindustrie gar nicht wollte das DVDs unter Linux
angesehen werden und durch den Hack gewaltige Verluste erlitten hat, hat
niemanden interessiert. Und jetzt mach ihr so ein Theater um einen
Algorithmus dessen Schadenspotential bei Veröffentlichung nahe Null
läge? Wo bleibt da die Logik?
S. Dinger, Open Secret Group schrieb:> Unser Ziel ist: Auslesen und Analyse der HKW581-Firmware. Weitere> Projekt sind bereits in Planung.
Kaum zu glauben, wie Arbeitsbereit doch das Gefühl macht, ungerecht
behandelt zu werden ;-) Aber immerhin: DAS ist ein Ansatz, anstatt der
ewigen Meckerei. Auch wenn ich da einen Hauch von "Ich will aber,
menno!" verspüre, wenn jetzt schon der Kindergarten zitiert wird - SCNR
Davon abgesehen, mit dem Spaß dürfte es dann wohl vorbei sein, denn
einen ungezwungenen und stressfreien Prozess wie er hier über Jahre (!)
stattgefunden hat, werdet ihr auf diese Weise nicht erreichen - und der
war mir als (passiver) Leser viel mehr Wert als das Resultat zu sehen.
Ich bin jedenfalls gespannt, wie groß das Interesse an eurem Code sein
wird - so es jemals dazu kommt.
Thomas Karge schrieb:> Aha. Und was für CSS galt, soll für Meteotime nicht gelten? Sorry, aber> das ist eine ziemlich flache Ausrede. Bei Meteotime ruft ihr alle: Kauft> euch einen Chip und baut den ein. Was wäre gewesen, wenn man allen> Linuxusern bei CSS nur gesagt hätte: Kauft euch Windows und installiert> das. Das die Filmindustrie gar nicht wollte das DVDs unter Linux> angesehen werden und durch den Hack gewaltige Verluste erlitten hat, hat> niemanden interessiert. Und jetzt mach ihr so ein Theater um einen> Algorithmus dessen Schadenspotential bei Veröffentlichung nahe Null> läge? Wo bleibt da die Logik?
Vergiss es. Ihr kommt so nicht weiter.
Ich habe mir dieses Spielchen bereits vor Wochen angetan und mich auch
geärgert, was dies wohl soll.
Irgendwas scheint die Leute bewogen zu haben, so abzumauern. Was das
war, weiß ich nicht. Einen solchen Kleinbetrieb vor dem Bankrott zu
bewahren, ist es sicherlich nicht.
Wenn ich selbst so eine Uhr bauen wollte, würde ich garantiert keinen
fremden IC drin haben wollen. Selbst ist der Elektronikfan. Ein Glück,
dass ich so keine Uhr brauche. Mir wären die Wetterdaten sowieso zu
ungenau.
> Und jetzt mach ihr so ein Theater um einen> Algorithmus dessen Schadenspotential bei Veröffentlichung nahe Null> läge?
Der Schaden liegt bei exakt 0 Euro und 0 Cent, da der Algorithmus
nicht geknackt wird. Ganz einfach.
Es wurde noch nichts geknackt, auch wurde kein funktionierender Code von
jemandem privatem geschreiben. Das fake Video erstellt jeder der will
das ist keinerlei Beweis.
VORSCHLAG:
Mach doch die Gegenprobe und stelle ein paar verschlüsselte Daten hier
rein welche in der Zukunft liegen und fantasie Wetterdaten enthalten
welche dann hier vom Originalchip decodiert werden können.
Hier will nur jemand das ihr aufhört, das ist alles. Lasst euch dadurch
nicht aufhalten !
Ich verstehe jetzt nicht, wieso jeder den Code haben will.
Meteotime ist für den laufenden Betrieb uninteressant.
- Die Vorhersagen sind zu ungenau (zu großes Raster)
- Die Wetterdaten werden nur selten aktualisiert.
- Man braucht Zusatzhardware (modifizierte Wecker oder Funkuhrempfänger)
Es gibt viele freie Wetterinformationen im Internet.
- Sie haben ein sehr feines Ortsraster (ja, auch Vororte sind aufgeführt
und haben andere Werte als der 5km entfernte Hauptort).
- Sie aktualisieren teilweise stündlich.
- Sie sind kostenlos.
- Sie sind ohne Programmieraufwand direkt im Browser einsehbar.
- Sie sind mit kleinem Programmieraufwand in jedem selbtgeschriebenen
Programm verwendbar.
Und nein, ich habe weder die S-Boxen noch den Code.
Mir reicht aus, dass ich weiß, wie der Code funktioniert - und das wurde
hier bereits veröffentlicht.
Wer unbedingt einen DES-Code sehen will. Hier gibt es den
DES-Algorithmus in mehreren Programmiersprachen:
http://www.tero.co.uk/des/code.php
Das ist der unmodifizierte Algorithmus und nicht der von Meteotime!
G. Wichmann schrieb:> rzjfz schrieb:>> Das beigefügte Bild zeigt den Silizum Chip des HKW581 Dekoder IC.>> Noch eine Frage. Wurde der Chip von oben oder unten geöffnet?>> Ich hab gerade einige Chips geordert. Es wäre dumm einen Chip zu opfer,> nur weil ich von der falschen Seite rangeht.
Der Chip wurde ganz normal von oben geöffnet.
Bei der Suche nach Fuses gibt es noch nichts neues.
Abschleifen oder wegätzen der obersten Metallschicht
wäre ein möglicher Weg, allerdings habe ich dazu nicht die
Möglichkeiten.
Ausserdem wären dann wahrscheinlich die Bond-Drähte weg, so dass dann
auch Micronadel zur Kontaktierung notwendig werden, um den Chip auslesen
zu können.
*KOPFSCHÜTTEL* schrieb:> Ich verstehe jetzt nicht, wieso jeder den Code haben will.
Also ich brauche den Code nicht zum Leben :). Es geht auch eigentlich
mehr ums Prinzip bzw. die Gründe, warum die Leute so grob gegen die
Hackerethik verstoßen.
*KOPFSCHÜTTEL* schrieb:> Meteotime ist für den laufenden Betrieb uninteressant.
Da kann man geteilter Meinung sein.
> - Die Vorhersagen sind zu ungenau (zu großes Raster)> - Die Wetterdaten werden nur selten aktualisiert.
Da gebe ich dir allerdings Recht.
> - Man braucht Zusatzhardware (modifizierte Wecker oder Funkuhrempfänger)
Nein. Mit dem Algorithmus bräuchte man eben KEINE Zusatzhardware mehr.
Das könnte dann der ohnehin schon in der Selbstbau-DCF-Uhr vorhandene
Prozessor mit übernehmen.
*KOPFSCHÜTTEL* schrieb:> Ich verstehe jetzt nicht, wieso jeder den Code haben will.
Weil die dann was haben was andere nicht haben.. Kneipengelalle "Du
weisst Du was ich habe... blah und Co" Nur dafuer, fuer nichts anderes
braucht man den. Fuer 9,95 gibt es den ganzen Wecker, da dremelt man
sich den Chip raus und schon kann JEDER decodieren.
Die hier ankommen und angeblich an der Funktionsweise interesse haben,
haben von diesen Threads hier NICHTS, aber auch rein ganrnichts
verstanden.
Und "seltsamerweise" wieder alles Gaeste.
Peter W. schrieb:> Kneipengelalle "Du> weisst Du was ich habe... blah und Co"
Das ist genau das Benehmen derer, die den Code angeblich haben.
> Fuer 9,95 gibt es den ganzen Wecker, da dremelt man> sich den Chip raus und schon kann JEDER decodieren.
Klar. Das hat ja auch niemand bestritten. Nur: Darum geht es gar nicht.
Wer sich ein Gerät selbst baut der will im allgemeinen keine fremden
Chips darin haben, sondern alles selbst machen. Nun kommen sicher gleich
wieder das Argument, fremde Arbeit ausnutzen zu wollen und man solle es
doch gefälligst selbst herausbekommen. Das Argument zieht aber nicht,
denn dieser Argumentation folgend könnten z.B. beinahe keine
PC-Programme mehr geschrieben werden, denn auch da wird von der Arbeit
anderer profitiert. Ohne die Librarys und Funktionen, die tausende
anderer schon erarbeitet haben würde da gar nichts mehr laufen...
Thomas Karge schrieb:> Peter W. schrieb:>> Kneipengelalle "Du>> weisst Du was ich habe... blah und Co">> Das ist genau das Benehmen derer, die den Code angeblich haben.
Noe, denn die posaunen ja hier nicht rum , ich habe und blah... Im
Gegenteil hier werden, naja, es wurden sogar noch Tips abgegeben wie man
selbst drauf kommen kann. Statt da weiter zu machen wollen alle gleich
das fertige Produkt, kostenloas, schnell und mit deutscher Doku.
Ich werde meine e-mail-Benachrichtigung jetzt abschalten, denn dieses
Thread mit solcher Argumentation interessiert mich weniger als 0 und
finde ich mehr als arm.
@Thomas Karge:
da muß ich Dir Recht geben.
Ich war bisher eigentlich total dagegen, den Code zu veröffentlichen.
Auch die Moderatoren hier bitten immer wieder darum, nichts von den
"Kerndaten" zu veröffentlichen. Ich kenne mich da rechtlich nicht aus.
Der Hype um diesen Code ist wikrlich übertrieben.
Aber die Argumente stimmen schon, ein wirklicher Schaden wird damit
sicher nicht angerichtet werden und wenn ich mir eine Uhr selber bauen
will, dann will ich es auch "komplett" selber schreiben/bauen, das kann
ich nachvollziehen. Ein komerzieller Nachbau einer Wetterstation ist ja
wohl nicht wirklich möglich...
Ich findes aber schön, dass sich anscheinend jemand weiteres hat
motivieren lassen und wieder einen neuen Weg gehen will um dem PIC sein
"Geheimnis" zu entreissen. Bin gespannt, was rauskommt (das meine ich
ehrlich).
Kennt sich denn hier jemand rechtlich damit aus ? Also so wirklich,
nicht rein nach "Bauchgefühl" ?
Der erste Thread wurde ja anscheinend geschlossen, um eine scheinbar
bevorstehende Veröffentlichung zu verhindern...
Wie sehen das denn die Mods ? Ob Meteotime damit ein Problem hat, wenn
wir Bastler und die Stationen selber bauen ?
So: es darf wieder geschossen werden.
Walter.
PS: hat sich eigentlich schon mal jemand TMCpro angeschaut ? Ist das
wirklich verschlüsselt ? Ich hab mir schon mal nen Empfänger
geordert...;-)
Aber das Verfahren wurde doch schon detailiert erklärt oder sehe ich das
falsch ?
Das ist für mich eben die Frage. Soweit ich weiß hat es bisher einer
geschafft, den Code wirklich aus dem Controller zu holen. Andere haben
die Funktionsweise mit Hilfe eines RAM Monitors ermittelt. Der Code, der
daraus enstanden ist entstammt also der "Feder" des jeweiligen
"Interessierten" und da ist ja wohl mal kein Urheberrecht drauf (also
einen kenne ich zumindest...;-) Der Code, der veröffentlicht werden
würde wäre sicher nicht das Problem - es geht eher um das ganze System.
Walter Freywald schrieb:> Der Code, der> daraus enstanden ist entstammt also der "Feder" des jeweiligen> "Interessierten" und da ist ja wohl mal kein Urheberrecht drauf (also> einen kenne ich zumindest...;-) Der Code, der veröffentlicht werden> würde wäre sicher nicht das Problem - es geht eher um das ganze System.
Das Urheberrecht am entstandenen Code hat natürlich immer derjenige, der
den Code selbst geschrieben hat. Nur weil ich Code schreibe, der auch
dieselbe Funktion erfüllt, die in einem anderen Recher (wie dem
Wetter-IC) implementiert ist, heißt das nicht, dass mein eigener Code
plötzlich dem Urheber des anderen Rechers gehört.
Unabhängig davon kann allerdings die kommerzielle Verwendung, auch von
eigenem Code, durch Patente usw. möglicherweise erst durch Erhalten
einer Lizenz legitim werden.
Aber der Code selbst kann nicht geschützt sein. Das wäre dann das Thema
Softwarepatente und die gibt es, nach meinem Kenntnisstand, in
Deutschland nicht.
Hey Leute,
endlich mal was los im Thread.
Da kriegt die Altherrenliga mit ihrem Herrschaftswissen mal eins aufs
Dach. Wunderbar!
Den Ruhm wollen offenbar andere ernten.
Walter Freywald schrieb:> Soweit ich weiß hat es bisher einer> geschafft, den Code wirklich aus dem Controller zu holen.
Aha, also doch. Wußte ichs doch.
S. Dinger, Open Secret Group schrieb:> Wir, die "Open Secret Group", haben uns am 28.07.2011 formiert und> kommunizieren (natürlich) in einem "nicht öffentlichem Forum" :-).
Super Idee. Ich bin dabei. Könntest Du dich mal bei
"mikrocontroller.net" anmelden und mir eine PM schicken. Ich würde gern
bei Eurer Gruppe mitmachen. Hoffentliche seid Ihr nicht auch so ein
Geheimbund wie die Experten hier im Thread.
Mario M. schrieb:> Ich bin jedenfalls gespannt, wie groß das Interesse an eurem Code sein> wird - so es jemals dazu kommt.
Es spielt überhaupt keine Rolle, wer sich für das Projekt interessiert.
Wichtig ist, dass es durchgeführt wird.
rzjfz schrieb:> Der Chip wurde ganz normal von oben geöffnet.> Bei der Suche nach Fuses gibt es noch nichts neues.
Ich fragte deswegen, weil es auch MSOP-Chips gibt, wo der Die (also der
Chip selbst) anders herum eingebaut wird.
Zu Deinem Chip: Es gibt verschiedene Attack-Szenarien wie man den Chip
auslesen kann. Diese Techniken kann ich hier öffentlich nicht
diskutieren.
Nur soviel: Bei Chips mit mittlerer Komplexität und mittlerem
Scurity-Level (wie hier) liegen die Fuses in der Regel nicht im EEPROM.
Will man z.B. eine UV-Attack starten, kommt es nicht darauf an, die
Fuses zu lokalisieren, sondern den EEPROM-Bereich zu schützen.
Ich habe in Dein Chip-Photo (attached) die Bereiche eingezeichnet, die
vermutlich das EEPROM und den Microcode enthalten. Letzterer ist aber
UV-resistent. Das ist nur eine Vermutung, denn die Metallmaske soll
verschleiern.
Von anderen Methoden, wie das "Abschleifen oder Wegätzen der obersten
Metallschicht" würde ich im ersten Schritt abraten. Der Chip ist schnell
futsch. Es sei denn Du hast Zugang zu Universitätslabors und
entsprechende Kenntnisse.
Auch an Dich die Bitte:
Bitte bei "mikrocontroller.net" anmelden (anonyme Hotmail, gmx E-Mail
genügt) und mir eine PM schicken. Ich glaube, ich kann Dir helfen.
Und noch ein Wort zu meiner Geheimniskrämerei:
Gern werde ich alle Erkenntnisse, soweit vertretbar, veröffenlichen.
Aber nicht den genauen Weg dorthin. Deswegen auch keine Angaben zu
Angriffsmethoden. Das ist ja auch nicht Thema des Threads.
@George33: Ich denke das Bild ist ziemlich falsch:
Der PIC besitzt KEIN EEPROM!
Was du markiert hast dürfte der Flashspeicher (und evtl. der SRAM?)
sein.
Ich würde auf Flash tippen, der SRAM ist mit den paar Byte die er hat
deutlich kleiner und dürfte kaum sichtbar sein. Auch wenn es 2 Teile
sind: Es könnte durchaus sein dass der Flash so aufgeteilt ist. Man muss
bei bestimmten Sprüngen/Befehlen ja auch ein bestimmtes Bit setzen,
falls das Sprungziel in der oberen Hälfte liegt oder so.
Walter Freywald schrieb:> PS: hat sich eigentlich schon mal jemand TMCpro angeschaut ? Ist das> wirklich verschlüsselt ? Ich hab mir schon mal nen Empfänger> geordert...;-)
Ja, ich. Ist jetzt auch schon wieder zwei Jahre her...
Die Verschlüsselung ist ziemlich Banane und ich habe damals eine Attacke
gefunden, die mir die Suche nach dem Schlüssel erleichtert hat. Ich habe
jedenfalls den damals verwendeten Schlüssel rausbekommen, wobei der aber
so selten gewechselt wird (wenn überhaupt), so dass ich nicht die
komplette Tabelle habe...
Aber das gehört dann mal in einen anderen Thread :)
Viele Grüße,
Simon
Johannes O. schrieb:> @George33: Ich denke das Bild ist ziemlich falsch:
Man, was harte Geschütze. Nun ist gleich das Bild "ziemlich falsch", nur
weil die Terminologie ungenau ist.
Natürlich ist es kein klassisches "EEPROM" sondern ein "Flash EEPROM".
Aber ein Flash Memory ist eben auch ein EEPROM (= Ectrically Erasable
Programmable Read-Only Memory). Zu Deutsch: Elektrisch löschbarer (u.
wieder) programmierbarer Nurlesespeicher.
Sonst gibt es aber keine Probleme, oder? Wir wollen doch keine Haare
spalten oder.
Johannes O. schrieb:> Es könnte durchaus sein dass der Flash so aufgeteilt ist. Man muss> bei bestimmten Sprüngen/Befehlen ja auch ein bestimmtes Bit setzen,> falls das Sprungziel in der oberen Hälfte liegt oder so.
Nein, die Chipdesigner splitten das "Flash EEPROM" nicht. Da wäre die
Ansteuerung (2*) viel zu aufwendig. Außer der Chip besitz ein
zusätzliches "Flash EEPROM" zum Ablegen von Programmdaten. Das wäre dann
ein zweiter "Flash EEPROM"-Block. Das hat der 12F509 aber nicht.
Deine Erwähnung mit den Bits und Sprüngen spielt sich nicht im "Flash
EEPROM" ab. Dort steht nur das Programm, das aus 12-bit Worten besteht.
Das ist so: Im "Flash EEPROM" stehen 1024*12-bit Worte. Das ist das
Programm. Addressiert mit dem "Programm Counter" wird ein Wort ins
"Instruction Register" geladen. Das sind auch immer 12 bit.
Von diesem Wort werden die niederwertige 5 bits als Adressierung
abgespalten und die 8 höherwertigen bits werden dann im "Instruction
Decode and Control" - nennen wir das mal Microcode - ausgewertet. Oder
die höherwertigen 8 bits werden der per MUX (Multiplexer) der ALU
(Arithmetical and Logical Unit) als Literal field (Operand) zugeführt.
Kann man übrigens im Datenblatt ("41236E.pdf") Seite 12 inder Grafik
wunderbar sehen.
Das SRAM ist mit 41 Bytes sehr klein. Das kann keiner der großen Blöcke
im Bild sein.
PS:: Ich hoffe, dass ich nun die richtige Terminologie benutzt habe;-).
Das unten sieht nach unbenutzen Platz aus als Folge von die shrinking.
Oben ist das Flash, daneben der Microcode.
Die Langen mit Metall bedeckten Flächen müssten die Fuses sein.
Ps: Wenn du den Artikel gelesen hättest, dann wüsstest du daß es ohne
das Metall wegätzen geht, einfach ... , aber les den Artikel nochmals.
Walter Freywald schrieb:> Kennt sich denn hier jemand rechtlich damit aus ? Also so wirklich,> nicht rein nach "Bauchgefühl" ?
Es müsste sich primär mal auf StGB §202a rauslaufen
> Ausspähen von Daten> (1) Wer unbefugt sich oder einem anderen Zugang zu Daten, die nicht> für ihn bestimmt und die gegen unberechtigten Zugang besonders gesichert> sind, unter Überwindung der Zugangssicherung verschafft, wird mit> Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft.
Diese Wetterdaten sind nicht für die bestimmt, die sie ohne lizenzierten
Chip auslesen wollen ... die Daten sind vor unberechtigten Zugang mit
einem Algorithmus geschützt der nicht öffentlich bekannt ist ... und die
Überwindung der Zugangssicherung, nun ja, da fällt dann wohl z.b. das
Revers-Engeneering drunter.
Dazu kommt dann noch
> §202c - Vorbereiten des Ausspähens und Abfangens von Daten
was auch mit einem Jahr Freiheitsentzug bestraft werden kann ...
Es gibt dann noch ein paar Sachen rund um den Urheberschutz die hier
vermutlich zur Anwendung kommen könnten. Ich weiß im Moment leider nicht
ob es hier irgendwelche Patente gibt - wenn ja, hätte man hier die
nächsten Rechtsverletzungen.
Also es sollte sich niemand was vormachen, das "öffentliche Interesse"
mag hier nicht hoch sein, der potentielle wirtschaftliche Schaden
gering... gegen bestehende Gesetze wird aber auf jeden Fall verstoßen
...
Das ist UNFUG !
Zwei Paragraphen lesen und meinen sich mit dem Gesetz auszukennen. Es
ist NICHT verboten Daten, egal welcher Art abzufangen, aufzuzeichnen, zu
entschluesseln und so weiter. Sonst waere es schon verboten einen
Videorecorder zu besitzen.
chris schrieb:> Das unten sieht nach unbenutzen Platz aus als Folge von die shrinking.
Unbenutzer Platz auf einem Chip? Wohl eher nicht.
chris schrieb:> Oben ist das Flash, daneben der Microcode.
Das ist zu klein für den Microcode. Ist eher die Ansteuerung des Flash
bzw. die Ladungspumpen. Im Vergleich: bei anderen MCs ist der Bereich
des microcodes etwa so große wie der des Flash.
Gustavson. schrieb:> Es wurde noch nichts geknackt, auch wurde kein funktionierender Code von> jemandem privatem geschreiben. Das fake Video erstellt jeder der will> das ist keinerlei Beweis.>> VORSCHLAG:> Mach doch die Gegenprobe und stelle ein paar verschlüsselte Daten hier> rein welche in der Zukunft liegen und fantasie Wetterdaten enthalten> welche dann hier vom Originalchip decodiert werden können.>> Hier will nur jemand das ihr aufhört, das ist alles. Lasst euch dadurch> nicht aufhalten !
Dann nenne mir ein paar Wetterdaten und Uhrzeitdaten, die du gerne
verschlüsselt haben möchtest
also 22 Bit Wetterdaten, und 40 Bit Uhrzeitdaten. von mir kriegst du
dann die 82 Bit daten.
Egal was es ist.
Und es wurde Code ausgetauscht, ich habe den von Walter bekommen.
Jedoch weiß ich von mindestens 3 Entwicklungen, die selbst entwickelt
wurden.
Gruß
Thomas
Ichbins schrieb:> Zwei Paragraphen lesen und meinen sich mit dem Gesetz auszukennen. Es> ist NICHT verboten Daten, egal welcher Art abzufangen, aufzuzeichnen, zu> entschluesseln und so weiter. Sonst waere es schon verboten einen> Videorecorder zu besitzen.
Welchen Beleg führst du für deine Behauptung an?
Dein Videorekorder Beispiel ist hier leider nicht angebracht, weil hier
nichts "verschlüsselt" oder "geschützt" ist - außerdem darf man davon
ausgehen, dass die normale Nutzung im Sinne der Sender ist - sonst
würden sie was dagegen machen - oh, machen sie neuerdings ja, HD+ ...
Außerdem wäre mit deiner Argumentation z.B. das Schwarzsehen von Sky
legal - ich hoffe es ist auch hier im Forum, und speziell bei dir,
anerkannt, dass dem (leider) nicht so ist.
Tobias Geringer schrieb:> Welchen Beleg führst du für deine Behauptung an?
Nur den, dass es eben nicht reicht, mal kurz in irgendein Gesetzbuch zu
gucken.
Thomas Berends schrieb:> Und es wurde Code ausgetauscht, ...
Na da kommt die Wahrheit langsam ans Licht, wenn auch scheibchenweise.
Walter Freywald schrieb:> Soweit ich weiß hat es bisher einer geschafft,> den Code wirklich aus dem Controller zu holen.
Und wer von Euch wäre dann so nett, mir das Imagefile für meine
Untersuchungen zur Verfügung zu stellen.
Ich meine, ich bekomm das File auch selbst aus dem Chip.
Das wär ein paar Tage Arbeit und wirklich unnötig.
Mehr will ich gar nicht.
Soweit ich mich erinnere, wurde bereits ein unzulässiger String
verschlüsselt. Einer der zwar algorithmisch zulässig ist, aber nicht im
Sinne der Nutzdaten von Meteotime.
Weiß nur nicht mehr in welchem Thread. Walter hatte das wohl gepostet.
31.02.x wäre ein nettes Datum.
Zum Recht: Das legt das Gericht aus. Viel Spaß.
Ichbins schrieb:> Nur den, dass es eben nicht reicht, mal kurz in irgendein Gesetzbuch zu>> gucken.
oh - na dann ...
Aber vertrau mir, ich kenn mich in dem Bereich gut genug aus: "Ausspähen
von Daten" StGB §202, "Erschleichen Leistungen" StGB §265, "Unerlaubte
Verwertung" UrHG §106, etc. sind in diesem Bereich die
Standardparagraphen bei dearartiger Thematik.
@Abdlul K.
Ja, die Gesetze werden von den Gerichten ausgelegt - das ist in manchen
Fällen schwerer als in anderen. Grad im Bezug auf StGB §202 und §265
muss hier aber nicht viel ausgelegt werden, das ist eher offensichtlich
- Auslegungsbedarf besteht bestenfalls beim Strafmass, was dann wieder
die Frage nach dem öffentlichen Interesse und dem Schaden aufwirft.
Thomas Berends schrieb:> Dann nenne mir ein paar Wetterdaten und Uhrzeitdaten, die du gerne>> verschlüsselt haben möchtest
Berliner Regionscode
24.12.2013 20:15
Tageshöchstwert 35°C
Tieftsttemp -40°C
Regenwarscheinlichkeit 90%
Wind N höchste Stärke
Wolkig mit Gewitter
20.08.2015
Tageshöchstwert -10°C
Tieftsttemp +40°C
Regenwarscheinlichkeit 10%
Wind S höchste Stärke
Wetter klar
Hallo,
Das was du vor hast geht so nicht. Ich benötige die 22 Bit (und 40 Bit
Schlüssel, alias Uhrzeit), da die Wetterdateninterpretation selbst
(höchst Tiefstwerte, Wind oder Regen) Interpretationsabhängig sind.
Um die Regionscodes zu berechnen gibt es die formel, hier als Funktion
ausgedrückt:
1
//Ermittelt den Aktuellen Datensatz (zwischen 0 und 479)
intforecastType90=(int)Math.Floor((setNumber()-420)/30d);//Erst gültig wenn setNumber >=420
Das muss eingehalten werden, alles andere ergibt nicht Interpetierbare
Wetterdaten.
Außerdem habe ich keine Lust die ganze Sache ausnnaner zu frickeln.
PS:
Kann auhc eine Datei mit mehreren Hundert Datensätzen sein.
Den 2. Datensatz, das sind 2 stück, den werde ich nun zusammenfrickeln,
aber das darüber, mit dem Berliner Code und der genauen Zeitangabe geht
so nicht.
Thomas Karge schrieb:> Wer sich ein Gerät selbst baut der will im allgemeinen keine fremden> Chips darin haben, sondern alles selbst machen.
Aha, also alle Bauteile selber dremeln?
Na da haben wir doch dann die nötige Begründung. Mehr brauchts nicht.
Öffentliches Interesse kann man bei der Vielzahl der Teilnehmer hier,
annehmen.
<ich wiederhole mich>
Ich habe mal ein Frage
bezüglich der Interpretation der dechiffrierten Wetterdaten.
Wahrscheinlich wurde das schon beantwortet, ich konnte aber weder in den
Threads noch im Dokument "DB_W-Protokoll-V_1.pdf" ein Antwort finden.
Wie kommt es dass in den DCF-Logs z.B.:
OUT: - Tag: 0100 2 2 - leicht bewölkt
- Nacht 1010 5 11 - Wärmegewitter !!!!!
oder
OUT: - Tag: 0110 6 9 - starker Regen !!!!!
- Nacht: 1100 3 3 - vorwiegend bewölkt
die Werte 5 als 11 bzw. 6 als 9 interpretiert werden?
Was habe ich übersehen? Kann jemand helfen?
Die erste Zahl gibt den Dekodierten Wert an,
die 2. Zahl ist die, die im HKW-Dokument für die Vorhersagen verwendet
wird.
Aus irgendwelchen gründen weicht das gesendete von den Spezifikationen
von HKW ab. Aus diesem Grund sind dort beide werte Angegeben.
Wobei das mittlerweile eigentlich überflüssig ist, und aus den
Logdateien entfernt werden kann.
Ich habe mir da Folgende Arrays angelegt:
1
string[]mStringArrForecast={" 0 - --",
2
" 1 - klar",//Bei Tag " 1 - sonnig"
3
" 2 - leicht bewölkt",
4
" 3 - vorwiegend bewölkt",
5
" 4 - bedeckt",
6
" 5 - Hochnebel",
7
" 6 - Nebel",
8
" 7 - Regenschauer",
9
" 8 - leichter Regen",
10
" 9 - starker Regen",
11
"10 - Frontengewitter",
12
"11 - Wärmegewitter",
13
"12 - Schneeregenschauer",
14
"13 - Schneeschauer",
15
"14 - Schneeregen",
16
"15 - Schneefall"
17
};
18
19
//Und zum übersetzen der Gesendeten Daten in die Vorhersagen:
Ich hab heute eine PM bekommen, wahrscheinlich wortgleich auch an
andere. Etwas unverfroren, deswegen poste ich diese hier:
-----------------------------------------------------------------------
Hallo,
ich baue seit 3 Monaten an einer Wetterstattion über DCF77. Funkuhr geht
schon und an den Wetterdaten arbeite ich auch schon. Ich habe mir sogar
auch schon einen HKW581 aus eine Kauf-Wetterstation ausgelötet.
Allerdings hab ich ihn wohl beim Löten gegrillt, da es eine sehr kleines
S08-Gehäuse ist.
Ich verfolge hochinteressiert die aktuelle Diskussion über den
geknackten Meteotime-Code.
Da ich weiter an meiner Wetterstation bauen möchte und eher an einer
SW-Entschlüsselung interessiert bin als dies über den HKW zu tun, frage
ich dich, ob du mir behillich sein kannst.
Ich möchte nicht den fertigen Code präsentiert bekommen, sondern sehe es
ähnlich wie im Forum angesprochen, dass ich die Dekodier-Regeln wissen
muss, um den C-Code dann selber zu schreiben.
Bin ich bei dir richtig?
-----------------------------------------------------------------------
Mein Kommentar:
>Bin ich bei dir richtig?
NEIN !
> ich baue seit 3 Monaten an einer Wetterstattion über DCF77.
Schade um die Zeit.
> Ich habe ... einen HKW581 ... ausgelötet.> Allerdings ... beim Löten gegrillt
Hey, das mit dem Löten kann man lernen, ganz bestimmt.
Aber was möchtest Du mir damit sagen. Ist das Grillfest ein Grund für
Irgendwas?
Außerdem wäre es besser gewesen, den Chip in der Wetterstation zu
lassen. Dann hättest Du genau das, was Du seit 3 Monaten bauen möchtest.
> Da ich ... eher an einer SW-Entschlüsselung interessiert bin als> dies über den HKW zu tun ...
Die Entschlüsselung per HKW ist der richtige Weg, auch lizenzrechtlich.
> ... dass ich die Dekodier-Regeln wissen muss, um den C-Code> dann selber zu schreiben.
Die Dekodier-Regeln muss man nicht wissen. Und falls doch, na das steht
doch alles in den postings oben.
> Ich möchte nicht den fertigen Code präsentiert bekommen
Den gibt Dir auch niemand. Man kann es ja mal probieren.
Diese Mail habe ich auch bekommen, hätte ich das gewusst, hätte ich gar
nicht erst geantwortet, also das nenn ich jetzt mal ne dreiste Masche so
an den Code ran zu kommen, nach drm Motto vielleicht gibt mir ein Idiot
ja den Code,
Ich sach mal so:
WIR SIND HIER NICHT IM KINDERGARTEN!!!
Was soll der Unsinn...
Sorry wenn ich jetzt etwas schroff reagiere, aber der Absender der Mail
sollte sich das mal zu Herzen nehmen.
Gruß
Thomas
Vielleicht hilft es ja, das Lied "I Engineer" von Animotion rückwärts
anzuhören. Ich denke mal privates Reverse-Engineering ist nicht
verboten. Auch die öffentliche Diskussion hier im Forum ist unkritisch.
Nur wenn jetzt jemand ohne Lizenz Wetterstationen nachbaut und verkauft,
dann hat er ein Problem.
Andernfalls dürfte man sich auch nicht mit Bluetooth oder MP3
auseinandersetzen.
Und wegen 14 Byte Wetterdaten, die sich einer privat aus dem DCF-Signal
filtert, jetzt wegen Uhrheberrecht (!) anzukommen ist extrem lächerlich.
Hab diese Mail auch bekommen... Und leider freundlich geantwortet.
Geschrieben hab ich, dass er es sein lassen soll, außer er hat seeeehr
viel Zeit und Geduld. Für seine 1 Wetterstation tut er sich doch
leichter wenn er direkt den Chip hernimmt.
Und keiner braucht mir erzählen dass er zu ungeschickt ist diese 8 Pins
da richtig auszulöten...
Vielleicht findet sich ja jemand, der ihm einen Chip auslötet und auf
einem Adapter zur Verfügung stellt?? Das sollte doch kein Problem sein
und diese sinnleere Diskusion endlich abwürgen.
20 Euro + Material + Versand oder so.
Interessant wäre ja mal die Frage, wieweit ein Verkäufer über die
Verwendung von Produkten entscheiden darf. Gibts da Regeln?
Ein verkäufer kann frei Entscheiden an wem er seine Produkte verkaufen
möchte (es darf nur nicht diskriminierend sein, beispiele brauch ich da
wohl nicht nennen), sollte der Verkäufer mitbekommen, das das Gerät
zerlegt wird um nur ein bestimmtes Bauteil daraus zu entnehmen, und der
Verkäufer möchte das nicht, dann darf dieser dem Kunden sagen, das er
das nicht verkaufen möchte.
Entscheiden, was nach dem Verkauf damit passiert darf er nicht, da das
Eigentums- und Besitzrecht auf den Käufer übergegangen ist.
Es handelt sich aber um einen Lizenzvertrag! Was ist hier Eigentum?
Ein ähnliches Problem gibts bei Software allgemein. Und schaut man 100
Jahre zurück, stößt man auf ein extra erlassenes Gesetz was den damals
üblichen und straflosen Stromklau eindämmte. Damals war es so, das man
nur anfaßbares Gut 'klauen' konnte. Strom war dies nicht.
Naja, etwas für einen neuen Thread.
Gut, das die Gedankenpolizei immernoch nicht funktioniert. So können wir
alle noch unverschämte Dinge in den eigenen vier Wänden tun.
>Allerdings hab ich ihn wohl beim Löten gegrillt, da es eine sehr kleines>S08-Gehäuse ist.
Abschlagen??
Ist doch nicht so schwehr, und grillen kann man ihn dann auch ned!
Abschlagen: Schraubendreher in die Hand nehmen, auf den IC halten und
draufhaun. Steht alles in SMD-Löten Wiki!
julian
PS:
Wie habt ihrs gemacht?
Hm. Klingt nach IC hats überlebt, leider stach der Schraubendreher in
die Eingeweide...
Aber der Artikel ist nett zu lesen. Wenn Benzin, dann würde ich es aber
einfach aufs IC kippen und anzünden und dann das IC aus dem Flammenmeer
holen. Werde ich bei Gelegenheit ausprobieren.
>Hm. Klingt nach IC hats überlebt, leider stach der Schraubendreher in>die Eingeweide...
Was hätte schon passieren sollen?
Nein ich hab mich nicht gestochen!
julian
Du bist aber auch erst 16 !
Warte mal ab, das Risiko sinkt zwar mit steigender Lebenserfahrung, aber
das Gesamtrisiko steigt trotzdem! Wenns 100% erreicht hat, ist Schluß!
Viel Spaß!
Sorry für die PMs. Es war nicht meine Absicht dreist Code zu erbetteln!
Aber warum geht ihr so hart mit mir ins Gericht?
Ich war mir sicher, dass keine Verfahren oder Detail-Infos im Forum
selber publiziert werden. Deswegen hab ich mich über PM gemeldet. Da ich
nicht weiß, wer nun überhaupt Ansprechpartner ist, ging die Mail an
mehrere.
Was ist da nun so schlimm dran? Mal ehrlich...
Damit ihr nicht denkt, ich will nur den Code, wie einige das auslegen,
im Anhang ein Bild von meiner aktuellen Wetterstation "ohne Wetter" nur
Testdaten. Ich bin bereit den Code selber zu schreiben.
Ich hab mich über DES mal schlau gemacht und auch eine step-by-step
Anleitung gefunden, allerdings basiert die auf 64 Bit Daten.
Auch wenn mit mir keiner sprechen will :/ hab ich trotzdem eine Frage:
Wie unterscheidet sich die 64-bit-DES mit dem 40-bit-DES im HKW?
schönen Abend.
Danilo
Wenn du den Thread mal hochblätterst, fallen dir Beiträge wie dieser in
die Arme:
S. Dinger, Open Secret Group schrieb:> Und nun spielt Ihr Euch zum "Richter Gnadenlos" auf. Erlasst eigene> Gesetze, fühlt euch stark, wissend und mächtig.>> Vielleicht habt ihr einfach den Beruf verfehlt. Wärt besser Polizist> geworden. Jedenfalls interessant ist das Phänomen aus psychologischer> Sicht allemal. Kennt man doch den Mechanismus Eurer Projektion nach dem> Motto:>> "Ich weiß was, was du nicht weißt. Aber ich sagt nicht. Nie, Ätsch">> Das kenn ich doch irgenwo her, ähm, ähm, wo hab ich das schon erlebt.> Ach ja, jetzt fällt es mir ein.> Das ist lange her. Das war im Kindergarten.
Deswegen haben sie so auf dich reagiert! Und wenn ich meinem Senf
beimischen darf: Ich hätte nicht anders reagiert, wenn ich erst in den
Dreck gezogen und dann gebeten werde den Algo zu veröffentlichen.
Also bleiben dir zwei Möglichkeiten:
Mit der "Anleitung" hier aus den drei Threads den HKW851 knacken
oder
Über das www die Infos holen (kannst ja auf dcf77logs.de die Webkonsole
abgreifen, wenns dir so am DCF liegt).
julian
Hallo miteinander,
also ich verfolge diesen Thread schon seit einiger Zeit, weil ich
Kryptographie total spannend find. Erst mal Gratulation und meine
Hochachtung an die Lösergruppe! Ich kann die Gründe, den Code nicht zu
veröffentlichen sehr gut nachvollziehen.
Eine Frage interessiert mich aber noch, die mir vielleicht diejenigen,
die es geschafft haben, beantworten können:
Wurden für die S-Boxen nun echte Tabellen im uC abgelegt, oder hat man
sich diesen Speicherplatz gespart und die 4 Ausgangsbit jeder S-Boxen
werden aus deren jeweiligen 6 Eingangsbits berechnet?
Ansonsten freu ich mich über meine eigene Meteotime-Wetterstation - sie
zeigt nämlich noch für (min) 4 Tage gutes Wetter an :)
Beste Grüße,
Marcel
Hallo Marcel,
so wie ich das sehe liegen die Daten als Tablle im Speicher und werden
nicht berechnet.
- zum einen geht das Erzeugen recht flott (ein paar Zyklen, würde zu
einem GOTO PC+X und RETLW passen), es liegen auch keine
Zwischenergebnisse vor.
- zum anderen hat jemand anderes die Tabelle mit einer Kombination aus
Single Step und RAM-Monitor gefunden (PC setzen, Controller für ca. 1us
laufen lassen, anhalten und den Inhalt des W-Regsiters ausgeben). Wir
sind beide zum gleichen Ergebnis gekommen.
Ich kann es aber nicht 100%ig sagen, da ich den "echten" Code aus dem
PIC nie gesehen habe.
Walter.
Hallo Walter,
danke für Deine Antwort. Genau, aus dem in diesem Thread bestehenden
RAM-Dump konnte ich einen Teil dieser "Tabelle" rekonstruieren. Aber
leider nicht die ganze. Deshalb auch meine Frage. Bis jetzt bin ich auch
nicht auf eine passende Formel gekommen. Stehen denn noch weitere
RAM-Dumps zur Verfügung?
Marcel
ich habe damals den Zeitpunkt im Programmablauf rausgesucht, an dem
entsprechenden Stellen berechnet werden und habe dann unterschiedliche
Telegramme eingeschoben (jeweils ein Bit gesetzt) und geschaut, wie sich
das Ergebnis ändert. Dabei gibt es an Adresse 0x31 (wenn ich mich recht
erinnere) einen Zähler, der dafür sorgt, dass der Watchdog 15 Mal
"zuschlagen" muß bevor ein neues Telegramm eingeschoben werden kann. Den
Zähler muß man zuerst auf 1 setzen (beim nächsten WDT Timeout wird der
dann auf 0 gesetzt) und es kann wieder ein Telegramm eingeschoben
werden. Sonst muß man immer ca. 30 Sekunden warten, ist halt lästig.
Das habe ich aber alles "live" am Rechner gemacht, somit sind bei mir
keine RAM-Dumps mehr da. Wenn Du den RAM Monitor am Laufen hast ist es
aber eigentlich nicht weiter wild die Daten herauszubekommen. Das gilt
auch für die anderen Tabellen.
Walter
Hm ok, verstehe. Ich habe keine H/W dazu aufgebaut, sehe aber nun, dass
es schwierig wird, dies ohne zu schaffen. Muss erst mal überlegen, ob
mir dieser Aufwand noch wert ist. Ich habe aber richtig verstanden, dass
dazu der PIC-Chip und nicht der Chip mit dem Aufdruck "HKW..." notwendig
ist?
Ich habe ein Brute-Force-Programm geschrieben, um die restlichen
Tabelleninhalte zu finden. Dazu habe ich von dcf77log das Telegramm
herausgesucht, dass am günstigsten zu den mir bekannten Tabelleninhalte
passt. Die Brute-Force-Atacke dauert aber immer noch sehr lange. Mal
sehn.
Marcel
Was hast du denn für eine Wetterstation?
Die Bezeichnung des Chips ist HKW und dann ein paar Ziffern. Steckt aber
ein PIC dahinter. Den kann man auch schon (größere Mengen
vorrausgesetzt) mit einem beliebigen Aufdruck bei Microchip kaufen.
Den RAM-Monitor muss man selbst in den Chip laden, dazu muss man aber
direkt an die Programmierpins kommen. Leider können viele
Programmiergeräte diesen Flashbereich nicht beschreiben, d.h. man muss
sich da selbst was basteln. Ich hab mir damals einen
Programmer/RAM-Monitor-Bediener per Atmega16 gebaut.
Ah ok, das wusste ich gar nicht. Ich habe eine Cresta Meteotime mit
Außensensor. Dann ist die Hürde ja in der Tat nicht so hoch und ich
müsste mich um einen RAM-Monitor kümmern.
Alternativ frage ich mich, ob eine Implementation meiner
Bruto-Force-Attacke auf einem FPGA den nötigen Geschwindigkeitsschub
geben würde.
Noch einen erholsamen Feiertag,
Marcel
Hallo Jungs,
ich verfolge das Thema von Beginn DCF77 Wetter an.
Und jetzt ist alles gelaufen?
Walter Du hast die Hauptarbeit geleistet. Hut ab!
Wenn ich mir jetzt die Sache nochmal ansehe dann wurde die Entwicklung
kurz vor der Lösung und der Veröffentlichung abgewürgt.
Was stand denn in den zwischendurch gelöschten Beiträgen?
Ich glaube hinter der "Core Group" u.a. steht Fa. Meteotime (Gast) !
es war die einzige Chance die Veröffentlichung abzuwenden.
Dort läuft die SW zum chiffrieren und dechiffrieren.
Ich ermutige Euch, nehmt die Werkzeuge wieder auf und macht weiter!
Es ist schon einiges Zusammengetragen. Es muss nur nochmal step by step
lauffähig konstruiert werden. z.B. wegen der Übersichtlichkeit in VB und
Excel.
MfG
In den zwischendurch gelöschten Beiträgen befand sich überwiegend
Werbung und Spam.
Was die Veröffentlichung angeht:
Es steht definitiv nicht die Firma Meteotime dahinter, das es nicht
veröffentlicht wird. Wir haben zusammen das System wobei Walter mit
Abstand die meiste Arbeit geleistet hat.
Die Veröffentlichung findet nicht statt, weil wir uns nicht strafbar
machen wollen. Oder ist hier etwa ein Rechtsanwalt der zweifelsfrei
bestätigen kann, das es nicht verboten ist?
Selbst eine rechtliche Grauzone wäre mir zu heikel.
Ich würde es ja auch gern Veröffentlichen, um zu zeigen das es
wirklich...
Aber ich möchte keine Straftat begehen.
Oder traut sich jemand Meteotime direkt anzufragen, ob die ein Problem
damit haben? Wär vielleicht mal interessant, das herauszufinden...
obwohl die Antwort klar sein dürfte.
Das document Meteo_Crypt_V2.pdf gibt eine beschreibung von der Meteotime
DES. Ich habe das in eine arduino programiert. Das heisst das encrypt
und decrypt laufen und aus eine codierte code kann wieder der plaintext
gemacht werden. Habe bits jetst nicht der S-Box E P permutations.
Aus das document versteh ich doch nicht folgende.
Am sluss hat man 40bit plaintext. Der chiffer chip hat nur 20 bits
output.
Was ist mit der ueberige 20 bits.
Man zol ein gultiges plain erkannen an 0x2501. Hat das mit der 40bits zu
tun ?
Die algorithmus muss 41 mal ausgefuhrt werden und man zoll ein bit aus
der cipher data knippfen aber ich versteh nicht wie man das machen zoll.
Kan jemand mir helfen.
Im Ergebnis gibt es ein festes Feld, welches einen bestimmten festen
Wert erhalten muß. Nur dann ist die Dekodierung fehlerfrei gewesen. Dies
ist obige Konstante.
Damit man einzelne Bitfehler finden kann, wird der gesamte Algorithmus
eben mehrfach durchgeführt, wobei jedes einzelne Bit im Eingangsstrom
mal gekippt wird. Taucht irgendwann dabei fehlerfrei obige Konstante an
richtiger Stelle auf, ist der Bitfehler korrekt korrigiert worden. Sind
alle Bitkippungen durch und immernoch nicht obige Konstante gefunden
worden, dann handelt es sich um ein unkorrigierbares Datagram.
Der Algorithmus kann also die Bitfehler gar nicht gezielt korrigieren,
er testet einfach ALLE Möglichkeiten durch! Was man sonst üblicherweise
findet, sind Korrekturalgorithmen mit sogenannten Syndrome, wobei dieses
einen Index auf das fehlerhafte Bit darstellt.
Stell dir vor, dein Eingangsdatenstrom ist bis auf ein einziges Bit
korrekt. Dieses eine Bit MUSS also gekippt sein, denn es gibt nur ZWEI
mögliche Zustände!!!
Dann läßt du einfach alle Bits mal einzeln kippen. Es ist klar, daß du
dabei irgendwann das RICHTIGE Datagramm gefunden hast - dies aber noch
nicht weiß. Damit du das verifizieren kannst, ist obiger Algorithmus
eingebaut.
Man möge mich korrigieren, wenns falsch ist. Ist ne längere Zeit her.
Thomas Berends schrieb:> Die Veröffentlichung findet nicht statt, weil wir uns nicht strafbar> machen wollen.
Erstmal wäre das, wenn überhaupt, keine straf-, sondern eine
zivilrechtliche Sache. Wobei sich die Frage stellen würde, wofür ihr
denn überhaupt belangt werden solltet? Das bloße Wissen und seine
Weitergabe kann niemals bestraft werden. Beispiele dafür gibts zu hauf.
Ich sage jetzt mal z.B. CSS und Premiere. Vorgehen konnten die Firmen
immer nur gegen die ANWENDUNG des Wissens, also z.B.
DVD-Entschlüsselungssoftware oder Premiere-Piratenkarten. In eurem Fall
würdet ihr natürlich Ärger bekommen, wenn ihr fertige Programme ins
Netzt stellen oder Chips nachbauen würdet. Aber gegen die
Veröffentlichung des Algos oder eines Quelltextes gibt es keine
rechtliche Handhabe. Weder zivil- noch strafrechtlich.
DCF77Freak schrieb:> Sollte so ohne weiteres kompilierbar sein.> Umsetzung in C#
Vielen Dank für den Link!
Soweit ich es testen konnte, funktioniert es so wie erwartet. Mein
Respekt! Und dazu das ganze noch in einen hübsch kommentierten Code
verpackt. Damit dürfte nun zweifelsohne geklärt sein, dass es gelungen
ist, die Wetterdaten zu entschlüsseln.
DCF77Freak schrieb:> Ich bin mal so frei...>> http://pastebin.com/<link gelöscht>>> Sollte so ohne weiteres kompilierbar sein.> Umsetzung in C#
Hmm,
unfair :-)
Jetzt können Diejenige, welche den Algo geheim halten wollten, nicht
mehr mit "ich weis es, sags aber nicht - bä bä bä -" durchs Leben gehen
und sich die Eier schaukeln sondern müsssen sich nach was anderem zum
Profilieren umschaun :-)
Lars R. schrieb:> Soweit ich es testen konnte, funktioniert es so wie erwartet.
Wie hast du es getestet?
> Mein Respekt!
Meinen nicht.
> Und dazu das ganze noch in einen hübsch kommentierten Code> verpackt.
Ohne Kommentar.
> Damit dürfte nun zweifelsohne geklärt sein, dass es gelungen> ist, die Wetterdaten zu entschlüsseln.
Bist du sicher? Wenn ja - beweisen.
Und schon steht die Ausgabe auf der Konsole. Dann siehst du das
Ergebnis. Ich habe es mit mehreren Beispielen versucht. Es hat
funktioniert.
Wenn du es nicht glaubst, versuche es einfach selbst. Microsoft stellt
den C#-Kompiler kostenlos zur Verfügung.
bitemychiniesmetalass schrieb:> Ob die das nicht kannten?> http://de.wikipedia.org/wiki/Kerckhoffs%E2%80%99_Prinzip
Das Kerckhoffs' Prinzip ist hier nicht anwendbar. Der Algorithmus wurde
vor einiger Zeit schonmal gepostet, nur ohne die Pattern und Tabellen.
Damit war der Algorithmus öffentlich und es konnte trotzdem kein
(anderer) entschlüsseln.
Der Schlüssel liegt in den Patterns und Tabellen. Und für den Schlüssel
sagt dieses Prinzip auch, dass auf DIESEN die Sicherheit beruhen soll.
Zum Veröffentlichten Code: Ich gehe davon aus dass er funktioniert. Ich
habe es nicht selbst getestet, aber soweit ich es überprüft habe
scheinen die Tabellen usw. (also der Schlüssel!), korrekt zu sein.
Das deckt sich mit dem Code den auch ich geschrieben hatte.
Alex W. schrieb:> Jetzt können Diejenige, welche den Algo geheim halten wollten, nicht> mehr mit "ich weis es, sags aber nicht - bä bä bä -" durchs Leben gehen> und sich die Eier schaukeln sondern müsssen sich nach was anderem zum> Profilieren umschaun :-)
[ ] Du hast verstanden weshalb wir den kompletten Code nicht
veröffentlicht haben.
=> Nochmal den Thread durchlesen.
Insgesamt finde ich es NICHT in Ordnung, dass irgendeiner jetzt den Code
hier reinstellen musste. Es gibt keinen Anspruch darauf den Code zu
kennen, die Firma zwingt euch nix auf, die Firma schadet euch nicht -
warum macht man dann sowas?
Es hat damit angefangen dass ein paar Bastler interessiert daran waren
ob das System sicher ist, ob man es knacken kann und wie es
funktioniert. Es ging (zumindest für mich) niemals darum, der breiten
Öffentlichkeit diesen Code zugänglich zu machen und damit ggf. einer
Firma ihre Geschäftsgrundlage zu nehmen.
Es geht hier nicht um irgendwelche höheren Ziele oder Werte!
Dieses Verhalten ist in meinem Verständnis ein grober Verstoß gegen
jegliche Hackerethik! Pfui! Schäm dich!
Micha schrieb:> @Alex W. (a20q90): eh Du ueber Leute herziehst, die die ganze Arbeit> gemacht haben, überlege mal, wer das denn gepostet haben koennte
Ich ziehe über diejenigen her die es tun könnten, aber nicht wollen!
Vorallem weil ihrem Willen nun nicht mehr entsprochen wurde! :-)
Micha schrieb:> überlege mal, wer das denn gepostet haben koennte
Ich frage mich ob es vom Poster gewollt war das man seine "Anonymität"
durch 3 Mausklicks untergraben kann...
Na super, das ist ja mein Code...
Ich war wohl zu nachlässig
Ich habe die ZIP-Datei mit dem Code auf meinen Webserver hochgeladen
gehabt, wollte es aber sofort löschen, bis gestern war die Datei da noch
drauf...
Warum ich diese hochgeladen habe:
Ich habe meinem bekannten den Code geschickt. Dieser hat es aber nicht
hochgeladen, dem vertraue ich in der Hinsicht. Es gab aber mehrere
Zugriffe auf die Datei.
Das Video bei YouTube habe ich im Namen von DCF77Freak hochgeladen, was
ich jetzt aber unverschämt finde ist, das derjenige den gleichen Namen
für die Veröffentlichung des Codes verwendet.
Ich bitte Vielmals um Entschuldigung. Es war nicht meine Absicht, das
der Code in falsche Hände gerät!
Na, ich denke, er wollte es nicht ganz so offiziell tun. Hier im Forum
findet man noch nach Jahren seinen Namen und es koennte Aerger geben,
das Linkziel dagegen kann in ein paar Tagen veschwunden sein.
Simon K. schrieb:> Thomas Berends schrieb:>> Na super, das ist ja mein Code...>>>> Ich war wohl zu nachlässig>> Ob das jetzt so geschickt war, das hier zu posten...
Ich könnt mir jetzt echt in' Arsch beißen das ich das überhaupt auf
meinen Server geschmissen habe
Ich bin grad echt... Grrrr
Thomas Berends schrieb:> Na super, das ist ja mein Code...>> Ich war wohl zu nachlässig> ...> Ich bitte Vielmals um Entschuldigung. Es war nicht meine Absicht, das> der Code in falsche Hände gerät!
Wenn es zu einem Schaden für die Firma Meteotime gekommen ist, dann
sollte deine Kasse gut gefüllt sein. In deiner Haut möchte ich
jedenfalls nicht stecken.
Haha das glaubst du doch wohl jetz selbst nicht. Einmal einigermaßen
verbreitet wird der Code jetzt glaube nie wieder "verschwinden".
Tja..wenn man was nicht verbreiten will, sollte man es nicht ins Inet
stellen...auch nicht für gute Bekannte...
Buh schrieb:> Haha das glaubst du doch wohl jetz selbst nicht. Einmal einigermaßen> verbreitet wird der Code jetzt glaube nie wieder "verschwinden".
Das ist mir klar, aber solange das nur hier ist, kann man die weitere
verbreitung jedenfalls etwas bremsen....
Vielleicht kann ja auch ein Moderator die Beitraege mit Deinem Namen und
den mit dem Link loeschen. dann gibts keinen Bezug mehr dazu. Dein
Programm bei pastebin muss dann erstmal gefunden werden.
Thomas Berends schrieb:> Ich bitte Vielmals um Entschuldigung.
Du brauchst dich nicht zu entschuldigen, denn du hast nichts falsches
getan.
> Es war nicht meine Absicht, das> der Code in falsche Hände gerät!
Das ist er auch nicht. Überlege doch mal, für wen der Code letztendlich
nützlich ist: Niemand wird ihn kommerziell verwenden, denn
selbstverständlich würde er sofort von Meteotime dafür belangt werden
können. Bleiben also nur ein Paar Bastler zu hause in ihrem stillen
Kämmerlein, die es entweder einfach gut finden den Code endlich zu haben
oder die, bei genügend Fachwissen, das Ganze für sich selbst als
Einzelstück auf einem AVR implementieren. Gegen beides ist rechtlich
nichts einzuwenden. In beiden Fällen entsteht Meteotime kein Schaden.
Ich werde mir auch einen Spaß daraus machen, das Ganze mal für mich auf
AVR umzusetzen. Nicht weil ich damit Geld sparen wollte, denn ich habe
bereits in mehreren Zimmern gekaufte Uhren, wo der originale Chip drin
ist und ich einfach einen raus rupfen könnte. Nein, es geht einfach um
das selbst machen. Ich habe kein Problem damit zuzugeben, das meine
Fähigkeiten nicht ausreichten um selbst an den Code des Chips zu kommen.
Wohl aber, um den jetzt veröffentlichten Code zu portieren. So wie mir
wird es wahrscheinlich vielen gehen, die zwar auf Hobbyebene was zu
Stande bringen wollen, aber eben nicht die Fähigkeiten eines Walter
Freywald besitzen. Und allen, die jetzt wieder mit "Damit nutzt du nur
die Arbeit anderer aus" kommen, sei gesagt: Wo wären wir ohne die
Vorarbeit anderer? Wie viele Anwendungsprogrammierer verstehen alle
Librarys die sie benutzen vollkommen? Wie oft wird gerade im
Kryptobereich die Vorarbeit anderer benutzt? In diesem Sinne mal ein
großes Dankeschön an DCF77Freak, der sich nicht hat einschüchtern lassen
und ein lautes"Schäm dich" an denjenigen, der den Link in vorauseilendem
Gehorsam (ja, darin sind die Deutschen echt gut) wieder gelöscht hat.
Wenn die Leute bei CSS auch so vorauseilend gehandelt hätten, könnte man
unter Linux heute noch keine DVDs gucken. Aber zum Glück wurde das ja
auch nicht zuerst in Deutschland versucht...
> Ich habe bei pastebin einen Löschantrag gestellt.> Ich hoffe das es schnell gelöscht wird
Das wird nichts mehr nutzen. Von jetzt an wird der Code immer wieder
hoch geladen werden und über die Suchfunktion auch zu finden sein. Was
einmal im Internet ist...
> Was einmal im Internet ist...
Leider ist das eine urban legend.
Es gibt unendlich Vieles, was auf Nimmerwiedersehen verschwindet, und
bei dem man sich ärgert, nicht rechtzeitig eine lokale Kopie gemacht zu
haben.
Natürlich ist es frech, Sachen hochzuladen, die man nicht selbst gemacht
hat. Leider ist die Welt voll von solchen kleinen Scheissern.
@Thomas:
wäre es nicht besser, wenn du die Software zum Dekodieren von DCF77 mit
Wetterdaten von deiner Seite nimmst. Sie ist in NET geschrieben und
liese sich somit sehr einfach decompilieren, so dass wieder C#-Code
vorliegt.
Das kann doch nicht wahr sein, wie mit den Erfindungen andere Leute
umgegangen wird. So ist es doch kein Wunder das ACTA eingeführt werden
soll.
Gerade habe ich Meteotime über diesen Thread informiert. Evtl. können
alle Beteiligten dann direkt Kontakt miteinander aufnehmen und es
außerhalb des Forums klären!
Peter K. schrieb:> @Thomas:> wäre es nicht besser, wenn du die Software zum Dekodieren von DCF77 mit> Wetterdaten von deiner Seite nimmst. Sie ist in NET geschrieben und> liese sich somit sehr einfach decompilieren, so dass wieder C#-Code> vorliegt.
Mir ist klar, das .NET Code einfach dekompiliert werden kann. Ich habe
aber auf meiner Webseite keinerlei Software öfentlich zugänglich, welche
die wetterdaten, ich betone, ohne hardware, dies bedeutet ohne hkw chip
entschlüsseln kann. Ihr könnt es gern dekompilieren, aber es wird
nirgends der Code zu finden sein.
Der Code für das Ansprechen derHardware befindet sich in der
TimecodeLib.dllar, dass .NET
unfair schrieb:> Gerade habe ich Meteotime über diesen Thread informiert.
Dazu darf ich mal Hoffmann von Fallersleben zitieren:
"Der größte Lump im ganzen Land, das ist und bleibt der Denunziant."
Sehe ich auch so. Damit schadet man der Bastlergemeinde nur noch mehr.
Warten wir ab, ob da nicht ein weiterer Algorithmus im PIC steckt und
Meteotime nun zu diesem wechselt. Da gabs ja noch genug Baustellen, wo
wir nicht wissen was der PIC da machen soll.
Mal wieder zur Technik:
Ich finde die Fehlererkennung irgendwie nicht sonderlich effektiv. Als
Beispiel kann der Code der im Radio bei RDS verwendet wird, 1 und 2
Bit-Fehler korrigieren und Bursts von 5 Bit - wenn ich mich recht
entsinne. Dabei sind die Daten: 16 Bit Rohdaten plus 10 Bit Syndrom
RDS ist viel älter als das Verfahren hier. Äh, vermute ich. Wer weiß ob
Meteotime nicht irgendwo selbst abkupferte.
Vielleicht kann man das näher erörtern. Schließlich läßt sich sowas auch
gut für eigene Projekte verwenden! Solche Anfragen tauchten ja schon
öfters auf.
Ansonsten kann ich Linuxer nur zustimmen. Kultur ist die
Wissensweitergabe und stetige Verbesserung. Sonst würden wir heute noch
mit dem Steinen Nüsse knacken. Irgendwo in Afrika.
Ganz einfach. Mit dieser Formulierung stellt er 'wir' über Menschen, die
mit Steinen Nüsse knacken, und über Menschen in Afrika. Das wollte er
vermutlich gar nicht.
Info schrieb:> Ganz einfach. Mit dieser Formulierung stellt er 'wir' über Menschen, die> mit Steinen Nüsse knacken, und über Menschen in Afrika. Das wollte er> vermutlich gar nicht.
Bist du ein Rassist oder noch schlimmer - Gutmensch? Was du da anderen
unterstellst ist einfach eine Ungeheuerlichkeit.
Nee, er ist nur schwer lesebehindert,
und liest was was gar nicht dasteht,
und ist so fehlerzogen, daß er meint,
er wäre soooo toll wenn er daraus eine
grosse Welle macht, da hat Mami ihn auch
immer gelobt.
@ Heinz (Gast)
Derjenige der den Code hat müsste ihn auch auf den AVR portiern und das
schient nur einer zu sein.
Wird es irgendwann eine Möglichkeit geben dieses Feature in meinen
DCF-Empfänger mit einzubauen oder hat man Angst dass die Chinesen das
Programm nutzen und dann wie die USBasp bei eBay verkaufen?
Thomas Berends schrieb:> Buh schrieb:>> Haha das glaubst du doch wohl jetz selbst nicht. Einmal einigermaßen>> verbreitet wird der Code jetzt glaube nie wieder "verschwinden".>> Das ist mir klar, aber solange das nur hier ist, kann man die weitere> verbreitung jedenfalls etwas bremsen....
Na,
Ich glaube das dürfte jetzt schon fast zu spät sein...
Selbst wenn jemand erst jetzt hereinschneit und sich ärgert das er es
nicht schnell genug gesehen hat, so wird er es bereits mit einer
einfallslosen Google suche finden.
Gerade getestet, egal ob die Suchbegriffe Meteotime decoder oder
Meteotime Verschlüsselung sind, es steht schon immer ganz weit vorne.
Und diese Suchbegriffe sind wohl die welche schon der einfallsloseste
als erstes Ausprobieren wird.
Kommt dann noch der Name der Veröffentlichten Website ins Spiel, dann
ist es Platz eins, und der Name steht ja da noch... Das Ganze liegt auch
schon in diversen SuchmaschinenCaches.
Im Übrigen steht das Programm mindestens ZWEI MAL da drin. Einmal habe
ich es gefunden mit mitlerweile >200 Zugriffen wo die Namen (wf) noch im
Klartext stehen, ein zweites mal mit >90 Zugriffen mit Datum von heute
und editiert ohne Namen.
Zum Vorgang der Veröffentlichung selbst:
Das die kompletten Geheimnisse nun aufgedeckt sind, das finde ich im
Grunde nicht verkehrt, ABER:
1. Ich finde es eine riesen Schweinerei das einfach Code veröffentlicht
wird wo Namen von anderen Personen ohne deren Zustimmung in Klartext
enthalten sind.
2. Es ist eine Schweinerei einfach fremden Code den man sich angeeignet
hat ohne groß eigene Arbeit da hereinzustecken zu veröffentlichen.
ALLERDINGS: Hätte ich keine Einwände gehabt wenn jemand die der
öffentlichkeit noch fehlenden Daten aus der SW extrahiert und nur diese
Tabellen z.B. als aufbereitetes PDF online Gestellt hätte. Solange die
Entdecker das nicht öffentlich machen wollen ohne irgendeinen Verweis wo
die her kommen, so das man keine Rückschlüsse daraus ziehen kann.
Ist zwar auch nicht ganz Lupenrein, aber das ist der ganze Vorgang
vorher auch nicht gewesen. Einmal ist alleine schon das Knacken des
Codes an sich nach derzeitigen Recht zumindest Fragwürdig, auch ohne die
weitergabe.
Zum anderen haben zwar ganz wenige die Arbeit am ende zum erfolg
gebracht, aber wie hier zu erkennen war haben eine Menge Leute sich mit
Ideen, Vorschlägen und auch Versuchen an der Sache beteiligt und evtl.
auch so denjenigen die es geschafft haben den Weg bereitet oder gar erst
auf die Spur gesetzt. Hier haben also viele gemeinsam angefangen.
Nach dem der Erfolg da war haben dann aber einige wenige das Ergebniss
gehabt, dann erst den Moralischen Zeigefinger herausgeholt und
beschlossen das ja alle Mitarbeiter damit glücklich zu sein haben das
die nun wissen es ist möglich...
Viele haben Mitgearbeitet, ein etwas kleinerer Teil hat richtig viel
Arbeit reingesteckt - aber nur ein winzig kleiner TEil profitiert vom
Erfolgt und lässt den Rest im Regen stehen.
Das dies unmut bei den Mitstreitern und erst recht bei denen die
wirklich intensiv mitgemacht haben, zurücklässt ist da nur verständlich.
Dann hätte man entweder selbst von Anfang an klarstellen müssen das man
selber ein Ergebnis niemals veröffentlichen wird, oder aber -bei solch
starken bedenken- sich gar nicht erst einmischen brauchen.
Aber DAS kam alles erst nachdem man bereits von der Vorarbeit anderer
profitiert hat und mit etwas Glück es dann selbst geschafft hat.
Gruß
Carsten
Naja, bißchen schade wie das gelaufen ist...
Aber im Grunde kann man jeden Code knacken. Es ging nie darum das zu
beweisen - das war bereits vorher klar. Es ging evtl. nur darum wieviel
Aufwand nötig ist.
Und was den Code angeht - das nennt man Streisand-Effekt. Versuche die
Verbreitung einer Information zu unterdrücken und sie wird sich erst
recht verbreiten weil ihr plötzlich ungeahnte Aufmerksamkeit gewidmet
wird. Ich gebs zu, ich hab auch sofort eine Kopie davon gemacht, ohne zu
wissen ob ich den Code jemals brauchen werde. Vielleicht habe ich nun
einen guten Grund und Ansatz auch mal eine DCF77-Uhr zu bauen - aber ich
weiß nicht ob ich das jemals tun werde... Ich hab genug Uhren.
Ich habe soeben den Timer angestellt und warte nun darauf, wann der
erste programmierte Controller bei ebäh erscheint. Es wird vermutlich
keine Woche brauchen.
Achja, zu vorhin: Natürlich ist die Wiege der Menschheit in Europa! Wie
sollte man sonst begründen, daß wir doch schon so weit sind.
Ehrlich gesagt, tue ich mich mit dem Code schwer. Welche Routine
verschlüsselt denn den Plaintext? Ich finde die dort einfach nicht,
obwohls in den Einleitungskommentaren als implementiert erwähnt ist. Ich
habe aber auch noch nie in C# irgendwas gemacht. Ich erwarte nun nicht,
daß jemand den Quellcode nochmals postet. Nicht das jetzt wieder ne
Diskussion beginnt. Ich führe grundsätzlich lieber Monologe ;-)
Also einfach nur den Funktionsnamen posten oder per PM.
Übrigens wurde der Betrieb von DCF77 wohl bis ins Jahr 2022 verlängert.
Die Schwester in der Schweiz wurde ja vor geraumer Zeit stillgelegt!
Wie sieht das rechtlich eigentlich aus für die Verschlüsselung ?
Soweit ich weiß, sind alle rechtlichen Grundlagen nur für die
Entschlüsselung ausgelegt. Darf man den Code für eine Verschlüsselung
noch so einfach frei handeln?
B.A. schrieb:> @ Heinz (Gast)> Derjenige der den Code hat müsste ihn auch auf den AVR portiern und das> schient nur einer zu sein.
Die Portierug kann doch jeder durchführen, der die Kenntnisse und den
C#-Code hat. Bin leider zu spät gekommen zum Download. :(
Heinz schrieb:> B.A. schrieb:>> @ Heinz (Gast)>> Derjenige der den Code hat müsste ihn auch auf den AVR portiern und das>> schient nur einer zu sein.>> Die Portierug kann doch jeder durchführen, der die Kenntnisse und den> C#-Code hat. Bin leider zu spät gekommen zum Download. :(
Der Code ist immer noch online verfügbar.
Ähm,
könnte man den Thread nun nicht endgültig schließen? Durch die Löscherei
ist er mittlerweile löchrig geworden wie ein Schweizer Käse und es ist
nicht sichergestellt, daß irgendwelche Trolle nicht doch weiterhin
Hinweise auf die Quelltexte hier einstellen, die dann bis zur Löschung
durch die Mods sichtbar sind.
Gruß...Maschinist
Bert Braun schrieb:> Durch die Löscherei> ist er mittlerweile löchrig geworden wie ein Schweizer Käse
Das die hiesigen Moderatoren abhängig von persönlicher Lust und Laune
Beiträge löschen ist doch bekannt und betrifft nicht nur diesen Thread
hier. Von daher sehe ich hier nichts besonderes.
> und es ist> nicht sichergestellt, daß irgendwelche Trolle nicht doch weiterhin> Hinweise auf die Quelltexte hier einstellen
Wenn jetzt auch schon bloße Hinweise, also z.B.: "Hemden gibts im
Kaufhaus" oder "Probiers mal bei pastebin.com" verboten sind dann kann
ich nur sagen: Armes Deutschland! Von wegen Freiheit von Forschung und
Lehre. Von wegen Wissen muss frei sein. Aber was solls. Wenn das
Grundgesetz schon die Regierung nicht interessiert, von wem soll man es
dann erwarten...
Abdul K. schrieb:> Ehrlich gesagt, tue ich mich mit dem Code schwer. Welche Routine> verschlüsselt denn den Plaintext? [...]> Also einfach nur den Funktionsnamen posten oder per PM.
Zeile 724:
Linux User Nr. 63524354 schrieb:> Wenn jetzt auch schon bloße Hinweise, also z.B.: "Hemden gibts im> Kaufhaus" oder "Probiers mal bei xxx.com" verboten sind dann kann> ich nur sagen: Armes Deutschland! Von wegen Freiheit von Forschung und> Lehre. Von wegen Wissen muss frei sein. Aber was solls. Wenn das> Grundgesetz schon die Regierung nicht interessiert, von wem soll man es> dann erwarten...
Unfaßbar, wofür das Grundgesetz bei so manchem Anarchisten alles
herhalten muß...
Ob die erwähnte "Freiheit von Forschung und Lehre" die Verbreitung von
irgendwo geklautem Code beinhaltet, möchte ich mal stark anzweifeln.
Und geklauten Code mit freiem Wissen zu bezeichnen, ist wirklich nur
anarchistisch. Wahrscheinlich zählst Du Deine Bankdaten, Deine
Krankenakte, Deine Personalunterlagen auch zu "freiem Wissen" und
publizierst sie fleißig auf breiter Basis?
Nein? Warum nicht?
Somit ist Dein Einschrieb lediglich als ein weiterer Trollversuch zu
werten, klar, hast ja auch extra den Speicherort nochmal gepostet, QED.
Maschinist
Es war ganz klar Andreas Wunsch das keine Links/Code hier gepostet wird,
zumde wurde der Code gegen den Willen des Urhebers gepostet. Zum Thema
Metrotime ist hier denke ich auch alles gesagt, daher erstmal ein
close an dieser Stelle.
Thread beobachten
Seitenaufteilung abschalten