Ich hoffe ich bin hier richtig:
Ist es mit einfachen Mitteln die Türklingel so an die Fritzbox zu koppeln, dass beim Klingeln ein Rundruf an alle Telefone geht?

Da wir oft im Garten sind, hören wir die Türklingel einfach oftmals nicht!

Wenn es dazu eine einfache Möglichkeit gibt, bitte ich um Informationen.

Gruß
K

Hallo zusammen,

ich habe hier eine 7362SL rumliegen und frage mich nun, wie ich über einen USB-Port eine externe Antenne anschließen kann.

Das Chipset der externen Antenne ist R8188EU.

Mein Gedanke ist es mit Freetz zu flashen und Treiber für die externe Antenne gegebenfalls mit dazupacken. Anschließend möchte ich die beiden Interfaces mit Hostapd und DHCP verknüpfen um "Virtual Wifi" zu ermöglichen und die interne Antenne als "Access Point" zu nutzen. Dazu müsste ich wahrscheinlich Hostapd und Pakete für den DHCP-Server auf das Image ziehen.

Hat jemand damit schon Erfahrungen gemacht? Ist das so möglich?

Danke & Grüße,
manip

Nachdem nun bei der 7390 der Plugin-Mechanismus wiederauferstanden ist (das war er bei der internationalen Version ja schon für die 06.20, weil die Language-Datenbanken ausgelagert wurden) und auch die (sicheren) Updates der DECT-Komponenten immer wichtiger werden, weil sie meist ohne Interaktion mit dem Benutzer ablaufen, wird es Zeit, den AVM-Mechanismus zum Signieren der Image-Dateien mal etwas genauer zu untersuchen (bzw. eher zu erläutern). Auch die Tatsache, daß neue Firmware nur noch korrekt signierte Firmware-Images installieren will, trägt natürlich dazu bei, daß dieses Thema einmal mehr in den Mittelpunkt des Interesses (zumindest des meinigen) gerückt ist.

Das ist hier wieder eher "als Story" erzählt ... wer es kürzer und "als Referenz" will, muß es eben selbst erkunden.

Nicht zuletzt spielt die Verwendung einer wirklich originalen Firmware auch dann ein Rolle, wenn man mein modfs-Skript verwenden will, um seine NAND-basierte FRITZ!Box an die eigenen Wünsche anzupassen. Dieses Skript kann ja auf Wunsch auch eine aktuelle Firmware direkt vom FTP-Server von AVM laden ... bisher wird dabei allerdings nicht getestet, ob es sich wirklich um eine unveränderte Version von AVM handelt oder ob da schon jemand manipuliert hat.

Nun kann so eine Image-Datei ja auf verschiedenen Wegen in eine FRITZ!Box gelangen, wer schon einmal einen Blick in das Shell-Skript /sbin/start_dect_update.sh einer aktuellen Firmware-Version gewagt hat, dem wird früher oder später unweigerlich die Zeile
ins Auge springen und nach etwas Analyse des Shell-Codes in dieser Datei stellt man dann schnell fest, daß damit offenbar ein solches Image (das ja nur ein TAR-Archiv mit einem "komischen Namen" ist) sowohl geladen (je nach URL) als auch geprüft und entpackt werden kann, denn nach dem Aufruf dieses Programms liegen die einzelnen Bestandteile so einer Image-Datei in /var vor, sofern die Datei korrekt signiert ist. Das gilt auch für die Datei /sbin/plugin_start.sh in der neuesten Version für die 7390, dort wird ebenfalls tr069fwupdate zur Prüfung benutzt:
... offenbar sind wir also bei diesem Programm schon vor der richtigen Schmiede.

Für eine genauere Analyse der Vorgänge dort, müssen wir uns also erst einmal eine passende Datei besorgen, die wir als Eingabe für unsere Tests benutzen können. Ein komplettes Firmware-Image paßt hier schon deshalb nicht so richtig, weil es eine erkleckliche Größe hat und wir absehbar mit ein paar Kommandos wie hexdump, dd und auch strings umgehen müssen, die bei einer größeren Datei dann auch größere Ausgaben produzieren und in der Regel auch länger brauchen bei der Abarbeitung.

Daher böte es sich an, für diese Untersuchungen ein Update-Image für ein DECT-Gerät von AVM zu verwenden, denn dieses ist normalerweise etwas kleiner - allerdings eignet sich seit dem Erscheinen der 84.06.51 das dort enthaltene plugins.update (auch ein verkapptes TAR-Archiv) noch viel besser für die ersten Schritte, da im Gegensatz zu den für andere Images verwendeten öffentlichen Schlüsseln:
es für das Signieren der Plugins offenbar ein anderes Schlüsselpaar gibt, dessen öffentlicher Teil in einer weiteren Datei enthalten ist:
Das hat also gleichzeitig den Vorteil, daß wir nicht erst raten müssen, welcher öffentliche Schlüssel denn nun zu einer Signatur gehören könnte ... die Annahme, daß es sich hier um den oben gezeigten handelt, ist ja naheliegend.

Also nehmen wir mal diese Datei plugins.update auf einer 7390 genauer unter die Lupe (sie wird ja beim Update auf die 06.51 automatisch an einer Stelle im Dateisystem abgelegt, auf die man notfalls auch mit den NAS-Funktionen zugreifen könnte), zuerst sehen wir uns einmal an, was dort an Dateien enthalten ist:
So eine Datei mit dem Namen signature in der Image-Datei legt ja einen Zusammenhang mit unserem Thema nahe, auf den ersten Blick wirkt es natürlich etwas seltsam, wenn die Signatur-Datei selbst Bestandteil der signierten Datei ist. Das kann normalerweise ja nicht funktionieren ... beim Berechnen der Signatur (die i.d.R. ja eine mit einem privaten (RSA-)Schlüssel verschlüsselte DER-Struktur ist, die einen kryptographisch erzeugten Hash-Wert über die signierte Datei enthält) kann ja das endgültige Ergebnis (also der Inhalt dieser Signatur) noch nicht in deren Berechnung einfließen; da muß AVM offenbar irgendwelche "Kunstgriffe" verwenden, damit das am Ende funktioniert.

