Kleines Skript ausführen ohne Custom Fireware

Jack Sabbath

Neuer User
Mitglied seit
10 Okt 2020
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Hallo allerseits,

ich würde gerne ein kleines Programm auf meiner Fritzbox 7490 laufen lassen und würde dafür nur ungern gleich ein neues Betriebssystem drauf flashen (weil ich gerne weiterhin automatischen Updates erhalten möchte).

Das Skript soll möglichst auf dem internen NAS Speicher abgelegt sein und ich würde es gerne per remote (Telnet, SSH, sonstiges.. völlig egal, Hauptsache es läuft von der Kommandozeile) aus dem lokalen Netzwerk starten. Dass das Skript bei einem Neustart sicher beendet wird ist kein Problem.

Das Skript hat zwei Funktionen:
a) Man hinterlegt eine Nachricht (message of the day), welche im RAM (Und nur dort! Die Nachricht könnte vertrauliche Informationen enthalten.) der Fritzbox gespeichert wird.
b) Jeder andere Rechner im Netzwerk soll sich zur Fritzbox verbinden können um diese Nachricht abzurufen. Das setzt natürlich voraus, dass die Fritzbox einen Port für eben diese Anfragen öffnet.

Habt ihr lieben Leute einen Vorschlag oder vielleicht Links mit Anleitungen, wie man das angehen kann? Ideen, wie man solche Informationen bei der Fritzbox mit den hauseigenen Funktionen simulieren kann sind ebenfalls willkommen. Man könnte ja per Http-Skript etwas in die Weboberfläche posten und aus dieser Abfragen.. mir fällt aber leider keine unwichtige Konfiguration ein, die wirklich nur im RAM gespeichert wird.

Danke schonmal!
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
8,480
Punkte für Reaktionen
456
Punkte
83
Da kommst du zu spät. Vor ca. 5 Jahren wäre das noch gegangen.
Jetzt ist die FB so dicht (und damit sicher gegenüber Angriffen) gemacht, daß dies nicht mehr geht.
 

chked

IPPF-Promi
Mitglied seit
20 Nov 2006
Beiträge
4,256
Punkte für Reaktionen
17
Punkte
38
Die einzige Möglichkeit, die ich sehe:
Eine HTML-Datei, z.B. index.html auf dem NAS-Speicher ablegen und dann über http://fritz.box:49200/FRITZ/index.html darauf zugreifen.
Die "vertraulichen Informationen" sind dann allerdings im Flash-Speicher der Box gespeichert.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,286
Punkte für Reaktionen
1,095
Punkte
113
Glücklicherweise stimmt #2 - mit aktueller Firmware sollte es keine einfache Möglichkeit mehr geben, etwas in das laufende FRITZ!OS einzubauen, was dann dort zur Ausführung fremder Kommandos führt.

Stellt sich also eher die Frage, ab wann eine Firmware dann "customized" ist bzw. was man noch an Vorkehrungen treffen könnte, damit solche Änderungen auch ein automatisches Update mit einer originalen AVM-Firmware überleben.

Außer man wählt tatsächlich den Weg über den Media-Server aus #3, der aber - nach wie vor - generell eine sehr schlechte Lösung für Daten ist, die nicht jeder x-beliebige (W)LAN-Client auslesen können soll ... denn an den hier: [Info] Dein Freund, der AVM-Mediaserver ... und wie er Dir in den Rücken fallen könnte beschriebenen Umständen hat sich auch mit der 07.21 wohl absolut nichts geändert. So sind sowohl die Teildatenbanken immer noch auszulesen, wenn man deren Pfad kennt und darin sind auch (das nun wieder "erwartbar", weil die Datenbanken ja auch für den NAS-Zugriff über das GUI verwendet werden) immer noch alle Dateien verzeichnet. Ebenso braucht der Abruf über den HTTP-Server auf Port 49200 immer noch keine Authentifizierung.

