Hallo,

ich würde gerne meine Fritz!Box 6490 am Telekom Glasfaser-Anschluss weiterverwenden.
Fritz!OS Version: 06.83

Hinter einem anderen Router funktioniert es ohne Probleme mit "Internetzugang über LAN1".
Leider gibt es aber keine weiteren Einstellungen und um direkt am Glasfaser-Anschluss zu funktionieren müsste die Box mit PPPoE und VLAN ID 7 verbinden.

Ist das irgendwie möglich zB durch editieren der ar7.cfg?

Die ar7.cfg einer Fritzbox die für PPPoE über LAN1 konfiguriert ist würde mir vielleicht auch schon weiterhelfen.

Gruß
Pashtir

Vielleicht kann ja jemand von gegenteiligen Erfahrungen berichten ... hier meine Ergebnisse beim Test des Zugriffs auf das lokale Management-Interface:

• Beschrieben/spezifiziert ist dieser Zugriff in der DOCSIS-Spezifikation (Teil OSSI) im Punkt 9.1 - dort steht ziemlich unzweideutig:
  
  Zitat:

  ---

  Zitat von Spec

  The CM MUST support SNMP access, as specified in Section 8.5.4.2, through the following IP addresses regardless of the CM registration state:
  
  • The CM MUST support 192.168.100.1, as the well-known diagnostic IP address accessible only from the CMCI interfaces. The CM MUST support the well-known diagnostic IP address, 192.168.100.1, on all physical interfaces associated with the CMCI. The CM MUST drop SNMP requests coming from the RF interface targeting the well-known IP address.

  ---

• Angesichts des "regardless of registration state" sollte so ein Zugriff auch dann funktionieren, wenn das CM provisioniert ist und arbeitet.
• Um SNMP-Zugriff zu ermöglichen, braucht es erst einmal eine korrekte IP-Konfiguration für ein entsprechendes Interface; das soll in der neuen AVM-Firmware offenbar das Interface "lan0" auf dem ARM-Core übernehmen.
• Dieses "lan0"-Interface wird mit einer MAC-Adresse konfiguriert, die bei meiner 6490 im Environment als "usb_rndis_mac" geführt wird - das ist hier die CM-MAC (steht als "macdsl" im Environment) + 2.
• An dieses Interface (bzw. an seine IP-Adresse) sind folgende Dienste gebunden:
  
  Code:

  ---

  # netstat -anp | grep 100\.1
tcp        0      0 192.168.100.1:80        0.0.0.0:*              LISTEN      709/pumaglued
tcp        0      0 192.168.100.1:443      0.0.0.0:*              LISTEN      709/pumaglued
udp        0      0 192.168.100.1:161      0.0.0.0:*                          948/snmp_agent_cm
udp        0      0 192.168.100.1:162      0.0.0.0:*                          948/snmp_agent_cm

  ---

  Das ist also einmal der von der DOCSIS-Spezifikation geforderte SNMP-Zugriff (i.d.R. nur read-only und mit eingeschränktem Vorrat an SNMP-Settings, die man abfragen kann) und ein Proxy-Service, der HTTP(S)-Zugriffe auf diese IP-Adresse auf den ATOM-Core (und dort auf das GUI) weiterleiten soll. Letzterer ist zumindest für den Port 443 vermutlich auch schon mal "bullshit", weil zwar im "pumaglued" die Weiterleitung auf die 169.254.1.1 (also den ATOM-Core) gesetzt wird:
  
  Code:

  ---

  # showshringbuf pumaglued
1970-01-01 01:00:23.202 - syncstate: InitState: *UNKNOWN* -> NOT RUNNING
1970-01-01 01:00:23.206 - syncstate: setup module done.
1970-01-01 01:00:23.348 - voipdqos: setup module done.
1970-01-01 01:00:23.350 - docsis: setup module done.
1970-01-01 01:00:23.351 - pumacmflt: setup module done.
1970-01-01 01:00:24.844 - syncstate: InitState: NOT RUNNING -> NOT SYNCHRONIZED (NOT READY)
1970-01-01 01:00:29.365 - tcpproxy: 192.168.100.1:80 -> 169.254.1.1:80
1970-01-01 01:00:29.366 - tcpproxy: 192.168.100.1:443 -> 169.254.1.1:443
1970-01-01 01:00:29.366 - tcpproxy: init done.
1970-01-01 01:00:32.122 - pumacmflt: snmp_allowed: 0
1970-01-01 01:00:32.132 - pumacmflt: tr069_allowed: 0
1970-01-01 01:00:32.223 - startstop: start: undef -> start
1970-01-01 01:00:49.844 - syncstate: InitState: NOT SYNCHRONIZED (NOT READY) -> NOT SYNCHRONIZED
1970-01-01 01:00:50.844 - syncstate: InitState: NOT SYNCHRONIZED -> RANGING IN PROGRESS (DS TOPOLOGY RESOLUTION)
1970-01-01 01:00:50.844 - syncstate: SyncState: no-sync -> training
1970-01-01 01:00:53.843 - syncstate: InitState: RANGING IN PROGRESS (DS TOPOLOGY RESOLUTION) -> REGISTRATION: US PARAMETERS ACQUIRED
1970-01-01 01:00:54.843 - syncstate: InitState: REGISTRATION: US PARAMETERS ACQUIRED -> RANGING IN PROGRESS
1970-01-01 01:01:01.844 - syncstate: InitState: RANGING IN PROGRESS -> NOT SYNCHRONIZED
1970-01-01 01:01:01.844 - syncstate: SyncState: training -> no-sync
1970-01-01 01:01:02.843 - syncstate: InitState: NOT SYNCHRONIZED -> RANGING IN PROGRESS (DS TOPOLOGY RESOLUTION)
1970-01-01 01:01:02.843 - syncstate: SyncState: no-sync -> training
1970-01-01 01:01:05.844 - syncstate: InitState: RANGING IN PROGRESS (DS TOPOLOGY RESOLUTION) -> REGISTRATION: US PARAMETERS ACQUIRED
1970-01-01 01:01:07.843 - syncstate: InitState: REGISTRATION: US PARAMETERS ACQUIRED -> RANGING IN PROGRESS
1970-01-01 01:01:14.843 - syncstate: InitState: RANGING IN PROGRESS -> RANGING COMPLETE
1970-01-01 01:01:16.843 - syncstate: InitState: RANGING COMPLETE -> REGISTRATION: DHCPV6 IN PROGRESS
2017-05-14 20:59:16.575 - docsis: erouter on
2017-05-14 20:59:16.576 - docsis: edva off
2017-05-14 20:59:16.576 - docsis: emta off
2017-05-14 20:59:16.578 - docsis: B2B: commit start
2017-05-14 20:59:16.579 - docsis: B2B: add l2sd0.2 erouter0
2017-05-14 20:59:16.579 - docsis: B2B: commit end
2017-05-14 20:59:16.582 - docsis: B2B: commit start
2017-05-14 20:59:16.583 - docsis: B2B: commit end
2017-05-14 20:59:16.617 - syncstate: InitState: REGISTRATION: DHCPV6 IN PROGRESS -> REGISTRATION: CONFIG FILE DOWNLOAD COMPLETE
2017-05-14 20:59:17.617 - syncstate: InitState: REGISTRATION: CONFIG FILE DOWNLOAD COMPLETE -> REGISTRATION: IN PROGRESS
2017-05-14 20:59:22.617 - syncstate: InitState: REGISTRATION: IN PROGRESS -> OPERATIONAL
2017-05-14 20:59:22.617 - syncstate: SyncState: training -> showtime
2017-05-14 20:59:22.617 - syncstate: DS/US: 0/0 -> 106000/6360

  ---

  , aber das läuft nun mal auf dem ATOM-Core genauso wie auf anderen FRITZ!Boxen, daß der "ctlmgr" bei abweichend konfiguriertem, externem HTTPS-Port (was man schon wg. der Portscans nutzen sollte) auch intern nur auf diesem Port aktiviert wird.
  Ich hatte mal die stille Hoffnung, daß AVM das mit der Einführung von PCP wenigstens auf ein Port-Mapping (von extern irgendwas auf intern 443) umstellen würde, so daß man aus dem internen Netz einen HTTPS-Aufruf auch ohne die Angabe eines abweichenden Ports machen kann. Wenn man das unbedingt auch intern auf dem externen Port erreichen will (wg. NAT-Hairpinning), dann muß man eben zwei Ports binden oder einen transparenten, lokalen Tunnel legen.
  Jedenfalls zeigt dann eben ein Mapping auf 169.254.1.1:443 bei mir auch prompt ins Leere, weil der "ctlmgr" für HTTPS bei mir an einem anderen Port lauscht.
  
