Fritzbox 6490 Cable Firmware Update?

Hallo,

Stralsunder schrieb:

Kann ich überhaupt von 6.22 direkt auf 6.62

Zum Vergrößern anklicken....

IMHO gibt es schon eine 64er

@Frank_m27:
Sicher? Die Update-Prüfung bei mir sagt "Nein" und für die 6490 gibt es doch (hoffentlich) keine "INTERN"-Versionen; zumindest hoffe ich mal, daß es dann keine mit "ShellInABox" sind ... das würde meinem Argumentationsversuch "Man braucht nicht unbedingt einen Shell-Zugang zur 6490 als normaler Besitzer." dann doch den Zahn endgültig ziehen.

Hallo,
es gibt sie
ftp://yyy:[email protected]/..../....FRITZ.Box_6490_Cable.de-en-es-it-fr-pl.141.06.64.image

Dabei handelt es sich um eine internationale Firmware-Version.

Hallo,
wie in Post #817

Es lag an meiner Windoofschleuder... mit meinem Mac gehts auch tadellos... sorry für die aufruhe und danke...

Alcaline schrieb:

Es lag an meiner Windoofschleuder...

Zum Vergrößern anklicken....

Damit möchtest du doch sicher nur von deinem eigenen Versagen ablenken, oder?

@PeterPawn:

PeterPawn schrieb:

...zumindest hoffe ich mal, daß es dann keine mit "ShellInABox" sind ...

Zum Vergrößern anklicken....

Leider kann ich mangels entsprechender Hardware nicht testen.
Ist meine Mail heute Morgen eigentlich angekommen? Ging an Admin@...

Franky

Nun noch einmal explizit auf die 06.64 angesprochen, habe ich einmal kurz hineingesehen ... es gibt zwar neue "timestamps" (auch als FSSTAMP in der /etc/version), aber die Kernel für ARM- und ATOM-Kern sind (nach Ansicht von "cmp") identisch mit denen aus der 06.63 und auch ein "find" für reguläre Dateien und ein anschließendes "diff" für all jene Dateien, die beim Aufruf "file <filename>" kein "ELF" in der Ausgabe haben (wo es sich also eher um Text-Dateien handelt und nicht um binäre Programmdateien bzw. -bibliotheken), bringt keine wirklichen Änderungen ans Licht - abgesehen von den Änderungen an der Versionsnummer und den Zeitstempeln (die 06.64 ist vom 13.01.2017).

Ob es innerhalb der binären Dateien nennenswerte Unterschiede gibt, bräuchte etwas länger bei einer "Durchsicht" - solange niemand diese Version dann auch einsetzt, ist das eindeutig zuviel Arbeit und anhand der Ergebnisse beim Vergleich der Text-Dateien ist ohnehin nicht zu erwarten, daß es sichtbare Änderungen gab.

Bemerkenswert ist halt, daß auch dort im Firmware-Image immer noch (wobei man anhand des enthaltenen Funktionsumfangs durchaus unterstellen kann, daß es sich um die Firmware für eine Retail-Box handelt - auch hier fehlt der PACM-Teil für zusätzliche eSAFE-Konfigurationen) das Programm zum Laden eines neuen Zertifikats enthalten ist - wo es bei der "Zielgruppe" der Retail-Boxen ja gar keinen Bedarf für einen solchen Download geben sollte, denn dort müßten jeweils neue Zertifikate ab Werk existieren. Das erspart einem bei einem "Cross-Update" dann weitere zusätzliche Schritte (neben dem "Online-Versuch" für das Zertifikate-Update), wenn man auf "die letzte Version" updaten will. Ich bin mal gespannt, ob das bei der zu erwartenden 06.80 auch noch der Fall sein wird ... eigentlich ist es ja fast ein "Service" für die Besitzer von (ehemaligen) Provider-Boxen. Ob der nun auf den Unwillen, einen weiteren Unterschied beim Installationsprozess eines Updates einzuführen, zurückzuführen wäre oder ob es AVM tatsächlich egal ist, wenn mit der Retail-Firmware dann auch die ganz alten Schätzchen noch einmal versuchen, ein neues Zertifikat zu erhalten, kann man ja auch nur spekulieren - "komisch" (im Sinne von "merkwürdig", nicht von "lustig") ist das aber schon.

