Fritzbox 6490 Cable Firmware Update?

warum gibt es eigentlich auch ein "tar cf /var/flash/provideradditive.tar provider_additive" in der libcmapi.so?) und kann mit passend zurechtgebogenem Inhalt Dateien im "tmpfs" der Box überschreiben (recht weit vorne im Startprozess).

die "einschlägige Literatur" lieferte mir folgendes:
ob die tatsächlich diese "provideraddtive.tar" irgendwo permanent erzeugt oder ob die nicht nur "on the fly" gepackt wird, um sie beim Sichern der Einstellungen zu archivieren. Die Zeilen
Code:
/var/flash
provideradditive.tar
/var/tmp
tar cf %s provider_additive

in der libcfgimpexp.so lassen mich letzteres vermuten ... /var/flash als aktuelles Verzeichnis, wo das "tar"-Kommando mit dem zusammengesetzten Pfad aus "/var/tmp" und "provideradditive.tar" ausgeführt wird und die dort entstandene Datei dann in der Export-Datei landet. Man sieht ja in den Köpfen der Dateien im "Textformat" auch, daß die ebenfalls direkt für den Export als Kopie in /var/tmp erzeugt werden - bei der provideradditive.tar wäre es eben ein etwas komplexeres Kommando zur Erzeugung.

dies erklärt jedoch noch nicht den Zusammenhang mit libcmapi.so;
CM steht üblicherweise für "cable modem";
ist da evtl. noch mehr implementiert worden ? z.B. Datei-Download nach /var/tmp/provider_additive und dann "on the fly" packen nach /var/flash/provideradditive.tar ?
 
Ich tippe eher darauf, daß in "libcmapi" das "cm" für "ctlmgr" steht ... sonst wäre die Existenz (und Verwendung, wie ein Blick mit "cat /proc/$(pidof ctlmgr)/smaps" (oder auch "maps") verrät) auch außerhalb der DOCSIS-Modelle etwas schwer zu erklären. Auch der Umzug diverser Funktionen aus dem "ctlmgr" in diese (neue) Library in nicht allzu ferner Vergangenheit spricht dafür.

Wobei die "additive"-Datei ja nicht exportiert wird (afaik) - insofern ist auch diese o.a. Vermutung meinerseits inzwischen überholt, das wußte ich damals eben auch noch nicht definitiv, weil ich keine Box mit einem solchen Zusatz hatte und ihn auch noch nicht selbst "herstellen" konnte. Die Spuren in der "libcfgimpexp.so":
Code:
NoDelete=yes
ProviderDefaultConfig=yes
ProviderAdditiveConfig=yes
NoUserOverwrite=yes
stammen (so meine derzeitige These) von der Möglichkeit, eine solche Zusatzkonfiguration auch als Import-Datei bereitzustellen - ob das jetzt regulär genutzt wird oder nur in der ebenfalls noch alternativ vorhandenen Möglichkeit, eine Datei auf einem USB-Stick als Konfigurationsvorlage einzulesen (über "tr069starter", was bei jedem Mounten eines USB-Volumes nach entsprechenden Dateien sucht), Anwendung findet, weiß ich auch noch nicht. Jedenfalls lassen ja "NoUserOverwrite" und "NoDelete" die Vermutung zu, daß es auch ohne "cfgtakeover" einen partiellen Import bzw. ein Mischen von Einstellungen geben könnte - beim normalen Import wird ja alles ersetzt.

Hier hilft jetzt auch alles Spekulieren und Nachdenken/Brüten über den Ergebnissen von Dumps nicht wirklich weiter ... das muß man einfach einmal ausprobieren, wann dieses "tar c" zuschlägt (und zwar einmal das in der "libcmapi.so" und einmal das in der "libcfgimpexp.so", da sind ziemlich sicher unterschiedliche Trigger am Werk) und was hinterher im Node 29 steht. Selbst wenn so ein eigener Zusatz zur "provideradditive.tar" irgendwann wieder überschrieben würde ... als Einstieg ist das eben leider auch schon vollkommen ausreichend für einen Angreifer.

Hier wäre es ja z.B. auch denkbar, in die "/var/post_install" die Kommandos einzubauen, um eine geänderte Firmware (aus dem Internet geladen bei einem echten Angreifer - notfalls in einem "zweistufigen Verfahren", falls die Internet-Verbindung nicht die schnellste ist - oder auf dem USB-Stick abgelegt bei einem berechtigten Benutzer) vor dem nächsten Neustart zu installieren. Das dauert vielleicht 30 Sekunden extra, bei einer 6490 ein wenig mehr, wenn man noch die Prüfung machen läßt und das merkt normalerweise kein Besitzer einer Box.

Es bleibt eben dabei ... so ein schreibender Zugriff auf (eigentlich dem Zugriff entzogene) Verzeichnisse in einer Box bietet jede Menge Möglichkeiten als Einstieg, auch wenn die nicht immer sofort ins Auge springen. Deshalb ist das ja auch der Punkt (neben RCEs, die aber auch eine Folge solcher Schreibzugriffe sein können), der in so einer Firmware "am besten verteidigt" sein sollte - alles andere (auch "security by obscurity") sind nur (früher oder später nutzlose) Krücken, wenn es um die Abwehr von Angriffen geht.

Zwar hat AVM es inzwischen geschafft, die Zugriffe über die NAS-Funktionen (FTP, Samba, NAS-GUI) auf Pfade unterhalb von "/var/media/ftp" zu beschränken (oder sagen wir mal, ich habe noch keinen Weg gefunden, dort Fehler zu provozieren - weder über "traversal" noch über "special files" oder "symbolic/hard links"), aber der kleinste Fehler an so einer Stelle führt dann eben zur Möglichkeit des Ausbruchs aus diesem "Gefängnis" - und spätestens weil alle Benutzer Mitglied der Gruppe "root" sind, bringen an dieser Stelle dann auch ACLs nur noch den halben Effekt und das auch nur dann, wenn sie richtig gesetzt sind.