• Ungeachtet all dieser Vorbereitungen, reagiert eine FRITZ!Box 6490 mit 153.06.83 bei mir jedoch auf keinen ARP-Request, kein ICMP (wenn ich die MAC-Adresse mit "arp" fest setze), kein HTTP (HTTPS natürlich erst recht nicht, s.o.) und - natürlich - auch nicht auf irgendwelche SNMP-Pakete (die ja i.d.R. ohnehin ARP-Auflösung bräuchten, der Test mit festem ARP-Eintrag war ja nur ein versuchter Workaround).

Aktiviert man dann mal das Interface ":lan0" im "Paketmitschnitt" (die Interfaces mit dem Doppelpunkt am Beginn beziehen sich in der 06.83 auf das eCM, die anderen auf das IAD - also den ATOM-Teil), dann kommen da auch nur die (ARP-)Broadcasts des CMTS von der WAN-Seite an, mit der dieses nach dem richtigen CM für IPv4-Adressen sucht - von der LAN-Seite (bzw. von einem CMCI) ist da nicht ein Paket zu sehen. Auch dann nicht, wenn man direkt auf dem ATOM-Teil versucht, mit der 192.168.100.1 zu kommunizieren.

Ausgehend von dem vermuteten Aufbau müßte m.E. über den externen Switch (mithin die LAN-Ports der Box) eingehender IP-Verkehr erst einmal zum ATOM-Core, bevor dieser dann den Packet-Prozessor entsprechend programmiert (für "externe" Verbindungen) oder eben selbst antwortet für interne. Anhand der Routing-Tabelle im ATOM-Core würde dieses System die Daten so behandeln, als wären sie für ein externes Ziel gedacht ... die Tabelle auf dem ATOM-Core hat keine "Sonderbehandlung" für die 192.168.100.1 (meine ansonsten übliche "Standardroute" für 192.168.0.0/16 über "dev lan" habe ich extra auf 192.168.128.0/17 präzisiert):
Zunächst könnte man also mal unterstellen, daß hier einfach eine Route vom ATOM-Core zum ARM-Core fehlt, über die dann Pakete an diese Adresse nicht dem ganzen Geraffel mit NAT und CT im "dsld" unterzogen werden - zumindest könnte das ja ein Ansatz sein, warum da nichts beim "lan0"-Interface des ARM-Cores ankommt bzw. warum das wohl einer Filterung zum Opfer fallen könnte.

Also tragen wir mal selbst eine Route ein:
Damit hätte man jetzt auch - zumindest vom ATOM-Core aus - einen funktionierenden Zugriff auf die 192.168.100.1 - halt über den "Interconnect" zwischen den Kernen geroutet, wie auch immer diese Verbindung aussehen mag. Das zeigt zumindest, daß diese Adresse prinzipiell vorhanden und erreichbar ist ... selbst wenn natürlich auch jetzt noch nichts in einem Mitschnitt für ":lan0" zu sehen ist, weil das ja kein Traffic ist, der über dieses Interface läuft. Das kommt ja jetzt über ":acc0" herein und geht wohl auch nur deshalb wieder über dieses Interface raus - denn der ARM-Core selbst hat keine Standardroute o.ä., nur eine einzige für 169.254.1.0/30 für die Kommunikation mit dem ATOM-Core.

Da stellt sich mir halt jetzt die Frage, was AVM da wohl vergessen haben mag (oder was ich wohl falsch machen könnte), damit die 192.168.100.1 dann auch - so wie es m.W. bei jedem anderen DOCSIS-Gerät Usus ist, zumindest für SNMP eben auch in der Spezifikation gefordert wird (s.o.), der HTTP(S)-Zugriff über den Proxy im "pumaglued" ist hingegen Kür - aus dem LAN jenseits des IAD erreichbar ist.

Auch wenn der Satz an abfragbaren SNMP-Variablen beschränkt ist, sollte doch zumindest der Hersteller (bzw. alles unter OID 1.3.6.1.2.1.1) und die Version der eingesetzten Firmware (und noch ein paar Sachen aus den DOCSIS-MIBs unter OID 1.3.6.1.2.1.69.1.1 - docsDevBase) abfragbar sein.

Ich habe es auch leider versäumt, das bei den 06.6x-Versionen für die Retail-Modelle explizit zu testen ... wenn meine Aufzeichnungen stimmen, klappte es zumindest bei der 06.10 mit meiner alten KDG-Box noch problemlos (allerdings ist das schon 2,5 Jahre her). Ich hege ein wenig den Verdacht (lasse mich aber auch gerne vom Gegenteil überzeugen), daß hier etwas dem Umbau auf die "new architecture" zum Opfer gefallen ist (und ich will jetzt deshalb auch nicht auf eine 06.6x "zur Kontrolle" wechseln, weil mich viel mehr interessiert, wie man es unter 06.83 zum Laufen bringen kann als die Frage, wie es zuvor bei der Retail-Version aussah).

Ich habe zwar den SNMP-Zugriff unter "Anbieter-Dienste" deaktiviert, das sollte aber ohnehin nur für den Zugriff des Anbieters jenseits des eCM (also z.B. auf den eRouter, ein eMTA gibt es ja in der Retail-Version nicht) gelten und nicht für den Zugriff von der CMCI-Seite auf die 192.168.100.1 ... aber eine Änderung dieser Einstellungen bewirkt auch keine Besserung (es hätte ja sein können, daß AVM hier beim "Abschalten" etwas zu weit geht).

Vielleicht liest hier ja jemand mit, der ansonsten Provider-Boxen bei Kunden einrichtet und dafür normalerweise (zumindest zur Abfrage des CM-Status) auf SNMP zurückgreift (bzw. dann ist es sicherlich die Software seines Arbeitgebers, die damit arbeitet) ... ggf. kann so jemand mir ja den entscheidenden Tipp geben oder seinerseits bestätigen, daß es ihm bei der FRITZ!Box 6490 mit "new architecture" (die 06.6x hat m.W. auch bei den Providern noch den alten Aufbau) auch nicht gelingt, da per SNMP irgendetwas von der 192.168.100.1 zu erhalten.

- - - Aktualisiert - - -

Falls es jemanden interessiert ... die DOCSIS-Spezifikation (konkret die CMCI-Spezifikation, also "Cable Modem to CPE Interface") wurde erst vor kurzem subtil verändert und steht seit dem 10.05.2017 in Version I03 zur Verfügung.

Ich verstehe zwar den Unterschied zwischen dem alten und dem neuen Text an einer Stelle (Punkt 6.1) nicht so richtig:
, aber das wird schon seine Gründe haben.

Für mich persönlich wäre jetzt der Unterschied zwischen "darf den Zugriff nicht erlauben" (MUST NOT allow) und "ist verpflichtet, den Zugriff nicht zu erlauben" (is required to not allow) nicht so prägnant (immerhin ist das "MUST NOT" auch noch als "This phrase means that the item is an absolute prohibition of this specification." präzisiert), aber das liegt vermutlich nur an meinem mittelmäßigen Englisch. Oder es erklärt den Versuch für ausreichend und erwartet in der neuen Formulierung gar nicht mehr wirklich, daß der Hersteller den Zugriff wirksam unterbindet ... der (gezeigte) Wille allein genügt vielleicht schon.