Kleiner Spaß mit dem Binärsystem am Rande ... da, wo beim normalen Benutzer das tägliche Leben dann in der Regel auf die IT und Netzwerke allgemein durchschlägt, wenn dort Netze auf der Basis von Vielfachen von 10 "strukturiert" werden, da hat man sich bei AVM beim Erstellen des self-signed-Zertifikats für die CA, mit der der Update-Server validiert werden soll (das liegt als "ca.pem" mit im Firmware-Image), dann zum entgegengesetzten Vorgehen entschlossen. Anstatt so ein Zertifikat für eine "runde" Zahl von Jahren oder Monaten (oder meinetwegen noch kleinere Einheiten, wenn es wirklich "temporär" ist) zu generieren, wie das nun wieder "üblich" ist, wurde dort am 13.02.2015 für das Zertifikat die Gültigkeitsdauer auf 1024 Tage (2 ** 10) gesetzt, womit das am 03.12.2017 dann ablaufen wird. Das ist mir zuvor auch nicht so richtig aufgefallen ... erst jetzt, weil beim Auslesen von Zertifikaten bei mir eine Warnung erzeugt wird, wenn das Ablaufdatum das aktuelle Jahr enthält. Man weiß m.W. auch nicht genau, ob AVM bei der Prüfung des Zertifikats dann auch die Zeit einbezieht ... wäre das aber der Fall, dann würde das "cm_dl_cert" nach dem Ablauf des CA-Zertifikats auch den c4.avm.de nicht mehr verifizieren können - selbst wenn der dann immer noch laufen sollte.

---

-In einem anderen Thread hier wurde gerade davon berichtet, daß jemand von UM als Austauschgerät eine FRITZ!Box 6360 mit 06.04 (und anschließend bei einem erneuten Tausch sogar mit 06.03, wo die "webcm"-Lücke noch enthalten sein müßte) erhalten hat. Wenn so eine Box nach dem Zurücksetzen auf Werkseinstellungen tatsächlich provisioniert wird (die 06.04, die ich hier liegen habe, kennt definitiv noch keine Schutzmaßnahmen für neue Zertifikate im Flash), dann müßte an diesem CMTS ja immer noch die Verwendung alter Zertifikate möglich sein ... mit allen (negativen) Konsequenzen, die sich daraus ergeben.

So ein "altes" Zertifikat kann man sich eben selbst für jede beliebige CM-MAC erstellen und das öffnet nun mal Tür und Tor für das Klonen von (e)CM. Ich habe zwar keinen Schimmer, welche zusätzlichen Gegenmaßnahmen da bei UM nun die Verwendung von Klonen verhindern sollen oder zumindest "könnten" ... aber ich kann mir wenige solcher "counter-measures" vorstellen, bei denen nicht der rechtmäßige Benutzer der CM-MAC auch in Mitleidenschaft gezogen wird (also wie UM das innerhalb eines Kabelsegments "auflösen" will, bei mehreren reicht die Phantasie dann wieder) und insofern finde ich die Gelassenheit, die es bei UM da dem Anschein nach gibt, schon bemerkenswert.

Vor allem dann, wenn man anhand der WLAN-Netze in der Nachbarschaft (zumindest in der Theorie) recht leicht die CM-MACs der verwendeten FRITZ!Boxen errechnen kann (und die erkennt man auch nicht nur am Namen, sondern ebenso an der verwendeten MAC-Adresse) ... damit fällt (nach meiner Überzeugung, ich lasse mich gerne korrigieren) auch das "Argument" flach, es könne außer dem KNB ja niemand wissen, welche CM-MAC der Nachbar nun verwendet.

Ich würde mal gerne den bisherigen Stand zusammenfassen. Bzw. mal "durchspinnen" wie man eine gebrandete Box auf den aktuellen Stand bekommt, bzw. zu Regenerieren.

Andere Ideen für weitere Ansätze wären dann vielleicht in der Art:

Eigene Recovery bauen, Flash per bootloader programmieren. Anpassung der MAC, Erstellung eines neuen Zertifikats.
Sniffen des Verkehrs am Modem bei einem Update.
Simulation einer CMTS. QAM per hacktf, o.ä.
Flash direkt per Programmer auslesen/programmieren. Direkt an der Hardware wurde scheinbar noch nicht viel versucht, sinnvoll?

Was sind denn die Möglichkeiten sonst noch welche man verfolgen könnte?

PeterPawn schrieb:

... die 06.64 ist vom 13.01.2017 ....

Zum Vergrößern anklicken....

Muss man das verstehen, wenn VF KDG die 6.65 schon seit Nov./Dez. 2016 im Feldtest hat?

Ich vermute mal, AVM wird da zwei "Zählweisen" einführen und die Versionen für "Retail" und "Provider" gesondert behandeln.

Es wäre irgendwo auch recht blödsinnig, wenn KDG wirklich (nach drei Monaten Feldtest) jetzt tatsächlich noch die 06.65 ausrollen würde (aber mich überrascht da auch nichts mehr wirklich) ... die hat ja noch genau dieselben Löcher wie die 06.63, wenn es um das "Eindringen" der Kunden in die Provider-Boxen geht und - bei allem Verständnis für Gründlichkeit und Change-Management, ohne geht es in einem großen Netz auch kaum - wenn das dann in demselben Tempo weitergeht bei den Updates, dann gibt es die 06.80 für die Provider-Boxen wohl frühestens zur IFA - egal wann die von AVM an die Provider geht.

Wenn man wirklich ständig solche (doch recht langen) Feldtests machen will, rennt man der Entwicklung nun mal ständig hinterher und nur weil es für die Geräte von anderen Herstellern seltener neue Firmware gibt, heißt das noch lange nicht, daß die dann sicherer wären oder man als Provider damit automatisch weniger Angriffsfläche bietet (man hat vielleicht weniger Arbeit damit, aber auf Kosten der eigenen Sicherheit und der Sicherheit der Kunden). Da interessiert sich nur kein Mensch für die Lücken in der Firmware und selbst wenn, gibt es vom Hersteller noch wesentlich seltener gefixte Versionen ... während AVM ja wohl sogar die Provider mit einer Art "Labor-Version" für die FRITZ!Boxen versorgt.