Das ist also generell eine eher furchtbare Idee, den Media-Server überhaupt zu aktivieren (was vermutlich ohnehin nicht erforderlich wäre, weil der immer noch per Default-Settings eingeschaltet sein dürfte), wenn die Daten auf den angeschlossenen Volumes (zumindest auf denen, für die der Media-Server "zuständig" ist und das sind als Standard immer noch alle) in irgendeiner Weise vertraulich sein könnten. Die kann jede App auf einem Smartphone, Tablet, TV, etc. jederzeit lesen, wenn sie nur auf das Heimnetzwerk kommt.

Aber hier ist ja von einer 7490 die Rede ... und die hat einen Aufbau der Hardware, bei dem durch den einmaligen Start mit einem eigenen Image wieder eigene Programme ins YAFFS2-Image "eingepflanzt" werden können. Mit nur wenig mehr Anstrengung kann man dann auch dafür sorgen, daß diese Prozedur auch ohne den Start mit dem eigenen Image genau dann erneut vollzogen wird, wenn eine neue AVM-Firmware aus dem laufenden System installiert wurde und jetzt ein Neustart ansteht.

Man muß sich also entscheiden:

- Media-Server, wo die Daten dann persistent gespeichert werden und alle andere Daten auf dem genutzten Volume ebenfalls offenliegen
- Verzicht, denn es gibt ja auch noch genug andere Lösungen, z.B. mit einem Einplatinen-Rechner oder gar einem MCU, je nachdem, wie die abzurufenden Daten aussehen
- etwas Bastelei rund um das FRITZ!OS, allerdings ohne das SquashFS-Image zu ändern (geht aber nur bei VR9-Boxen auf diesem Weg)

Einen lokalen HTTP-Server hat das FRITZ!OS zwar, aber dem kann man keine weiteren Dateien zur Auslieferung "übergeben" - das wäre auch wieder eine Sicherheitslücke, weil diese Dateien natürlich unter dieselbe Security-Policy fallen würden, wie die anderen Zugriffe auf das FRITZ!OS-GUI und damit XSS gar nicht mehr "cross" wäre.
 
  • Like
Reaktionen: Jack Sabbath

Jack Sabbath

Neuer User
Mitglied seit
10 Okt 2020
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Danke an alle für die Antworten!

Aber hier ist ja von einer 7490 die Rede ... und die hat einen Aufbau der Hardware, bei dem durch den einmaligen Start mit einem eigenen Image wieder eigene Programme ins YAFFS2-Image "eingepflanzt" werden können. Mit nur wenig mehr Anstrengung kann man dann auch dafür sorgen, daß diese Prozedur auch ohne den Start mit dem eigenen Image genau dann erneut vollzogen wird, wenn eine neue AVM-Firmware aus dem laufenden System installiert wurde und jetzt ein Neustart ansteht.
Das klingt doch gut. Hast du dazu zufällig noch einen Link zu einer Anleitung? VR9 Plattform ist bei der 7490 ja gegeben.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,286
Punkte für Reaktionen
1,095
Punkte
113
Was für eine "Anleitung"? Es gibt keine "Schritt für Schritt"-Liste dazu - das Prinzip habe ich hier: FRITZ!Box-Kennwort vergessen ... was nun? (Mail-)Recovery a la AVM oder besser nicht? beschrieben und in Form der "Injektion" von Shell-in-a-Box auch umgesetzt und veröffentlicht (die Suche im Board sollte helfen).

Dann muß man sich noch schlau machen, wie der Update-Prozess bei einer 7490 arbeitet und sich mit geeigneten Mitteln an einer passenden Stelle auf die Lauer legen, damit man das bei einem Update auch in die YAFFS2-Partition des neuen Systems einbauen kann (natürlich alles "per Skript" und nicht von Hand) - das ist auch keine "rocket science", denn der Ablauf eines Updates ist auch desöfteren hier beschrieben worden.

Irgendwelche Links dafür habe ich grundsätzlich nur dann, wenn das Threads sind, die auch von mir selbst begonnen wurden (und auch da lange nicht von allen diesen Threads) - alles andere müßte ich auch erst suchen und das dann wiederum noch einmal aufschreiben. Das erscheint mir jetzt nicht sehr effektiv (aus meiner Warte jedenfalls - die Zeitersparnis für den "Absender" so einer Frage sehe ich natürlich schon).