Bei der Beschreibung des "Engineering Change" mit "Remove management access interfaces normative text" hätte ich irgendwie etwas anderes erwartet ... gut, da kam jetzt am Satzende noch ein Verweis auf [MULPI] und eine etwas präzisere Fassung hinzu, was diese "DOCSIS CM functions" nun sein mögen, aber irgendwie erklärt das (für mich jedenfalls) die Änderung von "MUST NOT" auf "is required to not" noch nicht so richtig, zumal eben die meisten solcher Spezifikationen mit "MUST (NOT)", "SHOULD", "MAY", usw. arbeiten und da fiel mir diese Änderung halt besonders auf. ;-)

Moin Moin,

gibt es eine Auflistung an Commands für den IRC-Proxy?

Immer wieder stehen FRITZ!Box-Besitzer aus den verschiedendsten Gründen vor dem Problem, aus ihrem Gerät irgendwelche Daten extrahieren zu müssen, die von AVM dort (vorbildlicherweise, wenn es um das "ob" geht, zum "wie" und ein paar Nachlässigkeiten dabei kommen wir gleich) nur in verschlüsselter Form gespeichert werden und auch beim Export der Einstellungen sind diese Daten normalerweise verschlüsselt.

Es gibt aber durchaus gute und legitime Gründe für das Ansinnen, auch auf solche Daten Zugriff zu erhalten. Eine kleine Liste von Beispielen (ohne jeden Anspruch auf Vollständigkeit) wäre z.B. die folgende:

• Jemand möchte seine FRITZ!Box mit zusätzlichen Programmen erweitern, die Kenntnis von solchen, verschlüsselt gespeicherten, Einstellungen benötigen. In diesem Falle ist es sicherlich keine allzu gute Idee, dieselben Datei noch einmal irgendwoanders zu verwalten und das vielleicht noch unverschlüsselt ... es gibt ja i.d.R. einen Grund dafür, warum so eine Einstellung von AVM verschlüsselt wird und nur wenige dieser Werte vom FRITZ!OS dann wieder in der Klartext-Version bereitgestellt werden (zumindest auf Wegen, die mit überschaubarem Aufwand verbunden sind).
• Jemand hat nur eine ältere Sicherungsdatei auf einer früheren Box (mit oder ohne Kennwort für die Sicherungsdatei), braucht aber ganz dringend noch irgendeine uralte Einstellung oder irgendwelche Zugangsdaten, die nur in dieser einen Datei noch vorhanden sind und ein (teilweiser) Import kommt als Lösung nicht in Frage.
• Als aktuelles Problem: Jemand hat eine aktuelle Sicherungsdatei erstellt, weil er verdächtige Aktivitäten in seiner FRITZ!Box bemerkt hat und bevor er alle Spuren vernichtet durch das Laden der Werkseinstellungen samt Neukonfiguration, war er so schlau, noch eine Sicherung der aktuellen Einstellungen zu machen. Die nutzt ihm aber nichts, weil er die in dieser Sicherung enthaltenen Benutzerkonten gar nicht wirklich "untersuchen" kann, denn man sieht einem Account in einer Sicherungsdatei nicht mehr an, für welchen Benutzer der nun erzeugt wurde (es gibt ja auch eine Möglichkeit, Benutzer zu verstecken vor dem GUI) und welches Kennwort dort ggf. von einem Angreifer überschrieben wurde, so daß sich der Besitzer selbst nicht mehr anmelden konnte. Hier hilft es natürlich unheimlich, wenn man (bei Kenntnis des Export-Kennworts, es geht hier nicht um das Brechen der Verschlüsselung einer unbekannten Export-Datei) die Sicherungsdatei dann einfach als Klartext anzeigen lassen kann.

Es gibt also auch legitime Gründe für solche "Neugierde" und nachdem AVM mit Version 06.10 das früher existierende "allcfgconv -c" zum Anzeigen von Klartext-Daten eingestampft hat, gab es noch ein weiteres Programm (namens "webdavcfginfo"), mit dem man in der Version 06.20 immer noch diese Daten entschlüsseln konnte. Das wurde aber nach dieser Version von AVM ebenfalls abgestellt. Trotzdem gibt es in den Händen der falschen Leute natürlich immer noch entsprechende alte Firmware (und AVM hat da praktisch nichts Entscheidendes geändert bei der internen Version, nur der Export wurde etwas modifiziert) und damit auch diese älteren Programme ... wer also genug Energie aufbringt (und das darf man einem (halbwegs engagierten) Angreifer unterstellen), der findet auch heute noch genug Möglichkeiten, an die geheimen Daten aus einer FRITZ!Box zu kommen, wenn er erst einmal so weit gekommen ist, daß er die AVM-Programme (allcfgconv, webdavcfginfo) überhaupt verwenden könnte. Dazu müßte er ja auch erst einmal in einer (fremden) Box sein und die dort aufrufen können ... dann läßt er sich eben die verschlüsselten Daten ausgeben (am besten gleich als TFFS-Dump) und dekodiert die hinterher in aller Ruhe auf einem eigenen System, notfalls einer FRITZ!Box mit Firmware vor 06.10.

Einem "bad guy" (unter "bad girl" versteht sicherlich jeder etwas anderes) hat man damit also nur ein paar Kiesel in den Weg gelegt ... aber der "Gelegenheitsnutzer" aus den o.a. Beispielen steht dabei (in aller Regel, solange er das nicht ständig machen muß) vor entsprechenden Problemen. Das ist in meinen Augen aber der Falsche, der hier von Sanktionen betroffen ist ... daher halte ich es für geboten, diesem legitimen Benutzer auch die passenden Werkzeuge in die Hand zu geben. Das habe ich lange und reiflich überlegt - ein entscheidender Punkt war auch der Wegfall des Routerzwangs und damit entfällt für mich zu einem großen Teil auch das "Schutzbedürfnis", das man früher für Einstellungen vom Provider in den FRITZ!Boxen noch unterstellen und geltenlassen konnte, die dem Provider gehören. Seitdem die Kunden aber die Zugangsdaten ohnehin vom Provider erhalten müssen, entfällt auch dieser Punkt der "contra"-Liste.

Das führt dann im Ergebnis zu der Einstellung, daß diese "security by obscurity" eigentlich nur einem wirklich schadet: dem berechtigten Benutzer. Alle anderen finden auch ohne mich und die folgenden Informationen immer wieder einen Weg, an diese Daten zu gelangen. AVM hilft also mit dieser Geheimniskrämerei eher den Bösen und ich sehe nicht einen einzigen Punkt, wo eine Beschreibung meinerseits die Sicherheit eines FRITZ!Box-Besitzers tatsächlich aushöhlen würde - ganz im Gegenteil ... wie im Beispiel oben angeführt, kann es dem Besitzer sogar helfen, über Merkwürdigkeiten in den Einstellungen auf einen Angriff zu schließen.

Das war's dann jetzt auch mit der Präambel und nun geht es "in medias res".

---

Schaut man sich die verschlüsselten Daten in irgendeiner AVM-Datei einmal an, stellt man ja schnell fest, daß diese immer mit vier Dollarzeichen beginnen und danach dann nur die Großbuchstaben A bis Z und Ziffern 1 bis 6 folgen. AVM muß also irgendwie die verschlüsselten Daten aus der binären Form (das Ergebnis der eigentlichen Verschlüsselung sind alle denkbaren Werte von 0 bis 255 in mehreren Bytes - das ist dann die "binäre Form", so wie die Daten im Speicher liegen) in eine andere transformieren, die mit insgesamt 32 Zeichen (26 Buchstaben, 6 Ziffern) auskommt.

Das kennt aber praktisch jeder aus der Mathematik und der Schule ... es ist am Ende nichts anderes als eine andere Zahlenbasis, die da zum Einsatz kommt. Da, wo das Binärsystem mit den Zeichen 0 und 1 auskommt, braucht das Oktalsystem dann schon acht (0 bis 7), das Dezimalsystem zehn (0 bis 9) und auch vom Hexadezimalsystem (mit 0 bis 9 und den Buchstaben A bis F für die Werte 10 bis 15) sollte man schon mal etwas gehört haben (wenn nicht, wäre hier der richtige Zeitpunkt, sich das z.B. in der Wikipedia anzusehen).

