Ansonsten ist es ja auch "bekannt", daß die Verschlüsselung der intern gespeicherten Zugangsdaten (aka "credentials") - und das meint nicht nur die DSL-Zugangsdaten, sondern
alle verschlüsselt gespeicherten Werte, also diejenigen, die mit vier Dollarzeichen beginnen und danach nur die Buchstaben A bis Z und die Ziffern 1 bis 6 für die von AVM verwendete Form einer
Base32-Kodierung enthalten - "individuell" ist (es wird aus boxspezifischen Einstellungen ein Kennwort errechnet und neben diesem Kennwort geht noch ein jeweils für einen Wert individueller "salt"-Wert mit die Ver-/Entschlüsselung eines konkreten Wertes ein) und auf den verwendeten Werten für "wlan_key" und "maca" basiert (zumindest bei vielen Modellen, bei der 6490 weiß ich es gerade nicht mehr und bei der 6360 kann ich es nicht mehr testen). Auf der Basis dieser "Erkenntnisse" arbeitet dann ja auch "decode_passwords", wenn man es für das Dekodieren der (internen) Dateien einer anderen FRITZ!Box mit MAC-Adresse und WLAN-Key aufruft. Sowie man also einen der beiden Werte ändert (ob nun in den Daten aus der Finalisierung oder über Einträge im TFFS - entscheidend ist der resultierende Wert im FRITZ!OS), kann das OS die eigenen (verschlüsselten) Einstellungen nicht mehr lesen ... das ist also kein "spezielles Problem" beim Ändern des Bootloaders.
Vom "Leeren" von MTD3 und/oder MTD4 (bzw. das spielt eben nur eine Rolle, wenn man beide gleichzeitig bearbeitet, weil ansonsten - dank 0xFFFFFFFF als "segment ID"-Kennzeichnung bei gelöschten Flash, wo ansonsten 0x00010004, gefolgt von einem 32-Bit-Wert für die (negierte) ID, stehen würde - einfach die andere benutzt wird) kann man ohnehin nur abraten ... vor allem dann, wenn man hinterher das Recovery-Programm verwenden will. Kann der Bootloader dann aus irgendeinem Grund das "RETR env" nicht korrekt ausführen (er muß dazu eigentlich auf die Daten aus der Finalisierung und den "legacy settings" in seinem eigenen Code zurückgreifen), hat das Recovery-Programm auch nur ein "unvollständiges Environment", schreibt das dann in die TFFS-Partitionen und im ungünstigsten Fall startet dann der Bootloader beim nächsten Versuch nicht einmal den FTP-Server korrekt. Wer das also ohne serielle Konsole oder JTAG-Interface in Angriff nimmt, riskiert m.E. zuviel ... vollkommen unabhängig davon, daß das ruKernelTool das schon lange so macht. Dort wird beim "Leeren" einfach (nach dem impliziten Löschen der Partition, ein direktes Kommando zum Löschen - wie über die Konsole - gibt es im FTP-Server nicht) eine Datei der Länge 0 geschrieben ... in der Folge sind beide Partitionen leer und werden jetzt beim Start des FRITZ!OS erst einmal mit einer gültigen TFFS-Struktur initialisiert. Was in so ein Image eigentlich alles hineingehört, kann man sich im Ergebnis von "build_tffs_image" ansehen ... spätestens dann, wenn der TFFS-Treiber beim Start des Systems irgendwann mal NICHT mehr damit klarkommt, daß es gar keine Daten in den Partitionen gibt (der neue Legacy-Treiber für TFFS 3 "beschwert" sich zumindest schon mal über fehlende Strukturen in "TFFS3_LGCY_Setup()"), dann kann das ins Auge gehen.
Wobei das im AVM-TFFS-Treiber ohnehin ein Krampf ist, wo man sich fast einen Knoten ins Gehirn machen muß ... intern wird die Segment-ID nämlich dann nicht als vorzeichenbehaftete 32-Bit-Zahl angesehen, das gilt nur für die Speicherung im Flash und so wird diese ID dann nach dem Lesen noch negiert, bevor sie im laufenden System verwendet wird und vor dem Speichern dann logischerweise ebenfalls. Damit zählt der Code im Treiber dann diese Segment-ID
hoch für eine neue Version, während sie bei der Speicherung
dekrementiert wird. Das sind beim Review dieses Codes ganz böse Fallen, wenn da irgendein "größer/kleiner"-Vergleich steht und im Hexdump des Inhalts findet man den negierten Wert ... nur noch als "Ergänzung", weil der Code-Schnipsel in #10 ansonsten mit seinem Vergleich mittels ">" vielleicht etwas mißverständlich wirkt.
Ich bin ohnehin mal gespannt, ob AVM dann einen
Fehler bei der Initialisierung der "name table" im laufenden System tatsächlich gefixt hat und wie die neuen Quellen dort aussehen (war ja nicht so kompliziert, nur ein zusätzliches Limit war einzubauen).
Warum stelle ich mir diese Frage überhaupt? Nun, nicht alle "bestätigten" Probleme sind ja auch korrigiert und für dieses Problem habe ich nur eine E-Mail am 23.09.2016 um 10:59 Uhr erhalten, jedoch keine Incident-Nummer von AVM und nur den Hinweis, es wäre in der nächsten Labor-Version für die 7490 dann gefixt.
Das galt aber nach meinem Verständnis für
dieses Problem auch (E-Mail vom 24.06.2016, 15:25 Uhr, auch mit der Versicherung, es würde im nächsten "major release" behoben sein) und diese Lücke war zumindest in der 113.06.80 gerade noch auszunutzen (das PowerShell-Skript dazu steht im Repo). Zumindest wurde die Datei noch überschrieben und das wäre schon für sich ein "Problem", selbst wenn das FRITZ!OS dann vielleicht wegen irgendeiner zusätzlich gespeicherten Prüfsumme (es gibt irgendwelche neuen Einträge in Konfigurationsdateien zu diesem "BPjM-Thema") dieses Update nicht mehr verwendet und auf die interne, ältere Version zurückgreift (habe ich gar nicht erst getestet) - zumindest wäre es dann immer noch möglich, auf diesem Weg das Verwenden einer aktuellen Liste (über deren generelle Aktualität bei monatlicher Versionierung sollen andere urteilen) zu verhindern, was nur auf den ersten Blick "weniger schlimm" (bzw. "relevant") aussieht. Andererseits könnte es ja auch sein, daß AVM die 06.80 gar nicht als ein solches "major release" ansieht und erst eine Version 07.irgendwas dieses Kriterium erfüllt - dann wäre ich meinerseits von falschen Annahmen ausgegangen.
EDIT: Dem BPjM-Thema hatte ich ja tatsächlich schon einen eigenen Thread "gewidmet", der findet sich hier:
http://www.ip-phone-forum.de/showthread.php?t=288698
