Bei andere Anbieter kann ich sehr wohl weiter SipNummern eintragen/bearbeiten.
Mir geht es aber um die bereits eingetrage Nummer.
Mir geht es aber um die bereits eingetrage Nummer.
[Info] Kennwörter aus der FRITZ!Box-Konfiguration auslesen für Firmware ab 06.10
- Ersteller PeterPawn
- Erstellt am
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Ja, holla, die mein ich auch.
Wähle mal Anderer Anbieter bei einer deiner Problemnummern.
...einfach aufklappen, auswählen und gucken.
Verhindern könnte die Bearbeitung der in der voip.cfg (siehe Sicherungsdatei) für die Telefonnummer zuständige Parameter...
gui_readonly = yes;
...ich schätze dann siehste nur die Nummer beim Bearbeiten.
Wähle mal Anderer Anbieter bei einer deiner Problemnummern.
...einfach aufklappen, auswählen und gucken.
Verhindern könnte die Bearbeitung der in der voip.cfg (siehe Sicherungsdatei) für die Telefonnummer zuständige Parameter...
gui_readonly = yes;
...ich schätze dann siehste nur die Nummer beim Bearbeiten.
Zuletzt bearbeitet:
Also, mein Vorhaben ist vorerst geglückt.
> Sicherung mit der FB6490 erstellt mit Passwort
> diese Sicherung auf meiner FB7390 mit der Firmware -> FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.03.image eingespielt
> Neustart
> Telnet aktieren
> rest geht eigentlich ohne skript -> einfach mit dem aktuellen ruKernelTool die benötigten Dateien auslesen, bei Bedarf speichern
SO, hab nun meine heiss begehrten Daten - nach ein paar stunden am zeil angekommen.
> hab nun die Daten auf meiner FB7490 (IP-Client modus) eingestellt -> Ergebnis: die Nummer kann nicht registriert werden .;-) -_> also war alles um sonst, sicher nicht aber für heute geb ich auf
morgen geht der kampf weiter.
> Sicherung mit der FB6490 erstellt mit Passwort
> diese Sicherung auf meiner FB7390 mit der Firmware -> FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.03.image eingespielt
> Neustart
> Telnet aktieren
> rest geht eigentlich ohne skript -> einfach mit dem aktuellen ruKernelTool die benötigten Dateien auslesen, bei Bedarf speichern
SO, hab nun meine heiss begehrten Daten - nach ein paar stunden am zeil angekommen.
> hab nun die Daten auf meiner FB7490 (IP-Client modus) eingestellt -> Ergebnis: die Nummer kann nicht registriert werden .;-) -_> also war alles um sonst, sicher nicht aber für heute geb ich auf
morgen geht der kampf weiter.
Ich verstehe eh nicht, warum du dir diesen Krampf antust. Warum meldest du nicht einfach die Client Fritzboxen am SIP-Registrar der Kabelbox an? Dass das geht, steht hundertfach hier im Forum: Eine FRITZ!Box an einer FRITZ!Box mit SIP-Registrar anmelden, um darüber zu telefonieren
Danke für die Erklärung. Genau nach dieser Anleitung bin ich ursprünglich auch vorgegangen. Und es hat geklappt. Ich konnte auch auf meine IP-Client boxen telefonieren.
Die Lösung war aber zu einfach. Ich hab ja die ganzen Boxen auch aus Bastelfreude.
Und ich hab hier wochenlang diverse Anleitungen gelesen. Und gestern hab ich mich getraut die Umsetztung anzugehen.
Wie gesagt, die Daten habe ich bereits.
Derzeit habe ich es noch nicht geschafft, mittels den ausgelesenen Daten die Rufnummer auch registriert wird.
Ich werde wohl noch weiter experementieren müssen, ev. muss ich die Macadressen noch anpassen.
Oder kann der Anbieter mehr als 1 Registrierung erkennen und unterbinden?
Die Lösung war aber zu einfach. Ich hab ja die ganzen Boxen auch aus Bastelfreude.
Und ich hab hier wochenlang diverse Anleitungen gelesen. Und gestern hab ich mich getraut die Umsetztung anzugehen.
Wie gesagt, die Daten habe ich bereits.
Derzeit habe ich es noch nicht geschafft, mittels den ausgelesenen Daten die Rufnummer auch registriert wird.
Ich werde wohl noch weiter experementieren müssen, ev. muss ich die Macadressen noch anpassen.
Oder kann der Anbieter mehr als 1 Registrierung erkennen und unterbinden?
Gut, dann experimentiere ruhig weiter so nutzlos, aber bitte nicht in diesem Thread. Dein Ziel hier hast du ja erreicht.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Falls irgendjemand noch "decode_passwords" benutzen sollte und damit die Daten einer anderen Box entschlüsseln will, sollte er folgendes beachten: AVM bezieht in die Bildung des Hashes für das Gerätepasswort auch die Angabe "SerialNumber" aus dem Environment mit ein. Bisher war die m.W. immer 16x "0" und damit konnte man die quasi ignorieren als "Variable" bei diesem Anwendungsfall.
Bei der 7580 (sicherlich auch bei der 7560, vielleicht sieht ja mal jemand nach, der auf eine Zugriff hat) wird nun aber tatsächlich die Seriennummer dort maschinenlesbar hinterlegt ... damit funktioniert das "Mimikry" für eine fremde Box nicht mehr so, wie es bisher möglich war. Nun ist ja das Ganze ohnehin schon älter und muß dringend durch etwas anderes ersetzt werden ... daher passe ich diesen "Spezialfall" (also das Entschlüsseln der Daten einer fremden Box, wobei sich an den variablen Bestandteilen nichts wirklich geändert hat, das ist immer noch ein MD5-Hash über "SerialNumber" (inkl. Zeilenumbruch mit 0x0A), "maca" (ebenfalls inkl. Zeilenumbruch) und "wlan_key" als Kennwort für die interne Verschlüsselung) jetzt nicht mehr an im GitHub-Repository. Wer wirklich noch auf diesen Weg angewiesen sein sollte, der müßte sich (nochmal, es geht nur um "mimicry", der Rest ändert diese Angaben im Environment ja nicht) halt selbst helfen.
Ich wurde auch erst stutzig, als meine Daten sich nicht mehr dekodieren ließen ... ich war einfach zu faul und hatte die Seriennummer fest mit 16x Null verdrahtet.
Bei der 7580 (sicherlich auch bei der 7560, vielleicht sieht ja mal jemand nach, der auf eine Zugriff hat) wird nun aber tatsächlich die Seriennummer dort maschinenlesbar hinterlegt ... damit funktioniert das "Mimikry" für eine fremde Box nicht mehr so, wie es bisher möglich war. Nun ist ja das Ganze ohnehin schon älter und muß dringend durch etwas anderes ersetzt werden ... daher passe ich diesen "Spezialfall" (also das Entschlüsseln der Daten einer fremden Box, wobei sich an den variablen Bestandteilen nichts wirklich geändert hat, das ist immer noch ein MD5-Hash über "SerialNumber" (inkl. Zeilenumbruch mit 0x0A), "maca" (ebenfalls inkl. Zeilenumbruch) und "wlan_key" als Kennwort für die interne Verschlüsselung) jetzt nicht mehr an im GitHub-Repository. Wer wirklich noch auf diesen Weg angewiesen sein sollte, der müßte sich (nochmal, es geht nur um "mimicry", der Rest ändert diese Angaben im Environment ja nicht) halt selbst helfen.
Ich wurde auch erst stutzig, als meine Daten sich nicht mehr dekodieren ließen ... ich war einfach zu faul und hatte die Seriennummer fest mit 16x Null verdrahtet.
Übrigens auch bei der Fritz!Box 6590 Cable. Vielleicht generell bei der "5er-Serie" (wenn man die 7570 mal außen vor lässt)...?
- Mitglied seit
- 7 Okt 2015
- Beiträge
- 9,165
- Punkte für Reaktionen
- 1,426
- Punkte
- 113
Hab folgendes aus meinem Fundus holen können
7560 FW 6.53 + 6.80
7560 FW 6.53 + 6.80
Code:
3.10.12
HWRevision 221
HWSubRevision 1
ProductID Fritz_Box_HW221
SerialNumber 0000000000000000
bootloaderVersion 1.3082- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Danke für die Info ... wie gesagt: Das betrifft ohnehin nur diejenigen, welche die (originalen bzw. ohne Kennwort exportierten) Daten einer fremden Box dekodieren wollen/müssen. Die wären z.B. in den erweiterten Supportdaten im TFFS-Dump enthalten und da steht dann auch wieder die Seriennummer tatsächlich drin bei der 7580 (auch wenn sie eigentlich ja aus dem Urlader stammt). Wobei ich für NAND-TFFS ja noch kein Skript zum "Zerlegen" im Repository habe ...
Aber dank dieses Eintrags der Seriennummer auch im TFFS bleibt es weiterhin dabei, daß man mit einem einzigen Dump einer TFFS-Partition i.d.R. sämtliche in der Box enthaltenen Kennwörter auch entschlüsseln kann - es gilt also weiterhin, daß man diese "erweiterten Supportdaten" besser nirgendwo herumliegen läßt, wo ein "Angreifer" (egal, wer das auch immer sein mag) sie finden könnte (im "Fernzugriff"). Mit einer solchen (Support-)Datei und passendem Equipment kann er dann auch ohne physikalischen Zugang zur Box (hat er den, kann er wieder alles auslesen oder sich auch gleich den passenden Zugang für sich selbst einrichten) die komplette Einstellungsdatei "nachbilden" und zwar - nach Dekodierung - im Klartext.
Angesichts der Tatsache, daß es auch möglich wäre, sich diese Support-Datei über TR-069 zusenden zu lassen (für jemanden, der den ACS beim Provider unter seiner Kontrolle hat), sollte man auch nach jeder Benutzung der "erweiterten Support-Daten" diese Einstellung wieder auf den Standardwert zurücksetzen ... bei der Erzeugung der Support-Datei interessiert es dann niemanden mehr ("argo" als AVM-eigener Service verwendet allerdings eine abgewandelte Methode zum Sammeln der Informationen), woher so ein Aufruf für "/bin/supportdata" am Ende kommt. Die notwendigen Zeichenketten ("X 00040E Supportdata" als "Dateityp" für TR-069-Uploads und "/bin/supportdata" als aufzurufendes Kommando) existieren jedenfalls immer noch in der "usr/share/ctlmgr/libtr069.so", auch wenn ich jetzt den Upload und die Auswirkungen der verschiedenen Einstellungen in der "tr069.cfg" nicht erneut getestet habe (nach meiner "TR-069-Schelte" vor zwei Jahren).
Wobei es selbst die Zeichenkette "/usr/bin/tr069fwupdate configexport > %s; /usr/bin/ftpput%s "%s"%s "%s" -P %d "%s" "%s" %s 2>/var/dl_err" als auszuführendes Kommando immer noch gibt (das Ergebnis nähert sich damit schon sehr an das an, was man mühsam aus dem TFFS-Dump extrahieren müßte) ... am fehlenden Kennwort beim Aufruf von "tr069fwupdate configexport" kann man dann erkennen, daß hier eine Datei exportiert wird, die wieder das "Gerätekennwort" anstelle eines angegebenen verwendet (man braucht also wieder die drei "Komponenten" für die Entschlüsselung), aber der nachfolgende Aufruf von "ftpput" wird mit hoher Wahrscheinlichkeit dann eben auch wieder genau diese Datei übertragen und das ohne jede zusätzliche Sicherungsmaßnahme wie TLS - so etwas kennt nämlich das "ftpput"-Applet gar nicht. Wenn man Glück hat, bleibt noch ein "Der Dienstanbieter hat Informationen aus diesem Gerät abgerufen." im Ereignisprotokoll als "Spur" übrig nach einem solchen Zugriff.
Aber dank dieses Eintrags der Seriennummer auch im TFFS bleibt es weiterhin dabei, daß man mit einem einzigen Dump einer TFFS-Partition i.d.R. sämtliche in der Box enthaltenen Kennwörter auch entschlüsseln kann - es gilt also weiterhin, daß man diese "erweiterten Supportdaten" besser nirgendwo herumliegen läßt, wo ein "Angreifer" (egal, wer das auch immer sein mag) sie finden könnte (im "Fernzugriff"). Mit einer solchen (Support-)Datei und passendem Equipment kann er dann auch ohne physikalischen Zugang zur Box (hat er den, kann er wieder alles auslesen oder sich auch gleich den passenden Zugang für sich selbst einrichten) die komplette Einstellungsdatei "nachbilden" und zwar - nach Dekodierung - im Klartext.
Angesichts der Tatsache, daß es auch möglich wäre, sich diese Support-Datei über TR-069 zusenden zu lassen (für jemanden, der den ACS beim Provider unter seiner Kontrolle hat), sollte man auch nach jeder Benutzung der "erweiterten Support-Daten" diese Einstellung wieder auf den Standardwert zurücksetzen ... bei der Erzeugung der Support-Datei interessiert es dann niemanden mehr ("argo" als AVM-eigener Service verwendet allerdings eine abgewandelte Methode zum Sammeln der Informationen), woher so ein Aufruf für "/bin/supportdata" am Ende kommt. Die notwendigen Zeichenketten ("X 00040E Supportdata" als "Dateityp" für TR-069-Uploads und "/bin/supportdata" als aufzurufendes Kommando) existieren jedenfalls immer noch in der "usr/share/ctlmgr/libtr069.so", auch wenn ich jetzt den Upload und die Auswirkungen der verschiedenen Einstellungen in der "tr069.cfg" nicht erneut getestet habe (nach meiner "TR-069-Schelte" vor zwei Jahren).
Wobei es selbst die Zeichenkette "/usr/bin/tr069fwupdate configexport > %s; /usr/bin/ftpput%s "%s"%s "%s" -P %d "%s" "%s" %s 2>/var/dl_err" als auszuführendes Kommando immer noch gibt (das Ergebnis nähert sich damit schon sehr an das an, was man mühsam aus dem TFFS-Dump extrahieren müßte) ... am fehlenden Kennwort beim Aufruf von "tr069fwupdate configexport" kann man dann erkennen, daß hier eine Datei exportiert wird, die wieder das "Gerätekennwort" anstelle eines angegebenen verwendet (man braucht also wieder die drei "Komponenten" für die Entschlüsselung), aber der nachfolgende Aufruf von "ftpput" wird mit hoher Wahrscheinlichkeit dann eben auch wieder genau diese Datei übertragen und das ohne jede zusätzliche Sicherungsmaßnahme wie TLS - so etwas kennt nämlich das "ftpput"-Applet gar nicht. Wenn man Glück hat, bleibt noch ein "Der Dienstanbieter hat Informationen aus diesem Gerät abgerufen." im Ereignisprotokoll als "Spur" übrig nach einem solchen Zugriff.
Ich habe letztens mit "decode_passwords" mal versucht die Passwörter in der ar7.cfg von einer 6490 auf einer 7490 zu entschlüsseln (wlan_key und maca entsprechend angegeben beim Skriptaufruf), allerdings kam da nichts brauchbares dabei raus. Nach den letzten Posts hier im Thread hatte ich schon Hoffnung geschöpft, dass es eventuell an der SerialNumber liegt, allerdings ist die bei der 6490 ebenfalls noch "0000000000000000".
In meinem 6490 FW Fundus ist die 06.24 die älteste Version, da wurde in der webdavcfginfo schon die -p Option entfernt, eine noch ältere FW habe ich nirgends auftreiben können. Insofern wäre es schon interessant, decode_passwords zum Laufen zu bekommen.
Hat da jemand schon ähnliches probiert und eine Lösung bzw. einen Hinweis was ich noch probieren könnte?
Es ist nicht kriegsentscheidend, vermutlich würde es auch über den Umweg des Exports und das PHP Skript gehen. Auf der Konsole wäre es halt schneller.
In meinem 6490 FW Fundus ist die 06.24 die älteste Version, da wurde in der webdavcfginfo schon die -p Option entfernt, eine noch ältere FW habe ich nirgends auftreiben können. Insofern wäre es schon interessant, decode_passwords zum Laufen zu bekommen.
Hat da jemand schon ähnliches probiert und eine Lösung bzw. einen Hinweis was ich noch probieren könnte?
Es ist nicht kriegsentscheidend, vermutlich würde es auch über den Umweg des Exports und das PHP Skript gehen. Auf der Konsole wäre es halt schneller.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Es wird in Kürze eine neue Version von "decode_passwords" von mir geben (das meint, noch vor Pfinggggggschten - der Branch für den bisherigen Stand ist schon angelegt im Repository und es geht im "master" jetzt weiter), die nur ein OpenSSL für das Dekodieren braucht und in der Lage ist, die Daten sowohl auf einer FRITZ!Box als auch außerhalb zu entschlüsseln. Diese Version wird dann auch verwendbar sein, um direkt Export-Dateien zu dekodieren, wenn der Benutzer das korrekte Kennwort hat und es wird - neben den Shell-Skripten zum Aufzeigen der Arbeitsweise und als "slow solution" - noch eine Implementierung in C geben, die man sich dann passend übersetzen kann/muß.
Also noch ein ganz klein wenig Geduld ... dann braucht es auch den Exploit von M.Engelke nicht mehr unbedingt, der ja leider ab 2FA nur noch funktioniert, wenn man diese deaktiviert.
Das erste (Teil-)Skript habe ich ja schon (versehentlich) eingecheckt, andere Dateien halte ich noch zurück (zumindest die Synchronisation mit dem öffentlichen Repository), damit gar nicht erst jemand in die Versuchung kommt, mir zeigen zu wollen, wie man es richtig oder gar besser machen muß, bevor ich damit halbwegs fertig bin (und selbst die Gelegenheit hatte, eine "stable"-Version erst einmal fertigzustellen) und parallel dazu einen neuen "Info"-Thread für diese AVM-Verschlüsselung eröffnet und diese "seziert" habe.
Ich habe mich diesem Thema auch deshalb erneut widmen müssen, weil eben ein paar neue Modelle mit geänderten Eigenschaften dazugekommen sind, seit ich das zuletzt angesehen habe. So gibt es neben der Seriennummer im Environment schon wesentlich länger auch noch die "tr069_passphrase", die ebenfalls in den Geräte-Schlüssel eingeht - auch die war/ist (teils absichtlich) noch nicht berücksichtigt in der öffentlich zugänglichen Version. Wenn das also bei Dir nicht funktioniert, müßtest Du ggf. noch die "tr069_passphrase" in der Kopie des Environments löschen oder so einstellen, wie sie auf dem Ursprungsgerät vorliegt (die DOCSIS-Boxen haben i.d.R. einen konfigurierten CWMP-Account).
Für die 6360 funktionierte aus genau diesem Grund auch das Dekodieren zum Zeitpunkt der Veröffentlichung von v0.2 nicht. Das steht so auch in der alten README.md, inkl. der Vermutung, daß es da weitere Daten aus dem Enviroment gibt, die verwendet werden ... ich habe später nur versäumt, diese neue Erkenntnis zu "tr069_passphrase" auch in die öffentlich zugänglichen Versionen einzuarbeiten (es gab ja auch schon kein brauchbares "webdavcfginfo" von AVM mehr, was das gesamte Skript etwas unnütz machte ohne eigenen Dekoder und den wollte ich damals nicht direkt veröffentlichen) und ich bin gerade erst dabei, die diversen Wege (und Skripte), die für das Bilden des Geräte-Kennworts in Frage kommen, zu einer gemeinsamen Datei zusammenzufassen.
Auch das Kennwort für den Export ohne benutzereigenes Kennwort wird ja aus den Daten der Box gebildet (das sind dann die Dateien, die nur in der originalen Box wiederhergestellt werden konnten), aber da entfällt dann wieder der "wlan_key" - ich habe gerade erst das "device_password" noch einmal so geändert (allerdings noch kein "push" im Repository ausgeführt), daß auch dieser Fall (nur zwei Parameter) in demselben Skript abgehandelt werden kann ... bisher hatte ich dafür noch ein gesondertes und auch für Boxen mit CWMP-Account habe ich noch weitere (auch für auf der Box (wo man die Daten aus dem Environment lesen kann) und "nicht auf der Box" gibt es unterschiedliche Versionen bisher) - das muß erst mal alles zusammengefaßt werden, was da im Laufe der Zeit (bzw. Jahre) so entstanden ist.
Also noch ein ganz klein wenig Geduld ... dann braucht es auch den Exploit von M.Engelke nicht mehr unbedingt, der ja leider ab 2FA nur noch funktioniert, wenn man diese deaktiviert.
Das erste (Teil-)Skript habe ich ja schon (versehentlich) eingecheckt, andere Dateien halte ich noch zurück (zumindest die Synchronisation mit dem öffentlichen Repository), damit gar nicht erst jemand in die Versuchung kommt, mir zeigen zu wollen, wie man es richtig oder gar besser machen muß, bevor ich damit halbwegs fertig bin (und selbst die Gelegenheit hatte, eine "stable"-Version erst einmal fertigzustellen) und parallel dazu einen neuen "Info"-Thread für diese AVM-Verschlüsselung eröffnet und diese "seziert" habe.
Ich habe mich diesem Thema auch deshalb erneut widmen müssen, weil eben ein paar neue Modelle mit geänderten Eigenschaften dazugekommen sind, seit ich das zuletzt angesehen habe. So gibt es neben der Seriennummer im Environment schon wesentlich länger auch noch die "tr069_passphrase", die ebenfalls in den Geräte-Schlüssel eingeht - auch die war/ist (teils absichtlich) noch nicht berücksichtigt in der öffentlich zugänglichen Version. Wenn das also bei Dir nicht funktioniert, müßtest Du ggf. noch die "tr069_passphrase" in der Kopie des Environments löschen oder so einstellen, wie sie auf dem Ursprungsgerät vorliegt (die DOCSIS-Boxen haben i.d.R. einen konfigurierten CWMP-Account).
Für die 6360 funktionierte aus genau diesem Grund auch das Dekodieren zum Zeitpunkt der Veröffentlichung von v0.2 nicht. Das steht so auch in der alten README.md, inkl. der Vermutung, daß es da weitere Daten aus dem Enviroment gibt, die verwendet werden ... ich habe später nur versäumt, diese neue Erkenntnis zu "tr069_passphrase" auch in die öffentlich zugänglichen Versionen einzuarbeiten (es gab ja auch schon kein brauchbares "webdavcfginfo" von AVM mehr, was das gesamte Skript etwas unnütz machte ohne eigenen Dekoder und den wollte ich damals nicht direkt veröffentlichen) und ich bin gerade erst dabei, die diversen Wege (und Skripte), die für das Bilden des Geräte-Kennworts in Frage kommen, zu einer gemeinsamen Datei zusammenzufassen.
Auch das Kennwort für den Export ohne benutzereigenes Kennwort wird ja aus den Daten der Box gebildet (das sind dann die Dateien, die nur in der originalen Box wiederhergestellt werden konnten), aber da entfällt dann wieder der "wlan_key" - ich habe gerade erst das "device_password" noch einmal so geändert (allerdings noch kein "push" im Repository ausgeführt), daß auch dieser Fall (nur zwei Parameter) in demselben Skript abgehandelt werden kann ... bisher hatte ich dafür noch ein gesondertes und auch für Boxen mit CWMP-Account habe ich noch weitere (auch für auf der Box (wo man die Daten aus dem Environment lesen kann) und "nicht auf der Box" gibt es unterschiedliche Versionen bisher) - das muß erst mal alles zusammengefaßt werden, was da im Laufe der Zeit (bzw. Jahre) so entstanden ist.
Cool, vielen Dank.
Ich probiere die Erweiterung von decode_passwords auf meiner 7490 um "tr069_passphrase" diese Woche mal aus. Stellt sich mir gerade nur die Frage, ob die zum Dekodieren verwendeten closed-source Komponenten auf der 7490 die "tr069_passphrase" berücksichtigen werden. Mal sehen.
Ich probiere die Erweiterung von decode_passwords auf meiner 7490 um "tr069_passphrase" diese Woche mal aus. Stellt sich mir gerade nur die Frage, ob die zum Dekodieren verwendeten closed-source Komponenten auf der 7490 die "tr069_passphrase" berücksichtigen werden. Mal sehen.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Die neue Version von decoder ist jetzt online.
Das geht nun alles auch ohne irgendwelche AVM-Unterstützung, es braucht nur ein OpenSSL-CLI-Programm für die Shell-Skripte bzw. OpenSSL bei der Übersetzung des alternativen (und natürlich viel schnelleren) C-Programms.
Für eine Beschreibung der Arbeitsweise der AVM-Verschlüsselung (bzw. genauer für die Entschlüsselung) und die genauen Parameter beim Aufruf werde ich aber einen neuen Thread aufmachen und solange das C-Programm noch nicht "fix" ist bei den Parametern, kann/wird sich da noch einiges ändern.
Mit einigen Sonderfällen hat die binäre Version noch ihre Probleme (das liegt am Handling beim Lesen von Dateien, weil ich da auch direkt ein TFFS-Device-File als Eingabe verarbeiten will und damit das Lesen nur in eine Richtung möglich ist bei "char I/O") und mit einigen anderen kommen dann die Shell-Skripte nicht klar (in erster Linie mit Sonderzeichen im Klartext, die lt. AVM ohnehin "verboten" sind).
Unter anderem sind davon bei der C-Variante auch praktisch alle verschlüsselten Daten betroffen, deren kodierte Darstellung (ohne die Dollarzeichen) 128 Byte lang ist ... die kann das C-Programm im Moment noch nicht sauber verarbeiten und da müßte man auf die Shell-Variante zurückgreifen.
Aber das sollte nicht dagegen sprechen, daß man es mal mit der neuen Version probieren kann ... die verbleibenden Probleme räume ich Schritt für Schritt aus. Das ist in der C-Implementierung ein schrittweises Zusammenführen verschiedener einzelner Programme inkl. Refactoring verschiedener Funktionen gewesen - das dauert noch ein wenig, bis das wieder richtig rund läuft.
Die C-Variante habe ich bisher unter openSuSE und unter 06.83 auf einer 7490 getestet. Passend übersetzt, sollte die auch auf der 6490 laufen ... die Frage LE vs. BE dürfte keine Rolle spielen, meine Tests haben das ja bereits beides abgedeckt. Auch die Frage 32- oder 64-Bit sollte nicht entscheidend sein, auf der 7490 läuft es bei mir als 32-Bit-Version und unter openSuSE als 64-Bit-Variante.
Das geht nun alles auch ohne irgendwelche AVM-Unterstützung, es braucht nur ein OpenSSL-CLI-Programm für die Shell-Skripte bzw. OpenSSL bei der Übersetzung des alternativen (und natürlich viel schnelleren) C-Programms.
Für eine Beschreibung der Arbeitsweise der AVM-Verschlüsselung (bzw. genauer für die Entschlüsselung) und die genauen Parameter beim Aufruf werde ich aber einen neuen Thread aufmachen und solange das C-Programm noch nicht "fix" ist bei den Parametern, kann/wird sich da noch einiges ändern.
Mit einigen Sonderfällen hat die binäre Version noch ihre Probleme (das liegt am Handling beim Lesen von Dateien, weil ich da auch direkt ein TFFS-Device-File als Eingabe verarbeiten will und damit das Lesen nur in eine Richtung möglich ist bei "char I/O") und mit einigen anderen kommen dann die Shell-Skripte nicht klar (in erster Linie mit Sonderzeichen im Klartext, die lt. AVM ohnehin "verboten" sind).
Unter anderem sind davon bei der C-Variante auch praktisch alle verschlüsselten Daten betroffen, deren kodierte Darstellung (ohne die Dollarzeichen) 128 Byte lang ist ... die kann das C-Programm im Moment noch nicht sauber verarbeiten und da müßte man auf die Shell-Variante zurückgreifen.
Aber das sollte nicht dagegen sprechen, daß man es mal mit der neuen Version probieren kann ... die verbleibenden Probleme räume ich Schritt für Schritt aus. Das ist in der C-Implementierung ein schrittweises Zusammenführen verschiedener einzelner Programme inkl. Refactoring verschiedener Funktionen gewesen - das dauert noch ein wenig, bis das wieder richtig rund läuft.
Die C-Variante habe ich bisher unter openSuSE und unter 06.83 auf einer 7490 getestet. Passend übersetzt, sollte die auch auf der 6490 laufen ... die Frage LE vs. BE dürfte keine Rolle spielen, meine Tests haben das ja bereits beides abgedeckt. Auch die Frage 32- oder 64-Bit sollte nicht entscheidend sein, auf der 7490 läuft es bei mir als 32-Bit-Version und unter openSuSE als 64-Bit-Variante.
Zuletzt bearbeitet:
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Moins
Wird die C Variante auch Exportdateien unterstützen und kann die dann auch "out of the box" beispielsweise auf/für einen Raspberry kompiliert werden ?
...also ohne Crosscompilebuiltumgebung
Wird die C Variante auch Exportdateien unterstützen und kann die dann auch "out of the box" beispielsweise auf/für einen Raspberry kompiliert werden ?
...also ohne Crosscompilebuiltumgebung
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,275
- Punkte für Reaktionen
- 1,751
- Punkte
- 113
Die C-Variante kann (theoretisch) jetzt schon Export-Dateien (mit bekanntem Kennwort) - es gibt noch ein oder zwei Probleme bei bestimmten Längen von kodierten Daten. Die kriege ich hoffentlich zeitnah noch in den Griff.
Einfach mal mit "decoder decode_export [password] < export.file" probieren (das "make" im "source"-Ordner sollte auf praktisch jeder Linux-Installation mit "gcc" und "OpenSSL" klappen) ... es sollte zumindest durchlaufen, wenn auch vielleicht ein paar Werte fehlen und einige nicht richtig übersetzt werden. Die Variante ohne Password würde nur auf der Box und nur für ältere Dateien (ohne Kennwort beim Export) funktionieren.
Das ganze Buffer-Handling mit den "corner cases" ist da etwas komplizierter ... ich baue einfach als Nächstes eine Option ein, die eingelesene Datei (ich gehe davon aus, daß da keine Repositionierungen und mehrfaches Lesen funktionieren, wie da z.B. bei einem TFFS-Node der Fall wäre) in einem einzigen größeren Buffer zu konsolidieren, wenn sie mit dem Standard von 8 KB als Blockgröße eingelesen wurde. Dann haben sich die Grenzfälle, wo ein Wert ggf. in mehr als einem solchen Puffer steht, automatisch mit erledigt.
Einfach mal mit "decoder decode_export [password] < export.file" probieren (das "make" im "source"-Ordner sollte auf praktisch jeder Linux-Installation mit "gcc" und "OpenSSL" klappen) ... es sollte zumindest durchlaufen, wenn auch vielleicht ein paar Werte fehlen und einige nicht richtig übersetzt werden. Die Variante ohne Password würde nur auf der Box und nur für ältere Dateien (ohne Kennwort beim Export) funktionieren.
Das ganze Buffer-Handling mit den "corner cases" ist da etwas komplizierter ... ich baue einfach als Nächstes eine Option ein, die eingelesene Datei (ich gehe davon aus, daß da keine Repositionierungen und mehrfaches Lesen funktionieren, wie da z.B. bei einem TFFS-Node der Fall wäre) in einem einzigen größeren Buffer zu konsolidieren, wenn sie mit dem Standard von 8 KB als Blockgröße eingelesen wurde. Dann haben sich die Grenzfälle, wo ein Wert ggf. in mehr als einem solchen Puffer steht, automatisch mit erledigt.
Neueste Beiträge
-
[Frage] Dect-WS500S Verbindungen an Compact 4000
- Letzte: oezi
-
Analoges Wählgerät einer Alarmanlage an VoIP betreiben ...
- Letzte: provisorischerFtmmsch
-
[Frage] Kompletter Ausfall von DNS over TLS (DoT)- Letzte: stoney
-
Fritz Dect200: Temperaturabhängig plus manuelle Schaltung
- Letzte: toko42