Auf vielen Modellen fällt sogar das oben von Dir angesprochene Ersetzen der Verzeichnisse des Webservers gar nicht weiter auf - beim Testen von eigenen Änderungen am GUI ist das auch der bessere Weg im Vergleich zum "bind"-Mount für einzelne Dateien, wenn man den gesamten Verzeichnisbaum kopiert (braucht 5-6 MB zur Speicherung) und diesen Link ersetzt, dann hat man auch gleich die Sicherung der Änderungen auf einem persistenten Speicher, falls man doch mal einen Neustart oder sogar Recovery machen muß und nicht nach jeder Änderung ein Backup machen will. Da die Zugriffe über diesen Link i.d.R. im Rahmen eines zusätzlichen Aufrufs von "luacgi" erfolgen, wirkt sich eine Änderung des Links normalerweise auch aus, ohne daß man den Webserver (aka "ctlmgr") neu startet.

Aber auch als "Versteck" für eigenen Code/eigene Dateien eines Angreifers ist der interne NAND-Speicher für das NAS eben benutzbar (und der wird normalerweise auch nicht vom Benutzer einfach mal abgezogen zum unpassendsten Zeitpunkt) ... bei einer 7412 gibt es z.B. keine NAS-Funktionen, damit kann ein Angreifer dort den Platz unter "/var/media/ftp" (auch wenn es nur 15-20 MB sind, je nachdem, wie "unauffällig" man sein will) ziemlich ungeniert benutzen und auch auf anderen Boxen (mit NAS-Funktion) fällt sicherlich ein Verzeichnis "avm" unterhalb von "FRITZ" eher weniger auf - vor dem Löschen über das NAS-GUI sind da die Dateien des Angreifers auch schon mal sicher, denn das wird dort blockiert.

Wie schon desöfteren mal von mir zu lesen war, ist das FRITZ!OS gegen Angriffe von innen in meinen Augen erstaunlich schlecht gesichert ... das stammt eben in weiten Teilen auch noch aus einer Zeit, wo das LAN "grundsätzlich gut" war und so ein Paradigmenwechsel braucht seine Zeit, bis der in den Köpfen der Leute und im Programm-Code angekommen ist. Da, wo andere Hersteller dann auch mal mit der Firmware von vorne beginnen, ist es bei AVM eben eine beständige Weiterentwicklung und Änderung bestehenden Codes - das hat ja auch seine Vorteile, denn im Vergleich zu anderen Geräten in derselben "Leistungsklasse" sind die FRITZ!Boxen dann wieder erstaunlich sicher und auch recht gut getestet (aber natürlich auch entsprechend teuer im Vergleich zur - meist schlechter ausgestatteten/integrierten - Konkurrenz).

Selbst teurere Hersteller wie Cisco (oder Linksys) haben immer wieder mal erhebliche Lücken in ihrer Firmware (welche die NSA dann halt als "Beute" betrachtet und benutzt) und wenn das für andere Hersteller von Geräten für SoHo-Einsatz (bintec, Lancom, usw.) vermeintlich besser aussieht, weil man so wenige Informationen dazu findet, dann liegt das m.E. auch daran, daß sich kein Mensch wirklich für diese Geräte als Ziel interessiert, weil es ihnen einfach an Verbreitung mangelt. Zwar mag bintec/elmeg mit den Telekom-Digitalisierungsboxen eine Nische besetzen und bei (meist eher kleineren) Unternehmen auch Lancom eine Rolle spielen ... aber das sind eben immer noch Bruchteile von dem, was sich an (meist auch noch schlecht gesicherten) AVM-Routern in deutschen Haushalten so tummelt und für den Aufbau von Bot-Netzen (so ähnlich wie diejenigen, welche vor kurzem erst die Website von B. Krebs angegriffen haben) sind viele, ggf. auch schlechter angebundene Systeme eben besser geeignet als wenige gut angebundene ... da verkraftet so ein Bot-Netz dann auch den regelmäßigen Ausfall eines Teils der Teilnehmer durch Updates oder Austausch nach Entdeckung, solange nur neue infizierte Geräte dazukommen.
 
[...]

Hier wäre es ja z.B. auch denkbar, in die "/var/post_install" die Kommandos einzubauen, um eine geänderte Firmware (aus dem Internet geladen bei einem echten Angreifer - notfalls in einem "zweistufigen Verfahren", falls die Internet-Verbindung nicht die schnellste ist - oder auf dem USB-Stick abgelegt bei einem berechtigten Benutzer) vor dem nächsten Neustart zu installieren. Das dauert vielleicht 30 Sekunden extra, bei einer 6490 ein wenig mehr, wenn man noch die Prüfung machen läßt und das merkt normalerweise kein Besitzer einer Box.

[...]

wird "/var/post_install" etwa bei jedem "init reboot" aufgerufen?
 
Zuletzt bearbeitet:
"/etc/inittab" aus 141.06.62 (ARM) - weil das ja ein Thread ist, der sich um die 6490 dreht:
Code:
#
/dev/console::sysinit:/etc/init.d/rc.S

# Start an "askfirst" shell on /dev/console
/dev/console::askfirst:-/bin/sh

# Stuff to do before rebooting
/dev/console::shutdown:/bin/sh -c /var/post_install
Ich würde mal sagen: ja.
 
Ich würde mal sagen: ja.

Sehr gut, dann besteht ja jetzt wieder Hoffnung meine 6490 mit 6.50 auf 6.62 und wieder online zu bringen... ;)

Jetzt muss ich mir "nur" noch ein passend modifiziertes tffs + provideradditive.tar mit entsprechender traversiertes "/var/post_install"-scripts basteln. Ich hab noch nie ein Update über Console gemacht. Um den Updateprozess besser zu verstehen hab ich mich gerade in das "./var/install" eingelesen. Ich gehe mal davon aus das sich bei diesen Infos nicht so viel Grundlegendes geändert hat, oder?

Ich müsste auf jeden Fall das install Script etwas anpassen, da das traversierte "post_install" ja schon beim reboot ausgeführt wird. Dort könnte ich aber erst ein "prepare_fwupgrade start" ausführen, um Platz zu machen. Ich würde erstmal versuchen so nah wie möglich beim originalen Updateprozess zu bleiben. Die Signaturprüfung findet ja nur bei Update übers WebIf statt. Also könnte man doch theoretisch das Image der 6.62 so modifizieren, dass der Symlink für telnet gesetzt ist?