Nun steht zu vermuten, daß AVM auch nicht jedesmal das Rad neu erfindet und daher wird die Berechnung so einer Signatur sicherlich in irgendeiner Bibliothek enthalten sein, da bietet sich eine solche mit dem Namen libfwsign.so ja geradezu als "Verdächtige" an. Schauen wir dort also einmal nach, was diese Bibliothek einem Aufrufer so zu bieten hätte (das erfolgt jetzt auf einer 7490 und in dem dort installierten Labor-Image (33361 - mit modfs angepaßt), weil ich die Toolchain nur auf der 7490 verwende und sie daher auch nur für die 7490 erstellt habe, die 7390 ist dafür dann doch zu schwachbrüstig - daher können die Offsets in der Bibliothek von denen in der 7390 abweichen):
Diese Bibliothek stellt also einige Funktionen zum Umgang mit einer Signatur zur Verfügung (die roten) und verwendet dazu offenbar kryptographische Standardfunktionen: MD5 - sicherlich für den Hash-Wert und RSA - womit man schon mal Daten bis zur maximalen Länge des Schlüsselpaars direkt signieren kann.

AVM verwendet 1024-Bit-RSA-Schlüssel, wie man oben anhand des Inhalts der /etc/plugin_global_key.pem ja sehen kann, die erste Zeile ist der Modulus und die zweite der Exponent des öffentlichen Schlüssel, das sehen wir später auch noch einmal in den Protokoll-Dateien von AVM.

Auf der anderen Seite paßt das auch hervorragend zu der Größe der Datei signature aus unserem Image, denn diese 1024 Bit sind ja genau die 128 Byte, die diese Datei groß ist und auch die von der libfwsign.so importierte Funktion BN_hex2bn paßt zu unserem Szenario, denn aus der Zeile mit den beiden Faktoren in der Datei mit dem öffentlichen Schlüssel müssen ja irgendwann wieder "big numbers" in der internen Darstellung werden, damit die Kryptographie-Funktionen damit umgehen können.

Auch die ebenfalls von der Bibliothek importierte Funktion RSA_verify paßt nahtlos zu den bisherigen Feststellungen (wobei man für das grundlegende Verständnis des AVM-Mechanismus nun nicht unbedingt auch mit den Kryptographie-Funktionen von OpenSSL programmieren können muß, das ist nur als "Nachweis" verlinkt).

Damit können wir (als Arbeitsthese) mal zwei Punkte festhalten:

1. Die Datei signature in so einer Image-Datei ist eine mit einem privaten RSA-Schlüssel erzeugte Signatur-Datei, der signierte Hash-Wert dürfte ein MD5-Hash über die Eingabedatei sein.
2. Dieses Verhalten müßte man auch mit "normalen Tools" nachbilden können, denn für das Signieren so einer Datei gibt es im OpenSSL-Paket auch entsprechende Programme.

Das läßt sich ja nun recht einfach mittels OpenSSL überprüfen, die dazu notwendigen Binaries kann man z.B. mit dem Freetz-Projekt erstellen.

Wenn es sich bei der signature um das vermutete Format handeln sollte, dann müßte diese Datei ja einfach zu "entschlüsseln" sein.

Dazu brauchen wir - neben einem möglichst kompletten OpenSSL-Programm, das eigentlich nur ein CLI für die libcrypto.so und libssl.so ist - noch die Signatur-Datei und den öffentlichen Schlüssel zu ihrer Überprüfung.

Erstere ist schnell extrahiert:
Nun ist die Datei /etc/plugin_global_key.pem in der AVM-Firmware ja trotz ihres Namens keine Datei in PEM-Kodierung, wie man sie gewöhnlich im Umgang mit Kryptographie-Tools findet, dort handelt es sich beim PEM-Format um die Base64-kodierte DER-Struktur - also ASN.1-kodierte einzelne Werte in binärer Darstellung.

Für das Umwandeln einer Datei aus dem von AVM verwendeten Format in eine "richtige" PEM-Datei habe ich schon vor langer Zeit ein Shell-Skript erstellt und dieses (auch schon eine Weile her) in meinem GitHub-Repository veröffentlicht: https://github.com/PeterPawn/YourFri...ubkey_to_pkcs8

Mit diesem Skript ist dann der öffentliche Schlüssel von AVM schnell in das passende Format konvertiert und einem Test der oben stehenden Hypothese zum Inhalt der Datei signature steht nichts mehr im Wege:
Nach der Umwandlung des öffentlichen Schlüssels noch einmal schnell den korrekten Aufbau verifiziert (wenn OpenSSL den akzeptiert, kann da nichts falsch sein, außerdem stimmt der angezeigte Modulus mit dem Hexdump im AVM-File überein) und dann erst einmal mit diesem öffentlichen Schlüssel den Inhalt der signature geprüft ... das hat noch nichts mit der Prüfung der Image-Datei zu tun, es stellt nur sicher, daß die Datei signature mit dem zugehörigen privaten Schlüssel erzeugt wurde und die oben zu sehende ASN.1-Struktur "enthüllt" auch, daß die Annahme eines MD5-Hashes richtig war - der rote Teil ist der mit der Signatur gesicherte Hash-Wert der Eingabedatei. Die Gegenprobe mit einem anderen Schlüssel ergibt dann den erwarteten Fehler - bis hier sollte also alles halbwegs stimmig sein.

Schauen wir uns jetzt das Ergebnis so eines Aufrufs von tr069fwupdate mal etwas genauer an:
Neben dem Return-Code erzeugt so ein Aufruf ja noch einiges an Dateien, schauen wir einmal, welche das sind:
In unseren umgeleiteten Ausgabedateien steht offensichtlich nichts (die haben die Länge 0) - da werden tatsächlich nur Fehler beim Aufruf (z.B. ungültige Dateinamen) protokolliert. Das Ergebnis der Signaturprüfung wird wohl am ehesten in den Dateien in /var/tmp stehen, die Liste wurde oben nach Datum sortiert und nur die relevanten Einträge werden dargestellt. Sehen wir uns zunächst die (vermutlich) relevantesten Dateien an:
Hier finden wir also unseren MD5-Hash in den Protokolldateien wieder ... die fwsign.log enthält darüber hinaus noch weitere Einträge zu anderen öffentlichen Schlüsseln (erst der grüne ist der hier verwendete), wenn man die Daten vergleicht, stellt man schnell fest, daß es sich hier um den Inhalt der Dateien für das Signieren von anderen Images handelt:
Anscheinend wird also bei der Verwendung der libfwsign.so (oder auch von tr069fwupdate selbst) nach mehr als einem Kandidaten für den öffentlichen Schlüssel geschaut ... wenn keiner gefunden wird, gibt tr069fwupdate allerdings einen Return-Code ungleich 0 aus, hier wurde also (s.o.) offenbar ein passender Schlüssel zum Prüfen der Signatur gefunden.