AVM verwendet hier also 32 verschiedene "Ziffern" und damit ist das offenbar ein Zahlensystem mit der Basis 32 ... daher nennt man diese Kodierung dann auch folgerichtig: Base32. Die gibt es auch an anderen Stellen (die Base64-Kodierung zur Darstellung beliebiger Inhalte nur mit ASCII-Zeichen ist aber bekannter), aber AVM verwendet hier wohl ein eigenes "Alphabet", denn die meisten anderen arbeiten mit 0 bis 5 für die zusätzlich benötigten 6 Werte. Warum AVM hier überhaupt auf Base32 zurückgreift, kann man auch nur vermuten ... die zusätzlichen 32 "Zeichen" für Base64 sind sicherlich nicht das Problem; notfalls ersetzt man die zwei Sonderzeichen im Zeichenvorrat (das sind das Plus und der Schrägstrich) durch andere, wenn man diese Zeichen für eigene Zwecke braucht.

Also rate ich mal hinsichtlich der Beweggründe und tippe auf: Verschleierung (für Laien) - auf Kosten zusätzlicher "Längen" bei der Kodierung, denn im Gegensatz zum Base64 (mit einem Verhältnis von 4 Zeichen für 3 Byte Binärdaten) braucht Base32 da mehr und bietet ungünstigere Bedingungen (8 Zeichen für 5 Byte Binärdaten) "aus Computersicht" bei den binären Daten (es müssen Vielfache von 5 sein bei der Länge der zu kodierenden Daten).

Kommen wir darauf zurück, wie das "AVM-Alphabet" wohl genutzt wird ... irgendwo in der Firmware gibt es bestimmt passende Zeichenketten. Das naheliegendste ist zunächst mal der Blick in die "libar7cfg.so", diese ist für die Be- und Verarbeitung der "Hauptdatei" (ar7.cfg) zuständig:
Da ist also unser Zeichenvorrat und wie man sehen kann, steht die "1" dann für den Wert 26 und die "6" für 31 - das "A" ist dann die Null in diesem "Zahlensystem".

Mit dieser Erkenntnis ausgerüstet, ist es jetzt recht simpel, aus der Base32-Form die binäre Darstellung zu gewinnen. Das habe ich im Laufe der Jahre in mehreren Formen realisiert ... von Python über Shell bis C.

Aber mit diesen Daten kann man jetzt auch noch nicht so richtig viel anfangen ... was wir zunächst einmal brauchen, ist ein bekannter Klartext und das dazugehörige Chiffrat. Das ist schnell erledigt ... auf einer 7412 habe ich mir einen Benutzer "PeterPawn" mit dem Kennwort "PeterPawn" angelegt und das Ergebnis war dann das Folgende:
Hier sehen wir also schon mal zwei verschiedene Kodierungen, die eigentlich für denselben Wert stehen sollen ... offensichtlich gibt es neben dem Klartext und einem (bisher unbekannten) Schlüssel auch noch einen weiteren zufälligen Wert, der in das Chiffrat eingeht und damit dafür sorgt, daß sich jedesmal eine andere Darstellung ergibt. Egal, ob es sich dabei nun um das "Salz in der Suppe" (salt) handelt oder um einen "initialization vector" (IV) für eine Block-Chiffre, dieser zufällige Wert muß natürlich zusammen mit dem Chiffrat gespeichert werden, damit bei einer Entschlüsselung genau wieder dieser Wert verwendet werden kann.

Was wir auch schon aus der Erfahrung wissen (entsprechende Berichte gibt es seit Jahren) ... es gibt bei der Verschlüsselung für die interne Speicherung auch noch eine gerätespezifische Komponente, denn eine Datei von der einen FRITZ!Box läßt sich nicht ohne weiteres auf einer anderen FRITZ!Box entschlüsseln - das ging schon zu Zeiten von "allcfgconv -c" nicht. Wenn man sich ein wenig mit dem Aufbau einer FRITZ!Box befaßt, kommt man auch schnell dahinter, daß diese "Geräteeigenschaften" für die Verschlüsselung eigentlich nur im sogenannten "Urlader-Environment" gespeichert sein können ... das sind ein paar Eckdaten einer Box (inkl. variabler Daten, die auch bei zwei Geräten desselben Modells bei der Finalisierung der Boxen ab Werk unterschiedlich sind) und - da die Firmware an sich für alle Geräte eines Modells dieselbe ist - praktisch die einzige (maschinenlesbare) Stelle, wo das FRITZ!OS auf (dauerhaft existierende, denn diese Daten werden weder bei Recovery noch bei Werkseinstellungen gelöscht) Daten eines Gerätes zugreifen kann.

Wenn es also variable Größen gibt, dann können die praktisch nur dort drin stehen und wenn man dann etwas mit den Werten im Environment und einem (bekanntermaßen funktionierenden) Programm zum Dekodieren von verschlüsselten Daten experimentiert, stellt man recht schnell auch fest, daß diese variablen Daten offenbar aus dem Wert bei "maca" und "wlan_key" bestehen, die in praktisch jeder FRITZ!Box vorhanden sind. Zusätzlich kommt noch ein weiterer Wert hinzu, der aber nicht bei allen Boxen vorhanden ist und deshalb auf den ersten Blick nicht auffällt ... das ist "tr069_passphrase", was nur bei den Boxen mit konfiguriertem CWMP-Account (also einer TR-069-"Identität") vorhanden ist.

Es geht auch noch ein vierter Wert in diese gerätespezifischen Daten ein ... aber auch der fiel bisher eher nicht auf, weil es praktisch nur Geräte gab, in denen er immer denselben Wert hatte. Es handelt sich hierbei um "SerialNumber" und die meisten FRITZ!Boxen haben dort lediglich 16 Nullen (als Zeichen, also 0x30) stehen ... erst bei einigen neueren Modellen wird da jetzt tatsächlich die Seriennummer hinterlegt. Dieser Umstand (und der damit verbundene Ausfall meiner bisherigen Lösungen, weil ich diese 16 Nullen auch fest verdrahtet hatte) war es auch, der mich zur erneuten Beschäftigung mit dem Thema "Verschlüsselung im FRITZ!OS" zwang und im Zuge dessen kam dann der Entschluß, das nun doch zu veröffentlichen.

[ Die 16 fest verdrahteten Nullen waren das Ergebnis von früheren Untersuchungen mit einer Library, die über "LD_PRELOAD" eine Funktion von AVM ersetzte (HASH_Update - wie man die findet, kommt gleich) und deren Aufrufe protokollierte. Das machte es auch leichter, die korrekte "Reihenfolge" der gerätespezifischen Daten zu ermitteln, obwohl da die denkbaren Permutationen mit 8 Variablen (jeder Wert einmal mit und einmal ohne "newline" am Ende) auch begrenzt wären und rein experimentell ermittelt werden könnten. ]

Wir haben also experimentell dann vier Werte ermittelt, die für diese "Identität" einer FRITZ!Box eine Rolle spielen und für die weitere Betrachtung brauchen wir dann auch die zu den oben gezeigten Chiffraten passenden Werte aus der Box:
Die Box hier hat also keinen CWMP-Account, damit gibt es nur drei Werte. Wie diese nun zu einer Variablen verknüpft werden, die als variable Größe in die Verschlüsselung eingehen kann (normalerweise als "key", aber denkbar wäre auch als "iv"), wissen wir aber damit noch lange nicht.

