[Info] Sammelthema zur AVM FRITZ!Box 7520

[PeterPawn]

Auch auf die Gefahr hin, daß wieder jemand "off-topic" schreit (dann bitte in einen gesonderten Thread: "AVM-Firmware und das Urheber-/Marken-/Wettbewerbsrecht" o.s.ä. verschieben - meine ohnehin angefertigte, lokale Kopie hat dann wieder die ganzen Textauszeichnungen nicht mehr und auch keine funktionierenden Links):

Ist das mit dem Mod-Recovery nicht einfacher? Könnte man dann sogar jedesmal benutzen und teilen?

Ich weiß zwar auch nicht genau, was ein "Mod-Recovery" ist ... aber wenn das ein modifiziertes Recovery-Programm von AVM sein sollte, dann führt eine solche Modifikation (a) zu einer ungültigen Signatur des Windows-Programms und (b) zu einer Verletzung der Urheberrechte von AVM (eine solche Modifikation müßte dann ja dauerhaft ausgeführt sein, wenn man keinen eigenen Loader o.ä. programmieren will) und (c) spätestens die Weitergabe einer solchermaßen modifizierten Software wiederum zur Verletzung der Lizenzbestimmungen und des Urheberrechts (§53 UrhG greift dann garantiert nicht mehr) ... und hier hilft auch der Verweis auf GPLv2 und "distribution as a whole" nicht weiter, weil ja der unter GPL stehende Teil dieser (Recovery-)Datei (der Kernel und das Dateisystem liegen ja im Datensegment des Windows-Programms) gar nicht betroffen ist und die Änderung an AVM-Code erfolgen würde.

Wenn Freetz trotzdem das Extrahieren der GPL-lizensierten Teile aus einem AVM-Programm unterstützt, ist das wieder etwas anderes ... das Ergebnis ist ja das unter entsprechender Lizenz stehende Firmware-Image (bzw. die darin enthaltenen Teile mit Kernel und Dateisystem) und jene Teile des Programms, die unter AVM-Lizenz stehen, werden dabei nicht verändert.

Wenn sich natürlich jemand ein eigenes Recovery-Tool schreiben möchte (und das vielleicht sogar anderen zur Verfügung stellen möchte), das eine bereits (selbst!) modifizierte Firmware in einem Schritt installiert und man das unter "Mod-Recovery" verstehen möchte, ist das wieder etwas anderes.

----------------------------------------------------------------------------------------------------------------------------

Aber schon die (öffentlich bekundete) Weitergabe (natürlich ebenso das Bereitstellen zum Download durch Dritte) eines modifizierten Firmware-Images, in dem weiterhin die AVM-Programme enthalten sind, ist ein sehr zweischneidiges Schwert, bei dem AVM garantiert in dem einen oder anderen Sprengel in Deutschland (dank Internet-Verbreitung wäre das ja auch wieder ein "fliegender Gerichtsstand" - §32 ZPO) wenigstens einen Achtungserfolg in der ersten Instanz erzielen würde, wenn man dagegen vorgehen wollte.

Denn ob ein Richter der Argumentation folgt, die Verteilung durch AVM erfolge ja ebenfalls "im Ganzen", wenn man genau für die Modifikation das Image auseinandernehmen, ändern und neu zusammenpacken muß, darf man wohl bezweifeln.

Zumindest mit gesundem Menschenverstand, wobei das irgendeine halbwegs schlüssige Argumentation durch einen "advocatus" natürlich auch nicht wirklich ausschließt ... ich würde es jedenfalls trotzdem nicht darauf anlegen, mein eigenes Recht, eine modifizierte AVM-Firmware zu verbreiten, auf das Vorhandensein von OpenSource-Komponenten in der AVM-Firmware zu stützen.

Nicht ganz umsonst passe ich bei den von mir bereitgestellten Lösungen extrem auf, daß es sich dabei - sofern ich etwas zum Download anbiete - tatsächlich nur um (fremde) Komponenten handelt, die ihrerseits unter GPL stehen und alles das, was AVM-Programme benötigt und beinhaltet (eben wieder "im Ganzen" bei einem AVM-Image), nur vom Benutzer selbst auf seinen Systemen modifiziert wird. Da stelle ich das dann eben nicht zum Download bereit und "verbreite" es damit auch nicht, womit auch die Rechte von AVM aus §17 UrhG nicht verletzt werden, denn diese räumt AVM dem Kunden eben explizit nicht ein und "geschlagen" wird diese Lizenzbestimmung nur von anderen Festlegungen in den OpenSource-Lizenzen.

----------------------------------------------------------------------------------------------------------------------------

Genau aus diesen FOSS-Lizenzen kann man auch das Recht auf die Verbreitung der unmodifizierten AVM-Images (und wohl auch des unmodifizierten Recovery-Programms, denn das enthält ja wieder die FOSS-Teile) herleiten ... ich kenne auch keinen Fall (seit dem Cybits-Urteil in 2011), wo AVM jemandem die Verbreitung der unveränderten Images versucht hätte zu untersagen bzw. gar mit einer Zivilklage dahingehend Erfolg gehabt hätte. Trotzdem kann man bei AVM noch heute folgendes nachlesen (https://avm.de/aktuelles/kurz-notiert/2011/weiteres-urteil-im-cybits-fall/ - Hervorhebung meinerseits, Grammatikfehler (Zeichensetzung, denn für mich steht da ein eingeschobener Nebensatz) sind aus dem Original):

Im Bezug auf die GPL ergeben sich aus dem Urteil wie von AVM erwartet keine Veränderungen. AVM wird seine Arbeit im Open-Source-Bereich unvermindert und ohne Änderungen fortsetzen und weiterhin nachhaltig alle seriösen Entwicklungen unterstützen.

Diese Behauptung ist insofern interessant, als AVM in diesem Prozess tatsächlich zunächst versucht hatte, aus dem Urheberrecht ein generelles Verbot für die Modifikation der Firmware abzuleiten. Aber da solche Versuche eines Verbreitungs- und generellen Modifikationsverbotes ja vermutlich nicht zur "Arbeit im Open-Source-Bereich" gehören, könnte man diesen Satz noch "durchgehen" lassen ... auch wenn er vermutlich beim Leser eher die Assoziation: "Wir machen bei allem so weiter, wie bisher." wecken soll bzw. wird.

Nachlesen kann man das Scheitern von AVM "im Übrigen" wiederum in der Urteilsbegründung des LG Berlin (16 O 255/10 v. 08.11.2011), die man bei der FSFE auch als PDF (als Scan des ausgefertigten Urteils) einsehen kann: https://fsfe.org/activities/ftf/lg-urteil-20111118.pdf ... schon die Kostenentscheidung (Seite 3, Punkt 2), bei der eine Aufteilung der Kosten zu 4/5 zulasten der Klägerin (also AVM) erfolgte (1/5 für die Beklagte - also Cybits), macht für mich Feststellungen wie diese: (Unterstreichung durch mich)

AVM sieht sich grundsätzlich bestätigt, da auch weiterhin die Software Surf-Sitter DSL in Bezug auf die FRITZ!Box in vorliegender Form nicht verbreitet werden darf.

eher zum Pfeifen im Wald (wobei ja auch heutzutage jeder Wahlsieger sein will, wenn er überhaupt eine einzige Stimme erhalten hat) - denn daß Cybits die eigene Software (also "Surf-Sitter DSL") nicht unverändert weiterhin verbreiten durfte, basierte lediglich auf der Tatsache, daß damit ein paar Anzeigen der Box nicht mehr so waren, wie AVM das vorgesehen hatte (insb. die DSL-Anzeige bzw. die Anzeige, daß die AVM-KiSi noch aktiv wäre - siehe Urteil).

In den anderen Punkten, die AVM sonst noch so versuchte ins Feld zu führen, wurde die Klage abgewiesen ... hier verbirgt sich hinter dem "Im Übrigen ..." aus dem Urteil dann eben der überwiegende Teil, wie man aus der Kostenentscheidung ableiten darf.

----------------------------------------------------------------------------------------------------------------------------

Wie hatte AVM denn genau argumentiert? Im Urteil findet sich in der Tatbestandsbeschreibung dazu folgendes:

Die Klägerin ist der Ansicht, die Firmware und die Auswahl und Anordnung der Module und Da-teien sei eigenschöpferisch, da es eine festgelegte Auswahl nicht gebe. Es handele sich um ein Sammelwerk im Sinne von § 4 UrhG. Indem nach der Installation von Surfsitter ihre Firmware von ihrer Internetseite herunter geladen werde, vervielfältige die Beklagte die in der Firmware enthaltenen proprietären Programme im Sinne von § 69c Nr. 1 UrhG. Durch die Bereitstellung von Updates auf ihrer Internetseite willige sie nicht generell in das Herunterladen der Firmware ein, da die Firmware ausschließlich ihren Kunden und nicht jedermann zum freien Download zur Verfügung gestellt werde.

Die Entfernung der Dateien [...] stelle eine Umarbeitung im Sinne von § 69c Nr. 2 UrhG dar. Das Verbleiben der Dateien im Speichermedium stelle keine bestimmungsgemäße Benutzung im Sinne von § 69d UrhG dar, weil für die Funktionalität der Fritzbox auch der Arbeitsspeicher wesentlich sei. Die Nichtansteuerung einzelnen Softwarebestandteile der Firmware stelle eine Umarbeitung dar.

Daraufhin erfolgte seitens Cybits folgender Vortrag:

Die Beklagte ist der Ansicht, die Firmware genieße keinen selbständigen, über den Schutz seiner Bestandteile hinausgehenden eigenen urheberrechtlichen Schutz. Der Auswahl und Zusammenstellung der Bestandteile komme keine Individualität zu. Da die Firmware auch Open Source Software enthalte, müssten ihr die Rechte gemäß § 2 der General Public License (GPL) von den Urhebern eingeräumt werden. Nach dem aus § 3 GPL folgenden Copyleft-Prinzip sei die Vervielfältigung und Weitergabe von Bearbeitungen eines Programms nur zulässig, wenn diese unter den Lizenzbedingungen der GPL erfolge, um zu verhindern, dass Open Source Software zu proprietärer Software umgewandelt werde. Daher würden gemäß § 4 GPL sämtliche Rechte aus einer Lizenz erlöschen. Auch wenn man die Firmware als Sammelwerk im Sinne von § 4 ZP 550 16 Abs. 1 UrhG ansähe, dürfte dieses nach § 2 GPL auch nur unter der GPL vertrieben werden. Gemäß § 4 GPL besitze die Klägerin in jedem Fall keine Nutzungsrechte an den Open Source Bestandteilen der Firmware. Gemäß § 2 GPL werde dem Nutzer das Recht zur Bearbeitung des Kernels eingeräumt, das er durch die Installation von Surfsitter wahrnehme.
[...]
Zudem bestehe der Anspruch deshalb nicht, weil die Klägerin die Firmware für jedermann zum Download bereitstelle, ohne den Download an Bedingungen zu knüpfen oder technisch einzu-schränken. Das Herunterladen erfolge daher mit ihrer Zustimmung im Sinne von § 69d UrhG.
[...]
Gemäß § 69d i.V.m. § 69c UrhG bedürfe es für den bestimmungsgemäßen Gebrauch der Software keiner Zustimmung der Klägerin. Die Benutzung sei andernfalls nicht möglich.

----------------------------------------------------------------------------------------------------------------------------

Was stellte das Gericht dann in seinem Urteilsspruch fest? (Hervorhebungen schon wieder meinerseits)

Der Klägerin stehen keine urheberrechtlichen Unterlassungsansprüche zu. Sie hat gegen die Beklagte keinen Anspruch gemäß §§ 97 Abs. 1, 69c Nr. 1 UrhG, es zu unterlassen, Kunden mittels der Software „Surf-Sitter DSL" dazu zu veranlassen, bei Installation der Software „Surf-Sitter DSL" auf einem Personalcomputer die jeweilige Firmware der Klägerin für die von dieser angebotenen bzw. vertriebenen DSL Router von einer Internetseite herunterzuladen und dadurch zu vervielfältigen (Antrag zu 1a)).

