@Flole:
Ich habe doch ganz ausführlich beschrieben, wie ich mir eine "Fälschung" vorgestellt hätte ... der Verweis auf die manuelle Speicherung in "/nvram" ohne passende Änderung im Bootloader ist ja kaum mißzuverstehen und läßt (meines Erachtens jedenfalls) kaum Spielraum für eigene Spekulationen, was ich da nun genau meinen könnte.
Und wenn ich das Wort "gefälscht" in Anführungszeichen setze, dann meine ich das auch so ... eine Box mit einem "fremden" Zertifikat (darf ich das so nennen?) ist auch erst mal ein "gefälschtes" Produkt, weil sie mit einem nicht zu ihr gehörenden Zertifikat (das dann auch nicht im Bootloader steht) entsprechenden Einschränkungen unterliegt, die hier der Fragesteller wohl zu spüren bekam.
Ich habe keinen Schimmer, wie Du Dir eine "Änderung" der MAC-Adresse in einem Zertifikat vorstellst ... damit kann ich das auch kaum mit "gefälscht" meinen. Ich wüßte nicht, wie man ein Zertifikat nach einer solchen Änderung wieder korrekt signieren kann, solange man den privaten Key des Herstellers nicht hat und den hat (für den neuen Key von 2015) hoffentlich niemand außer AVM.
Wenn ein "gefälschtes" Zertifikat nur im Download-Ordner lag und sich auf eine andere CM-MAC als die hinten aufgedruckte bezog (das ist dann der "gefälschte" Punkt, wobei natürlich der Key und das Zertifikat "ein Original" wäre, halt nur von einem anderen Device), dann kann das - bei passender Firmware-Version und Zurücksetzen auf Werkseinstellungen - auch gelöscht worden sein ... in so einem Falle hätte die alte Firmware (die ja auch das Löschen des neuen Zertifikats im Download-Ordner zu verantworten hätte) beim nächsten Neustart wieder "cmcertgen" benutzt, um ein neues Zertifikat (halt mit dem alten Key signiert) zu erstellen.
-------------------------------------------------------------------------------------------------------------------------------------------
Ein "old/old" muß also nicht heißen, daß es gar kein Zertifikat gibt ... es kann auch ganz simpel darauf hinweisen, daß ein Zertifikat mit dem alten Key signiert wurde (obwohl AVM das am Speicherort von Dateien festmacht und gar nicht in die Dateiinhalte schaut) und dazu das alte Hersteller-Zertifikat für die Chain gehört. Im Gegensatz zum "cmcertgen" wird auch bei einer Box mit den Zertifikaten im Bootloader das Ganze erst mal genau an dieselben Stellen kopiert, wo auch die Dateien aus einem Download landen würden ... daher kann AVM anhand der Verlinkung auch erkennen, ob es neue Dateien sind (dann stehen die im Download-Ordner, egal wie sie dorthin kamen) oder doch alte.
Die Änderung der CM-MAC bei irgendeiner Aktion wurde ja hier vom Fragesteller beobachtet und berichtet ... ohne diese "Änderung" der CM-MAC stellt sich die Frage des "fremden" Zertifikats gar nicht erst.
Mancher wirft auch einfach nur die verschiedenen MAC-Adressen durcheinander, weil auf dem Etikett auf der Rückseite einer alten 6490 durchaus auch die "maca" stehen könnte, die für den CWMP-Account verwendet und ebenfalls aufgedruckt wurde - m.W. stand da gar keine CM-MAC, denn die war nur auf der Kiste ... aber ich habe auch keine alte 6490 mehr, um das selbst zu prüfen.
Das Verschwinden eines Download-Zertifikats kann einfach das Ergebnis des Zurücksetzens mit der falschen Firmware sein, denn noch in der 06.50 mit "avm"- und "lgi"-Branding (vom 02.03.2016) ist in der "S01-head" folgendes zu finden:
Code:
######## locate nvram mtd (config-space) ########
## first hit
mtd_nvram=`grep 'config-space' /proc/mtd`
for i in ${mtd_nvram} ; do
mtd_nvram=$i
break
done
if [ -n "${mtd_nvram}" ] && [ -n "${Recover_was_here}" ] ; then
del_mtd_nvram=${mtd_nvram#mtd}
del_mtd_nvram=${del_mtd_nvram%:*}
## erase nvram (formatting) due to preceding recover
nvram_erasestring="mtd ${del_mtd_nvram} erase all"
echo "[config-space/Recover] nvram erasing start ... (${nvram_erasestring})" > /dev/console
echo "${nvram_erasestring}" > /proc/mtd
echo "[config-space/Recover] nvram erasing ... done." > /dev/console
fi
if [ -n "${mtd_nvram}" ] ; then
mtd_nvram=${mtd_nvram#mtd}
mtd_nvram=${mtd_nvram%:*}
echo "[config-space] using mtd$mtd_nvram for /nvram"
if mount -t jffs2 /dev/mtdblock$mtd_nvram /nvram ; then
echo "[config-space] nvram assigned @ /dev/mtdblock$mtd_nvram" ;
else
#########retry (once)############
echo "[config-space] nvram assignment failed - retrying once" ;
## erase mtd (formatting)
nvram_erasestring="mtd ${mtd_nvram} erase all"
echo "[config-space] nvram erasing start ... (${nvram_erasestring})" > /dev/console
echo "${nvram_erasestring}" > /proc/mtd
echo "[config-space] nvram erasing ... done." > /dev/console
if mount -t jffs2 /dev/mtdblock$mtd_nvram /nvram ; then
echo "[config-space] nvram assigned @ /dev/mtdblock$mtd_nvram" ;
else
#########retry (fail)#######
echo "[config-space] nvram assignment failed (retry once does not work)" ;
fi
fi
else
echo "[config-space] ++++++++++++++++++++++++++++++" ;
echo "[config-space] ++++++++++++++++++++++++++++++" ;
echo "[config-space] ERROR: nvram not found (FATAL)" ;
echo "[config-space] ++++++++++++++++++++++++++++++" ;
echo "[config-space] ++++++++++++++++++++++++++++++" ;
fi
Da das "Recover_was_here" auch infolge des Zurücksetzens auf die Werkseinstellungen gesetzt wird (mittels "recovered=3"):
Code:
## intentionally kept simple: just detect config-space/nvram) an set the need of 'factorydefault'
## firmware_info setzen (damit wir nach dem reboot das nachholen k.nnen) [factorydef: recovered=3]
echo "[$$] nvram INFO: erasing scheduled for next bootup" > /dev/console
fw_info=`grep firmware_info $CONFIG_ENVIRONMENT_PATH/environment`
## take care on preventing multiple entrys ',recovered=*'
fw_info=`echo ${fw_info} | sed -e "s/,recovered=[0-9]\+//g"`
echo "$fw_info,recovered=3" >$CONFIG_ENVIRONMENT_PATH/environment
fi
(der Ausschnitt stammt aus der dortigen "/bin/setfactorydefaults")
wird bei dieser Firmware-Version beim Zurücksetzen auf die Werkseinstellungen noch ganz prosaisch die komplette JFFS2-Partition neu formatiert und damit sind auch per "cm_dl_cert" dort schon abgelegte Zertifikate (die beim Update auf die 06.50 eigentlich gezogen worden sein sollten, denn in den Images, die ich hier habe (avm+lgi und kdg), war auch da schon das "cm_dl_cert" enthalten) dann wieder weg.
Das ist exakt der Umstand, vor dem ich hier gewarnt habe:
https://www.ip-phone-forum.de/threa...e-firmware-update.286994/page-63#post-2195150
... und wenn da etwas von 06.31 steht, liegt das u.a. auch daran, daß die 06.50 mit "kdg"-Branding (vom 19.02.2016) das "Retten" der Zertifikate tatsächlich schon enthielt, während es in der erwähnten 06.50 für "avm+lgi" (vom 02.03.2016) wieder fehlt - da hat mich AVM dann wirklich "verwirrt".
---------------------------------------------------------------------------------------------
Und es gibt tatsächlich noch Programme, die in SD übertragen werden (zumindest bei mir im Kabel) ... bei der Übertragung über WLAN (z.B. auf ein Smartphone oder Tablet beim Sitzen unter dem Apfelbaum im Garten - ja, bei Fontane ist's ein Birnbaum, ich weiß und ich habe eigentlich auch keinen Garten, dafür aber auch eine funktionierende 6490 bzw. eigentlich sogar zwei davon) kann das sogar richtig Sinn ergeben und ich muß mir tagesschau24 nicht unbedingt in HD ansehen (bzw. meist eher anhören), um zu wissen, was in der Welt so los ist ... das ändert nämlich auch nichts daran, daß die Box 4 Tuner hat und bei 4 SD-Streams auch problemlos noch hinterherkommt (solange der ATOM-Core nicht noch jede Menge andere Sachen erledigen muß) - auch ein RasPi mit Kodi kommt beim Anzeigen von 2 HD-Streams kaum hinterher (trotz Hardware-Beschleunigung für die Video-Ausgabe) und erst recht nicht beim Aufzeichnen über seinen USB2-Anschluß. Es kommt also immer darauf an, was man genau von wo nach wo übertragen will und für welchen Zweck.
