[Frage] Fritzbox 7590 mit ProviderAdditive ausstatten

fortender

Neuer User
Mitglied seit
26 Mai 2021
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Hallo,

ich möchte eine Fritzbox 7590 (ProductID: Fritz_Box_HW226, Firmware: 154.7.21, Bootloaderversion: 1.3258) mit Provider-Additiven ausstatten.
Jetzt sind mir durch Recherche zwei Möglichkeiten bekannt, wie das zu bewerkstelligen ist:
  1. TFFS Dump erzeugen und dort die ProviderAdditive.tar hineinfriemeln und dann auf die Box zurückflashen
  2. Im Netz und auch hier im Forum kursiert aber das Gerücht, dass das üblicherweise per USB auf die Box gebracht werden kann.
Mir war es leider nicht möglich per FTP die mtd3 Partition oder irgendeine andere Partition herunterzuladen. Gemacht hab ich das wie in der Freetz Doku beschrieben, allerdings unter Windows über MobaXTerm mit FTP-Version "GNU inetutils 1.7":
Code:
> (
> cat <<EOT
> open 192.168.178.1
> user adam2 adam2
> debug
> bin
> quote MEDIA FLSH
> get mtd1
> get mtd2
> get mtd3
> get mtd4
> quit
> EOT
> ) | ftp -n -p

ftp> open 192.168.178.1
ftp> user adam2 adam2
ftp> debug
Debugging on (debug=1).
ftp> bin
---> TYPE I
ftp> quote MEDIA FLSH
---> MEDIA FLSH
ftp> get mtd1
---> PORT 192,168,178,2,200,126
Command not implemented
---> RETR mtd1
Command not implemented
ftp> get mtd2
---> PORT 192,168,178,2,200,127
Command not implemented
ftp> get mtd3
---> PORT 192,168,178,2,200,128
Command not implemented
ftp> get mtd4
---> PORT 192,168,178,2,200,129
Command not implemented
ftp> quit
---> QUIT

Ich habe hier schon von diversen Leuten gelesen, dass es mit der Kommandozeile in Windows zusammenhängen soll, daher hab ich das mit der FTP-Implementierung von MobaXTerm probiert. Über Ubuntu (WSL2) scheitert es bereits am Öffnen der Sockets, aber das ist ein anderes Problem. Um dem ganzen auszuweichen, habe ich es zusätzlich über den PowerShell FTP-Client von @PeterPawn probiert. Dieser hat leider keine eingebaute Methode, um Dateien abzurufen, daher habe ich mich an GetEnvironmentFile orientiert und das Skript um folgende Methode erweitert:
Code:
function GetFlashFile {
    Param(
        [Parameter(Mandatory = $False, Position = 0, HelpMessage = 'the name of file to read')][String]$name,
        [Parameter(Mandatory = $False, Position = 0)][String]$filename
    )

    # set binary transfer mode
    SendCommand "TYPE I"
    $answer = ReadAnswer
    if (-not (ParseAnswer $answer "200")) {
        $ex = New-Object System.IO.IOException "Error setting binary transfer mode."
        Throw $ex
    }

    # set media type to FLSH
    SendCommand "MEDIA FLSH"
    $answer = ReadAnswer
    if (-not (ParseAnswer $answer "200")) {
        $ex = New-Object System.IO.IOException "Error selecting media type."
        Throw $ex
    }
    if (-not (ReadFile $filename $name)) {
        $ex = New-Object System.IO.IOException "Read error"
        Throw $ex
    }
}
Das führt allerdings zu 501 unknown variable mtd3.
Code:
PS C:\Sourcecode\Fritzbox\YourFritz\eva_tools> .\EVA-FTP-Client.ps1 -Verbose -Debug -ScriptBlock { GetFlashFile -name "mtd3" -filename "C:\Sourcecode\Fritzbox\mtd3.image" }
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3258 0x0 0x46409

================
DEBUG: Sent
TYPE I
================
DEBUG: Response:
200 Type set to BINARY

================
DEBUG: Sent
MEDIA FLSH
================
DEBUG: Response:
200 Media set to MEDIA_FLASH

================
DEBUG: Sent
P@SW
================
DEBUG: Response:
227 Entering Passive Mode (192,168,178,1,12,8)

================
DEBUG: Sent
RETR mtd3
================
DEBUG: Response:
501 unknown variable mtd3

