[Sammlung] Fragen, Probleme, Lösungen zum Thema "modfs-Starter"

[eisbaerin]

Das mit dem Datum ist tatsächlich kurios

Das hatte ich schon im Oktober bemerkt, ich habe es aber auf die für dich vieeeeel zu alte original drauf gewesene FW 113.06.05 geschoben.

 

[PeterPawn]

Bei unterschiedlichen Versionen des SquashFS können die Systeme gegenseitig das in der yaffs2-Partition enthaltene SquashFS-Image "filesystem_core.squashfs" nicht mounten und damit auch die dort enthaltene /etc/version nicht aufrufen (da die nur Shell-Code enthält, rufe ich die einfach auf anstatt mit irgendeinem Kommando im Text zu suchen) und darüber die Version ermitteln. Dann ist es "normal", wenn da "unknown" stehen würde:

alternative_filesystem=$(get_mtd_by_name $reservedprefix$filesystemname)
mp=$(mount_alternative_system $alternative_filesystem "$tempdir")
if [ $? -ne 0 ]; then
    alternative_version="unknown"
    [COLOR="#FF0000"]alternative_date[/COLOR]="unknown"
else
    alternative_version=$(get_system_version "$mp/")
    [COLOR="#FF0000"]alternative_date[/COLOR]=$(get_system_date "$mp/")
fi
[COLOR="#FF0000"]alternative_date="$(stat -c %Y "$tempdir/altfs/$rootfsimage")"[/COLOR]
[...]

Die komplett rote Zeile ist die Ursache für den falsch angezeigten Wert - das war am falschen Ende gespart mit der wiederholten Verwendung desselben Namens, wenn man den hinterher noch zur Anzeige benötigt. Das ist auch erst dazugekommen mit der Möglichkeit, daß das andere SquashFS eine abweichende Version haben könnte (also seit der 06.36+), daher habe ich damals wohl das nachträgliche Testen an dieser Stelle vergessen, weil ich mit dem Testen des eigentlichen "modfs"-Ablaufs bei den verschiedenen Kombinationen aus aktuellem und neuem System genug zu tun hatte.

Ich passe bei Gelegenheit mal das modscript dafür an auf dem Server ... das dauert aber noch 1-2 Tage, dann kommen da gleich noch ein paar optionale Patches für die 06.50 dazu (z.B. nervt es mich ebenfalls, daß beim Wechsel auf 06.30 die Einstellung "volume_labels" aus der usb.cfg gelöscht wird und jedesmal nach dem Wechsel auf 06.50 wieder gesetzt werden muß, wenn man sie braucht oder haben will ... da patche ich einfach den Test auf dieses "yes" raus) - vielleicht kann die ja auch jemand anderes dann nutzen.

 

[mrZAKspeed]

Ich hatte mich lange vor einem Update auf >6.29 gezogen weil ich die Störabstandsmarge über Telnet ändern muß (ca. +1MBit).
Danke an der Stelle für ShellInABox.
Hat mich insgesamt zwar etwas Zeit gekostet mich da reinzulesen was genau ich jetzt brauche aber schlußendlich wars dann doch recht einfach.

Habe soeben auf 6.50 geupdated, der 7490 ShellInABox aufs Auge gedrückt und konnte sofort ohne weitere Arbeiten den entsprechenden Wert ändern.

Super Arbeit.
Danke für die Mühen, die Arbeit, vor allem die Veröffentlichung des Ganzen und natürlich auch die super Erklärung im anderen Thread.
Danke danke danke!!!!

 

[H´Sishi]

Ich bekomme die ShellInABox nicht zum Laufen. Ich gehe nach Anleitung vor, aber nach einem Neustart gibt's auf Port 8010 keine Shell.

Gegeben:
- FW: 6.51-32297
- Box-Kennwort: gesetzt
- Ansicht: Erweitert

Wie beschrieben mault die Box beim Datei-Update wegen "keine von AVM freigegebene FW", eine Wiederholung oder ein Neustart führen leider nicht zum gewünschten Ergebnis.