Ich würde da eben annehmen, daß ein solcher "Feldtest" dann auch mit der Labor-Version erfolgt und nicht erst dann, wenn die Release-Version da ist, dann einen Monat in der Technik und drei weitere bei wenigen Kunden getestet wurde. Dann steht nämlich in aller Regel bereits die nächste Version ins Haus (auch die nicht nur mit neuen Funktionen, sondern mit geschlossenen Lücken (die bis dahin ja dann schon wieder erkannt wurden, sonst könnte man sie nicht fixen) und da liefert der Provider dann genau die Firmware im großen Stil aus, die gerade "aktuelle Probleme" hatte.

Das ist irgendwie widersinnig und das am Ende auf die Update-Frequenz von AVM zu schieben, wenn der eigene Support mit dem Rollout eines Updates nicht nachkommt, ist auch eher "kurzsichtig". Da stimmen dann (meine Meinung, die man nicht teilen muß) irgendwo auch die Update-Prozesse bei den KNB nicht so richtig, wenn das alles immer so endlos braucht, bis es auf den Geräten beim Kunden ankommt.

Andererseits kann man es den KNB auch nicht wirklich verübeln, wenn sie etwas gründlicher sind beim Testen (wenn das aber dann so lange braucht, muß man eben mehr Manpower daran setzen) ... schaut man sich einige "Schnitzer" aus der Vergangenheit an (z.B. die VPN/VoIP-Geschichte bei der 6360 oder der 6490, so genau habe ich das nicht im Kopf), ist man da sicherlich auch "gebranntes Kind" und hinsichtlich der AVM-eigenen QS kann man eben auch durchaus geteilter Meinung sein, wie man einige Male in den Labor-Reihen erfahren mußte. Da ist also ein "Erst mal raus damit zum Kunden, wird schon schiefgehen ..." vielleicht auch der falsche Ansatz, aber überlanges Zaudern ist genauso gefährlich.

Gibt es schon Ideen zu den Dateien cm_key_prv.bin mfg_key_pub.bin?

Hallo Liebes IPPF Mitglieder

wie man in meinem Status sehen kann bin ich schon sehr lange hier Registriert aber das ist doch mein erster Beitrag also doch Neuling :razz:.
Ich bin eigentlich nur Leser und komme mit hier geschriebenen Lösungen oder beispiele gut klar.

Jetzt bei dem Punkt von PeterPawn post #1127 für dumpen der Original Firmware komme ich einfach nicht weiter.
Ich habe diesen Beitrag hier seit Anfang an mit gelesen rauf und runter, vieles habe ich nicht gleich kapiert. Aber weiter dabei geblieben, dank der Stichpunkte von tetzlav post #1047 und die Scripte von PeterPawn klappt das Retail Firmware aufspielen ohne Probleme. So konnte ich schon meine aus der bucht kommende Fritzbox schon erfolgreich flashen und in Betrieb nehmen. Danke noch mal hier für eure Arbeit, besonders an tetzlav und PeterPawn.

So jetzt dachte ich wenn das aufspielen schon wunderbar klappt sollte Jetzt auch mal eine Sicherung der Original Firmware her. Brauchen tun ich das nicht aber ich lerne oder probiere gerne und vielleicht hätte ich auch hier was dazu beitragen können. Also ein neue Fritzbox aus der bucht besorgt um zu probieren und als ersatz.

Zum Problem:
Ich mache die Scripte save_system.sh + dump_firmware(mit geänderte Name auf run_update) + update_firmware auf die Box in die Wurzel des NAS-Speichers.
Nach Neustart habe ich eine saved_firmware.tar Datei auf der NAS aber sie ist leer.
Ich habe nochmals und nochmals gelesen aber finde den Fehler nicht, die Dateien habe ich mit Filezilla auf NAS geschoben (übertragungstyp binär), rechte auf 755 gesetzt aber es klappt nicht.

Ich bedanke mich schon in voraus für eure Zeit und mühe.

Warum lädst du dir nicht einfach die Firmware hier aus dem Board?

Der Link zum AVM Server ist hier irgendwo in einem von den vielen Beiträgen.

@Phantomias2501

sorry blöd ausgedrückt von mir, mit Original Firmware meine ich die die auf der Box ist also die Gebrandete z.b. KDG oder lgi Firmware.

@ice012345:
Zeig' mal die verwendeten Skript-Dateien, ich hatte die zwar getestet, aber vielleicht bin ich ja mit Versionen durcheinander gekommen.

Eigentlich sollte "save_system.sh" ja mit heftigem Blinken der LEDs seine Aktivitäten verdeutlichen und das sollte auch seine Zeit brauchen. War das denn der Fall? Wenn ja, stimmt vielleicht nur beim Packen der Dateien etwas nicht (dann müßten aber die Ausgangsdateien ja noch existieren). Das "save_system.sh" an sich ist eigentlich auch getestet (gibt hier auch irgendwo einen Thread, wo ich das zum ersten Mal gezeigt habe, noch vor der Aufnahme ins Repository) und dürfte keine Probleme bereiten.

Vielleicht änderst Du ja auch "dump_firmware" noch ab und läßt das Packen erst einmal weg (das war ja nur der Bequemlichkeit zuliebe), dann hast Du die beiden Verzeichnisse "ARM" und "ATOM" halt im NAS liegen - sofern das "Auslesen" der Firmware funktioniert hat.

Was ist das denn jetzt für eine Version? (2000 2790)



http://www.ebay.de/itm/FRITZ-Box-64...265165?hash=item2efd2fd1cd:g:A~kAAOSwCU1YoDL9

@PeterPawn

Also in deinem Beitrag post #1127 steht das es für die Verschieden Auslese vorgänge verschiedene LEDS Blinken und am Schluß beim Packen die Info Rot blinkt richtig?

Aber bei mir leuchtet der Info LED ganz kurz Rot und danach Startet die Box Neu, ergo habe ich auch nur eine leere tar datei.
Ich habe auch keine ARM und ATOM verzeichnis danach auf der NAS. Habe grade auch mit weg lassen der tar datei Packen probiert, dann Starte es auch einfach neu, ohne Rot zu leuchten.

save_system.sh

#! /bin/sh
ringbuffer=savesystem
rm /var/.srb_$ringbuffer
nand=/var/media/ftp
logfile() { showshringbuf -i $ringbuffer; }
log() { echo "$*" | logfile; }
save_part()
{
local dev="$1" content="$2" version="$3" fn rc
fn=${content}_$version
cat $dev >$TD/$fn
rc=$?
[ $rc -eq 0 ] && log "Successfully saved $dev to $TD/$fn" || log "Error $rc saving $dev to $TD/$fn"
}
if [ "$CONFIG_PRODUKT" == "Fritz_Box_HW213a" ]; then
core=ARM
ledon="update_running"
ledoff="update_no_action"
else
if [ "$CONFIG_PRODUKT" == "Fritz_Box_HW213x" ]; then
core=ATOM
ledon="wlan_starting"
ledoff="wlan_on"
else
log "Unknown hardware revision $CONFIG_PRODUKT"
exit 1
fi
fi
TD=$nand/$core
led-ctrl $ledon
log "Waiting for NAND flash to appear ..."
while true; do
mode=$(sed -n -e "s|^[^ ]* $nand .* \(r.\),.*|\1|p" /proc/mounts)
[ x"$mode" == x"rw" ] && break
log "Still waiting until NAND flash storage is mounted read/write"
sleep 10
done
log "NAND flash is mounted now on $nand"
rm -r $TD
mkdir -p $TD
log "Saving serial flash content:"
logfile </proc/mtd
sed -n -e "s/^\(mtd[0-9]\{1,2\}\): [0-9a-f]* [0-9a-f]* "\(.*\)"\$/MTD=\1 NAME="\2"/p" /proc/mtd |
while read line; do
eval $line
NAME=$(echo "$NAME" | sed -e "s/[()]//g" -e "s/ /_/")
cat /dev/$MTD >$TD/${MTD}_$NAME
log "Copying /dev/$MTD to $TD/${MTD}_$NAME done, rc=$?"
done
log "Saving serial flash done"
log "Saving kernel and filesystem partitions"
mp=/var/tmp/savesystem.mp
mkdir -p $mp
dmesg | grep "/dev/mmcblk.*logical:.*$core" | sed -n -e "s|.*\(/dev/mmcblk.*\) logical: \(.*\)|DEV=\1 CONTENT=\2|p" |
while read line; do
eval $line
echo "$CONTENT" | grep -q "_reserved_" && stat="inactive" || stat="active"
CONTENT=$(echo "$CONTENT" | sed -e "s/_reserved//")
echo "$CONTENT" | grep -q "filesystem"
if [ $? -eq 0 ]; then
mount -t squashfs -o ro $DEV $mp
rc=$?
if [ $rc -eq 0 ]; then
version=$($mp/etc/version --version)
vdate=$($mp/etc/version --date)
project=$($mp/etc/version --project)
umount $mp
rc=$?
[ $rc -ne 0 ] && log "Error $rc unmounting $DEV from $mp"
version=$version${project+-$project}
log "Device $DEV contains $stat $CONTENT with version $version created at $vdate"
save_part $DEV $CONTENT $version
else
log "Error $rc mounting $DEV to $mp - skip kernel and filesystem partition"
version="unknown"
fi
else
[ "$version" != "unknown" ] && save_part $DEV $CONTENT $version
fi
done
rmdir $mp
showshringbuf $ringbuffer >$TD/logfile
rm /var/.srb_$ringbuffer
led-ctrl $ledoff

Zum Vergrößern anklicken....

dump_firmware(als run_update)

$SHELL /var/media/ftp/save_system.sh
rpc $SHELL /var/media/ftp/save_system.sh
led-ctrl filesystem_mount_failure
tar -c -v -f /var/media/ftp/saved_firmware.tar /var/media/ftp/ARM /var/media/ftp/ATOM
led-ctrl filesystem_done

Zum Vergrößern anklicken....