[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

Die bearbeiteten images mit Freetz gehen nicht mehr mit modfs

Code:
root@fritz:/var/mod/root# ./modfs update 7490_06.69-rev41137_labor-freetz-devel-
13932M.de_20160922-094814.image
Using debug mode with a 64 KB buffer
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.69-41137

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/mod/root/7490_06.69-rev41137_labor-freetz-devel-13932M.de_20160922-094814.image' wird als Quelle für die Aktualisierung genutzt.
Überprüfen der Signatur der geladenen Datei ... Fehler
 
Die bearbeiteten images mit Freetz gehen nicht mehr mit modfs
Siehe hier, vorletzter Absatz.

Wenn das neue Image mit Freetz ordentlich signiert wurde (seit drei Monaten ist das im Trunk) und das aktuelle System in der Box bereits den verwendeten öffentlichen Schlüssel enthält, dann sollte das genauso funktionieren wie mit jedem originalen AVM-Image ... ansonsten muß man sich eben mal damit beschäftigen, so neu ist das auch in Freetz nicht mehr.

Die zwei denkbaren Lösungen (richtige Einstellungen in Freetz vs. NOVERIFY=1 beim Aufruf) liegen sicherlich auf der Hand ...
 
Als Ergänzung zu #820

Das angemahnte Fehlerprotokoll

Code:
1970-01-01 08:48:20.197 - find_free_storage_space: /var/media/ftp:303480832
1970-01-01 08:48:20.216 - find_free_storage_space: exiting, rc=0
1970-01-01 08:48:20.271 - progress: mode=3, msg= OK
1970-01-01 08:48:20.290 - check_prerequisites: exiting, rc=0
1970-01-01 08:48:21.227 - modfs: source=file_update
1970-01-01 08:48:21.257 - modfs: firmware update file=41137.image
1970-01-01 08:48:21.314 - progress: mode=3, msg=Die angegebene Datei '/var/media/ftp/modd/41137.image' wird als Quelle f
r die Aktualisierung genutzt.
1970-01-01 08:48:21.336 - find_free_space: wanted=100M, order=tmpfs nand storage
1970-01-01 08:48:21.364 - check_free_tmpfs: wanted=104857600, needed=104857600
1970-01-01 08:48:21.391 - check_free_tmpfs: exiting, rc=0
1970-01-01 08:48:21.411 - find_free_space: tmpfs=/var/tmp
1970-01-01 08:48:21.429 - find_free_space: exiting, rc=0
1970-01-01 08:48:21.450 - get_working_directory: /var/tmp
1970-01-01 08:48:21.470 - modfs: working directory=/var/tmp
1970-01-01 08:48:21.498 - modfs: image directory=/var/tmp/28101
1970-01-01 08:48:21.517 - try_to_check_integrity: target=/var/media/ftp/modd/41137.image
1970-01-01 08:48:21.568 - progress: mode=1, msg=Überprüfen der Signatur der geladenen Datei ...
1970-01-01 08:48:21.941 - progress: mode=3, msg= Fehler
1970-01-01 08:48:21.960 - try_to_check_integrity: integrity check failed, error code was 1
1970-01-01 08:48:21.979 - try_to_check_integrity: exiting, rc=205
1970-01-01 08:48:21.999 - cleanup: running cleanup from file /var/tmp/3805_filelist_28098
1970-01-01 08:48:22.017 - /var/media/ftp/modd/bin/185/busybox rm -r /var/tmp/28101
#

Mir auch etwas unklar. Egal und nur der Vollständigkeit halber.

Code:
41137.image            check_image_signature  mke2fs                 openssl                unsquashfs4
busybox                check_signed_image     mksquashfs3            unsquashfs
busybox.config         e2fsck                 mksquashfs4            unsquashfs3
# ./check_signed_image 41137.image -b
Missing openssl binary.
#

LG
 
"openssl" liegt nicht in einem Verzeichnis, das sich im Suchpfad befindet ... die Änderung von heute nacht sollte da bereits helfen.

Wie findet man die Ursache, wenn man selbst suchen will?

  • Fehlercode von "modfs" ist 205 => https://github.com/PeterPawn/modfs/blob/master/modfs#L169
  • mit dieser "205" findet man dann auf Anhieb die Stelle des Aufrufs => https://github.com/PeterPawn/modfs/blob/master/modfs#L1422 (die Fehlernachricht steht wenige Zeilen dahinter in der Auswertung des Return-Codes)
  • es wird also "check_image_signature" aufgerufen und dort wird zwar noch einmal nach den notwendigen Programmen (also nach "openssl" und nach "check_signed_image") gesucht, aber eben nach dem Wechsel des Verzeichnisses (noch in "modfs") mit der Syntax, die (ausschließlich) im aktuellen Verzeichnis sucht und dort liegen die Dateien auch tatsächlich

Wenn also das entsprechende Verzeichnis im Suchpfad ist, dann werden die Dateien auch in "check_signed_image" gefunden. Warum ich dieses Skript nicht ändern konnte und wollte, habe ich bereits geschrieben.

Eigentlich ist der zusätzliche Aufruf mit "check" extra deshalb vorhanden, damit fehlende Bestandteile (auch wenn die inzwischen drei Monate im "modfs"-Archiv enthalten sind) nicht zu einem Fehler bei der Prüfung führen ... hier hat sich die zusätzliche Änderung mit dem Wechsel des Verzeichnisses beim Aufruf von "check_image_signature" (wer sich dafür interessiert, kann ja die Commits dazu ansehen) dann negativ auf den "check"-Aufruf ausgewirkt.

Ohne diesen Wechsel wurde bereits "openssl" nicht gefunden und der Test entsprechend übersprungen ... außer bei einer kompletten Installation auf meinen FRITZ!Boxen, wo "openssl" eben zur Grundausstattung gehört und in jeder Firmware (über ein passendes Image für E99-custom) erreichbar ist.
 
Auch mit der letzten Version keine Änderung? Ist imho ja auch nicht so wichtig, solange man den Signaturcheck auch weglassen kann.

Code:
Ermitteln der Hardware-Version ... OK
Pr  fen, ob die Hardware-Version unterst  tzt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Pr  fen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ...   bersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
  berpr  fen des zur Verf  gung stehenden Speicherplatzes im RAM ... OK
  berpr  fen des freien Speicherplatzes f  r das Auspacken des Dateisystems ... OK

Das System erf  llt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment l  uft auf der Box die Version: 113.06.60

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionpr  fung.
Somit ist jeder selbst daf  r zust  ndig, die Kompatibilit  t der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgef  hrt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/modd2/41137.image' wird als Quelle f  r die Aktualisierung genutzt.
  berpr  fen der Signatur der geladenen Datei ... Fehler


# showshringbuf modfs
2016-09-22 12:01:45.086 - modfs: starting modfs script version 0.3.5-210920162027
2016-09-22 12:01:45.105 - modfs: script=./modfs
2016-09-22 12:01:45.127 - modfs: using language de
2016-09-22 12:01:45.155 - modfs: using temporary file list from /var/tmp/4859_filelist_1474538505
2016-09-22 12:01:45.175 - modfs: cleanup trap set
2016-09-22 12:01:45.194 - modfs: invoked with: update 41137.image
2016-09-22 12:01:45.216 - modfs: noversioncheck=1, update_file_provided=1
2016-09-22 12:01:45.235 - modfs: firmware_update_file=41137.image
2016-09-22 12:01:45.256 - check_prerequisites: starting checks
2016-09-22 12:01:45.309 - progress: mode=1, msg=Ermitteln der Hardware-Version ...
2016-09-22 12:01:45.338 - check_prerequisites: hwrev=185
2016-09-22 12:01:45.393 - progress: mode=3, msg= OK
2016-09-22 12:01:45.447 - progress: mode=1, msg=Pr  fen, ob die Hardware-Version unterst  tzt wird ...
2016-09-22 12:01:45.470 - check_prerequisites: supported hardware revision
2016-09-22 12:01:45.524 - progress: mode=3, msg= OK
2016-09-22 12:01:45.578 - progress: mode=1, msg=Suchen der Einstellung zur Umschaltung auf das alternative System ...
2016-09-22 12:01:45.608 - check_prerequisites: system switch value is 1
2016-09-22 12:01:45.662 - progress: mode=3, msg= OK
2016-09-22 12:01:45.715 - progress: mode=1, msg=Pr  fen der aktuell zu startenden Systemversion ...
2016-09-22 12:01:45.831 - progress: mode=3, msg= OK
2016-09-22 12:01:45.887 - progress: mode=1, msg=Suchen der aktuellen Kernel-Partition ...
2016-09-22 12:01:45.914 - check_prerequisites: kernel device is /dev/mtdblock2
2016-09-22 12:01:45.968 - progress: mode=3, msg= OK
2016-09-22 12:01:46.022 - progress: mode=1, msg=Suchen der alternativen Kernel-Partition ...
2016-09-22 12:01:46.049 - check_prerequisites: alternative kernel device is /dev/mtdblock0
2016-09-22 12:01:46.103 - progress: mode=3, msg= OK
2016-09-22 12:01:46.158 - progress: mode=1, msg=Vergleich der Systeme in den Kernel-Partitionen ...
2016-09-22 12:01:46.212 - progress: mode=3, msg=   bersprungen
2016-09-22 12:01:46.267 - progress: mode=1, msg=Suchen der aktuellen Dateisystem-Partition ...
2016-09-22 12:01:46.294 - check_prerequisites: filesystem device is /dev/mtdblock3
2016-09-22 12:01:46.348 - progress: mode=3, msg= OK
2016-09-22 12:01:46.402 - progress: mode=1, msg=Suchen der alternativen Dateisystem-Partition ...
2016-09-22 12:01:46.429 - check_prerequisites: alternative filesystem device is /dev/mtdblock1
2016-09-22 12:01:46.483 - progress: mode=3, msg= OK
2016-09-22 12:01:46.539 - progress: mode=1, msg=  berpr  fen des zur Verf  gung stehenden Speicherplatzes im RAM ...
2016-09-22 12:01:46.566 - check_free_tmpfs: wanted=25165824, needed=10485760
2016-09-22 12:01:46.594 - check_free_tmpfs: exiting, rc=0
2016-09-22 12:01:46.652 - progress: mode=3, msg= OK
2016-09-22 12:01:46.706 - progress: mode=1, msg=  berpr  fen des freien Speicherplatzes f  r das Auspacken des Dateisyst
ems ...
2016-09-22 12:01:46.731 - find_free_storage_space: needed=140509184, accept=
2016-09-22 12:01:46.858 - get_nand_mountpoint: location=/var/media/ftp
2016-09-22 12:01:46.889 - check_free_nand: size=140509184, nand=/var/media/ftp, free=269950976
2016-09-22 12:01:46.910 - find_free_storage_space: /var/media/ftp:269950976
2016-09-22 12:01:46.930 - find_free_storage_space: exiting, rc=0
2016-09-22 12:01:46.985 - progress: mode=3, msg= OK
2016-09-22 12:01:47.004 - check_prerequisites: exiting, rc=0
2016-09-22 12:01:47.923 - modfs: source=file_update
2016-09-22 12:01:47.953 - modfs: firmware update file=41137.image
2016-09-22 12:01:48.010 - progress: mode=3, msg=Die angegebene Datei '/var/media/ftp/modd2/41137.image' wird als Quelle
f  r die Aktualisierung genutzt.
2016-09-22 12:01:48.035 - find_free_space: wanted=100M, order=tmpfs nand storage
2016-09-22 12:01:48.062 - check_free_tmpfs: wanted=104857600, needed=104857600
2016-09-22 12:01:48.090 - check_free_tmpfs: exiting, rc=0
2016-09-22 12:01:48.109 - find_free_space: tmpfs=/var/tmp
2016-09-22 12:01:48.128 - find_free_space: exiting, rc=0
2016-09-22 12:01:48.149 - get_working_directory: /var/tmp
2016-09-22 12:01:48.169 - modfs: working directory=/var/tmp
2016-09-22 12:01:48.197 - modfs: image directory=/var/tmp/1474538508
2016-09-22 12:01:48.217 - try_to_check_integrity: target=/var/media/ftp/modd2/41137.image
2016-09-22 12:01:48.268 - progress: mode=1, msg=  berpr  fen der Signatur der geladenen Datei ...
2016-09-22 12:01:48.933 - progress: mode=3, msg= Fehler
2016-09-22 12:01:48.952 - try_to_check_integrity: integrity check failed, error code was 1
2016-09-22 12:01:48.972 - try_to_check_integrity: exiting, rc=205
2016-09-22 12:01:48.992 - cleanup: running cleanup from file /var/tmp/4859_filelist_1474538505
2016-09-22 12:01:49.011 - /var/media/ftp/modd2/bin/185/busybox rm -r /var/tmp/1474538508
#

Edit. Danke für die Hinweise zur selbstständigen Fehlersuche. Wenn der Signaturcheck halt negativ ausfällt ... who cares.
 
Zuletzt bearbeitet:
Mich interessiert das Thema schon, schließlich war u.a. die Möglichkeit der Signaturprüfung in "modfs" ja eine der Triebfedern für die Umsetzung des Signatur-Themas außerhalb der AVM-Firmware.

Ich habe zwei Commits eingecheckt, die den Aufruf über den relativen Dateinamen durch einen über den Suchpfad ersetzen. Jetzt sollte entweder die Signaturprüfung irgendwann funktionieren (auch Rückmeldungen von anderen sind gerne gesehen) oder die Dateien sollten bereits bei der Überprüfung nicht gefunden werden.

Für einen manuellen Test kann man auch das Folgende als "arme Leute"-Ersatz für ein fehlendes "which"-Applet verwenden:
Code:
$ w=<filename>;OIFS="$IFS";IFS=: set -- $PATH;for p in $*; do [ -f $p/$w ] && echo "$p/$w";done;IFS="$OIFS"
, das gibt dann den Pfad der gesuchten Datei "<filename>" aus, sofern die irgendwo in einem Verzeichnis im Suchpfad gefunden wird - im Gegensatz zum "which"-Applet sogar für jedes Vorkommen von "<filename>" in einem Verzeichnis im Suchpfad (das Applet bricht nach dem ersten Fund ab).

Wenn ich das nach einigen Änderungen am Suchpfad auf meinem System für "openssl" verwende, wird das erwartungsgemäß nicht gefunden (das "set -x" führt zur Anzeige jedes Kommandos):
Code:
$ set -x;w=check_signed_image;OIFS="$IFS";IFS=: set -- $PATH;for p in $*; do [ -f $p/$w ] && echo "$p/$w";done;IFS="$OIFS"
+ set -x
+ w=check_signed_image
+ OIFS=

+ IFS=: set -- /bin:/usr/bin:/sbin:/usr/sbin
+ [ -f /bin/check_signed_image ]
+ [ -f /usr/bin/check_signed_image ]
+ [ -f /sbin/check_signed_image ]
+ [ -f /usr/sbin/check_signed_image ]
+ IFS=

$ set -x;export PATH=/var/custom/usr/bin:$PATH;w=openssl;OIFS="$IFS";IFS=: set -- $PATH;for p in $*; do [ -f $p/$w ] && echo "$p/$w";done;IFS="$OIFS"
+ set -x
+ export PATH=/var/custom/usr/bin:/bin:/usr/bin:/sbin:/usr/sbin
+ w=openssl
+ OIFS=

+ IFS=: set -- /var/custom/usr/bin:/bin:/usr/bin:/sbin:/usr/sbin
+ [ -f /var/custom/usr/bin/openssl ]
+ echo /var/custom/usr/bin/openssl
[COLOR="#008000"]/var/custom/usr/bin/openssl
[/COLOR]+ [ -f /bin/openssl ]
+ [ -f /usr/bin/openssl ]
+ [ -f /sbin/openssl ]
+ [ -f /usr/sbin/openssl ]
+ IFS=

$
(inkl. der Gegenprobe) und trotzdem funktioniert der "modfs"-Aufruf mit den zwei letzten Commits - hier können also auch die besonderen Umstände auf meinem System keine Ergebnisse mehr verfälschen:
Code:
$ ./modfs update ../system/FB7490/firmware/FRITZ.Box_7490_Labor.113.06.69-41137.image
Using debug mode with a 64 KB buffer
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.69-41137

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/system/FB7490/firmware/FRITZ.Box_7490_Labor.113.06.69-41137.image' wird als Quelle für die Aktualisierung genutzt.
[COLOR="#0000FF"]Überprüfen der Signatur der geladenen Datei ... [COLOR="#008000"]OK[/COLOR]
[/COLOR]Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... OK
Entpacken des root-Dateisystems für die Modifikationen ... -
[...]
Wenn es jetzt immer noch nicht funktionieren sollte und man an der Lösung interessiert ist, muß man eben die verwendeten Aufrufe aus "modfs" mal von Hand und außerhalb machen.

Es gibt/gab ja von der 41137 m.W. auch mehrere Versionen (die "Inhouse-Variante" - die hat kein "Labor" oder "LabBETA" im originalen Dateinamen - und die offizielle Labor-Version) und ich habe irgendwann mal geprüft, ob die Entwicklerversion mit demselben Schlüssel signiert wird - das war damals der Fall. Bei mir wurde auch die offizielle Labor-Version verwendet ... es kann also auch nicht mehr am falschen Schlüssel liegen.

Der Aufruf zum eigenen Test (aus dem "modfs"-Verzeichnis heraus) sähe so aus (wobei aus "modfs" heraus das zusätzliche Verzeichnis im Pfad ein absolutes sein sollte):
Code:
$ [COLOR="#0000FF"]PATH=./bin/VR9:$PATH check_signed_image /var/tmp/FRITZ.Box_7490.113.06.69-41164.image -b[/COLOR]
Found OpenSSL 1.0.2h  3 May 2016
Check dgst command ... OK
Check rsautl command ... OK
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... OK
Checking support for the used hash algorithm md5 ... OK
Verification succeeded.
$ [COLOR="#0000FF"]PATH=/var/media/ftp/modfs/bin/VR9:$PATH check_signed_image /var/tmp/FRITZ.Box_7490.113.06.69-41164.image -b[/COLOR]
Found OpenSSL 1.0.2h  3 May 2016
Check dgst command ... OK
Check rsautl command ... OK
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... OK
Checking support for the used hash algorithm md5 ... OK
Verification succeeded.
$ [COLOR="#0000FF"]echo $PATH[/COLOR]
/bin:/usr/bin:/sbin:/usr/sbin
... auch wenn hier mit der aktuellen Entwicklerversion von AVM geprüft wird, sollte das Ergebnis vergleichbar sein.
 
Mangels Kenntnis der kompletten Verzeichnis-Struktur und auch Beginner an der Console, mag ich mich zu dumm anstellen. Andere User können dabei sicherlich besser testen.

Ich habe das "offizielle" (über die Laborseite von AVM) gezogene 41137.image in Verwendung.

Einen Teilerfolg kann ich sehen. Weshalb "mktemp" Line 361 angemeckert wird? k.A.

Code:
# PATH=./bin/VR9:$PATH check_signed_image /var/media/ftp/modd2/41137.image -b
Found OpenSSL 1.0.2h  3 May 2016
Check dgst command ... OK
Check rsautl command ... OK
./bin/VR9/check_signed_image: line 361: mktemp: not found
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... OK
Checking support for the used hash algorithm md5 ... OK
WARNING: can't open config file: /var/custom_config/ssl/openssl.cnf
Signature verification failed.

Unter /var/ habe ich hier auch keine custom_config/ssl/openssl.cnf. Das müsste man sich wohl irgendwie mit einbauen, was ich eh nicht aus dem Stehgreif als "Fingerentspannungsübung" :mrgreen: beherrsche.

LG und sorry wenn ich nicht Schritt-Halten kann.
 
"mktemp" ist halt als Applet in der kompletten BusyBox enthalten (die wieder im "bin"-Verzeichnis wäre) und hier wird offenbar eine BusyBox-Variante verwendet, die kein "mktemp" enthält.

Da hier beim gesonderten Aufruf auch nicht die BusyBox aus dem Archiv zum Einsatz kommt (die sucht zuerst nach Applets und schaut erst dann ins Dateisystem), findet die BusyBox das Applet gar nicht.

Die fehlende "openssl.cnf" ist in diesem Falle tatsächlich nur eine Warnung wert, die Prüfung funktioniert auch ohne diese Datei:
Code:
$ [COLOR="#0000FF"]rm /var/custom_config/ssl/openssl.cnf[/COLOR]
$ [COLOR="#0000FF"]PATH=/var/media/ftp/modfs/bin/VR9:$PATH check_signed_image /var/tmp/FRITZ.Box_7490.113.06.69-41164.image -b[/COLOR]
Found OpenSSL 1.0.2h  3 May 2016
Check dgst command ... OK
Check rsautl command ... OK
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... OK
Checking support for the used hash algorithm md5 ... OK
[COLOR="#FF0000"]WARNING: can't open config file: /var/custom_config/ssl/openssl.cnf[/COLOR]
[COLOR="#008000"]Verification succeeded.[/COLOR]
$
Das Problem dürfte hier also das fehlende "mktemp" sein und das sollte als Problem beim Aufruf aus "modfs" heraus eigentlich nicht auftreten. Es ist halt extrem nervig, wenn man sich nicht auf die genutzte BusyBox-Version verlassen kann ... vor jedem Kommando erst zu prüfen, ob die richtige BusyBox verwendet wird oder alle anderen Voraussetzungen stimmen, bläht das ganze "modfs"-Skript noch mehr auf. Das muß ich mir erst einmal in aller Ruhe überlegen, was man da machen könnte ... hier sollte in jedem Falle vor dem Aufruf von "./modfs" ein gesondertes Kommando "bin/VR9/busybox sh" helfen, weil dann alle folgenden Aktionen zuerst nach passenden Applets suchen sollten (das startet eine neue Shell-Instanz aus der BusyBox im "modfs"-Paket).

Ich schaue mir mal an, ob man den Aufruf von "check_image_signature" vielleicht noch so modifizieren kann, daß in jedem Falle die BusyBox aus dem "modfs"-Paket verwendet wird. Vielleicht ist es (auch für die Aufteilung des großen "modfs"-Skripts in handlichere Stücke, die ich bei Zeit und Gelegenheit immer mal wieder weiter betreibe) sogar eine sinnvolle Überlegung, den Suchpfad für die Dauer von "modfs" ausschließlich auf das "modfs"-Verzeichnis (und "bin" darunter) zu begrenzen ... dann kommen garantiert keine unerwarteten Versionen mehr zum Einsatz.

Wenn mir etwas eingefallen ist, werde ich das hier im Thread mitteilen.

- - - Aktualisiert - - -

So, der nächste Versuch, das noch allgemeiner zu gestalten, damit es auf beliebigen Boxen/OS-Versionen läuft und keine falschen/unerwarteten Kommandos mehr dazwischenfunken können (vieles war bisher schon mit absoluten Pfaden, aber bei externen Skript-Dateien wird das sehr unhandlich).

Jetzt wird am Beginn geprüft, ob das Skript sich selbst noch einmal über einen zusätzlichen Aufruf mit der Shell aus der "modfs"-Busybox gestartet hat. Ist das nicht der Fall, wird dieser zusätzliche Aufruf gestartet und bei dieser Gelegenheit dann auch gleich noch der Suchpfad ausschließlich auf das Verzeichnis mit den "modfs"-Binärdateien beschränkt.

Bei der Gelegenheit bzw. beim Test ist dann gleich noch aufgefallen, daß sich "mod_rc_tail_sh" auch schon bei der Änderung der Firmware (zusätzlich allerdings auch zur Laufzeit, da ist das aber erhalten geblieben) auf die Existenz von "mkconfigfile" verläßt (das jetzt natürlich nicht mehr gefunden wird). Da das durch einen simplen Einzeiler zu ersetzen ist, habe ich das auch gleich noch mit ausgetauscht.
 
Sofern ich die richtige busybox gestartet habe,
Code:
BusyBox v1.22.1 (2015-06-09 10:54:06 CEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
hängt es stets an der selben Stelle auch mit der letzten version=0.3.5-220920161302

Ich komme mit NOVERIFY=1 für meine bescheidenen Ansprüche hier zurecht.
LG+TX für die Mühe

Es bleibt hier derselbe Fehler
Code:
Die angegebene Datei '/var/media/ftp/modd4/41137.image' wird als Quelle f├╝r die Aktualisierung genutzt.
Überprüfen der Signatur der geladenen Datei ... Fehler
# showshringbuf modfs
2016-09-22 16:30:51.954 - modfs: starting modfs script version 0.3.5-220920161554
2016-09-22 16:30:51.972 - modfs: script=./modfs
2016-09-22 16:30:51.994 - modfs: using language de
2016-09-22 16:30:52.012 - modfs: search path is /var/media/ftp/modd4/bin/185
2016-09-22 16:30:52.039 - modfs: using temporary file list from /var/tmp/7510_filelist_1474554652
2016-09-22 16:30:52.058 - modfs: cleanup trap set
2016-09-22 16:30:52.077 - modfs: invoked with: update ./41137.image
2016-09-22 16:30:52.097 - modfs: noversioncheck=1, update_file_provided=1
2016-09-22 16:30:52.115 - modfs: firmware_update_file=./41137.image
2016-09-22 16:30:52.134 - check_prerequisites: starting checks
2016-09-22 16:30:52.184 - progress: mode=1, msg=Ermitteln der Hardware-Version ...
2016-09-22 16:30:52.212 - check_prerequisites: hwrev=185
2016-09-22 16:30:52.263 - progress: mode=3, msg= OK
2016-09-22 16:30:52.315 - progress: mode=1, msg=Pr  fen, ob die Hardware-Version unterst├╝tzt wird ...
2016-09-22 16:30:52.337 - check_prerequisites: supported hardware revision
2016-09-22 16:30:52.387 - progress: mode=3, msg= OK
2016-09-22 16:30:52.437 - progress: mode=1, msg=Suchen der Einstellung zur Umschaltung auf das alternative System ...
2016-09-22 16:30:52.466 - check_prerequisites: system switch value is 1
2016-09-22 16:30:52.516 - progress: mode=3, msg= OK
2016-09-22 16:30:52.566 - progress: mode=1, msg=Pr├╝fen der aktuell zu startenden Systemversion ...
2016-09-22 16:30:52.672 - progress: mode=3, msg= OK
2016-09-22 16:30:52.723 - progress: mode=1, msg=Suchen der aktuellen Kernel-Partition ...
2016-09-22 16:30:52.750 - check_prerequisites: kernel device is /dev/mtdblock2
2016-09-22 16:30:52.800 - progress: mode=3, msg= OK
2016-09-22 16:30:52.850 - progress: mode=1, msg=Suchen der alternativen Kernel-Partition ...
2016-09-22 16:30:52.877 - check_prerequisites: alternative kernel device is /dev/mtdblock0
2016-09-22 16:30:52.930 - progress: mode=3, msg= OK
2016-09-22 16:30:52.981 - progress: mode=1, msg=Vergleich der Systeme in den Kernel-Partitionen ...
2016-09-22 16:30:53.031 - progress: mode=3, msg=   bersprungen
2016-09-22 16:30:53.083 - progress: mode=1, msg=Suchen der aktuellen Dateisystem-Partition ...
2016-09-22 16:30:53.109 - check_prerequisites: filesystem device is /dev/mtdblock3
2016-09-22 16:30:53.160 - progress: mode=3, msg= OK
2016-09-22 16:30:53.211 - progress: mode=1, msg=Suchen der alternativen Dateisystem-Partition ...
2016-09-22 16:30:53.237 - check_prerequisites: alternative filesystem device is /dev/mtdblock1
2016-09-22 16:30:53.289 - progress: mode=3, msg= OK
2016-09-22 16:30:53.339 - progress: mode=1, msg=  berpr  fen des zur Verf  gung stehenden Speicherplatzes im RAM ...
2016-09-22 16:30:53.366 - check_free_tmpfs: wanted=25165824, needed=10485760
2016-09-22 16:30:53.393 - check_free_tmpfs: exiting, rc=0
2016-09-22 16:30:53.444 - progress: mode=3, msg= OK
2016-09-22 16:30:53.495 - progress: mode=1, msg=  berpr  fen des freien Speicherplatzes f  r das Auspacken des Dateisyst
ems ...
2016-09-22 16:30:53.519 - find_free_storage_space: needed=140509184, accept=
2016-09-22 16:30:53.637 - get_nand_mountpoint: location=/var/media/ftp
2016-09-22 16:30:53.666 - check_free_nand: size=140509184, nand=/var/media/ftp, free=203153408
2016-09-22 16:30:53.686 - find_free_storage_space: /var/media/ftp:203153408
2016-09-22 16:30:53.704 - find_free_storage_space: exiting, rc=0
2016-09-22 16:30:53.757 - progress: mode=3, msg= OK
2016-09-22 16:30:53.776 - check_prerequisites: exiting, rc=0
2016-09-22 16:30:54.226 - modfs: source=file_update
2016-09-22 16:30:54.251 - modfs: firmware update file=./41137.image
2016-09-22 16:30:54.306 - progress: mode=3, msg=Die angegebene Datei '/var/media/ftp/modd4/41137.image' wird als Quelle
f  r die Aktualisierung genutzt.
2016-09-22 16:30:54.328 - find_free_space: wanted=100M, order=tmpfs nand storage
2016-09-22 16:30:54.354 - check_free_tmpfs: wanted=104857600, needed=104857600
2016-09-22 16:30:54.382 - check_free_tmpfs: exiting, rc=0
2016-09-22 16:30:54.402 - find_free_space: tmpfs=/var/tmp
2016-09-22 16:30:54.420 - find_free_space: exiting, rc=0
2016-09-22 16:30:54.440 - get_working_directory: /var/tmp
2016-09-22 16:30:54.459 - modfs: working directory=/var/tmp
2016-09-22 16:30:54.486 - modfs: image directory=/var/tmp/1474554654
2016-09-22 16:30:54.504 - try_to_check_integrity: target=/var/media/ftp/modd4/41137.image
2016-09-22 16:30:54.553 - progress: mode=1, msg=Überprüfen der Signatur der geladenen Datei ...
2016-09-22 16:30:54.694 - progress: mode=3, msg= Fehler
2016-09-22 16:30:54.713 - try_to_check_integrity: integrity check failed, error code was 1
2016-09-22 16:30:54.732 - try_to_check_integrity: exiting, rc=205
2016-09-22 16:30:54.751 - cleanup: running cleanup from file /var/tmp/7510_filelist_1474554652
2016-09-22 16:30:54.769 - /var/media/ftp/modd4/bin/185/busybox rm -r /var/tmp/1474554654
#
 
Zuletzt bearbeitet:
Das kann eigentlich nicht die richtige BusyBox sein ... die im "modfs"-Verzeichnis sollte eine 1.24.2 sein.

Wenn da der Fehler weiterhin besteht (trotz automatischem, internen "respawn" mit der eigenen BusyBox), sollte man vielleicht wirklich erst einmal sicherstellen, daß die Image-Datei hier tatsächlich korrekt signiert ist. Auch das alte Problem des "short read" könnte da am Ende eine Rolle spielen, weil für die Berechnung des Hashes dann schon mal ein paar Blöcke fehlen könnten (selbst wenn die nur binäre Nullen enthalten sollten).

Das ist jedenfalls das neue Skript (man sieht es auch an der Uhrzeit von 15:54 in der ersten Zeile) und auch der angezeigte Suchpfad (vierte Zeile des Logs) ist plausibel und sollte verhindern, daß da andere Programme verwendet werden.

Vielleicht findet sich ja noch jemand, der das seinerseits unabhängig testet ... bei mir mag ja die speziellere Umgebung einen effektiven Test verhindern, aber wenn das am Ende das Image-File ist, sucht man sich vollkommen umsonst einen Wolf.

Wenn ich es nachher noch schaffe, baue ich die Update-Abfrage bei AVM ein ... allerdings kam heute ein OpenSSL-Update raus und das will auch erst einmal eingearbeitet werden.
 
Vorsorglich falls ausreichend
Code:
# md5sum 41137.image
1eecd611286fa546e589d1eb2366531c  41137.image
#

LG
 
Ja, der Hash stimmt überein ... bleibt die Frage, was anders ist.

Ein manueller Test wäre mit
Code:
# /var/media/ftp/modd4/bin/VR9/busybox sh --help
BusyBox v1.24.2 (2016-04-02 23:18:36 CEST) multi-call binary.

Usage: sh [-/+OPTIONS] [-/+o OPT]... [-c 'SCRIPT' [ARG0 [ARGS]] / FILE [ARGS]]

Unix shell interpreter
# echo $SHLVL
# /var/media/ftp/modd4/bin/VR9/busybox sh (da sieht man erst einmal keinen Unterschied)
# echo $SHLVL (das sollte jetzt um eins größer sein als vorher)
# export PATH=/var/media/ftp/modd4/bin/185
# check_signed_image /var/media/ftp/modd4/41137.image -b
# exit (verläßt dann die zusätzliche Shell aus der dritten Zeile)
machbar - alles auf die Pfade aus den bisherigen Protokollen ausgelegt.

Ich habe auch keine Idee mehr so richtig, woran es nun kranken könnte ... also muß man erst einmal sehen, ob das Problem in den Voraussetzungen für "check_signed_image" liegt oder in der Ausführung selbst.
 
Die richtige shell 1.2.4 hatte ich zuvor auchschonmal probiert in einem weiteren Anlauf.

Und jetzt -DANKE für die Zeilen- nochmals brav ausgeführt ;) ... die ersten 4Zeilen hinter ...--help-Ausgabe kein Problem
Code:
...check_signed_image /var/media/ftp/modd4/41137.image -b
gibt einen Fehler aus unterhalb/beim Aufruf von openssl ... check dgst command oder so ähnlich.

Gefühlt habe ich check_signed_image in Verdacht in Verbindung mit openssl.

Ich wäre froh, wenn auch andere user mit mehr Kompetenz mal testen könnten. Ich möchte nicht unnütz Mehrarbeit produzieren ;)

