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

Du hast einfach 3 neue unbekannte Variable definiert, die IMO nirgends abgefragt werden.
Das muss schon etwas bewirkt haben auch wenn du meinst das es unbekannte Variable sind. Habe in myfritz.net als Bild die 7530 und ohne Änderung das Icon (schwarzes Gehäuse) der 7520 UI.
Du kannst ja mal Die Daten Deiner 7520 mit denen von mir vergleichen


Code:
<e:BoxInfo xmlns:e="http://juis.avm.de/updateinfo" xmlns:q="http://juis.avm.de/request">
<q:Name>FRITZ!Box 7530</q:Name>
<q:HW>236</q:HW>
<q:Major>164</q:Major>
<q:Minor>7</q:Minor>
<q:Patch>14</q:Patch>
<q:Buildnumber>73183</q:Buildnumber>
<q:Buildtype>1</q:Buildtype>
<q:Serial>98*********22D</q:Serial>
<q:OEM>avm</q:OEM>
<q:Lang>de</q:Lang>
<q:Country>049</q:Country>
<q:Annex>B</q:Annex>
<q:Flag>crashreport</q:Flag>
<q:Flag>prov_acs</q:Flag>
<q:Flag>avm_acs</q:Flag>
<q:Flag>mesh_master</q:Flag>
<q:UpdateConfig>1</q:UpdateConfig>
<q:Provider>telekom_tr069</q:Provider>
<q:ProviderName>Telekom</q:ProviderName>
</e:BoxInfo>
 
Ich antworte mal für NDiIPP:
Werde die Finger vom Bootloader lassen.
Nö, das ist nicht nötig, der bootloader schützt sich schon selbst, aber vom mtd und speziell mtd1 solltest du sie lassen.

Habe meine Lektion gelernt
IMO aber nicht die richtigen Schlußfolgerungen daraus gezogen.


Du kannst ja mal Die Daten Deiner 7520 mit denen von mir vergleichen
Ja, mache ich später mal. z.Z. habe ich die FW von der 7520 drauf.
Aber deine Variablen gibt es auf einer normalen FB (auch mit CWMP-Account) nicht.
Du kannst ja mal folgendes testen:
Code:
echo $tr069_passphrase
echo $tr069_serial
echo $ProductID
Bei einer normalen FB bekomme ich da keine Antworen.
 
Zuletzt bearbeitet:
Werde die Finger vom Bootloader lassen.
Der Bootloader wird dabei doch überhaupt nicht angefasst. Die Environment-Variablen werden dabei im TFFS abgelegt/gespeichert sowie jede Menge anderer Einstellungen auch, die zwangsweise dort gespeichert werden.
 
Zuletzt bearbeitet:
Bei einer normalen FB bekomme ich da keine Antworen.
Dann habe ich keine normale
Code:
root@ubuntu ~ > telnet 192.168.1.1
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
password:


BusyBox v1.24.2 (2019-02-11 19:34:24 CET) built-in shell (ash)

ermittle die aktuelle TTY
tty is "/dev/pts/0"
Console Ausgaben auf dieses Terminal umgelenkt
disable start/stop characters and flowcontrol
# echo $tr069_passphrase
1234567890Fc
# echo $tr069_serial
00040E-989******2D
# echo $ProductID
Fritz_Box_HW236
#

Das ist die Ausgabe meiner 7520.
 
Ja, weil du diese Variablen ja nun in deiner Firmware definiert hast. Aber bei anderen Fritzboxen (auch mit CWMP-Account) bekommt man da keine Antwort. Auch nicht für die Variable "ProductID".
 
Nein, nur nutzlos.
 
Für mich nicht. Ohne diese Änderungen funktioniert kein Easy Support bei der Telekom und in myfritz.net wird nicht die 7530 dargestellt.
 
Meiner Ansicht nach sind das bisher nur die Folgen von "export HWRevision=236"

Ich konnte jedenfalls im Filesystem der Firmware im Klartext keine Stellen finden wo diese Variablen verwendet werden (dem Script zum Erstellen der Support-Daten mal abgesehen). Wenn dann müsste entweder der Kernel oder eines der Binarys die Werte noch einmal direkt aus dem Environment auslesen.
 
