Richtlinie 2014/53/EU eine Gefahr für Freetz?
- Ersteller JokerGermany
- Erstellt am
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,285
- Punkte für Reaktionen
- 1,755
- Punkte
- 113
Eher nicht (der andere Thread dreht sich ja um OpenWRT und die Beteiligung ist ausgesprochen rege und auf den Punkt in der Diskussion), denn Freetz ändert am WLAN-Teil der Box mal genau nichts.
Eine komplette Verriegelung (Tivoisierung) wäre zwar denkbar, aber m.E. unwahrscheinlich - AVM dürfte dann vor demselben Problem stehen, wie es der DD-WRT-Entwickler im gestrigen Interview mit heise.de auch skizziert hat (GPL-Verstoß mit "geheimem" DRM für den WLAN-Treiber im Kernel vs. Veröffentlichung der Quellen mit der Möglichkeit der Analyse und des Nachbaus).
Ein komplettes eigenes Betriebssystem für die FRITZ!Box ohne Linux-Kernel ist sicherlich (im Moment) blanke Utopie ... ich zweifele ja schon immer im Stillen an den Behauptungen von Bintec/elmeg, daß deren OS so vollkommen ohne Anleihen bei Open-Source-Software auskommen soll. Aber ich will es einfach mal glauben, deshalb kommt mir auch definitiv kein solches Gerät ins Haus, denn parallel dazu glaube ich dann eben auch an Spionagefunktionen und/oder Hintertüren und/oder Sicherheitslücken in solchen proprietären Systemen - schwer für den Hersteller, deren Abwesenheit zu "belegen", wenn es keine Quellen gibt. Wenn ich mir nur überlege, wieviele Fehler man bei der Implementierung eines eigenen IPSec-Stacks machen kann (auch AVM ist da m.E. auf einem "Holzweg"), dann beschäftigt entweder Bintec/elmeg eine Legion der fähigsten Entwickler in D (und das meine ich tatsächlich im Sinne der altrömischen Legionen mit ihrer Personalstärke) oder das ist einfach nur der "Nischencharakter" dieser Geräte, der sie für Angreifer so uninteressant macht.
Für neue Geräte mag AVM so etwas ja (mit technischen Maßnahmen und einem abgewandelten Design) realisieren können, bei den aktuell vertriebenen wäre das ein tiefer Eingriff in den Bootloader, der zwar jedem ohne JTAG-Zugriff erst einmal die Suppe versalzen würde, aber dann brummt eben das Geschäft mit (E)JTAG-Adaptern ab diesem Zeitpunkt - auch so ein Bootloader ist ja keine "rocket science", wie man an "u-boot" sehen kann (der ginge auch auf einer FRITZ!Box). Ich erinnere nur an dbox/dbox2 usw. ... die Community läßt sich eher nicht unterdrücken und "einschüchtern", egal was damals "Premiere" (irgendwie hießen sie anfangs noch anders, ist aber inzwischen aus dem Gedächtnis gestrichen) auch versucht hat.
Das ändert allerdings nichts daran, daß auch ich den diversen Idioten (die sich auch hier ab und an tummeln), die ihre real abgestrahlte Sendeleistung erhöhen (und sei es durch Antennenumbau ohne notwendige Korrekturen von Einstellungen) und von den physikalischen Zusammenhängen so gar keinen Schimmer haben, am liebsten mit dem Knüppel etwas Verstand verpassen würde - aber auch das gibt es wohl immer wieder, schon seit den Zeiten des CB-Funks und der Freigabe für nicht-lizensierte Funk-"Amateure".
Ich bin dafür, daß seitens der BNetzA echt saftige Bußgelder (nicht unter fünfstelligen Beträgen) für solche Verstöße "vergeben" werden dürfen - aber mit einer Verriegelung von Geräten kommt man m.E. dort nicht einen Schritt weiter. Wer absichtlich an den Einstellungen/am Design herumspielt, um sich einen (teilweise auch nur eingebildeten) Vorteil zu verschaffen, der läßt sich auch nicht davon abhalten und es gibt dann wieder einen weiteren "grauen Markt" für nicht ganz konforme WLAN-Geräte. Am Ende kann so eine Regulierung nur den Import und den Vertrieb solcher Geräte in die EU und/oder die USA verhindern, in Russland/Südostasien/Indien/Südamerika (die Welt ist ja nicht nur EU/USA) interessiert das keinen und die Produktion solcher Geräte wird damit ja nicht unterbunden. Am Ende landet dann ein Hinweis-Aufkleber "Darf nicht in D oder der EU verwendet werden" auf dem Gerät (hatten wir bei CB-Funk-Verstärkern alles schon) und gut ist's ...
Eine komplette Verriegelung (Tivoisierung) wäre zwar denkbar, aber m.E. unwahrscheinlich - AVM dürfte dann vor demselben Problem stehen, wie es der DD-WRT-Entwickler im gestrigen Interview mit heise.de auch skizziert hat (GPL-Verstoß mit "geheimem" DRM für den WLAN-Treiber im Kernel vs. Veröffentlichung der Quellen mit der Möglichkeit der Analyse und des Nachbaus).
Ein komplettes eigenes Betriebssystem für die FRITZ!Box ohne Linux-Kernel ist sicherlich (im Moment) blanke Utopie ... ich zweifele ja schon immer im Stillen an den Behauptungen von Bintec/elmeg, daß deren OS so vollkommen ohne Anleihen bei Open-Source-Software auskommen soll. Aber ich will es einfach mal glauben, deshalb kommt mir auch definitiv kein solches Gerät ins Haus, denn parallel dazu glaube ich dann eben auch an Spionagefunktionen und/oder Hintertüren und/oder Sicherheitslücken in solchen proprietären Systemen - schwer für den Hersteller, deren Abwesenheit zu "belegen", wenn es keine Quellen gibt. Wenn ich mir nur überlege, wieviele Fehler man bei der Implementierung eines eigenen IPSec-Stacks machen kann (auch AVM ist da m.E. auf einem "Holzweg"), dann beschäftigt entweder Bintec/elmeg eine Legion der fähigsten Entwickler in D (und das meine ich tatsächlich im Sinne der altrömischen Legionen mit ihrer Personalstärke) oder das ist einfach nur der "Nischencharakter" dieser Geräte, der sie für Angreifer so uninteressant macht.
Für neue Geräte mag AVM so etwas ja (mit technischen Maßnahmen und einem abgewandelten Design) realisieren können, bei den aktuell vertriebenen wäre das ein tiefer Eingriff in den Bootloader, der zwar jedem ohne JTAG-Zugriff erst einmal die Suppe versalzen würde, aber dann brummt eben das Geschäft mit (E)JTAG-Adaptern ab diesem Zeitpunkt - auch so ein Bootloader ist ja keine "rocket science", wie man an "u-boot" sehen kann (der ginge auch auf einer FRITZ!Box). Ich erinnere nur an dbox/dbox2 usw. ... die Community läßt sich eher nicht unterdrücken und "einschüchtern", egal was damals "Premiere" (irgendwie hießen sie anfangs noch anders, ist aber inzwischen aus dem Gedächtnis gestrichen) auch versucht hat.
Das ändert allerdings nichts daran, daß auch ich den diversen Idioten (die sich auch hier ab und an tummeln), die ihre real abgestrahlte Sendeleistung erhöhen (und sei es durch Antennenumbau ohne notwendige Korrekturen von Einstellungen) und von den physikalischen Zusammenhängen so gar keinen Schimmer haben, am liebsten mit dem Knüppel etwas Verstand verpassen würde - aber auch das gibt es wohl immer wieder, schon seit den Zeiten des CB-Funks und der Freigabe für nicht-lizensierte Funk-"Amateure".
Ich bin dafür, daß seitens der BNetzA echt saftige Bußgelder (nicht unter fünfstelligen Beträgen) für solche Verstöße "vergeben" werden dürfen - aber mit einer Verriegelung von Geräten kommt man m.E. dort nicht einen Schritt weiter. Wer absichtlich an den Einstellungen/am Design herumspielt, um sich einen (teilweise auch nur eingebildeten) Vorteil zu verschaffen, der läßt sich auch nicht davon abhalten und es gibt dann wieder einen weiteren "grauen Markt" für nicht ganz konforme WLAN-Geräte. Am Ende kann so eine Regulierung nur den Import und den Vertrieb solcher Geräte in die EU und/oder die USA verhindern, in Russland/Südostasien/Indien/Südamerika (die Welt ist ja nicht nur EU/USA) interessiert das keinen und die Produktion solcher Geräte wird damit ja nicht unterbunden. Am Ende landet dann ein Hinweis-Aufkleber "Darf nicht in D oder der EU verwendet werden" auf dem Gerät (hatten wir bei CB-Funk-Verstärkern alles schon) und gut ist's ...
Hi,
wollte mal diesen Thread wieder beleben.
Inzwischen sind ja bei der 7490 die Firmware-Updates seit der aktuellen Version 6.51 nur noch mit signierter Firmware moeglich. Ist das nicht auch ein Resultat der oben im Heise-Beitrag genannten Funkregulierung im US-Markt, die sich nun auf anderen Wegen Einzug in die EU findet?
Das Einspielen einer mit Freetz erweiterten Firmware ist derzeit nur durch einen technischen Kniff moeglich (modfs). Das beherrschen aktuell nur die wirklichen Spezialisten hier im Forum. So zumindest mein Eindruck.
Aber wie siehts denn nun mit weiteren neuen Versionen der Firmware aus? Wird die Loesung per modfs oder auch das Rukernel-Tool (wird gerade fit fuer die 7490 gemach) die Loesung sein und auch bleiben koennen?
Interessant auch (zumindest mein Eindruck), das von AVM wenig zu hoeren ist, warum nun die Firmware signiert ist.
Gruss
Goggo
wollte mal diesen Thread wieder beleben.
Inzwischen sind ja bei der 7490 die Firmware-Updates seit der aktuellen Version 6.51 nur noch mit signierter Firmware moeglich. Ist das nicht auch ein Resultat der oben im Heise-Beitrag genannten Funkregulierung im US-Markt, die sich nun auf anderen Wegen Einzug in die EU findet?
Das Einspielen einer mit Freetz erweiterten Firmware ist derzeit nur durch einen technischen Kniff moeglich (modfs). Das beherrschen aktuell nur die wirklichen Spezialisten hier im Forum. So zumindest mein Eindruck.
Aber wie siehts denn nun mit weiteren neuen Versionen der Firmware aus? Wird die Loesung per modfs oder auch das Rukernel-Tool (wird gerade fit fuer die 7490 gemach) die Loesung sein und auch bleiben koennen?
Interessant auch (zumindest mein Eindruck), das von AVM wenig zu hoeren ist, warum nun die Firmware signiert ist.
Gruss
Goggo
Hmm, das hab ich verpasst.
Wollte dieses Wochenende 2 FB7490 mit Version FRITZ!OS 06.30-freetz-devel-13321 auf die neueste Version bringen.
Muss ich da was beachten?
OpenVPN wird auf beiden Boxen benötigt...
qwertz.asdfgh
IPPF-Promi
- Mitglied seit
- 18 Feb 2011
- Beiträge
- 4,467
- Punkte für Reaktionen
- 66
- Punkte
- 48
Das liest du am besten in einem entsprechenden Thema nach:
[thread]284143[/thread]
Also kann ich ruhig das freetz image flashen, allerdings kann man nicht mehr von Orginal 6.51+ auf freetz flashen?
Und Recovery ist nur mit Windows möglich?
Das Fände ich sehr bedenklich, insbesondere da zukünftige Fritz!Boxen wohl nur noch signierte Images beinhalten werden.
Finde zwar die Fritz!Boxen genial, aber sollte Freetz in Zukunft nicht mehr möglich sein, würde ich mir einen Kauf gut überlegen...
Muss glaube ich mal mich beim AVM Support beschweren bzw. Fragen wie das in Zukunft geplant ist...
Und Recovery ist nur mit Windows möglich?
Das Fände ich sehr bedenklich, insbesondere da zukünftige Fritz!Boxen wohl nur noch signierte Images beinhalten werden.
Finde zwar die Fritz!Boxen genial, aber sollte Freetz in Zukunft nicht mehr möglich sein, würde ich mir einen Kauf gut überlegen...
Muss glaube ich mal mich beim AVM Support beschweren bzw. Fragen wie das in Zukunft geplant ist...
Das es ab 06.51 erstmal keinen Weg gibt finde ich auch nicht besonders prickelnd - vorallem in Anbetracht der (zugegeben älteren) Aussage von AVM:
Link:
http://avm.de/service/fritzbox/frit...FRITZ-Box-per-Telnet-wird-nicht-unterstuetzt/
Link:
http://avm.de/service/fritzbox/frit...FRITZ-Box-per-Telnet-wird-nicht-unterstuetzt/
Interessant, dass AVM nach wie vor noch mit so einer Aussage zu Markte geht.
Der Kern der Sache, die von der FCC (US Regulierungsbehoerde) betrieben wird, ist wohl WiFi. Mit modifizierter Firmware konnte bei Routern anderer Hersteller (TP-L***) die Sendeleistung des WLAN teilweise nicht unwesentlich erhoeht werden. Das wiederum fuehrt(e) zu unerwünschten Störungen in den Funknetzen.
Um das nun zu vermeiden werden die Hersteller von Routern nun angehalten (oder sogar gezwungen), ihre Geräte bzw. die Firmware so zu gestalten, dass das nicht mehr moeglich ist. Deswegen ist nur noch signierte Firmware moeglich. Ob und inwieweit sich nun die EU angleicht, ist noch nicht ganz raus. Das Vorgehen von AVM ist aber vielleicht ein Vorbote.
Vorstellen koennte ich mir, dass Routerhersteller kuenftig kein WLAN-Modul mehr in ihre Box einbauen. Dann koennte alternative Firmware wieder Einzug halten. Um die WLAN-Funktion wieder herzustellen wäre nur ein zusaetzlicher WLAN-Accesspoint erforderlich, der per LAN am Router anzuschliessen ist.
Gruss
Goggo
Der Kern der Sache, die von der FCC (US Regulierungsbehoerde) betrieben wird, ist wohl WiFi. Mit modifizierter Firmware konnte bei Routern anderer Hersteller (TP-L***) die Sendeleistung des WLAN teilweise nicht unwesentlich erhoeht werden. Das wiederum fuehrt(e) zu unerwünschten Störungen in den Funknetzen.
Um das nun zu vermeiden werden die Hersteller von Routern nun angehalten (oder sogar gezwungen), ihre Geräte bzw. die Firmware so zu gestalten, dass das nicht mehr moeglich ist. Deswegen ist nur noch signierte Firmware moeglich. Ob und inwieweit sich nun die EU angleicht, ist noch nicht ganz raus. Das Vorgehen von AVM ist aber vielleicht ein Vorbote.
Vorstellen koennte ich mir, dass Routerhersteller kuenftig kein WLAN-Modul mehr in ihre Box einbauen. Dann koennte alternative Firmware wieder Einzug halten. Um die WLAN-Funktion wieder herzustellen wäre nur ein zusaetzlicher WLAN-Accesspoint erforderlich, der per LAN am Router anzuschliessen ist.
Gruss
Goggo
Ich möchte die 7490 in der Heimat gerne per VPN Updaten, bräuchte aber noch eine 7490 recover Version die mein Vater im Notfall installieren kann, falls mein Update fehlschlägt.
Aber da ich nach dem Recover wieder ein freetz raufspielen möchte, brauche ich eine recover version 6.50 oder kleiner.
Weiß jemand woher ich die bekomme?
Aber da ich nach dem Recover wieder ein freetz raufspielen möchte, brauche ich eine recover version 6.50 oder kleiner.
Weiß jemand woher ich die bekomme?
qwertz.asdfgh
IPPF-Promi
- Mitglied seit
- 18 Feb 2011
- Beiträge
- 4,467
- Punkte für Reaktionen
- 66
- Punkte
- 48
Dazu braucht es kein eigentlich kein Recovery, die 7490 ist dankenswerterweise ein DualBoot-System.
Na von AVM höchstpersönlich:
https://service.avm.de/downloads/downgrade/fritzbox_7490/deutsch/
https://avm.de/service/fritzbox/fri...257_Aelteres-FRITZ-OS-installieren-Downgrade/
PS:
Was hat das eigentlich mit diesem Thema hier zu tun?
Geht auch mit Wine, macht zwar seltsame Meldungen,m schreibt aner trotzdem.
Per FTP von EVA aus kann man auch nach wie vor die MTD-Partitionen direkt beschreiben, bei manchen (mindestens 7490) ist das nun jedoch erschwert, weil AVM-Original-Dateien nicht mehr einfach nach „mtd1“ kopiert werden können, die muß man aufteilen, was aber mit der Freetz-Infrastruktur irgendwie gehen muß.
Also: vorsorgen und die Partitionen per FTP sichern, damit man sie im Fehlerfall zurückschreiben kann.
Tu das, schadet nicht, wenn die befürchten, zu viele Nicht-Standard-Nutzer unter ihren Käufern zu verprellen, bevor deren Schlipsträger das per „Zunageln“ einfach mal über die Umsatzzahlen austesten. Man darf aber auch nicht zu viel Aufwand machen, sonst kommen die noch auf die Idee, daß Kunden wie wir mehr Personalkosten verbrauchen, als sie an unseren Boxen verdienen.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,285
- Punkte für Reaktionen
- 1,755
- Punkte
- 113
Ich kann es mir nicht verkneifen, deutlich darauf hinzuweisen, daß der zweite Absatz
Über den FTP-Server im Bootloader können nur die SPI-Partitionen geschrieben werden und das System liegt bei den NAND-Modellen eben auch in diesem "NAND"-Flash, auf den der Bootloader (sagen wir mal der Einfachheit halber
keinen (Schreib-)Zugriff hat.
Eine Sicherung von Partitionen (der Satz nach dem Zitat) ist zwar per FTP theoretisch denkbar, aber eben nur, wenn man den Inhalt der Partitionen vorher irgendwie an eine Stelle geschafft hat, von wo man ihn per FTP (und das meint den NAS-FTP-Service) kopieren kann. Die SPI-Partitionen lassen sich auch nicht über den Bootloader sichern, sondern lediglich neu beschreiben.
in weiten Teilen nicht mehr stimmt und am Ende eher verwirrt als weiterhilft.Christoph_F schrieb:
Über den FTP-Server im Bootloader können nur die SPI-Partitionen geschrieben werden und das System liegt bei den NAND-Modellen eben auch in diesem "NAND"-Flash, auf den der Bootloader (sagen wir mal der Einfachheit halber
keinen (Schreib-)Zugriff hat.Eine Sicherung von Partitionen (der Satz nach dem Zitat) ist zwar per FTP theoretisch denkbar, aber eben nur, wenn man den Inhalt der Partitionen vorher irgendwie an eine Stelle geschafft hat, von wo man ihn per FTP (und das meint den NAS-FTP-Service) kopieren kann. Die SPI-Partitionen lassen sich auch nicht über den Bootloader sichern, sondern lediglich neu beschreiben.
Mich hat das hier auf den Gedanken gebracht: http://freetz.org/ticket/2273.
Die FTP-Sitzung erweckt auf mich den Anschein, als beschreibe AVM da „mtd2“ und „mtd3“, also im Prinzip kaum was anderes als bei den alten Boxen. Jetzt bin ich vollends verwirrt.
Die FTP-Sitzung erweckt auf mich den Anschein, als beschreibe AVM da „mtd2“ und „mtd3“, also im Prinzip kaum was anderes als bei den alten Boxen. Jetzt bin ich vollends verwirrt.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,285
- Punkte für Reaktionen
- 1,755
- Punkte
- 113
Das Ticket ist ca. 3 Jahre alt, da kam die 7490 gerade raus.
Warum da @Whoopie jetzt noch einmal vor drei Wochen in das Thema eingestiegen ist, weiß ich auch nicht ... wie es bei der 7490 funktioniert, habe ich in dem anderen Thread verlinkt und die notwendigen Skript-Dateien stehen in meinem GitHub-Repository.
Die Diskussion bzgl. der Möglichkeiten, die man von Freetz aus hätte, eine NAND-Box direkt zu ändern, ist auch etwas älter als diese drei Wochen ... vermutlich hat @Whoopie die nicht gelesen, bevor das Ticket wieder ausgegraben wurde.
Warum da @Whoopie jetzt noch einmal vor drei Wochen in das Thema eingestiegen ist, weiß ich auch nicht ... wie es bei der 7490 funktioniert, habe ich in dem anderen Thread verlinkt und die notwendigen Skript-Dateien stehen in meinem GitHub-Repository.
Die Diskussion bzgl. der Möglichkeiten, die man von Freetz aus hätte, eine NAND-Box direkt zu ändern, ist auch etwas älter als diese drei Wochen ... vermutlich hat @Whoopie die nicht gelesen, bevor das Ticket wieder ausgegraben wurde.
Hier der komplette Mitschnitt:
(Die PCAP-Datei ist „schlecht gefiltert“, da sind also ein paar Relikte von binärem Nicht-Klartext, die wie druckbare Zeichen aussehen.)
Moment… gerade sehe ich: sie schreiben nach „mtd4“, nicht „mtd2“ und zuletzt nochmal was in den RAM.
Code:
$ strings ../fritzbox-recover-tool-ftp.pcap
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.1964 0x0 0x740D
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,12,10)
RETR env
150 Opening BINARY data connection
226 Transfer complete
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.1964 0x0 0x740D
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,12,4)
RETR count
150 Opening BINARY data connection
226 Transfer complete
221 Thank you for using the FTP service on ADAM2
221 Goodbye.
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
puc0
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.1964 0x0 0x740D
TYPE I
200 Type set to BINARY
MEDIA FLSH
pupl
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,178,1,12,15)
STOR mtd3
150 Opening BINARY data connection
226 Transfer complete
221 Thank you for using the FTP service on ADAM2
221 Goodbye.
`f4~P
220 ADAM2 FTP Server ready
`f4~
USER adam2
$`f4
331 Password required for adam2
PASS adam2
E`f4
230 User adam2 successfully logged in
SYST
l`f4
215 AVM EVA Version 1.1964 0x0 0x740D
TYPE I
200 Type set to BINARY
MEDIA FLSH
200 Media set to MEDIA_FLASH
P@SW
227 Entering Passive Mode (192,168,178,1,12,11)
STOR mtd4
150 Opening BINARY data connection
226 Transfer complete
5`f4
221 Thank you for using the FTP service on ADAM2
221 Goodbye.
220 ADAM2 FTP Server ready
USER adam2
puE-
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.1964 0x0 0x740D
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,12,4)
RETR env
150 Opening BINARY data connection
226 Transfer complete
p|,2
221 Thank you for using the FTP service on ADAM2
221 Goodbye.
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
pu5.
230 User adam2 successfully logged in
SYST
p{fE
215 AVM EVA Version 1.1964 0x0 0x740D
SETENV memsize 0xe7de800
200 SETENV command successful
SETENV kernel_args_tmp mtdram1=0x8e7de800,0x90000000
200 SETENV command successful
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
p{z0
227 Entering Passive Mode (192,168,178,1,12,0)
STOR 0x8e7de800 0x90000000
150 Opening BINARY data connection
226 Transfer completeMoment… gerade sehe ich: sie schreiben nach „mtd4“, nicht „mtd2“ und zuletzt nochmal was in den RAM.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,285
- Punkte für Reaktionen
- 1,755
- Punkte
- 113
Wobei ich es schon extrem spannend fände, wenn da wirklich "mtd2" beschrieben wird ... da wäre bei den meisten Modellen das Update des Bootloaders und das kommt nur alle Jubeljahre mal vor.
Ansonsten enthält mtd3 und mtd4 das TFFS (das überschreibt Recovery tatsächlich, mit einem "leeren" Image, was nur das Environment und die "name table" enthält) und der Rest wird vom aus dem Speicher gestarteten System in den NAND-Flash geschrieben.
- - - Aktualisiert - - -
Da wird MTD2 gar nicht angefaßt ... es ist genau, wie ich zuvor schrieb: Es wird ein leeres TFFS-Image (das die ausgelesenen Daten aus dem "RETR env" und "RETR count" enthält) nach MTD3 und MTD4 geschrieben (die Daten dort sind identisch) und anschließend das Image ins RAM geladen und gestartet. Alles nichts Geheimnisvolles ... und unter den bereits im anderen Thread verlinkten Beiträgen ausführlich diskutiert und geschildert.
Hier habe ich beschrieben, wie man das mit einem eigenen Image umsetzen kann.
Ansonsten enthält mtd3 und mtd4 das TFFS (das überschreibt Recovery tatsächlich, mit einem "leeren" Image, was nur das Environment und die "name table" enthält) und der Rest wird vom aus dem Speicher gestarteten System in den NAND-Flash geschrieben.
- - - Aktualisiert - - -
Da wird MTD2 gar nicht angefaßt ... es ist genau, wie ich zuvor schrieb: Es wird ein leeres TFFS-Image (das die ausgelesenen Daten aus dem "RETR env" und "RETR count" enthält) nach MTD3 und MTD4 geschrieben (die Daten dort sind identisch) und anschließend das Image ins RAM geladen und gestartet. Alles nichts Geheimnisvolles ... und unter den bereits im anderen Thread verlinkten Beiträgen ausführlich diskutiert und geschildert.
Hier habe ich beschrieben, wie man das mit einem eigenen Image umsetzen kann.
Zuletzt bearbeitet:
Danke sehr; wenn ich Dich richtig verstanden habe, brauche ich also nur die Box in den EVA-FTP-Modus zu zwingen, darauf Dein Skript aufzurufen:
./eva_to_memory $FREETZDATEI
- - - Aktualisiert - - -
Ich frage mich gerade, wo ich herhatte, daß die 2. und 3. Partition angeblich Kernel und Dateisystem für die zu aktivierende neue Software enthalten solle. Irgendwo hatte ich sowas gelesen…
./eva_to_memory $FREETZDATEI
- - - Aktualisiert - - -
Ich frage mich gerade, wo ich herhatte, daß die 2. und 3. Partition angeblich Kernel und Dateisystem für die zu aktivierende neue Software enthalten solle. Irgendwo hatte ich sowas gelesen…
Gut dan bleibe ich jetzt in diesem Thread hier.
Wenn ich das alles richtig verstanden habe, sind es die letzten beiden Dateien aus der von Freetz erstellten Tar-Datei, die für das Hochladen über das Web-Interface bestimmt ist, mit „dd“ zusammenkopiert:
?
- - - Aktualisiert - - -
Was macht „nc -d“? Die Option kennt meine Version nicht.
Wenn ich das alles richtig verstanden habe, sind es die letzten beiden Dateien aus der von Freetz erstellten Tar-Datei, die für das Hochladen über das Web-Interface bestimmt ist, mit „dd“ zusammenkopiert:
Code:
$ tar tvf trunk/images/26.9.2016_7490_06.30-freetz-devel-13941M.de_20160926-161605.image
[…]
-rwx------ root/root 28553224 2016-09-26 16:16 ./var/tmp/filesystem.image
-rw-r----- root/root 1861384 2016-09-26 16:16 ./var/tmp/kernel.image- - - Aktualisiert - - -
Was macht „nc -d“? Die Option kennt meine Version nicht.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,285
- Punkte für Reaktionen
- 1,755
- Punkte
- 113
Im Prinzip ja, aber ohne die Prüfsumme (8 Byte - 4 Byte Header, 4 Byte CRC) hinter dem Kernel oder der letzte Block muß (wenn er nicht "voll" ist bis zur nächsten 256-Byte-Boundary) aufgefüllt werden.
Wenn man die 8 Byte stehen stehen läßt und damit dann die Länge in Hex auf "8" endet, dann findet der Kernel-Code den Beginn des Filesystems nicht, denn das muß an einer 256-Byte-Grenze beginnen.
- - - Aktualisiert - - -
https://linux.die.net/man/1/nc
Wenn man die 8 Byte stehen stehen läßt und damit dann die Länge in Hex auf "8" endet, dann findet der Kernel-Code den Beginn des Filesystems nicht, denn das muß an einer 256-Byte-Grenze beginnen.
- - - Aktualisiert - - -
https://linux.die.net/man/1/nc
Neueste Beiträge
-
BITCOIN RECOVERY REDEFINED: RAPID DIGITAL RECOVERY EXPERT APPROACH
- Letzte: gilbertsamson563
-
FRITZ!Repeater3000 AX INHAUS - 7.9x - Smart24P1FCS- Letzte: stoney
-
Mesh System- schlechter Empfang- Letzte: Jstessi
-
5690 Pro Datenraten Problem 5ghz und 6ghz
- Letzte: BlacknightSat
-
[Problem] T41s registriert nicht an Fritzbox
- Letzte: ernesto_filo