Zunächst einmal müssen wir irgendwie feststellen, welche (hoffentlich standardisierten) Algorithmen von AVM an dieser Stelle überhaupt verwendet werden. Dazu schauen wir uns mal ein paar Dateien aus der AVM-Firmware etwas genauer an und versuchen, die Abhängigkeiten zwischen den Bibliotheken dort zu ermitteln. Beginnen wir mit der "libar7cfg.so", die muß ja irgendwie in der Lage sein, so etwas zu ver- und entschlüsseln - wenn das nicht helfen sollte, bleibt uns immer noch ein altes "webdavcfginfo" ... schon anhand der Größe der Datei ist es relativ unwahrscheinlich, daß diese die gesamte Unterstützung der Verschlüsselung direkt enthält.
Das sieht ja schon sehr nach dem aus, was wir eigentlich suchen ... die "libar7cfg.so" braucht also für ihre Arbeit (wir sehen ja nur die importierten Funktionen) auch die rot markierten aus anderen Bibliotheken (man kriegt auch noch heraus, welche Bibliotheken das wären) und dabei taucht sowohl ein "MD5_Environ" als auch ein "AES256_Environ" auf - es spricht einiges dafür, daß wir hier sowohl eine Digest- als auch eine Cipher-Funktion gefunden haben.

Eine Digest-Funktion macht aus Daten variabler Länge einen eindeutigen Wert mit fester Länge, der z.B. als "key" oder als "iv" (der muß der Blockgröße eines Cipher-Algorithmus entsprechen von der Größe) für eine Verschlüsselung verwendet werden kann oder als "Prüfsumme", ob Daten in verschlüsselter oder Klartext-Form korrekt (sprich: unverändert bzw. erfolgreich entschlüsselt) wurden.

Eine Cipher-Funktion (hier das symmetrische AES mit einer Schlüssellänge von 256 Bits, wobei auch das eine Blocklänge von 16 Byte (128 Bits) verwendet) kann dann als "Block-Chiffre" auch dazu verwendet werden, einen Datenstrom (reversibel) zu verschlüsseln, der aus mehr als einem Block (16 Byte sind etwas wenig) besteht. Die gebräuchlichste Variante (und m.W. auch die älteste) ist dabei "Cipher Block Chaining" (CBC) und das ist auch das Erste, was man bei einer Untersuchung hier probieren würde.

Wir haben also die chiffrierten Daten (nach Base32-Dekodierung) und eine Vorstellung, was da von AVM wohl verwendet wird. Mit diesem Wissen bewaffnet, kann man sich jetzt ans Experimentieren machen ... ob man dazu jetzt das OpenSSL-Kommandozeilen-Tool, irgendeine höhere Sprache mit Crypto-Unterstützung oder direkt C-Programmierung mit OpenSSL-Funktionen verwendet, bleibt den eigenen Vorlieben überlassen. Als (nachvollziehbare) Demonstration bietet sich aber wieder die Linux-Kommandozeile an und so benutzen wir hier auch diese erst einmal:
Das ist also schon mal der binäre Inhalt der verschlüsselten Daten und damit wir den nicht jedesmal neu dekodieren müssen, speichern wir das Ergebnis einfach jeweils in einer Datei:
Für eine AES-Verschlüsselung brauchen wir einen "key" und einen "iv" ... normalerweise würde der IV zufällig gewählt (der muß auch nicht geheim sein und wird damit unverschlüsselt übermittelt/gespeichert) und der Key mit einer passenden Funktion aus einem Kennwort generiert - z.B. mit PBKDF2 als standardisiertem Weg, wo auch noch ein "salt" (das man entweder im Klartext oder selbst noch einmal verschlüsselt speichern muß oder man verwendet einen festen Wert) eingearbeitet werden kann, damit das Ergebnis für dasselbe Kennwort variiert und nicht beim System A mit demselben Kennwort auch derselbe Wert aus der PBKDF (Password Based Key Derivation Function) herauskommt wie beim System B (das nimmt dann eben einen anderen "salt"-Wert).

Gehen wir davon aus, daß auch AVM den IV irgendwo speichern wird ... da ist dann die Speicherung am Beginn der Daten (diese können ja eine variable Länge haben) logischer, als wenn das irgendwo am Ende steht (auch wenn das ebenfalls machbar wäre). Nun wissen wir ja (MD5 und AES256 nehmen wir mal als gesicherte Erkenntnis, auch wenn es ganz am Beginn natürlich nur eine Hypothese ist, die man mal bestätigen muß), daß wir für AES256 auch einen IV mit 16 Byte Länge brauchen. Das wäre dann der oben grün markierte Teil des jeweiligen Chiffrats ... damit beginnen die Daten vermutlich doch eher erst bei Byte 16 einer unserer Dateien "cipher_x.bin". Das müssen wir zunächst auch mal splitten ... ansonsten wird das später zu unhandlich beim "Probieren".
Nun stehen wir also vor der Aufgabe, uns irgendwie einen Key aus den vorhandenen Daten der Box zu generieren ... wir bräuchten hier aber einen Key mit 256 Bits (also 32 Bytes). Merkwürdigerweise gibt es bei AVM aber in den Beziehungen zwischen den Bibliotheken keinen Hinweis auf eine PBKDF-Funktion oder irgendeine Hash-Funktion (bzw. eine Digest-Funktion, das ist im Prinzip dasselbe), die uns diese 32 Bytes als Hash-Wert liefern würde (z.B. käme hier SHA-256 in Frage).

Wir haben also eigentlich nur unsere MD5-Implementierung, um aus den variablen Daten einer FRITZ!Box irgendeinen (spezifischen) Wert mit fester Länge zu berechnen ... und auch dafür sind die Möglichkeiten jetzt nicht allzu üppig. Wir greifen hier aber mal nur zwei davon heraus (eine richtige und eine falsche) und generieren uns dafür einen MD5-Hash:
Ich will das jetzt nicht weiter auswalzen und ich habe die korrekte Reihenfolge für das Berechnen des Hash-Wertes auch auf anderem Weg ermittelt (s.o.), aber man kann sich natürlich auch mit den vier Variablen (mit und ohne "\n" sind es dann acht) die jeweiligen Kombinationen automatisch berechnen lassen - das sprengt aber den Rahmen. Der grüne Wert ist der korrekte "Geräteschlüssel" für meine 7412 und der rote dient uns nachher nur zur Demonstration, was bei der Entschlüsselung mit einem falschen Schlüssel passiert.

Wir "wissen" ja auch, daß als Verschlüsselung AES-256 verwendet wird ... damit sähe dann ein Versuch des Entschlüsselns z.B. so aus:
Weil unsere Schlüssellänge nicht so richtig passend erscheint, habe ich erst einmal die Daten anzeigen lassen (-P), wie sie mit diesem Aufruf verwendet würden. Wir sehen also, daß der Schlüssel einfach mit Nullen auf die benötigte Länge aufgefüllt wird. Gehen wir jetzt mit dem falschen Schlüssel an unseren ersten Versuch, sieht das Ergebnis so aus:
Das Ergebnis sieht zwar mit den roten Zeilen recht entmutigend aus, aber da das Kommandozeilen-Tool von OpenSSL auch einen speziellen Aufbau der Datei erwartet, ist das ein Fehler, den man hier "aushalten" muß ... wenn man das mal mit einer OpenSSL-Version macht, die mit allen Schikanen erstellt wurde, sieht man auch, daß der Fehler erst beim "Finalisieren" des letzten Blocks auftritt:
Solange wir dafür sorgen, daß unsere Daten immer mit einer Länge vorliegen, daß der letzte Block nicht genau "gefüllt" ist, können wir den Fehler ignorieren (wir haben ja auch keinen "envelope", der da stimmen könnte) - und AVM tut uns hier mit der Base32-Kodierung und deren "krummen Längen" auch noch den Gefallen, daß es nur selten Probleme gibt ... aber wir hängen einfach mal vorsichtshalber an unsere Daten noch ein paar binäre Nullen an:
Wir haben jetzt also mindestens den letzten Block komplett und unsere binäre Null an Position 49 (0x31) stellt sicher, daß die Finalisierung erst für den nächsten Block stattfindet und die Daten davor noch komplett bearbeitet wurden ... allerdings rettet uns das auch nicht vor dem Fehler und wir werden diesen Fehler einfach ignorieren müssen:
Aber das ist ja auch nur die Entschlüsselung mit einem der denkbaren Keys (kennt man die richtige Reihenfolge beim Hash-Berechnen nicht, muß man halt alle ausprobieren) und wenn wir das jetzt mit dem richtigen Key angehen, sieht es schon viel besser aus:
Na das sieht doch schon wieder ganz anders aus ... wenn da im Klartext "PeterPawn" auftaucht, war die Entschlüsselung offenbar erfolgreich und dann stellt sich jetzt die Frage, was da eigentlich verschlüsselt wurde. Schon vor langer Zeit hatte ich entsprechende Tests zu den "Grenzen" der AVM-Daten gemacht und ermittelt, welche Länge der Klartext-Daten zu welcher Länge der verschlüsselten Daten führt ... das Ergebnis kann man u.a. hier sehen (habe ich irgendwann mal versehentlich veröffentlicht). Der graue Text ist ohnehin "garbage" und resultiert nur aus unserer "Verlängerung" der Daten.