Aber eins nach dem anderen. Erstmal das tffs und ein paar Tests...

Schonmal Vielen Dank @PeterPawn für die Denkanstöße und @ncc-1701 fürs Mitdenken!
 
Zuletzt bearbeitet:
vielleicht hilft es ja jemandem...
flashen via console auf die nichaktive partition:
ich habs mit cat der jeweiligen datei auf das inaktive system gemacht.
bei aus 0 gestartet:
Code:
/dev/mmcblk0p1: filesystem_ARM
/dev/mmcblk0p2: kernel_ARM
/dev/mmcblk0p3: filesystem_ATOM
/dev/mmcblk0p4: kernel_ATOM
/dev/mmcblk0p5: filesystem_reserved_ARM
/dev/mmcblk0p6: kernel_reserved_ARM
/dev/mmcblk0p7: filesystem_reserved_ATOM
/dev/mmcblk0p8: kernel_reserved_ATOM
bei aus 1 gestartet:
Code:
/dev/mmcblk0p1: filesystem_reserved_ARM
/dev/mmcblk0p2: kernel_reserved_ARM
/dev/mmcblk0p3: filesystem_reserved_ATOM
/dev/mmcblk0p4: kernel_reserved_ATOM
/dev/mmcblk0p5: filesystem_ARM
/dev/mmcblk0p6: kernel_ARM
/dev/mmcblk0p7: filesystem_ATOM
/dev/mmcblk0p8: kernel_ATOM

die 4 datein passend mit cat auf die reserved mmc devices schreiben... klappt wunderbar, sogar downgrades sind so easy machbar wenn man das passende futter hat. ich hab mir nen dump der 6.24 gut weggepackt. ;)

Also könnte man doch theoretisch das Image der 6.62 so modifizieren, dass der Symlink für telnet gesetzt ist?
daran frickel ich gerade. müsste machbar sein, die passende image datei zu entpacken, der link reinzusetzen, sie wieder zu packen... signaturprüfung fällt aus ...
 
Zuletzt bearbeitet:
Ich müsste auf jeden Fall das install Script etwas anpassen, da das traversierte "post_install" ja schon beim reboot ausgeführt wird.
Das verstehe ich nicht ... das "/var/install"-Skript "ergänzt" ja auch nur die "/var/post_install" und der Zeitpunkt ihrer Ausführung ist immer derselbe.

Wenn man das nachvollzogen hat, was da passiert (die Zuordnung der Partitionen findet man auch in den Support-Daten, solange man die nicht allzu lange nach dem Starten der Box lädt und die Startinformationen in "dmesg" noch sichtbar sind - ansonsten hilft auch die Liste von @noob_noob, wobei man dann wissen muß, was gerade in "linux_fs_start" steht), dann kann man ja genau so eine "/var/post_install" vorbereiten ("Ich habe da schon mal etwas vorbereitet ..."), wie sie nach der Ausführung von "/var/install" aussehen würde.

Wobei es sich bei diesem Vorgehen ohnehin eher anbietet, auf "prepare_fwupgrade" komplett zu verzichten (es dürfte kaum ein Mangel an Ressourcen auftreten) und die neuen Daten für die beiden Kernel und die beiden Dateisysteme nicht aus dem RAM, sondern vom USB-Speicher (oder sogar aus der eMMC-Partition mit ext4-Dateisystem unter "/var/media/ftp") zu kopieren. Auf die Verwendung der "/var/install" von AVM würde ich in diesem Falle komplett verzichten ... am Ende ist es nur das Schreiben von 4 Dateien in die richtigen Devices für die eMMC-Partitionen.
 
Auf die Verwendung der "/var/install" von AVM würde ich in diesem Falle komplett verzichten ... am Ende ist es nur das Schreiben von 4 Dateien in die richtigen Devices für die eMMC-Partitionen.

im Prinzip müßte eigentlich nur aus dem Backup-Skript http://www.ip-phone-forum.de/showthread.php?t=283851&p=2147376&viewfull=1#post2147376 ein "Inverses Backup-Skript" generiert werden, dies kann dann in /var/media/ftp/flash-skript.sh abgelegt werden;