Das stellt also schon mal klar, daß eine andere Software, die einen Download der Firmware von einem AVM-Server bewirkt (wie es Freetz oder auch "modfs" machen), keinen Unterlassungsanspruch nach dem Urheberrecht bewirkt.

Weiterhin hat die Klägerin gegen die Beklagte keinen Anspruch gemäß §§ 97 Abs. 1, 69c Nr. 2 UrhG, es zu unterlassen, ihre Firmware [...] dergestalt umzuarbeiten, dass Dateien der Firmware, [...] aus dem ausführbaren Speicher entfernt werden (Antrag zu 1b)) bzw. dass Komponenten und/oder Dateien, [...] hinzugefügt werden (Antrag zu 1c)).

Es gibt also auch keinen Anspruch nach dem Urheberrecht, daß niemand eine AVM-Firmware an sich modifizieren dürfe oder daß er dafür die Zustimmung von AVM einholen müsste (§69c UrhG regelt, welche Handlungen der Zustimmung durch den Urheber bedürfen).

Schließlich hat die Klägerin keinen Anspruch gemäß §§ 97 Abs. 1, 69c Nr. 1 UrhG, es zu unterlassen, Kunden der Beklagten [...] dazu zu veranlassen, [...] Dateien der Firmware, von dem Speichermedium in den Arbeitsspeicher der FRITZIBox zu laden und dadurch zu vervielfältigen (Antrag zu 1f)).

Eine andere Software darf also die Firmware durchaus dahingehend modifizieren, daß auch weiterhin AVM-Programme vom Kunden verwendet werden ... mit der Modifikation erlischt nicht automatisch das von AVM dem normalen Kunden eingeräumte Recht zur Benutzung (der AVM-eigenen Programme).

Trotzdem folgt das Gericht sogar der Argumentation von AVM, es handele sich bei der Firmware um ein Sammelwerk:

Bei der Firmware handelt es sich um ein Sammelwerk im Sinne von § 4 Abs. 1 UrhG. Ein Sammelwerk liegt vor, wenn die Auswahl oder Anordnung der das Sammelwerk bildenden Elemente eigenschöpferisch ist. Geschützt ist dabei, auch die Kleine Münze, also diejenigen Gestaltungen, die bei einem Minimum an Gestaltungshöhe gerade noch urheberrechtsschutzfähig sind (Wandte/Bullinger, UrhR, 3. Auflage 2009, § 4 UrhG Rn. 5 m.w.N.). Nach diesem Maßstab stellt die Firmware der Klägerin ein nach § 4 Abs. 1 UrhG geschütztes Sammelwerk dar.

Aber danach wird konstatiert:

Für Sammelwerke bestimmt § 2 GPL, dass Werke, die Open Source Software enthalten, als Ganzes den Bedingung der GPL unterliegen (Determann, GRUR Int 2006, 645, 648 f. m.w.N.).
[...]
Danach stehen der Klägenn an der Firmware als Ganzes - und so sind ihre Anträge zu verstehen - keine urheberrechtlichen Unterlassungsansprüche zu.

Erfolg hat AVM am Ende nur noch mit dem Hilfsantrag, der - eben auf der Basis dieser falschen Anzeigen nach den Umarbeitungen durch die Cybits-Software - auf den zusätzlichen Aufwand bei AVM durch "verwirrte Benutzer" gründet und mit dem Gesetz gegen unlauteren Wettbewerb (UWG) argumentiert.

Alles andere, was AVM sonst noch so angeführt hatte, vom Markenrecht bis zum Ansinnen, daß man - als (kommerzieller) Mitbewerber - generell den Nutzer nicht unterstützen dürfe beim Modifizieren von AVM-Geräten, wurde hingegen deutlich abgewiesen und nicht nur mangels Notwendigkeit nicht betrachtet bzw. entschieden - somit bleibt auch kein Raum für Zweifel (am Urteil und seiner Begründung) offen.

----------------------------------------------------------------------------------------------------------------------------

Nun kommt für den privaten Hobbyisten als Anbieter solcher Software zwar i.d.R. das UWG ohnehin nicht in Betracht als Hebel (solange das nicht kommerziell ist, was er da anbietet, ist er auch kein Wettbewerber nach UWG), aber beim Markenrecht muß man halt etwas aufpassen.

Vor nicht allzu langer Zeit machte AVM wohl mal wieder eine Runde durch "die Community" und bat (dem Vernehmen nach sehr freundlich) um das Respektieren der eigenen Wort- und Bildmarken bei einigen Entwicklern, die ihrerseits die geschützte Marke "FRITZ!" in den Namen von Projekten und/oder Programmen eingebaut hatten und damit u.U. den Eindruck einer Nähe zum Markeninhaber beim Nutzer hervorrufen könnten.

Die Frage der Groß-/Kleinschreibung könnte hier deutlich weniger relevant sein, als das danach folgende Ausrufungszeichen ... in der Presse wird eben häufig auch "Fritz!" geschrieben, was man bei AVM allerdings (fast) nie findet. Gerade für einige der zusammengesetzten Produktnamen (FRITZ!Box, MyFRITZ!, usw.), gibt es aber auch eigene Markeneinträge (Recherche mit "(inh="AVM" oder anm="AVM") and (marke="fritz")") - da spielt dann die Groß-/Kleinschreibung wohl noch weniger eine Rolle.