================
Ich dachte es könnte daran liegen, dass die ReadFile Funktion RETR statt GET verwendet, daher hab ich es mit GET probiert, was aber dann nur zu einem anderen Fehler führt: 502 Command not implemented.
Mir blieb also bisher nichts anderes übrig, als einen TFFS Dump über die erweiterten externen Supportdaten zu erzeugen. Darüber konnte ich erfolgreich die ProviderAdditive (ID: 29) extrahieren und modifizieren.

Mir stellen sich jetzt also folgende Fragen:
  1. Ist es allgemein noch möglich bei diesem Fritzbox-Modell mit dem Bootloader Partitionen zu sichern und wieder auf die Box zu flashen?
  2. Lässt sich das Ganze tatsächlich wie oben in 2. angedeutet über USB auf die Box bringen, wenn ja, dann wie? Einfach die ProviderAdditive.tar auf nen FAT32 formatierten USB-Stick hauen und die Box neustarten hat nichts gebracht. Habe dazu leider keine Dokumentation gefunden. Ich habe mir auch die Mühe gemacht die Firmware zu entpacken und das Dateisystem (aus firmware.image) nach Binaries zu suchen, die ProviderAdditive.tar lesen, habe da aber nichts gefunden, was direkt auf den USB-Stick zugreift. Gefundene Skripte habe ich dann mal überflogen, über Kompilate habe ich mit Ghidra drübergeschaut, in der Hoffnung, dass ich so mehr über das Verhalten herausbekomme. Leider nicht fündig geworden.
Würde mich sehr über Hilfe freuen. Falls ich irgendein notwendiges Detail ausgelassen habe, lasst es mich wissen. Bin ja noch neu hier.

EDIT: Mit fällt gerade auf, dass ich evtl. ein Unterforum für den Thread gewählt habe, das nicht ideal passt. Vielleicht kann ein Mod den Thread entsprechend verschieben, sofern notwendig?

Viele Grüße,
Tim
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
[Edit Novize: Überflüssiges Fullquote des Beitrag direkt darüber gelöscht - siehe Forumsregeln]
Es handelt sich um keinen bekannten Provider. Ich habe einen ACS und die zugehörigen Zugangsdaten dazu, die ich gerne auf die Box bringen würde, sodass diese einen Factory Reset der Box überleben.
 
Zuletzt bearbeitet von einem Moderator:
Für einen ACS braucht man keinen Provider Additive, sondern einen CWMP Account auf der Box, siehe Typenschild. Ist da keiner drauf?
 
1. Aktuelle Bootloader bei AVM lassen GAR KEIN Auslesen irgendwelcher (Raw-)Partitions über FTP zu. Alles, was man da ggf. auslesen kann, sind aufbereitete (cooked) Daten aus dem Environment (auch wenn das in einer oder zwei Partitionen gespeichert ist) und teilweise noch Infos aus dem Konfigurationsbereich des Bootloaders. Letzteres schwankt im Umfang je nach Architektur (manchmal sogar Modell).

2. Öffentlich hat AVM m.W. die korrekten Formate nie beschrieben. Es gibt aber - iirc z.B. bei Netcologne - Beispiele dafür in Netz. Der Import erfolgte üblicherweise nach dem Mounten eines USB-Volumes, daher findet man den Aufruf entsprechender Programme auch in den Dateien, die vom udevd beim Mounten von Volumes aufgerufen werden. Auch aktuelle Versionen sollten dort noch den Aufruf von /bin/tr069starter enthalten ... allerdings nur dann, wenn das Programm auch in der Firmware enthalten ist (da gibt es ein test -x ... davor) und da das seit einiger Zeit nicht mehr der Fall ist (seit wann genau, kann ich nicht sagen - in 07.08-Versionen war es noch vorhanden, in der 07.11 der 7490 nicht mehr), wird das wohl in aktueller Firmware auch nicht mehr funktionieren. Wer sich (aus Interesse für die potentiellen Dateinamen) das Ganze noch einmal genauer ansehen will, braucht also ein Image, wo /bin/tr069starter noch enthalten ist. Vermutlich wird in den aktuelleren Versionen auch die früher existierende Funktion configimportbyusb in tr069fwupdate nicht mehr vorhanden sein - diese wurde von /bin/tr069starter aufgerufen, wenn eine passende (und passend benannte) Datei auf einem Volume existierte.