nachfolgende 5 Zeilen am Beginn der "post_install" Datei in die "provideradditive.tar" könnten den Flashvorgang durchführen
Code:
if [ -x /var/media/ftp/flash-skript.sh]
 then 
   /var/media/ftp/flash-skript.sh 
   mv /var/media/ftp/flash-skript.sh /var/media/ftp/[B][COLOR=#0000ff]_[/COLOR][/B]flash-skript.sh
fi
das Umbenennen des Skripts verhindert dann auch "Mehrfach-Flaschen" bzw. unbeabsichtigtes Flashen bei wiederholten Reboots.
 
Denkbar ... aber da gibt es jetzt so viele unterschiedliche Möglichkeiten und sinnvolle Lösungen, daß ich mich da heraushalte.

Was bei dem einen funktioniert, geht beim Nächsten wieder mit Anlauf und Ansage in die Hose ... wer an dieser Stelle weitermachen will und wirklich eine (zumindest ungefähre) Vorstellung hat, was er da eigentlich tut, der braucht auch keine "Anleitung" für das weitere Vorgehen.

Wer auf so eine Anleitung angewiesen wäre, sollte m.E. wieder die Finger davon lassen ... das kann man jetzt meinetwegen wieder interpretieren, wie man will - aber mehr als warnen kann/will ich an dieser Stelle auch nicht.

Auch wenn mir die Sinnlosigkeit so eines Appells im Prinzip klar ist ... ich kann jedem nur empfehlen, sich sehr genau zu überlegen, ob er sich wirklich ein Sicherheitsloch wie einen Telnet-Zugang in seiner FRITZ!Box freiwillig aufreißen will.

Provider-Boxen sollten ohnehin tabu sein für ein eigenständiges Update oder tiefergehende Änderungen durch den Kunden (jedenfalls beim Update auf die Retail-Versionen und auf die Provider-Version hat man normalerweise keinen Zugriff), die Diskussion dazu und zu den Folgen eines solchen Updates gibt es ja hier auch im Thread.

Wer wirklich der Meinung ist, er brauche unbedingt einen Zugang zur Kommandozeile seiner "FRITZ!Box Cable", der kriegt das (a) selbst hin, sich einen solchen einzubauen und macht das (b) dann so, daß die Sicherheit der Box darunter nicht (zusätzlich) leidet. Da gibt es ja durchaus auch mehrere Möglichkeiten - angefangen bei Shell-In-a-Box mit TLS-Zwang bis zur Verwendung eines SSH-Servers.

Ich bleibe jedoch sogar dabei, daß nach eigener, erfolgreicher Modifikation der Firmware (solange das nicht reiner Selbstzweck ist und man ein "abrechenbares Ziel" damit verfolgte) der Zugriff zur Kommandozeile gar nicht mehr erforderlich ist (zumindest kann man ihn dann von Fall zu Fall einschalten und sollte ihn keinesfalls permanent und unbeaufsichtigt laufen lassen). Wer die eigenen Änderungen dann nur so ausführt, daß er sie nach jedem Neustart von Hand anstoßen muß, der braucht natürlich ständig so einen Zugang und schießt sich damit am Ende selbst ins Knie.

Wer sich z.B. den TV-Empfang im Netzwerk auch bei Provider-Branding freischalten will (schon die Antwort auf die Frage, wieso eine eigene Box das Provider-Branding hat, wäre recht interessant - wobei bei "kdg" und 06.31-06.50 bisher wohl nicht anderes blieb), der bräuchte dafür weder Telnet noch eine permanente Änderung der Firmware, es würde bereits die erwähnte "/var/tmp/avmfeature.conf" ausreichen. Die Alternative ist das Ändern der "/etc/init.d/rc.conf" und auch die braucht keinen dauerhaften Telnet-Zugang. Das sind dann auch Änderungen, die der Provider gar nicht mitkriegt und die weder ihn beim PACM (da steckt ja auch ein "Managing" in der Abkürzung und das kann man dem Provider kaum "übelnehmen") noch die Funktion anderer Firmware-Teile beeinträchtigen.

Das Vorgehen über den Zusatz zur "provideradditive.tar" ist sogar am Ende "reine Einstellungssache" und verändert nicht einmal im Ansatz die installierte Firmware, damit dürfte das (ich bin aber auch kein Anwalt und das hier ist auch keine Rechtsberatung) sogar im Kontext der neuen BGB von UM nur schwer zu beanstanden sein:
Punkt 4.2 c) schrieb:
Der Kunde verpflichtet sich, für das Zugangsendgerät ausschließlich von dem Kabelnetzbetreiber bereitgestellte Software/Firmware zu verwenden.

Es gibt schon in der AVM-Firmware genug Punkte, an denen ein Angreifer ansetzen könnte ... da muß man nicht noch mit einem offenen (und genutzten) Telnet-Zugang einen weiteren schaffen (ich hatte hier auch mal irgendwo vorgerechnet, wieviele (unregistrierte) Login-Versuche ein Angreifer auf den Telnet-Daemon am Tage so schaffen kann) und wer sich heute noch hinstellt und behauptet, bei ihm könne so ein Angriff aus dem LAN prinzipiell nicht vorkommen, weil er alle Geräte in seinem Netz unter seiner Kontrolle hat, der lebt nun mal (wenn er halbwegs aktuelle Technik und Systeme verwendet) in einer Traumwelt.

Selbst die Canonical-Systeme (für viele ja das, was "Linux" ausmacht) "telefonieren nach Hause" und ein erfolgreicher Angriff auf einen Server der Paketverwaltung kann bereits ausreichen, um über ein wichtiges (automatisches) Update ein Loch in ein lokales System zu reißen. Das gilt auch für andere Distributionen und nicht einmal das eigene Übersetzen jedes Paketes - a la LFS - kann sicherstellen, daß nicht eine Änderung im Quelltext oder sogar eine bereits vorhandene Schwachstelle eine Lücke eröffnen. Nur die ausschließliche Verwendung selbstgeschriebener (oder zumindest selbst geprüfter) Software würde so eine Annahme erlauben und auch das wieder nur dann, wenn man sich selbst für so gut hält, daß einem keine Fehler unterlaufen. Wie realistisch das ist, braucht man wohl nicht weiter auszuführen ...

Wer auf der anderen Seite auf automatische Updates verzichtet und alles "von Hand" machen will, der hat entweder nur sehr wenige Systeme, um die er sich kümmern muß oder er kann es gar nicht schaffen, jedes System zeitnah zu aktualisieren.

Eine Lücke findet man also (mit sehr, sehr hoher Wahrscheinlichkeit) immer und dann kann ein Telnet-Zugang zu einer FRITZ!Box (möglichst noch ohne die Notwendigkeit der Anmeldung, weil es ja so schön bequem ist und man nicht immer das Kennwort tippen will) praktisch als Einladung interpretiert werden - das gilt auch nicht nur für die DOCSIS-Geräte von AVM.
 
Also könnte man doch theoretisch das Image der 6.62 so modifizieren, dass der Symlink für telnet gesetzt ist?
daran frickel ich gerade. müsste machbar sein, die passende image datei zu entpacken, der link reinzusetzen, sie wieder zu packen... signaturprüfung fällt aus ...
Warum das Rad neu erfinden? Ich sehe gerade, dass fesc da netterweise etwas vorbereitet hat - sogar ssh statt telnet: https://bitbucket.org/fesc2000/ffritz/overview
 
So, wie versprochen noch mal die Mitteilung:
Also ich wurde am Montag angerufen für einen Termin, Dienstag kam der Techniker, Box ausgetauscht und lief sofort wieder.
Alles wie im Vorfeld besprochen, interessantes Gespräch geführt und auch noch ein paar nette Infos erfahren.