LG + TX
 
Dann frage ich mal ganz dumm wie baue ich mir ein signiertes image denn! Ich gebe es ehrlich zu bin glaube ich zu dumm da zu.

Wer das eine möglichkeit wenn ich nun mit modfs auf die FW FRITZ.Box_7490.113.06.51.image zurück gehe dann ein image mit freetz baue und das dann wieder per ./modfs update 7490_06.69-rev41137_labor-freetz-devel-13932M.de_20160922-094814.image. Oder ist das dann immer noch nicht signiert. Weil ich finde leider nichts in freetz wegen signiert zum einschalten
 
Hallo PeterPawn,
bei mir treten die Probleme auch auf, obwohl ich eigentlich modfs "Out-of-Box im Telnet-Mode" nutze:

Code:
# ./modfs update FRITZ.Box_7490_Labor.113.06.69-41137.image
respawn script with custom BusyBox shell
Using debug mode with a 64 KB buffer
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.69-41137

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image' wird als Quelle für die Aktualisierung genutzt.
Überprüfen der Signatur der geladenen Datei ... Fehler

Code:
# /bin/showshringbuf modfs
2016-09-22 19:03:28.169 - modfs: starting modfs script version 0.3.5-220920161554
2016-09-22 19:03:28.189 - modfs: script=./modfs
2016-09-22 19:03:28.213 - modfs: using language de
2016-09-22 19:03:28.243 - modfs: search path is /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/bin/185
2016-09-22 19:03:28.278 - modfs: using temporary file list from /var/tmp/8337_filelist_1474563808
2016-09-22 19:03:28.303 - modfs: cleanup trap set
2016-09-22 19:03:28.329 - modfs: invoked with: update FRITZ.Box_7490_Labor.113.06.69-41137.image
2016-09-22 19:03:28.360 - modfs: noversioncheck=1, update_file_provided=1
2016-09-22 19:03:28.382 - modfs: firmware_update_file=FRITZ.Box_7490_Labor.113.06.69-41137.image
2016-09-22 19:03:28.406 - check_prerequisites: starting checks
2016-09-22 19:03:28.470 - progress: mode=1, msg=Ermitteln der Hardware-Version ...
2016-09-22 19:03:28.504 - check_prerequisites: hwrev=185
2016-09-22 19:03:28.563 - progress: mode=3, msg= OK
2016-09-22 19:03:28.626 - progress: mode=1, msg=Prüfen, ob die Hardware-Version unterstützt wird ...
2016-09-22 19:03:28.651 - check_prerequisites: supported hardware revision
2016-09-22 19:03:28.715 - progress: mode=3, msg= OK
2016-09-22 19:03:28.771 - progress: mode=1, msg=Suchen der Einstellung zur Umschaltung auf das alternative System ...
2016-09-22 19:03:28.812 - check_prerequisites: system switch value is 0
2016-09-22 19:03:28.878 - progress: mode=3, msg= OK
2016-09-22 19:03:28.944 - progress: mode=1, msg=Prüfen der aktuell zu startenden Systemversion ...
2016-09-22 19:03:29.057 - progress: mode=3, msg= OK
2016-09-22 19:03:29.106 - progress: mode=1, msg=Suchen der aktuellen Kernel-Partition ...
2016-09-22 19:03:29.130 - check_prerequisites: kernel device is /dev/mtdblock0
2016-09-22 19:03:29.179 - progress: mode=3, msg= OK
2016-09-22 19:03:29.228 - progress: mode=1, msg=Suchen der alternativen Kernel-Partition ...
2016-09-22 19:03:29.253 - check_prerequisites: alternative kernel device is /dev/mtdblock2
2016-09-22 19:03:29.301 - progress: mode=3, msg= OK
2016-09-22 19:03:29.350 - progress: mode=1, msg=Vergleich der Systeme in den Kernel-Partitionen ...
2016-09-22 19:03:29.399 - progress: mode=3, msg= übersprungen
2016-09-22 19:03:29.448 - progress: mode=1, msg=Suchen der aktuellen Dateisystem-Partition ...
2016-09-22 19:03:29.473 - check_prerequisites: filesystem device is /dev/mtdblock1
2016-09-22 19:03:29.522 - progress: mode=3, msg= OK
2016-09-22 19:03:29.571 - progress: mode=1, msg=Suchen der alternativen Dateisystem-Partition ...
2016-09-22 19:03:29.596 - check_prerequisites: alternative filesystem device is /dev/mtdblock3
2016-09-22 19:03:29.645 - progress: mode=3, msg= OK
2016-09-22 19:03:29.694 - progress: mode=1, msg=Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ...
2016-09-22 19:03:29.719 - check_free_tmpfs: wanted=25165824, needed=10485760
2016-09-22 19:03:29.745 - check_free_tmpfs: exiting, rc=0
2016-09-22 19:03:29.794 - progress: mode=3, msg= OK
2016-09-22 19:03:29.843 - progress: mode=1, msg=Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ...
2016-09-22 19:03:29.866 - find_free_storage_space: needed=140509184, accept=
2016-09-22 19:03:29.979 - get_nand_mountpoint: location=/var/media/ftp
2016-09-22 19:03:30.006 - check_free_nand: size=140509184, nand=/var/media/ftp, free=74829824
2016-09-22 19:03:30.042 - check_space: needed=140509184
2016-09-22 19:03:30.176 - get_possible_usb_mountpoints: on=/var/media/ftp/USB-Stick-01
2016-09-22 19:03:30.216 - get_possible_usb_mountpoints: count=1
2016-09-22 19:03:30.235 - check_space:  /var/media/ftp/USB-Stick-01:87540304K
2016-09-22 19:03:30.256 - find_free_storage_space:   /var/media/ftp/USB-Stick-01:87540304K
2016-09-22 19:03:30.274 - find_free_storage_space: exiting, rc=0
2016-09-22 19:03:30.323 - progress: mode=3, msg= OK
2016-09-22 19:03:30.341 - check_prerequisites: exiting, rc=0
2016-09-22 19:03:30.799 - modfs: source=file_update
2016-09-22 19:03:30.824 - modfs: firmware update file=FRITZ.Box_7490_Labor.113.06.69-41137.image
2016-09-22 19:03:30.877 - progress: mode=3, msg=Die angegebene Datei '/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image' wird als Quelle für die Aktualisierung genutzt.
2016-09-22 19:03:30.897 - find_free_space: wanted=100M, order=tmpfs nand storage
2016-09-22 19:03:30.922 - check_free_tmpfs: wanted=104857600, needed=104857600
2016-09-22 19:03:30.948 - check_free_tmpfs: exiting, rc=0
2016-09-22 19:03:30.966 - find_free_space: tmpfs=/var/tmp
2016-09-22 19:03:30.984 - find_free_space: exiting, rc=0
2016-09-22 19:03:31.003 - get_working_directory: /var/tmp
2016-09-22 19:03:31.021 - modfs: working directory=/var/tmp
2016-09-22 19:03:31.046 - modfs: image directory=/var/tmp/1474563811
2016-09-22 19:03:31.065 - try_to_check_integrity: target=/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image
2016-09-22 19:03:31.113 - progress: mode=1, msg=Überprüfen der Signatur der geladenen Datei ...
2016-09-22 19:03:31.308 - progress: mode=3, msg= Fehler
2016-09-22 19:03:31.325 - try_to_check_integrity: integrity check failed, error code was 1
2016-09-22 19:03:31.344 - try_to_check_integrity: exiting, rc=205
2016-09-22 19:03:31.363 - cleanup: running cleanup from file /var/tmp/8337_filelist_1474563808
2016-09-22 19:03:31.381 - /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/bin/185/busybox rm -r /var/tmp/1474563811
#