Übersehe ich was, oder hat AVM wirklich die Tür zugemacht, vorher die Schlösser getauscht und nachher die Schlüssel weggeworfen?

 

[PeterPawn]

Wenn das die offiziell bereitgestellte Version ist, dann ist das genau das zu erwartende Ergebnis. Das Update ist ja eine "unsignierte Firmware" und damit wird die /var/install nie aufgerufen.

Wenn man das weiterhin verwenden will, muß man halt mit modfs von der 06.50 aus aktualisieren und dabei dann gleich die notwendigen Bestandteile mit in die inaktive Partition kopieren. Was das /var/install-Skript macht, ist ja im anderen Thread beschrieben ... wenn man das mount-Kommando entsprechend anpaßt, kann man sogar das Skript weitgehend weiterhin verwenden.

Ob ich die Absicht habe, eine Variante bereitszustellen, die nach "modfs" angewendet werden kann, um das System in der inaktiven Partitiion um SIAB zu erweitern anstatt das Telnet zu reaktivieren (auch das war ja nur ein "Abfallprodukt", ursprünglich ging es dabei mal um die "debug.cfg"), weiß ich noch nicht.

Eigentlich war auch das hier ja nur ein "proof of concept", der eher zu eigenen Experimenten einladen und andere Wege der Modifikation aufzeigen sollte, als eine 1:1 umzusetzende Anleitung. Daß der PoC sich direkt anwenden ließ, war nur ein "Sahnehäubchen" und je weiter sich die denkbaren Szenarien spreizen, um so mehr speziell auf einen Fall zugeschnittene Images/Skripte müßte man dann bereitstellen - das ist irgendwie nicht so ganz mein Ziel.

Eigentlich sollte sich jeder, der das Prinzip verstanden hat und auch bei einer FRITZ!Box mit einem Shell-Zugang nicht seinerseits wieder unnötige Security-Probleme einbauen würde, bei der Anpassung selbst helfen können ... insofern bin ich etwas zurückhaltender mit Rezepten. Manchmal muß man einige Leute auch vor sich selbst schützen und wenn man es allzu leicht macht, eine Box unsicher zu konfigurieren und zu betreiben, ist das schon fast "Beihilfe" - nur die Tatsache, daß SIAB mit TLS allemal besser und sicherer im LAN ist als die (unreflektierte) Reaktivierung von Telnet, hat mich dazu bewogen, das überhaupt als "Komplettllösung" bereitzustellen.

 

[yogie007]

@PeterPawn
Es ist ja heute die 6.51 für die 7490 als Fehlerupdate rausgekommen.
Frage: Ich habe unter der 6.50 das ShellInABox installiert, und es funktioniert einwandfrei.
Was passiert wenn ich jetzt auf 6.51 Update? Kann ich sollte es weg sein, es nochmal
neu installieren. oder gilt hier deine vorherige Antwort auch hier?
Vielen Dank.

 

[qwertz.asdfgh]

Logischerweise gilt seine vorhergehende Antwort.

 

[PeterPawn]

Ich muß mir erst einmal etwas einfallen lassen ... wer vorerst nur mittels "modfs" aktualisiert und dabei dann doch Telnet aktivieren läßt, für den ändert sich ja erst einmal nichts. Daß man sich das Recovery-Programm für die 06.50 gut weglegen sollte, habe ich schon mehrfach geschrieben (in den Firmware-Threads).

Ob man jetzt SIAB von einer Shell aus appliziert (egal ob in der aktiven oder der inaktiven Partition) oder über den Bootloader einen Kernel und ein passendes Filesystem lädt, das nur die Aufgabe des "Pseudo-Images" übernimmt und die Dateien in das yaffs2-Filesystem kopiert, weiß ich noch nicht genau ... aus Sicherheitsgründen (nur über LAN und nur bei Neustart der Box ist das dann möglich) würde ich zur Methode über EVA tendieren - die wäre dann auch noch so weit von weiteren Änderungen unabhängig, daß sie in der Perspektive am längsten halten dürfte.