Ich habe mal aus Spaß den letzten Post von PeterPawn kurz überflogen.
wer an dieser Stelle weitermachen will und wirklich eine (zumindest ungefähre) Vorstellung hat, was er da eigentlich tut, der braucht auch keine "Anleitung" für das weitere Vorgehen.
Ja, spricht schon für sich, - Kluge Menschen werden wissen was ich genau meine.
Unbegreiflich solche Menschen wie PeterPawn, aber ist nicht meine Baustelle.
Ich werde mich nun auch wie angekündigt hier aus dem Forum raus ziehen.

Das nötigste schrieb ich ja bereits, und ansonsten allen viel Erfolg.
Und lasst euch bitte nicht von solchen Kaspern verunsichern.

Gruß
 
Warum das Rad neu erfinden? Ich sehe gerade, dass fesc da netterweise etwas vorbereitet hat - sogar ssh statt telnet: https://bitbucket.org/fesc2000/ffritz/overview

möp, mööp, mööööp. :) dropbear. mir laufen mal wieder die tränen ... ist das, was ich mir gewünscht hab... DANKE!!!
nächste baustelle für mich: eigenen ssh key ablegen und pw auth disable...

- - - Aktualisiert - - -

o.t.
Ich werde mich nun auch wie angekündigt hier aus dem Forum raus ziehen.

Das nötigste schrieb ich ja bereits, und ansonsten allen viel Erfolg.
Und lasst euch bitte nicht von solchen Kaspern verunsichern.

Gruß

selber schuld, wenn du dich gerade jetzt und hier herauskasperst...
ey, mimosen kann hier wirklich keiner gebrauchen. sorry. wenn dir hier wer die "haare wäscht" weil du was nicht richtig gelesen hast, dann ist das nu mal so. ganz ehrlich? der ton in der linux-gemeinde ist manchmal zeimlich direkt. meist dann, wenn man nicht lesen, verstehen und auch umsetzen kann... rtf... oder man pages. oder auch den thread in dem sich leute herumtreiben, die was bewegen wollen/können. schiebe<->anzeige-gerät benutzer ohne eigenen willen gibt es wie sand am meer...
auch ich lieg nicht immer richtig. ich hab noch bischen kapazität an ungenutzten grauen zellen, probier auch gern mal was aus.
genau so stösst meine art und weise zu schreiben/posten bei manchem auf. menschen sind halt unterschiedlich, wenn es um ne gemeinsame sache geht, können sie aber plötzlich alle in 1 richtung ziehen. ( wenn der hunger gross genug ist )
aber: ich lass mich nicht von misserfolgen abschrecken oder klemm beleidigt den schwanz ein und verkrümel mich.
/ o.t.

@fesc: in die install.txt vlt noch der hinweis auf upgrade managed: yes/no und auf das script zum ändern auf uifile und uploadfile & angabe der zu flashenden datei. find ich (persönlich) sehr brauchbar. aber: ich hab halt kein fenster-os ... ich bin mit git nicht so freund, sonst würd ich dir nen pull request schicken

dann squashfs... irgendwo hab ich mal was von nem (un)squashfsx86 von peter beim überfliegen gelesen. finds nur nicht mehr... :( weisst du mehr dazu? oder vlt drückt der gute peter ja seinen senf dazu aus der tube... und: ja: ich mag senf. ;) *njam*
 