Ich bin mir auch bei Deiner Feststellung:
VR9 Plattform ist bei der 7490 ja gegeben.
nicht so ganz sicher, wie gründlich Du Dir #4 durchgelesen hast, dann da stand ja meinerseits schon:
Aber hier ist ja von einer 7490 die Rede ... und die hat einen Aufbau der Hardware, bei dem durch den einmaligen Start mit einem eigenen Image wieder eigene Programme ins YAFFS2-Image "eingepflanzt" werden können.
- ansonsten wäre es ja auch Unsinn von mir gewesen, diese "Besonderheit" der VR9-Plattform (bzw. der VR9-Modelle von AVM mit NAND-Flash) hier überhaupt ins Spiel zu bringen.

EDIT: Ich sehe gerade erst (weil ich mir die Zitate meiner eigenen Beiträge i.d.R. nicht durchlese, da ich ja weiß, was ich selbst geschrieben habe), daß Du sogar denselben Satz von mir VOR Deiner Feststellung, daß die 7490 eine VR9-Box wäre, zitiert hast ... das verwirrt mich jetzt vollkommen.
 
  • Like
Reaktionen: Jack Sabbath

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
12,693
Punkte für Reaktionen
350
Punkte
83
Ich neige dazu eine 7270 zu empfehlen.
Die wird von AVM bestimmt nicht weiter zugenagelt und hat einen persistenten Speicher von 1MB: /data
jason_boxinfo.xml
Code:
<j:BoxInfo xmlns:j="http://jason.avm.de/updatecheck/">
<j:Name>FRITZ!Box Fon WLAN 7270 v2</j:Name>
<j:HW>139</j:HW>
<j:Version>54.06.06</j:Version>
<j:Revision>31461</j:Revision>
<j:Serial>FFFFFFFFFFFF</j:Serial>
<j:OEM>avm</j:OEM>
<j:Lang>de</j:Lang>
<j:Annex>B</j:Annex>
<j:Lab/>
<j:Country>049</j:Country>
</j:BoxInfo>
( :cool: YEP - Aktuellste Firmware ist drauf )
Hat: VoIP Server, NAS ( HTTPS/HTTP/FTP/Samba ) und den Mediaserver mit Webserver ( Port: 49200 )
Außerdem kann die v2 wahlweise das 2,4-, oder 5 GHz WLAN repeaten, also kabellos ( bis auf Strom ) unterwegs sein. Die ist aber logischerweise nicht meshfähig, was ich persönlich auch nicht als Nachteil betrachte.
Connect mit telnet ( ConnectBot oder PuTTY ) und mal umgucken was da noch von mir zu finden ist...
Code:
BusyBox v1.19.3 (2012-05-21 13:40:41 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
# cd /data
# ls -la
drwx------    6 root     root             0 Aug  8 15:18 .
drwxr-x---   14 root     root           179 Sep 30  2015 ..
-rw-------    1 root     root           236 Jul  1 18:45 .profile
drwx------    2 root     root             0 Aug  8 11:17 .ssh
-rwx------    1 root     root        370576 Jun 29 15:57 dropbear
lrwxrwxrwx    1 root     root             8 Jun 29 16:18 dropbearkey -> dropbear
drwxr-xr-x    2 root     root             0 Aug  2 13:22 html
-rw-------    1 root     root           799 Aug  2 12:25 koyinc
-rwxr-xr-x    1 root     root           482 Jul  5 22:07 koys.lua
-rw-r--r--    1 root     root           548 Aug  8 18:01 landevices.sh
lrwxrwxrwx    1 root     root             8 Jul  9 00:19 scp -> dropbear
lrwxrwxrwx    1 root     root             8 Jun 29 16:17 ssh -> dropbear
drwxr-xr-x    3 root     root             0 Jan  1  1970 tam
-rwxr-xr-x    1 root     root            36 Jul 18 09:33 test.lua
# df /data
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mtdblock5            1024       680       344  66% /data
...oder einen "unmodifizierten" Rasperry Pi nehmen, auf den Massen von Entwicklern abgewandert sind, nachdem die Boxen zugenagelt worden sind.
Dann kannste sogar starke Kryptologie anwenden und Vertraulichkeit üben.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,286
Punkte für Reaktionen
1,095
Punkte
113
Da ist dann aber ein Pi Zero W (für die Verbindung zur Außenwelt muß es schon "W" sein) oder ein Arduino schon fast wieder sinnvoller als eine 7270 - zumindest dann, wenn man die nicht noch in irgendeiner Kiste herumliegen hat und sie damit "kostenlos" ist (in der Anschaffung).

Ansonsten gehen die Nachteile beim Stromverbrauch los (mit Verbrauchsoptimierung kann man auch den Zero W aus einem USB-Port der 7490 betreiben, wenn der Gesamtstrom für die Box nicht überschritten wird und ein Arduino mit Ethernet-Shield bräuchte weniger als der Zero W) und enden bei der "Wahlfreiheit" hinsichtlich der auszuführenden Software auch noch nicht wirklich.

Ich denke mal, es geht hier eher um die "Nebenbei-Nutzung" eines ohnehin laufenden Geräts (so zumindest mein Eindruck, der ja nicht stimmen muß) und wenn es tatsächlich ein zweites Gerät sein soll und man dessen Hardware nicht schon in der Bastelkiste findet, sollte man da etwas "mit Perspektive" wählen, denn so einem kleinen Zusatzsystem kann man natürlich noch viele andere Aufgaben überlassen, an die man gegenwärtig vielleicht noch gar nicht denkt ... der Appetit kommt da ja meist beim Essen.
 
  • Like
Reaktionen: Jack Sabbath

Jack Sabbath

Neuer User
Mitglied seit
10 Okt 2020
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Was für eine "Anleitung"? Es gibt keine "Schritt für Schritt"-Liste dazu - das Prinzip habe ich hier: FRITZ!Box-Kennwort vergessen ... was nun? (Mail-)Recovery a la AVM oder besser nicht? beschrieben und in Form der "Injektion" von Shell-in-a-Box auch umgesetzt und veröffentlicht (die Suche im Board sollte helfen).

Dann muß man sich noch schlau machen, wie der Update-Prozess bei einer 7490 arbeitet und sich mit geeigneten Mitteln an einer passenden Stelle auf die Lauer legen, damit man das bei einem Update auch in die YAFFS2-Partition des neuen Systems einbauen kann (natürlich alles "per Skript" und nicht von Hand) - das ist auch keine "rocket science", denn der Ablauf eines Updates ist auch desöfteren hier beschrieben worden.

Irgendwelche Links dafür habe ich grundsätzlich nur dann, wenn das Threads sind, die auch von mir selbst begonnen wurden (und auch da lange nicht von allen diesen Threads) - alles andere müßte ich auch erst suchen und das dann wiederum noch einmal aufschreiben. Das erscheint mir jetzt nicht sehr effektiv (aus meiner Warte jedenfalls - die Zeitersparnis für den "Absender" so einer Frage sehe ich natürlich schon).

Ich bin mir auch bei Deiner Feststellung:

nicht so ganz sicher, wie gründlich Du Dir #4 durchgelesen hast, dann da stand ja meinerseits schon:

- ansonsten wäre es ja auch Unsinn von mir gewesen, diese "Besonderheit" der VR9-Plattform (bzw. der VR9-Modelle von AVM mit NAND-Flash) hier überhaupt ins Spiel zu bringen.

EDIT: Ich sehe gerade erst (weil ich mir die Zitate meiner eigenen Beiträge i.d.R. nicht durchlese, da ich ja weiß, was ich selbst geschrieben habe), daß Du sogar denselben Satz von mir VOR Deiner Feststellung, daß die 7490 eine VR9-Box wäre, zitiert hast ... das verwirrt mich jetzt vollkommen.
Danke dir, diese Informationen helfen schon mal sehr!
Zur Verwirrung: Ich habe deinen Beitrag komplett gelesen und hatte es so verstanden, dass die VR9-Plattform genau die von dir beschriebene Besonderheit der 7490 ist, welche die Injektion ermöglicht. Laut FritzBox Übersicht baut die 7490 auf VR9 auf und deswegen habe ich das nochmal erwähnt um dir Recht zu geben, dass diese Voraussetzung wohl gegeben ist. Ich hoffe das klärt dieses Missverständnis ;)
 