Das setzt aber für "Normalbenutzer" ein Programm voraus, welches ähnlich wie das AVM-Recovery-Programm arbeitet (solange man das nicht von Hand machen will :mrgreen und das möglichst auch noch plattformübergreifend arbeiten kann. Zwar fällt da vielen sicherlich spontan das ruKernelTool ein, aber bisher weiß noch niemand, wie da die NAND-Boxen künftig behandelt werden und ich bin auch alles andere als begeistert, wenn ich ein ClosedSource-Programm "empfehlen" soll - von den Security-(Fehl-)Alarmproblemen wegen AutoScript oder ScriptIt oder was auch immer das war (habe ich verdrängt) ganz zu schweigen.

Ich denke da eher an eine Umsetzung in C#, die dann plattformübergreifend verwendet werden kann ... zwar wäre Java auch eine mögliche Lösung, aber das .NET-Framework ist schon etwas handlicher und bei neueren Windows-Versionen bereits definitiv installiert. Dann noch das "auto compile"-Feature sinnvoll genutzt und man kann mittels PowerShell unter Windows auch ganz gut arbeiten. Bei Java hätte man wieder entweder die Sourcen und müßte die erst übersetzen (und auch noch die dazu notwendige Umgebung installieren) oder man wäre mit einem fertigen JAR-Archiv ebenfalls wieder "blind", was da genau drin ist.

Wie gesagt, ich probiere noch ... am liebsten würde ich sogar hingehen und einen weiteren "public key" in /etc aufnehmen (das wäre die geringste Änderung) und dann künftig Images genauso signieren, wie es AVM auch macht. So eine Datei mit einem öffentlichen Schlüssel müßte sich wieder aus dem Wrapper-Dateisystem ziemlich einfach per bind-Mount über eine der AVM-Dateien legen lassen. Die entscheidende Frage hier wäre es für mich, ob sich jeder "Kunde" sein eigenes Schlüsselpaar zulegen soll/muß, was dann wieder entsprechende Tools erfordert und ein System, mit dem man sein eigenes Image auch signieren kann oder ob man einen privaten Schlüssel für diese Zwecke "veröffentlicht".

Dann macht natürlich jeder Bastler seine eigene Box wieder angreifbar, wenn er den zugehörigen "public key" installiert in /wrapper, aber auch das könnte man wahrscheinlich so machen, daß man als Vorbereitung auf das Flashen eines eigenen Images erst einmal einen Neustart machen muß, bei dem dieser öffentliche Schlüssel dann nur temporär eines der AVM-Files ersetzt.

Aber dazu muß man erst einmal eigene Images überhaupt signieren ... anders als bei AVM will ich das auch - so weit es geht - mit Standard-Tools lösen, was dann wieder leichter zu kontrollieren ist auf eingebaute "backdoors".

Der umgekehrte Weg (die Dateien weiterhin erst auf der Box zu ändern mit "modfs") würde künftig eben auch "mehr Sorgfalt" erfordern. Bisher lädt "modfs" die Image-Dateien auch über eine ungesicherte FTP-Verbindung direkt vom AVM-Server und läßt dabei aber jede Gültigkeitsprüfung außer acht. Wenn man das ebenfalls sicher machen will, sollte man zumindest ein originales AVM-Image auch entsprechend checken.

Die eingebauten "Kontroll-Möglichkeiten" ("firmwarecfg stream" bzw. "tr069fwupdate packet") sind aber entweder nicht "batchtauglich" (bei firmwarecfg, weil es da keinen passenden Exit-Code gibt, nur Dateien in /var/tmp, die man dann selbst prüfen muß) oder sie kommen im Moment nicht mit "richtigen" Firmware-Images klar (so bei "tr069fwupdate", was zwar die "/var/install" sogar startet, aber da die image-Dateien nicht nach /var/tmp kopiert werden, schlägt das "chksum" für den (fehlenden) Kernel fehl und "tr069fwupdate" liefert mit "3" den Fehlercode von "/var/install" zurück). Man müßte für eine Prüfung mit "openssl" erst einmal die AVM-Dateien (die sind "Text" mit dem Modulus und dem Exponenten) in ein lesbares Format (DER oder PEM) bringen.

Wie gesagt ... es gibt viele Möglichkeiten und welche man für einfacher erachtet, wird immer auch von den eigenen Erfahrungen beeinflußt. Ich bin noch am Probieren und Überlegen ... auch wenn einzelne Aspekte bereits funktionieren, muß man das erst einmal zu einem "laientauglichen Paket" zusammenschnüren und wie hoch dabei die Einstiegshürden sein dürfen, sieht auch jeder anders.

 

[KingTutt]

...über den Bootloader einen Kernel und ein passendes Filesystem lädt, das nur die Aufgabe des "Pseudo-Images" übernimmt und die Dateien in das yaffs2-Filesystem kopiert...

Das setzt aber für "Normalbenutzer" ein Programm voraus, welches ähnlich wie das AVM-Recovery-Programm arbeitet (solange man das nicht von Hand machen will :mrgreen

Geht denn ein FW Update über EVA überhaupt so einfach von Hand? Das Umsetzen einer Variable oder das entfernen von provider additiven ist ja fix gemacht!
Ich habe mal ein wenig in den alten Threads gesucht. Unter dem Titel "Firmware-Update per Konsole unter Linux" wird zwar mal etwas skizziert, aber wenn ich das richtig verstehe, wird da einerseits nur der Kernel kopiert (und nicht das Filesystem) und andererseits frage ich mich, ob das Kopieren nach mtd1 für NAND-Boxen überhaupt noch zutreffend ist?

Wenn ich Deinen Ausführungen im Thread "modfs-Starter" richtig verstanden habe, müsste man doch nur den Kernel und das Dateisystem in den RAM laden und starten (so wie AVM es bei einem Recover macht) damit das Script /sbin/flash_update den Rest bei einem Neustart übernimmt oder man müsste Kernel- und Dateiystsemimage in die Partitionen des "zweiten Systems" kopiert werden und zum Abschluss das bisher aktive System auf das neue umgeschaltet werden. Wie man das bei EVA macht, habe ich allerdings (zusammenfassend) noch nicht gefunden...

 

[koyaanisqatsi]

Moinsen


Hm, war da nicht was mit den Speicheradressen, die dann im Vorfeld ermittelt werden müssten?
Bei einer 7360SL, und wohl bei allen Anderen auch, in einer Konsole mit...

 cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00d81300 00020000 "rootfs"
mtd1: 001ded00 00020000 "kernel"
mtd2: 00020000 00020000 "urlader"
mtd3: 00040000 00020000 "tffs (1)"
mtd4: 00040000 00020000 "tffs (2)"
mtd5: 01000000 00020000 "reserved"
mtd6: 01000000 00020000 "mtd-nor"

...zu Ermitteln (steht bestimmt auch in den Supportdaten).

Hm, zumindest kennt man so die mtd Nummer/n die für ein Backup, in der Konsole auf USB Speicher mit cat, interessant wären.

 

[realhacker]

Das setzt aber für "Normalbenutzer" ein Programm voraus, welches ähnlich wie das AVM-Recovery-Programm arbeitet (solange man das nicht von Hand machen will :mrgreen und das möglichst auch noch plattformübergreifend arbeiten kann. Zwar fällt da vielen sicherlich spontan das ruKernelTool ein, aber bisher weiß noch niemand, wie da die NAND-Boxen künftig behandelt werden

Aber sicher doch. Frag doch einfach skyteddy! Per Email gab er mir bereitwillig Auskunft und nannte mir folgende Links:
http://rukerneltool.rainerullrich.de/FAQ.html#3.22
http://rukerneltool.rainerullrich.de/FAQ.html#1.44
http://rukerneltool.rainerullrich.de/Entstehung.html#update2016
http://rukerneltoolx.rainerullrich.de/ChangeLog_Long.txt

und ich bin auch alles andere als begeistert, wenn ich ein ClosedSource-Programm "empfehlen" soll

Open source ist keinen Deut besser als closed source, wie einige Beispiele die letzten 2 Jahre deutlich bewiesen haben. Aber diese Diskussion ist muessig und in erster Linie persönliche Ansichtssache.

- von den Security-(Fehl-)Alarmproblemen wegen AutoScript oder ScriptIt oder was auch immer das war (habe ich verdrängt) ganz zu schweigen.

Das kann dir mit jedem Programm passieren! Einfach das rukerneltool in die Ausnahmeliste hinzufuegen und Schluss ist mit dem Fehlalarm.

kind regards
DMC

 

[PeterPawn]

@reallhacker:
Danke für die Aufklärung - ich habe tatsächlich "gelernt", daß es einen neuen Branch 0.7 gibt. Das ist nett, aber für mich trotzdem vollkommen uninteressant.

Warum?

Wie Dir vielleicht entgangen ist, brauche ich das gar nicht selbst - insofern bellst Du bei mir den falschen Baum an.

Eine Empfehlung an andere für ein "closed source"-Programm, das - ob zurecht oder nicht, interessiert dabei gar nicht - bei AV-Lösungen die Alarmglocken klingeln läßt, kann ich trotzdem nicht mit meinen Ansichten vereinbaren, egal was Du dazu denken magst.

Das ist auch nicht vollkommen neu für r@iner, insofern brauchst Du da gar nicht "in die Bresche springen" ... und ich bin bei "open source" durchaus in der Lage (und mache das meistens auch, z.B. beim FBEditor), mir ein eigenes Bild vom "Innenleben" der Software zu machen. Das genau geht beim ruKernelTool nicht und insofern ist das nicht nur persönliche Ansichtssache, wie man zu so einem Programm steht (ich mache die Leute sogar darauf aufmerksam, daß sie den von mir veröffentlichten Sachen mißtrauen sollen und lieber selbst noch einmal nachsehen sollten - wie soll das da erst bei CS von anderen aussehen?) ... wenn man es durch andere Lösungen ersetzen kann, braucht es das schlicht nicht, schon gar nicht mit den damit einhergehenden Einschränkungen.

Schon das von Dir ebenfalls verlinkte Changelog zeigt nämlich sehr deutlich, warum das eben nicht die Lösung sein kann ... die derzeit aktuelle Version (0.7.0.4 vom 07.02.2016) funktioniert noch genau bis morgen abend (09.02.2016 23:00 Uhr). Wenn mir ein Programm genau dann, wenn ich es dringend brauchen würde, den Dienst wegen so einer ablaufenden Zeit verweigert (und ich mir bei womöglich nicht funktionierendem Router dann erst auf irgendwelchen anderen Wegen eine neue Version davon besorgen muß), dann ist das einfach keine Lösung, die ich akzeptieren kann und die ich jemand anderem empfehlen würde. Da kannst Du gar nichts gegen machen ... jede andere "Lösung" kann man sich "auf Vorrat" hinlegen und bei Bedarf darauf zurückgreifen.

BTW ... woher Du die Aussage

Das kann dir mit jedem Programm passieren! Einfach das rukerneltool in die Ausnahmeliste hinzufuegen und Schluss ist mit dem Fehlalarm.

nimmst, scheitert bei mir schon an dem Verständnis, woher Du wissen willst, daß es sich tatsächlich um einen Fehlalarm handelt. Das ist eben genau das "closed source"-Problem. Wenn Du zu den Leuten gehörst, die bei solchen Alarmmeldungen auch schon mal auf "trotzdem verwenden" gehen, wenn es denn nur dringend genug ist, hätte ich da noch die eine oder andere "Spezialversion" für Dich - bei Interesse Deinerseits.

 

[KingTutt]

Closed source ist keinen Deut besser als open source, wie einige Beispiele die letzten 2 Jahre deutlich bewiesen haben. Aber diese Diskussion ist muessig und in erster Linie persönliche Ansichtssache.

Es geht nicht darum, ob besser oder nicht, sondern es geht um die Nachvollziehbarkeit! Wenn ich mir sicher sein möchte, was die Software macht, kann ich bei OS nachsehen. Bei allem andren kann ich nur hoffen, dass das bei rauskommt, was mir "versprochen" wird.

@PeterPawn
Wenn das rukernel Tool im neusten Branch 7490 flaschen kann, muss es doch auch für EVA "einfach nur eine Reihe von Befehlen geben", um eine FW per FTP bei NAND Boxen auf zu spielen. Kannst DU mir da "ein wenig Hilfestellung" geben oder bist Du da selbst noch am Testen?

 

[PeterPawn]

@KingTutt:
Nicht am Testen, am Aufbereiten für eine Veröffentlichung und am Schreiben einer passenden "Anleitung" - das Prinzip beim Upload zur EVA kannst Du Dir aber hier schon ansehen - nur mittels einer (halbwegs vernünftigen) Shell (die mit "exec" umgehen kann) und den Kommandos "nc" und "mkfifo" realisiert, damit man nicht noch Perl o.ä. irgendwo installieren muß (wo das natürlich wieder einfacher geht, das weiß ich auch).

Das "Geheimnis" dabei ist dann aber das passende Image-File, das aus einer Kombination von Kernel und Dateisystem besteht und dessen /etc/inittab dann die Skripte starten könnte, um irgendwelche Dateien in die yaffs2-Partition zu kopieren.

 

[coco722]

Hallo, vorab auch von meiner Seite her vielen Dank, Lob und Anerkennung für das Shell-in-a-Box. Ich nutze version fs4 für Kernel 3.10 mit internationaler Labor 6.36.31667 .
Installation war einfach und erfolgreich, Funktion ist bestens (dachte anfänglich den nvi nur über telnet benutzen zu können, doch auch in der cgi des browsers IE oder Chrome fuktioniert es bestens, insofern gar nicht notwendig telnet separat zu starten).

Hätte zwei Fragen:
- Die shell nutzt busybox 1.21.1 und es gibt mittlerweile die busybox 1.24.1 (stable, gibt auch eine vorkomplilierte mipsel Version). Würde ein Ersetzen/upgrade der busybox funktionieren (und wie, falls nicht allzu umständlich)?
- lässt sich dropbear (ssh) zusätzlich zur Shell-in-a-Box problemlos installieren (und wie)? Freetz wird nicht genutzt.

 

[koyaanisqatsi]

Moins


Für MIPS Binaries (dropbearmulti, sftp-server) und Anleitungen, besuch mal: "http://www.fritzmod.net/de/"

./dropbearmulti --help
Dropbear SSH multi-purpose v2013.62
Make a symlink pointing at this binary with one of the following names:
'dropbear' - the Dropbear server
'dbclient' or 'ssh' - the Dropbear client
'dropbearkey' - the key generator
'scp' - secure copy

Hier mein Startskript...
rc.dropbear

#!/bin/sh
local CMD="env -i PATH=$PATH /var/tmp/dropbear"
local OPTIONS="-R -m -p 22"
local HELPTEXT="$(basename $0): [start|stop|restart]"
local PID=$(pidof dropbear)
start () {
$CMD $OPTIONS
}
stop () {
kill -1 $PID
}
restart () {
stop
sleep 1
start
}
case $1 in
start) start ;;
stop) stop ;;
restart) restart ;;
-h)echo $HELPTEXT ;;
--help)echo $HELPTEXT ;;
-?)echo $HELPTEXT ;;
*)echo $HELPTEXT ;;
esac
#EOF

