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.
Für alle die ans Fuse-Bit löschen denken: Hier hat einer nen PIC 18F1320 gehackt: http://hackaday.com/2011/06/27/bunnies-archives-unlocking-protected-microcontrollers/ http://www.bunniestudios.com/blog/?page_id=40 Hier is ne ghetto methode zum entblößen des dies erklärt (vlt. auch für nen Ram-Dump brauchbar)... http://hackaday.com/2010/07/16/decapping-integrated-circuits-with-sap/ http://s3cu14r.wordpress.com/2010/07/15/boiling-chips-in-tree-sap/
Max D. schrieb: > Hier is ne ghetto methode zum entblößen des dies erklärt (vlt. auch für > nen Ram-Dump brauchbar)... > http://hackaday.com/2010/07/16/decapping-integrated-circuits-with-sap/ https://berlin.ccc.de/wiki/Experiment:_IC-Entkapselung_mit_Kolophonium (SSL-Zertifikat ist ungültig, Ausnahme hinzufügen)
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
Dann gibt es offensichtlich zwei 'Untergrund'-Organisationen. Wenn das Schäuble wüßte.
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.
Der 'Russe' scheint die eleganteste Methode gefunden zu haben. Zumindest was die Hardware angeht.
Hast du zu dieser Methode noch genauere Infos? Also bzgl. Timing, Pegel auf den einzelnen Leitungen usw?
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.
>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.
Angehängte Dateien:
-
HKW561_1.jpg
860 KB -
HKW581_2.jpg
650 KB
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?
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?
Probehalber erst an einem 12f509 suchen und testen, bevor hier der hkw verbraten wird...
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.
Vielleicht kommt man auf den CCC zurück. Der Vorschlag wurde gemacht.
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.
Wenn ihr mal in Berlin seid, werft ne CD mit dem Code anonym in den Briefkasten des CCC :D
Ich frage mich nur die ganze Zeit welches Interesse der CCC an der Veröffentlichung habe könnte...
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: > Äh, soweit ich das sehe hat hier niemand vom CCC "Interesse geäußert". Ich dachte das: Beitrag "Re: Meteotime Crypt" ging irgendwie vom CCC aus....
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 !
Meine Guete was ein Gebettel, dass ist ja schlimmer als am Bahnhof.
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...;-)
Niemand muss den urheberrechtlich geschützten Code hier rausgeben. Das Verfahren genau zu erklären ist dagegen vollkommen legitim.
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.
Angehängte Dateien:
-
HKW561_01_work1.jpg
1 MB
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)
|
2 | private int setNumber() |
3 | {
|
4 | TimeSpan baseTime = new TimeSpan(1, mIntHour, mIntMinute, 0); |
5 | return (int)((baseTime.Add(new TimeSpan((2 - mIntUtcOffset), 0, 0)).Ticks / (TimeSpan.TicksPerMinute * 3)) % 480); |
6 | }
|
7 | |
8 | //Ermittelt Regionscode:
|
9 | int forecastType60 = (int)Math.Floor(setNumber() / 60d); |
10 | int forecastType90 = (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.
Anbei die Wetterdaten, zum bearbeiten hats leider nicht mehr gelangt... Gruß Thomas
Daten sind korrekt und lassen sich entschlüsseln! Habe es soeben selbst ausprobiert.
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?
Ich hatte mal eine Anfrage geschickt wegen Kosten des uC für ein Reel (ca 3300 Stück). Antwort war, diese kleine Menge verkaufen sie nicht.
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:
|
20 | byte[] mByteArrForecastLookup = { 0, 1, 2, 3, 4, 11, 9, 15, 6, 14, 7, 8, 13, 10, 5, 12 }; |
Ich musste die Daten Mühsam über Monate hinweg Zuordnen. Gruß Thomas
Christian H. schrieb: > Aha, also alle Bauteile selber dremeln? Nein, aber alle programmierbaren Bauteile auch selber programmieren.
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ß!
Angehängte Dateien:
-
wetterstation.jpg
72 KB
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.
> Oder ist hier etwa ein Rechtsanwalt der zweifelsfrei > bestätigen kann, das es nicht verboten ist? Alles Luschen. Mit so einer Einstellung wäre es nie zu http://www.oocities.org/mwinterhoff/helpdeco.htm oder http://www.oocities.org/mwinterhoff/galblast.htm gekommen. Und, kam was ? Klar, Jobangebote.
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.
Ich bin mal so frei... http://pastebin.com/<link gelöscht> Sollte so ohne weiteres kompilierbar sein. Umsetzung in C#
:
Wiederhergestellt durch User
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 :-)
:
Wiederhergestellt durch User
coole nummer.... ich muss es mir bei gelegenheit mal näher anschauen. Ich habs vorsichtshalber gleich mal gespeichert ;) Ob die das nicht kannten? http://de.wikipedia.org/wiki/Kerckhoffs%E2%80%99_Prinzip
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.
Infidel schrieb: > Wie hast du es getestet? Ganz einfach:
1 | DeEnCoder coder = new DeEnCoder(); |
2 | Console.WriteLine(coder.DecodeDataset("Hier Datensatz einfügen"));
|
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!
@Alex W. (a20q90): eh Du ueber Leute herziehst, die die ganze Arbeit gemacht haben, überlege mal, wer das denn gepostet haben koennte
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!
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...
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.
Ich habe bei pastebin einen Löschantrag gestellt. Ich hoffe das es schnell gelöscht wird
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.
Und den Beitrag vin LinuxUser auch loeschen (oder editieren), denn da ist der Name als Zitat leider auch drin
Entschuldigung, ich bin immer zu voreilig, ist ja doch noch alles da, es wurde wohl was anderes gloescht
@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.
Abdul K. schrieb: > Sonst würden wir heute noch > mit dem Steinen Nüsse knacken. Irgendwo in Afrika. Das solltest du evtl. anders formulieren.
Eine Frage zum obigen C#-Programm: Hat jemand bereits mit der Implementierung auf einen ATTiny/ATMega begonnen?
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:
1 | unsafe private byte[] Encrypt(byte* plain, byte* key) |
Linux User Nr. 63524354 schrieb: > Wenn jetzt auch schon bloße Hinweise, also z.B.: "Hemden gibts im > Kaufhaus" oder "Probiers mal bei xxx.com" verboten sind dann kann > ich nur sagen: Armes Deutschland! Von wegen Freiheit von Forschung und > Lehre. Von wegen Wissen muss frei sein. Aber was solls. Wenn das > Grundgesetz schon die Regierung nicht interessiert, von wem soll man es > dann erwarten... Unfaßbar, wofür das Grundgesetz bei so manchem Anarchisten alles herhalten muß... Ob die erwähnte "Freiheit von Forschung und Lehre" die Verbreitung von irgendwo geklautem Code beinhaltet, möchte ich mal stark anzweifeln. Und geklauten Code mit freiem Wissen zu bezeichnen, ist wirklich nur anarchistisch. Wahrscheinlich zählst Du Deine Bankdaten, Deine Krankenakte, Deine Personalunterlagen auch zu "freiem Wissen" und publizierst sie fleißig auf breiter Basis? Nein? Warum nicht? Somit ist Dein Einschrieb lediglich als ein weiterer Trollversuch zu werten, klar, hast ja auch extra den Speicherort nochmal gepostet, QED. Maschinist
Es war ganz klar Andreas Wunsch das keine Links/Code hier gepostet wird, zumde wurde der Code gegen den Willen des Urhebers gepostet. Zum Thema Metrotime ist hier denke ich auch alles gesagt, daher erstmal ein close an dieser Stelle.
Thread beobachten
Seitenaufteilung abschalten