(Wenn man das später weiter testet, stellt man fest, daß da die Dateien /etc/avm_firmware_public_key[1-9] der Reihe nach probiert werden (so sie denn vorhanden sind) und dann erst kommt die /etc/plugin_global_key.pem dran - das merken wir uns mal für später als interessantes Detail.)

Nun ist offenbar beim Erzeugen der fwsign.log die Prüfung schon erfolgt bzw. in vollem Gange, das wirft dann die Frage auf, was da in der /var/tmp/firmware_stream_result stehen mag.
Dem Augenschein nach handelt es sich bei total=1239040 ja um die Größe der Image-Datei (viel weiter oben mal markiert in einem CODE-Kasten), ret=0 ist sicherlich irgendein Return-Code und die Angabe nach sigcrc ist ja ohne Zweifel der MD5-Hash, der uns hier immer wieder über den Weg läuft.

Bleibt die Frage, wer diese Datei eigentlich erzeugt ... da tr069fwupdate bereits selbst die Signaturen überprüft, macht so eine "intermediate"-Datei für dieses Programm ja nur begrenzten Sinn, es ist also anzunehmen, daß sie von einer anderen durch tr069fwupdate aufgerufenen Komponente erzeugt wurde als Mittel der Kommunikation zwischen Prozessen. Stimmt diese Annahme, wird der Dateiname irgendwo in dieser Komponente auftauchen und somit auch per grep zu finden sein.

Das machen wir jetzt wieder an einer entpackten Dateisystemstruktur für die 7490 (und auf der 7490), weil so eine Suche über das procfs auf der FRITZ!Box nicht funktioniert und das dann eine ziemlich nervige Zeile für den Aufruf von grep würde. Also verwende ich dafür die auf der Box entpackte Struktur der 113.06.55-33361 - irgendwo habe ich mal das Skript extract_7490_new_filesystem hier veröffentlicht, mit dem man so eine Struktur auf einer 7490 selbst auspacken kann (wenn man kein Freetz nutzen will) - allerdings muß man auf der FRITZ!Box dann sicherstellen, daß sich keine "directory loops" ergeben, wenn man rekursiv suchen läßt.
Das Ergebnis dürfte nicht allzuviel Interpretationsspielraum lassen ... ganz offensichtlich kommunizieren nur diese beiden Komponenten über diese Datei.

Also liegt die Vermutung nahe, daß tr069fwupdate (welches wir ja aufgerufen haben) seinerseits firmwarecfg aufruft. firmwarecfg ist nun ein CGI-Binary, das auch an diversen anderen Stellen im GUI für den Upload von Dateien verwendet wird, insofern wäre auch die Annahme, daß dort ebenfalls Funktionen zur Prüfung von Images enthalten sind (z.B. für das manuelle Update über eine Image-Datei), auch nicht so abwegig. Das war lange Zeit so etwas wie die eierlegende Wollmilchsau bei den binären Komponenten für das GUI - im Prinzip ist das sogar heute noch so, daß da alle möglichen Funktionen aus unterschiedlichen "Funktionsblöcken" enthalten sind.

Sehen wir jetzt mit strings mal in das Programm tr069fwupdate hinein, findet sich auch schnell der Aufruf von firmwarecfg:
Das hatten wir zwar früher schon festgestellt (bei der TR069-Geschichte) ... aber man sieht auch deutlich, daß offenbar irgendwie die Image-Datei auf verschiedenen Wegen bereitgestellt werden kann, aber am Ende landet sie immer in stdin für firmwarecfg, während die Ausgabe dann gleich per Pipe an das tar-Applet weitergeleitet und von diesem entpackt wird.

Spätestens seit der Version 06.30 der Firmware wissen wir auch, daß AVM da den Mechanismus beim Auspacken von Firmware-Images in firmwarecfg noch einmal geändert hat (bei der Verwendung von tr069fwupdate war da schon länger ein anderes Verzeichnis beim Aufruf eines der o.a. Kommandos aktiv, nämlich /var/packet), damit das Auspacken nicht mehr direkt nach /var erfolgt und dabei dann alle möglichen Dateien (im einzigen regulär beschreibbaren Verzeichnis unterhalb von /) überschrieben werden können.

Zwar wurde auch vorher schon sichergestellt, daß nur relativ zu ./var/ eingepackte Dateien überhaupt ausgepackt werden können (andere Pfade werden stur in /var/tmp/ignored_tar_content geändert von firmwarecfg stream, ebenso alle Dateien, die kein normales Verzeichnis/keine normale Datei sind oder das /../ für das übergeordnete Verzeichnis im Namen haben - obwohl das schon vom tar-Applet (inzwischen) verhindert würde), aber es gab immer wieder neue Ideen, wie man diesen Mechanismus zum Überschreiben von FRITZ!OS-Dateien verwenden könnte - schon früher wurde nach jedem der oben stehenden tar-Aufrufe die Datei /var/post_install aus dem SquashFS-Image erneuert, weil sie einfach durch so eine Image-Datei überschrieben werden konnte und dann beim Neustart des Routers Kommandos ausgeführt werden konnten. Seit der Verschärfung der "Sicherheitsbestimmungen" ist da jedenfalls (fast) alles wirklich sicherer geworden, weil nicht mehr mit dem Wurzelverzeichnis als Basis entpackt wird und die entpackten Dateien erst nach erfolgreicher Signaturprüfung nach / (bzw. /var) verschoben werden. Für die 06.30 hat dann auch AVM irgendwann mal diese beseitigte Schwachstelle beschrieben, nachdem der Finder sie auf der Full Disclosure-Mailingliste veröffentlicht hatte (bzw. parallel dazu, denn das war wohl abgestimmtes Vorgehen).