busybox 1.24.1
...wo hast du denn die MIPS/MIPSEL Binaries gefunden?
Denn offiziell scheint es die noch nicht zu geben: "https://busybox.net/downloads/binaries/"

 

[coco722]

danke für die Rückmeldung.
wg busybox mag ich mich irren, jedoch ist unter den binaries (dein angegebener link ist korrekt) eine "busybox-mipsel" vom Datum 02.10.2015 (demnach vom Datum zumindest aktueller als die version 1.21.1 ...kann die Datei/version nicht auslesen, da es eine Binärdatei ist, und sie einfach mal auszuführen habe ich mich noch nicht getraut).


Die Anleitungen bei www.fritzmod.net sind ganz ok, nur wird da anscheinend eine NEUE/ZUSÄTZLICHE busybox unter /var/tmp installiert. Habe aber schon 2 busyboxen, und will diese beiden (oder eine davon) updaten... einmal die der originalen fw unter /bin/busybox und die andere vom ShellInABox-starterfs unter /var/custom/bin/busybox ... wobei die originale AVM version 1.21.1 mit weniger Befehlen ist als die shellinabox-version 1.21.1, da sind sehr viel mehr Befehle enthalten (sieht man bei Eingabe von
/bin/busybox oder mit /var/custom/bin/busybox ).

 