chked

IPPF-Promi
Mitglied seit
20 Nov 2006
Beiträge
4,256
Punkte für Reaktionen
17
Punkte
38
Statt des Arduino würde ich einen ESP8266 nehmen. Das Teil hat WLAN gleich schon eingebaut, ein Entwicklungsboard bekommt man bei eBay oder AliExpress für unter 5€.
Wenn man Grundkenntnisse in C/C++ hat, kann man recht schnell einen kleinen Webserver hinzaubern. Der Stromverbrauch fällt nicht ins Gewicht, wenn man das Board z.B. über den USB-Port der Box versorgt, zieht das Modul 20-30 mA.
 
  • Like
Reaktionen: Jack Sabbath

koyaanisqatsi

IPPF-Urgestein
Mitglied seit
24 Jan 2013
Beiträge
12,693
Punkte für Reaktionen
350
Punkte
83
Wie wurde einst von einer meiner Lieblingspunkbands geschrien: "The door stands open - The possibilities are enormous"
Ick brauch nur zweimal in die Hände zu klatschen, dann gehen die Dinge bei mir an oder aus und Wenigverbraucher über USB lass ich lieber über einen aktiven USB-Hub laufen.
...sonst wird bei meinen Ausfallschutz noch der Tetheringmodus verlassen.