Code:
# echo $PATH
/bin:/usr/bin:/sbin:/usr/sbin
Code:
# busybox --help
BusyBox v1.22.1 (2015-06-09 10:54:06 CEST) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2012.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, [[, arp, arping, ash, basename, brctl, bunzip2, bzcat, bzip2, cat, chgrp, chmod, chown, chroot, cmp, cp, cut, date, dd, df, dirname, dmesg, dnsdomainname, du, echo, egrep,
        env, ether-wake, expr, false, fgconsole, fgrep, find, flock, free, fstrim, ftpget, ftpput, getopt, grep, groups, gunzip, gzip, halt, hostname, id, ifconfig, ifdown, ifup,
        inetd, init, insmod, iostat, ip, ipaddr, iplink, iproute, iprule, iptunnel, kill, killall, killall5, ln, login, logname, ls, lsmod, lsof, md5sum, mkdir, mkfifo, mknod, mkswap,
        modprobe, more, mount, mpstat, mv, nbd-client, netstat, nice, nohup, nslookup, passwd, pidof, ping, ping6, pivot_root, pmap, poweroff, printenv, printf, ps, pstree, pwd, pwdx,
        readlink, realpath, reboot, renice, reset, rm, rmdir, rmmod, route, sed, seq, setconsole, setserial, sh, sha3sum, sleep, smemcap, sort, stat, stty, swapoff, swapon,
        switch_root, sync, sysctl, tail, tar, tee, telnetd, test, tftp, time, top, touch, tr, traceroute, true, tty, ubiattach, ubidetach, ubimkvol, ubirmvol, ubirsvol, ubiupdatevol,
        umount, uname, uniq, unxz, unzip, uptime, vconfig, vi, wc, wget, whois, xargs, xz, xzcat, zcat

#

auch ein Ändern der PATH-Umgebungsvariable hat keine Lösung ergeben:
Code:
# pwd
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554
#

# PATH=/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/bin/VR9 ./modfs update FRITZ.Box_7490_Labor.113.06.69-41137.image
respawn script with custom BusyBox shell
Using debug mode with a 64 KB buffer
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.69-41137

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image' wird als Quelle für die Aktualisierung genutzt.
Überprüfen der Signatur der geladenen Datei ... Fehler
#

Code:
# /bin/showshringbuf modfs
2016-09-22 19:09:53.757 - modfs: starting modfs script version 0.3.5-220920161554
2016-09-22 19:09:53.774 - modfs: script=./modfs
2016-09-22 19:09:53.794 - modfs: using language de
2016-09-22 19:09:53.812 - modfs: search path is /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/bin/185
2016-09-22 19:09:53.837 - modfs: using temporary file list from /var/tmp/9170_filelist_1474564193
2016-09-22 19:09:53.855 - modfs: cleanup trap set
2016-09-22 19:09:53.872 - modfs: invoked with: update FRITZ.Box_7490_Labor.113.06.69-41137.image
2016-09-22 19:09:53.893 - modfs: noversioncheck=1, update_file_provided=1
2016-09-22 19:09:53.910 - modfs: firmware_update_file=FRITZ.Box_7490_Labor.113.06.69-41137.image
2016-09-22 19:09:53.929 - check_prerequisites: starting checks
2016-09-22 19:09:53.978 - progress: mode=1, msg=Ermitteln der Hardware-Version ...
2016-09-22 19:09:54.003 - check_prerequisites: hwrev=185
2016-09-22 19:09:54.051 - progress: mode=3, msg= OK
2016-09-22 19:09:54.100 - progress: mode=1, msg=Prüfen, ob die Hardware-Version unterstützt wird ...
2016-09-22 19:09:54.121 - check_prerequisites: supported hardware revision
2016-09-22 19:09:54.169 - progress: mode=3, msg= OK
2016-09-22 19:09:54.218 - progress: mode=1, msg=Suchen der Einstellung zur Umschaltung auf das alternative System ...
2016-09-22 19:09:54.244 - check_prerequisites: system switch value is 0
2016-09-22 19:09:54.293 - progress: mode=3, msg= OK
2016-09-22 19:09:54.341 - progress: mode=1, msg=Prüfen der aktuell zu startenden Systemversion ...
2016-09-22 19:09:54.441 - progress: mode=3, msg= OK
2016-09-22 19:09:54.489 - progress: mode=1, msg=Suchen der aktuellen Kernel-Partition ...
2016-09-22 19:09:54.514 - check_prerequisites: kernel device is /dev/mtdblock0
2016-09-22 19:09:54.563 - progress: mode=3, msg= OK
2016-09-22 19:09:54.612 - progress: mode=1, msg=Suchen der alternativen Kernel-Partition ...
2016-09-22 19:09:54.636 - check_prerequisites: alternative kernel device is /dev/mtdblock2
2016-09-22 19:09:54.685 - progress: mode=3, msg= OK
2016-09-22 19:09:54.735 - progress: mode=1, msg=Vergleich der Systeme in den Kernel-Partitionen ...
2016-09-22 19:09:54.784 - progress: mode=3, msg= übersprungen
2016-09-22 19:09:54.832 - progress: mode=1, msg=Suchen der aktuellen Dateisystem-Partition ...
2016-09-22 19:09:54.857 - check_prerequisites: filesystem device is /dev/mtdblock1
2016-09-22 19:09:54.906 - progress: mode=3, msg= OK
2016-09-22 19:09:54.955 - progress: mode=1, msg=Suchen der alternativen Dateisystem-Partition ...
2016-09-22 19:09:54.980 - check_prerequisites: alternative filesystem device is /dev/mtdblock3
2016-09-22 19:09:55.028 - progress: mode=3, msg= OK
2016-09-22 19:09:55.078 - progress: mode=1, msg=Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ...
2016-09-22 19:09:55.103 - check_free_tmpfs: wanted=25165824, needed=10485760
2016-09-22 19:09:55.130 - check_free_tmpfs: exiting, rc=0
2016-09-22 19:09:55.179 - progress: mode=3, msg= OK
2016-09-22 19:09:55.227 - progress: mode=1, msg=Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ...
2016-09-22 19:09:55.250 - find_free_storage_space: needed=140509184, accept=
2016-09-22 19:09:55.363 - get_nand_mountpoint: location=/var/media/ftp
2016-09-22 19:09:55.390 - check_free_nand: size=140509184, nand=/var/media/ftp, free=74829824
2016-09-22 19:09:55.425 - check_space: needed=140509184
2016-09-22 19:09:55.560 - get_possible_usb_mountpoints: on=/var/media/ftp/USB-Stick-01
2016-09-22 19:09:55.599 - get_possible_usb_mountpoints: count=1
2016-09-22 19:09:55.619 - check_space:  /var/media/ftp/USB-Stick-01:87540304K
2016-09-22 19:09:55.639 - find_free_storage_space:   /var/media/ftp/USB-Stick-01:87540304K
2016-09-22 19:09:55.657 - find_free_storage_space: exiting, rc=0
2016-09-22 19:09:55.707 - progress: mode=3, msg= OK
2016-09-22 19:09:55.724 - check_prerequisites: exiting, rc=0
2016-09-22 19:09:56.158 - modfs: source=file_update
2016-09-22 19:09:56.183 - modfs: firmware update file=FRITZ.Box_7490_Labor.113.06.69-41137.image
2016-09-22 19:09:56.235 - progress: mode=3, msg=Die angegebene Datei '/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image' wird als Quelle für die Aktualisierung genutzt.
2016-09-22 19:09:56.256 - find_free_space: wanted=100M, order=tmpfs nand storage
2016-09-22 19:09:56.281 - check_free_tmpfs: wanted=104857600, needed=104857600
2016-09-22 19:09:56.306 - check_free_tmpfs: exiting, rc=0
2016-09-22 19:09:56.324 - find_free_space: tmpfs=/var/tmp
2016-09-22 19:09:56.343 - find_free_space: exiting, rc=0
2016-09-22 19:09:56.362 - get_working_directory: /var/tmp
2016-09-22 19:09:56.380 - modfs: working directory=/var/tmp
2016-09-22 19:09:56.406 - modfs: image directory=/var/tmp/1474564196
2016-09-22 19:09:56.424 - try_to_check_integrity: target=/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image
2016-09-22 19:09:56.471 - progress: mode=1, msg=Überprüfen der Signatur der geladenen Datei ...
2016-09-22 19:09:56.605 - progress: mode=3, msg= Fehler
2016-09-22 19:09:56.623 - try_to_check_integrity: integrity check failed, error code was 1
2016-09-22 19:09:56.642 - try_to_check_integrity: exiting, rc=205
2016-09-22 19:09:56.660 - cleanup: running cleanup from file /var/tmp/9170_filelist_1474564193
2016-09-22 19:09:56.677 - /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/bin/185/busybox rm -r /var/tmp/1474564196
#

evtl. helfen diese Inputs weiter;
ansonsten kann ich gerne weitere Diagnose-Inputs liefern.

Gruß
Pokemon20021
 
[SIZE=2pt]@Master SaMMy[/SIZE] in #835
Wenn es um das umshippern der Signatur Prüfung geht.
Code:
NOVERIFY=1 ./modfs update 7490_06.69-rev41137_labor-freetz-devel-13932M.de_20160922-094814.image
und die Hürde ist genommen.
LG

TX @Pokemon20021 ...
 
Zuletzt bearbeitet:
Ein manueller Test wäre mit
Code:
# /var/media/ftp/modd4/bin/VR9/busybox sh --help
BusyBox v1.24.2 (2016-04-02 23:18:36 CEST) multi-call binary.

Usage: sh [-/+OPTIONS] [-/+o OPT]... [-c 'SCRIPT' [ARG0 [ARGS]] / FILE [ARGS]]

Unix shell interpreter
# echo $SHLVL
# /var/media/ftp/modd4/bin/VR9/busybox sh (da sieht man erst einmal keinen Unterschied)
# echo $SHLVL (das sollte jetzt um eins größer sein als vorher)
# export PATH=/var/media/ftp/modd4/bin/185
# check_signed_image /var/media/ftp/modd4/41137.image -b
# exit (verläßt dann die zusätzliche Shell aus der dritten Zeile)
machbar

Hallo PeterPawn,
anbei die Ergebnisse dieses Tests:

Code:
# /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/bin/VR9/busybox sh --help
BusyBox v1.24.2 (2016-04-02 23:18:36 CEST) multi-call binary.

Usage: sh [-/+OPTIONS] [-/+o OPT]... [-c 'SCRIPT' [ARG0 [ARGS]] / FILE [ARGS]]

Unix shell interpreter
#
#
#
# echo $SHLVL
3
# pwd
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554
# /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/bin/VR9/busybox sh
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 #
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 #
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 #
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 #
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # bin/VR9/busybox sh
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # pwd
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # echo $SHLVL
5
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # export PATH=/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/bin/185
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # check_signed_image /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.
06.69-41137.image -b
Found OpenSSL 1.0.2h  3 May 2016
[COLOR=#ff0000]Check dgst command ... FAILED[/COLOR]
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 #
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 #
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # exit
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # exit
#

Gruß
Pokemon20021

- - - Aktualisiert - - -

hier der "sh -x" Output des relevanten Skripts:

Code:
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # ./bin/VR9/check_signed_image /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_
Labor.113.06.69-41137.image -b
Found OpenSSL 1.0.2h  3 May 2016
[COLOR=#ff0000]Check dgst command ... FAILED[/COLOR]
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 #

Code:
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # sh -x ./bin/VR9/check_signed_image /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box
_7490_Labor.113.06.69-41137.image -b
+ avm_default_files=/etc/avm_firmware_public_key[1-9] plugin_global_key.pem
+ eva_prompt=Eva_AVM
+ box_key_name=/var/flash/websrv_ssl_key.pem
+ box_cert_name1=/var/flash/websrv_ssl_cert.pem
+ box_cert_name2=/var/tmp/websrv_ssl_cert.pem
+ [ -z /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image ]
+ image_file=/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image
+ [ -f /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image ]
+ show_version
+ local v
+ openssl version
+ v=OpenSSL 1.0.2h  3 May 2016
+ [ 0 -eq 127 ]
+ echo -e Found \x1B[1;34mOpenSSL 1.0.2h  3 May 2016\x1B[0m
Found OpenSSL 1.0.2h  3 May 2016
+ return 0
+ [ 0 -ne 0 ]
+ echo -en Check \x1B[1mdgst\x1B[0m command ...
Check dgst command ... + echo
+ grep -q ^(stdin)=
[COLOR=#ff0000]+ openssl dgst
+ rc=127
+ [ 127 -eq 0 ]
+ show_error
+ echo -e \x1B[1;31mFAILED\x1B[0m
FAILED
+ exit 33
[/COLOR]/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 #

- - - Aktualisiert - - -

ich denke, dass es an Nutzung des /bin/busybox Binary in Verbindung mit Skript ./bin/VR9/check_signed_image liegt,
da es nach "Über-Mounten" des AVM-busybox Binary durch das modfs-busybox Binary
und Anpassen der PATH-Umgebungsvariable gut aussieht:

Code:
# ls -la bin/VR9/busybox /bin/busybox
-rwxrwxrwx    1 root     root        452396 Sep 16 13:34 /bin/busybox
-rwxr-xr-x    1 root     root       1196472 Apr  2 23:20 bin/VR9/busybox
#

[COLOR=#0000ff]# mount --bind bin/VR9/busybox /bin/busybox[/COLOR]

[COLOR=#0000ff]# export PATH=/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/bin/185[/COLOR]

# ./bin/VR9/check_signed_image /var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image -b
Found OpenSSL 1.0.2h  3 May 2016
[COLOR=#0000ff]Check dgst command ... OK[/COLOR]
Check rsautl command ... OK
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... OK
Checking support for the used hash algorithm md5 ... OK
WARNING: can't open config file: /var/custom_config/ssl/openssl.cnf
[COLOR=#0000ff]Verification succeeded.[/COLOR]
#

- - - Aktualisiert - - -

Code:
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # ls -la
drwxr-xr-x    6 root     root          4096 Sep 22 19:59 .
drwxrwxrwx   55 root     root          4096 Sep 22 19:01 ..
-r--r--r--    1 root     root         10745 Apr 26 17:18 BOOTSELECTION.ger
-rw-r--r--    1 root     root      26992640 Sep 16 19:29 FRITZ.Box_7490_Labor.113.06.69-41137.image
-r--r--r--    1 root     root         18092 Feb 13  2016 LICENSE
-r--r--r--    1 root     root         28257 Feb 13  2016 README.ger.outdated
-r--r--r--    1 root     root         17964 Feb 13  2016 README.outdated
drwxr-xr-x    3 root     root          4096 Sep 22 19:00 bin
drwxr-xr-x    2 root     root          4096 Sep 22 19:00 files
drwxr-xr-x    2 root     root          4096 Sep 22 19:00 locale
-rwxr-xr-x    1 root     root         97407 Sep 22 15:54 modfs
dr-xr-xr--    2 root     root          4096 Sep 22 19:00 modscripts
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 #

Code:
/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554 # ./modfs update ./FRITZ.Box_7490_Labor.113.06.69-41137.image
respawn script with custom BusyBox shell
Using debug mode with a 64 KB buffer
Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... übersprungen
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 113.06.69-41137

Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.

Die angegebene Datei '/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/FRITZ.Box_7490_Labor.113.06.69-41137.image' wird als Quelle für die Aktualisierung genutzt.
[COLOR=#0000ff]Überprüfen der Signatur der geladenen Datei ... OK[/COLOR]
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ... OK
SNIP
 
Zuletzt bearbeitet:
Das ist ja spannend ... mach mal den letzten Test mit dem "dgst"-Fehler bitte noch einmal und rufe die gesamte Zeile mit "sh -x" davor auf.

Wenn ich die entscheidende Zeile in "check_signed_image" von Hand aufrufe:
Code:
# echo "" | bin/VR9/openssl dgst 2>&1 | grep -q '^(stdin)=' 2>&1; echo $?
0
#
erhalte ich das erwartete Ergebnis und zwar auch dann, wenn auf STDERR die Warnung zur Konfigurationsdatei auftaucht. Da die Zeilen ja "buffered" sein sollten und das "grep" nach dem "(stdin)" am Beginn der Zeile sucht, sollte die existierende Ausgabezeile in
Code:
$ echo "" | bin/VR9/openssl dgst 2>&1
WARNING: can't open config file: /var/custom_config/ssl/openssl.cnf
(stdin)= 68b329da9893e34099c7d8ad5cb9c940
$
dann halt die zweite Zeile sein. Das kann eigentlich nur dann schiefgehen, wenn da STDERR und STDOUT verwürfelt werden, weil nicht zeilenweise geschrieben wird.

Egal, ich habe eine neue Version eingecheckt, die einfach versucht, die Warnung wg. der fehlenden "openssl.cnf" auszufiltern (die kommt - nur mal nebenbei bemerkt - bei den AVM-Versionen (openssl_genrsa/openssl_req) genauso, halt für eine andere Datei), bevor nach den entscheidenden Zeilen gesucht wird.

Die Umleitung von STDERR nach STDOUT muß bleiben, ansonsten findet das Skript einige Fehlernachrichten nicht richtig, die wirklich auf STDERR ausgegeben werden und in die Pipe gelangen müssen. Der Versuch des Ausfilterns wird aber wohl auch nur dann richtig funktionieren, wenn das wenigstens alles auf einer Zeile steht.

Wenn das jetzt immer noch nicht funktionieren sollte, dann lege ich einfach eine leere "openssl.cnf" an ... bisher konnte ich noch ganz gut die Einstellungen für die Übersetzung von "openssl" mit meinen eigenen Bedürfnissen (dazu gehört eben der Pfad "/var/custom_config" für Einstellungsdateien) zur Deckung bringen. Notfalls müßte ich eine gesonderte Version übersetzen, die ihre Einstellungen einfach in /var/openssl.cnf sucht, das spart das Anlegen des kompletten Pfades nur für eine leere Datei.

Aber bis dahin dauert es noch ... bitte jetzt erst einmal die geänderte Version testen. Ach so ... bei der Gelegenheit habe ich auch gleich noch das "openssl"-Binary gegen die heute neu erschienene Version (1.0.2i) ausgetauscht.

- - - Aktualisiert - - -

Ok, ich habe zu lange geschrieben und geändert ... teilweise sind da ja schon neue Erkenntnisse zu sehen.

Wobei rc=127 eigentlich daraufhin deutet, daß das Programm "openssl" gar nicht gefunden wurde beim Aufruf - das ist eher noch verblüffender.

- - - Aktualisiert - - -

Ich setze nachher doch besser die Idee mit der leeren "openssl.cnf" in "/var" um, dann ist das unabhängig vom Buffer-Verhalten beim Schreiben in irgendeine Pipe.

Allerdings habe ich gerade nach langer Zeit ein "merge" mit dem Freetz-Upstream gemacht und da arbeitet jetzt das Übersetzen des kompletten Trunks wohl noch eine Weile ... bis ich also die angepaßte Version von "openssl" erstellen kann, dauert es noch ein wenig - irgendwann in der Nacht wird es wohl werden.
 
Hallo PeterPawn,
ich habe die Fritzbox nochmals durchgebootet und getestet:

Code:
# ./bin/VR9/check_signed_image  FRITZ.Box_7490_Labor.113.06.69-41137.image -b
Missing openssl binary.
#

# [COLOR=#0000ff]export PATH=/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-220920161554/bin/185:$PATH[/COLOR]

# ./bin/VR9/check_signed_image  FRITZ.Box_7490_Labor.113.06.69-41137.image -b
Found OpenSSL 1.0.2h  3 May 2016
Check dgst command ... OK
Check rsautl command ... OK
./bin/VR9/check_signed_image: line 361: mktemp: not found
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... OK
Checking support for the used hash algorithm md5 ... OK
WARNING: can't open config file: /var/custom_config/ssl/openssl.cnf
[COLOR=#ff0000]Signature verification failed.[/COLOR]
#

d.h. die Signature-Verification macht Probleme

Gruß
Pokemon20021

- - - Aktualisiert - - -

nach "Über-Mounten" des AVM-busybox Binary durch das modfs-busybox Binary funktioniert es:

Code:
# [COLOR=#0000ff]mount --bind bin/VR9/busybox /bin/busybox[/COLOR]

# ./bin/VR9/check_signed_image  FRITZ.Box_7490_Labor.113.06.69-41137.image -b
Found OpenSSL 1.0.2h  3 May 2016
Check dgst command ... OK
Check rsautl command ... OK
Trying to determine the correct key now ...
Checking the public key from /etc/avm_firmware_public_key1 ... OK
Checking support for the used hash algorithm md5 ... OK
WARNING: can't open config file: /var/custom_config/ssl/openssl.cnf
[COLOR=#0000ff]Verification succeeded.[/COLOR]
#
 
Zuletzt bearbeitet:
Nun habe ich doch noch eine andere Lösung gewählt ... ich hoffe, daß die jetzt dem Problem der fehlenden Konfigurationsdatei endgültig den Zahn zieht - zumindest für den Aufruf von "check_signed_image".

- - - Aktualisiert - - -

Das Problem beim direkten Aufruf von "check_signed_image" aus einer anderen BusyBox sollte in "modfs" selbst nicht existieren, da sollte das "respawn" mit der richtigen Shell helfen.
 

Neueste Beiträge

Statistik des Forums

Themen
244,917
Beiträge
2,220,953
Mitglieder
371,687
Neuestes Mitglied
c002
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.