Fakt ist doch das ich die Box im Adam2 anhalten muss um irgend was an der Firmware änder zu können, oder?
Habe ich doch genau so auch geschrieben ... ohne Bootloader geht nichts anderes.
Aber welche Möglichkeiten es dafür gibt und was man dabei alles falsch machen kann, ist nun wirklich so oft durchgekaut worden, daß es unmöglich noch eine weitere Selbsthilfegruppe zu diesem Problem brauchen kann. Dann eher eine zum Thema: "Wie suche ich richtig - im IPPF und mit einer externen Suchmachine" ... noch mal: Es bringt keinesfalls "mehr Übersicht", wenn man dieselben Themen immer und immer wieder "bespricht" und dabei nicht wirklich auch neue Fakten eine Rolle spielen ... die gibt es aber an dieser Stelle eher nicht. Das heißt nicht, daß ich mich hier nicht irren kann ... aber vor die Vermutung, daß am Ende der Bootloader selbst schuld ist, würde ich immer wieder erst einmal die penible Überprüfung auf eigene Fehler setzen - rein unter dem Gesichtspunkt der Wahrscheinlichkeit.
Klar, man kann auch mal der Erste sein, der eine Änderung durch AVM bemerkt ... je nachdem, wie intensiv man sich jetzt selbst mit der FRITZ!Box beschäftigt, sollte man aber auch eine (realistische!) Einschätzung treffen können, wie hoch die Wahrscheinlichkeit dafür tatsächlich ist. Wenn ich vier Wochen nach dem Erscheinen einer Hard- und Software-Version noch "neue Feststellungen" mache, sollte ich diese erst recht mehrfach überprüfen, bevor ich mir sicher sein kann, daß es nicht nur irgendwelche "Phantom-Schmerzen" sind.
Das, was Dir
@stoney in #24 geschrieben hat, ist halt die häufigste Feststellung ... selbst bei dem 6490-Problem in den letzten Tagen stellte sich das am Ende nur als heiße Luft heraus mit der Vermutung, daß AVM da den Bootloader irgendwie gänzlich blockiert hat (bzw. den Zugang zu diesem).
----------------------------------------------------------------------------------------------------------
So etwas geht zwar tatsächlich ... aber eben nur mit einer umgekrempelten Architektur (z.B. einer kryptographisch gesicherten Verbindung zwischen Recovery-Programm und Bootloader) und das wäre für ein existierendes Modell wohl eher ein Support-Albtraum, wenn dann Recovery-Programm A nicht mehr mit Box B, sondern nur noch mit Box C funktioniert.
Das ist AVM eine höhere Sicherheit bei Zugriffen über den Bootloader sicherlich nicht wert - was nicht heißen muß, daß man bei neuen Entwicklungen (für die Hardware) nicht auch da Aufwand treiben könnte.
Die Frage wäre vermutlich, ob Veränderungen an dieser Stelle (nicht jede Änderung muß auch eine Verbesserung sein) so weitreichende Auswirkungen auf den Support-Aufwand hätten (was schon mal unterstellt, daß viele "Bastler" AVM am Ende mit ihren Problemen behelligen würden), daß sich der Mehraufwand (von Entwicklung über zusätzliche Hardware-Komponenten in Form von SoC bis zur Programmierung von Firmware, Bootloader und Recovery-Programm) am Ende auch auszahlt. Bei allen bekannt gewordenen Sicherheitsproblemen waren ja nicht die eigenen Modifikationen der Kunden die Ursache, sondern originäre Probleme in der AVM-Firmware. Die beseitigt man auch nicht dadurch, daß man den Kunden keine eigene Firmware mehr installieren läßt.
Es würde ja schon reichen, wenn AVM den (nicht autorisierten) Zugriff auf den Bootloader erschwert (ob das bei den GRX5-Boxen nun Absicht oder ein Fehler ist, hat AVM ja auch noch nicht definitiv bestätigt oder habe ich da etwas verpaßt?) und damit die Angriffsfläche verringert ... das endgültige "Verriegeln" der Boxen würde wohl eher dazu führen, daß weitere Kunden (die bisher den etwas höheren Aufwand für eigene Änderungen in Kauf nehmen, weil das bei ihnen wirklich mehr als "nice to have" ist und sie am Ende mit einem Shell-Zugang auch etwas anfangen können - teilweise im Gegensatz zu anderen, die den einfach nur "aus Prinzip" wollen und der Meinung sind, sie hätten den ja bezahlt) der FRITZ!Box den Rücken kehren.
Das wäre dann viel Aufwand in eine Funktion investiert, die den Multiplikatoren (und die Bastler sind ja i.d.R. auch in dieser Rolle) den Spaß an der Box erst so richtig vermiest und sie von der Box wegtreibt - also im Prinzip ein Schildbürgerstreich. Wer, wenn nicht die Leute mit "Ahnung", soll denn am Ende die künftigen Kunden davon überzeugen, daß der Mehrpreis einer FRITZ!Box sich - je nach Anwendungsfall - durchaus rechnen kann?
Daher glaube ich auch gar nicht an solche finsteren Pläne (zumindest an keine ernsthaften - vielleicht mal als Machbarkeitsstudie mit einem TPM o.ä.,) bei AVM - vielleicht mit Ausnahme der DOCSIS-Boxen (ggf. noch LTE, wobei ich nicht weiß, wie weit das Modem da wirklich gekapselt und abgeschottet ist in der Art, wie die Baseband-Module bei Smartphones), weil da der Standard schon entsprechende Forderungen enthält.
Ich habe bisher auch noch keinen Bootloader für die 7490 gesehen, bei dem tatsächlich ein FDT im Bootloader enthalten wäre (die GRX5-Boxen haben immerhin auch 1 MB für den Bootloader im NAND reserviert, die 7490 hat gerade mal 256 KB im SPI-Flash) - bisher hege ich ja die Vermutung, daß dieser die Ursache dafür wäre, wenn Änderungen von "firmware_version" im TFFS nicht mehr übernommen werden und immer eine Einstellung aus der Finalisierung aktiv ist.
Die muß auch nicht stimmen (es gibt ja auch andere Einstellungen, die immer wieder beim Booten auf den Ausgangswert gesetzt werden und das könnte sich in neueren Bootloader-Versionen der 7490 ja auch auf "firmware_version" erstrecken), aber es ist halt auch schwer, bei solchen Meldungen dann zwischen Problemen des "Finders" beim Ändern und der wirklich unmöglichen Änderung zu unterscheiden - meine Skepsis orientiert sich dann immer an meiner Meinung, was AVM von so einer Änderung hätte bzw. ob die irgendwo die Kompatibilität mit alten/anderen Geräten so weit über den Haufen wirft, daß Aufwand und Ergebnis in keinem Verhältnis zueinander stehen.
Man muß nur mal überlegen, welchen "Weg des geringsten Widerstands" AVM z.B. bei der 7412 und ihrem "Mißbrauch" als "DSL-Modem" gegangen ist ... das war ja nun in der Umsetzung eher "symbolisch" und irgendwie leuchtet mir nicht so richtig ein, was AVM jetzt für einen Vorteil davon hätte (oder auch, welcher OEM das von AVM gefordert haben könnte, das Gehäuse und die Farbe ändert sich mit "firmware_version" ja noch lange nicht), wenn man diese Variable nicht mehr auf "avm" oder "avme" setzen könnte.
Echte Vorteile im Absatz würde ich dabei eher nicht sehen (solange die Hardware praktisch identisch ist und bleibt, fehlende TAE-Buchsen sind da mal außen vor) ... ganz im Gegenteil - ein Beispiel hatten wir doch gerade erst hier, wo jemand jetzt stinksauer auf AVM zu sein scheint. Das "Geschlecht" der FRITZ!Box bei ihrer Geburt war ja schon lange im Bootloader in den Finalisierungsdaten enthalten ... das ließ sich halt nur bisher überschreiben, was aber bei "maca" meist auch schon scheiterte.
Sinn ergibt das ja eigentlich nur dann, wenn wirklich die deutsche und die internationale Version jetzt oder in Zukunft mal unterschiedliche Hardware enthalten und/oder der Einsatz der deutschen Firmware im Ausland generell unterbunden werden soll (z.B. wegen des WLAN). Wie das dann aber die Leute davon abhalten soll, sich eine internationale oder auch eine deutsche Firmware auf die Unterstützung von "avme" und "avm" parallel zu modifizieren (auch wenn es in Binärdateien noch einige Abfragen diesbezüglich geben mag, kann man ja jedem Binary gezielt das benötigte "$OEM" im Environment unterjubeln), sehe ich auch nicht ... damit liefe das eigentlich auch wieder ins Leere. Wenn es also nicht sehr einfach zu realisieren war - quasi fast als "Nebenprodukt", verstünde ich den Aufwand dafür nicht bzw. was man sich davon verspräche.
