[Problem] Neues Debranding Problem: FB7490 1&1, HWRevision: 185, Subversion: 6 (2017)

[angelo]

Jo, cool funktioniert das so? Ist zwar bisserl Operation am offnen Herzen, aber was solls, no risk, no fun...

 

[angelo]

Ich antworte mir mal selber
Also, ausprobiert an der 7490 International mit HWSubRevision 6 (mittlerweile gibts schon die HWSubRevision 7, keine Ahnung ob das da dann auch noch geht).

Mit einer alten Recover auf die 6.30 (International) geflasht, um Telnet zu bekommen (per Pseudo Firmware). War für mich die schnellste Variante für Telnet.

Dann unter der 6.30 mit Telnet folgendes ausführen:

Mit

cat /dev/mtdblock6 > /InternerSpeicher/FRITZ/faxbox/bootloader.bin

den Bootloader in den nichtflüchtigen NAS Speicher der Box geladen

dann über das Fritz.Nas die Datei holen, mit dem Hex-Editor bearbeiten wie oben beschrieben, ich hab die firmware_version von avme auf avm, den Annex von A nach B sowie die MAC Hersteller ID (erstes Byte) geändert von 38:xx auf 34:xx. Anscheinend wird der Schreibschutz auch anhand der MAC Adresse gesetzt, weil siehe da, mit einer 34er MAC war der Schreibschutz weg und man konnte wieder permanente Änderungen im Environment mit Adam2 vornehmen.

Wichtig:
zurückladen über Fritz.NAS und dann
per
cd ..
cd InternerSpeicher/FRITZ/faxbox
cat bootloader.bin > /dev/mtdblock6

den Bootloader zurück schreiben.

Ich habe danach noch einen Gegen-Test gemacht, ob der Bootloader richtig geschrieben wurde, indem ich das Prozedere wie oben nochmal gemacht habe und die Daten verglichen habe. Und siehe da, es steht nur Müll in mtdblock6. Wenn jetzt ein Reboot erfolgt, hilft nur noch JTAG.
Anscheinend greifen da im laufenden Betrieb noch andere Prozesse drauf zu und deswegen ist das ein wenig Glücksspiel und das Ergebnis sollte immer vor einem Reboot verglichen werden!

Also noch folgendes probiert:
cat bootloader.bin > /dev/mtd6

Und wieder gegencheck gemacht, dieses Mal mit
cat /dev/mtdblock6 > /InternerSpeicher/FRITZ/faxbox/bootloader.bin
und
cat /dev/mtd6 > /InternerSpeicher/FRITZ/faxbox/bootloader2.bin

und voila: sowohl in mtd6 wie auch in mtdblock6 stehen die richtigen Daten.

Nun konnte ich beruhigt einen Reboot machen und siehe da, die Änderungen wurden übernommen.


Achja: ab FritzOS 7 scheint das eh wurscht zu sein ob avme oder avm, er machte bei mir aus avme immer avm beim Upgrade von 6.93 auf 7.01. Nur das Annex=A blieb, aber durch Umschalten an der Oberfläche auf B kommen dann die kernel_args Annex=B hinzu, also eigentlich keine Notwendigkeit mehr, die obige Operation am offenen Herzen durchzuführen...


.

 

[stoney]

Ginge das nicht auch, indem man sich mtd6 via Bootloader "zieht" um sich so einen Haufen (unnötige?) Arbeit zu sparen?

 

[NDiIPP]

Ich habe danach noch einen Gegen-Test gemacht, ob der Bootloader richtig geschrieben wurde, indem ich das Prozedere wie oben nochmal gemacht habe und die Daten verglichen habe. Und siehe da, es steht nur Müll in mtdblock6.

So ähnlich war mir das auch schon passiert (siehe vor-vorletzter Absatz):
https://www.ip-phone-forum.de/threa...ourfritz-eva_tools.298591/page-4#post-2311795

Zum Glück hatte ich ebenfalls einen "Gegen-Test" gemacht und es somit rechtzeitig bemerkt.


@stoney
Ich glaube bei den neueren Bootloaderersionen verhindert dieser ein (Über)-Schreiben der Bootloader-Partition. Da ich sowieso eine aktuelle (modifizierte) Firmware mit Konsolenzugang (dropbear) verwendete (damals FRITZ!OS 6.93 oder 7.00) war das auch nicht weiter tragisch oder ein Mehraufwand (Edit: Alternativ, wenn man die Firmware nicht modifizieren möchte, kann man ja auch eine dieser neueren Inhaus-Version mit Konsolenzugang verwenden anstatt das Downgrade auf eine uralte Firmware durchzuführen).

Bei den neueren Boxen (mit wohl anderem Flash-Chip, ab SubRev. 7?) würde ich übrigens auch keine alte Firmware-Version mehr flashen sondern eine aktuelle (modifizierte) mit Konsolenzugang empfehlen.

 

[PeterPawn]

Man kann über den Bootloader zwar die Daten aus der Finalisierung auslesen (als "config"), aber nicht mehr den gesamten Bootloader-Code - jedenfalls soweit ich weiß bzw. das immer mal wieder probiere (einfach um diese in Stein gemeißelte Erkenntnis zu prüfen, falls es wieder mal "stille Änderungen" gibt).