Ausgehend davon, daß der Aufruf von firmwarecfg das einzige Programm ist, was in den oben gefundenen Zeilen zwischen dem Download einer Datei und dem Auspacken steht, kann eigentlich nur innerhalb von firmwarecfg diese Umorganisation des Firmware-Images stattfinden und in der Tat stellt man bei direktem Aufruf von firmwarecfg fest, daß dort am TAR-Archiv "herumgepfuscht" wird:
Wie man sehen kann, fügt firmwarecfg dem Pfad so einer Datei einfach eine weitere Komponente unpack hinzu, dieses Verzeichnis wird auch vorher ordentlich rekursiv gelöscht. Damit ist das Schreiben außerhalb von /var/unpack durch das tar-Applet recht schwierig, auch wenn das Wurzelverzeichnis das aktuelle wäre für den tar-Aufruf - bei tr069fwupdate ist das ohnehin nicht der Fall, dort wird ja /var/packet beim Aufruf der Kommandokette verwendet.

Auf der anderen Seite kann man auch sehen, daß die Datei /var/tmp/firmware_stream_result tatsächlich von firmwarecfg (oder einer dort aufgerufenen Komponente) erzeugt wird, denn sie ist nach vorherigem Löschen und Ausführung von firmwarecfg ja wieder da.

Wenn wir jetzt etwas weiter oben noch einmal nach den Dateien schauen, die so ein Aufruf von tr069fwupdate offensichtlich erzeugt, stechen einem die Dateien /var/tmp/install_out.log und /var/tmp/install_error.log ins Auge, die waren vorher ebenfalls nicht vorhanden.
Hier handelt es sich augenscheinlich um die Ausgabedateien bei der Abarbeitung der im Image enthaltenen Skript-Datei ./var/install ... wenn die Signatur paßt, ruft tr069fwupdate offenbar auch gleich noch die im Image enthaltene Skript-Datei auf. Das disqualifiziert dann tr069fwupdate irgendwie als Mittel der Wahl für eine eigene Prüfung eines AVM-Images - es ist sicherlich nicht im Sinne des Erfinders, wenn ein Firmware-Image mit gültiger Signatur im Rahmen von modfs auch gleich noch installiert wird. Selbst wenn das in die inaktive Partition erfolgen würde und sich durch das Umsetzen von linux_fs_start auf den ursprünglichen Wert wieder rückgängig machen ließe, ist das eine unnötige Belastung des Flash-Speichers, denn sicherlich soll eher eine modifizierte Firmware nach modfs verwendet werden.

Also müssen wir uns vielleicht selbst um die Auswertung des Ergebnisses von firmwarecfg stream in der /var/tmp/firmware_stream_result kümmern, wenn wir nur rein die gültige Signatur eines AVM-Images überprüfen wollen. Probieren wir doch einfach einmal aus, ob bereits der Aufruf von firmwarecfg stream zur Ausführung der enthaltenen ./var/install führt:
Der Vergleich der Zeitstempel der erzeugten Protokolldateien macht schnell deutlich, daß von firmwarecfg tatsächlich nur die /var/tmp/firmware_stream_result geschrieben wird (neben der Ausgabe des modifizierten Archivs auf stdout). Für weitere Tests können wir uns also auch gleich auf den Aufruf von firmwarecfg stream beschränken.

Nun kommen wir wieder zu der Thematik zurück, wie eine Signatur gleichzeitig Bestandteil der signierten Datei sein könnte ... ohne besondere Vorkehrungen ist das schlicht nicht möglich, wie ich weiter oben schon mal angedeutet habe. Auch offenbart die Verwendung eines stinknormalen Programms zur Berechnung des MD5-Hashes für die plugins.update schnell, daß da offenbar der MD5-Hash nicht 1:1 über die Datei - so wie sie im Dateisystem liegt - gebildet wird, weder vor noch nach der Modifikation mit dem zusätzlichen unpack-Verzeichnis im Pfad:
Die Änderung an den Pfaden bewirkt zwar auch eine Änderung des Hashes, aber der ist immer noch meilenweit von dem entfernt, was da firmwarecfg für die Datei berechnet hat.

Ausgehend davon, daß es eben nicht möglich ist, die Signatur selbst in die Berechnung der Signatur einzubeziehen, liegt ja die Vermutung nahe, daß da von firmwarecfg auch einfach bei der Berechnung des Hashes diese Datei ausgeblendet wird ... wenn diese Annahme stimmt, müßte ja auch die Berechnung des Hashes durch firmwarecfg dasselbe Ergebnis liefern, wenn man diese Datei im "Ausgangsmaterial" ändert - eine solche Änderung fällt dann logischerweise nicht auf, wenn der Hash ohne diese Datei berechnet wird. Das läßt sich ja schnell überprüfen:
Die Datei ./var/signature ist die letzte im Archiv, der Header mit den Metadaten der Datei beginnt an Offset 0x12da00 und der eigentliche Inhalt der Datei beginnt am Offset 0x12dc00. Wenn der Inhalt der Datei tatsächlich nicht berücksichtigt wird, dürfte sich eine Änderung an diesem Inhalt nicht auf den Hash-Wert auswirken, den firmwarecfg berechnet/berechnen läßt (denn das macht sicherlich wieder die libfwsign.so). Also überschreiben wir den Inhalt einfach mit etwas anderem, ausgehend von der Angabe im total-Wert in der firmware_stream_result sollte man erst einmal nicht annehmen, daß die Datei einfach "ausgeschnitten" wird - solche abweichenden Längen machen das am Ende nur komplizierter als nötig:
Die Änderung des Inhalts hat also keine Auswirkung auf den durch firmwarecfg berechneten MD5-Hash, aber der Hash über die geänderte Datei stimmt immer noch nicht mit dem berechneten Wert überein, also ist da offensichtlich noch etwas anders im Archiv.