Für die ersten 22 Bytes Klartext braucht AVM also 50 Bytes Chiffrat, wobei das beim verwendeten Cipher-Algorithmus ja auf ein Vielfaches der Blockgröße zu reduzieren ist und die 2 Bytes "Overhead" nur der Tatsache geschuldet sind, daß die Base32-Kodierung immer in Fünfer-Gruppen erfolgt. Bleiben also 48 Bytes Daten übrig und davon gehen die ersten 16 Bytes auch noch für den IV ab. Aber die verbleibenden 32 Bytes sind ja immer noch deutlich mehr als der reine Klartext und damit wird da wohl noch etwas anderes mitverschlüsselt.

Und richtig ... vor den Klartextdaten stehen oben ja noch weitere 8 Bytes, wobei die Bedeutung der vier ab Offset 4 wohl augenfällig ist. Das ist einfach die Länge der Klartextdaten (hier mit einer binären Null als Ende einer Zeichenkette in C) als 32-Bit-Wert in "big endian"-Speicherung. Da bei AVM (fast) alles Zeichenketten sind, was da verschlüsselt wird, ist die Längenangabe halt immer um eins höher als der eigentliche Wert, damit braucht AVM also eigentlich diese 48 Bytes Chiffrat für 23 Zeichen Klartext, denn das "end of string" ist ja Bestandteil des Chiffrats.

Aber was könnte das "4e 2b d5 d3" in den ersten vier Bytes denn sein? Da kommen wir wieder auf die eingangs mal erläuterte Bedeutung eines "Markers" für die richtige Entschlüsselung (mithin das richtige Kennwort) zurück ... hat man so eine Validierung vorgesehen, kann man anhand dieses Wertes sehen, ob die Entschlüsselung erfolgreich war oder nicht. Nun kann man einerseits hingehen und dafür eine "Signatur" verwenden, die immer aus denselben Zeichen besteht ... das hat zwar andere Nachteile (bei denkbaren Angriffen auf die Verschlüsselung), aber wir können ja auch leicht überprüfen, ob das eine Signatur ist oder nicht - wir nehmen einfach den nächsten Wert und lassen uns den entschlüsseln:
Die Entschlüsselung funktioniert also auch hier (nicht vergessen, den IV ebenfalls passend anzugeben) und wir sehen, daß die "relevanten" Inhalte der Daten (die Längenangabe und die Daten an sich, bis Offset 0x12) tatsächlich dieselben sind ... nur der "Müll" beim Auffüllen auf die Blockgröße ist ein anderer und auch der Inhalt der ersten vier Bytes.

Sollten diese jetzt tatsächlich so ein Marker sein, dann müssen sie aber (da sie sich ja unterscheiden für die beiden Klartext-Angaben) mehr als nur die Längenangabe und die Daten an sich absichern (also mehr als 14 Bytes ab Offset 4), ansonsten wären die Werte ja wieder identisch. Was liegt jetzt näher als das Einbeziehen des "Schmutzes" hinter den Daten (bis zur nächsten Blockgröße der Verschlüsselung) ... wären das wieder alles Nullen, ergäbe sich auch immer wieder derselbe "Prüfwert" am Beginn und daß es sich offenbar um zufälligen Inhalt handelt (egal, wie der erzeugt wurde), sieht man wieder im Vergleich der beiden Klartext-Puffer.

Bleibt also die Frage, wie man so etwas realisieren könnte ... wir hätten hier in unserem konkreten Fall 32 Byte (2 Blöcke) abzgl. der 4 Bytes für den Prüfwert, da der natürlich nicht selbst eingehen kann in die Berechnung und entweder als Nullen interpretiert wird (das haben wir beim Signieren der Firmware ja auch für die Signatur-Datei so gesehen) oder die Berechnung erfolgt erst ab Offset 4.

Trotzdem stellt sich immer noch die Frage, wie man da nun 32-Bit-Werte zur Prüfung erzeugen könnte und da wäre der erste Kandidat eine CRC32-Prüfsumme mit einem der bekannten Polynome. Das habe ich damals auch tatsächlich als erstes treudoof ausprobiert (schließlich hat AVM auch an einer Export-Datei einen solchen Wert zur Prüfung), aber irgendwann fiel mir dann doch auf, daß die libar7cfg.so (die das ja offenbar auch kann) per se gar nichts mit Im- oder Export zu tun hat ... also müßte diese Sicherung vielleicht doch mit irgendeiner Funktion erfolgen, die auch von der Library importiert wird.

Da blieb dann wieder schnell nur noch MD5 übrig ... allerdings erzeugt diese Funktion eben 16 Bytes. Nach ein wenig Probieren (auch mit längeren Werten, die nicht mehr in zwei Blöcke (das Minimum) paßten) stellte sich dann heraus, daß hier tatsächlich erneut MD5 als Digest verwendet wird - es werden aber nur die ersten vier Bytes des Hash-Wertes gespeichert und das mit der Länge hat AVM dann so gelöst, daß diese vier Bytes von der Länge der Daten abgezogen werden (also von den Vielfachen der vollen Blockgröße).

Das ergibt dann 28 Bytes für zwei Blöcke, 44 Bytes für drei Blöcke, usw. - jeweils eben mit dem "Müll", der da gerade im Buffer steht (ich glaube nicht, daß das initialisiert wird mit Zufallsdaten, weiß es aber nicht sicher, schlau wäre es aber in jedem Falle) und damit dafür sorgt, daß dieselben Daten nicht einmal als Hash-Wert dasselbe Ergebnis liefern. Stimmt dann nach dem Dechiffrieren der noch einmal berechnete Hash-Wert (auch wenn es nur die ersten vier Bytes sind, ist die Wahrscheinlichkeit für einen Zufallstreffer gering - geringer als bei CRC-Prüfsummen, wo man das gezielt herbeiführen kann mit dem richtigen "filler"), dann stimmte offensichtlich auch der Key und man kann den entschlüsselten Wert verwenden. Ansonsten nimmt AVM i.d.R. die verschlüsselten Daten genau so, wie sie kommen ... das ergibt dann beim Restore von Freetz-Sicherungen auf anderen Geräten diese lustigen Werte, wie man sie desöfteren in Freetz-Tickets findet.
Das war dann auch schon "das Geheimnis" der AVM-Verschlüsselung (zumindest in Kurzform) ... das gilt es nun nachzubauen.

Wobei AVM da m.E. ohnehin selbst noch einen "off by one" macht, der mich fast wahnsinnig gemacht hat, als ich begonnen hatte, das mit der Verschlüsselung an sich zu untersuchen:
Bei einer Länge der Klartextdaten von 24 (inkl. "end of string", also 23 "reine" Zeichen) würden die Daten genau in zwei Blöcke passen (24 Bytes + 4 Bytes Längenangaben (man sieht auch das 0x18 dort) + 4 Bytes Hash-Beginn) ... aber AVM beschickt die Verschlüsselung hier offenbar mit einem Byte mehr und das ergibt bereits bei 23 Zeichen Eingabe dann einen zusätzlichen Block bei der Verschlüsselung und einen Sprung um 15 Byte in der Länge der verschlüsselten Daten (oder 20, wenn kein "garbage" dabei war). Das war dann die wirkungsvollste Verschleierung - bis ich da eine Systematik entdeckt hatte, brauchte es eine Weile.

