[Problem] ar7.cfg von 3170 lässt sich nicht entschlüsseln

[T0814S]

Hallo zusammen,

ich versuche seit mehreren Tagen auf verschiedensten Wegen, das Passwort meiner alten 3170 auszulesen. Die 3170 ist nur dafür da, um alles mögliche auszuprobieren, damit ich dann bei einem Bekannten das Passwort seiner 7590 herausfinden kann.

Ich habe bisher auf der 3170 freetz-ng installiert und decrypt-fritzos-cfg probiert, allerdings gibt das nur "decrypt failed" zurück. Also habe ich mal die ar7.cfg und das urlader environment kopiert, um möglichst viel von der Entschlüsselung mit dem decoder von PeterPawn selbst zu machen. Ich hab also mit

device_password -v 0000000000000000 BC:05:43:63:45:80 6753352899388991
device_password: device key value is 0x0A1287EE4ADE5DE429288CE09EC7F6BC
0x0A1287EE4ADE5DE429288CE09EC7F6BCmit

meinen Key generiert und mit

decode_secret -v QYJN1Y6Y2YV26CUL5KWTXWK1MRWWZTSOZFYUSG55J3SFIGRPJ4NWC5DEVAQFER4W5O6L2256QV1YWAAA 0A1287EE4ADE5DE429288CE09EC7F6BC
decode_secret: key      : (016) 0x0A1287EE4ADE5DE429288CE09EC7F6BC
decode_secret: base32   : (080) QYJN1Y6Y2YV26CUL5KWTXWK1MRWWZTSOZFYUSG55J3SFIGRPJ4NWC5DEVAQFER4W5O6L2256QV1YWAAA
decode_secret: input    : (050) 0x8612DD63F8DE2BBF8A8BF2AD3BD95A646D6CCE4EC971491BDE4F24541A2F4F5B617864A8205247B6F3BEBDEFDF85758B0000
decode_secret: iv       : (016) 0x8612DD63F8DE2BBF8A8BF2AD3BD95A64
decode_secret: enc'd    : (034) 0x6D6CCE4EC971491BDE4F24541A2F4F5B617864A8205247B6F3BEBDEFDF85758B0000
decode_secret: dec'd    : (032) 0x5A6523FFA5D7333A17706FBDC9215F34EA6E87B141D72EF9D3742EEEC83F49D1
decode_secret: The specified password is wrong.

versucht, das Passwort zu entschlüsseln, allerdings scheint das Passwort falsch zu sein. Dabei hab ich alles sowohl mit den Scripts, als auch mit dem C-Programm getestet.
Unter /proc/sys/urlader/environment ist auch kein "tr069_passphrase", also sollte mein Passwort (vorausgesetzt ich hab nichts falsch aus dem urlader environment kopiert) soweit ich weiß korrekt sein.

Also was habe ich falsch gemacht? Wenn ihr mehr Dateien oder Infos braucht, dann fragt gerne. Wollte den Beitrag hier erstmal kurz halten.

PS: dass ich hier Passwörter leake ist mir ziemlich egal, schließlich ist die Box nicht mehr an die große weite Welt angeschlossen

 

[NDiIPP]

Wozu die Umstände? Bei einer 3170 gibt es doch noch die allcfgconv welche die Option -C zulässt…

 

[T0814S]

Ja, funktioniert auch ohne Probleme. Mit ein bisschen Nachdenken würde mir das Passwort wahrscheinlich sogar noch einfallen und ein Reset wäre auch nicht tragisch. Aber ich möchte für einen Bekannten das Passwort von seiner 7590 rausfinden. Und damit dass halbwegs schnell geht, möchte ich vorher wissen was ich mache und es auf meiner 3170 ausprobiert haben. Deswegen beschränke ich mich erstmal auf alle Möglichkeiten, die die 7590 auch hat, daher kein "allcfgconv".

 

[NDiIPP]

I.V.m. Freetz-NG und dem Paket "decrypt FRITZ!OS configs" kann das bspw. auf der Konsole dann mit folgendem Befehl durchgeführt werden:
decoder decrypt-fritzos-cfg < /var/flash/ar7.cfg > /var/media/ftp/decrypted_ar7.cfg

