[Problem] Shellinabox von YourFritz auf FB 6490 installieren

[Trigus]

Hallo, ich wollte um später mod-fs und weitere Modifikationen durchzuführen Shellinabox auf meiner FritzBox 6490 installieren.
Dazu wollte ich nach diesem Beitrag von @PeterPawn vorgehen.

Das erste Problem bekomme ich aber schon, wenn ich versuche das Repo zu downloaden.

root@raspberrypi:/tmp# git clone -b binaries https://github.com/PeterPawn/YourFritz yf
Cloning into 'yf'...
fatal: Remote branch binaries not found in upstream origin

Das Problem konnte ich zwar umgehen indem ich einfach das -b binaries weggelassen habe aber jetzt bekomme ich erneut eine Fehlermeldung :

root@raspberrypi:/tmp/yf/toolbox# TOOLBOX_IMAGE_SIZE=3 ./build_shellinabox_implant_image FRITZ.Box_6490_Cable.de-en-es-it-fr-pl.141.07.01.image > SIAB-6490.image
Missing toolbox script '../bin/mips/3.10.73/shellinaboxd', starting from current directory.

Auch hier habe ich konnte ich mir einfach behelfen :

root@raspberrypi:/tmp/yf/bin# git clone https://github.com/PeterPawn/yf_bin.git
Cloning into 'yf_bin'...
remote: Enumerating objects: 87, done.
remote: Counting objects: 100% (87/87), done.
remote: Compressing objects: 100% (18/18), done.
remote: Total 429 (delta 4), reused 85 (delta 3), pack-reused 342
Receiving objects: 100% (429/429), 25.63 MiB | 489.00 KiB/s, done.
Resolving deltas: 100% (88/88), done.
root@raspberrypi:/tmp/yf/bin# cp -r /tmp/yf/bin/yf_bin/target/* /tmp/yf/bin

Jetzt bekomme ich aber einen Fehler, bei dem ich leider nicht weiter weiß :