Nun kann man den Inhalt der Metadaten für die ./var/signature zwar wohl tatsächlich "vorhersagen" und könnte ihn vermutlich auch in die Signatur mit einbeziehen, aber genauso gut kann man die natürlich auch auslassen ... wir suchen ja jetzt nach der maximal möglichen Änderung am Eintrag für die ./var/signature, die noch keine Auswirkung auf den von firmwarecfg berechneten Hash hat. Die Hälfte der denkbaren Änderungen haben wir schon durchgeführt (so eine Datei in einem TAR-Archiv hat immer eine Länge, die ein Vielfaches von 512 ist und die Metadaten stecken ebenfalls in einem Block dieser Länge), also ändern wir jetzt einfach die andere Hälfte auch noch und sollte das nicht zum Erfolg führen (weil sich der Hash-Wert von firmwarecfg dann doch ändert), liegt die Wahrheit irgendwo in der Mitte zwischen den beiden Änderungen:
Wir können nun natürlich nicht länger nach dem Namen im Hexdump suchen, aber man sieht oben, daß die kompletten Metadaten und der Inhalt (2x 512 Byte) mit binären Nullen überschrieben wurden. Was sagt denn firmwarecfg zu dieser Datei?
Na also, für firmwarecfg sind die Dateien noch identisch und sogar das "Standardprogramm" zum Berechnen eines MD5-Hashes auf der Linux-Kommandozeile kommt zu demselben Ergebnis. Damit ist also nachgewiesen, daß von firmwarecfg bei der Berechnung des MD5-Hashes über ein Firmware-Image (bzw. über irgendeine TAR-Datei, die durch firmwarecfg stream gejagt wird) der Archiv-Member mit dem Namen ./var/signature nicht berücksichtigt wird ... man darf sicherlich auch getrost annehmen, daß das in der tatsächlichen Größe dieser Datei anhand der Metadaten erfolgt und nicht einfach 1024 Byte da blind überschrieben werden.

Damit wissen wir nun aber auch, wie wir für eine Signaturprüfung ohne die Verwendung von tr069fwupdate oder firmwarecfg stream vorgehen müssen.

1. Suchen des Offsets, an dem die Metadaten der ./var/signature in der Datei beginnen
2. Parsen der Metadaten, um die Länge der Datei zu ermitteln
3. Überschreiben der Metadaten und des Dateiinhalts (bis zur nächsten 512-Byte-Grenze) mit binären Nullen

Das so entstandene TAR-File kann dann ganz einfach mit dem OpenSSL-CLI-Programm getestet werden:
Der zweite Aufruf ist nur die Gegenprobe.

Nun gilt es also, die angeführten Aktionen so in einem Shell-Skript zu kombinieren, daß damit ein vom FTP-Server geladenes AVM-Image auf seine Echtheit geprüft werden kann (für modfs) und auf der anderen Seite ist es nun auch möglich, seine eigene Firmware zu signieren, wenn man sich selbst einen passenden RSA-Schlüssel (die 1024 Bit sind nun mal "Pflicht") erzeugt und den zugehörigen öffentlichen Schlüssel im richtigen Format (das ist ja auch alles andere als kompliziert) in das erste eigene Firmware-Image erst einmal eingebunden hat.

Hier rufen wir uns dann wieder in Erinnerung, daß tr069fwupdate (bzw. eher libfwsign.so) da zuerst die Dateien /etc/avm_firmware_public_key[1-9] versucht zu lesen und daß - in den Firmware-Versionen, die ich bisher gesehen habe - dort bisher nur bis zur "3" diese Dateien in Benutzung sind. Da es auch nichts schadet, wenn es eine Lücke zwischen den vorhandenen Dateien und der eigenen gibt, kann man den eigenen öffentlichen Schlüssel problemlos als /etc/avm_firmware_public_key9 in ein eigenes Image einbinden lassen.

Die entsprechenden Skript-Dateien für das Signieren eines eigenen Images (immer daran denken, daß die Verwendung einer solchen Signatur dann voraussetzt, daß man seinen öffentlichen Schlüssel irgendwie auf die FRITZ!Box gebracht hat und zwar auch noch unter dem richtigen Namen) und für die Prüfung so einer Signatur kommen in Kürze ins GitHub-Repository ... aber das kann noch ein wenig dauern. bzw. sie stehen inzwischen unter https://github.com/PeterPawn/YourFri...ster/signimage im Repository. Der Frage, wie der Aufruf da auszusehen hat und wie man eine AVM-Signatur prüft bzw. seine eigene erzeugt, die dann von einer Firmware mit dem zusätzlichen öffentlichen Schlüssel auch mit Bordmitteln getestet werden kann, widmet sich der nächste Beitrag.

Sollte jemand Fragen haben, wäre es nett, wenn die erst einmal in einem gesonderten Thread gestellt werden könnten - event. kann dann ja ein Moderator diesen zusätzlichen Thread später hier anhängen, wenn ich mit der Beschreibung fertig bin.

Hallo,
ich würde gern über das Intranet den Nutzern des Heimnetzwerkes ein paar Internetseiten zur Verfügung stellen.

Nun überlege ich, wie ich es umsetzen könnte. Am liebsten wäre es mir, wenn ich keinen eigenen Computer, wie z.B. mit dem Raspberry Pi, dafür laufen lassen müsste, sondern wenn ich die FritzBox (7360 SL), die eh 24h am Tag an ist, dafür verwenden könnte. Es steckt für den Anrufbeantworter eh bereits ein USB-Stick drin, der sich für die Speicherung der Webseiten anbieten würde. Das Problem ist nur, dass es keine statischen Seiten sind, sondern dass ich noch eine Datenbank benötige und einen Interpreter für das Backend (am liebsten Javascript für node.js. Python für aiohttp wäre auch ok und zur Not Ruby für Ruby on Rails).

