[Problem] unsquashfs4-avm-be zum entpacken der DSL-Firmware für OpenWrt

[KarstenDE]

Hallo zusammen,

ich versuche aus der AVM-Firmware die enthaltene DSL-Firmware zu extrahieren um diese dann in OpenWRT zu nutzen.
Leider scheitert es an der Möglichkeit den Befehl "unsquashfs4-avm-be" zu starten.

Ich habe ihn bereits versucht aus den Freetz-Sourcen zu starten.
Ebenso ein Download aus GitHub "https://github.com/PeterPawn/yf_bin/blob/master/squashfs/i686/unsquashfs4-avm-be" hat nicht geholfen.

Die Datei ist jeweils vorhanden, lässt sich aber nicht starten. Auch ein chmod habe ich schon ausgeführt ...

Gibt es noch andere Möglichkeiten?

Vielen Dank!
Karsten

 

[PeterPawn]

Das Repo wurde im Ganzen geklont oder war es nur ein einzelner Download? Die URL zeigt ja auf die HTML-Seite bei GitHub ... um die eigentliche Datei zu kriegen, müßte man da ja bei "View raw" das Kontextmenü aufrufen und "Save link as ..." wählen, wenn man das als Download machen will und nicht einfach gleich das ganze Repo (am besten auch nicht nur "yf_bin", sondern "YourFritz" rekursiv mit Submodulen) auf einmal klont. Ist das Ziel ein natives Linux-Dateisystem, sollten auch die Dateirechte gleich korrekt gesetzt werden.

Nur mit "Save as ..." kriegt man jedenfalls den eigentlichen binären Inhalt der Datei beim Download und erst dann macht ein "chmod" auch wieder Sinn. Außerdem kann man mit "file <name>" sich ja anzeigen lassen, was das überhaupt für eine Datei ist ... dieses Kommando versucht das anhand aller möglichen Signaturen zu erkennen und wenn das keine ELF-Datei für 32-Bit-Systeme ist, ist da beim Download (ne, dann ja eigentlich nur beim Versuch eines Downloads) etwas daneben gegangen.

Zumindest die Ausgabe des erwähnten "file"-Kommandos sollte also mal gepostet werden ... ich bin schon aus dem Dialog in der GitHub-Issue nicht so ganz schlau geworden - aber hier wäre es ja dann wenigstens Deutsch, so daß da zumindest keine "Übersetzungsfehler" mit hineinspielen können.

Aber auch die Frage, warum da ein eigener Build mit der Freetz-Toolchain (und damit dann auch gezielt für den Build-Host - zum Unterschied i686/ATOM hatte ich schon in GitHub etwas geschrieben, auch wenn die bisher zu sehende Fehlermeldung noch nichts mit der Unterstützung der "movbe"-Instruktion zu tun hatte) nicht funktioniert, wäre natürlich interessant zu verfolgen. Nur braucht es dazu wenigstens mal eine Idee, was da alles gemacht wurde (und zwar als Protokoll und nicht als Nacherzählung) ... wenn hier nur die passenden Einstellungen per "make menuconfig" und das nachfolgende "make tools" nicht richtig aufgerufen wurden, wäre die Erklärung ja bereits gefunden. Solange man kein Protokoll sieht, ist diese Annahme genauso legitim, wie jede andere.

EDIT: BTW ... die URL für die genannte Datei, die man z.B. mit "wget" o.ä. benutzen könnte, wäre dann: https://github.com/PeterPawn/yf_bin/blob/master/squashfs/i686/unsquashfs4-avm-be?raw=true

 

[KarstenDE]

Also auf meinem Rapbian x86 gibt es folgende Ausgabe bei der per Browser (View Raw) geladenen Datei:
file unsquashfs4-avm-be
unsquashfs4-avm-be: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

 

[PeterPawn]

Dann sollte - wenn es tatsächlich ein x86-System ist - die Datei auch (nachdem die Flags es zulassen, die man beim manuellen Download dann natürlich selbst richtig setzen muß) ausführbar sein ... ich will einfach noch einmal darauf hinweisen, daß ein passendes Protokoll aus einer Shell-Session wesentlich aufschlußreicher wäre, als eine Beschreibung in reiner Prosa. Das sollte also mit dem "wget" (oder was auch immer man zum Download verwenden will, meinetwegen auch "curl" o.ä.) beginnen, das "chmod" zeigen, danach noch einmal das "file" (und zwar für die mit dem "wget" geladene Datei), ebenso ein "ls -l" für die Datei (um die Dateigröße vergleichen zu können und gleichzeitig die aktuellen Flags zu prüfen) und dann den Aufruf der gespeicherten Datei mit der Option "-v".