[eisbaerin]

shellinabox-version 1.21.1

Was soll der Quatsch? Was hat shellinabox mit der busybox zu tun?

Dann solltest du auch sehen, daß modfs-Starter die busybox Version 1.23.2 installiert.

Welche FB hast du eigentlich?
Ich verstehe nicht, was du immer mit einer "mipsel" willst.

busybox 1.24.1
...wo hast du denn die MIPS/MIPSEL Binaries gefunden?
Denn offiziell scheint es die noch nicht zu geben: "https://busybox.net/downloads/binaries/"

Ich habe auch eine Weile gesucht.
Genau unter deinem Link! Keinen Unter-Pfad weiter!
Die haben nur seit 2 Jahren vergessen neue Unter-Pfade anzulegen.
Und auch die unter "latest" sind schon 2 Jahre eingestaubt.
Habe ich aber auch erst gerade bemerkt.
Die unter deinem Link vom 5.10.2015 haben z.Z. die Version 1.24.0

BusyBox v1.24.0.git (2015-10-05 12:07:17 UTC) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list[-full]
   or: busybox --install [-s] [DIR]
   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:
        [, [[, acpid, add-shell, addgroup, adduser, adjtimex, arp, arping, ash,
        awk, base64, basename, beep, blkid, blockdev, bootchartd, brctl,
        bunzip2, bzcat, bzip2, cal, cat, catv, chat, chattr, chgrp, chmod,
        chown, chpasswd, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm,
        conspy, cp, cpio, crond, crontab, cryptpw, cttyhack, cut, date, dc, dd,
        deallocvt, delgroup, deluser, depmod, devmem, df, dhcprelay, diff,
        dirname, dmesg, dnsd, dnsdomainname, dos2unix, du, dumpkmap,
        dumpleases, echo, ed, egrep, eject, env, envdir, envuidgid, ether-wake,
        expand, expr, fakeidentd, false, fatattr, fbset, fbsplash, fdflush,
        fdformat, fdisk, fgconsole, fgrep, find, findfs, flock, fold, free,
        freeramdisk, fsck, fsck.minix, fstrim, fsync, ftpd, ftpget, ftpput,
        fuser, getopt, getty, grep, groups, gunzip, gzip, halt, hd, hdparm,
        head, hexdump, hostid, hostname, httpd, hush, hwclock, i2cdetect,
        i2cdump, i2cget, i2cset, id, ifconfig, ifdown, ifenslave, ifplugd,
        ifup, inetd, init, insmod, install, ionice, iostat, ip, ipaddr, ipcalc,
        ipcrm, ipcs, iplink, iproute, iprule, iptunnel, kbd_mode, kill,
        killall, killall5, klogd, less, linux32, linux64, linuxrc, ln,
        loadfont, loadkmap, logger, login, logname, logread, losetup, lpd, lpq,
        lpr, ls, lsattr, lsmod, lsof, lspci, lsusb, lzcat, lzma, lzop, lzopcat,
        makedevs, makemime, man, md5sum, mdev, mesg, microcom, mkdir, mkdosfs,
        mke2fs, mkfifo, mkfs.ext2, mkfs.minix, mkfs.vfat, mknod, mkpasswd,
        mkswap, mktemp, modinfo, modprobe, more, mount, mountpoint, mpstat, mt,
        mv, nameif, nanddump, nandwrite, nbd-client, nc, netstat, nice, nmeter,
        nohup, nslookup, ntpd, od, openvt, passwd, patch, pgrep, pidof, ping,
        ping6, pipe_progress, pivot_root, pkill, pmap, popmaildir, poweroff,
        powertop, printenv, printf, ps, pscan, pstree, pwd, pwdx, raidautorun,
        rdate, rdev, readahead, readlink, readprofile, realpath, reboot,
        reformime, remove-shell, renice, reset, resize, rev, rm, rmdir, rmmod,
        route, rpm, rpm2cpio, rtcwake, run-parts, runsv, runsvdir, rx, script,
        scriptreplay, sed, sendmail, seq, setarch, setconsole, setfont,
        setkeycodes, setlogcons, setserial, setsid, setuidgid, sh, sha1sum,
        sha256sum, sha3sum, sha512sum, showkey, shuf, slattach, sleep, smemcap,
        softlimit, sort, split, start-stop-daemon, stat, strings, stty, su,
        sulogin, sum, sv, svlogd, swapoff, swapon, switch_root, sync, sysctl,
        syslogd, tac, tail, tar, tcpsvd, tee, telnet, telnetd, test, tftp,
        tftpd, time, timeout, top, touch, tr, traceroute, traceroute6, true,
        truncate, tty, ttysize, tunctl, ubiattach, ubidetach, ubimkvol,
        ubirmvol, ubirsvol, ubiupdatevol, udhcpc, udhcpd, udpsvd, uevent,
        umount, uname, unexpand, uniq, unix2dos, unlink, unlzma, unlzop, unxz,
        unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, vlock, volname,
        watch, watchdog, wc, wget, which, whoami, whois, xargs, xz, xzcat, yes,
        zcat, zcip

 

[coco722]

@eisbär/in - Danke für Mitteilung/Infos/Anregungen... dennoch, eine eventuelle Unwissenheit, sonstige Unkenntnis oder eine evtl. missverständliche Aussage, ssollte nicht gleich als "Quatsch" bezeichnet werden. Einerseits wird eruiert "was habe shellinabox mit busybox zu tun" und andererseits "modf-Starter installiert busybox 1.23.2" - das modfs-Starter bietet demnach shelinabox und busybox, da ist schon ein gewisser Zusammenhang.
- MIPS bzw. MIPSEL (für ältere Box Prozessoren) sind vorgefertigte binaries, die man nutzen kann (bevor man selber das Ganze vorkompilieren muss), dass die Betreiber von "busybox.net" die Seite nicht besonders geplegt halten, ist aber nicht meine Schuld
- Auf meiner FB 7490 wurde vor etwa 1 Monat modfs-Starter injektion fs4 installiert, da ist keine busybox 1.23.2 sondern definitiv 1.21.1 .

Es ging mir um die Frage, ob ein update/überschreiben der in der FB laufenden busybox möglich wäre (in vereinfachter Form).

 

[koyaanisqatsi]

Das machst du einfach mit der PATH Variable.
Jedes Login sucht im Homeverzeichnis nach einer Datei namens: .profile
Da hab ich das so gemacht...
/var/tmp/.profile

[COLOR=#ff0000]PATH=/var/tmp:/var/tmp/bin:$PATH[/COLOR]
PS1=$(echo -e "\033[1;35m$(hostname) # \033[0;37m\n")
[COLOR=#ff0000]export PATH[/COLOR]
alias ls='ls -AFp --color=auto'
alias l='ls -al'
echo "Mit grosser Macht kommt grosse Verantwortung"
echo "clear_id 87" > /proc/tffs
/sbin/eventadd 1 "telnetd: Login von $(netstat -tepn|grep telnetd)"

...die busybox nach /var/tmp kopieren, und gleich in /var/tmp/bin installieren mit...

mkdir /var/tmp/bin && /var/tmp/busybox --install -s /var/tmp/bin

@eisbaerin: Danke, gefunden

busybox
BusyBox v1.24.0.git (2015-10-05 12:07:17 UTC) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list[-full]
   or: busybox --install [-s] [DIR]
   or: function [arguments]...