[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

Code:
commit 0bb9744fe73df7394b7c5ece7acc81affcaeba8f (HEAD -> master, github/master, github/HEAD)
Author: YourFritz <[email protected]>
Date:   Wed May 27 20:28:46 2020 +0200

    gui_bootmanager: add support for IPQ4019 - update 1

diff --git a/bootmanager/gui_bootmanager b/bootmanager/gui_bootmanager
index c03805d..cee3dba 100755
--- a/bootmanager/gui_bootmanager
+++ b/bootmanager/gui_bootmanager
@@ -295,7 +295,7 @@ get_partition()
        if [ "$st" = "VR9" ] || [ "$st" = "AR10" ]; then
            [ "$1" = "$kernel_name" ] && get_mtd_partition "$1" "$2" || get_vr9_image "$1" "$2"
            rc=$?
-       elif [ "$st" = "GRX500" ] || [ "$st" = "GRX350" ]; then
+       elif [ "$st" = "GRX500" ] || [ "$st" = "GRX350" ] || [ "$st" = "IPQ4019" ]; then
            get_mtd_partition "$1" "$2"
            rc=$?
        else
Schön blöd ... da habe ich mir schon die Stelle mit den geringsten notwendigen Änderungen rausgesucht (das war dann direkt in "get_system_type") und dann vergesse ich, die Abfrage auf den neuen Typen auch noch einzubauen.
 
Das sieht sehr gut aus:
Code:
7520:/var/mod/root# gui_bootmanager4 debug
system type = IPQ4019
system selector = 1
system is switched = false
system branding = avm
system branding is changeable = false
active kernel = /dev/mtdblock3
active filesystem = /dev/mtdblock6
active system version = 164.07.14
active system date = 08.11.2019, 05:46:33 Uhr
active system modification date = 09.02.2020, 01:58:07 Uhr
active system modification source = Freetz
brandings supported on active system = 1und1 avm
inactive kernel = /dev/mtdblock0
inactive system is installed = true
inactive filesystem = /dev/mtdblock5
inactive filesystem mounted on /var/tmp/5349_1590604868/alt_root
inactive system version = 164.07.19-78653
inactive system date = 15.05.2020, 04:51:55 Uhr
inactive system modification date = 25.05.2020, 05:30:00 Uhr
inactive system modification source = -
brandings supported on inactive system = avm (fixed)
inactive filesystem dismounted

Und auch in der GUI wird es angezeigt und die Umschaltung klappt auch. DANKE!
Dann sollte es ja jetzt auch bald mit freetz klappen.

Nach Umschaltung:
Code:
7520+10:$(pwd)# gui_bootmanager4 debug
system type = IPQ4019
system selector = 0
system is switched = false
system branding = avm
system branding is changeable = false
active kernel = /dev/mtdblock0
active filesystem = /dev/mtdblock5
active system version = 164.07.19-78653
active system date = 15.05.2020, 04:51:55 Uhr
active system modification date = 25.05.2020, 05:30:00 Uhr
active system modification source = -
brandings supported on active system = avm (fixed)
inactive kernel = /dev/mtdblock3
inactive system is installed = true
inactive filesystem = /dev/mtdblock6
inactive filesystem mounted on /var/tmp/2058_1590606036/alt_root
inactive system version = 164.07.14
inactive system date = 08.11.2019, 05:46:33 Uhr
inactive system modification date = 09.02.2020, 01:58:07 Uhr
inactive system modification source = Freetz
brandings supported on inactive system = 1und1 avm
inactive filesystem dismounted


Das Branding läßt sich aber nicht ändern?
 
Zuletzt bearbeitet:
Ich gehe mal davon aus, daß die persistente Änderung auch hier nicht möglich ist ... zumindest habe ich das alles bisher so verstanden (in der c't und auch hier im Board).

Im Moment mache ich das an der Existenz eines FDT fest ... die Modelle mit einem solchen können m.W. alle keine persistenten Änderungen über "/proc/sys/urlader/environment -> firmware_version" mehr vornehmen. Wenn aber eines der installierten Systeme mit festem Branding gebaut ist (wie bei Dir offenbar das inaktive), wird das erkannt und (hoffentlich richtig) angezeigt. Ich habe jetzt auch mal in das "run_modscripts" noch eine ".modfs_version" eingebaut - war zwar nur ein Beispiel, aber wenn ich schon "gui_bootmanager" als "modscript" zeigen will, sollte das auch die passenden Dateien für die Anzeige bei "modification source" finden können.

Wenn's jetzt paßt, bedanke ich mich für's Testen und mache das mal als Update insgesamt fertig.
 
  • Like
Reaktionen: Insti
Zuletzt bearbeitet:
  • Like
Reaktionen: Insti
Natürlich mit geänderter rc.conf, damit es wirken kann.
Der Boot-Manager kann aber nicht mehr die "rc.conf" ändern und da die ja seit geraumer Zeit "vernünftig" filtert (das hat auch lange genug gebraucht, bis das zur Lösung mit einer Whitelist wurde), funktioniert das "out of the box" nicht länger (die Filterung auf "CONFIG_irgendwas", die das für OEM auch schon verhinderte, ist noch viel länger schon vorhanden).

Da man dem inaktiven System auch nicht ansieht, ob es nun eine geänderte "rc.conf" hat oder nicht (und dafür gibt es - anders als bei OEM, wo von Beginn an die Änderung des "export OEM" empfohlen wurde von mir - auch keinen "Standard"), wüßte ich jetzt nicht, wo und wie ich das ändern sollte.

Das ist halt nicht Aufgabe des Boot-Managers - wenn man ein festes Branding haben will (ein Wunschkonzert ist es ja ohnehin nicht, weil die passenden Verzeichnisstrukturen vorhanden sein müssen), muß man eben die "rc.conf" ändern (das macht ja auch "mod_fixed_branding" und man kann ja auch ein anderes als "avm" einstellen lassen) und kann dann ganz nebenbei noch das Auslesen von "HWRevision" ändern und sogar den gewünschten Wert noch einmal selbst "schreiben" - der wird nämlich (anders als "firmware_version", was dann in der OEM-Variablen landet und später praktisch immer von dort gelesen wird) noch an anderen Stellen ausgelesen und da bietet es sich an, den bereits beim Start noch einmal zu "setzen", bevor ihn der Bootloader beim nächsten Neustart wieder "gerade rückt".

Das richtet sich jetzt auch an @Insti ... natürlich hat das FTP-Kommando "SETENV" in der "rc.conf" eines FRITZ!OS nichts zu suchen. Da muß man sich die Stelle heraussuchen, wo das ausgelesen wird und die dann so abändern, daß nicht der ausgelesene, sondern ein fester Wert verwendet wird - und den schreibt man dann am besten auch gleich noch einmal ins Urlader-Environment. Das ist dann zwar bei jedem Start ein Schreibzugriff, aber das sieht AVM mit der "userstat.cfg" mittlerweile auch nicht mehr so eng, die wird noch viel öfter geschrieben (und ist viel größer). Üblicherweise wird es irgendwo ein Statement "export HWRevision" geben und wenn man das gleich so ändert, daß da noch ein fester Wert zugewiesen wird, braucht man den nur noch zusätzlich ins Urlader-Environment schreiben lassen - ein Beispiel, wie das geht, findet man in der "S01-head" beim Setzen von "firmware_info".

Da der Rest der Daten (bis hin zu "CONFIG_PRODUKT_NAME" mit dem Namen des Modells) ohnehin aus der Firmware kommt und nicht vom Gerät, sollten mit solchen Änderungen schon viele der internen Funktionen davon ausgehen, daß es sich tatsächlich um eine 7530 handelt - bis hin zur automatischen Update-Suche und dem Inhalt der "juis_boxinfo.xml". Allerdings weiß ich nicht, ob tatsächlich auch alles andere dann reibungslos funktioniert - wobei die Tatsache, daß es auch ohne die Änderung der "HWRevision" so la-la klappt (außer eben die Online-Funktionen bei AVM, die i.d.R. auf dieser Nummer aufbauen), eigentlich ein Zeichen dafür ist, daß da wenig Probleme zu erwarten wären.
 
  • Like
Reaktionen: Insti
Danke Peter für den neuen Bootmanager! Tolle Arbeit! Werde es Morgen früh gleich auf meiner zweiten 7520 flashen.
Flash-Speicher und einfach ein "cat > /dev/mtd[block]<something>" funktioniert nur, wenn der zuvor gelöscht wurd
habe das nach mtdblock1 geschrieben und dann auch geprüft und nochmal gesichert. Es war in mtd1, mtd1ro und mtdblock1 schon alles richtig. Nächste Woche habe ich Kurzarbeit und werde mal das Gehäuse öffnen und schauen wo der ttl converter angeschlossen wird.
 
Bei der 4040 habe ich gerade erst (irgendwo hier) gelesen, daß der CONFIG-Bereich (da stehen ja dann die Variablen drin) nicht länger an 0x580 im Loader liegt, sondern irgendwo weiter am Ende ... außerdem scheint AVM hier tatsächlich den Loader irgendwie kryptographisch zu sichern (was sollte das "tz_update" sonst machen) und daher glaube ich nicht, daß Änderungen so ohne weiteres möglich sind. Wenn Du den alten Inhalt 1:1 wieder in die Partition schreibst (die startet ja auch nicht bei 0x0, da liegt vermutlich auch bei der 7520/7530 eine Partition namens "SBL", oder?), könntest Du Glück haben, wenn das wirklich in derselben Partition signiert wird und diese Signaturen nicht irgendwo gesondert gelagert werden (wobei auch das noch klappen sollte, solange die Signatur weiterhin paßt, selbst wenn sie irgendwo anders gespeichert ist).
 
  • Like
Reaktionen: Insti
Sollte die abgeschossene 7520 wieder funktionieren mit der gesicherten original mtd1, dann würde ich es nochmal probieren mit der mtd1 unserer weiß/roten7530 die am APL hängt. Es müsste dann eigentlich nur die MAC in der mtd1 geändert werden?
Danke Peter für den neuen Bootmanager! Tolle Arbeit! Werde es Morgen früh gleich auf meiner zweiten 7520 flashen.
Bootmanager sieht sehr gut aus. Vielen Dank @PeterPawn
 

Anhänge

  • 7520to7530.JPG
    7520to7530.JPG
    103.6 KB · Aufrufe: 35
Zuletzt bearbeitet:
Durch Eintragung der HWRevision der 7530 in der /etc/init.d/rc.config wird bei der 7520 kein Update mehr angezeigt.
Code:
##########################################################################################
## exporting ...
##########################################################################################
ETC_CONFIG_PATH=/etc/init.d/rc.init
export HWRevision=236
export HWSubRevision=1
export SerialNumber
export Country
export Language
export ETC_CONFIG_PATH
export CONFIG_ENVIRONMENT_PATH
##########################################################################################
 

Anhänge

  • 7530HW.JPG
    7530HW.JPG
    54.6 KB · Aufrufe: 55
  • 7530HW2.JPG
    7530HW2.JPG
    46.1 KB · Aufrufe: 56
Zuletzt bearbeitet:
Und warum setzt du auch "HWSubRevision" auf 1?
 
Die 7530 hat im Environment HWSubRevision=1 die 7520 hat HWSubRevision=2. Für die Update URL wird das (so wie ich das verstehe) benötigt.
Code:
EXTERNAL_BOX_PARAMS="hardware=${HWRevision}&oem=${OEM}&language=${Language}&country=${Country}&version=${CONFIG_VERSION_MAJOR}.${CONFIG_VERSION}&subversion=${CONFIG_SUBVERSION##*-}"
 
Wo steht in deinem Code etwas von HWSubRevision ?
 
Habe ja geschrieben "so wie ich das verstehe" wegen:
Code:
&subversion=${CONFIG_SUBVERSION##*-}"
wenn sich das auf etwas anderes bezieht mag sein.
 
CONFIG_SUBVERSION != HWSubRevision
 
Für die Update URL wird das (so wie ich das verstehe) benötigt.
Das wird für die Update-URL nicht benötigt. Und selbst wenn, warum sollte es keine 7530 mit HWSubRevision=2 geben bzw. sollte es mal geben? Also selbst wenn das verwendet werden würde, sehe ich da noch keinen Grund den Wert dieser Variable zu verändern.
 
Ja gut, sehe auch keinen Grund den Wert nicht zu ändern wenn der geändert werden kann und von der originalen 7530 bekannt ist. Hat anscheinend kein Vor - und kein Nachteil bis jetzt.
 
So arglos würde ich das nicht ohne weiteres sehen. Bei einigen Modellen wurde die HWSubRev bspw. bei PCB-Layout bzw. Hardware-Änderungen ggf. angepasst. Bei der 7580 wird meiner Erinnerung nach bspw. bei neueren FRITZ!OS-Versionen auf einer älteren HWSubRev. der 7580 ein Patch/Workaround bzgl. WLAN angewendet (weil bei der ersten HWSubRev. der 7580 noch eine ältere Rev. des entspr. WiSoC verbaut wurde) um ein Problem zu lösen. Bei den neueren Rev. des WiSoC ist dieser Patch jedoch unnötig, weshalb er bei einer entsprechend höheren HWSubRev auch nicht angewendet wird (da er ggf. auch kontraproduktiv sein kann).

Kurzum, den Wert der Variable HWSubRevision würde ich nur ändern, wenn man weiß was man da tut (also ggf. recherchiert welchen Einfluss bei der verwendeten Firmware die HWSubRevision haben kann) und damit auch ein bestimmtes/bekanntes Problem oder Verhalten lösen kann.

---

Edit/BTW #1:
... und von der originalen 7530 bekannt ist.
Weißt du wirklich, dass der Wert bei allen 7530ern =1 ist bzw. auch bei zukünftigen 7530ern bei 1 bleiben wird? Vielen Modellen wurde im Laufe der Zeit, bspw. bei PCB-Layout Änderungen und/oder anderen Bauteilen, bei Bedarf auch eine neue HWSubRevision verpasst, welche ggf. auch von der Firmware berücksichtigt wird um bspw. bestimmte Aktionen/Patches durchzuführen/anzuwenden oder eben nicht (siehe Beispiel oben). Bei der 7490 gibt es bspw. die HWSubRevisionen 1, 3, 4, 5, 6 oder 7 (und vielleicht auch 2 und mittlerweile vielleicht auch 8).

Und vom 7520/7530er PCB gibt es m.W.n. bisher mindestens 4 verschiedene PCB-Layouts/Bauteilebestückungen... Da würde ich mir schon gut überlegen, ob man da unbegründet/ohne Not einfach so mal die HWSubRevision ändert. Nur etwas zu ändern weil es geht kann ja eigentlich keine brauchbare Begründung sein, wenn man nicht weiß, was man damit wirklich bewirkt.

---

Edit #2:
Wenn man solche Änderungen an Werten vornimmt und das hier zeigt (insb. ohne diese näher zu Beschreiben/zu Begründen) machen das in Zukunft evtl. auch andere Leute nach, nur weil es hier so als Beipsiel steht. Das mag derzeit vielleicht noch keine (ernsthaften) Folgen haben aber wer weiß schon, ob in Zukunft bei der 7520/7530 noch HWSubRevisionen wie 3, 4 usw. auftauchen mit entsprechender Behandlung in den (zukünftigen) FRITZ!OS Versionen. Dann könnte der Schuss irgendwann einmal auch nach hinten losgehen und das für eine Änderung, die (zumindest derzeit) eigentlich gar nicht notwendig ist...
 
Zuletzt bearbeitet:
Dann könnte der Schuss irgendwann einmal auch nach hinten losgehen und das für eine Änderung, die (zumindest derzeit) eigentlich gar nicht notwendig ist...
Denke nicht das die User die das so eingetragen haben irgendwelche Hemmungen haben die Firmware nochmals flashen zu müssen weil etwas nicht passt. Du doch auch nicht @NDiIPP ?

Mein nächster Test wird sein:
Code:
export tr069_passphrase=1234567890Fc
export tr069_serial=00040E-#maca
export ProductID=Fritz_Box_HW236
und dann mal schauen ob die sich von alleine am Telekom Anschluß konfiguriert.
 
Denke nicht das die User die das so eingetragen haben irgendwelche Hemmungen haben die Firmware nochmals flashen zu müssen weil etwas nicht passt.
Das mag wohl sein. Aber das ist doch hoffentlich keine Begründung dafür bestimmte Werte zu ändern ohne zu wissen was man damit bewirkt. Ich bin nach wie vor der Ansicht nur das zu ändern wovon ich mir auch einen Vorteil verspreche/erhoffe.

---

Edit:
Die CWMP-Account Variablen (sofern bei 1und1-Modellen nicht vorhanden) sollten sich imo im Environment nachträglich eintragen lassen (bspw. per Bootloader, selbst erstelltem neuen TFFS-Image oder Konsolenzugriff), dann bräuchte es dazu keine dahingehend modifizierte Firmware. Man sollte aber bedenken, dass die Passphrase-Variable für den CWMP-Account meiner Erinnerung nach für die Verschlüsselung der Konfiguration der Box verwendet wird. Also nach Eintragung im Environment kann die Box die verschlüsselten Werte ihrer eigenen Konfiguration nicht mehr entschlüsseln. Also anschließend ggf. auf Werkseinstellungen zurücksetzen.
 
Zuletzt bearbeitet:
mal schauen ob die sich von alleine am Telekom Anschluß konfiguriert.
Das könnte klappen - aber eben nur bei drei Modellen:
Code:
NAME=Telekom$EMPFOHLEN: Automatische Einrichtung des Internetzugangs, der Telefonie und weiterer EasySupport Dienste der Telekom Deutschland GmbH (weitere Infos unter www.telekom.de/easysupport)
{
ID=telekom_tr069;BOX=7490;
ID=telekom_tr069;BOX=7590;
ID=telekom_tr069;BOX=7530;
}
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,347
Beiträge
2,250,583
Mitglieder
374,001
Neuestes Mitglied
curious2315
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.