Damit kann man dann auch eine Idee entwickeln, ob das Vorgehen tatsächlich alles korrekt ist und es somit auch funktionieren müßte - dann muß man beim verwendeten System weiter suchen. Bis dahin würde ich erst mal davon ausgehen, daß es ein Fehler "bei der Anwendung" ist - wenn das Raspbian x86 "normale" ELF-Binaries für i686-Plattformen ausführen kann, gibt es keinen offensichtlichen Grund, warum es mit "-v" nicht funktionieren sollte. Ein Problem mit der "movbe"-Instruktion, die ggf. auf einigen x86-Plattformen fehlt, tritt frühestens dann auf, wenn man das mit einer Datei aufruft, die man zerlegen lassen will. Wenn hier das Kommando nicht mal gestartet wird, ist das aber definitiv ein anderes Problem.

Andererseits läßt mich das andere Problem, mit der Freetz-Toolchain selbst ein passenden "unsquashfs" zu bauen, auch ein wenig darüber nachdenken, ob ein Raspbian x86 hier die Ursache sein könnte ... aber eigentlich ist das m.W. auch nur ein Debian-System, dem halt der Desktop vom Raspberry Pi aufgepfropft wurde. Warum das jetzt ein Problem mit der (32-Bit-Version der) Freetz-Toolchain haben sollte, springt zumindest mal nicht direkt ins Auge - also arbeitet man sich halt von den wahrscheinlichsten Ursachen zu den weniger wahrscheinlichen vor.

 

[PeterPawn]

Nachdem das hier ja zuerst als Issue im Freetz-Repo startete und hier auch nicht wirklich neue Infos hinzukamen, stelle ich jetzt mal - nachdem 10 Tage vergangen sind - die Frage, ob sich der Thread erledigt hat oder ob hier noch etwas nachkommen wird.

Klappt das nun doch oder hast Du es aufgegeben, die DSL-Firmware extrahieren zu wollen? Es gibt ja auch andere Leute, die auf diesem Weg die Firmware extrahieren - und von denen hört man sonst nichts über Probleme in dieser Richtung.

Ich werde sicherlich bei Gelegenheit wieder eine x86-Version OHNE die "movbe"-Instruktion ins Repo übernehmen, weil die dann sowohl auf ATOM, als auch auf x86 ohne ebendieses "movbe" funktionieren würde - aber schon heute sollte ja jeder das notwendige Programm mit der Freetz-Toolchain und einem beherzten "make tools" auch in einer "echten" x86-Version selbst erstellen können ... halt mit etwas größerem Aufwand als einem simplen Download.

Aber es ist ja immer noch unklar, warum es hier offenbar nicht erst bei der Verwendung von "movbe" im Programm schiefging, sondern schon lange vorher, weil das OS die Datei nicht als "ausführbar" erkennen wollte.

 

[er13]

Mir fällt noch ein möglicher Grund ein, warum die heruntergeladene Datei sich nicht starten lassen könnte.

Wo genau wird die heruntergeladene Daten gespeichert, insbesondere welches Dateisystem wird genutzt? Ich könnte mir wegen "Raspbian x86" vorstellen, dass es irgendeine VFAT-Partition auf der SD-Card ist oder alternativ irgendein Remote-Verzeichnis. Unterstützt denn das Dateisystem ausführbare Dateien bzw. ist dieses entsprechend gemountet?

Auch, wenn chmod sich nicht beschwert (meiner Erinnerung nach könnte man das Dateisystem so mounten, dass das Nicht-Unterstützen bestimmter Features gar nicht explizit signalisiert wird), so könnte man spätestens nach dem Ausführen von chmod mit z.B. ls checken, ob die entsprechenden ausführbar-Flags gesetzt wurden.

Edit:
Sorry, habe übersehen, dass Peter in #2 denselben Hinweis schon mal gegeben hat, der wurde bloß vom Thread-Ersteller übersehen.

Ist das Ziel ein natives Linux-Dateisystem, sollten auch die Dateirechte gleich korrekt gesetzt werden.

 

[PeterPawn]

Wobei an dem Gedanken ja weiterhin was dran ist ... es könnte sich natürlich auch um ein Dateisystem handeln, was mit "noexec"-Option gemountet wurde - das Fehlerbild wäre wohl dasselbe.

Aber das sollte dann natürlich auch alle anderen Programme betreffen, die man dort ablegt - und es sollte ja i.d.R. schon vorher irgendwann mal aufgefallen sein, daß man gar keine eigenen Programme von dort starten kann, wenn nicht gerade Freetz oder auch der Download von "unsquashfs4-avm-be" der erste Versuch in dieser Richtung (des Ausführens zusätzlicher Programme) gewesen sein sollte.

Aber da das "Raspberry Pi Desktop"-System ja eigentlich auch als Entwicklungsumgebung dienen und sich einigermaßen ähnlich zum Raspbian auf einem echten RasPi verhalten soll (damit beim Rollout auf einen RasPi dann nicht wieder vollkommen neue Probleme auftauchen), würde mich das auch irgendwie wundern, wenn da standardmäßig ein User-Verzeichnis mit "noexec" gemountet ist - aber ich weiß es nicht (und ich mag Debian-Ableger - inkl. Ubuntu - eigentlich nicht (höchstens im Container, wo ich mit denen nichts weiter machen muß), daher macht mir dieses "Nichtwissen" auch nichts aus).