Individualisierung, finde ich, macht es Angreifern schwerer.
Sicherheit pentesten muss es aber schon, zumindest die "einfachsten" Sachen.
...aber zu weit möcht ich mich da dann doch nicht aus dem Fenster hängen.
 

Jack Sabbath

Neuer User
Mitglied seit
10 Okt 2020
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Ich neige dazu eine 7270 zu empfehlen.
Die wird von AVM bestimmt nicht weiter zugenagelt und hat einen persistenten Speicher von 1MB: /data
... Vollzitat gemäß Boardregeln gekürzt by stoney
Ich wollte jetzt keine neue FritzBox deswegen anschaffen. Einen ungenutzten Pi habe ich noch rumliegen, aber wie #8 schon treffend beschrieben hat wäre ich recht froh, wenn's die FritzBox übernimmt.
 
Zuletzt bearbeitet von einem Moderator:

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,748
Punkte für Reaktionen
30
Punkte
48

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,286
Punkte für Reaktionen
1,095
Punkte
113
Die überlebt aber ein Update auch nicht ... das habe ich zwar auch mal gebaut, aber noch nicht "freigegeben", weil AVM mittlerweile auch an der "/var/install" und "/var/post_install" herumprökelt, um das mit dem "SILENT MODE" für die Updates auf die Kette zu kriegen. Außerdem war mir eine Änderung, die sich selbst in der Firmware "festkrallt", irgendwie immer zu nahe am "Wurm", der sich selbst weiterverbreitet (hier halt in die andere Partition).

@Jack Sabbath:
Das ist dann auch genau der Weg, den man da mit einer eigenen Erweiterung gehen könnte. Die "/var/post_install" steht in der Datei "/var.tar" in der AVM-Firmware und wird beim Start nach "/var" (das ist die einzige Stelle in der Firmware, wo ein (internes) Dateisystem mit Schreibzugriff gemountet ist) entpackt. Die wird dann (über die "/etc/inittab") beim Shutdown der Box ausgeführt und wenn es ein Firmware-Update von AVM gibt, dann schreibt ein dort enthaltenes Skript die für das Update notwendigen Kommandos an das Ende dieser Datei. Damit hat man üblicherweise einen relativ sicheren Marker dafür, ob da ein Update erfolgte (bzw. eigentlich noch erfolgen soll) oder nicht ... man muß nur die Dateigröße überprüfen oder man sucht sogar gezielt nach entsprechenden Kommandos (sicherer).