Zuletzt bearbeitet:
dann squashfs... irgendwo hab ich mal was von nem (un)squashfsx86 von peter beim überfliegen gelesen. finds nur nicht mehr... :( weisst du mehr dazu?

Fuer x86 nehme ich die "normalen" squashfs-tools vom host OS, da das FS im Gegensatz zum arm little endian ist. Allerdings habe ich bisher das x86 FS nicht modifiziert da es nicht noetig war. Fuer meine Zwecke geht alles via rpc vom arm core.

- - - Aktualisiert - - -

nächste baustelle für mich: eigenen ssh key ablegen und pw auth disable...

Das passiert bereits. Die dropbear hostkeys, /etc/shadow (fuer passwoerter) und das .ssh/ directory (fuer authentifizierung/login via authorized_keys) vom root user landen in /nvram.
Man muss sich halt nach der ersten installation noch einmal via telnet einloggen und ein root-passwort vergeben (bzw. .ssh/authorized_keys befuellen). Das bleibt dann persistent (wenn man paranoid ist sollte man das passwort noch mal aendern wenn man sich per ssh eingeloggt hat).
telnetd wird nach 5 minuten gekillt.
 
Zuletzt bearbeitet:
Das "unsquashfs4" für das BE-Format gibt es als x86- und als MIPS-Binary in meinem Repository, inkl. Signatur zur Kontrolle.

Informationen dazu stehen vermutlich im "modfs"-Thread.

Eine ARMv6-Variante gibt es dort allerdings nicht ... das Entpacken wird ja nur selten auf der Box selbst erfolgen und dann sollte man das ohnehin auf dem x86-Core ausführen, wobei die Version aus dem Repo auf der Box auch auf dem x86-Core nicht läuft (dafür war sie auch nicht gedacht, sondern für ein "richtiges" Linux-System mit glibc, usw., wenn jemand nur für dieses Tool keine komplette Build-Toolchain oder die Freetz-Toolchain installieren will).
 
Das passiert bereits. Die dropbear hostkeys, /etc/shadow (fuer passwoerter) und das .ssh/ directory (fuer authentifizierung/login via authorized_keys) vom root user landen in /nvram.
Man muss sich halt nach der ersten installation noch einmal via telnet einloggen und ein root-passwort vergeben (bzw. .ssh/authorized_keys befuellen). Das bleibt dann persistent (wenn man paranoid ist sollte man das passwort noch mal aendern wenn man sich per ssh eingeloggt hat).

schon klar. stand nur auf meiner todo.
da die gurke bei mir aber nur dvb-c reciever macht und ich gern bischen mehr spaß am gerät hab, interessiert die kiste mich halt... und dazu muss ich telnet oder ssh lokal haben da derzeit keine seielle ( mir bekannter weise ) daten ausspukt. zum thema gibt es nen thread, ich hab paar ideen dazu. ich meld mich im thread zur seriellen auf der 6490 in den nächsten tagen mit gedanken/info's dazu.
 
In den letzten Labor-Versionen von AVM für die 7490 ist auch etwas in Richtung von Änderungen für DOCSIS-Modelle zu erkennen. Es gibt wohl eine "new architecture", bei der dann die Umgebungsvariable für die Aktivierung von "DOCSIS" nicht mehr "CONFIG_DOCSIS=y" ist, sondern "CONFIG_DOCSIS_MODEM=y".

Irgendwie macht das auf mich den Eindruck, als wolle AVM tatsächlich eine Trennung von DOCSIS-eCM und dem Rest der Firmware vornehmen ... z.B. kommt wohl in den nächsten Versionen irgendein ein neuer Daemon "pumaglued" hinzu, der bei Erstellen der Support-Daten dann z.B. so nach Informationen "befragt" wird:
Code:
if [ "$CONFIG_DOCSIS" = y -o "$CONFIG_DOCSIS_MODEM" = y ] ; then
   echo "##### BEGIN SECTION DOCSIS Supportdata cable"
   echo "##### BEGIN SECTION DOCSIS Erouter"
   ls -la /var/tmp/edocsis.state*
   for fn in /var/tmp/edocsis.state* ; do
          echo -n "$fn: " ; cat $fn
   done
   echo "##### END SECTION DOCSIS Erouter"
[COLOR="#008000"]   aicmd pumaglued support get cable[/COLOR]
   echo "##### END SECTION DOCSIS"
fi
Angesichts der "Erkennung" für diese "new architecture" (in puma6_helper.sh) handelt es sich dabei eher um eine neue Architektur der Software als um geänderte Hardware ... man darf also gespannt sein, was sich da für die 6490 tun wird in der nächsten (oder einer folgenden) Version; an die komplette Trennung glaube ich erst, wenn ich sie sehe. Bisher kann es auch nur der Ansatz sein, um die "Abstraktion" des "dsld" (der hier ja eher "docsisd" heißen müßte) noch weiter voranzutreiben und die WAN-Funktionen auf unterschiedlichen Medien noch weiter vom Rest zu entkoppeln (wer weiß, was da "glue" benötigt).
 
hat jemand nochmal versucht eine 6.31 (kdg) zu entbranden?
Ich bin leider da noch nicht weiter gekommen :(
(Und ich würde doch so gerne die bei UM anmelden)
 
Durch die neue bekannte Lücke beim Provider Additive könnte sich eine neue Möglichkeit ergeben, Telnet zu aktivieren und zu updaten.
 
hat jemand nochmal versucht eine 6.31 (kdg) zu entbranden?

das verstehe ich nicht; wie soll das gehen ?
Code:
/usr/www/kdg
/etc/default.Fritz_Box_HW213a/kdg

da fehlen doch die avm Sub-Directories
Code:
/usr/www/[COLOR=#ff0000]avm[/COLOR]
/etc/default.Fritz_Box_HW213a/[COLOR=#ff0000]avm[/COLOR]

Warum konzentrierst Du Dich nicht auf einen Direct-Update von 06.30 auf 06.61 oder 06.62 mit der "provideradditive.tar overwrites /var/post_install" Methode ?

Hast Du die Postings ab #917 nicht gelesen ?

- - - Aktualisiert - - -

Provider Additive könnte sich eine neue Möglichkeit ergeben, Telnet zu aktivieren und zu updaten.

Wozu wird Telnet benötigt ?
das sollte alles im Batch-mode mittels "/var/post_install" funktionieren.
 
Zuletzt bearbeitet:
Ich habe mal etwas in mein GitHub-Repository eingecheckt, was ich bisher in leicht abgewandelter Form auf entfernten FRITZ!Boxen eingesetzt habe, um dort beim Neustart der Box auf dem internen NAS-Speicher (unter /var/media/ftp, ich habe nur noch Boxen "in Pflege", die dort einen Speicher haben - 7390, 7490, 6490) abgelegte neue Firmware zu installieren. Bisher habe ich das dazu genutzt, die von mir modifizierte Firmware einfach über den NAS-Zugriff dort abzulegen und bei der nächsten Gelegenheit (i.d.R. nachts, wenn in den betreffenden Filialen garantiert niemand das Telefon braucht) installieren zu lassen.

Das ist zwar alles weitgehend getestet, aber es ist in dieser Form auch aus vorhandenen Bausteinen neu zusammengesetzt und muß erst einmal ausgiebig unter verschiedenen Bedingungen seine Eignung unter Beweis stellen. Das "Abschalten" ist normalerweise sehr einfach ... auch im Fehlerfalle. Da vor jedem Aufruf einer Datei im Verzeichnis "/var/media/ftp" erst deren Existenz geprüft wird, führt bereits das Löschen einer falschen Datei per NAS-Zugriff (FTP, Samba, GUI) dazu, daß der Ablauf nicht geändert wird - es reicht also bereits, eine Datei zu löschen, um das Ganze wieder zu deaktivieren, wenn man die entfernte Firmware erfolgreich aktualisiert hat.

Der bisher realisierte Ablauf ist folgender ... beim Neustart der FRITZ!Box (noch einmal, ich rede eigentlich von anderen Modellen als der 6490, aber nach meinen Tests und ein paar ausgeführten Änderungen funktioniert es auch für diese) wird ja bekanntlich die "/var/post_install" abgearbeitet. Schaut man dort kurz hinein (hier in die 141.06.62), sieht der Beginn dort so aus:
Code:
## ! /bin/sh
## Skip Startup (on very early reboot-cmd)
if ps | grep -v grep | grep -q 'rc.S'; then
echo "rc.S is running - set 'skip init'"
touch /var/skip_init
[COLOR="#FF0000"]else
test -f /var/media/ftp/update_firmware && . /var/media/ftp/update_firmware
[/COLOR]fi
## AHA
if ps | grep -v grep | grep -q /usr/bin/aha ; then
Die roten Zeilen sind schon eine Ergänzung meinerseits, sie fügen die Kommandos aus der Datei "/var/media/ftp/update_firmware" ein, wenn diese Datei existieren sollte. In diesem Falle (bei der 6490) auch nur, wenn das kein "early reboot" ist, wie er z.B. bei Änderungen an der "featovl.cfg" über "docsis_feature_disable" auftritt, deshalb der "else"-Zweig bei der 6490 - bei anderen Modellen gibt es diese Abfrage gar nicht, dann läßt man das "else" einfach weg.

Die eingefügte Datei kann dann z.B. so aussehen:
Code:
## Check semaphore to avoid 2nd call
if ! [ -f /var/run/post_install_2nd_run ]; then
if [ -f /var/media/ftp/run_update ]; then
touch /var/run/post_install_2nd_run
exec $SHELL /var/media/ftp/run_update
fi
fi
Hier wird beim ersten Aufruf (solange die Datei "/var/run/post_install_2nd_run" nicht existiert) die Abarbeitung der "/var/post_install" erst einmal beendet, wenn ein weiteres Skript "/var/media/ftp/run_update" existiert und stattdessen dieses Skript ausgeführt (über "exec", was in diesem Falle entscheidend ist).

Dieses Skript kann jetzt machen, was es für notwendig erachtet ... es muß nur bei jedem "Ausgang" dafür sorgen, daß es seinerseits wieder die "/var/post_install" erneut aufruft, woraufhin dann der Rest der Kommandos in dieser Datei abgearbeitet wird, weil die Datei als Semaphore beim zweiten Aufruf existiert. Das kann also durchaus auch die durch das "/var/install"-Skript aus einem AVM-Firmware-Image geänderte "/var/post_install" sein. Macht man das richtig, funktioniert das auch auf den DSL-Boxen, sogar auf den NOR-Modellen, mit denen "modfs" nichts am Hut hat (hier natürlich mit einem gewissen Risiko, deshalb teste ich solche "remote updates" bei mir auch immer vorher auf einer passenden Box).

Die eigentliche Arbeit übernimmt dann das Skript "run_update", das ich für die Veröffentlichung noch etwas umgeschrieben habe.

Als erstes testet es, ob eine neue Firmware bereits auf dem NAS-Speicher vorhanden ist (als "newfirmware.image"). Findet es keine, versucht es im nächsten Schritt den AVM-Service zu befragen, ob es eine neuere Version gibt oder nicht. Wer diese Prüfung nicht haben will, entfernt einfach das "check_update"-Skript (oder stellt es gar nicht erst bereit) - wobei das Vorhandensein der "include"-Datei (update_firmware) bei Fehlen der Datei "newfirmware.image" eine etwas paradoxe Situation ergeben würde ... warum ist dann die "update_firmware" überhaupt existent?

Wer eigene Firmware installieren will (bei mir der Haupteinsatzzweck), der kann bzw. muß natürlich neben den Skript-Dateien auch noch die passende Datei "newfirmware.image" bereitstellen, das kann auch ein mit Freetz erstelltes Image sein.

Sollte eine neuere Version bei AVM existieren für die Box, wird diese heruntergeladen und so behandelt (sie bleibt auch gespeichert, solange man am Pfad "/var/media/ftp" nicht dreht - bei Boxen ohne (ausreichenden) internen NAS-Speicher muß man ohnehin das Basisverzeichnis (und ein paar weitere Zeilen) anpassen), als wäre sie von Beginn an vorhanden gewesen.

Jetzt wird die Firmware-Datei (nur überwindlich) geprüft ... sie muß eine Größe > 0 haben und die Dateien "var/tmp/filesystem.image", "var/tmp/kernel.image" und "var/install" enthalten. Hat sie diesen Test bestanden und existiert die Datei "check_signed_image" (hier beschrieben), dann wird versucht, die Signatur der Datei zu überprüfen.

Das setzt allerdings die Existenz einer passenden OpenSSL-Version als Binary auf der betreffenden Box voraus ... bei mir ist das "openssl" immer irgendwie erreichbar, daher werden in "check_signed_image" auch keine speziellen Vorkehrungen für den Aufruf mit absolutem Pfad getroffen. Für die MIPS-Boxen (NAND/VR9) gäbe es im "modfs"-Repository ein passendes Binary, für die 6490 muß man sich eben eines basteln, wenn man die Signaturprüfung überhaupt will. Ich habe die bei mir eingebaut, weil ich die Firmware für "remote install" eben auch passend signiere und damit erstens weiß, daß der Inhalt richtig übertragen wurde und zweitens sicher sein kann, daß keine manipulierte Firmware installiert wird.

Aber damit die Signaturprüfung nicht zum Stolperstein wird, ignoriere ich in der Version im Repository jeden Fehler, der nicht explizit sagt "falsche Signatur" - damit reicht auch das Fehlen des "openssl"-Binaries, damit die Signaturprüfung quasi übergangen wird.

Im Anschluß gibt es noch die Möglichkeit, die entpackten Firmware-Dateien durch den Aufruf eines passenden Kommandos/Skripts zu modifizieren - z.B. mit der (bisher unveröffentlichten) Batch-Version von "modfs". Aber hier kann sich auch jeder selbst seine Kommandos zurechtbasteln ... die Zutaten in Form von "unsquashfs" und "mksquashfs" für die Box, auf der das laufen soll, muß man sich eben vorher besorgen - für die 6490 stelle ich da (zumindest bisher) nichts weiter bereit, für MIPS-Boxen ist wieder alles Notwendige im "modfs"-Repo zu finden.

Ist bis hierhin alles fehlerfrei gelaufen, wird nun das Skript "/var/install" aufgerufen - das ist dann dafür verantwortlich, die Firmware zu installieren. Dabei kann es sich um das originale Skript von AVM handeln oder um ein beliebiges selbstgeschriebenes ... es muß sich nur wie das von AVM verhalten.

Die Arbeitsweise von "run_update" läßt sich noch an einigen Stellen modifizieren ... dazu gibt es in der Datei die folgenden Zeilen/Variablen, deren Bedeutung kurz erläutert wird:
Code:
exec_to=/var/post_install
[...]
log_ip="192.168.178.2"
log_port=514
[...]
basedir=/var/media/ftp
[...]
imagename=newfirmware.image
[...]
force_update=0
[...]
force_branding=1
[...]
modify_firmware=0
modify_command="$SHELL $basedir/modfs/modfs_batch unpacked /"
"exec_to" gibt den Namen des Skripts an, welches im Anschluß (ebenfalls mit "exec") aufgerufen werden soll.

"basedir" ist der Pfad, in dem nach den ganzen Bestandteilen dieses "autoupdate"-Mechanismus für Arme gesucht wird ... bei einer Box ohne internen NAS-Speicher muß das natürlich auf ein Verzeichnis auf einem USB-Stick geändert werden und gleichzeitig muß sichergestellt sein, daß der USB-Stack noch verfügbar ist, wenn "/var/post_install" aufgerufen wird (nach "prepare_fwupgrade" nur teilweise der Fall).

"imagename" enthält den Namen der Image-Datei, falls den jemand ändern möchte.

"force_update" kann man auf "1" setzen, wenn man dafür sorgen will, daß auch ältere Firmware installiert wird, die bei AVM durch die Versionsprüfung fällt (also ein Downgrade auszuführen ist). Dabei werden dann aber vom AVM-Code vorhandene Einstellungen gelöscht ... nur falls sich niemand mehr an diesen Mechanismus erinnern kann, seitdem AVM ihn abgeschafft hat.

"force_branding" sorgt dafür, daß ich auf einer internationalen 7390 auch die deutsche Version der Firmware installieren kann und umgekehrt. Dazu überprüft das Skript in der "/var/install" von AVM (das Entpacken von SquashFS-Images ist dafür zu mühsam und wenig platzsparend), welche Brandings enthalten sind ... das ist etwas fragiler Code, weil so ein Shell-Statement natürlich leicht zu ändern ist - andererseits editiert Freetz daran auch herum, wenn man dort ein Branding entfernen läßt. Ist das aktuelle Branding in der neuen Firmware nicht enthalten, wird die Variable "OEM" mit dem ersten Wert aus der Liste der Brandings exportiert, damit sich "/var/install" nicht am falschen Branding stört. Kommt es dann wirklich zur Installation, wird am Ende von "run_update" auch noch das Branding im Bootloader-Environment entsprechend gesetzt - damit ist der (automatisierte) Wechsel zwischen "avm" und "avme" möglich, aber es sollte theoretisch auch von "kdg" auf "avm" klappen. Den erhobenen Zeigefinger, daß man das nur auf der eigenen Box machen sollte, kann und will ich niemandem ersparen. Bei mir gibt es jedenfalls einen Kunden, der hat Anschlüsse in D und in A mit der 7390 und irgendwann hatte ich die Nase voll, die vorhandene Reserve-Box immer erst vom aktuellen Branding auf das benötigte umzuschalten - die wird nämlich auch für (kritische) Updates eingesetzt, wenn noch eine garantiert funktionsfähige Alternative benötigt wird.

"modify_firmware" und "modify_command" sind die beschriebenen Einstellungen für die Änderung der Firmware vor der Installation - kann man benutzen, muß man aber nicht; es hängt halt davon ab, ob man eine bereits modifizierte oder eine originale Firmware als Ausgangsmaterial hat.

Interessant ist vielleicht noch die Einstellung "log_ip" ... da ich keine Lust habe/hatte, so ein Update immer live zu überwachen, habe ich eine Möglichkeit der Protokollierung eingebaut, die auch über Netzwerk-Verbindungen arbeiten kann - sogar über das Internet, solange die WAN-Verbindung verfügbar ist. Dazu wird eine TCP-Verbindung zum angegebenen Host aufgebaut und sowohl die Standardausgabe als auch die Standardfehlerausgabe (STDOUT/STDERR) auf diese Verbindung umgeleitet ... parallel dazu wird der Debug-Modus der Shell aktiviert (set -x). Steht "nc" nicht zur Verfügung (bei originaler AVM-Firmware auf DSL-Boxen ist das der Fall), wird einfach nach "/dev/console" protokolliert, auch wenn das wohl nie jemand sehen wird (außer er hat eine serielle Schnittstelle oder eine Shell-Session mit "getcons" am Laufen). Weil auch AVM nach "/dev/console" protokolliert, wird das ggf. noch in der "/var/install" geändert (auf FD 6), bevor dieses Skript aufgerufen wird.

Wer die Protokollierung über das Netzwerk aktivieren will, muß also bei "log_ip" die IP-Adresse (oder den Namen) eines passenden Hosts eintragen und auf diesem dann einen entsprechenden "Empfänger" einrichten ... im einfachsten Falle ist das ein "nc -l <eigene IP-Adresse> 514" auf einem passenden Gerät (es gibt auch ein "netcat" für Windows, falls jemand keinen TCPClient mit PowerShell verwenden kann oder will). Gerade bei der Fehlersuche kann das gute Dienste leisten, wenn man ansonsten keinen Shell-Zugang hat (kann man auch als Beispiel nehmen, warum es einen solchen gar nicht immer braucht).

- - - Aktualisiert - - -

Falls es jemand noch als Zusammenfassung für das Update von kdg-06.31 (oder größer) auf avm-06.62 braucht: Einfach die vier Dateien (drei reichen auch, solange man kein "openssl"-Binary für dem Puma6 (ARM) hat - dann kann man "check_signed_image" auch weglassen) per NAS-Zugriff auf die Box bringen und dann in der "/var/post_install" die eine bzw. zwei Zeilen ergänzen.

Dann sollte beim nächsten Neustart (mit aktiver WAN-Verbindung) auch das Update anlaufen ... funktioniert das irgendwie nicht, kann man ja wieder per Bootloader auf die vorherige Version und das vorherige Branding zurückstellen.

Als Vorlage kann man auch die "/var/post_install" aus der 06.62 nehmen, so sehr unterscheiden die sich nicht - von der 06.24-30805 zur 06.50 ist dann nur das WLAN auf den x86-Core umgezogen (keine Ahnung, wo das bei der 06.31 läuft) und zwischen der 06.50 und der 06.62 (falls jemand kdg-06.50 auf avm-06.62 ändern will) gibt es gar keinen Unterschied.
 
Zuletzt bearbeitet:

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,264
Beiträge
2,249,075
Mitglieder
373,851
Neuestes Mitglied
Yete
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.