Liest man sich das o.g. Urteil durch, stellt man fest, daß selbst dem LG Berlin die Spielerei mit der eingetragenen Marke am Ende zuviel wurde, wenn sich das durch das gesamte Urteil ziehen sollte: (die Farbe im Zitat stammt - man errät es wohl schon - wieder von mir)

Die Klägerin ist einer der führenden Anbieter von DSL-Endgeräten in Europa. Sie vertreibt seit 2004 u.a. verschiedene Produkte unter der Bezeichnung „FRITZIBox" (im Folgenden: Fritzbox) und ist Inhaberin folgender beim DPMA eingetragener Marken:

----------------------------------------------------------------------------------------------------------------------------

Aber auch das Markenrecht wird man als Privatmann nur selten verletzen ... ich habe jedenfalls bisher von AVM auch noch keine Post erhalten, ich solle meine Domains "yourfritz.de" oder "fritzsecurity.de" irgendwie an sie ab- oder einfach nur aufgeben.

Spoiler

Ich würde dem auch nicht ohne Rechtsstreit nachkommen, denn das einfache "fritz" ist von AVM eben nicht geschützt und für das Wort als solches - ohne die Großschreibung und das Ausrufungszeichen - hätte AVM vermutlich auch keinen Markenschutz erhalten; zumindest nicht in den derzeit betroffenen Nizza-Klassen und mit Unterlassungsanspruch auch bei der Benutzung durch andere, wo keine Verwechslungsgefahr besteht.

Bleibt also noch das Urheberrecht und da hat das LG Berlin eben geurteilt (wie oben zitiert), daß AVM nur an der Firmware als Ganzes keine Unterlassungsansprüche zustehen ... die Rechte von AVM, die nach §69c UrhG der Zustimmung durch AVM bedürfen (insb. die Rechte aus §§ 16, 17 UrhG), wird wohl kein Richter als "nicht verletzt" ansehen, wenn für die Verletzung eben die Zerlegung der originalen Firmware, ihre Änderung und das anschließende, erneute Zusammenpacken "zu einem Ganzen" erforderlich war. Solange das jeder für sich selbst ausführt, kann man ggf. noch mit §53 UrhG argumentieren.

----------------------------------------------------------------------------------------------------------------------------

AVM feiert (bzw. feierte, denn es war ja schon vor 7 1/2 Jahren) hier also einen "Sieg" in der Auseinandersetzung mit Cybits, der nicht wirklich einer war und es ist ja wohl mehr ein offenes Geheimnis, daß AVM vor diesem Urteil durchaus andere (ja, auch - mehr oder weniger - private Projekte, wie das IPPF) gerne mal dazu aufgefordert hat, die eigene Verbreitung - auch der unveränderten Firmware als Ganzes - zu unterlassen, obwohl AVM diese Rechte (zumindest aus dem Urheberrecht) gar nicht zustanden (nach dem Urteil des LG): https://www.ip-phone-forum.de/threads/ab-sofort-bitte-keine-firmware-patches-mehr-posten.65712/ - dort dann das zitierte Anschreiben von AVM in #1, wo es u.a. heißt:

Handelt es sich demgegenüber insbesondere um eine Veröffentlichung (d.h. Vervielfältigung, Verbreitung und/oder öffentliche Zugänglichmachung) von vollständigen (modifizierten oder nicht-modifizierten) Firmware Images, die urheberechtlich geschützten Code von AVM enthalten, steht dies eindeutig nicht im Einklang mit den Verwertungsrechten, die einem FRITZ!Box Kunden üblicherweise eingeräumt werden. Dies gilt unabhängig von der Frage, ob diese Firmware Images kostenpflichtig angeboten werden oder nicht. In solchen Fällen behalten wir uns vor, die erforderlichen rechtlichen Maßnahmen zu ergreifen und durchzusetzen.

(Merke: Nicht jede Behauptung in einem "offiziellen Anschreiben" muß auch der objektiven Realität entsprechen oder einer Überprüfung durch die Rechtssprechung standhalten - ob das dann als reine oder gar absichtliche Lüge (oder auch Benachteiligung/Nötigung eines potentiellen Konkurrenten) oder als läßlicher Rechtsirrtum (vor dem Urteil) angesehen wird, liegt oft im Auge des Betrachters und bedarf ggf. noch der Würdigung der mit einer solchen Behauptung verknüpften Intentionen.)

Für die Frage der unmodifizierten Firmware hat das LG Berlin das jedenfalls im Jahre 2011 deutlich geklärt ... für das Verbreiten von modifizierter Firmware, die ihrerseits AVM-Programme enthält, gibt es zwar kein ausdrückliches Urteil für/gegen AVM (afaik, anderslautende Informationen nehme ich immer gerne zur Kenntnis und in mein "Register" auf), aber kein vernünftiger Mensch wird hier behaupten wollen, die Rechte von AVM wären dabei nicht verletzt und solange dann keine schlüssige Argumentation vorgetragen werden kann, warum die Rechte von AVM hinter andere Rechte zurücktreten müssen, wird das wohl immer schlecht für den Verbreiter ausgehen, wenn AVM mal ernst machen sollte.

Um das noch einmal deutlich festzuhalten: Der Autor dieses Beitrags ist kein Jurist - er verfügt nur über gesunden Menschenverstand (denkt er zumindest) und ist in der Lage, sowohl Gesetze als auch entsprechende Urteile zu lesen, (weitgehend) zu verstehen und nach seiner Ansicht relevante Passagen zu zitieren, die ihm zur Aufdeckung von Zusammenhängen und zur Bekräftigung der hier vorgetragenen Ansichten (Meinungsäußerung nach §5 GG) dienen.

 

[NDiIPP]

Und ich hatte beim erstellen von Beitrag #60 schon überlegt, ob ich auch den 2. Satz des entsprechen Beitrages kommentiere. Zum Glück hatte ich das nicht getan, denn so fundiert und ausführlich wäre das bei mir nicht gewesen.

 

[stoney]

I.B.a. "Mod-Recovery" es wurde ja von @PeterPawn (auch wenn ich dieses fundamentelle Wissen nicht hatte und mir ehrlich gesagt auch nicht angelesen hätte) ausführlich erläutert.

Außerdem glaube ich, von jedem halbwegs versierten User, dass wenn er die Grundvorraussetzungenen auf einem Windows PC herstellen kann, könnte er sich auch den anderen Hilfsmitteln (und das auch noch plattformübergreifend) bedienen (Anleitungen wie man dies bewerkstelligt, sollten definitiv auffindbar sein [falls die nötigen Suchbegriffe getroffen werden]) und bei Fragen, sich einem der Threads anschließen, welche sich mit den einzelnen Möglichkeiten beschäftigen und falls man nichts passendes findet, erstellt man einen eigenen Thread, dieser kann ja verschoben oder gar mit einem bestehenden zusammengeführt werden - hier wäre die "Meldenfunktion" ein probates Mittel, falls es bereits woanders (ausführlich) behandelt wurde.

Vll. findet sich ja jmd. der ein Script schreibt / bereits geschrieben hat, welches das (Windows/Linux) Environment, vorher sichert, ändert und wieder zurücksetzt oder gar alles aus einem "Ordner" heraus mit einem Aufruf erledigen kann incl dem Downloaden der aktuellen FW vom AVM-FTP (anderenfalls kann man ja selbst ein passendes Image ablegen.... oder so - ich behaupte sogar, wer die JUIS-Abfrage mit den "Vorlagen" in Windows umsetzten kann, könnte/sollte auch diesem Belangen nachkommen können) - dieses in ein image.in-memory Format bringen und die Box dann im Bootloader zu fangen, um im Anschluss das Image in den RAM laden zu lassen. (Ansich sicherlich kein Hexenwerk, wenn man Zeit/Lust/Nutzen davon hat), Sollten mittlerweile mehr als genügend Infos vorliegen - und ich beschränke mich auf zwei Foren - um einen solchen Automatismus umzusetzten.