Ich habe mal nach "Webserver auf FritzBox" gegoogelt und bin auf ältere Threads von 2005 ( http://www.ip-phone-forum.de/showthread.php?t=145922 ) und 2007 ( http://www.ip-phone-forum.de/showthread.php?t=136258 ) gestoßen. Da sich ja viel in dem Bereich tut wollte ich Fragen, ob das immer noch die empfohlenen Vorgehen sind, ob es aktualisierte Tutorials mit neuen Versionen gibt oder ob es auch alternative Vorgehen gibt.
Ich kenne mich mit Modifizierungen der FritzBox nicht aus (momentan ist das normale Fritz!OS 6.3 installiert) und würde auch einen Weg bevorzugen, mit dem ich das original FritzOS nutzen kann.

Danke für eure Hilfe.

Grüße
Ulrikop

Guten Tag

Ich habe eine Fritzbox 7360SL von 1&1 mit Firmwäre 6.31 in englisch.
Auf der Oberfläche steht auch nur 7360 ohne SL

Wie kann ich die originale Firmware laden?
Ich habe es über die Oberfläche versucht aber die Box sagt immer falsche Firmware.
Das Tool welches man über Windows nutzen kann sagt das gleiche.

Hat jemand eine Idee?


MFG

Hallo,

wie viele vor mir auch wünsche ich mir die LEDs meiner Fritz!Box 7490 zu deaktivieren. Am liebsten natürlich permanent, allerdings bin ich auch schon froh hier Hilfe für eine Deaktivierung bis zum nächsten Re-Boot zu bekommen.

Nachdem ja Telnet ab Version 06.50 nicht mehr (regulär) aktivierbar ist fallen die bisherigen Lösungsmöglichkeiten die hier im Board beschrieben sind leider aus. Habt Ihr eine software-technische Lösung um die LEDs zu deaktivieren?

Besten Dank für Eure Hilfe!

lmvdr

7490, derzeit 6.23, telnet an


Hallo liebes Forum,

ich bräuchte mal einen Schubs in die richtige Richtung:

Ich möchte einige Werte (WLAN-key etc.) in einer 7490 dauerhaft so verändern, das sie (die Werte) auch ein Recover überstehen. Ich habe mittels rukerneltool mal an diversen x.cfg rumgefummelt, erstaunlicherweise nimmt die Box für vieles auch Plain Text :eek:

Ein Update übersteht der so gesetzte Key, ein Laden der Werkseinstellungen bzw. ein Recover natürlich nicht. IIRC konnte man all das mit dem rkt bei allen Boxen kleiner 7490 "recoverfest" flashen. Bevor ich nun den Lötkolben anwerfe:

- Ich vermute als Speicherort für diese Daten das Eprom mittig Platinenunterseite. Richtig?
- Wie kann ich das ohne Lötkolben-Einsatz beschreiben?

Ein paar konkrete Stichworte reichen mir, ich lese mich dann ein. 7490, Flash, (E)EPROM sind auch in Kombination undankbare Suchbegriffe.

Danke schonmal und munter bleiben :D

Hi,
habe zufällig per Websuche ein tolles Tool gefunden. Es gibt hier im Forum auch keinen Eintrag dazu.
Das Auslesen, Dekodieren, Extrahieren, Hashen und Reimportieren von der Fritzbox ist ein wichtiges Thema.
Insbesondere für Besitzer von Fritzbox-UM-Kastraten wie meiner Wenigkeit.

Das geht mit den Fritzboxtools sehr einfach. Habe es auf einer Fritzbox 7490 mit FritzOs 06.50 versucht.
Einwandfrei. Tipp: die portable PHP distribution, kriegt man auch im DL-Bereich vom Entwickler.

Sollte nicht unerwähnt bleiben.

;)

Zugangsdaten.png

1file_decrypted_1.png

Extracted.png

Edit: PeterPawn hat es sich angeschaut und hier ein paar Sätze zur Funktionsweise niedergeschrieben.

Angehängte Grafiken

• Zugangsdaten.png (187,5 KB)
• 1file_decrypted_1.png (37,5 KB)
• Extracted.png (70,2 KB)

Hallo zusammen,

ich besitze eine Fritz 7490 (ohne jegliche mods) und bin auch eigentlich zufrieden damit. Jedoch geht mir der DHCP Server tierisch auf den Geist.

Wichtig ist mit ein DCHP Server mit fester IP über die MAC und das die anderen IPs nach ein paar Stunden wieder verschwinden. Die feste IP Anbindung über die FritzBox finde ich alles andere als gelungen und Geräte die schon tagelang nicht mehr im Netz waren, werden immer noch aufgeführt.

Daher meine Idee:

1. Die FritzBox mit freetz und dnsmasq (mittlerweile recht schwer zu installieren, da ab Firmware 06.51 keine fremde Firmware mehr zulassen)
2. Einen TP Router mit openwrt und dnsmasq

Was würdet Ihr empfehlen, auch hinsichtlich Gastzugang und dem anderen IP Adressraum?

Danke!

PS: Kennt sich jemand damit aus oder hat es sogar am laufen, so dass ich für den ersten Start mit dnsmasq Hilfe bekommen könnte?

Hallo zusammen,

ich habe eine ältere Fritzbox 7360 "M-Net Edition" und würde dieser gerne eine neuere Firmware verpassen. Ich habe mich schon ein bisschen eingelesen und es gibt wohl nicht bei allen Hardwarerevisionen meiner Box die Möglichkeit eines Updates. Daher wollte ich erst mal die genaue Hardware Revision meiner Box bestimmen. Leider hat das bisher nicht ganz geklappt.
Ich habe hier einen interessanten Beitrag gefunden, in welchem diverse Versionen der 7360 gelistet sind. Leider ist meine nicht exakt dabei. Meine Artikelnummer passt zu keiner der in dem Beitrag gelisteten Boxen. Die Artikelnummer meiner Box ist: 2000 2553


Folgende Infos habe ich aus einer Sicherungsdatei ausgelesen:

FirmwareVersion=111.06.30
CONFIG_INSTALL_TYPE=mips34_16MB_vdsl_dect441_2eth_ 2geth_1ab_pots_2usb_host_wlan11n_25711
OEM=avm
Country=049
Language=de


Zusätzlich habe ich noch ein paar Infos aus einer "Supportdaten" Datei geholt:

HWRevision 183
HWSubRevision 2
ProductID Fritz_Box_HW183
annex B
autoload yes
bootloaderVersion 1.1475
firmware_info 111.06.30
firmware_version avm
flashsize nor_size=16MB sflash_size=0KB nand_size=0MB