Auch heute noch machen einige meiner Lösungen Probleme, wenn es zu diesen Grenzfällen bei der Länge und bei deren Berechnung kommt - einfach weil der "Sprung" dafür auch bei der Berechnung des Hash-Wertes in den ersten vier Bytes des Klartextes erfolgt und das dann genauso zu implementieren ist, wie es AVM (meiner Ansicht nach ist das tatsächlich auch ein Fehler und keine Absicht) macht. Die einzige "vernünftige" Erklärung wäre es halt, daß ohne irgendwelche Zufallsdaten am Ende auch bei der Berechnung des Hash-Wertes (über das Längenfeld und den Inhalt) immer derselbe Hash-Wert entstehen würde - vielleicht möchte man das vermeiden. Das finde ich dann angesichts von einfachen MD5-Hashes als Key aber schon weit vorausgedacht und es paßt für mich nicht wirklich zum Rest (komme ich gleich noch drauf).

Parallel dazu gibt es noch den Spezialfall einer Export-Datei ... hier können ja für den Key offensichtlich nicht die Eigenschaften des Gerätes herangezogen werden ... dann ließe sich die Datei ja nicht auf einem anderen Gerät entschlüsseln und importieren. Also muß AVM hier etwas anders machen ... und das fällt einem auch ins Auge, wenn man mal einen Blick in so eine Export-Datei wirft. Dort steht im Header der Datei (i.d.R. vor der Firmware-Version) ein Eintrag mit dem Namen "Password", offensichtlich gefolgt von einem verschlüsselten Wert, wie er auch an anderen Stellen auftritt.

Da wir inzwischen ja schon wissen, wie die Daten aussehen sollten nach der Entschlüsselung (und mit dem Hash-Wert auch selbst prüfen können, ob unser Kennwort stimmt), ist es dann wieder nur eine Fingerübung, diesen Wert solange mit wechselnden Keys zu traktieren, bis wir den passenden gefunden haben (ich hatte mir dafür entsprechende Hilfsprogramme geschrieben). Es gibt ja mindestens zwei Möglichkeiten, denn wir kennen Export-Dateien mit einem benutzerspezifizierten Kennwort und solche, die sich nur auf demselben Gerät wiederherstellen lassen (also wohl wieder den Geräteschlüssel benutzen).

Für die Variante mit dem Kennwort kommt man dann relativ schnell dahinter, daß es sich hier lediglich um den simplen MD5-Hash des Kennwortes handelt (ohne "newline" dahinter) und auch für die Variante ohne, wird man schnell fündig - nachdem man erst einmal verwirrt wurde, daß es sich dabei nicht um denselben Key handelt, wie er für die interne Speicherung verwendet wird. Auch hier ist halt "fröhliches Probieren" angesagt, aber die Permutationen sind wieder nicht so zahlreich - am Ende landet man bei der Seriennummer (bzw. für mich waren das immer irgendwelche Nullen und der Zusammenhang war mir bis vor kurzem gar nicht klar, weil die eben auf fast allen Geräten identisch war) und der MAC-Adresse, jeweils gefolgt von einmal "newline" (0x0A).