Spoiler: In diesem Fall zwar [OT - da es eh keine FW unter 6.93 gibt

aber ich erwähne es, da es ja dem Ein oder Anderen ja bei seinen Recherchen helfen könnte]
Wem dies nicht möglich ist bzw wer der Meinung ist, dies nicht "zu packen", dem empfehle ich den (ansonsten unnötigen und auch von mir nicht empfohlenen) Schritt des Downgrades (woher man die passenden Recovery's bekommt, sollte ja bekannt sein), wobei es bei einem Nandmodell ja wiederum nicht so "dramatisch" ist, wenn man sich die Version <=6.50 in einem der Partitionssets behält und von diesem aus immer das Update via GUI anstößt oder eben vorher linux_fs_start auf den Alternativwert ändert.

Die Möglichkeit mit dem Hex-Editor (habe es selbst noch nicht getestet, wollte ich jetzt aber machen) sollte ja dann ebenfalls möglich sein, für diejenigen, welche auf dem Windows-System das passende Environment herstellen können.

 

[DDD]

Ich weiß zwar auch nicht genau, was ein "Mod-Recovery" ist ...

Das hier: https://www.onlinekosten.de/forum/showthread.php?p=2485396#post2485396
und Download/bereitstellen war jetzt auch nicht so gedacht dass man es offiziell bei heise anbietet sondern z.B. ähnlich wie damals die die spezielle A400 Arcor Firmware durch nachfrage im Sammelthread Firmware zusendet.
Bzw. dass man es dann auch mal selbst 2-3 durchführen kann wenn man einmal ein Recovery damit gebaut hat.

 

[stoney]

Da wird doch nix gebaut, Problem ist halt, dass dieser Weg (wenn man nicht den über das in-memory Image geht und das ganze manuell macht) ebenso jedes mal auf neue gemacht werden muss incl dem damit verbunden Einstellungsverlust.

 

[DDD]

Wann muss er jedesmal neu gemacht werden? Nach jedem Online Update geht das verloren und muss neu gemacht werden oder wenn man den Mod für 7.01 gemacht hat und den für 7.10 nun auch haben will?
Das zweite wäre ja nicht unbedingt notwendig, wenn man danach einfach online aktualisieren könnte.

 

[stoney]

Das mit dem Recoverytool ist wenn dann nur möglich/sinvoll wenn man aus der 7520 eine 7530 machen will (wie sich das Update verhält teste ich, wenn ich von 7.02 (7530) auf >7.10 updaten kann) wenn es allerdings um die firmware_version geht, sieht's schlecht aus auf diesem Weg, ein Tool zum Bau eines AVM-Recovery-Tools kenne ich nicht, extrahieren von filesystem und kernel aus einer recovery.exe hingegen schon

-- Aktualisiert --

der Test zwecks Update einer 7520 mit der 7530 FW muss noch warten, da die 7520 ja mit 7.03 raus kam - aber mit der 7.02 FW (auf die Schnelle mal ein image2ram erzeugt, welches allerdings nach dem Flashen - blinkenden Info LED - in einer finstren LED-Lichterorgel endet) der 7530 nicht läuft (ggf. ähnlich wie bei der 7490 und den verschiedenen Bootloaderversionen und der "Downgradebarkeit" des FRITZ!OS).

Die 7530 ist mit 6.93 und die 7520 mit 7.03 gestartet und beide sind nun gleichauf mit der 7.10.

Aber vll. kann @PeterPawn das beantworte, ob die JUIS-Daten aus der FW gezogen oder über das Env generiert und weggeschickt werden (und wie sich das ggf. auf die Installation auswirkt - Danke).

 

[PeterPawn]

Ja, das ist eine gute Frage ... wenn die "HWRevision" direkt aus der OF-Beschreibung der Box kommt, dann spielt es eben auch keine Rolle mehr (sofern der Rest auch noch identisch ist), was die Firmware dort erwartet. Braucht es nicht länger den ODT in der "avm_kernel_config" oder gibt es den dort gar nicht, unterscheidet sich wohl auch der Kernel an dieser Stelle nicht wirklich zwischen der 7520 und 7530. Selbst wenn mal das Layout ein anderes sein sollte, müßte eigentlich genau dieser ODT dafür sorgen, daß der Kernel auch mit anderen GPIO-Pins zurecht kommt.

Solange das nur bei der Installation getestet wird (entweder vom Recovery-Programm oder eben von "/var/install" - wobei für beide die Quelle dieser Nummer ja wieder im ODT liegt) und nicht noch einmal innerhalb der installierten Firmware bei deren Ausführung, kann man die Firmware des einen Modells dann halt gegen die eines anderen tauschen, wenn es keine nicht vorhandenen Komponenten gibt oder man diese deaktivieren kann (über CONFIG-Variablen).

Ich bin mir nicht sicher, ob man sich bei AVM dieser Konsequenzen bewußt war (na gut, auch die 7412 war als kastrierte Version ja eher ein Rohrkrepierer, weil das "Aufbohren" viel zu leicht war, da man sich nicht viel Arbeit gemacht hatte) - wenn nicht und wenn man das künftig vermeiden will, wird sicherlich eine zusätzliche Abfrage Einzug in die Firmware halten.

Das sperrt zwar die "Hardcore-Modder" dann auch noch nicht aus (weil man diese Abfrage ja wieder ändern kann), allerdings könnte es dann den einfachen Austausch der Firmware verhindern.

Ob man nun das Recovery-Programm (für sich selbst) patcht und das dann einfach nicht an die große Glocke hängt (weil es eine Urheberrechtsverletzung bleibt, auch wenn kein Hahn danach kräht - aber man stellt sich ja auch nicht - außer als Poser - hin und gibt damit an, daß man für die 300m Spielstraße unter 10 Sekunden gebraucht hat) oder ob man einfach ein 7530-Image nimmt und es über den Bootloader installieren läßt, hängt sicherlich auch von den eigenen Fähigkeiten und vorhandenen Werkzeugen ab.

Ich bin mir einigermaßen sicher, daß lange nicht jeder Freetz-Benutzer (der sich dann aussuchen kann, ob er nun "make push_firmware" benutzt, sofern er den "non-genuine"-Fork verwendet oder doch "externe Tools" - wobei die eben gar nicht so extern sind und selbst dieser Fork wohl nicht länger ohne andere Tools aus genau derselben Quelle auskommen will) über ein Windows-System UND darauf dann auch noch über einen Hex-Editor verfügt UND den richtigen Offset unfallfrei findet UND die Änderung erfolgreich vornehmen kann. Da bietet sich natürlich - wenn er die Methoden über den Bootloader ohnehin beherrscht - der Weg über EVA dann auch wieder an.

Von der Benutzung eines "fremden" Recovery-Programms, bei dem ein anderer diesen Patch vorgenommen haben will (und genau auch nur diesen), würde ich persönlich (wie immer, wenn es dafür gar keine ersichtliche Notwendigkeit gibt) deutlich abraten ... der fehlschlagenden Signaturprüfung unter Windows ist es nämlich egal, ob da tatsächlich nur diese eine Änderung vorgenommen wurde oder ob da noch etwas anderes "huckepack" mitkommt.

Das Thema des einmaligen Impfens der Box mit einer Malware, die sich bei einem normalen Update selbst in die neue Version einpflanzt und damit über mehrere Updates reproduzieren kann, wenn sie die Box erst einmal infiziert hat, habe ich auch oft genug angesprochen ... kombiniert man das mit einem "provider"-Eintrag im Environment, läßt sich das nicht mal mehr mit einem Recovery-Programm (egal, ob mit oder ohne Patch für die HWRevision) entfernen und man muß dafür doch wieder zum Bootloader greifen.

Um endlich mal wieder auf die Frage zurückzukommen, was da von der Firmware bei einer JUIS-Abfrage verwendet wird ... das weiß schlicht ich auch nicht. Aber man kann die Abfrage ja einfach mal mitschneiden, wenn man die 7530-Firmware auf seiner 7520 hat - steht da wieder die 236 drin, sucht die Firmware nach der 7530-Firmware.

Steht da die 247 drin (was ich erwarten würde), macht die Firmware natürlich ein Update auf die nächste 7520-Version und man muß damit auf das automatische Update entweder gänzlich verzichten (auch auf das über eine Datei, weil man nicht einfach in der "/var/install" herumpatchen kann) oder es nachträglich (nach jedem Update) dann doch wieder von Hand korrigieren (mit dem Recovery-Programm oder eben direkt über EVA). Ob das dann immer derselbe Offset im Recovery-Programm ist (spätestens beim Wechsel der C-Library von MS würde ich eine Verschiebung erwarten - ggf. eine kleine), weiß ich auch nicht.

Wenn ich selbst vor der Aufgabe stehen würde, das automatisch so zu machen, daß die Firmware auch bei Updates immer diejenigen für die 7530 sucht (also die HWRevision 236 für diese Suche verwendet), würde ich als erstes mal versuchen, den Wert in der "juis_boxinfo.xml" zu ändern (die liegt ja beschreibbar in "/var/tmp") ... in der Hoffnung, daß die nicht nur von extern (das meint alles außerhalb der Box) abgerufen werden kann, sondern daß auch der "ctlmgr" bei der JUIS-Abfrage (die sollte da ihr Heim in der Prozessstruktur haben) auf diese Datei zurückgreift.

 

[NDiIPP]

Das hier: ...

Wie man in der Antwort von Peter in #61 gleich am Anfang lesen kann, ist es genau das, worauf er sich bezogen hat.

und Download/bereitstellen war jetzt auch nicht so gedacht dass man es offiziell bei heise anbietet sondern z.B. ähnlich wie damals die die spezielle A400 Arcor Firmware durch nachfrage im Sammelthread Firmware zusendet.

Hmm. Also es geht hier ja um eine vergleichsweise einfache oder kleine (und imo ausreichend gut beschriebene) Änderung bspw. per HEX-Editor an einem bestimmten Wiederherstellungs-Tool von AVM. Das sollte man nun wirklich auch selbst hinbekommen, ohne danach erst irgendjemanden fragen zu müssen, der einem das auf Nachfrage erst zusenden muss (das ist vermutlich noch mehr Aufwand, als die Änderung einfach mal durchzuführen). Der Aufwand für einen solchen "Service" ist meiner Ansicht also nicht wirklich gerechtfertigt (unabhängig noch von der Betrachtung bzgl. Urheberrechte, was das ganze imo noch absurder macht für eine solch kleine Änderung).

Zudem auch das bereits erwähnte Problem bzgl. der Signatur besteht, welche anschließend ungültig ist (per Bootloader kann man einer Fritzbox ja nach wie vor beliebig manipulierte Images unterschieben, weshalb es meiner Ansicht nach wichtig ist, dass die Signatur eines Recovery-Tool vom AVM gültig ist (es sei denn man weiß selbst, was man daran geändert hat)).
Also deshalb sollte man also diese Änderung selbst durchführen denn sonst könnte man dir ein x-beliebiges Recovery-Tool zusenden, welches eben nicht nur die beschriebene Änderung enthält, sondern auch gleich noch ein paar andere "nette" Features. Allein das ist schon ein weiterer relevanter Punkt, weshalb man deinen Vorschlag niemals umsetzen sollte!

Wer in der Lage ist, das zugesendete (manipulierte) Wiederherstellungs-Tool mit dem Original von AVM zu vergleichen (um zu sehen ob tatsächlich nur die gewünschte Änderung enthalten ist und keine weitere), kann die Änderung am Original auch wieder gleich selbst umsetzen. Für alle anderen gilt dann: Imo besser Hände weg, wenn es schon an solch einfachen Aufgaben scheitert.

 

[PeterPawn]

Witzig ... bei der c't ist es jetzt einem Redakteur gelungen, im Schweiße seiner Füße aus einer 7520 eine 7530 zu machen. Dazu setzt er halt "HWRevision" im Bootloader-Environment auf den richtigen Wert für die 7530 und läßt danach das Recovery-Tool für die 7530 auf dieses Gerät los (ohne Power-Cycle, weil ansonsten die Modifikation der "HWRevision" natürlich wieder weg wäre) - zumindest geht das für mich so aus dem Erzählten hervor, denn den Beitrag im Heft habe ich nicht gelesen (mein Abo ist inzwischen lange eingestellt, nach über 30 Jahren Treue).

Ich finde das durchaus interessant als "Ansatz" ... allerdings tatsächlich eher die "Recherche-Resistenz" eines c't-Redakteurs, wenn er das wirklich alles selbst ermittelt hat/ermitteln mußte, nachdem er - wie berichtet in dem Podcast, der Teil geht von ca. 1:13 bis 16:39 min - die beiden Boxen aufgeschraubt und die PCBs miteinander verglichen hat.

Erstaunlich finde ich das u.a. auch deshalb, weil das IPPF ja nun alles Mögliche ist, aber bestimmt keine "anrüchige Quelle", wenn es um die Möglichkeiten der Modifikation von FRITZ!Boxen geht und da stellt man sich dann schon unwillkürlich die Frage, was ein Journalist (ich unterstelle mal, daß ein c't-Redakteur zumindest die "Grundbegriffe" des Journalisten-Handwerks beherrschen sollte und da gehört "Recherche" ja nun zum kleinen Einmaleins, selbst wenn er "nur" ein Volontariat macht) so alles anstellen muß, um sooo wenig von der Welt um ihn herum und "da draußen" (in den Weiten des Neulands) zur Kenntnis zu nehmen.

Spaßig ist es halt auch, wenn so ein technischer Redakteur (und er befaßt sich ja nach den Aussagen und den bisher veröffentlichten Artikeln doch etwas eingehender mit den Boxen) dann an AVM die "unangenehme Frage" stellt bzw. stellen muß (bei 12:34 min), ob es schon zuvor irgendwelche Geräte gab, die lediglich per Software "gedrosselt" wurden und dann - später im Podcast und in leicht anderem Zusammenhang - stolz eine 7412 in die Kamera hält (und in 02/2020 auch einen Artikel zur 7412 geschrieben hatte).

Ich würde hier halt erwarten, daß so jemand dann auch von der "alten Geschichte" im Hinblick auf das "1&1-DSL-Modem" (ab Routerfreiheit) und das "1&1-WLAN-Modem" irgendwann schon einmal etwas gehört oder gelesen hat.

Aber ich habe da vermutlich ohnehin deutlich zu hohe Erwartungen ... jetzt warte ich halt darauf, daß er (dann wirklich "investigativ") noch eine Anleitung veröffentlicht, wie man die "Geburtsdaten" einer 7520 im Bootloader so abändert, daß danach auch tatsächlich die Firmware-Updates für die 7530 automatisch eingespielt werden können ... denn das fiel wohl erst nach Redaktionsschluß auf, daß die Box nach wie vor die Updates für die 7520 installieren will und das scheitert - naturgemäß - schon daran, daß für das Signieren der Firmware bei beiden Modellen unterschiedliche Keys verwendet werden, deren "public parts" dann halt in der jeweils installierten Firmware liegen.

Vielleicht gelingt es ihm bis zum nächsten Artikel zu diesem Themen-Komplex aber auch zu ermitteln, wie genau die FRITZ!Box nach einem Update sucht (ab 5:30 min geht es darum in dem Podcast) und da wird das dann auch beschrieben ... es sind halt "aufregende Zeiten". Aber wenn jetzt schon (Technik-)Journalisten nicht mehr richtig recherchieren (können) oder es tatsächlich (auch bei sinnvoller und systematischer Recherche) keine ergiebigen Fundstellen über die großen Suchmaschinen mehr gibt, dann liegt wohl einiges im Argen.

 

[NDiIPP]

... - zumindest geht das für mich so aus dem Erzählten hervor, denn den Beitrag im Heft habe ich nicht gelesen

Da ich den Artikel (dank Abo) lesen konnte, kann ich das so bestätigen.

In diesem Sinn (bzgl. Fritzbox im Allgemeinen) ist vielleicht auch der Artikel "Box für die Tonne" auf Seite 32 interessant. Durchaus kein uninteressanter Artikel, insb. im rechtlichen Zusammenhang. Es geht dort um ehemalige/gebrauchte 6490er von Unitymedia, welche von einem Händler in größerem Umfang mit der Retail-Firmware versehen und ohne angebliche Einschränkungen an Endkunden verkauft wurden bzw. werden sollten. Dies hat AVM gerichtlich untersagen lassen. Auch der c't-Autor dieses Artikels stellt sich erst einmal auf den Standpunkt ein, dass es praktisch keinen Unterschied zwischen der Retail-Version und dieser aufbereiteten UM Version gibt und somit für den Endkunden erst einmal kein Unterschied bei der Verwendung feststellbar sein sollte.
Leider wurde aber in diesem Artikel mit keinem Wort auf den Umstand hingewiesen, das ggf. die CM-MAC bei UM (bzw. nun Vodafone West) auf einer Blacklist steht und somit u.U. an einem solchen Anschluss nicht direkt verwendet werden kann.

Erinnert mich ein wenig an einen c't-Artikel zur 7580, wo der Autor behauptete, man könne diese Box nicht mehr an DSL-Anschlüssen mit Splitter betreiben. Aber dafür hätte sie ja nun einen Ethernet-WAN Port, wo man ein externes DSL-Modem anschließen könne, um sie auch an solchen Anschlüssen mit Splitter einsetzen zu können. Die Mühe den Autor auf dieses Missverständnis (bzw. Fehler) hinzuweisen hätte ich mir wohl sparen können, hatte den Eindruck, das Problem wurde nicht so richtig von ihm verstanden.

... jetzt warte ich halt darauf, daß er (dann wirklich "investigativ") noch eine Anleitung veröffentlicht, wie man die "Geburtsdaten" einer 7520 im Bootloader so abändert, daß danach auch tatsächlich die Firmware-Updates für die 7530 automatisch eingespielt werden können ... denn das fiel wohl erst nach Redaktionsschluß auf, daß die Box nach wie vor die Updates für die 7520 installieren will und das scheitert - naturgemäß - schon daran, daß für das Signieren der Firmware bei beiden Modellen unterschiedliche Keys verwendet werden, deren "public parts" dann halt in der jeweils installierten Firmware liegen.

Diesbezüglich erlaube ich mir mal einen kleinen Ausschnitt aus dem Artikel zu zitieren (ich denke, das dürfte kein Problem sein, oder doch?) und zur Diskussion zu stellen:

[...]
Uns gelang die Modifikation jedoch nur mit dem 7530-Recovery-Tool der Version 7.14 und auch nur, wenn zuvor FritzOS 7.14 auf der 7520 lief. Vorherige Versuche, die 7520 mit einer alten Version der 7530-Firmware zu flashen, um den Webupdater zu testen, scheiterten allesamt. Eine 7530-Firmwaredatei für FritzOS 7.14 akzeptierte die Mod-7520 im Webinterface aber anstandslos – ein Anzeichen dafür, dass zumindest das händische Update funktioniert.
[...]

Aber falls der Autor des Artikels hier vielleicht doch mal vorbeischaut: Die MAC-Adresse ist es offensichtlich nicht (bzgl. Web-Upate)...

 

[PeterPawn]

6490

Bin ich mal gespannt, wie sich der Fall weiter entwickelt ... gegen einen Händler hat AVM halt - auch über das UWG, selbst wenn hier wohl das Markenrecht herhalten soll - deutlich mehr Handhabe, als gegen das "Refurbishing" von Privatleuten. Denn Urheberrechtsgründe (hinsichtlich des "Mißbrauchs" der AVM-Firmware für ein anderes Modell, auch wenn hier nur die Nummern und die äußere Anmutung tatsächlich unterschiedlich sind im Vergleich zur Retail-Version) sind hier ebenso unbegründet, wie beim Download von (unveränderten) Firmware-Images, sofern diese GPL-Software (o.ä. Lizenzen, die eine Verwendung/Verbreitung entgegen der AVM-Bestimmungen dann doch wieder erlauben) enthalten.

Aber da sich ja tatsächlich keine (bisher bekannten) Verschlechterungen ergeben, solange die CM-MACs der verkauften Boxen nicht von den Betreibern gesperrt sind (denn eine Einschränkung: "Funktioniert nur im Netz von A und B, aber nicht in dem von C." ist natürlich schon eine recht tiefgreifende Beschränkung, auch wenn der Händler darüber ggf. sogar transparent informiert - da hat AVM beim passenden Richter vielleicht sogar noch Glück mit der Argumentation), dürfte nach wie vor das "nicht gewerbsmäßige" Aufpolieren der Boxen kein wirkliches Problem sein.

7520 bzw. 7530

Hier bin ich einigermaßen verblüfft, wobei ich aus dem Zitierten auch nicht ganz schlau werde. Wenn die "Mod-7520" am Ende eine ist, die mit der Firmware der 7530 arbeitet, dann beschränkt sich der Vergleich in der "var/install" ja auf den Wert von "CONFIG_INSTALL_TYPE" (über die "/etc/version") und der wird aus der laufenden Firmware gesetzt, komplett ohne Ansehen der Box, auf der die Firmware gerade läuft.

Dann gibt es ja auch kein Recovery-Programm (keinen FTP-Client), der das Bootloader-Environment mit der vorliegenden, neuen Firmware vergleicht. Insofern sollte so ein Update über das GUI, mit einer Firmware für dasselbe Modell wie die derzeit laufende, eigentlich immer funktionieren oder zumindest nicht an "Unverträglichkeiten" scheitern - das gilt für die bisher bekannten Images und natürlich gibt es auch bei passender Firmware ab und an mal Probleme beim ersten Anlauf für ein Update (das füllt hier ganze Threads).

Da die beiden Boxen (bzw. AVM) aber tatsächlich unterschiedliche Keys zum Signieren der Images verwenden:

inspect_image, version 0.8

Copyright (C) 2018-2020 P.Hämmerlein ([email protected])

This script is a part of the YourFritz project from https://github.com/PeterPawn/YourFritz.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU
General Public License as published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License under http://www.gnu.org/licenses/gpl-2.0.html for more details.

--------------------------------------------------------------------------------------------------

Device uses NAND flash to store kernel and filesystem.
SquashFS version used: 4
SquashFS compression used: xz
SquashFS endianess used: little

>>>>> Output of 'extract_version_values' <<<<<
Model="Fritz_Box_HW247"
Product="FRITZ!Box 7520"
Date="08.11.2019 13:45:29"
Version="175.07.14"
Subversion="-73182"
Buildnumber="73182"
Buildtype="1"
Brandings="1und1 avm"
Release="1"
BetaRelease="0"
LaborName=""
DirtyBuild=""
InstallType="arm_128MB_cortexa9_2geth_usb_host_2wlan11n_dect_vdsl_02249"
KernelVersion="4.4.60"
LibraryProject="uClibc-ng"
LibraryVersion="1.0.14"
LibraryIdent="uClibc-ng-1.0.14"
BootType="rc.S"
PublicKey1="00c9416c9dae6096459487e0e7f8f44536228fbf681e8963f0ad711583b413a5831fe284b734c1cb147018c9d1abe9ffde95d72b329f087337286a53f6c06cbbeb850eb990c37e313e797a113e403421b2da254b58e698bcc7cc887257ddbfd98e183defeedd36f645003ff6e704d504fc3f57150a8c474f4b1540a9df5da3c0c1"
PublicKey2="00fc4f870ad6243712ba49f57f1bf243073a0157d11005d3aa0a85649d473d161f039d3dc9d10a7553c74f9292ca3f7c8bd94eba9b6f0aa4b992c3b493a57cd6f518c291b721aa82ef15c2dd67f8a00751b58199b9790d979e41616a15fdd37aff7ba51314e722f33d853db3050ddfad14b30a448c944c2aea701f9f8c34203ad7"
PublicKey3="00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849"
>>>>> ================================== <<<<<

The unpacked filesystem structure may be found at:

/tmp/tmp.3dOdgT3EiM/20486_inspect_image/fs

Please use another terminal session to inspect or backup data from the location above.

If you've done with it and want to continue, the whole working directory

/tmp/tmp.3dOdgT3EiM/20486_inspect_image

gets deleted - any possibly open file(s) within, will lead to an orphaned directory, which has to be removed manually.

Do you want to continue/exit? Enter 'x' / 'q' (eXit/Quit):

vs.

inspect_image, version 0.8

Copyright (C) 2018-2020 P.Hämmerlein ([email protected])

This script is a part of the YourFritz project from https://github.com/PeterPawn/YourFritz.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU
General Public License as published by the Free Software Foundation; either version 2 of the
License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License under http://www.gnu.org/licenses/gpl-2.0.html for more details.

--------------------------------------------------------------------------------------------------

Device uses NAND flash to store kernel and filesystem.
SquashFS version used: 4
SquashFS compression used: xz
SquashFS endianess used: little

>>>>> Output of 'extract_version_values' <<<<<
Model="Fritz_Box_HW236"
Product="FRITZ!Box 7530"
Date="08.11.2019 13:46:33"
Version="164.07.14"
Subversion="-73183"
Buildnumber="73183"
Buildtype="1"
Brandings="1und1 avm"
Release="1"
BetaRelease="0"
LaborName=""
DirtyBuild=""
InstallType="arm_32MB_cortexa9_plc_1geth_wlan11n_Dect_vdsl_63849"
KernelVersion="4.4.60"
LibraryProject="uClibc-ng"
LibraryVersion="1.0.14"
LibraryIdent="uClibc-ng-1.0.14"
BootType="rc.S"
PublicKey1="00a199d98aaa5ff1a8f9a9f8f956930470ae533fd6a4731468acf686cd2234a6ba4ae17798ec93a5862a56baf1ff3741ea13c4fb35a4ca76df9be66eb0b2c0d3d7f271cc061f394f201b62290d8a9d8695735aa3dafb54a43e3521b4df42c5e52188228b8e133079872bdd7357ceb7379336715e9b50f2d2e678dc79e90c231d8f"
PublicKey2="00b7ad86f7002a3539a54a5c65b42ae58b018a3563e64468a96f13d870a259c668111110390964c06062d198a6ef91b840da862b666a8080760217369cc2e352860abb9d0f30e2e4c13ed0ef4a10b90a6031b5ddef3cf09c08759b3d98dbe4392c6539f6a322cd3cdec115bc737066d54fb82cd59ce066abccd7dfe7c775b96cb1"
PublicKey3="00f2ee9ffd8556211f5644da48a252b107124b330d4c20dcf3b9bac892924cabaa4df4f53e1c62e3f2aa12a23eb1d770df1520a998078738407e6a71b077f73ba976363836b880b0dd88741bc3b83ab061691226e823404b7fc88ed278d8130fe5336eb925c78f2f8ad7cb87d9586286f768ab3236fa8fb51ae7c4bbe1e041d849"
>>>>> ================================== <<<<<

The unpacked filesystem structure may be found at:

/tmp/tmp.IV7KUvMEnc/20726_inspect_image/fs

Please use another terminal session to inspect or backup data from the location above.

If you've done with it and want to continue, the whole working directory

/tmp/tmp.IV7KUvMEnc/20726_inspect_image

gets deleted - any possibly open file(s) within, will lead to an orphaned directory, which has to be removed manually.

Do you want to continue/exit? Enter 'x' / 'q' (eXit/Quit):

, scheitert ein (Cross-)Update (zwischen 7520 und 7530 bzw. umgekehrt) über das GUI auch nicht erst an der Prüfung von "CONFIG_INSTALL_TYPE", sondern bereits an der Prüfung der Signatur (der dritte Key ist für Zubehör-Firmware und deshalb in beiden derselbe).

Auch der Satz:

Vorherige Versuche, die 7520 mit einer alten Version der 7530-Firmware zu flashen, um den Webupdater zu testen, scheiterten allesamt.

erscheint mir eher sehr logisch, wenn diese "vorherigen Versuche" über das GUI abgelaufen sein sollten ... denn dann wäre das ein Downgrade (mal ganz abgesehen vom Konflikt hinsichtlich der "CONFIG_INSTALL_TYPE"-Variablen, wenn da eine 7520-Firmware läuft und eine 7530-Version installiert werden soll, s.o.) und ein solches Downgrade funktioniert nicht einmal mehr mit der passenden Firmware, wie wir alle (zumindest als "fleißige IPPF-Leser") wissen.

Wenn diese Versuche aber über ein Recovery-Programm für eine ältere 7530-Version gemacht wurden und dabei auch dieselben Schritte ausgeführt wurden, wie beim (schlußendlich erfolgreichen) Einsatz der Version 07.14, dann erscheint mir die Feststellung durch nichts begründet und ich würde hier auch wieder eher auf einen Fehler in der Handhabung tippen, als auf ein echtes Problem.

Ansonsten wüßte ich schon gerne noch ein paar Einzelheiten oder hätte gerne eine plausible Erklärung, warum ein Update über den Bootloader fehlschlagen sollte. Das in der Firmware beim Start aus dem RAM zum Flashen verwendete Skript (/etc/init.d/E03-flash_update), ist jedenfalls das "übliche", wenn es um NAND-Flash mit UBI-Partitionen geht (Sizes: 44 / 44 / 2 / Rest - alles in MB - und damit natürlich auch wieder mit dem Löschen des Dateisystem-Images in der alternativen Partition verbunden, wenn man mit dem Recovery-Programm von AVM auf die 7520/7530 losgeht und das sein ",recovered=2" in "firmware_info" setzt) und dieses Init-Skript führt keine weitere oder erneute Prüfung, ob das überhaupt eine passende Firmware ist, durch. Wurde das System aus dem RAM gestartet (wo das Recovery-Programm es hinschreibt) und es gibt die Partitions "kernel_ram" und "rootfs_ram" in "/proc/mtd", dann wird auch in den Flash geschrieben - solange es von der Größe her irgendwie noch paßt.

 

[NDiIPP]

Wenn die "Mod-7520" am Ende eine ist, die mit der Firmware der 7530 arbeitet, ...

Ja, also kein "Cross-Update". Das schließe ich zumindest aus dem Artikel (also auf der 7520 lief zu diesem Zeitpunkt FRITZ!OS 7.14 für die 7530, welches zuvor per Recovery-Tool aufgespielt wurde). Somit dürften die Schlüssel (key1 und key2) in diesem Fall passen.

Auf das (automatische) Web-Update sollte man in diesem Fall wohl verzichten.

---

EDIT:

Bzgl. Recovery-Tool <7.14:
Ich kann mich täuschen aber irgendwie habe ich es (dunkel) in Erinnerung, dass wohl mal von Problemen mit ein paar älteren Recovery-Tools für die 7520/7530 hier im Forum berichtet wurde. Vielleicht ist da eine Ursache für das beschriebene Problem des Autor zu finden. Oder aber er hat bei diesen Versuchen zwischendurch die Box neu gestartet (REBOOT oder Unterbrechung der Stromzufuhr anstatt BYE/QUIT) und somit wurden die eingestellten Werte zurückgesetzt.

 

[Theo Tintensich]

In dem Artikel steht auch, dass die beiden Modell licht unterschiedlich bestückt sind.
Entweder es sind zwei aufeinander folgende Platinenlayouts, oder sie haben in einigen Bereichen doch Unterschiede.
Wen man sich die beiden Platinenbilder im Artikel ansieht, sieht man im linken Bereich ein paar Unterschiede.

 

[NDiIPP]

In dem Artikel steht auch, dass die beiden Modell licht unterschiedlich bestückt sind.

Das ist imo eher darauf zurückzuführen, dass da Mainboards mit unterschiedlichen Produktionszeitpunkten verglichen wurden. Die Unterschiede würde ich jedenfalls nicht, so wie es der Autor des Artikels getan hat, auf 7520 oder 7530 zurückführen sondern eher auf das jeweilige Produktionsdatum des Mainboard. Man findet im Internet noch mindestens 2 weitere leicht unterschiedliche PCBs, also insg. schon 4 verschiedene für 7520 und 7530... Und die eine Version einer 7520 ähnelt da auf einmal mehr der Version der 7530 aus dem c't-Artikel.

Edit:
Solche kleineren Unterschiede bei der Bestückung sieht man bspw. auch schon bei gleichen Modellen (bspw. 7490) und das tw. sogar bei gleicher HW-SubRev. Da wechseln also durchaus auch mal die Hersteller entsprechender Bauteile (bspw. mal Transceiver von Würth Electronic, mal von Delta usw.) Würde ich jetzt also einfach mal darauf schieben, dass man das nimmt was gerade am Markt (günstig) in der gewünschten Menge verfügbar ist. Bzw. die Ausschreibung/Bestellung erfolgt herstellerneutral.

 

[gjaekel]

Witzig ... bei der c't ist es jetzt einem Redakteur gelungen, im Schweiße seiner Füße
[...] zumindest geht das für mich so aus dem Erzählten hervor, denn den Beitrag im Heft habe ich nicht gelesen (mein Abo ist inzwischen lange eingestellt, nach über 30 Jahren Treue).

Hallo PeterPawn, Hallo Ihr alle,

tja - so ist das halt, wenn man älter wird - und es ist völlig normal: Auch ich bin jetzt über 50 und auch ich kenne die c't seit ihrer ersten Ausgabe. Und die Mitarbeiter dort, die noch technisches Wissen in einer Breite *und* Tiefe mitgebracht und ausgebaut haben wie andere aus dieser Generation, die sind mehr oder weniger bereits alle in den Ruhestand gegangen. Und die Nachrücker haben das einfach nicht - woher auch.

Sich darüber auszulassen ist zwar verständlich und amüsant für die Teilnehmer hier, aber letztlich vertane Zeit. Viel wichtiger ist die Basisarbeit in der Community hier und ich möchte meinen persönlichen Dank an alle hier aussprechen, die -- wie insbesondere PeterPawn und noch andere hier -- sowohl in der Lage als auch dazu bereit sind mit so vielen Stunden ihrer privaten Zeit dazu beizutragen das so viele andere davon unentgeltlich profitieren dürfen.

Mit großem Respekt und bitte "weiter so!"
Guido

 

[Theo Tintensich]

tja - so ist das halt, wenn man älter wird - und es ist völlig normal: Auch ich bin jetzt über 50 und auch ich kenne die c't seit ihrer ersten Ausgabe. Und die Mitarbeiter dort, die noch technisches Wissen in einer Breite *und* Tiefe mitgebracht und ausgebaut haben wie andere aus dieser Generation, die sind mehr oder weniger bereits alle in den Ruhestand gegangen. Und die Nachrücker haben das einfach nicht - woher auch.

Ich bin der Meinung, dass auch die aktuellen neuen Jedakteuere ein hervorragendes techniches Wissen haben.
was sich aber geändert hat, ist das Wisser den langjährigen Leser.
Was von x Jahren noch böhmische Dörfer waren, kennen sie, auch wegen des Lesens der c't sehr viel besser als damals™
und dadurch erscheinen die Artikel einfacher.

 

[gjaekel]

Lieber Theo,
auch wenn ich sie nicht komplett teile will ich Dir Deine Meinung gerne lassen, ja bestimmten Teilen sogar völlig beistimmen! Wir leben doch nun aber mal in der freien Marktwirtschaft. Und da wird auch eine Zeitschrift wie die c't in die Richtung entwickelt wo "man" meint eine Zielgruppe zu sehen. Und die war in den Anfängen garantiert kleiner, viel Treuer und -- da gebe ich Dir recht -- wusste selbst noch nicht so viel und hat daher alles aufgesaugt. "Man" ist auch der Heise-Verlag, der -- wie es der Zeitgeist ist -- mit seiner inflationären Entwicklung des Angebots an Zeitschriften-Formaten (verzweifelt?) seine Marktanteile und Marktpräsenz "sichern" will. Wohin aber aktuell die Reiseroute der c't hinzeigt, sieht man an der eingeführten Kennzeichnung von Artikeln als "hard core" -- wozu nun scheinbar alles mit ein wenig Substanz zählt -- und der "Preiserhöhung" durch die Einführung von "heise+".

Leute, die *das* hier lesen, sind halt heutzutage nicht mehr die primäre Zielgruppe der c't. Nur die Leute, die damit überfordert sind *das* hier (und alle vergleichbaren Informationen zu anderen Themen) zu finden sind doch in der breiten Masse diejenigen, die eine c't kaufen. Überfordert meint hier nicht unbedingt gleich intellektuell, sondern auch zeitlich. Eine Zeitschrift ist ja auch ein Aggregator und Filter.

Ja, das alles liegt sowohl an uns als auch an den aktuellen "Machern" der c't. Ist hat so, hat keiner Schuld 'dran. PeterPawn schrieb ja "ich hab's abbestellt". Kann man einfach machen, auch dabei *ohne* den Gedanken im Kopf zu haben "So, jetzt zeig ich's denen aber!"

Weil das aber doch wohl eher off-topic ist, will ich hier auch nicht weiter posten.
Grüße
Guido

 

[betaman2]

...zum Thema:
Z.Zt. ist bei mir eine 7530 "zu Gast".
Weil ich eine 7520 als DSL-Router betreibe, interessiert mich das Thema "aufbohren".
Mit Hilfe der .export Dateien und Notepad++ habe ich das Innenleben beider Boxen inspiziert.
Dabe habe ich schon mal einen (sicher wichtigen) Unterschied gefunden:

Ausschnitte:
1.
**** FRITZ!Box 7530 CONFIGURATION EXPORT
Password=$$$$MJR63I1EWTG3MIFNWDGNMVMJ4CKJKIXTOUDITFBXYNFYNLDSNRPCNGDFZGQGJNHWUBCZPUU5V6IIF1UIHU6X4N4RSJKJA1U61S6F4FIA
FirmwareVersion=164.07.14
CONFIG_INSTALL_TYPE=arm_32MB_cortexa9_plc_1geth_wlan11n_Dect_vdsl_63849
OEM=avm
Country=049
Language=de
**** CFGFILE:ar7.cfg
/*
* /var/tmp.cfg
* Tue Mar 31 11:13:33 2020
*/

meta { encoding = "utf-8"; }

2.
**** FRITZ!Box 7520 (UI) CONFIGURATION EXPORT
Password=$$$$AISCHYKDDZMML6D43G3UL2YKFWAZXFENONSRFNSIXZXX16CYRIGRO4LLAKRO6F3VGDXUECJU1ZKSVJTLR5GB4OUIUVJVFH2UGYH4Z5AA
FirmwareVersion=175.07.14
CONFIG_INSTALL_TYPE=arm_128MB_cortexa9_2geth_usb_host_2wlan11n_dect_vdsl_02249
OEM=1und1
Country=049
Language=de
**** CFGFILE:ar7.cfg
/*
* /var/tmp.cfg
* Sat Dec 7 12:56:53 2019
*/

meta { encoding = "utf-8"; }

Die .support Dateien nehme ich als nächstes unter die Lupe.

Übrigens: die 'ct-Methode des Fw-Updates hat bei mir noch nicht funktioniert...
Die 7530 ist in puncto mesh zumindest bei mir noch etwas störrischer als die 7520!

 

[PeterPawn]

Dabe habe ich schon mal einen (sicher wichtigen) Unterschied gefunden:

Hmm ... ich sehe da - beim Vergleich der beiden Ausschnitte - sogar nur 57% Übereinstimmung, bezogen auf die Zeilen (8 von 14 Zeilen sind identisch, 6 unterscheiden sich).

Aber ich mag mich auch irren ... die anderen sind vermutlich weniger wichtig, während Du es für die farblich markierte Zeile offenbar genau weißt, wenn Du Dir sicher bist (nach Deinen Worten).

Die Frage, die sich mir hier stellt, wäre jetzt: Was heißt das am Ende? Welche Konsequenzen ergeben sich aus diesem Unterschied? Sind die Geräte tatsächlich vergleichbar?

Ich würde ja schon tippen, daß die beiden Geräte sogar unterschiedliche Gehäusefarben haben (eines in 1&1-Schwarz und das andere in den "AVM-Farben") ... und Du uns diesen Unterschied (vermutlich auch eher "unwichtig", aber man kann das ja auch nie so ganz genau wissen) nur unterschlagen hast.

Wenn Du Dich jetzt fragen solltest, warum das irgendwie so klingt, als würde ich das nicht so 100% bierernst betrachten, dann empfehle ich Dir den "Rückblick" in diesem Thread (es reicht schon diese Seite), denn da habe ich erst vor kurzem u.a. genau diesen Unterschied zwischen der 7520- und 7530-Firmware gezeigt (wenn auch anhand der Firmware-Images und nicht anhand einer Export-Datei) und auch versucht zu erklären, welche Auswirkungen dieser Unterschied hat und wo er überhaupt "bemerkt" wird von der Firmware (nämlich in der Installationsdatei eines Firmware-Updates, welches auf den Namen "install" hört und sich im Unterverzeichnis "var" eines Firmware-Images befindet).

Und wenn die Methode, welche in der c't beschrieben wurde, bei Dir nicht funktioniert, dann hast Du entweder nicht die passenden Gerätschaften (FRITZ!Box, Firmware, Windows-PC, ggf. noch Netzwerkzubehör) oder Du machst tatsächlich etwas falsch bei der Umsetzung. Das ist nichts, was bei dem einen eben funktioniert und bei dem anderen (prinzipiell) nicht ... die 7520 als 1&1-Version hat auch keine "provider additive"-Konfiguration, so daß das Recovery-Programm der 7530 davon beeinflußt werden könnte. Zumal ein "hat bei mir noch nicht funktioniert" als Fehlerbeschreibung halt auch etwas dünn wäre ... daher gehe ich auch nicht davon aus, daß Du damit hier nach Hilfe zur Lösung Deines Problems suchen wolltest.

Wobei es (zumindest für manchen) auch einfacher ginge als auf dem in der c't beschriebenen Weg (soweit er mir berichtet wurde bzw. ich ihn mir zusammenreimen kann aus dem Gehörten und Gelesenen) ... lädt man gleich das (passend aufbereitete) Image eines 7530-Updates über EVA in den Speicher der 7520 und läßt es dort starten, fällt der ganze Mumpitz mit der temporären Änderungen von "HWRevision" weg.

Allerdings sollte man zuvor die 7520 dann (sicherheitshalber) noch auf Werkseinstellungen gebracht haben (und das noch ohne den anschließenden Neustart mit der alten 7520-Firmware, weil sonst gleich wieder die Default-Einstellungen der 7520 geladen werden), wenn man nicht ganz genau weiß, wie man das ansonsten hinterher (falls die Box nach dem Update nicht sauber starten will, weil noch Reste einer 7520-Konfiguration herumfliegen) bewerkstelligen soll - denn dann kommt man ggf. weder ins GUI für eine solche Aktion, noch funktionieren irgendwelche Telefone.