Diese Überprüfung kann man jetzt durch (automatisches) Editieren der "/var/post_install" an deren Anfang schreiben ... dafür reicht ja eine einzelne Zeile, die ein eigenes Shell-Skript aufruft, das dann diese Überprüfungen vornimmt und ggf. sogar noch dafür sorgt, daß die später von den AVM-Kommandos installierten Images bereits die eigene Erweiterung beinhalten (so müßte/würde man das auf anderen Boxen machen, die direkt ein SquashFS-Image als Root-FS verwenden). Dieser Prozess ist aber für verschiedene Plattformen auch unterschiedlich, weil die tatsächliche Installation (also das Schreiben der neuen Daten in den Flash oder den eMMC-Speicher) zu anderen Zeitpunkten erfolgt - bei VR9 wird da tatsächlich erst beim Shutdown in den Flash geschrieben.

Daher muß man hier wieder dafür sorgen, daß man sich entweder direkt an den Anfang der "post_install" klemmt, weil man da noch - nach den eigenen Aktionen, die auch eine "Erweiterung" um einen Aufruf nach dem Flash-Schreiben von AVM (mittels "cp -R" als Kommando) beinhalten müssen - die Gelegenheit hat, die Abarbeitung einer noch einmal modifizierten "post_install" mittels "exec" erneut in die Wege zu leiten, nachdem man eigene Aktionen (den ersten Teil der notwendigen Schritte) ausgeführt hat - das verringert die Chancen, daß doppelt ausgeführte Aktionen in der "/var/post_install" zu Problemen führen, wenn man die bei einem späteren Stand der Abarbeitung noch einmal modifizieren würde (es ist "undefined", wie eine Shell auf eine nachträgliche Änderung eines von ihr gerade ausgeführten Skripts reagiert).

Oder man muß hingehen und die "filesystem.image" mit der eigenen Erweiterung neu zusammenpacken - das braucht dann das passende "mksquashfs" in der eigenen Erweiterung und braucht entsprechend lange, was zu diesem späten Zeitpunkt auch keine wirklich gute Idee ist, weil u.a. auch jeder Swap-Space schon Geschichte wäre, da der USB-Stack (üblicherweise) schon gestoppt wurde - das ist auf anderen Modellen ziemlich das Einzige, was bleibt und so ist es dort tatsächlich deutlich komplizierter, weil man am besten schon lange vor dem Shutdown dann die neuen Image-Dateien verändert, was eine kompliziertere "Erkennung" der Update-Situation erforderlich macht.

Für diesen konkreten Fall mit einer 7490 und eher "schmalen" Änderungen, die auch nicht ins SquashFS-Image Einzug halten müssen/sollen, ist es also tatsächlich das Beste, wenn man sich hinter das "cp -R" klemmt (aber vor das "umount" für das YAFFS2-FS) und dort einfach noch einmal ein eigenes Skript für die Übernahme der eigenen Erweiterung nach "/var/tmp/fs_mtd" (da ist die Wrapper-Partition des neuen Systems dann gerade gemountet) aufruft.

Ab 07.19-Labor bzw. 07.21-Release, ist das dann wieder alles ganz anders ... ab jetzt wird - zumindest für "SILENT_UPDATE", was bei AVM wohl eher ein "blind update" ist, denn da wird halt nichts signalisiert mit den LEDs zum Zeitpunkt der tatsächlichen Installation - die neue Firmware sofort installiert (die Kommandos dazu werden in die Datei "/var/updatestore/update_action_flash" geschrieben und diese dann aufgerufen aus der "/var/install" heraus) und nur der Neustart auf später verschoben, während die "/var/post_install" auch schon durch die "/var/install" präpariert wird - ggf. werden ein paar notwendige Änderungen an den Einstellungen auch noch bis zum Neustart verschoben, damit das laufende System noch mit den alten arbeiten kann.

