Atalante Project: ubidump - UBIFS image extract utility

  • Das hat aber wenig mit Wissen zu tun ein Binary aufzurufen und den Output zu vergleichen. Und wenn sie gar nichts beitragen wollen dann brauchen sie es auch nicht runterladen :P


    Das testen ist in diesem Fall ist zwar eine Heidenarbeit aber irgendwer muss sie auch tun. Und bei bereits 40h Coding kann und will ich nicht auch noch Stunden mit dem Testen verbringen.


    Wenn eine Handvoll Leute sich nur 1h damit befassen würden, dann würde das wahrscheinlich ausreichen. Und das ubidump soll das Leben EINFACHER machen nur muss man halt was dafür tun. Das ist schon wie mit der Politikverdrossenheit - alle Jammern und dann gehen sie nicht mal am Sonntag zur Wahl.

    Einmal Rupert und Zurück

    Dieser Beitrag wurde bereits 2 Mal editiert, zuletzt von gutemine ()

  • Noch ein kleiner Nachtrag zur Frage nach einem Windows binary. Ich habe das jetzt wie versprochen ausprobiert. Sachen wie chown oder symlinks und device files gehen allerdings nicht 1:1 abzubilden womit das Ergebnis beim Extrahieren unter Windows nie 100%ig sein wird. Vor allem habe ich es als native Windows binary compiliert, also ohne cygwin & Co.


    Listing geht aber natürlich unter Windows genauso gut wie auf den anderen Plattformen.


    Außerdem ist die Performance unter Windows irgendwo auf halbem Weg zwischen dem mipsel binary für die Dreambox und dem Linux Intel binary, das kann aber auch am GCC Compiler liegen den ich der Einfachheit verwendet habe.


    Wenn das Atalante Projekt abgeschlossen ist wird es also auch eine Windows Version des ubidump geben, solange wir noch beim Testen und Entwickeln sind macht das aber noch wenig Sinn.


    Was allerdings super ist das es selbst unter Windows kein nennenswertes Memory benötigt (<1MB). Sobald ich die Files aus dem UBIFS ins Memory einlesen und Dekomprimieren muss, wird das zwar anders sein, aber selbst dann sollte es in der Größenordnung der zu komprimierenden Files bleiben womit es für unsere Zwecke ideal geeignet ist. Und letztendlich muss ich erst schauen ob die ganzen lzo und zlib Libraries für das Dekomprimieren unter Windows auch verfügbar sind, darauf Rücksicht zu nehmen würde mich also im Moment nur bremsen.


    Der hohe CPU Verbrauch liegt daran das ich im Moment noch sequentiell im File Suche, aber das ist leicht zu Optimieren. Zuerst muss aber die volle Funktionalität implementiert sein und die Erkennung 100%ig funktionieren, vorher macht es wenig Sinn da dran zu optimieren.


    LG


    gutemine

  • The problem is that I do not know how to use this ipk files.
    I do not know where after installing the ipk files what I can to do by it .
    please give The main points of thread in English.

  • type ubidump in telnet and do what it tells you :-)


    ubidump -l ubimagefile will list the content of the imagefile
    ubidump -x directory ubiimagefile will extract the ubiimage


    Listing works already quite nicely, extraction is still in very early stage of development.


    And the Wikipedia entry on Atalante is readable in lots of languages ... and the ubifs documents too which explain that currently there is no userspace ubifs extract utility :D

  • It means that first I should Flashing jffs2 image on box and installing mtd-utils-ubidump on it. Then I should copy the ubi image to harddisk, and then execute the following telnet commands to installing ubi image on the flash of box.
    Is the ubi image overwrited On the jffs2 image ?
    Due to their low memory, Do these files actually be used for DreamBox 500hd and 800se?
    Is this files can be used on multi-booted images?

  • You don't need to flash anything (new)


    The ubidump binary simply lists (and partly already extracts) any image file with ubifs content - which could be an ubi image (optimal results) and ubi volume (worser results) or an nfi image (worst results). And is is NOT a flashtool like nfiwrite - it is more a kind of 'nfidump on diet' as it doesn't use any block2mtd or nandsim to extract UBI images and hence it runs also on Linux or Windows PCs.


    But for the moment as we are still in early stages of development and hence for testing only the mipsel binary is available.


    It will work on any box when it is finished and also on PCs and will maybe replace nfidump for extracting images for multibooting, Dumbo, Flodder,... what so ever.


    And the reason is simply to get a virgin - as there is currently NO userspace UBIFS Image extraction tool available when I read the UBIFS FAQ correctly :P


    PS: I like to solve virgin problems, but this one was hard, very hard - but if you ask Aprodite instead of Athene for help everything goes ...

    Einmal Rupert und Zurück

    Dieser Beitrag wurde bereits 3 Mal editiert, zuletzt von gutemine ()

  • OK, ich habe jetzt noch einen halben Tag reingebuttert um in der Version 0.0.5 auch symlinks sauber zu unterstützen - beim listen werden sie jetzt mit quelle -> ziel angezeigt und beim extrahieren auch schon richtig angelegt.


    Aber schön langsam muss ich mir etwas anderes überlegen wenn ihr weiterhin so brav mithelft X(

  • Also momentan entpackt er mir das nfi nach tmp .. dateien schauen komplett aus .. aber inhalt ist natürlicch falsch. Diesmal gab es keine 1 2 3 Datei


    anbei die infos von meinem versuch.

  • die *.1-3 Files macht nur das nfidump. Das ubidump arbeitet anders und listet bzw. extrahiert wenn dann nur die UBI root also das *.3 file. Und der Inhalt von kleinen Files wie shellscripten oder config Dateien die auf Grund Ihrer Größe nicht komprimiert werden und auf einen einzigen Block passen (512/2048/4096 Bytes) je nach Flashchip der Box sollten schon OK sein.


    Noch eine Frage: soll ich auch einen -f filename Qualifier dazu machen mit dem man ein einzelnes File listen bzw. extrahieren kann ?


    Das Handling der großen und komprimierten Datenfiles ist nicht so einfach, das ist erst der Zweite Apfel zusammen mit der Erkennung wie es komprimiert wurde und es richtig zu dekomprimieren. Das ist aber nochmals ca. 1 Mannwoche Arbeit.


    Jetzt darf erstmals der erste Apfel, also die korrekte Erkennung aller Filedaten nicht wurmstichig sein.

  • Kommt immer darauf an wie groß sie sind. Ich baue mir im Moment die ubi Images nur mit compression None, da geht natürlich mehr als bei einem echten ubi Image. Und wie gesagt im Moment ist das einzige was hoffentlich halbwegs sauber extrahier wird die Directory Struktur und symlinks. Bitte also weniger mit dem extract testen weil das ist einfach noch in Entwicklung, sondern kontrollieren ob die Listings alle Files in Richtige directories machen, und die File Protection stimmt. Beim owner war ich eh schon faul weil auf der Dreambox fast alles root gehört.


    Das war nämlich eine Heiden Arbeit einen Algo zu stricken der in der Lage ist die Directory Struktur nur aus den Filenamen (ohne Pfad!) und der inode Number rekonstruieren zu können - das allein hat mich schon mehr als einen Tag Arbeit gekostet bis es funktioniert hat.


    Ich habe mir halt einen Plan zurecht gelegt wie ich das Problem lösen will und bis jetzt hat es ganz brauchbar funktioniert und ich konnte alle wesentlichen Zwischenziele erreichen. Vor allem sind es nur ganz wenige Tricks auf die man kommen muss um das Problem zu lösen, aber die zu finden um umzusetzen ist trotzdem ganz schön mühsam. In der Zwischnezeit weis ich zwar warum die meisten bisheringen Ansätze gescheitert sind (auch meine 3 Anläufe die ich schon gemacht habe) aber diese Erkenntnis musste ich auch erst mühsam erringen.


    In einem Satz - ich hätte nicht Athene sondern gleich Aprodite um Hilfe bitten müssen, und die Liebe findet immer einen Weg auch wenn dieser oft verschlungen ist.

  • Im konkreten Fall hätte ich nicht auf die guten Ratschläge der Intellektuellen hören sollen (=Athene) sondern auf mein Herz (=Aphrodite).


    Und das Problem ist das für die etwa 120h die meine Aufwandschätzung ist eigentlich ein 400 EUR Minijob nicht ausreichen würde. Ein üblicher Programmierersatz wäre z.B. 50 EUR/h - Rechne es dir aus was da rauskommt.


    Ich habe eh schon mit dem Gedanken gespielt das den Leuten mal bewusst zu machen. Das ubidump wäre dafür sogar recht gut geeignet weil es auch in der Nicht-Dreambox Welt dringend nötig wäre. Du kannst damit nämlich die Images deines Android Handies oder deines Routers sofern sie UBIFS verwenden genauso dumpen. Insofern ist der Usecase deutlich größer als für mich üblich.


    Na ja mal sehen ...

  • Danke fürs Testen. Das Einzige was noch nicht so toll funktioniert sind die User und Group aber das ist im Moment mal nicht so wichtig, weil bei einem Dreambox image sowieso praktisch alles unter root läuft.


    Im Moment quäle ich mich noch mit dem Daten extrahieren. Größere Textfiles.gehen schon ganz brauchbar, aber bei Binaries habe ich noch eine Menge Spass ...

  • Na ja im moment habe ich auch bewusst nichts an der Performance gemacht (volles root image dauert etwa 15min auf meiner 7020hd, während es am PC nur 80 Sekunden sind) aber man kann dann schön mitlesen, insofern ist das fürs vergleichen besser. Nur mache ich halt auch nur mehr Stichproben, also einfach ein 2. Terminalfenster wo man einen Pfad mit cut & paste rüber holt und damit ein ls- al macht und vergleicht.


    und da finden halt mehr Augen auch mehr


    PS: Ich habe schon eine Version die fast 4x so flott ist, was schon fast in der Größenordnung vom nfidump ist and sobald die Daten dekomprimiert werden müssen wird das wieder langsamer werden, aber keine Angst das wird schon werde. Aber deswegen zeigt die 0.0.6 am Schluss auch die Laufzeit an.

    Einmal Rupert und Zurück

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von gutemine ()

  • Auf der ersten Seite ist jetzt die Version 0.0.7 vom ubidump. Was hat sich getan gegenüber der letzten version:


    Die device files auf /dev sollte jetzt richtig gelistet und extrahiert werden, die Formatierung des Listings wurde verschönert und es sollten wenn man ein ubifs image mit compression none macht jetzt auch schon binaries und libs richtig extrahiert werden (mit md5sum Original und Kopie Stichprobenartig vergleichen)


    Außerdem gibt es jetzt ein -w oder --windows als option mit dem man device files als xxx.dev und links als yyy.lnk extrahieren kann damit diese files auch in einem Windows Filesystem funktionieren - sind dann halt reine Textfiles wo die nöltigen Infos drinnen stehen, damit ein entsprechend gepatchtes mkfs.ubifs unter Windows es wieder einpacken könnte.


    Bitte im Moment nur ubi images zum testen benutzen, nfi und ubi volumes muss ich erst wieder einbauen, aber zuerst muss das Extrahieren mit compression none 100%ig funktionieren, erst dann kommen die anderen compressions und die anderen Fileformate dran (=3. Apfel). Der zweite Apfeln, also das Extrahieren der Files ist dann aber auch schon zur Hälfte gegessen, wir stehen jetzt aber auch bereits bei etwa 65 Stunden Arbeit.


    LG
    gutemine

  • Auf er ersten Seite ist jetzt eine 0.0.8. Ich habe an der Performance gearbeitet - das ganze ist jetzt etwa doppelt so schnell - also listing eines ganzen Images in rund 1 mind und extrahieren in rund 7-8min auf meiner 7020hd. Die Erkennung von ubi images vs. ubivolumes vs NFI image wurde gefixed, es wird jetzt bei allen wieder sauber die sector size und die eraseblocksize ausgelesen. Damit sind ubi images und ubi volumes von der Qualität praktisch ident, nur NFI images sind etwas schlechter, aber das hat im Moment nicht Priorität.


    Also brav weitertesten, weil im Idealfall würde ich es gerne heute noch schaffen das die extraktion der datenfiles von ubi mit compression none zu 100% klappt, aber wie immer bei sowas sind die letzten Fehler am schwersten zu finden :(


    Nur stehen wir jetzt auch schon bei >70h Aufwand, aber der zweite Apfel ist greifbar.


    LG
    gutemine

  • Danke, habe dir dort Tipp gegeben wie du richtiges backup script machen kannst. Wobei in der 0.8 sollten eh auch wieder images die mit nfidump -i aus dem nfi image extrahier wurden funktionieren, nur die 0.7 konnte das nicht sauber. Trotzdem ist ein backup der eigenen root natürlich besser, weil man das leichter vergleichen kann.

  • habs ja mit der 08 gemacht aber es kommt


    Code
    1. + mkdir /tmp/root+ mount -o bind / /tmp/root+ touch /media/hdd/backup/root.ubi+ chmod 777 /media/hdd/backup/root.ubi+ cd /usr/lib/enigma2/python/Plugins/Extensions/dFlash/bin+ ./mkfs.ubifs -m 512 -e 16384 -c 3735 -F -x none -r /tmp/root -o /media/hdd/backup/root.ubiError: max_leb_cnt too low (14821 needed)+ umount /tmp/root+ exit 0
  • Jetzt schauts besser aus mach grad nen list in ein log file dass ich dann poste .. nur das schaut komisch aus

    Code
    1. l-rwxrwxrwx 0:0 40 /sbin/arp -> ../bin/busyboxÿÿÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎÎ
  • das sind eben noch Fehler in der Erkennung. Im Moment sind immer noch ein paar Prozent der Files falsch, und ich muss erst rausfinden warum und wie man das fixed. Das ist mühsam, ich weis, aber es geht eben nur mit entsprechenden Inputs von Euch.


    Überwiegend sind es aber Datenfiles wo die Fehler sind, und die 0.0.8 macht nur mehr etwa 5% Fehler - was eigentlich schon ziemlich gut ist - ABER es muss auf 0% runter bevor es weiter gehen kann.


    Ein Listing eines images dauert jetzt nur mehr rund 1-2 min womit wir das Listen als erstes fixen sollen, das dort keine Fehlerhaften namen mehr drinnen sind, dann kommt der Inhalt dran.

  • Ja danke, ich stricke für die owner:group Fehler mal einen Workaround, weil das ist leicht/später zu fixen, das Extrahieren der Daten ist wichtiger.


    Chech bitte mal wenn du -x macht ob in /dev alle device files richtig als block oder character device erkannt werden und auch die file ids stimmen - mit ls -al original /dsev und das extrahierte /dev vergleichen und auch auf die subdirectories vergleichen. Weil das /dev MUSS stimmen, sonst wird ein so extrahiertes image nicht booten.

  • kannst du mir die mal im listing markieren und ein entsprechenden ls -al dazu machen vom echten /dev ?


    Der unterschied kann sein das /dev im image vom udev kommt, und nicht das echte flash /dev ist. Du müsstest so wie im backup script einen bind mount von 7 auf /tmp/root machen und dann mit /tmp/root/dev vergleichen.

  • Das sind mal die die logs :


    devextract is das dev aus dem extract
    devflodder ist das dev vom laufenden flodder
    mountdev is das dev von dem nach /tmp/root gemounteten

  • danke, die major und minor values stimmen und die devices und typen auch. Das Einzige was nicht 100%ig stimmt ist die Protection, aber das ist nicht wirklich das Problem. Also gehe ich erstmals weiter mit dem Datenextrakt kämpfen ... Warum manche files zu groß werden habe ich schon gefunden aber noch nicht warum manche zu klein werden :-(

  • Na ja nachdem wir hier sehr exklusiv unterwegs sind freue ich mich über jeden der hilft. Dafür kriegst du dann eine Gratislizenz fürs ubidump, weil die Anderen kommen mir da nicht ungeschoren davon :thumbsup:


    Ich bin jetzt bei etwa 6400 Files in meinem Testimage von 250 Fehler auf 80 runter, was nur mehr etwa 1,2% sind. Nur die jetzt auch noch zu finden ist hart, sehr hart. Weil etwa die Hälfte davon sind pngs von de skins, oder pyo files und das sind bereits komprimierte files, wo das Brute Force sich naturgemäß am schwersten tut. Der Rest sind binaries und libs. Vor allem müssen es wenigstens noch 2-3 Bugs sein weil manchmal sind die Files zu groß und manchmal zu klein. Ich habe aber auch nur 3 bugs gefixed um von den 250 auf die 80 zu kommen, so viel kann also nicht mehr fehlen, nur ist es immer schwerer zu finden :wacko:


    Aber da muss ich jetzt durch und auf 0 Fehler kommen sonst kommen wir nicht weiter!

  • Na ja, super wäre wenn es schon gelöst wäre. So ist es im Moment wie wenn mir der letzte Bissen des 2. Apfels im Hals stecken bleibt. Aber da hilft jetzt nur kauen, kauen und nochmals kauen.


    Aber ich bin auch schon am Überlegen was ich machen soll wenn es fertig ist.


    Nachdem wahrscheinlich 5-6 Mannwochen reinlaufen werden wenn ich auch noch selbst so viel testen muss kann ich mir nur schwer vorstellen die Sourcen rauszurücken.


    Insofern bleibt mir wohl erstmal nur übrig Fakten zu schaffen, sprich ein voll funktionsfähiges ubidump zu machen. DANN könnte ich beruhigt abwarten bis das nfidump abläuft und schauen was passiert :evil:


    Wirklich wieder viel zum Testen gibt es erst wenn es 100%ig funktioniert - weil das gehört verifiziert und bestätigt und dazu muss man die so extrahierten Images eigentlich booten. Und dann das selbe Spiel nochmals wenn die Compression funktioniert.


    Aber vielleicht mache ich mal eine Umfrage wie die Leute ihr ubidump gerne hätten - geschüttelt, nicht gerührt ?

  • Na ja nachdem es im Moment noch keine Preis hat hast du nicht viel gespart :-)


    Mal sehen ob ich es hinbringe, es macht keinen Sinn das Modell wie ubidump mal zu bekommen ist jetzt zu diskutieren solange es noch nicht fertig ist. ich habs auf jeden Fall so gestrickt das Linux und Windows am PC auch funktionieren, ich entwickle und teste es ja am PC weil es dort viel flotter ist. Anfangs war der PC etwa 10x so schnell wie die dreambox, nachdem ich den Code optimiert habe ist der PC 'nur mehr' rund 4x so schnell. Aber das heisst Image listen in < 20 Sekunden und Image auspacken in rund 1 min)