EDIT: Abgesehen davon kann man sich natürlich auch seine Images selbst signieren, wenn man den eigenen öffentlichen Schlüssel in der laufenden Firmware hat (wenn nicht, kann man den trotzdem "aktivieren" und wie das geht, habe ich hier: https://github.com/PeterPawn/YourFritz/blob/master/framework/implant_public_key mal gezeigt bzw. in verschiedenen Varianten implementiert).
Habe das Script mal ausführen wollen, bekomme aber eine Fehlermeldung:
Code:
# cd /tmp
# vi implant.sh # RAW kopiert und eingefügt
# chmod 755 /tmp/implant.sh
# ./implant.sh
Missing 'mode' parameter and any modulus value(s).
#
Was mach ich falsch?

Dann ist das ein Placebo-Effekt.
Poste mal deine juis_boxinfo.xml dann sieht man ja ob es nur Placebo Effekt ist.
 
Was mach ich falsch?
Wie der Aufruf erfolgen muß, steht ja im "Kopf" der Datei.

Abgesehen davon, sollte man sich zuvor mit dem Signieren generell vertraut machen - dazu gehört mind. das Verständnis, was die Skript-Dateien aus "YourFritz/signimage" machen und wo man den eigenen öffentlichen Schlüssel in die Modifikationen einbauen muß ... iirc hatte ich bei meinem Beispiel für die 7530 sogar den YourFritz-Key mit einbauen lassen.

Wobei der natürlich nur als Beispiel dienen kann/soll, denn dessen privater Schlüssel befindet sich bei mir (unter sicherem Verschluß) und soll irgendwann mal zum Signieren von "Zusatzpaketen" dienen (wie man es z.B. hier schon sehen kann: https://github.com/PeterPawn/yf_bin/blob/master/scripts/create_YourFritz_base_image - das kann man auch als Beispiel, wie man selbst signiert, lesen). Aber man kann eben seinen eigenen öffentlichen Schlüssel nach demselben Prinzip in die eigenen Images integrieren (lassen) und dann braucht man das "implant_public_key" nur noch dann, wenn die laufende Firmware den Key (aus welchem Grund auch immer) nicht enthält.

Du bewegst Dich derzeit ohnehin in noch nicht komplett "erkundeten" (bzw. implementierten, denn "erkundet" ist hier nur ein Kunstgriff, um auf "where no man has gone before" zu kommen) Regionen der Firmware, wo Du Prinzipien selbst erkennen mußt anhand von Beispielen und nicht mehr davon ausgehen kannst, daß nur noch ein Aufruf irgendeines fertigen Skripts/Programms erforderlich wäre. Die Teile sind zwar (überwiegend) vorhanden (erinnert etwas an Lego), man muß sie nun "nur noch" passend zusammensetzen - was allerdings auch "Arbeit" ist, sonst hätte ich das längst schon alles fertig.

Und am Ende grätscht dann immer mal wieder AVM mit ein paar Änderungen dazwischen und bremst den Elan dadurch wieder aus, weil man dann lieber erst mal abwartet, was sich in der nächsten Version noch alles ändert, bevor man Zeit in Sachen investiert, die sich absehbar noch einmal ändern müssen.

Das geht bei der 07.19 jetzt seit August 2019 so (iirc) ... und hier hat AVM noch im Januar 2020 dann tatsächlich soo heftige Änderungen vorgenommen, daß sich - mitten in einer Labor-Reihe, zumindest dem Gefühl nach - noch jede Menge weiterer Veränderungen ergaben und so wartet man (ich) inzwischen sogar mit zunehmender Ungeduld, ob nicht bald mal der "Feature-Freeze" (nicht mit Freetz-Feature zu verwechseln, auch wenn meine Finger automatisch diese Buchstaben drücken wollen auf der Tastatur) für die 07.19 erkennbar wird und eine erste 07.20 "das Licht der Welt erblickt".

Mir ist auch erst jetzt aufgefallen, daß AVM den Teil, wo man "annex=<A|B>" noch in "kernel_args" angeben konnte, mittlerweile "ausgebaut" hat (eigentlich ist nur die "S01-head", wo das ausgelesen wurde nach "annex_param", entfallen in der 07.19 seit Mitte Januar 2020) und damit diejenigen, die bisher über diesen Parameter eine "deutsche" Box ("avm" oder "1und1") mit Annex A betrieben haben (die Diskussion, ob/wann eigentlich Annex J verwendet würde, schenken wir uns hier), nach einem Update auf 07.20 wohl den Annex unter den DSL-Einstellungen noch einmal neu setzen müssen - seit der "Zusammenfassung" der deutschen und der internationalen Versionen wird auch bei "avm" das "CONFIG_DSL_MULTI_ANNEX" ja nicht länger auf "n" gesetzt und damit funktioniert das mit der Auswahl (was der Patch "mod_multi_annex" zuvor noch "zu Fuß" machen mußte) jetzt auch bei einem "deutschen" Branding.
 
  • Like
Reaktionen: Insti
Poste mal deine juis_boxinfo.xml dann sieht man ja ob es nur Placebo Effekt ist.
Ja, hier ist der Beweis:
Ich habe deine 3 Variablen verankert, als Beweis:
Code:
7520+10:$(pwd)# echo $tr069_passphrase
1234567890Fc
7520+10:$(pwd)# echo $tr069_serial
00040E-1234567890AB
7520+10:$(pwd)# echo $ProductID
Fritz_Box_HW236
Und hier ist juis_boxinfo der 7520er FW:
Code:
<e:BoxInfo>
<q:Name>FRITZ!Box 7520</q:Name>
<q:HW>247</q:HW>
<q:Major>175</q:Major>
<q:Minor>7</q:Minor>
<q:Patch>19</q:Patch>
<q:Buildnumber>79182</q:Buildnumber>
<q:Buildtype>1000</q:Buildtype>
<q:Serial>1234567890AB</q:Serial>
<q:OEM>avm</q:OEM>
<q:Lang>de</q:Lang>
<q:Country>049</q:Country>
<q:Annex>B</q:Annex>
<q:Flag>medium_lan</q:Flag>
<q:Flag>mesh_master_no_trusted</q:Flag>
<q:UpdateConfig>3</q:UpdateConfig>
<q:Provider/>
<q:ProviderName/>
</e:BoxInfo>
Da hat sich also 0,nix gegenüber der originalen Version geändert!
 
Zuletzt bearbeitet:
Vielleicht reden wir aneinander vorbei.
Du kannst damit kein Easy Support einstellen, es fehlt tr69 das notwendig ist. Aber ist auch egal soll jeder das so machen wie er will. Wenn es für euch Placebo oder unnötig ist dann schreibt das nicht rein, ich schreibe es rein weil nur so das bei mir funktioniert.
Edit:
Ich habe deine 3 Variablen verankert, als Beweis:
Logisch das das im ausgepacktem Image in der rc.conf geschrieben wird - dannach einpacken und die Fritzbox flashen. Dann würde das bei dir auch anders aussehen.
 
Zuletzt bearbeitet:
Ich glaube schon, daß Du Dich da etwas verrannt hast ... entscheidend für den CMWP-Account ist die Angabe im Urlader-Environment und nichts in irgendeinem Shell-Environment.

Diese Angaben ("tr069_serial" und "tr069_passphrase") werden in der "libtr069.so" (unter "/usr/share/ctlmgr" zu finden) ausgelesen und - afaik - auch nur zum erstmaligen "Befüllen" der "tr069.cfg" verwendet (wenn das überhaupt noch geschieht in aktuellen Versionen). Dazu müssen die Werte aber eben auch im Urlader-Environment stehen und eigentlich passiert auch genau gar nichts, wenn es sie nicht gibt ... dann bleiben die Angaben in der "tr069.cfg" eben leer.

Entscheidend für den EasySupport ist am Ende die "tr069.cfg" in der Datei "provider-049.tar" und dort im Unterverzeichnis "telekom_tr069" - die läßt sich auch nur bei drei Modellen (7490, 7590, 7530) im GUI auswählen als Provider (das steht dann wieder in der "providermap.txt" im erwähnten TAR-File "providers-049.tar"). Dort werden dann in der "tr069.cfg" die Festlegungen getroffen, welches Client-Zertifikat zu verwenden ist (m.W. ist die Telekom bisher der einzige Provider, der bei CPEs ein Zertifikat erwartet):
Code:
tr069cfg {
        enabled = yes;
        igd {
           DeviceInfo {
              ProvisioningCode = "000.000.000.000";
           }
           managementserver {
              url = "https://acs.t-online.de/acs-v2/";
              username = "";
              password = "";
              URLAlreadyContacted = no;
              SessionTerminationWithEmptyPost = yes;
              ConnectionRequestUsername = "acs.t-online.de";
              ConnectionRequestPassword = "0f5bc0a4bb5a85990872214f29e15bb1";
           }
        }
        FirmwareDownload {
           enabled = yes;
           enabled_converted = yes;
           upload_enabled = no;
        }
        ACS_SSL {
           own_cert_file = "/etc/default/avm/tr069-default-iad-fritzchen.telekom.de.pem";
           verify_server = yes;
           trusted_ca_file = "/etc/default/avm/root_ca.pem";
        }
        Download_SSL {
           own_cert_file = "/etc/default/avm/tr069-default-iad-fritzchen.telekom.de.pem";
           verify_server = yes;
           trusted_ca_file = "/etc/default/avm/root_ca.pem";
        }
}
und wenn das dann auch noch existiert (was nicht in allen Firmware-Versionen der Fall ist, aber in deutlich mehr als denen für diese drei Modelle), dann sollte auch der EasySupport funktionieren.

Immerhin funktioniert TR-069 bei 1&1 auch für die 7520 ... und das auch dann, wenn die Box keinen CMWP-Account mitbekommen hat bei der Finalisierung. Ich würde also auch annehmen, daß Du da einem Irrtum bei der Beobachtung aufgesessen bist (die "export"-Statements bringen tatsächlich nichts - zumindest nicht für dieses Problem) und es der Änderungen beim CWMP-Account gar nicht bedarf, damit auch EasySupport funktioniert. Und wenn die tatsächlich notwendig sein sollten (was mich echt verwundern würde), dann eben eher als Variablen im Urlader-Environment und nicht im (Shell-)Environment irgendwelcher Linux-Prozesse, wo sie dank des "export" ja landen.

=====================================================================

Wobei TR-069 ohnehin Ähnlichkeiten mit einer eitrigen Wunde hat im FRITZ!OS ... das ist längst nicht alles sauber implementiert und vieles ist auch "historisch gewachsen". Das geht dabei schon los, daß direkt in der bereits erwähnten "libtr069.so" mehrere Subnetze (mit öffentlichen Adressen) von Vodafone hinterlegt sind, vermutlich sind das die, wo sich die ACS von Vodafone befinden können oder wo sie früher mal lagen und von wo dann "connection requests" des ACS kommen dürfen, wenn man den Angaben im Profil "vodafone_bytr069_ftth" glauben will.

Zumindest lagen bisher auch alle Antworten, die ich bei einer Abfrage von "acsaka.arcor-ip.de" (das ist der Name eines ACS bei VF, wie man in den Profilen "vodafone_bytr069*" sieht, selbst beim Glasfaser-Anschluß) erhielt, in einem dieser Netzsegmente. Die Tatsache, daß die noch einmal "hart kodiert" in der Library liegen (egal, ob es sich um die deutsche oder internationale Firmware handelt) und nicht nur in den entsprechenden Konfigurationsdateien, ist es am Ende auch, auf die sich meine Behauptung mit der "schwärenden Wunde" stützt, die auch bei der Einführung von ARGO (das TR-069-Geraffel dafür läuft über dieselben Wege wie für die Provider) nicht wirklich "aufgeräumt" wurde (und "system_no_sh" anstelle von "system" ist für mich noch kein Aufräumen) - bis hin zu immer noch vorhandenen, "festverdrahteten" Profil-Namen in der "libtr069.so".
 
  • Like
Reaktionen: eisbaerin
Logisch das das im ausgepacktem Image in der rc.conf geschrieben wird - dannach einpacken und die Fritzbox flashen. Dann würde das bei dir auch anders aussehen.
Ich mache es anders über die featovl.cfg, kommt aber auf das selbe hinnaus.
Und nein, es würde dann auch nicht anders aussehen.
 
Und nein, es würde dann auch nicht anders aussehen.
Es würde so ausehen wie bei mir in #208
Und nein ich fälsche keine Daten.
Ich habe das so gemacht:
Script von PeterPawn ausgeführt:
Code:
mkdir /tmp/7530
cd /tmp/7530
wget -q -O avm.tar http://ftp.avm.de/fritzbox/fritzbox-7530/deutschland/fritz.os/FRITZ.Box_7530-07.14.image
tar -x -f avm.tar -O ./var/tmp/kernel.image >kernel
dd of=kernel.bin if=kernel bs=8 count=$(( ( $(stat -c %s kernel) / 8 ) - 1 )) 2>/dev/null
rm kernel
tar -x -f avm.tar -O ./var/tmp/filesystem.image >fs.sqfs
git clone --recurse-submodules https://github.com/PeterPawn/YourFritz.git
git clone --recurse-submodules https://github.com/PeterPawn/modfs.git
sudo YourFritz/bin/squashfs/x86_64/unsquashfs4-le -no-progress fs.sqfs
sudo chown -R toni:users squashfs-root/
rm fs.sqfs
mv modfs/modscripts/ modfs/modscripts.org
mkdir modfs/modscripts
cp modfs/modscripts.org/gui_boot_manager_v0.6 modfs/modscripts/
cp modfs/modscripts.org/mod_enable_calllog modfs/modscripts/
cp modfs/modscripts.org/mod_fixed_branding modfs/modscripts/
cp modfs/modscripts.org/mod_telnet_enable modfs/modscripts/
cp modfs/modscripts.org/mod_rc_tail_sh modfs/modscripts/
cd modfs/
./run_modscripts ../squashfs-root/
jetzt die rc.conf mit den fehlenden Werten beschrieben und zum Schluss das Image wieder gepackt:

Code:
YourFritz/bin/squashfs/x86_64/mksquashfs4-le squashfs-root/ fs.sqfs -all-root -no-progress
cat kernel.bin fs.sqfs >7530.image
und mit der Windows Powershell installiert.
 
Zuletzt bearbeitet:
Welche sind das genau?
Alles was du geändert haben willst in dem Envoriment schreibst du als export.
Kann mir gut vorstellen das ein export firmware_version=avm das selbe bewirkt wie ein export oem=avm
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
244,868
Beiträge
2,219,771
Mitglieder
371,585
Neuestes Mitglied
PauSchmitz
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.