Für ein Update reicht dieser "config"-Bereich ja auch aus, der wird dann halt in den neuen Code an der richtigen Stelle "eingebaut" und schon hat man wieder ein Image, was dann den vorhergehenden Bootloader ersetzen kann. Der große Vorteil eines solchen "Downloads" der Finalisierungsdaten ist es aber, daß man damit schön vergleichen kann, wo diese nun im Bootloader-Code stehen und was sie beinhalten - auch wenn das (zumindest teilweise) mit den Kernel-Quellen auch nachvollziehbar wird.

 

[angelo]

Ja, die Methode zum Erlangen des Shellzugangs ist eigentlich wurscht, Hauptsache, man hat ihn dann
Über Adam2 wird leider der Zugriff auf mtd6 verhindert, auch lesend, über seriell habe ich es nicht probiert.
Ich habe als Bootloader eine 256kb große Datei erhalten aus dem mtdblock6 und die sieht mir, wenn ich es mit einem alten Bootloader aus der 7270 vergleiche, schon ziemlich komplett aus, nicht nur die Finalisierungsdaten?

 

[PeterPawn]

1. Über die serielle Schnittstelle kann man gar keine Daten auslesen, solange man das nicht "Wort für Wort" mit den Befehlen für den Speicherzugriff macht. Oder wie lautet das Kommando für den "Download" über die Serielle und vor allem, welches "Protokoll" käme dabei zum Einsatz? Da bliebe ja nur so etwas wie "kermit" (ist zwar nicht der Frosch, wurde aber nach ihm benannt) oder X/Y/ZModem, wenn man "Dateien" in einer solchen Verbindung "in-band" übertragen wollte. EDIT: Das gilt - nur nebenbei - auch für das Beschreiben der Flash-Partitionen ... ich wüßte zumindest nicht, wie das mit EVA und der seriellen Schnittstelle zu bewerkstelligen wäre.

2. Ich schrieb doch genau, unter welchem "Pseudodateinamen" man die Finalisierungsdaten über den Bootloader per FTP auslesen kann. Dabei war doch nicht mal im Ansatz davon die Rede, daß das "memory technology device" mit der Minor-ID 6 (im laufenden FRITZ!OS !) ausschließlich die Finalisierungsdaten beinhalten würde, oder? Nur liefert das "RETR config" beim Bootloader eben nicht den kompletten Inhalt der Bootloader-Partition (die dort - nur nebenbei - auch noch als "mtd2" firmiert), sondern nur die bereits erwähnten Finalisierungsdaten.

 

[angelo]

Achso, nix für ungut, hab dich dann falsch verstanden, dachte du meintest, dass man gar nicht mehr an den vollständigen Bootloader dran kommt. Das mit (als "config") war da wohl mißverständlich. Wusste gar nicht, dass man früher mit RETR config an den kompletten Bootloader kommen konnte.
Bei der seriellen ging das bei alten Boxen (da war ich aber zuletzt bei einer 7050 dran) tatsächlich über kermit oder xmodem, aber man musste sehr viel Geduld mitbringen, also vergesst es einfach wieder.

 

[PeterPawn]

Wusste gar nicht, dass man früher mit RETR config an den kompletten Bootloader kommen konnte.

Nicht böse sein, aber das habe ich auch wieder nicht geschrieben - weil ich's gar nicht (genau) weiß. Früher konnte man aber noch über den Bootloader den Inhalt von Flash-Partitionen lesen und da gehörte der Bootloader tatsächlich dazu, da war es aber m.W. auch noch der von TI. Irgendwo im Freetz-Wiki habe ich - so glaube ich mich zu erinnern - beim Erstellen des Mirrors vom Trac-Server vor der Bereitstellung auf GitHub sogar mal etwas dazu gelesen, wie man über den FTP-Server des Bootloaders den für die eigene Box sichern kann - aber wohl tatsächlich für die Boxen in der Gegend der von Dir erwähnten 7050 und bei der war noch sooo vieles anders als heute.

Mit dem "RETR config" kriegt man eben genau diesen Bereich mit den Finalisierungsdaten aus dem Bootloader, sofern es sich um AVM's EVA handelt ... das ist aber an anderen Stellen hier auch beschrieben und eine von den drei "Dateien", die man heutzutage noch mit dem "RETR"-Kommando aus fast jeder Box laden kann. Die anderen "Spezialdateien" gibt es auch nicht in allen Bootloader-Versionen bzw. allen FRITZ!Box-Modellen. Welche "Namen" der Bootloader und/oder ein Recovery-Programm i.d.R. kennt, kann man z.B. hier nachlesen: https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/EVA_FTP.cs#L169

EDIT: Korrektur war nur "Klammern auflösen".

 

[Insti]

sowie die MAC Hersteller ID (erstes Byte) geändert von 38:xx auf 34:xx. Anscheinend wird der Schreibschutz auch anhand der MAC Adresse gesetzt, weil siehe da, mit einer 34er MAC war der Schreibschutz weg und man konnte wieder permanente Änderungen im Environment mit Adam2 vornehmen.

Hi,
hat das Auswirkungen wenn der myfritz.net Dienst genutzt wird?

 

[avm_7170]

die MAC Hersteller ID (erstes Byte) geändert von 38:xx auf 34:xx.

wie bist du darauf gekommen? Gibt es denn eine MAC Adresse Raum von AVM für dir Box?

 

[angelo]

Ob das Auswirkung auf myFritz hat, keine Ahnung, nutze ich nicht.
Meine "deutschen" Boxen hatten alle MAC Adressen im 34:er Bereich, weshalb ich das einfach mal probiert habe.