Aber das funktioniert heutzutage eben wohl tatsächlich nicht mehr. Wenn mich nicht alles täuscht (und meine Thesen basieren auch nur auf eigenen Recherchen, ich habe KEINE zusätzlichen Informationen von AVM dazu), erfolgt heutzutage die Installation eines solchen Additivs (wenn es nicht bei der Produktion schon eingebaut wird, was wohl bei den ganzen "Editionen" eher der Fall sein dürfte) über das Recovery-Programm. Dort finden sich jedenfalls Zeichenketten, die auf derartige Funktionen schließen lassen:
Code:
install.cfg
LoadTarProviderDefaultFile '%s'
LoadTarProviderDefaultFile: line='%s'
LoadTarProviderDefaultFile: err too much entries %s
'%s' id=%d Dateilaenge %ld
provider: Fehler beim Schreiben des TFFS (evtl Id %d unbekannt)
provider: TFFS Id %d Laenge %d geschrieben
provider: '%s' erfolgreich gesetzt
Wie so eine - vermutlich tatsächlich install.cfg zu nennende - Datei für die Konfiguration dieser Funktion dann genau aussehen muß, weiß ich auch nicht - es hat mich nie wirklich interessiert, wobei einfache Versuche iirc nicht geklappt haben (es ist schon länger her, daß ich mich damit befaßt hatte).

Aber ich würde Wetten eingehen, daß ein passend konfiguriertes Recovery-Programm das kann ... ggf. aber auch eines, was nur an Provider ausgeliefert wird, denn es gibt auch noch andere "Leichen" in dem Programm, z.B. auch eine sehr ausführliche Protokollierung der einzelnen Schritte, die aber durch das Linken einer Dummy-Funktion bei den öffentlich bereitgestellten Programmen deaktiviert wurde und wohl auch mit einfachen Tricks nicht zu reaktivieren ist - jedenfalls ist es mir nicht gelungen und man müßte wohl diese (Dummy-)Funktion im Speicher bei der Ausführung durch eine eigene ersetzen.

Logisch wäre es in jedem Falle, das auch dort einzubauen ... letztlich macht das Recovery-Programm ja auch nichts anderes, als die Environment-Daten und die Zähler auszulesen und daraus ein neues TFFS-Image zusammenzubauen, was dann geflasht wird. Dabei jetzt noch ein Additiv einzubauen (und die TFFS-Minor-ID in der o.g. Meldung ist erst einmal "variabel" und nur als %d angegeben, auch wenn es wohl am Ende die 29 ist) und auch gleich noch die Variable provider im Environment passend zu setzen, erscheint mir jedenfalls sehr plausibel.