Könnte man sich dann bspw. mit einem
cat /var/media/ftp/decrypted_ar7.cfg
auch gleich auf der Konsole anzeigen lassen.

Mehr ist doch da gar nicht nötig…

 

[T0814S]

Dachte ich auch, aber ich kriege in der Rudi-Shell zwei mal [33m[1mdecrypt failed[0m als Antwort. In der decrypted_ar7.cfg ist das Passwort dann immer noch verschlüsselt. Die eckigen Klammern und die dazugehörigen Zeichen habe ich bisher als irgendein Codierungsproblem zwischen der Box und meinem Computer/Browser abgetan.

 

[NDiIPP]

Kann ich nicht nachvollziehen, funktioniert bei mir einwandfrei (7490, 7530, 7560, 7580 und 7590). Sowohl per ssh als auch per Rudi-Shell.

Edit:
Allerdings habe ich keine Ahnung ob die alte 4.8xer Firmware der 3170 i.V.m. Freetz-NG und den decoder-Tools von @PeterPawn überhaupt ohne weiteres funktioniert, das ist doch alles uralt…

Edit #2:
Mit den älteren FRITZ!OS 6.8x basierten Modellen (u.a. 7272 oder 7390) funktioniert das ebenfalls einwandfrei.

 

[PeterPawn]

irgendein Codierungsproblem

Das sind nur ANSI-Codes für das Einfärben von Texten.

---

Ich kann das gerade auf dem Tablet nicht sinnvoll nachzählen bzw. ausmessen - wieviele Nullen/Stellen hat denn die gezeigte "Seriennummer"?

Ich weiß nicht mehr sicher, wieviele es sein sollten - aber die reale Seriennummer (die bei einer 7590 dann auch im Environment steht) hat entweder eine Stelle mehr oder eine weniger als bei den ganzen Nullen … so weit erinnere ich mich noch.

Irgendwo habe ich das vermutlich auch beschrieben - meine Aufzeichnungen dazu sind leider einem SSD-Schaden zum Opfer gefallen. Event. gibt es auch noch Commits im GitHub-Repo für den Decoder, wo das erwähnt wird.

 

[T0814S]

Die Seriennummer sollte aus 16 Nullen bestehen, so wie es auch im Environment steht. Die reale Seriennummer besteht afaik aus 15 Stellen. Ich kann heute abend mal verschiedene Seriennummern für den Schlüssel probieren.

Kann ich nicht nachvollziehen, funktioniert bei mir einwandfrei

Dann weiß ich immerhin, dass kein total offensichtlicher Fehler von mir vorliegt, dankeschön!

 

[PeterPawn]

vorausgesetzt ich hab nichts falsch aus dem urlader environment kopiert

Gibt es denn einen anderen Device-Key, wenn Du das nicht mit device_password, sondern mit password_from_device angehst?

Das sollte ja auf dem Gerät problemlos funktionieren, da dort das Environment direkt gelesen werden kann.

---

Mir ist gerade noch eine vollkommen verrückte Idee gekommen (deren Ergebnis ich aber auch nicht vorhersagen kann) ... Du könntest natürlich auch mal versuchen, die originalen Quellen aus meinem decoder-Repository zu verwenden anstelle irgendeines - eher undefinierten - Standes, der in Freetz-NG verwendet wird: https://github.com/Freetz-NG/freetz...ritzos-cfg/decrypt-fritzos-cfg.mk#L1C22-L1C62

Denn das hier: https://github.com/PeterPawn/decoder/commits/84e9555131adb3c9d9bf49905bbb803e075c90b1 ist irgendwo im Niemandsland ... ein uralter Stand aus 2018, der auch von mir selbst gar nicht irgendwie getaggt oder gar "released" wurde. Damit steht zumindest bis zum Beweis des Gegenteils der Verdacht im Raum, daß die doch sehr unterschiedlichen Ergebnisse (von @NDiIPP und Dir) am Ende doch nur darauf zurückzuführen sind, daß er einen aktuellen(!) Stand verwendet und nicht irgendwelche ollen Kamellen.

 

[T0814S]

Gibt es denn einen anderen Device-Key, wenn Du das nicht mit device_password, sondern mit password_from_device angehst?

Nein, genau der gleiche Schlüssel. Ich hab jetzt auch 15 Nullen und die tatsächliche Seriennummer ausprobiert, gibt natürlich andere Schlüssel, die sind aber genau so falsch.

Du könntest natürlich auch mal versuchen, die originalen Quellen aus meinem decoder-Repository zu verwenden

Hatte ich nicht geschrieben, mache ich aber tatsächlich schon die ganze Zeit. Alles was nicht auf der Box selbst läuft (und das ist alles, außer den Befehlen von @NDiIPP und meinem aller ersten Versuch, die gesamte Fehlersuche mache ich auf meinem PC) hab ich mir vor ein paar Tagen aus deinem Repo runtergeladen. Alles was ich mit -v an Infos kriege, ist genau das gleiche.

 

[PeterPawn]

Wo kommt denn der Wert her, den Du bei decode_secret entschlüsseln lassen willst? So langsam gehen ja die Optionen aus, wo da noch ein Fehler sein könnte. Welche Version hat denn die Firmware, die Du auf der 3170 verwendest (vor 05.x nannte AVM die ja offiziell noch nicht FRITZ!OS)?

Ich weiß leider auch nicht mehr, ob ich bis zur 7170 zurück getestet hatte und meine Aufzeichnungen existieren eben nicht mehr.

 

[T0814S]

Direkt aus der ar7.cfg, mit cat /var/flash/ar7.cfg ausgeben lassen und dann von

webui {
        username = "";
        password = "$$$$QYJN1Y6Y2YV26CUL5KWTXWK1MRWWZTSOZFYUSG55J3SFIGRPJ4NWC5DEVAQFER4W5O6L2256QV1YWAAA";
        expertmode = no;
        wizard_completed = no;
        event_filter = 0;
        read_access_without_login = no;
}

das verschlüsselte Passwort ohne die Dollar-Zeichen kopiert. Firmware Version ist 49.04.58.
Inzwischen würde ich auch akzeptieren, dass die 3170 einfach anders verschlüsselt als es aktuellere Boxen tun, eigentlich wollte ich ja nur alles mögliche für die 7590 testen.

 

[Joe_57]

Früher war es möglich, das verschlüsselte Passwort "$$$$xxxxxx" einfach durch ein neues im Klartext "NeuesPasswort" (ohne $-Zeichen) zu ersetzen und die ar7.cfg wieder auf die Box zurück zu schreiben.
Beim nächsten Start hat die Box dann das neue Passwort selbst verschlüsselt und wieder in die ar7.cfg eingetragen.
Klappt das nicht mehr?

Ausserdem gibt es ja noch die Tools von M.Engelke:

Fritz!Box JSTool

Checksum mit JavaScript berechnen, Konfig-Datei entschlüsseln, ShrewVPN-Dateien erstellen, system_status / jason_boxinfo anzeigen, Zwei-Faktor-Authentisierung

www.mengelke.de

 

[NDiIPP]

Klappt das nicht mehr?

Wenn man das Passwort für das WebGUI nicht kennt? Nein, weder früher noch aktuell (von evtl. bestehenden Sicherheitslücken wie bspw. der webcm-Lücke mal abgesehen). Mit funktionierendem Konsolenzugriff (bspw. auch per modifizierter FW) gibt es aber andere Möglichkeiten (und um eine davon geht es hier gerade)…

 

[PeterPawn]

Beim nächsten Start hat die Box dann das neue Passwort selbst verschlüsselt und wieder in die ar7.cfg eingetragen.

Das wage ich mal zu bezweifeln ... denn das (erneute) Verschlüsseln von "secrets" erfolgt unmittelbar beim Schreiben der Settings durch das FRITZ!OS (und das betrifft tatsächlich ALLE verschlüsselt gespeicherten Werte bei JEDEM Speichern, denn die werden jedesmal komplett neu verschlüsselt). Am FRITZ!OS vorbei kann man diese (Pseudo-)Dateien für das TFFS nur dann ändern, wenn man zusätzlich Shell-Zugriff hat - und auch dann muß man (bei neueren Versionen, nicht bei der alten 04.8x) noch aufpassen, daß man dafür den ctlmgr zuvor anhält, denn der verwendet seit längerem schon ein (internes) Caching vieler Einstellungen und inzwischen auch ein "lazy write" beim Schreibzugriff, damit nicht jede einzelne Änderungen sofort (gesondert) ins TFFS geschrieben werden muß.

Das gilt zwar alles noch nicht für die 3170, aber da es ja am Ende um eine 7590 geht, wollte ich es zumindest mal erwähnen bzw. richtigstellen.

---

Ausserdem gibt es ja noch die Tools von M.Engelke:

Und was genau machen die jetzt anders, als die hier "besprochenen" Tools?

Laß mich raten: Du weißt es nicht.

Ich behaupte mal: Praktisch nichts ... zumindest soweit das mir bekannt ist: http://www.mengelke.de/Projekte/FritzBox-JSTool#credit

---

So richtig habe ich immer noch nicht verstanden, was denn jetzt bei der fraglichen 7590 das Problem ist ... aber ggf. hilft auch hier ja ein "selbstgebautes Firmware-Image" (für die 7590 müßte man das tatsächlich noch selbst bauen - die Prinzipien sind klar, aber vorhandene Skript-Dateien müßten dafür leicht abgewandelt werden), um wieder Zugriff auf die FRITZ!Box mit dem "vergessenen" Kennwort zu erlangen ... wenn nicht sogar (sofern man den Versand von E-Mails durch das FRITZ!OS zuvor schon konfiguriert hatte) das Zurücksetzen des vergessenen Kennworts über die Mechanismen im FRITZ!OS möglich sein sollte (das gab es bei der 04.8x auch noch nicht).

Eine Idee, wie man dabei vorgehen könnte, habe ich hier: https://www.ip-phone-forum.de/threa...l-recovery-a-la-avm-oder-besser-nicht.294386/ skizziert und (für VR9-Boxen, wozu die 7590 aber nicht zählt) auch passend umgesetzt. Die dabei verwendeten Skript-Dateien (spez. diese: https://github.com/PeterPawn/YourFritz/blob/main/toolbox/scripts/add_user_to_fritzos) sollten auch heute noch funktionieren und das auch auf einer 7590. Notfalls konvertiert das FRITZ!OS das dann beim nächsten Start passend ...

Man bräuchte dann halt nur ein Image mit einem System, welches die passenden Daten verwendet ... den richtigen Kernel aus einem AVM-Image und ein selbstgebautes SquashFS-Image, wo aus der /etc/inittab heraus dann der neue Benutzer eingetragen wird - fertig ist die Laube.

Ich habe das bisher bloß noch nie als (weiteres) Skript im toolbox-Abschnitt veröffentlicht, weil da schon jeder seinen eigenen Benutzernamen und ein passendes Kennwort für den neuen Benutzer verwenden sollte und mir daher ein "generisches Image" nicht zielführend erscheint - zumal die anderen Optionen (@CompatMode bzw. @SkipAuthFromHomeNetwork) seit 07.2x (wo AVM die Anmeldungen umgestellt hat) nicht mehr funktionieren bzw. nicht mehr von mir getestet wurden.

Die vorhandenen Skripte gehen noch von einem AVM-Image mit ext2-Format und gefaketem SquashFS-Header aus ... es geht also schon beim (automatischen) Auspacken los. Macht man das aber (bei passendem Verständnis, was man da eigentlich macht) von Hand, ist das - ggf. auch unter Verwendung der vorhandenen Skript-Dateien als Template, speziell bei der "Installation" der BusyBox-Kommandos - eigentlich nur noch eine Fingerübung ... sofern man die passenden Grundlagenkenntnisse hat (was hier ja der Fall sein könnte).

---

Andererseits könnte man natürlich auch hingehen und gleich ein komplettes AVM-System verwenden (das darf man dann halt nicht weitergeben wg. der AVM-Lizenz) - dann muß man nur das Skript, mit dem sich das System ansonsten selbst im Flash-Speicher verewigt, durch eines ersetzen, welches den neuen (administrativen) Benutzer einträgt und dann das System (wie nach dem Flashen) neu startet. Dieses Image dann einmalig über den Bootloader gestartet (wie das geht, ist auch hier irgendwo mehrfach beschrieben) und man hat sein Problem auch wieder (auf einigermaßen elegantem Wege) gelöst ... denn dazu braucht es nichts weiter, als die SquashFS-Tools zum (Ent-)Packen von AVM-Images (da müssen also die Patches für das AVM-Format enthalten sein) und das oben verlinkte Shell-Skript für den neuen Benutzer.

Die Tools gibt es fertig übersetzt (https://github.com/PeterPawn/yf_bin/tree/10853cff8192081b282652bfa3e1082ef551b68a/squashfs) und ansonsten muß man nur noch mit der Shell und einem Editor einigermaßen umgehen können. Als Vorlage für die auszuführenden Kommandos kann man dann z.B. das hier verwenden: https://www.ip-phone-forum.de/threa...nand-basierte-fritz-boxen.273304/post-2497242 - wobei an die Stelle von run_modscripts (https://github.com/PeterPawn/modfs/blob/b6f94fb91e6a78fe7cb311bdbfe8b74ce0ace5c7/modify.sh#L79) dann halt der Austausch der AVM-Datei zum Flashen (unter /etc/init.d/E03-flash_update, iirc) gegen das Skript zum Anlegen des neuen Benutzers tritt.

Und falls jemand dem erwähnten Shell-Skript nicht trauen will, kann er ja auch als "Flash-Skript" einfach ein "selbstgemachtes" (Skript) verwenden, welches den neuen Benutzer mit den Bordmitteln von AVM anlegt. Also entweder mit ctlmgr_ctl, wobei man dabei dann auch mehrere Aufrufe braucht, um alle Properties passend zu setzen ... oder man verwendet das Lua-Interface für die Variablen, da kriegt man die auch alle auf einen Schlag angelegt: https://www.ip-phone-forum.de/threa...m-einzigen-aufruf-und-ohne-ctlmgr_ctl.275773/

---

Es gibt so viele Optionen ... man muß es nur wollen und sich - gezielt - entsprechend schlau machen. Und man braucht natürlich physischen Zugang zur FRITZ!Box, damit man sein Image über den Bootloader starten kann ... daher ist das auch immer noch sicher genug, was EVA und das FRITZ!OS da bieten.

 

[NDiIPP]

Wobei ich befürchte die Idee das ganze vorher mit einer 3170 zu testen um das erlernte/getestete dann auf einer 7590 durchzuführen wohl nach hinten losgeht. Imo gibt es einfach zu viele Unterschiede zwischen diesen beiden Modellen, sowohl bzgl. der Hardware (inkl. Flash-Speicher) als auch der Firmware. Da sollte man sich imo besser ein aktuelleres Modell zum testen/lernen besorgen…

 

[T0814S]

ichtig habe ich immer noch nicht verstanden, was denn jetzt bei der fraglichen 7590 das Problem ist

"Nur" das vergessene Passwort. Aber wie du schon sagtst, es gibt jede Menge Optionen, ich muss nur noch die richtige finden.
Und währenddessen bin ich auf das beschriebene Problem auf der 3170 gestoßen und bin erstmal von einem Fehler bei mir ausgegangen, was ja nun doch evtl. nicht der Fall ist.

Wobei ich befürchte die Idee das ganze vorher mit einer 3170 zu testen um das erlernte/getestete dann auf einer 7590 durchzuführen wohl nach hinten losgeht.

Danke für den Hinweis. Morgen traue ich mich dann wohl doch mal, auf meiner eigenen 7590 zu experimentieren.