Atalante Project: ubidump - UBIFS image extract utility

  • Nachdem du scheinbar der Einzige bist der Input liefert muss ich den natürlich besonders ernst nehmen und habe auch an der Performance gearbeitet.


    Auf der ersten Seite ist jetzt die Version 0.0.9 vom ubidump.


    Die Fehlerrate ist jetzt bereits auf < 1% und ich habe die Geschwindigkeit so hingebracht das man selbst auf der Dreambox ein UBIFS Image in rund 2min extrahieren kann.


    Wie schnell es jetzt am PC ist sage ich am besten gar nicht :D

  • Hallo,


    ich würde ja auch gern was dazu beitragen.
    Leider weiß ich nicht wofür das Auspacken eines UBI-Images sein soll


    Gruß
    morrasen

  • Gute Frage!


    Wenn du eine Sicherung hast und davon files haben willst müsstest du sie flashen um an die files zu kommen wenn du das file nicht auspacken kannst.


    Wenn du Multibooten willst müsstest du um das image auf das USB device auszupacken dieses Flashen und dann kopieren (so wie z.B. Flodder das macht) statt einfach das image selbst aufs bootdevice auszupacken.


    Wenn du was am Image ändern willst ohne im OE eines neu zu bauen musst du das image am PC oder an der Dreambox auspacken (und wieder einpacken) können

  • Ich habe jetzt die Anzahl fehlerhafter Files des ubidump nach 1 Wochen harter und wirklich zäher Arbeit auf 0
    gebracht, das einzige was noch falsch ausgepackt wird sind hardlinks, aber dafür muss ich den Support erst implementieren - und das sind nur 7
    Files.


    Ein damit ausgepacktes Image hat soeben mit Barry Allen gebootet!


    Ich denke die Hardlinks werde ich früher oder später auch noch hinbringen und dann ist der zweite Apfel gegessen, sind dann aber bereits rund 100 Stunden statt der geplanten 80.


    Ich habe euch also daraus jetzt eine 0.0.11 vom ubidump gemacht.


    Mit der könnt ihr jetzt eure verschiedensten Images
    auspacken und zum booten testen indem ihr in ein ba imagedirectory auspackt:


    Code
    1. ubidump imagefile -x /media/ba/ba/imagename
    2. echo imagename > /media/ba/ba/imagename/.bainfo


    Und dann


    Code
    1. ba.sh boot imagename now



    und berichten ob es bootet.


    Das ist dann sozusagen der Elchtest des Ganzen.


    NUR halt noch ohne zlib/lzo compression, also sich die images zum Testen vorher immer schön wie beschrieben mit dem mkfs.ubifs -x none erstellen.

    Einmal Rupert und Zurück

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

  • Auf der ersten Seite ist jetzt die version 0.12 zusammen mit 2 goldenen Äpfeln, das heißt das bei einem unkomprimierten UBIFS Image jetzt alle Files aus dem Image (auch Hardlinks) korrekt ausgepackt werden sollten.


    Allerdings steht das Projekt jetzt auch schon bei rund 90 Stunden Zeitaufwand.

  • So, also das Listing sieht richtig gut aus und auch schnell. :thumbsup: :thumbup: 124 sec. bei ca. 120MB Image von der 8000er :thumbup: . Werde später mal noch eines Auspacken versuchen. Gib es noch einen anderen weg das image zu booten außern BA?



    *** edit ***


    Wow, Image ausgepackt in 181 sec. :D


    Gruß OBrien

  • Auf die Performance habe ich gar nicht mehr geachtet, wir waren schon auf knapp über eine Minute herunter. Sobald ich den Support für die Compression einbaue wird es eh wieder langsamer und ich muss sowieso optimieren.


    Am PC geht es etwa 8-10x so schnell. In der zeit hast du nicht mal das nandsim geladen, geschweige denn was drauf kopiert und gemountet.


    Insofern wir sich letztendlich die Frage erübrigen ob man ubidump braucht, aber ich muss mir das noch überlegen. Das Teil ist in der Zwischenzeit schon fast zu gut um es zu verschenken, vor allem in der Relation zu der Arbeit die schon drinnen steckt und was noch reinwandern wird (mindestens noch eine Mannwoche nach meiner Schätzung).


    Im Printzip kannst du das ausgepackte Image als Ergebnis in jedes Tool machen, also Flodder, Dumbo, BA. Zum testen ist BA aber immer noch am einfachsten weil man einfach in ein imagedirectory auspacken kann. Letzendlich wird es dann auch das nfidump ersetzen denke ich mal, aber das ist erstmal Zukunftsmusik, noch ist Atalante ja nicht besiegt :D


    Sonst kann man sich nur ein Shellscript schreiben das mit diff/cmp/md5sum die Files zwischen ausgepackt und Original vergleicht, aber das mache ich sowieso beim Entwickeln, da ist der Test ob eure images ganz normal booten der praktischere.


    LG
    gutemine

  • So, hab mal Flodder Installiert.
    Image in das flodder verzeichnis ausgepackt, und reboot. Box startet nicht mehr. Wenn ich Später zeit habe, mache ich noch ein Bootlog. Oder muss dann doch mal BA installieren.


    Gruß OBrien

  • Mit "geht nicht" kann ich aber nichts anfangen.


    Hast du dir vorher mit mkfs.ubifs -x none ein image ohne Komprimierung gemacht wie im Thread beschrieben, das du dann mit ubidump ausgepackt hast?


    Hast du noch den Output des Auspacken mit ubidump, und ja wenn das alles Ok ist würde auch ein bootlog nicht schaden.

  • Hast du dir vorher mit mkfs.ubifs -x none ein image ohne Komprimierung gemacht wie im Thread beschrieben, das du dann mit ubidump ausgepackt hast?


    Ah, ok. Das wird wohl der fehler sein. Das war eine dflash-sicherung (dflash mit standard werten). Wenn ich das dann richtig sehe, ist das dann ja mit "favor_lzo" Komprimiert. Dann werde ich Später mal eine Sicherung ohne Komprimierung machen und Testen.


    Gruß OBrien

  • Ihr müsste den Thread schon LESEN, da steht klar und deutlich das erst der 3. Apfel Support für komprimierte Images und nfi images bieten wird.


    Und wir haben erst 2 Äpfel. Der Ersta war richtiges Listen aller Files, der zweite richtiges Auspacken aller unkomprimierten Files und den Dritten findest du eben noch nicht auf der ersten Seite.


    Der 3. Apfel ist nochmals eine Mannwoche harter Arbeit, wobei auch hier es sein kann das es erste Testkits auch schon früher gibt. Kleine Files die großer als 128Byte sind (das ist die Grenze unter der überhaupt nicht komprimiert wird) kann ich schon mit lzo und zlib Dekomprimieren, nur dürfen die Files auch nicht größer als ein Sector sein (also 512/2048/4096 Bytes) weil ich es noch nicht richtig Mergen kann.


    Das zu proggen ist Sc* kompliziert, gerade für einen schlechten Programmierer wie mich, wo ich auch nicht nach der UBIFS Definition vorgehe (da scheitert man schon beim Lesen) sondern nur Alan Turing für mich arbeiten lasse - und das ist 70 Jahre alte Vorgangsweise.


    Der Vorteil dabei ist allerdings das ich 0 fremden Code brauche, keine libubi, keine ubi Header - die nackte libc und wahrscheinlich noch das minilzo und das mini-inflate für die LZO und ZLIB Komression sind alles was nötig ist.


    Das ist wie wenn du mit Gummibändern und Klebestreifen eine Atombome baust - du bist froh wenn es dir nicht ständig um die Ohren fliegt - womit wir in diesem Thread auch noch ein paar weitere Reizworte für die Serverfarm in Utah haben 8)

  • Auf der ersten Seite habe ich Euch jetzt den aktuellen Stand der Entwicklung als 0.0.15 hochgeladen. Der Support für zlib und lzo komprimierte File ist jetzt drinnen und sollte auch schon so halbwegs funktionieren.


    ABER jetzt sind wieder eine Menge Fehler in den extrahieren images (mit -v für verify wird die Größe überprüft, um zu sehen welche Files nicht korrekt extrahiert wurden). Auch die Kompression none hat jetzt wieder Fehler, aber das war das notwendige Übel für die nötigen Anpassungen.


    In Summe sind es aber immer noch maximal ein paar Prozent von Files die kaputt sind, also ungefähr des Stand den ich bei Kompression none vor einer Woche hatte.


    Und jetzt darf ich mich vergnügen das wieder auf 0 zu bringen, hoffentlich dauert es diesmal nicht so lange wie beim ersten mal, weil rund 100 Stunden Aufwand stecken da mit heute sowieso schon drinnen.


    Nachdem ich mich entschieden habe das ubidump erstmals NICHT als neues mtd-util einzuchecken, habe ich das ipk auf ubidump umbenannt. Also vor dem Installieren der 0.0.15 mit opgk remove mtd-utils-ubidump frühere Versionen entfernen.


    LG
    gutemine

    Einmal Rupert und Zurück

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

  • Ich bin jetzt bei allen UBIFS Kompressionen (none, zlib, lzo, favor_lzo) auf 0,3% fehlerhafte Files runter.


    xz Kompression lasse ich mal weg, man muss nicht alles habe, und da sie eh keiner verwendet macht das wenig Unterschied.


    Nachdem es aber sowieso scheinbar keinen interessiert gibt es davon keinen neuen Kit zum Testen ;(

  • Klar interessierts .. dann könnte ich ja ein nfi nehmen es in die teile aufspalten und den ubi teil damit entpacken? dsa müsste ja dann auch mit nem releasten v2 gehen oder?

  • Ja es geht seit dem die Kompressionen unterstützt sind auch schon ein echtes image durch das ubidump zu jagen wenn du dir mit nfidump -i das root image aus dem nfi rausholst.


    Das man das nfi auch direkt nehmen kann baue ich aber erst ein wenn alle Fehler weg sind - weil das ist dann nur mehr fades cut & paste vom code vom nfidump.


    Aber das kannst du auch mit der 0.0.15 ausprobieren - sind nur mehr fehlerhafte Files (sollten damit noch rund 3-5% sein) Mit dem -v für verfiy kannst du das vom ubidump relativ leicht beim Auspacken überprüfen lassen - Files die nicht die richtige Größe haben werden nur als Platzhalter mit Größe 0 angelegt bis ich das gefixed habe.

  • Auf der ersten Seite habe ich Euch noch eine 0.0.17 gemacht. Dabei habe ich noch 2 Bugs gefixed - die komischen Schmierzeichen die es manchmal am Ende von Symlink Pfaden gab und noch 2 Fehler beim Auspacken der Files.


    Es sind jetzt nur mehr ca. 10 Files kaputt bei einem ganzen root Filesystem mit etwa 6400 Files, und dabei ist es egal mit welcher Kompression man arbeitet - es sind immer die gleichen Files.


    Das ist rein rechnerisch schon ziemlich gut (weil < 2 Promille Fehlerrate) aber noch nicht gut genug weil es überwiegend lebensnotwendige Libs sind.


    Es sind aber wahrscheinlich nur mehr 2 Fehler drinnen die gefixed werden müssen, die aber beide das Verhalten bei White Holes betreffen, und das hat mich schon beim ersten mal 1,5 Tage gekostet es zu fixen, nur muss ich es nochmals lösen weil der erste Fix nur bei Komrimierung none funktioniert hat, was uns bei den großen Lib Files leider nichts hilft.


    Morgen ist auch noch ein Tag (c) Margaret Mitchell

  • Mal was anderes - nachdem ständig gefragt wird ob und wann es eine PC Versione geben wird:


    Ein kleines GUI zu basteln mit dem man mit dem Filebrowser Widget das Image auswählen kann und noch ein extract directory in welches dann wenn man einen Extract Button drückt extrahiert wird indem das ubidump mit den richtigen Parametern aufgerufen wird, geht wahrscheinlich mit realtiv wenig Aufwand mit einem der vielen GTK/Qt/WinAPI Examples die man im net so findet. Oder wir machen einen Wrapper zum Fole Roller in Linux so wie für das unrar binary.


    NUR ich habe genug mit derm ubidump zu tun, kann einer oder mehrere von Euch das übernehmen ?


    LG
    gutemine


    EDIT: der 0.0.20 Kit auf der ersten Seite ist schon halbwegs brauchbar, ich habe nicht umsonst die 3 Goldenen Äpfel dazu gemacht.

    Einmal Rupert und Zurück

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

  • Damit Ihr auch was tut außer warten.


    Könn Ihr Euch mal in den Tiefen des Internets auf die Suche nach ubifs images machen die NICHT von Dreamboxen oder anderen enigma2 basierenden Receivern stammen und mit hier als zusätzliche Testcases die Links dazu posten (oder von mir aus auch die Images wenn nicht zu groß)?


    Also images für Mobiltelefone, Tablets, alles was heutzutage so mit ubifs ausgestattet ist. Es gibt sicher bei Euch auch Leute die sich in solchen Boards herumtreiben :-)


    Aber bitte keine Illegalen gecrackten Sachen, oder images die schon für SD Karten oder ähnliches umgehämmert sind. Ich brauche native UBIFS so wie es vom Hersteller zum Flashen des Devices angebote wird, auch nichts was mit nanddump oder ähnlichem aus devices extrahiert wurde.


    Ich habe die letzte Version vom ubidump (nicht die aus dem Thread hier sondern meine Linux PC Variante) jetzt über fast alles was ich so im Netz an Images für SAT Receiver gefunden haben drüberrattern lassen (also auch V+, CT/ET, ...), und die Fehlerrate ist so gering das ich langsam mehr Testcases brauche, um auch die letzten Fehler zu finden und zu eliminieren.


    Und dabei ist jede Hilfe Willkommen!


    LG
    gutemine

    Einmal Rupert und Zurück

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

  • Ich habe es runtergeladen, lässt sich auch auspacken.


    Wenn zackmuc Zeit hat Euch eine grafische Obefläche unter Windows zu stricken poste ich Euch eh ein Windows binary vom ubidump dann könnt ihr es selber probieren was alles geht ohne es auf die Dreambox zu kopieren.


    Allerdings werde ihr Euch dann wieder mit Spendenaufrufen anfreunden müssen und warten bis die weggehen. Nachdem es zum ubifs extrahieren unter Windows bis jetzt NICHTS gab kommt ihr mir da vorraussichtlich nicht ungeschoren davon.


    Dafür gibt es dann wahrscheinlich für Spender einen Key damit der Aufruf verschwindet und sofort extrahiert wird - nur zackmuc hat seinen Key schon 'verdient' 8)


    Aber ich brauche auch viel mehr Images zum testen, die ganzen Android boards müssen doch voll davon sein.


    LG
    gutemine

    Einmal Rupert und Zurück

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

  • Hab mal das grün markierte extrahiert .. unter system\framework\ liegen jar files .. die ja eigenltich zips sind .. wenn man sie umbennent lassen sie sich leider nicht extrahieren .. :(

  • Moin!


    Aber ich brauche auch viel mehr Images zum testen, die ganzen Android boards müssen doch voll davon sein.

    Hätte ich auch gedacht, aber zumeist findet man nur Anleitungen um ein Image zu ubifizieren.


    Hab mal das grün markierte extrahiert .. unter syem\framework\ liegen jar files .. die ja eigenltich zips sind .. wenn man sie umbennent lassen sie sich leider nicht extrahieren ..

    Kann da leider nicht viel helfen. Bin zur Zeit nur mit MacBook unterwegs.


    EDIT:
    Colibri
    PXA 3.xx
    UBI
    UBIFS


    OpenWRT
    xburst
    UBI
    UBIFS

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

  • Danke für die links. Solche sachen suche ich halt damit ich mir ein Testbed aufbauen kann wo dann jede version alle images fehlerlos entpacken können muss.


    Nur Dreambox images sind keine Herausfoderung mehr. Nachdem ich das nach der Brute Force methode implementiert habe statt die Logik aus den Specs weg zu proggen gilt wenn es keine fehlerhaften Files mehr liefert ist der Code fehlerlos. Der Ansatz ist zwar seltsam aber extrem flexibel, weil er mit fast allem umgehen kann, ubifs images, ubifs voumes in nf eingepacktes ubifs, etc.


    Und das AM33* hat im Filesystemd directory ein ubi.img - probier mal das :-)

  • Du hast mcih missverstanden in dem markierten image sind u.a. jarfiles enthalten .. jar files sind ja im prinzip zips ... aber die ganzen jars die ich beim extracten bekomme sind defekt und lassen sich nciht entpacken .. habs mit funktionierenden jars probiert die konnte ich ohne probleme dann unzippen .. meine da passt was beim extract des ubis ned

  • Ach so, dann entpacke mal mit ubidump -v dann wird wenigstens überprüft ob die Filesize unterschiedlich ist zu dem was im ubifs spezifiziert ist.


    Wenn ich mit der 0.21 das ubi.img auspacke dann gibt das keine file size fehler beim -v mehr.


    Und wie schon gesagt, ich habe noch ein paar weitere Extract Fehler gefixed.


    Ich liege ja nicht faul herum in der Zwischenzeit, sondern poliere meine Äpfel noch.


    Schreib mir um welches file es geht, dann kann ich es mit der aktuellen Version ausprobieren - sind das diese:


    Wenn ich da eines unzippe geht es bei mir schon ohne Fehler:


    Code
    1. unzip filterfw.jar
    2. Archive: filterfw.jar
    3. creating: META-INF/
    4. inflating: META-INF/MANIFEST.MF
    5. inflating: classes.dex


    Und das Manifest file ist dann lesbar:


    Code
    1. cat META-INF/MANI*
    2. Manifest-Version: 1.0
    3. Created-By: 1.6.0_26 (Sun Microsystems Inc.)


    Im Prinzip brauche ich ja solche inputs um zu sehen wo es noch krankt. gerade bereits komprimierte Files sind am empfindlichsten das bei Extrahieren was schief geht, weil da die Compression vom ubifs meistens eh nichts mehr rausquetscht.


    Aber jetzt versteht ihr vielleicht ein bisschen besser warum ich das Teil gerade unter Windows wo es bis jetzt NICHTS gab um so einfach das File aufzumachen nicht so einfach herschenken will, nach derzeit bereits 140h Arbeit die da drinnen stecken.


    Und Shareware ist in dem Fall durchaus ein faires Konzept denke ich mal.


    LG
    gutemine

    Einmal Rupert und Zurück

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

  • Na ja es ist auch schon spät. Ich habe sowieso gerade eine Extraschicht für die Images der Vunderboxen gemacht weil von denen ist 0 Input gekommen, aber nachdem ich sie als zusätzliches Tesbed brauche musste ich die Fehler halt selber finden und fixen - sind eh einfache Sachen gewesen, wie das sie hunderte unnötige Terminalinfos im Image haben und damit die Anzahl der maximalen Hardlinkfiles die ich im code hatte überschritten haben (wer erhöht und gut ist es - jetzt gehen statt 128 Hardlinmks halt maximal 1024) oder das ihre ach so tolle opera broser library 18MB groß ist und ich bis jetzt die maximal Filegröße auf 16MB hatte, ist halt jetzt auf 32MB geändert.


    Nur damit ihr seht womit ich mich so herumschlage beim Äpfel polieren. Wobei jetzt ist es nur mühsame Arbeit solche Sachen zu finden und zu eliminieren. Ich muss die Images ja immer als Gegencheck mit nfidump auspacken (das verwendent block2mtd und funktioniert 100%ig weil ausgiebig in allen meinen Tools verwendet).


    Das hat mich trotzdem einen halben Tag gekostet den die User dort genauso einbringen hätten können - jetzt müssen sie sich halt wahrscheinlich auch Nagscreens anschauen.


    Wenn wer guten Vorschlag hat auch da ist Input willkommen. Derzeit tendire ich dazu den Mons Olympos zu nehmen (weil die Bilder der NASA sind von Gesetz her frei) - weil für mich ist das ubidump so ziemlich der höchste Berg im Sonnensystem den ich mit meinen begrenzten Fähigkeiten erklimmen kann (und dieser Vulkan ist 3x so hoch wie der Mt. Everest - und wir auch nie ohne Sauerstoff Geräte erklommen werden können).

    Einmal Rupert und Zurück

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

  • Nur das ihr nicht glaubt ich liege auf der faulen Haut, ich bin gerade dabei das ubidump für den PC zu optimieren. Auf der Dreambox muss ich die Daten ja direkt aus dem imagefile holen, womit der Memoryverbrauch aber minimalst bleibt und eigentlich die CPU das Bottleneck ist.


    Nachdem aber die heutigen PCs reichlich Memory haben und die üblichen ubifs Images nur rund 100MB sind habe ich für die PC Version ein -c für cache Argument gemacht wo das ganze File ins Memory gelesen wird und nur mehr von dort die Daten geholt werden. Dann ist ein Image selbst unter Windows in rund 1 min extrahiert. Bei den Dreamboxen mit 512MB Memory könnte man den Parameter dann theoretisch auch mal anbieten - bin schon gespannt wie das dann performt 8)


    Unter Windows am PC: :thumbdown: (ohne caching sind es aber fast 3 min)


    Code
    1. Extracting of ..\..\Merlin-3_OE-2.0-dm8000-20130418.nfi
    2. found 7199 files and was finished in 56 seconds


    Unter Linux am PC: :thumbsup:


    Code
    1. Extracting of ../../OoZooN-Image-dm7020hd-20130803.nfi
    2. found 6333 files and was finished in 5 seconds


    Direkt auf der dm7020hd: :thumbup:


    Code
    1. Extracting of /hdd/backup/dreambox-image-dm7020hd-20130821.nfi
    2. found 7081 files and was finished in 44 seconds


    Schön langsam beginnt es mir zu gefallen :love:


    Schade das ihr nicht mit tun wollt 8o

    Einmal Rupert und Zurück

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

  • Moin!


    Ich habe mir das *.ipk jetzt mal auf eine VM mit Debian runtergeladen, um zu sehen ob es vielleicht läuft (natürlich nicht).
    Dann entpackt.
    Lässt sich das auf einer Dream installieren, obwohl der CONTROL Ordner DEBIAN heisst?