Nur hat mich das halt selbst nie wirklich interessiert (von ein paar simplen Versuchen mal abgesehen), weil ich es ja mehr auf das mögliche Mißbrauchspotential des TFFS abgesehen hatte (schließlich ist das eine der Stellen, wo Daten/Modifikationen auch über mehrere FRITZ!OS-Versionen gehalten würden) und ohnehin anzunehmen wäre, daß das AVM-Programm einem da nicht alle "Freiheiten" beim Probieren einräumt - daraus entstanden dann ja auch die Shell-Skripte zum Umgang mit TFFS-Images (https://github.com/PeterPawn/YourFritz/tree/main/tffs).

Wem diese (bzw. das dort umgesetzte Prinzip) nicht zusagen, der kann sich zumindest mal näher mit dem Recovery-Programm befassen ... aber wie geschrieben, es MUSS nicht sein, daß diese Teile auch in den öffentlich verfügbaren Recovery-Programmen funktionieren, selbst wenn man die richtige Konfiguration dafür verwendet. Ich würde jedenfalls ebenso wetten, daß die install.cfg das alte "INI-Format" von Windows verwendet, denn einiges darin ist eben schon seeehr alt, bis hin zu Aufrufen von GetPrivateProfileString() (https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getprivateprofilestring), die eigentlich nur beim Lesen irgendwelcher Konfigurationsdateien (die dann vermutlich auch noch im Programm- oder sogar im Windows-Verzeichnis liegen müssen) einen Sinn ergeben.

Solltest Du das korrekte Format ermitteln können und sollte das obendrein auch noch mit den öffentlich verfügbaren Recovery-Programmen funktionieren, wirst Du das ja hoffentlich auch hier entsprechend beschreiben - aber ich könnte auch verstehen, wenn Du (wie ich) die Aktionen des Recovery-Programms einfach von Hand nachbaust (Teile für so ein - eigenes - Programm finden sich auch im YourFritz-Repo, ggf. auch in den C#-Quellen bzw. bei den PS-Skripts) und dann das eigene TFFS-Image schreibst. Macht man das, BEVOR man die Box konfiguriert (was ja normal wäre, schließlich soll dieses Additiv ja genau die Infos für diese automatische Konfiguration liefern), gibt es auch keinen Grund, den bisherigen TFFS-Inhalt (komplett) auszulesen und man kann sich aus den gekochten Daten (Environment und Counter) auch einfach sein eigenes TFFS-Image backen, dem man dann gleich noch die notwendigen Ergänzungen hinzufügt.

Wobei ich auch noch ein Wort der Warnung loswerden will ... neben der sichtbaren Beschäftigung mit dem Gegenstand dieses Threads, gibt es offenbar auch noch einige gravierende Wissenslücken (die Frage nach dem Auslesen von Partitionen über EVA wäre ein Beispiel dafür), die Du zuvor vielleicht schließen solltest - es ist vieles hier im Board beschrieben, speziell auch dazu, wie so ein TFFS-Image aufgebaut ist. Wobei auch dabei durchaus Vorsicht geboten ist ... anders als andere Architekturen verwendet die 7590 (wie alle GRX-Boxen) nämlich gar nicht mehr das "legacy format" des TFFS (auch wenn's bei Schreiben über EVA immer noch zum Einsatz kommt - das wird dann beim Beschreiben von mtdnand entsprechend angepaßt), sondern ein (relativ) neues, was besser zur Organisation von NAND-Flash paßt. Für dieses (interne und auch in den Support-Daten dann exportierte) Format gibt es (von mir jedenfalls und andere kenne ich auch nicht) noch KEIN Angebot an Software, um diese Images in die einzelnen Einstellungen zu zerlegen, wie das bei dissect_tffs_dump (https://github.com/PeterPawn/YourFritz/blob/main/tffs/dissect_tffs_dump) der Fall wäre für das "legacy format".

Und ein CWMP-Account in den "Geburtsdaten" der Box mag zwar hilfreich sein (auch wenn man den beim Schreiben eines eigenen TFFS-Images ebenso hinzufügen kann, denn das ist auch kein Hexenwerk), ist aber keine Voraussetzung. Meine "Test-Box" meldet sich jedenfalls auch mit diesen Einstellungen in der tr069.cfg:
Code:
                managementserver {
                        url = "http://192.168.131.2:80/CPERequest";
                        username = "";
                        password = "";
                        URLAlreadyContacted = no;
                        FirstConnectDelay = 0;
                        LastInformReq = "2021-04-15 22:41:43";
                        LastSuccessfulContact = "1970-01-01 00:00:00";
                        URLbyDHCPIface = "";
                        PeriodicInformEnable = no;
                        PeriodicInformInterval = 0;
                        PeriodicInformTime = "1970-01-01 00:00:00";
                        UpgradesManaged = no;
                        ACSInitiationEnable = yes;
                        ACSInitiationPorts = "8089+0";
                        SessionTerminationWithEmptyPost = no;
                        ConnectionRequestUsername = "";
                        ConnectionRequestPassword = "";
                        dnsprefer = tr069dnsprefer_ipv4;
                        CRSecurityEnable = no;
                        CRSecurityDNSUpdateInterval = 86400;
                        AllowedAccessMedium = tr069_medium_all;
                }
regelmäßig bei ihrem ACS, wie man an den Zeitstempeln sehen kann (auch wenn da derzeit gar kein ACS antwortet, weshalb auch LastSuccessFulContact nicht gesetzt ist).
 
Danke für die vielen Antworten.
Für einen ACS braucht man keinen Provider Additive, sondern einen CWMP Account auf der Box, siehe Typenschild. Ist da keiner drauf?
Der CWMP Account Aufkleber ist auf der Box zu finden, ja. Auch wenn ich jetzt mit Sicherheit nicht so tief in der Materie drin bin wie ihr, meine ich das wie folgt verstanden zu haben: Der Netzbetreiber registriert den CWMP Account des CPE das später dem Kunde zugeschickt wird im ACS. Nimmt der Kunde das CPE dann in Betrieb, so meldet es sich bei dem ACS und erhält die dem Kunden zugehörige Konfiguration. Das setzt aber voraus, dass das CPE weiß bei welchem ACS es sich melden muss. In meinem Fall kennt die Fritzbox den ACS aber nicht und daher muss ich diese (meines Wissens nach über die Provider Additiven, da dort die tr069.cfg mitkommt) zunächst auf die Box bringen.

Auch aktuelle Versionen sollten dort noch den Aufruf von /bin/tr069starter enthalten ... allerdings nur dann, wenn das Programm auch in der Firmware enthalten ist
Das ist leider nicht der Fall. Danach hab ich auch schon Ausschau gehalten.

Wie so eine - vermutlich tatsächlich install.cfg zu nennende - Datei für die Konfiguration dieser Funktion dann genau aussehen muß, weiß ich auch nicht - es hat mich nie wirklich interessiert, wobei einfache Versuche iirc nicht geklappt haben (es ist schon länger her, daß ich mich damit befaßt hatte).
Ich bin gerade dran das Recovery-Programm auseinanderzunehmen. Herausgefunden habe ich bis jetzt, dass wenn im Environment der Provider "x" gesetzt ist, dass im Verzeichnis des Recovery-Programms nach einer "x.tar" gesucht und diese anschließend geöffnet wird. Wenn man die Methodenaufrufe entsprechend verfolgt, dann findet man auch die Zeichenketten "LoadTarProviderDefaultFile" und "install.cfg", von denen du bereits geschrieben hast.

Ich würde jedenfalls ebenso wetten, daß die install.cfg das alte "INI-Format" von Windows verwendet, denn einiges darin ist eben schon seeehr alt, bis hin zu Aufrufen von GetPrivateProfileString()
Ich würde dagegen wetten. Ich habe die folgenden Aufrufe von GetPrivateProfileString() gefunden und alle gehen zu einem INI-File, das denselben Dateinamen wie das Recovery-Programm trägt. Ich will aber nicht ausschließen, dass der Inhalt der INI nicht doch was mit den Provider Additiven zu tun hat. All zu weit bin ich bisher damit nicht gekommen. Scheinbar sind zwei Sektionen in der INI möglich: "Command" und "Text". Ein direkter Zugriff auf spezielle Keys findet wohl nicht statt. Es wird also wohl die komplette Sektion abgerufen und gespeichert. Auf welche Schlüssel dann genau zugegriffen werden habe ich noch nicht herausgefunden.
C:
// In beiden Fällen fileName: ".\FRITZ.Box_7590-07.21-recover.ini"
GetPrivateProfileStringA("Command", NULL, "", buffer, bufferSize, fileName);
GetPrivateProfileStringA("Text", NULL, "", buffer, bufferSize, fileName);
Ich habe mit Sysinternals Process Monitor überprüft, ob der Versuch stattfindet, eine install.cfg zu finden. Das ist aber nicht der Fall. Es scheint mir so, dass die install.cfg in dem oben angesprochenen Tarball liegen muss.

es gibt auch noch andere "Leichen" in dem Programm, z.B. auch eine sehr ausführliche Protokollierung der einzelnen Schritte, die aber durch das Linken einer Dummy-Funktion bei den öffentlich bereitgestellten Programmen deaktiviert wurde und wohl auch mit einfachen Tricks nicht zu reaktivieren ist - jedenfalls ist es mir nicht gelungen und man müßte wohl diese (Dummy-)Funktion im Speicher bei der Ausführung durch eine eigene ersetzen
Die Log-Funktion enthält nur noch ein return. Daher dachte ich zunächst, dass dort kein Platz ist für ein Patch. Deshalb habe eine DLL gebaut, die sämtliche Calls zum Log-Dummy ermittelt und diese dann entsprechend patcht, sodass stattdessen printf aufgerufen wird. Der Injektor, der den Code injiziert stellt auch gleichzeitig das Konsolenfenster mit den Ausgaben bereit (siehe Screenshot). Leider laufe ich an irgendeiner Stelle in eine Access Violation Exception und die Anwendung crasht. So ganz sauber ist mein Patch dann scheinbar doch nicht. Aber ich verstehe es nicht. Der Callee muss hier ja nicht aufräumen, da hier offensichtlich variable Parameterlisten verwendet werden (also cdecl). Außerdem müsste der Log-Dummy dann ebenfalls aufräumen, aber der macht nichts außer ret. Naja... Mir ist dann aufgefallen, dass das alles zu viel Arbeit war, da die anliegende Funktion ohnehin keine Verweise hat und ich somit doch Platz habe, den Log-Dummy dort direkt zu patchen.
1622734137646.png
Bild gemäß Boardregeln als Vorschaubild eingebunden by stoney

Solltest Du das korrekte Format ermitteln können und sollte das obendrein auch noch mit den öffentlich verfügbaren Recovery-Programmen funktionieren, wirst Du das ja hoffentlich auch hier entsprechend beschreiben - aber ich könnte auch verstehen, wenn Du (wie ich) die Aktionen des Recovery-Programms einfach von Hand nachbaust (Teile für so ein - eigenes - Programm finden sich auch im YourFritz-Repo, ggf. auch in den C#-Quellen bzw. bei den PS-Skripts) und dann das eigene TFFS-Image schreibst. Macht man das, BEVOR man die Box konfiguriert (was ja normal wäre, schließlich soll dieses Additiv ja genau die Infos für diese automatische Konfiguration liefern), gibt es auch keinen Grund, den bisherigen TFFS-Inhalt (komplett) auszulesen und man kann sich aus den gekochten Daten (Environment und Counter) auch einfach sein eigenes TFFS-Image backen, dem man dann gleich noch die notwendigen Ergänzungen hinzufügt.
Das werde ich tun. Das NAND TFFS Format scheint mir jetzt nicht so kompliziert zu sein, bin schon händisch mit dem Hex-Editor durchgegangen. Natürlich werde ich alle Infos bereitstellen, sofern ich es schaffe.

Ich melde mich nochmal, wenn ich mehr herausgefunden habe :)
Vielen Dank für die Hilfe.
 
Zuletzt bearbeitet von einem Moderator:
Das NAND TFFS Format scheint mir jetzt nicht so kompliziert zu sein, bin schon händisch mit dem Hex-Editor durchgegangen.
Das bezog sich auch nicht auf das NAND-Format für die TFFS-Speicherung - das ist einfach nachzulesen in den Quelltext-Paketen, die AVM bereitstellt ... der gesamte TFFS-Treiber von AVM ist dort enthalten und man kann sich einfach die C-Quellen ansehen.

Ich meinte eher, ob/wie man das Recovery-Programm passend konfigurieren könnte ... denn das, was Du da eigentlich machen willst (ein eigenes Additiv auf die Box bringen), ist auch ohne das Recovery-Programm problemlos machbar. Da spielt auch das Format bei der Speicherung des TFFS keine Geige - beim "Installieren" eines neuen TFFS-Images durch Schreiben nach mtdnand wird weiterhin (wie ich oben schon schrieb) das "legacy format" verwendet.

Wie man sich ein eigenes, passendes Image zusammenstellen kann, ist schon lange hier im Board beschrieben ... iirc irgendwo bei den 6490-Modellen, wo ab August 2016 dann über eine Sicherheitslücke in der Verarbeitung des Inhalts einer provideradditive.tar eigene Kommandos auf der Box ausgeführt werden konnten. Das Problem ist hier beschrieben: https://github.com/PeterPawn/YourFritz/tree/main/reported_threats/480894 und wie ich gerade gesehen habe, ist in der dortigen README.md sogar ein Link ins IPPF enthalten - vermutlich führt der zu einer Stelle, wo beschrieben ist, wie man eine passende (den Fehler ausnutzende) provideradditive.tar erstellt und wie man die dann auf die Box bringt.

Wie ich auch oben schon schrieb ... das "Auslesen" irgendwelcher TFFS-Inhalte jenseits von Environment und Countern ist auch nur dann erforderlich/sinnvoll, wenn da alte Inhalte überhaupt vorhanden sind. Das Recovery-Programm schert sich (afaik) auch nicht darum, was da zuvor vielleicht gestanden haben könnte. Es baut einfach aus den (als Text) gelesenden Werten ein neues Image zusammen und ändert dabei sogar ein paar Werte ab - so wird z.B. my_ipaddress von diesem Programm immer auf 192.168.178.1 gesetzt, egal was zuvor aus der Box gelesen wurde. Daher ist das Recovery-Programm sogar "gründlicher" als ein Zurücksetzen auf die Werkseinstellungen ... woran das letztlich liegt, kannst Du auch nachlesen - das MUSS man also auch nicht mehr erforschen, auch wenn man es selbstverständlich tun KANN.

DAS dann aber jetzt nachzubauen, ist im Prinzip Programmierer-Klippschule ... dafür braucht man auch kein Reverse-Engineering des Recovery-Programms in größerem Umfang (deshalb habe ich das auch weitgehend unterlassen - mal abgesehen von den Fragen hinsichtlich §69e UrhG, welche durch eine Dekompilierung aufgeworfen werden). Auch der FTP-Dialog, der zwischen dem Recovery-Programm und dem Bootloader abläuft, ist bekannt (und beim Testen des Recovery-Programms wirst Du ja auch auf die Dateien ftp.log und environment.log gestoßen sein, die ich für andere z.B. hier: https://www.ip-phone-forum.de/threads/wie-recovere-ich-eigentlich-richtig.299790/post-2280100 beschrieben habe) ... und es gibt für jeden der dabei ausgeführten Schritte auch bereits einen "Ersatz" - nur muß man dazu ggf. eben ein paar (Shell-)Skripte passend miteinander verknüpfen, was aber nach meiner Überzeugung vollkommen der Philosophie "one tool - one job" entspricht (https://en.wikipedia.org/wiki/Unix_philosophy) und daher ist das bisherige Fehlen eines "Gesamtprogramms", was alle diese Schritte in sich vereint (und damit praktisch ein Nachbau des AVM-Programms wäre), auch pure Absicht meinerseits.

Ich will also niemanden von "Entdeckerfreude" abhalten und das Recovery-Programm von AVM ist ggf. auch noch den einen oder anderen Blick wert - aber wenn es dabei nicht tatsächlich um die Frage geht, OB und WIE man mit genau DIESEM Programm ein Provider-Additiv auf die Box bringen kann, sondern letztlich der Erfolg, DASS man ein solches auf die Box bringt, im Vordergrund steht, dann stehst Du am falschen Baum bzw. dann kannst Du Dir jede Menge Zeit sparen, wenn Du die richtigen Quellen findest und liest.
 
Ich will also niemanden von "Entdeckerfreude" abhalten und das Recovery-Programm von AVM ist ggf. auch noch den einen oder anderen Blick wert - aber wenn es dabei nicht tatsächlich um die Frage geht, OB und WIE man mit genau DIESEM Programm ein Provider-Additiv auf die Box bringen kann, sondern letztlich der Erfolg, DASS man ein solches auf die Box bringt, im Vordergrund steht, dann stehst Du am falschen Baum bzw. dann kannst Du Dir jede Menge Zeit sparen, wenn Du die richtigen Quellen findest und liest.
Ja was soll ich sagen. Du hast natürlich recht. In erster Linie geht es mir darum, DASS die Additiven auf der Box landen. Aufgrund meiner "Entdeckerfreude" bin ich dann aber wohl ein wenig abgedriftet in das Reverse Engineering. Daher habe ich die Recover.exe jetzt erstmal liegen lassen und versucht mit den Ressourcen die du zur Verfügung gestellt hast ein TFFS Image zu bauen mit eigenen Additiven und das auf die Box zu bekommen.

Ich bin wie folgt vorgegangen (ich hab mich dazu den Tools bedient, die du in deinem YourFritz-Repo bereitstellst, danke dafür):
  • Environment und Counter via eva_get_environment abgerufen
  • Das Environment habe ich weitgehend so gelassen, außer bei Provider, da habe ich einen kurzen prägnanten Namen hinterlegt (vermutlich unwichtig?)
  • Nametable aus meinem vorhandenen TFFS Dump erzeugt via name_table_from_tffs (vermutlich hätte ich auch einfach die Tabellen aus tffs/data nehmen können :D)
  • provideradditive.tar erzeugt und mit zlib komprimiert (default compression) und in 001D.bin umbenannt
  • Mit build_ttfs_image nametable env counter 001D.bin habe ich dann ein TFFS Image erzeugt
  • Abschließend nach Überfliegen des neuen Image habe ich mit eva_store_tffs mtdnand tffs_new.img das Image auf die Box gebracht.
  • Nach Neustarten der Box habe ich nochmal externe Supportdaten erzeugt und über den TFFS Dump verifiziert, dass die Änderungen gesetzt wurden, da ich leider keinen DSL-Anschluss habe, an dem ich es jetzt testen kann.
Testen wollte ich das Ganze, in dem ich eine lokale Adresse als ACS angebe und prüfe, ob die Box versucht den zu erreichen. Spielt die Box das Protokoll nur durch, wenn sie am DSL-Anschluss hängt oder kann ich die auch hinter meinen Router klemmen oder versucht sie das ohnehin ständig?
 
Zuletzt bearbeitet:
Die Box versucht auch bei einem ACS, der über die LAN-Verbindung zu erreichen wäre, einen INFORM-Request nach dem Reboot zu landen (und bei der Gelegenheit kann der ACS sie dann für weiteres regelmäßiges Melden konfigurieren und ggf. auch für "external knocking").

Wobei man auch über das Backup der Einstellungen und den Blick in die tr069.cfg (und die ar7.cfg, denn da sollte dann auch der Provider als active_provider stehen, iirc) erkennen können sollte, ob die gewünschten Einstellungen vom FRITZ!OS korrekt gesetzt wurden anhand des Additivs.

Und ja ... Du hättest auch die Name-Table aus dem Repo nehmen können, die habe ich (in Version @N) erst vor kurzem an die jüngsten AVM-Änderungen angepaßt. Es spielt auch keine Rolle (mehr), wenn die Name-Table im TFFS einen abweichenden Inhalt zu der im jeweiligen Kernel haben sollte - dann wird die tatsächlich beim Initialisieren des TFFS im Flash ersetzt.

EDIT: Und der Wert in provider im Environment verhindert dann auch (ich weiß nicht, ob der auch automatisch gesetzt würde, wenn die Einstellungen aus dem Additiv angewendet werden), daß der Besitzer der Box Deine Änderungen einfach mit dem Recovery-Programm wieder auslöscht - dazu müßte er erst die "Schutzvariable" wieder auf "leer" setzen.
 
Ich wurde vor kurzem von einem User zurück zu diesem Thread gebracht und plötzlich kam die Lust zurück mich nochmal mit dem Recovery-Tool auseinanderzusetzen.

Resumé des Thread war ja, dass es grundsätzlich auch ohne Recovery-Tool möglich ist die Provider-Additive zu setzen. Ich hatte mir hierzu abgeleitet von der Arbeit von @PeterPawn (und anderen?) entsprechende Tools gebaut, um Bulk-mäßig Fritzboxen mit den Provider-Additiven auszustatten. Für mich war bis jetzt unklar, wie und ob überhaupt es möglich ist, mit dem Recovery-Tool die Provider-Additive zu setzen. Ich teile mit euch jetzt meine Erkenntnisse aus etwas Reverse-Engineering.

Wenn die Umgebungsvariable "provider" gesetzt ist, dann weigert sich das Tool eine Wiederherstellung vorzunehmen. Im Hintergrund wird aber versucht die Providereinstellungen zu finden. Es wird hierzu im Ordner der Recovery-Tool Executable nach einer "[provider].tar" gesucht. In diesem Tarball wird nach einer "install.cfg" gesucht. Diese hält Mapping-Einträge für die im TFFS unterzubringenden Daten und gibt an unter welcher TFFS Node ID z.B. die Provider-Additive zu finden sein müssen.

Beispielaufbau des Provider Tarball (Auflistung der Dateien in [provider].tar):
Code:
install.cfg
provider_additive.tar

Beispielaufbau install.cfg:
Code:
29 provider_additive.tar

Wie eine provider_additive.tar aussieht, ist denke ich bekannt?

Im ftp.log tauchen dann folgende Zeilen auf:
Code:
0:11:252: provider: TFFS Id 29 Laenge 1221 geschrieben
0:11:252: provider: 'providername' erfolgreich gesetzt

ABER: Es war mir nicht möglich herauszufinden, ob und wie es möglich ist die Additive via Recovery-Tool zu setzen, wenn die Variable "provider" nicht gesetzt ist. Man müsste also ggf. vorher via SETENV provider [provider] zunächst den Provider setzen, um das Tool entsprechend zu triggern.

AVM stellt ISPs allerdings ein separates Kommandozeilen-Tool zum Flashen der Provider-Additive bereit. Es sieht so aus als würden sich die Tools allerdings einige Fragmente "teilen".
 
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.