Kann mir eventuel einer von euch weiterhelfen? Bestet für meine Box die Möglichkeit eines Updates oder besorge ich mir besser gleich eine neue?

Hallo zusammen,


ich muss mich zunächst entschuldigen, ich habe bereits zwei Tage Recherche betrieben, auch hier im Forum, da ich jedoch ein absoluter Nichtsblicker in diesem Thema bin, habe ich keine Lösung für mein Problem gefunden oder habe es nicht verstanden :(

Ich habe folgende Ausgangssituation:
Funkgong von Friedland an der Türklingel angeschlossen, insgesamt 3 Gongs im Haus (Einfamilienhaus) verteilt.
Fritzbox 6360, daran Panasonic Telefon direkt per Stecker an die Fritz angeschlossen und 3 Handgeräte in Betrieb.
Nun möchte ich irgendwie eine einfache Gegensprechmöglichkeit mit diesen 3 Handgeräten realisieren, und zwar derart, dass die 3 Handgeräte klingeln, wenn die Türklingel betätigt wird, und ich gegensprechen kann. Türöffnung oder ähnliches ist nicht interessant.

Ich stelle mir da in meiner laienhaften Ansicht einen kleinen Kasten vor, den ich in den Bereich der Türklingel packe, und der im Prinzip wie ein internes Telefon agiert.
Das Ganze müsste per Funk gehen, weil ich keine Kabelverbindung zwischen Haustür und Fritzbox herstellen kann. Wohl müsste dieser Kasten auch mit Batterien laufen, weil ich nicht wüsste, wie ich sonst den Strom herbekommen soll (Klingeldraht?)

Gibt es solch ein Bauteil oder ähnliches, welches meine Anforderungen erfüllt?

Leider kann ich zur Veranschaulichung kein Foto des Innenlebens des "Klingelkastens' beifügen, die Anhänge hier kann ich nicht verwalten (nur graues Fenster), Bild hochladen schlägt fehl und Links werden unkenntlich gemacht, so daß sie auch nicht mehr funktionieren :(



img4web_.com/i/1APL88.jpg

EDIT: Wenn man hier den Unterstrich entfernt, kommt man wenigstens zum Bild :p



Ich bin für jeden Hinweis und Idee dankbar, vielen Dank schon mal und einen schönen Tag!

Gruß,
load.balancer

Moin!

Ich habe vor kurzem modfs mit der aktuellen Firmware 6.60 auf einer 7490 installiert.

1. Nun ist es so, dass ich das WLAN jede Nacht um 2.00 Uhr bis 8.30 Uhr per Zeitschaltung abschalte.
Da die Box in beiden WLAN-Bändern (2,4Ghz und 5Ghz) nur mit 14dbm Sendeleistung funken (ich meine, dass der Wert vor dem 6.60er Update höher war), habe ich das per Telnet geändert (iwconfig ath0/1 txpower 21). Leider ist es nun so, dass nach Wiederanschalten des WLANs um 8.30 die Sendeleistung wieder auf 14dbm zurückgesetzt wird und ich jeden Morgen die Sendeleistung wieder erhöhen muss.
Ist es möglich, das irgendwie per Script zu regeln? Leider weiß ich nicht wo ich ansetzen muss. Normalerweise regle ich das über /etc/init.d, da SquashFS aber leider nur les- und nicht beschreibbar ist, geht das verloren.

2. Leider gar keine Ahnung: Woher bekomme ich zusätzliche Programme und wie kann ich diese installieren? Ich würde gerne dnsmasq installieren.

Kann mir hier jemand weiterhelfen?

Gruß
unwohltaeter

- - - Aktualisiert - - -

Niemand, der mir helfen kann bzw. will?

Ich habe auf meiner FB7390 (mit Freetz) einen Email Account auf den DECT Telefonen der nur dazu dient Statusbenachrichtigungen per Mail zu empfangen. Nun möchte ich auch auf einem weitere FritzFon diese Emails empfangen können. Was doof ist: ich habe das Passwort vergessen. Das wurde vor Jahren mal eingerichtet, sowohl auf dem Windows Server zum Versand der Emails als auch auf dem einen FritzFon, und danach nie wieder benötigt.
Mit den üblichen Ansätzen zum auslesen der Kennwörter für das Webinterface oder VoIP Zugansdaten komme ich nicht weiter. Wo werden denn die Infos zur Konfiguration der DECT-Telefone gespeichert?

Hallo, sicher bin ich nicht der erste der danach fragt, aber ich habe keinen passenden Blog dazu gefunden.

Die Ausgangslage: Hatte eine FB 7390 in der CH/A Version und mich immer geärgert, dass die Firmware Updates monatelang hinter her hinkten. Da ich kein VDSL einsetze, sonder einen Glasanschluss habe, kaufte ich mir eine D Version der FB 7390 und ich gehörte wieder dazu :p.

Ich habe mir nun günstig eine neue FB 7490 kaufen können, leider wieder eine CH/A Version. Die aktuelle FW ist die 6.52 - bei der D Version wäre es die 6.60, ich freue mich aber schon auf die finale Version der heute sich im Beta Stadium befindenden Version (ein paar tolle neue Features). Aber ich werde wohl als CH/A Benützer immer wieder länger warten müssen.

Nun zu meinen Fragen:

Ist der Aufwand sehr gross, aus der CH/A Version eine D Version zu machen? Habe gelesen, dass mit dem ruKernelTool gearbeitet werden muss. Bin nicht sicher, ob ich mir da grosse Probleme einhandle oder ob das mit ein paar Clicks und Downloads möglich ist. Ebenfalls werde ich wohl die Garantie verlieren oder?

Dann zur zweiten Frage: Meine aktuelle 7390 ist sehr komplex aufgebaut. Habe einen USB Stick, einen Mobile Stick, VoIP mit 6 AVM Funktelefone und diverse VoIP Apparate. Zusätzlich diverse Rufsperren, Diverse Nummern (total 6), Portweiterleitungen, etc. etc. etc.

Muss ich alles komplett neu programmieren oder gibt es gewisse Einstellungen, die ich von der 7390 auf die 7490 übernehmen kann?

Vielen Dank im Voraus.

Hi, ich habe mir eine Fritzbox 6490 gekauft. Laut Vorbesitzer ein freies Gerät welches noch nie im Betrieb gewesen ist.
Scheint auch so zu sein, ich sehe im Menü keinerlei Providerbranding, Version. 6.26
Problem was ich nun habe, wie mache ich hier ein FW Update? Bei meiner 7490 habe ich im Menü die Option Update, aber dieses fehlt hier.

Jemand eine Idee was ich da machen kann?

Frage 1: Ist bei der Fritz!Box 6490 Cable mit Artikelnummer AVM 20002778 eine Zwangsprovisionierung durch den Kabelanbieter sicher vermeidbar bzw. in gewünschten Teilbereichen eine Provisionierung gezielt ab-/anwählbar?

Hntergrund der Frage ist die fehlerhafte Zwangsprovisionierung eines Cisco EPC3925-Kabelmodem durch Unitymedia (UM), welche eine Sicherheits-Scheunentor aufreißt. Die Konstellation würde ich gern ändern. Gegeben sind Unitymedia Kabelanschluss mit öffentlicher IPv4-Adresse UND Telekom ISDN-Anschluss (ohne DSL) mit 6 MSNs. Am UM Kabelanschluss hängt ein Cisco EPC3925. Eine Fritz!Box 7490 ist per ’über LAN 1 Internetverbindung selbst aufbauen’ damit verbunden und zugleich mit dem T-ISDN Anschluss. So hat die Familie schnelles Internet und stabile Telefonie und es könnte alles gut sein (klar: bis irgendwann das ISDN wegfällt).

Nun begibt es sich, dass UM die Benutzerkonfiguration des EPC3925 per Zwangsprovisionierung überschreibt und dabei einen erheblichen Sicherheitsmangel „einbaut“, der unerwünscht ist. Im Kontakt mit UM war dazu bisher keine befriedigende Abhilfe möglich, leider.

Frage 2: Wie also in eigener Regie vorgehen?

• A) Eine Fritz!Box 6490 Cable mit Artikelnummer AVM 20002778 besorgen und den ISDN-Anschluss über eine zweite Fritz!Box integrieren (z.B. vorhandene 7490 od. alte 7170).
  (--> ISDN zu SIP zu migrieren ist hier zur Zeit nicht gewünscht ! )