root@raspberrypi:/tmp/yf/toolbox# ./build_shellinabox_implant_image FRITZ.Box_6490_Cable.de-en-es-it-fr-pl.141.07.01.image > SIAB-6490.image
tar: ./var/chksum.x86\n./var/chksum: Not found in archive
tar: Exiting with failure status due to previous errors
image/get_file_from_image: line 109: [: -eq: unary operator expected
image/get_file_from_image: line 138: [: 0: unary operator expected
tar: ./var/remote/var/tmp/kernel.image\n./var/remote/var/tmp/x86/kernel.image: Not found in archive
tar: Exiting with failure status due to previous errors
image/get_file_from_image: line 109: [: -eq: unary operator expected
image/get_file_from_image: line 138: [: 0: unary operator expected
tar: ./var/remote/var/tmp/filesystem.image\n./var/remote/var/tmp/x86/filesystem.image: Not found in archive
tar: Exiting with failure status due to previous errors
image/get_file_from_image: line 109: [: -eq: unary operator expected
image/get_file_from_image: line 138: [: 0: unary operator expected

Ich hoffe mir kann da jemand weiterhelfen, nachdem ich bei Freetz schon aufgegeben habe.

 

[PeterPawn]

Das erste Problem bekomme ich aber schon, wenn ich versuche das Repo zu downloaden.

Den ersten Satz im verlinkten Beitrag hast Du aber auch gelesen, oder?

Abgesehen davon, steht im verlinkten Beitrag durchaus auch eindeutig:

Das funktioniert aber eben nur für VR9-Modelle mit "wrapper"-Partition [...]

und meines Wissens gehört eine 6490 da eher nicht dazu.

Das "Impfen" einer 6490 mit SIAB funktioniert also gar nicht ... da muß man schon das gesamte SquashFS bei diesem Modell neu packen und das macht man dann ohnehin besser außerhalb der Box.

 

[Trigus]

Den ersten Satz im verlinkten Beitrag hast Du aber auch gelesen, oder?

Mmm ja.. ich komme zwar eigentlich ganz gut mit Github zurecht aber ich dachte "Auschecken" bezieht sich auf irgendwas anderes.

... da muß man schon das gesamte SquashFS bei diesem Modell neu packen

Gibt es den hier im Forum irgendwo eine Anleitung, wie das geht ? Da habe ich nun leider nicht viel Ahnung von und nur deinen Beitrag in der Richtung gefunden.

 

[PeterPawn]

Gibt es den hier im Forum irgendwo eine Anleitung, wie das geht ?

Ja, die gibt es (wenn nicht hier, dann woanders).

Außerdem ist das dazu notwendige Kommando "unsquashfs" hinreichend dokumentiert (z.B. hier: https://linux.cn/man/man1/unsquashfs.1.html) und dort findet man auch den Link zum benötigten Gegenstück "mksquashfs", wenn man das wieder einpacken will.

 

[Shirocco88]

Gibt es den hier im Forum irgendwo eine Anleitung, wie das geht ?

Meine Empfehlung für die Anforderung "Running SIAB@FB6490" wäre die Verwendung von Freetz, da gibt es inzwischen auch die Unterstützung für FB6490 für ATOM-CPU.
https://github.com/freetz/Freetz

 

[PeterPawn]

Verwendung von Freetz

Denkbar, aber fürchterlicher Overhead, wenn man wirklich nur SIAB installieren will. Die Binärdatei ist im "yf_bin" zu finden (statisch gelinkt) und man muß nichts weiter machen, als das Image auszupacken, die Binärdatei und ein passendes File in "/etc/init.d" hinzufügen (oder den Start zu einer existierenden Datei hinzufügen, z.B. zur "S85-app"), Image einpacken und über den Bootloader in die richtige Partition schreiben.

Der Aufwand dürfte also bei max. 20 Minuten (mit allem) liegen ... das braucht mit Freetz deutlich länger. Da die ATOM-CPU auch noch das LE-Format beim SquashFS4 verwendet, muß man nicht mal irgendwie nach den passenden Utilities suchen, weil das dann tatsächlich die Pakete aus den Distros handhaben können. Damit braucht man auch Freetz für die "tools" nicht - abgesehen davon, daß die passenden SquashFS-Utilities für BE-Format auch in "yf_bin" lägen.

 

[Trigus]

Denkbar, aber fürchterlicher Overhead, wenn man wirklich nur SIAB installieren will...

Danke. Ich denke jetzt habe ich eine ungefähre Vorstellung. Ich werde es gleich morgen mal versuchen.

 

[Shirocco88]

[Alternative-On]
das Aus-/Einpacken des Images in Verbindung mit Binary sowie RC-Skript dem Image hinzuzufügen könnte auch durch "fwmod" im "No Freetz"-Modus" automatisiert werden; Stichwort "fwmod_custom" anpassen;
https://freetz.github.io/wiki/help/howtos/development/repack_fw
[Alternative-Off]

 

[PeterPawn]

"fwmod" im "No Freetz"-Modus"

Ändert ja am Overhead nichts ... ich hatte ja extra noch festgehalten, daß der gar nicht im Erstellen eines "echten Freetz-Images" besteht, sondern bereits im (vor dem "fwmod" zweifellos erforderlichen) "make tools", bei dem jede Menge Übersetzungen erfolgen (bis hin zur BusyBox für den Build-Host und zu "fakeroot"), die man eigentlich nicht braucht. Oder hat sich das geändert und ich habe es nur nicht bemerkt?

Man benötigt ein stinknormales TAR-Kommando zum Extrahieren des (richtigen) SquashFS-Images aus der AVM-Datei und das "unsquashfs" zum Entpacken (praktisch jede aktuelle Linux-Distribution bietet das "squashfs-tools"-Paket an und das kann in Version 4 nur noch LE, was hier aber genau das benötigte Format ist).

Kopieren/Editieren sind Standardoperationen (müßte man ohnehin genauso "als Batch" in "fwmod_custom" einbauen) und danach braucht's noch genau den "mksquashfs"-Aufruf zum Einpacken.

Das ganze andere Gerödel, was dann von "Freetz" im "no-freetz"-Modus im Anschluß noch ausgeführt wird (Einpacken, Signieren), braucht hier kein Mensch, denn ohne den eigenen Key im bereits installierten Image (das dann ja wohl auch SIAB schon enthalten würde, wer würde sich ein Image nur mit dem Key bauen, wenn er eigentlich SIAB will) kann man damit gar nichts anfangen und muß es - für die Installation über den Bootloader - auch erst wieder in seine Bestandteile zerlegen.

Hat man hingegen bereits ein AVM-Image installiert (ARM-Kernel + -FS und ATOM-Kernel + -FS), braucht man ja auch nur die (aktive) ATOM-FS-Partition entsprechend zu ersetzen ... ich wiederhole also meinerseits einfach nioch einmal die Feststellung aus #6 (denn genau das habe ich ja zuvor schon "behauptet" und bei mir war nie davon die Rede, daß sich meine Replik auf "ein ganzes Freetz-Image" beziehen würde):

Denkbar, aber fürchterlicher Overhead, wenn man wirklich nur SIAB installieren will.

Hier stehen drei "übliche" Kommandos (tar -x, unsquashfs, mksquashfs) gegen eine komplette Freetz-Toolchain (zumindest deren "Host"-Teil) und den kompletten "Firmware-Builder" (ich müßte aber auch erst nachsehen, ob die ARM-Dateien ent- und wieder gepackt werden oder ob die 1:1 kopiert werden - bei ersterem wäre das Mißverhältnis noch krasser) - sowohl das "Kopieren/Editieren" als auch die Installation des eigenen SquashFS.-Images wäre beiden Wegen gemeinsam.

Selbst bei der "Installation" der Voraussetzungen in einer frischen Linux-Installation schneidet das DIY noch um Längen besser ab - eine der ersten Aktionen beim Freetz-Build ist ja wohl - da das derzeit nun mal "alles in einem" ist - das Testen auf das Vorhandensein diverser Build-Voraussetzungen (bis hin zum Developer-Paket für die "libreadline"), die hier am Ende niemand bräuchte.

Selbstverständlich gilt das alles nur dann, wenn man die einzubauenden Dateien (in diesem Falle das Shell-In-A-Box-Binary aus meinem "yf_bin"-Repo) bereits hat - aber mir ist so, als wäre das beim "no-freetz"-Modus ebenso der Fall, daß man die einzubauenden Files irgendwo schon haben sollte.

 

[Trigus]

So. Ich habe inzwischen das filesystem.image (müsste doch das unter ../var/remote/var/tmp/x86 sein, oder ?) extrahiert, nachdem ich anfangs Schwierigkeiten hatte, da ich erst spät bemerkt habe, dass xf Support nicht im Makefile aktiv war und die shellinaboxd Datei unter yf_bin/target/mips/3.10.73/ im Image nach /etc/init.d kopiert. Aber auch, wenn ich verstehen kann, dass die Binärdatei aufgerufen werden muss und nicht automatisch startet, weiß ich leider nicht, was du mit "ein passendes File" meintest bzw. wie ich die Datei "S85-apps" modifizieren soll.
Einfach ./shellinaboxd einfügen ?

... die Binärdatei und ein passendes File in "/etc/init.d" hinzufügen (oder den Start zu einer existierenden Datei hinzufügen, z.B. zur "S85-app")

 

[PeterPawn]

Schau mal in das Skript https://github.com/PeterPawn/YourFritz/blob/master/toolbox/build_shellinabox_implant_image hinein ... da wird ja auch für den Start (nach der "Impfung" mit SIAB bei den VR9-Modellen) nur die Datei https://github.com/PeterPawn/YourFritz/blob/master/toolbox/scripts/rc.shellinaboxd auf die Box kopiert (nach Substitution von variablen Werten) und die muß man dann halt nur mit dem Parameter "start" irgendwo aufrufen.

Das Binary gehört (schon nach LSB) nicht nach "/etc", sondern nach "/usr/sbin" am besten - wobei der Pfad auch im rc-File zu ändern ist.

In "/etc/init.d" gehört das "rc.shellinaboxd" (die Variablen darin müssen aber richtig gesetzt sein) und in irgendein anderes Skript aus der "Sxx"- bzw. "Exx"-Reihe (der Unterschied in der Bedeutung ist in "/etc/init.d/rc.S" nachzulesen) gehört dann dieser Aufruf mit "start" (das Home-Directory für den Benutzer "root" wird dann auch gleich passend mit angelegt, wie es durch die Variablen vorgegeben wurde) ... oder man macht das einfach alles selbst und dann kann man seiner Phantasie dabei freien Lauf lassen, wie man das integrieren möchte.

[ BTW: Auch hier macht es wieder keinen Unterschied, ob man das von Hand oder mit "fwmod" im "no-freetz"-Modus macht, denn die entsprechenden Kommandos müßte man auch in der "fwmod_custom" eintragen. Nur ein "full-blown Freetz image" würde einem hier den Start des Dienstes abnehmen mit dem entsprechenden Framework - zu einem (m.E. erheblichen) Preis. ]

 

[Trigus]

Ich hab jetzt die rc.shellinaboxd noch /etc/init.d/ kopiert, den Parameter my_executable="/usr/sbin/shellinaboxd" gesetzt, sowie shellinaboxd nach /usr/bin/ kopiert und ./rc.shellinaboxd in S85-apps eingetragen.
Jetzt nur noch mit

mksquashfs -comp xz squashfs-root/* filesystem.image
mv filesystem.image /var/remote/var/tmp/x86/
tar -cf var

wieder packen, oder ?
----
Wenn das geschafft ist :

Wie könnte ich das mit Dropbear machen ? Da gibt es ja in deinem Repo kein Script. Einfach die rc.shellinaboxd nehmen und

my_service="dropbear
my_display="Dropbear"
my_executable="/usr/sbin/dropbearmulti"

setzen ?


Beim Flashen einfach

ftp 192.168.178.1
- user : adam2
- passwort : adam2
quote MEDIA FLSH
binary
passive
debug
put filesystem.image mtd6
quote REBOOT

nicht ?

 

[PeterPawn]

Jetzt nur noch mit

mksquashfs -comp xz squashfs-root/* filesystem.image
mv filesystem.image /var/remote/var/tmp/x86/
tar -cf var

wieder packen, oder ?

Na ja, fast ... warum sollte man das wieder in ein TAR-File packen, wenn man doch hinterher das SquashFS-Image über den Bootloader in den Flash-Speicher schreibt? Macht ja nicht wirklich Sinn ...

Das "mksquashfs" braucht vermutlich noch die passenden Optionen (die von der Freetz-Toolchain erzeugten Utilities setzen automatisch die meisten Angaben schon passend für AVM-Kernel), die man sich am besten von der originalen "filesystem.image" von AVM abschaut, indem man das "unsquashfs" mit der "stat"-Option aufruft und dessen Ausgabe einfach mal liest. Da findet sich dann für jede denkbare Option des "mksquashfs" auch die Angabe, wie das im originalen File war ... und dann macht man das einfach ebenso.

Zum "dropbear": Im Prinzip wäre das richtig, nur ist "dropbear" ein "multi-call binary" (was das ist, suchst Du besser im Internet, bevor Du einfach wieder "nur fragst" ) und braucht passende Links und Parameter beim Aufruf. Das hat aber mit "YourFritz" (oder den Binaries in "yf_bin", die ich hier einfach mal dazugezählt habe) oder auch "Freetz" nur noch "am Rande" zu tun ... denn das ist absolut nichts, was irgendwie "speziell" für das FRITZ!OS wäre und daher kann man (neben dem eigenen "Probieren", was ja manchmal auch eine Option ist) auch durchaus mal andere Quellen im Internet konsultieren, wie das "richtig läuft".

Die Aufrufparameter für "shellinaboxd" oder auch "dropbear" (was die "Serverinkarnation" von "dropbearmulti" wäre, iirc) sind ja durchaus im Internet zu finden und auch "der Rest" beim Start so eines Programms, was von sich aus als "daemon" konzipiert ist, gestaltet sich bei einer FRITZ!Box jetzt nicht soo viel anders, als bei einem beliebigen Linux-System ... das "Bemerkenswerteste" ist da schon die "rc.S" und die daraus gestarteten "Sxx"- und "Exx"-Skripte.

Sich das dann noch einmal hier "bestätigen zu lassen" (also: "Ist das so korrekt? Es funktioniert leider nicht." anstelle von "Wie mache ich das genau?") oder um Hilfe bei der Fehlerbehebung zu bitten, wenn es dann (beim erwähnten "Probieren", was dem Hilferuf eben auch vorhergehen sollte) einfach nicht funktionieren will, steht wieder auf einem anderen Blatt ... aber eine "Fragestunde" (anstelle der eigenen Suche/Überlegung/Tests) fällt irgendwann auch dann mal auf, wenn man sie "temporär verteilt".

Ich denke mal, die "Basisausstattung" hast Du jetzt ... nun mach einfach was daraus oder probiere das zumindest mal, anstatt Dich nur "nach Anleitung" weiterzutasten. Ich bin nämlich auch noch nicht davon überzeugt, daß Du die Werte bei den "Substitutionen", die ab dieser Zeile: https://github.com/PeterPawn/YourFritz/blob/master/toolbox/scripts/rc.shellinaboxd#L24 beim "Installieren" des Skripts über eines meiner "toolbox"-Skripte vorgenommen werden, entsprechend gesetzt hast ... zumindest steht das nirgendwo und wenn Du nur betonst, daß Du "my_executable" angepaßt hast, schleicht sich bei mir eher der Verdacht ein, daß Du bis zu dieser Stelle gar nicht erst gekommen bist.

 

[Trigus]

..probiere das zumindest mal, anstatt Dich nur "nach Anleitung" weiterzutasten

Ja. Auch, wenn ich bei den meisten anderen Sachen lieber im Internet suche als zu fragen, brauchte ich erstmal eine Grundlage.

Ich bin nämlich auch noch nicht davon überzeugt, daß Du die Werte bei den "Substitutionen"[...] entsprechend gesetzt hast

Ich habe gedacht, dass währen Variablen, die bei der FritzBox irgendwo gespeichert sind. Das muss ich dann wohl nochmal anpassen.

Danke erstmahl für deine Hilfe.

EDIT : An alle die das vielleicht intressiert:
Die Befehle zum entpacken und packen waren

unsquashfs filesystem.image
mksquashfs squashfs-root/* filesystem.image -comp xz -no-xattrs[ -noappend -all-root -b 64K]

 

[PeterPawn]

Ich weiß nicht sicher, ob das tatsächlich reicht bzw. "so schlau" ist - andererseits scheint es ja zu funktionieren. Wenn ich mich nicht irre, ist die standardmäßige Blockgröße beim SquashFS4 aber 128 KB und bei AVM sind es nur 64 KB - und auch ein "-noappend" kann (aus reiner Vorsicht, falls das Ziel-Image dann doch mal existiert) genauso wenig falsch sein, wie ein "-all-root", falls man Dateien mit abweichendem Eigentümer in das zu packende Verzeichnis kopiert hat und das dabei nicht aus purer Absicht verwendet hat. Ein "normales" AVM-Image enthält nach dem Packen immer genau einen "user"-Eintrag:

Compression xz
Block size 65536
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always-use-fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 326
Number of inodes 4381
Number of ids 1

Möglich, daß es absolut nichts ausmacht ... wer sich so nahe wie möglich ans Original halten will, sollte aber auch die Blockgröße eben passend setzen (64 KB oben in der "stat"-Ausgabe) und Standard ist:

mksquashfs --help
SYNTAX:mksquashfs source1 source2 ... dest [options] [-e list of exclude
dirs/files]

Filesystem build options:
-comp <comp> select <comp> compression
Compressors available:
gzip (default)
lzo
lz4
xz
-b <block_size> set data block to <block_size>. Default 128 Kbytes
Optionally a suffix of K or M can be given to specify
Kbytes or Mbytes respectively
[...]

Zum "fragen": Ich verstehe das ja durchaus ... aber wenn das am Ende in ein "Ping-Pong-Spiel" ausartet mit Fragen und Antworten und es keine (sichtbaren) Erfolge gibt, kostet das (auf beiden Seiten, wenn man mal davon ausgeht, daß Du nicht hier nachfragst und dann einfach weitermachst, sondern dann Deinerseits wieder auf die Antwort wartest) nur unnötig Zeit.

Insofern muß man meine Aussage auch nicht falsch verstehen ... so richtig "unfreundlich" wäre es erst dann, wenn ich mir nur "denke": "Jetzt reicht's aber auch, soll er mal selbst suchen." und das nicht auch äußere ... denn was wäre dann das Ergebnis? Du sitzt vielleicht (Nägel kauend ) vor dem PC und wartest auf eine Antwort, die Du nicht kriegst und wunderst Dich nur, warum Du keine erhältst. Da ist meine "Ansage" dann - zumindest in meinen Augen - sogar noch "netter" und für die "Grundlage" sollte es ja nun (freundlich und zuvorkommend, wie das nun mal meine Art ist) auch gereicht haben.