Zur Untersuchung brauchen wir erst einmal irgendwelche Daten, wir lassen einfach auf der 7412 mal die Konfiguration mit einem bekannten Kennwort exportieren und suchen uns das Kennwort am Beginn und das "PeterPawn" im Benutzernamen
Mit dem Wissen um dieses Kennwort können wir jetzt (auch außerhalb der 7412) die ersten Daten entschlüsseln ... dabei setze ich jetzt gleich zwei der Dateien ein, die ich später noch beschreiben werde:
Da der Hash-Wert stimmt, ist die Entschlüsselung offenbar geglückt und die letzte Zeile enthält (hier hexadezimal angezeigt) einen 256-Bit-Wert, der ja durchaus als Schlüssel für unser AES-256 in Frage käme. Schaut man noch einmal genauer hin, ist das aber lediglich eine Doppelung der ersten 16 Bytes (es würde mich nicht wundern, wenn das ein verdoppelter MD5-Hash irgendeines Zufallswertes ist) und dadurch wird der Wert auf 32 Bytes aufgeblasen (inkl. Hash und der bezieht auch die "garbage" am Ende mit ein (8 Bytes).

Versucht man sich jetzt mit diesem 256-Bit-Key an der Entschlüsselung der einzelnen Einstellungen in der Export-Datei, beißt man aber auf Granit:
Das war also offensichtlich schon mal nicht der richtige Key ... aber mit etwas Probieren stellt man dann schnell fest, daß da auch wieder nur der halbe Key verwendet wird (die "Güte" ist dank Doppelung ja ohnehin nicht wirklich besser als bei 128-Bit):
Wie man sieht, lassen sich auch beide Werte aus den Tiefen der Export-Datei mit demselben Key dechiffrieren - es ist halt nur ein zweistufiges Verfahren zur Gewinnung des richtigen Schlüssels bei einer Export-Datei.

Damit wäre die Beschreibung jetzt tatsächlich durch ... bleibt noch so etwas wie ein Zwischenfazit. Auch wenn die AVM-Verschlüsselung mit einem 256-Bit-Key protzt, ist es am Ende in Wirklichkeit alles nur die Sicherheit, die sich aus AES mit 128-Bit-Schlüsseln ergibt - wenn jeweils die Hälfte der 256 Bits schon vorher bekannt ist (hier sind es eben immer Nullen), dann ist AES-256 ein wenig Augenwischerei, jedenfalls wenn es um den "Schlüsselraum" geht. Ob MD5-Hashes tatsächlich das Mittel der Wahl sind (erst recht bei der einfachsten Variante mit dem Export-Kennwort), muß jeder selbst beurteilen. So, wie es zur Zeit aussieht, verwendet AVM wohl tatsächlich auch eine eigene Implementierung des "Rijndael-Algorithmus" (der später als Standard dann in "Advanced Encryption Standard" (AES) umbenannt wurde) und begeht damit ggf. schon den ersten Fehler. Selbst wenn das vielleicht früher mal erforderlich war, gibt es lange genug auch AES-256 in OpenSSL und es wäre längst an der Zeit gewesen, die eigene Implementierung:
in einen Wrapper für ein Standard-Paket umzuwandeln. Daß es sich nicht um einen solchen handelt, kann man an den importierten Funktionen sehen.

Auch ist es eigentlich verpönt, irgendwelche Keys ganz simpel von einem Hash-Wert (wie beim Export-Kennwort) abzuleiten ... das ist anfällig für Attacken und die üblichen Funktionen zur Ableitung eines Keys von einem Kennwort (PBKDF2 hatte ich oben schon erwähnt) fügen diesem Vorgang der Kennwort-Generierung (auch ohne "salt", wenn also aus einem identischen Kennwort auch ein identischer Key werden soll) einiges an Komplexität hinzu, um genau solche Angreifer passend zu verlangsamen. Mit vorausberechneten MD5-Hashes (wenn sich das überhaupt lohnt) ist das jedenfalls relativ(!) leicht angreifbar - es macht bloß niemand, weil sich der Aufwand vermutlich nicht lohnt. Aber "sicher" ist eben etwas anderes ... zwischen einem "ausgezeichnet" und einem "genügend" können da Welten liegen.

---

Wenn es jedenfalls um das Nachbauen geht, so habe ich seit drei Jahren da die verschiedensten Lösungen am Start gehabt ... je nachdem, worum es dabei jeweils ging und wenn irgendetwas Neues gebraucht wurde, habe ich auch eher etwas Vorhandenes genommen, geändert und dann parallel zur "Vorlage" verwendet, anstatt das in eine "gemeinsame" Code-Basis zu integrieren. So ein "refactoring" ist eben ein erheblicher Aufwand und mich juckte es eher nicht, wenn ich denselben Code immer wieder verwendet habe ... es gab einfach keine Notwendigkeit, die Sachen irgendwie zusammenzufassen.

Das war jetzt für die Veröffentlichung dann wieder etwas anderes und so bin ich (wohl oder übel) hingegangen und habe einiges "from scratch" neu gemacht ... zwar mit älteren Dateien als Vorlage, aber im Prinzip ist wirklich alles neu (das war der Mai). Das führt aber auch dazu, daß einige Fehler sich wieder eingeschlichen haben (z.B. die oben erwähnte falsche Länge bei der Hash-Berechnung) und nun erst einmal mühsam gefunden und beseitigt sein wollen.

Ich lasse das Ganze hier jetzt etwas sacken und widme mich der Suche von Fehlern in den Shell-Dateien (den Fehler bei 22 bzw. 23 Zeichen habe ich gerade wiedergefunden in "decode_secrets") bzw. der Weiterentwicklung des neuen C-Programms, was die Funktionen der Shell-Skripte in einem einzigen Binary vereinen soll. Wenn das irgendwann mal so stabil sein sollte, daß ich es als halbwegs fertig ansehe, widme ich mich der Beschreibung der Shell-Skripte ... wobei ich jedem zum C-Programm raten würde, auch wenn die "Zutaten" für die Shell-Skripte normalerweise auf jedem Linux-System vorhanden sein sollten (auch die "bash" in Windows 10/x64 sollte ausreichen) oder sich aus dem Projekt-Repository (und aus dem YourFritz-Repository direkt daneben, denn die Shell-Skripte wollen die Script-Library aus diesem Repository sehen) laden lassen und dann auch ohne Übersetzung funktionieren.

Auch die Suche nach Tippfehlern schiebe ich erst einmal auf ... wer hier welche findet, darf sie erst einmal behalten. Ich editiere das irgendwann noch einmal, wenn ich Korrektur gelesen habe.

Dear Folks,
First I would like to excuse because I am writing in English, I hope it is not against the forum rules.

My intent is to demonstrate how I could update my Fritzbox 6490 KDG branded to firmware 6.83.

It was quite challenge to me because I am not German speaker and almost all material are in German. I also would like to summarize all my steps and trick steps that I passed in order to help others with the same issues I passed.

I thank all the information that were provided in the forum especially to lleeaaddeerr, fesc and PeterPawn posts which gave the main information that I need to proceed.

One of my difficulties was to follow all the 1900 posts in the thread http://www.ip-phone-forum.de/showthread.php?t=286994, which was the main source of the process described below.

My case: I have bought in ebay for 40 Euros a Fritzbox 6490 articlenumber 20002691, I knew that I might have problems to use and update but because the price I decide to take the risk.
My device was KDG branded and with firmware 6.26. I would like to use it on KMS (cablesurf Munich)

Lets see what I did:
First I have De-branded (easy part):

1. Connect the device in the Lan1 port with an Ethernet cable directly to your computer;
2. In the windows execute console write FTP 192.168.178.1 (do not press enter yet);
3. Turn of the Fritzbox 6490, after 3 seconds (few time), turn on again. All leds will blink once than the Power/cable will start to blink alone. Now you press enter in the windows console.
4. The FTP screen will appear asking the username adam2, press enter
5. Password adam2, press enter. You are now connected
6. So input the following commands:
   
   1. quote GETENV firmware_version (this is optional, and it is only to see which version you have, mine was kdg)
   2. quote SETENV firmware_version avm
   3. bye

So now you have de-branded the firmware to avm, however it still not possible to do web upgrade in the firmware.

After these steps I was trying to follow other procedures to be able to update the firmware, including the one I will explain below, but it only works after some process which I really do not know if it was to be like that. So I will explain what I did and might work to you also. Remember I am really just a curious person with no big knowledge of programing or hacking.

So after all not success upgrades I have decided to activate the my modem in KMS (cablesurf Munich) even with the old firmware. Until that I was connected in Internet with my older modem and Fritbox connected to my computer by the Lan1 port.

Fingers crossed, KMS (cablesurf Munich) had activate without problems and I start to surf by my new Fritzbox with old firmware. Then I decided to configure my voip telephone number, however the button to add a new number was not appearing in the manage telephone number in the firmware menu.

After some search I was believing that the solution was to make a factory reset. I was concern to do it because read that someone has problems of bootloop after factory reset, but I decide to try. After that I could configure my telephone number flawless.

I was thinking, as the telephone was a particular issue maybe the failure in updates could be the same, so I decide to make it again. However my scenario was different from the previous tries.

So I would include this steps as part of the procedure but I could be wrong if it really matters.

1. Activate the modem in your provider, and connect internet through it.
2. Disconnect the Lan1 from computer and connect by WIFI (all my failures was connected by Lan1)
3. Make a factory reset in the modem (Go in the firmware menu – 192.168.178.1 - System / Backup / Factory settings

An now you can start the procedure to update the firmware with the trick of the Developer tools of your browser.

1. Download the firmware image from: http://download.avm.de/firmware/6490...41.06.61.image
2. Connect to Firmware page 192.168.178.1
3. Navigate in the menu to System / Backup / Restore tab
4. Click with the right button of the mouse over the button Choose file, than select in the menu Inspect element.
5. A Developer frames will open with the source codes of the page. You will need to change the following information:
   
   1. <input type="file" id="uiImport" name="ConfigImportFile" size="40"> Change it to:
   2. <input type="file" id="uiFile" name="UploadFile" size="40">
   
   
6. After this change in the source code, just click in the Choose file button (normal button of the mouse) and select the Firmware image file that you had download in the step 1.
7. Click now Restore button.
8. If it works for you, the file will be upload to the modem and then the update starts. It take time, around 5 -7 minutes. Wait with patience and do not turn off the modem.
9. If it not works, you will see a message similar to an Unspecified error occurred during the update. (0)…

If you were successful your firmware is now 6.61 with no brand, and you can now update directly to the newest firmware 6.83 (this in Jun 2017).
To do that you follow the same procedure as an owner of an articlenumber 20002778 device which is:

1. Connect to Firmware page 192.168.178.1
2. Navigate in the menu to System / Update and press Find New FRITZ!OS button.

These were all I did and now I have my 40 euro device doing the same as the 189 Euro articlenumber 20002778, I hope I could help others like me.
It might not work with higher firmwares, and I know some people needs to have telnet access to update in the flash memory directly. Unfortunately I could not follow this kind of process, so I am very happy that I could do it in this way described above.

Good luck to you folks. ;)

Hallo,

auch auf die Gefahr hin, dass ich hier gesteinigt werde, so möchte ich zunächst zu meiner Verteidigung sagen, dass es ein Akt der Unmöglichkeit ist, aus Threads mit 60+ Seiten die hierzu aktuellsten Informationen zu beziehen, aber nun zum eigentlichen Thema:


Von dem Gedanken, meinen "günstig" erstandenen Briefbeschwerer als eigentliches Kabelmodem für meinen Kabel Deutschland Anschluss zu nutzen, habe ich mich nach stundenlangem Stöbern nun schon verabschiedet, da die Box wohl niemals mehr von KD auf mich provisioniert werden wird.

Es wäre dennoch schön, wenn ich die Box zumindest als Router oder WLAN-Anbieter hinter meinem eigentlichen KD Modem betreiben könnte.
Bis zur FW 6.30 konnte man ja scheinbar das Branding über Telnet entfernen und anschließend die Firmware updaten auf AVM und somit die Funktion "Internet über LAN1" erhalten, was ja so ziemlich das ist ,was ich mir vorstelle.
Wenn man das bei einer neuern Firmware versucht, scheint die Box wohl in einen Boot Loop zu verfallen?
Es ist mir leider nicht gelungen, Informationen zu Boxen mit Branding Firmware 6.50 zu erhalten, weshalb ich hier um Hilfe bitte.

Bislang verwendete Quellen:

http://www.ip-phone-forum.de/showthread.php?t=286994
http://www.ip-phone-forum.de/showthread.php?t=203652

Hallo,

da ich überall gesucht habe und keinen Hinweis auf o.g. Frage finden konnte, frage ich hier mal nach.

Viele Grüße

Merlin89