• B) Ein „freies“ Kabelmodem (was macht ein freies Kabelmodem aus?) nach Euro-Docsis 3.0/3.1 Standard, Bridge-fähig und möglichst ohne Telefoniefunktionen auftun, bei dem eine providerseitige Zwangsprovisionierung sicher unterbunden werden kann.

Frage 3: Was würdet Ihr tun, was spricht für/gegen A) bzw. B)?

• Risiko, dass doch irgendwie/-wann eine Zwangsprovisionierung stattfinden mag
• Stromverbrauch gesamt bei einer Lösung günstiger
• Umständliche Übergabe der ISDN-Telefonie bei B)
• u.a.m.

Frage 4: Kann jemand ein geeignetes Kabelmodem (müsste ja wohl Euro-Docsis 3.0/3.1 sein, oder?) empfehlen, welches folgendes unterstützt: feste IPv4, Bridge-Modus, unterbindbare Provisionierung durch den Kabelanbieter, geeignet für 150/10 MBit/s, gute Funktion, geringer Stromverbrauch ... und auch sagen, wo das her zu bekommen ist, bitte?


Für Diskussion dankt
Fib

Ich habe heute die frei käufliche 6490 mit der Version 6.60 erhalten. Leider kann dort die satipdesc.xml nicht gefunden werden, ebenso der Pfad /upnp/control/satip. Die Dateien satipdesc-template.xml und satipSCPD.xml gibt es allerdings. Gibt es eine Einstellung die diese aktiviert? Mein Ziel ist es alle Tuner in TVHeadend einzubinden.

Sorry if i write in english i hope it's ok.

I have a 7490 6.52 that is fully working and running and it's capable to get the voip autoconfiguration from the provider through tr069.. since it's not possible to manually edit the details for tr069.cfg using the user interface the only way it's to write directly the *.export backup -> recalculate the checksum -> restore it.

The problem is that some of those details are encrypted (i have all of them), so my question is if there is any way to calculate the encryption manually so that when i restore it the fritzbox can actually understand it and decrypt it.. that is simple if i wanted to change something like the webui port because that value is not encrypted.

Example:

7490 with user/pwd of the tr069 login set to harvey/specter, if i make a system settings backup i see that in the tr069.cfg part the user/pwd are encrypted, and that's ok.. if i wanted to change them to mike/ross manually (since the UI does not allow it like the wifi password) i have to encrypt those two values (using probably the system backup password) and then recalculate the checksum of the *.export file so that i can restore it with the new values.

Is there any way to do this?

Moin. :D

Nachdem ich meine 6490 erfolgreich nach avm debrandet habe und kein Erfolg beim provisionieren hatte wollte ich sie auf kdg zurücksetzten. Leider startet die Box nun nicht mehr. Kann sie auch nicht per ftp erreichen. Kann mir jemand helfen. Wäre schön. ;)

Hallo, ich bin hier neu und ich entschuldige mich zuerst für mein Deutsch aber es ist offensichtlich nicht meine Muttersprache.
Ich habe ein Kabel Deutschland Internet Vertrag seit etwa zwei Jahren und ein "alte" Fritz!Box 6360 Router das ich gerne nochmal benutzen würde, seit ich hier gelesen habe.
Wenn ich es zu mein Kabelanschluss verbinde, bekomme ich aber kein Internet Zugang (Power/Cable LED blinkt). Ich habe KD angerufen und sie meinten das mein Fritz!Box 6360 Artikelnummer (2000-2506) nicht funktionieren kann, sondern nur die Artikelnummer 2000-2778.
In diese Seite habe ich verstanden das die Artikelnummer zu tun hat mit der branding des Router (und wahrscheinlich der firmware).
Jetzt meine frage: wie kann ich mein Fritz!Box 6360 ändern damit es mit KD funktionieren kann? Wenn ich ein 2000-2778 firmware finden würde, und es in mein Router hochladen könnte, würde es aussehen wie ein 2778 gerät?
Vielen Dank erstmal :-)