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.