Hier kann/muß man sich einfach nur selbst darum kümmern, daß die (neue) Wrapper-Partition noch einmal gemountet wird, bevor man die eigene Erweiterung dort hineinkopieren kann - den Skript-Aufruf dazu kann man wieder getrost (beim Start der eigenen Erweiterung) an das Ende der "/var/post_install" schreiben (da braucht es dann die "frühe Prüfung" auch nicht), weil die "/var/install" die ohnehin fortschreibt und es hier kein "cp -R" durch die "/var/install" mehr gibt, nach dem man erst selbst aktiv werden kann. Da die neue Firmware schon in den Partitionen steht, kann man sie auch schon früher abändern.

Ab dieser Version stimmt dann auch die bisher in Freetz zu findende Aussage, daß man die Installation einfach "ungeschehen" machen könne, wenn man einen irregulären Neustart ausführt, bei dem die "/var/post_install" nicht abgearbeitet wird (meinetwegen per "Power Off"), für die anderen Modelle mit diesem Mechanismus nicht länger - aber auch da kriegt man dann deutlich mehr Zeit und Gelegenheit (wenn die Updates jetzt "planbar" sind), die bereits installierte, neue Firmware noch einmal zu überschreiben, während das System ansonsten noch voll funktionsfähig ist.

Denn das war eines der größten Probleme bei diesem Vorgehen bisher ... wurde ein Update gestartet, wurden auch die meisten FRITZ!OS-Prozesse schon vor diesem Update heruntergefahren und man mußte entweder auf sie verzichten (das betraf bei bestimmten Update-Formen auch die Internet-Verbindung) oder man mußte sie erst mühsam neu starten. Das schränkte die Möglichkeiten (bis hin zum Nachladen von zusätzlichen Programmen, die man noch in das Image einbauen lassen will, aus dem Internet) erheblich ein und ein aufgesetzter Watchdog für das Ende des Updates (falls sich das irgendwo aufhängt) mußte auch erst eingeschläfert werden oder man mußte innerhalb der vorgegebenen Zeit fertig werden.

Eigentlich hatte ich das Prinzip auch schon mal vor ein paar Jahren gezeigt, da ging es noch um eine 6490: https://github.com/PeterPawn/YourFritz/tree/master/autoupdate - in "update_system" wird ein (möglicher) Aufruf eines zweiten Skripts am Anfang der "/var/post_install" gezeigt (hier verhindert dann eine Datei als Semaphore den zweiten Aufruf des eigenen Skripts, wenn die "/var/post_install" erneut abgearbeitet wird) und in "run_update" wird (aus dem Kopf erzählt, steht bestimmt irgendwo in der Datei) geprüft, ob es ein Update gibt, was zu installieren wäre und wenn das der Fall ist, wird es eben gemacht. Das ist zwar von den Aktionen her leicht etwas anderes, aber die Prinzipien (Absichern gegen doppelte Ausführung, Prüfen auf notwendige Aktionen, ggf. Ausführen derselben) sind sich schon ziemlich ähnlich - auch wenn's hier eben nicht um die eigene Reproduktion der Software (und damit einen "Wurm") ging.
 
  • Like
Reaktionen: Jack Sabbath

Jack Sabbath

Neuer User
Mitglied seit
10 Okt 2020
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Vielen Dank @PeterPawn! Ich werde wohl erst in den nächsten Tagen dazu kommen das umzusetzen, aber diese Hilfe Informationen werden mit Sicherheit sehr helfen!
 

Jack Sabbath

Neuer User
Mitglied seit
10 Okt 2020
Beiträge
6
Punkte für Reaktionen
0
Punkte
1
Nochmal eine ganz dumme Frage (traue mich kaum zu fragen): Wie komme ich denn am besten auf die Fritzbox? Momentan ist Version 7.12 drauf. Telnet per Telefonanruf freischalten geht ja nicht mehr, wenn ich richtig informiert bin.
 

eisbaerin

IPPF-Promi
Mitglied seit
29 Sep 2009
Beiträge
8,480
Punkte für Reaktionen
456
Punkte
83
z.B. mit modfs von Peter:
oder
 
  • Like
Reaktionen: Jack Sabbath