Vermutlich ... da aber AVM wohl die /var/install (die müßte das feststellen) eher nicht besonders an die Labor-Versionen angepaßt hat (da werden wohl nur passende Teile zusammengesetzt - die Statements sind m.W. dieselben wie bei den Releases), wird das halt nicht erkannt. Eigentlich wäre auch das ja kein Problem, wenn nicht der "Rückweg" von der Labor-Version auf die andere über das Recovery-Programm führen sollte nach dem Willen von AVM.
Theoretisch ist das mit einem kleinen Programm (oder Skript), was ein startbares Image in den Speicher der Box schiebt und dann eben keine Firmware neu schreibt (selbst das ginge noch, ist aber unnötig, wenn man nur "linux_fs_start" umschalten muß), sondern den TFFS-Inhalt wieder so löscht, wie es bei "Werkseinstellungen" erfolgt. Das Problem liegt beim Recovery-Programm ja bloß daran, daß es unbedingt die beiden TFFS-Partitionen neu schreiben will und über den Bootloader nun mal der Node mit der "provider-additive.tar" nicht ausgelesen werden kann - eben auch vom Recovery-Programm nicht.
Der komplizierte Weg wäre es wohl, mit einem eigenen Image den Inhalt des Nodes 29 irgendwie auf einen USB-Stick zu schreiben (das ist aber wirklich komplizierter, weil da alles zusammenpassen muß bis zum udevd oder dem USB-Stack) oder sogar ein Programm mit einem kleinen TFTP-Server zu haben (die Box kann problemlos auch ohne "das große System" auf einen TFTP-Server zugreifen, macht AVM wohl inzwischen bei der Finalisierung genauso, habe ich in irgendeinem Skript gesehen, ich glaube bei der 7580), wo der Node 29 bei einem ersten Start gesichert wird, damit das Recovery-Programm im Anschluß wieder "ganz normal" das TFFS schreiben kann - halt dann mit dem zusätzlichen Node.
Es muß beim Recovery-Programm auch irgendeine Möglichkeit einer ini-Datei geben, mit der genau solche Einstellungen (zusätzlicher TFFS-Inhalt und die Provider-Variable) geschrieben werden können ... ich würde sogar sagen, daß es im normalen Import auch möglich ist, diese Daten irgendwie zu schreiben. Frag mich nicht, wie es geht ... das steht irgendwo weiter hinten auf der Liste der zu testenden Angriffe - einfach weil die Eingangsvoraussetzungen nicht ganz klar sind und die Kombinationsmöglichkeiten zu vielfältig.
Außerdem ist der Angriff über den Bootloader mit einem RAM-Image ja viel einfacher ... deshalb fällt mir bei Problemstellungen wie dieser auch das immer als erstes ein - selbst beim Auslesen unbekannter Konfigurationen oder ähnlichen Problemen wie einfachen TFFS-Dumps bei fehlendem Zugriff auf Benutzerkonten einer unbekannten Box. Aber das sollte man eben bei einer "unbekannten" Box immer erst mal machen, bevor man sie zurücksetzt und dann nichts mehr zur Analyse da ist - gilt am Ende eben auch für den Inhalt der "provider-additive.tar", deshalb finde ich das simple Löschen von "provider" im Environment mit anschließender Anwendung des Recovery-Programms auch nicht so prickelnd (solange die Box noch funktioniert, kann man die Daten auch sichern).
