[Info] Sammelthema zur AVM FRITZ!Box 7520

[Insti]

Jemand hatte mal ausprobiert, den Bootloader zu modifizieren. Daraufhin startete die Box dann nicht mehr, mit entsprechender Fehlermeldung.

Mir ist da auch noch was in Erinnerung :O https://www.ip-phone-forum.de/threa...-in-mtd1-zurückschreiben.306978/#post-2372110

 

[eisbaerin]

Aber das lag IMO nicht daran, daß da was signiert ist.

 

[treysis]

IMO

AFAIK?

Gut, es könnte sein, dass da nur irgendeine Prüfsumme getestet wird, dass sich der Inhalt nicht verändert hat?

 

[PeterPawn]

Bestätigt ist das m.W. bisher nicht wirklich ... es gibt aber Berichte, daß die Box nach einer Änderung an der Urlader-Partition nicht mehr richtig startet.

Ob das letztlich tatsächlich an einer "echten Signatur" des Loaders liegt (solange das nicht vom 1st-Stage-Loader über die Serielle behauptet wird, was ich auch schon irgendwo gelesen habe - das kann aber auch bei den 40x0-Boxen gewesen sein) oder nur an einer unsachgemäßen und/oder unvollständigen Änderung (z.B. an einer nicht angepaßten Prüfsumme, die aber noch längst keine Signatur ist), steht (immer noch nur m.W.) noch nicht fest - ein fehlgeschlagener Änderungsversuch ist zwar ein Grund für eine These, daß da etwas signiert sein könnte, aber noch lange kein Nachweis.

Eine solche Prüfsumme über den Konfigurationsbereich existiert auch bei anderen Modellen bereits (zumindest dem Anschein nach, falls man die Zeichen CRC am Ende dieses Bereichs als solche ansehen wollte:

000bf000  43 52 43 00 42 39 16 09  e3 b1 bf a4 ff ff ff ff  |CRC.B9..........|
000bf010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|

- auch wenn ich gerade nicht mehr weiß, was da von wo bis wo mit welchem Algorithmus abgesichert wird) ... nur interessiert(e) sich da niemand dafür (zumindest nicht so gründlich, daß eine Abweichung direkt die Box brickt), ob diese Prüfsumme auch stimmt - so zumindest meine Erfahrungen (und es gibt auch Berichte von anderen - aber eben bei anderen Modellen, die keinen ARM-SoC hatten).

Aber diese ARM-SoCs haben tatsächlich solche Möglichkeiten und AVM aktualisiert da nach einem Update auch mittels tzupdate noch irgendwelche zusätzlichen Daten ... und eine Interpretation von tz als "trust zone" wäre zumindest naheliegend. Auch die Zeichenketten im Inneren dieses tzupdate (das in den Update-Images für diese beiden Modelle enthalten ist) sprechen für diese Interpretation.

Wobei auch das noch nicht zwingend eine (kryptographische) Signatur bedeuten muß ... ja, wenn man sich ein paar Log-Files ansieht (u.a. das mittlerweile oben verlinkte), findet sich da auch die Zeichenfolge SBL - was angesichts einer sblupdate in den Update-Images schnell mal als "secure boot loader" interpretiert werden könnte (ging mir im ersten Reflex auch so) und auch die in der AVM-Datei sichtbaren Pfade (u.a. boot_images/core/boot/secboot3/hw/ipq40xx/sbl1/sbl1_config.c) sprechen mit ihrem secboot...-Teil ja irgendwie dafür.

Nur gibt es offensichtlich nicht nur einen SBL, sondern auch einen PBL - und wenn man den als "primary boot loader" interpretiert, drängt sich ein "secondary boot loader" für dieses SBL eigentlich genauso auf und auch das würde zu einem secboot... passen. Ich würde mittlerweile fast vermuten, daß zwar der PBL und der SBL gegen Modifikationen gesichert sind (auch diese (nicht fortlaufenden) Meldungen im SBL-Code, der ja in der sblupdate enthalten ist, sprechen dafür:

Image Verify, Start %s
Image Verification failed (%d)
No verified TZ in flash!!! Booting not possible!!!
No verified EVA in flash!!! Booting not possible!!!

), aber daß das KEINE kryptographischen Signaturen sind. Diese Annahme wird für mich dadurch gestützt, daß man im SBL (bzw. eben in sblupdate) zwar mehrfach Bezüge auf CRC finden kann:

vidar:/tmp $ strings sblupdate | grep -i crc
boot_images/core/services/utils/src/crc.c
boot_images/core/services/utils/src/crc.c
CRC page magic and version number mismatch 0x%08x.
[%s]CRCBLK found @ blk %d page 0x%x

, aber nicht einen Bezug auf sig oder ähnliches, was auf Signaturen hindeuten würde (und nein, assign hat nichts mit Signaturen zu tun).

In meiner (unbewiesenen und nur auf Schlußfolgerungen beruhenden) These sieht das bei diesen Boxen so aus, daß der PBL vom Hersteller stammt und der von AVM gar nicht angefaßt wird. Dieser lädt dann den SBL nach und der besteht (in meiner Vorstellung) aus dem originalen Code, in den AVM ein paar wenige, eigene Erweiterungen eingebaut hat. Der prüft zwar noch den Inhalt der Partition für die "TZ" (https://developer.arm.com/ip-products/security-ip/trustzone), aber die wird bei AVM gar nicht wirklich benutzt (so in etwa wie die Virtualisierung bei GRX-Chipsets, wo man auch mehr gezwungenermaßen nur den "bootcore" verwendet) und stattdessen wird tatsächlich (u.U. sogar mit kopiertem Original-Code) der AVM-eigene Loader-Code für EVA nachgeladen (der damit aus Sicht des Broadcomm-Codes praktisch schon "OS" ist) und der dann alles weitere übernimmt - entweder die Kommunikation im Netzwerk oder das Laden des FRITZ!OS-Kernels aus anderen NAND-Partitionen (auch das Vorhandensein mehrerer Firmware-Instanzen und die Auswahl über linux_fs_start bzw. deren Verwaltung ist ja ein EVA-Merkmal).

Irgendwo im Hinterkopf habe ich auch noch die Info, daß bei den IPQ-Boxen die Bootloader-Konfiguration (wo die Werte für die "Geburtsdaten" der Box stehen) gar nicht als integraler Bestandteil im Bootloader stehen (zumindest nicht so, wie bei den Boxen bis zum VR9, wo die an einem festen Offset in der Loader-Partition zu finden sind, was bei GRX-Boxen auch schon nicht mehr der Fall ist, weil die auch jeweils zwei Kopien haben), sondern irgendwo am Ende der Bootloader-Partition - das habe ich (vermutlich für die 4040) mal irgendwo bei OpenWRT gelesen, glaube ich zumindest.

Aber solange niemand einen Dump seines Bootloaders "einsendet" und man den ebenso auseinandernehmen kann, wie den der anderen Boxen (ich habe Puma6, VR9, GRX5 von den neueren Modellen, wo der Konfigurationsbereich in Version 3 vorliegt), bleibt das alles auch nur Spekulation - die Frage wäre es, wie langlebig diese Modelle/SoC in der AVM-Produktstrategie wären und nur mit diesem Wissen könnte man dann (fundiert) entscheiden, ob sich die Beschäftigung mit diesen SoC tatsächlich lohnt.

EDIT: OK, da ich das alles noch einmal geprüft habe beim Schreiben und auch die zitierten Stellen in den Code-Boxen erst noch erstellen mußte, hat das etwas länger gedauert und ein paar Fakten aus der "Präambel" wurden mittlerweile auch schon erwähnt - ich lasse das trotzdem so stehen.

 

[eisbaerin]

von tz als "trust zone"

Ah, danke.
Ich hatte mich schon gewundert was die da an der timezone ändern wollen.

 

[Wolle49]

Danke für die ganzen Infos!
Muss ich beim Kauf einer 7520 etwas besonderes beachten? Anscheinend sind mehrere Versionen im Umlauf (S0, GJ, EU, ZS, EX....)...

 

[Insti]

Die zwei Buchstaben hinter der 7520 sind nur dafür da um deine FB im Wlan zu unterscheiden wenn deine Nachbarn auch eine 7520 haben.

 

[koyaanisqatsi]

Moins


...und so heisst das WLAN (SSID) dann auch wieder, wenn Werkseinstellungen geladen oder eine AVM-Windows-Recovery.exe die Box in einen definierten Zustand versetzt.

 

[KunterBunter]

Anscheinend sind mehrere Versionen im Umlauf

Um genau zu sein: Es sind 676 verschiedene, von AA bis ZZ.

 

[eisbaerin]

Sicher, daß da AVM keine weg läßt, so wie z.B. bei der Seriennummer?

 

[Dann halt nicht mehr]

Ich würde wetten, das "II" .. also zwei groß "i" nicht stattfindet.

 

[j-g-s]

Ich hab eine 7520 zur 7530 aufgebohrt.

Erst Fritzbox Strom aus und ein-gesteckt.
Recovery von 7530 gestartet und abgepasst bis es fehlschlägt.
Dann ftp gestartet und Variablen geändert.
Dann Recovery erneut gestartet.
Dann Einstellungen zurück gespielt

Branding bleibt als 1&1, FW muss zukünftig per Datei uploaded werden.

Die 7530 ersetzt eine 7490 am DSL, das heißt die 7530 ist in der Garage direkt am Übergabepunkt.
Die 7490 bleibt wo sie ist und macht DECT und WLAN, der Standort ist besser und zentral.
Jetzt brauche ich das DSL Kabel nicht mehr verlängern, stattdessen liegt ein 1GB LAN Kabel zwischen den Boxen.

 

[j-g-s]

Man muss bemerken, wenn man an eine gemobte 7520 ein Fritz!Fon anschließt, zeigt diese ständig an das die FW aktualisiert werden muss.
07.27 -> 07.27
Die Oberfläche ist ja eine 7530, gesucht wird die FW im Verzeichnis der 7520.
Dann schlägt das Update fehl.

 

[PeterPawn]

eine gemobte 7520

Ich bin jedenfalls gegen Mobbing.

 

[Insti]

zeigt diese ständig an das die FW aktualisiert werden muss.
07.27 -> 07.27

[Sammlung] - Wie modifiziere ich die originale Firmware vom Hersteller und wie installiere ich meine eigene dann auf der FRITZ!Box?

Neuer Versuch ... da der Link auf den Raw-Content nicht vom Commit abhängt, ist es derselbe: https://raw.githubusercontent.com/PeterPawn/YourFritz/master/bootmanager/gui_bootmanager commit 0bb9744fe73df7394b7c5ece7acc81affcaeba8f (HEAD -> master, github/master, github/HEAD) Author: YourFritz...

www.ip-phone-forum.de

 

[j-g-s]

Ich hab mir die Beiträge durch gelesen.
Ich fasse zusammen: eine fertige FW gibt es nicht.
Man muss also die original FW bei AVM holen.
Die in einem Linuxsystem entpacken und
irgend wie ?? umbauen, dann wieder zusammen packen.
Würde man diese FW auf die Fritzbox bringen, dann hätte man eine Fehlermeldung wegen einer modifizierten FW.
Also muss man diese FW signieren und der Fritzbox einen anderen Schlüssel unter jubeln ??
Dann kann man die FW in das hoffentlich richtige Filesystem schieben ??

Hat das alles geklappt, dann hat man keinen Brick.
Wenn es schief geht, dann hat man einen Briefbeschwerer.

Zwischendurch steht noch wie man andere Fritzboxen verändert, so das man nicht weiß ob die Anweisungen zur 7520/30 gehören....




Dann ist noch die Frage muss man jede neue FW so verändern?





Oder man lebt damit das die F!B 7520/7530 im falschen FTP-Verzeichnis sucht und lädt die original FW händisch herunter und schiebt diese aufs Webinterface. Fertig

 

[treysis]

Es gibt eine fertig modifizierte Firmware. Die musst du einmal über die bekannten Methoden installieren. Wenn der Ersteller dieser Firmware dann Updates mit dem gleichen Schlüssel signiert, kannst du sie über das Webinterface einspielen. Die Fehlermeldung hast du mit dieser Firmware nicht mehr. Automatische Updates werden logischerweise nicht mehr funktionieren.

 

[NDiIPP]

Man muss also die original FW bei AVM holen.

Was anderes sollte man auch nicht machen...

Wenn es schief geht, dann hat man einen Briefbeschwerer.

So schnell nun auch wieder nicht. Zumindest wenn man nicht gerade "Dummfug" versucht, also bspw. den Bootloader überschreibt. Aber das ist eigentlich auch nicht Bestandteil der "richtigen" bzw. passenden Anleitung diesbzgl. (solange man bspw. keine alte Anleitung heranzieht die sich noch auf ältere Fritzbox-Modelle bezieht), weshlab der Fall mit dem Briefbeschwerer eigentlich nicht eintreten sollte, selbst wenn man versucht per Bootloader ein ungültiges Firmware-Image in den RAM hochzuladen.

Dann ist noch die Frage muss man jede neue FW so verändern?

Na ja, eigentlich muss man ja die FW der 7530 überhaupt nicht verändern um sie auf einer 7520 zu betreiben. Automatische Updatefunktion ist dann halt zu deaktivieren (ist ja auch im Falle der modifizierten FW zu deaktivieren, da ja auch dann die FW zuvor zu modifizieren bzw. alternativ "zu besorgen" wäre vor dem nächsten Update, sonst ist dann wieder die originale von AVM drauf). Wenn einem das zu viel ist jedes mal die FW anzupassen, ist das imo sowieso der bessere Weg. Ich würde da auch keine fertigen Images von dritten verwenden! Oder aber man verwendet einfach die originale 7520er-FW weiter, zumindest wenn man mit 2x Gigabit-Ethernet und USB 2.0 keine Probleme hat (was meistens der Fall ist).

 

[Micha0815]

Die in einem Linuxsystem entpacken und
irgend wie ?? umbauen, dann wieder zusammen packen.

Das habe ich mal als ewiger Beginner hier und drumherum beschrieben, was nicht auf grosse Gegenliebe stiess unter den grossen Jungz.

@Insti hat aktuell vereinfachend/zusammengefasst die scripte für die 7530(7520) und 7590 in dem thread zum wget`ten angeboten und aktuell gehalten.

http://force-unleashed.firewall-gateway.net:1973/osprey/7530.sh
bzw. als Befehl in der Ubuntu-Shell 
wget -O - -q http://force-unleashed.firewall-gateway.net:1973/osprey/7530.sh | bash

Anmerkung: mit 7590 als Argument klappt es auch

Zufuss kannst Du einzelne Steps des scripts auch auslassen ... aber wie in #237 angedeutet, kannst Du mit dem Key auch via GUI updaten, wenn Du beim nächsten Release das script dann nochmals durchlaufen lässt.

Beim ersten Mal musst Du halt nolensvolens die Powershell-Scripte von PeterPawn zum flashen nutzen, was nach einem Update der Powershellversion unter W10 und dem Anhalten der FB -ich nutze da immer eine falsche recovery, da ich mit den aneinanergeketteten PS-Scripten nie zurechtkam- mit etwas Übung recht einfach klappt, wobei -wie erwähnt- nix grossartig falsch laufen kann.

Eine kleine, gerne verschwiegene Nicklichkeit bedeutet mit dem W10-Explorer die tief versteckte 75xxin-memory.image-Datei im Ubuntu-Gastsystem aufzustöbern und an prominentere wiederauffindbare Stelle zu kopieren -usb-Stick ein guter Platz -
LG und nur Mut
OT: Und allemalbesser, als sich ein fertiges in-memory aus dem verpönten D**-Forum zu besorgen. Ein ähnliches Ergebnis kann man mutmasslich auch mit freetz-NG und dem Nofreetzmodus sich erarbeiten, sofern das NG so aktuell unterstützt.

 

[treysis]

OT: Und allemalbesser, als sich ein fertiges in-memory aus dem verpönten D**-Forum zu besorgen. Ein ähnliches

Wer sich das Leben gerne schwer macht, baut sich alles selbst, ja. Ich sehe keinen Grund, da Bauchschmerzen zu haben.