Atalante Project: ubidump - UBIFS image extract utility

  • ubidump am PC ist Shareware - was ist es mir wert ? 76

    1. 5 EUR (27) 36%
    2. O EUR weil ich brauche sowas nicht (23) 30%
    3. Ich helfe lieber mit und kriege so meinen key (13) 17%
    4. 10 EUR (7) 9%
    5. 1.000.0000 EUR dafür dann Open Source (6) 8%

    ubidump ist ein Tool für UBIFS images das diese ohne weitere Hilfsmittel listen und extrahieren kann.


    Es unterstützt das Listen und Entpacken von ubifs images die mit mkfs.ubifs erstellt wurden und ubifs volumes die mit ubinize für den Flash eingepackt wurden und auch Dreambox nfi images mit UBIFS als root Filesystem.


    ubidump am PC ist Shareware, jeder kann es für 30 Tage kostenlos testen.


    ubidump verwendet KEINEN code der mtd-utils, benötigt keine nandsim, block2mtd oder mtdram Module, und ist daher auch problemlos unter Windows lauffähig.

    ubidump wurde im Rahmen des Atalante Projekts entwickelt:


    Atalante ist eine Jägerin und ewige Jungfrau in der griechischen Mythologie - man könnte auch sagen eine emanzipierte Frau aus der Antike:


    Atalante, die immerbleibende Jungfräulichkeit geschworen hat, stellt die Bedingung, der zukünftige Gatte müsse sie im Wettlauf besiegen,
    ansonsten werde sie diesen töten. Iasos ist einverstanden – und so sind es auch viele Brautwerber, die allesamt nackt gegen die ebenso nackte
    Atalante antreten, verlieren und sterben. Erst als Melanion bzw. in einer anderen Überlieferung Hippomenes die Göttin Aphrodite um Hilfe bittet, gibt ihm diese drei goldene Äpfel die er während des Wettlaufs zu Boden fallen lassen solle. Und tatsächlich bückt sich Atalante, um die Äpfel aufzuheben, und Melanion kann den Wettlauf für sich entscheiden.


    Quelle: de.wikipedia.org/wiki/Atalante


    Atalantes Geschichte ist sehr ähnlich dem derzeitigen Zustand mit dem UBIFS extrahieren wie man in den FAQ des UBIFS Projekts nachlesen kann:


    Wie extrahiere ich Files aus einen UBI/UBIFS Image?


    Unglücklicherweise, gibt es im Moment keine User Space basierende Werkzeuge welche UBI und UBIFS Images auspacken können. UBIFS kann auch nicht loop-back gemountet werden, da es nicht mit Block devices arbeitet.

    Quelle: linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_extract


    Also außer nandsim und block2mtd als Umweg gab es nach Jahren der UBIFS Entwicklung immer noch KEIN ordentliches Tool um im Userspace ohne die ubifs kernel und Filesystemtreiber den Inhalt eines ubifs Images zu extrahieren. Eigentlich ein trauriger Zustand dem ubidump nun endgültig beendet!


    Wer noch was über UBIFS wissen will, fängt nachdem er die FAQs gelesen hat am besten hiermit an:


    linux-mtd.infradead.org/doc/ubifs.odp


    ubidump Kits und Support gibt es auf ubidump.oozoon.de
    Auf der Dreambox einfach ipk installieren und dann ubidump aufrufen in telnet.


    In der Version 0.1.8 gibt es erstmals public Kits für mipsel (Dreamboxen), ARM und einen Testkit am PC für Linux und Windows.


    Zum Testen unter Windows oder Linux am PC müsst Ihr mir eine PM oder ein e-Mail auf gutemine@oozoon.de schreiben mit dem Hardware Fingerprint eures PCs dann bekommt Ihr einen Key zum 30 Tage testen. Den Hardware Fingerprint zeigt das ubidump unter Windows beim Starten eines extract ohne key an, unter Linux in telnet mit ubidump -k oder im gubidump.py wenn Ihr auf die rote Ampel klicked weil noch kein key eingespielt wurde.


    Um Missverständnisse zu vermeiden - ubidump auf dem PC kann man auch nicht als Produkt KAUFEN, sondern wenn man nach dem Test einen dauerhaften Key haben will spendet man etwas mittels EU Standardüberweisung aus das vom ubidump bei jedem Starten angezeigte Konto - bitte dafür das Ergebnis der Umfrage als Richtwert zu nehmen, sprich ab 5 EUR wird es interessant, Ihr könnt aber auch gerne die 1 Mio überweisen damit ich die Sourcen public mache :D


    PS: nachdem es keinen Feedback zum ARM Testkit gab habe ich den entfernt, wenn Ihr den testen wollt schreibt PM oder e-Mail


    EDIT: KIT ENFERTN WEIL ABGELAUFEN, KIT REMOVED BECAUSE EXPIRED.

    Einmal Rupert und Zurück

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

  • NEWS: ubidump 0.1.13


    ubidump is a standalone tool for UBIFS images which allows listing and extracting of such images.


    ubidump supports listing and extracting of UBIFS images which were created with mkfs.ubifs, UBIFS volumes with were packed by ubinize for the flash and it supports also Dreambox images with uUBIFS as root filessystem.


    ubidump runnning on PCs is Shareware, everybody can test it for 30 days for FREE.


    ubidump uses NO code from mtd-utils, and it doesn't need any nandsim,
    block2mtd or mtdram modules, hence it runs without problems also under Windows where until now no ubifs extraction was possible.

    ubidump development was done within the Atalante Project:


    Atalante is a huntress and eternal virgin in greek mythodoloy - you could say an emanzipated woman from ancient Greece:


    Atalante, who has sworn eternal virginity requests that her future husband has to win against her in a running competition, otherweise she will kill him.
    Her father Iasos agrees - and so are many men which all run against the also naked Atalante, loose and die.


    Only when Melanion, or in other sources Hippomenes asks the goddess Aphrodite for help, he gets three golden apples from her, which he drops during the race. Atalante really stops to pick them up and Melanion can win the race.


    Source: http://en.wikipedia.org/wiki/Atalanta


    Atalantes story is very similar to the current situation of UBIFS extarcting as you can read from the FAQ of the UBIFS project.


    How do I extract files from an UBI/UBIFS image?


    Unfortunately, at the moment there are no user-space tools which can unwrap UBI and UBIFS images. UBIFS cannot be loop-back mounted as well, because it does not work with block devices.


    Source: linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_extract


    This means that besides nandsim and block2mtd Drivers as a workaround after years of UBIFS development there was still no working tool in userspace which could extract ubifs image content without ubifs kernel and the filesystemdrivers. This situation which now has come to an end!


    Who wants to know more about UBIFS, after reading the FAQs start reading this:


    linux-mtd.infradead.org/doc/ubifs.odp


    ubidump Kits and Support are available at ubidump.oozoon.de
    On a Dreambox simply install the ipk and enter in telnet ubidump.


    Version 0.1.8 has now public Kits for mipsel (Dreamboxes), ARM and a Testkit on PC for Linux and Windows.


    For testing under Windows or Linux on a PC you have to send me a PM or an e-Mail to gutemine@oozoon.de with the Hardware Fingerprint or you PC, then you will get a Key for testing 30 days. The Hardware Fingerprint is shown by ubidump
    under Windows when starting an extract without key, and under Linux in
    telnet with ubidump -k or in the gubidump.py when clicking on the red traffic light because no key was entered yet.


    Tp prevent misunderstandings - ubidump for the PC is not SOLD as a product, if you want a permanent key after testing you may donate something via EU standard bank transfer to the account shown every time when ubidump starts. Please use the result of the poll as a guideline for your donation - which means it may start with 5 EUR, but you may also donate 1 Mill if you want ubidump to become Open Source :D


    PS: as there was not any Feedback on the ARM testkit I removed it, if you want to test it send PM or e-Mail

    Einmal Rupert und Zurück

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

  • Ok werd mich mal auf der von dir genannten seite (linux-mtd.infradead.org/faq/ubifs.html#L_ubifs_extract) einlesen. Und dann ab zum FKK Strand ;)

  • Ich habe mich mit ubifs noch gar nicht beschäftigt und verstehe die Problemstellung nicht ganz. Wann komme ich bzw. in dem Fall du überhaupt in die Sitation ubifs images extrahieren zu wollen/müssen.



    Edit:
    jetzt habe ich auch mal wieder im Flodder Threat gelesen. Jetzt ist mir zumindest die Problemstellung klar :D

  • das nfidump extrahiert eigentlich das ubifs indem es temporär mit block2mtd gemountet wird und dann von dort die files kopiert. Das frißt dir dann aber bei großen ubifs images auf kleinen Boxen das Memory weg und stößt an die Grenzen der Boxen. Bei rambo II geht das noch gerade mal so aber die v2 boxen haben eine 16x mal so großen Flash und das doppelte Memory und da wird es sehr eng.


    Atalante müsste also in der Lage sein die Files korrekt aus dem ubifs image zu holen OHNE den Umweg es zu mounten und sich der standard ubifs Treiber zu bedienen.


    Und genau das ist eben nicht so einfach ....

  • ich hab' bisher drei v2 Images mit der SE V1 extrahiert. Das DMM Release mit BA, das klappte beim dritten Versuch mit 1GB Swap und dann sogar nochmal mit 512MB SWAP und laufendem Enigma2. Die ersten beiden Fehlversuche waren mit den "256MB Standard" swap. Dann noch zwei weitere experimental v2 Images nur mit nfidump (die vorletzte Version)


    Kann es sein, dass das swapfile am USB zu "langsam" ist und es deshalb nicht klappt? Ich hatte immer ein swapfile auf der schnellen internen hdd eingebunden, also auch kein neues mit BA erstellt, sondern einfach nur vor dem extrahieren das große swapfile auf der hdd manuell aktiviert. Mit Flodder habe ich das noch nicht getestet

  • Nein. mit der Geschwindigkeit darf das nichts zu tun haben (außer die Performance). Aber ich sagte bereits das ich bereits überlege mit die bei aktuellen Images sowieso vorhandenen Swappartition auf der Hardddisk im nfidump zu 'borgen', weil es eben wenig Sinn macht ein riesen Swapfile zu haben wenn man es nur temporär braucht damit das malloc glücklich ist und sich das Memory holen kann selbst wenn es dieses dann nie braucht.


    Aber auch das ist nur wieder ein Workaround

  • Eben, das gehört ein für alle mal gelöst und das geht nur wenn man das bis jetzt nicht gelöste Problem des direkt Extrahierens angeht.


    Atalante ließ sich durch nur schneller Laufen auch nicht besiegen :-)


    Und wie ich in der Einleitung schon schrieb, das Problem ist gar nicht so groß, das sind eher psychologische Barrieren als technische. Bei jffs2 ist es halt einfacher weil dort nur die Daten drinnen sind und alles andere beim Mounten erst im Memory aufgebaut werden muss. Beim UBIFS hast du mehr Overhead drinnen, den du aber wenn du nur die Daten extrahieren willst einfach ignorieren könntest und ab dann ist das Problem praktisch das selbe wie beim jffs2.


    Und im Falle von Atalante waren es auch 3 goldene Äpfel und nicht nur einer...

  • hast du eigentlich keine Frau zum spielen?


    Ist ja echt unglaublich ,wo nimmst du die ganzen Ideen und vor allem Zeit her? ;(

  • Immer langsam mit den jungen Pferde!!! .. gib gutemine einfach zeit, er hat immer super Einfälle ;)


    [edit by mod.]
    Bitte keine Beiträge extra noch einmal zitieren wenn du direkt darauf eine Antwort gibst. Danke.
    Es macht doch eh keinen Sinn, und wer will schon immer alles doppelt lesen?

  • Das ist ein Projekt, kein Plugin. Erstmals brauchen wir Goldene Äpfel = gute Ideen wie man das Problem lösen könnte. Ich habe meine schon fast aufgebraucht, weil ich es schon mehrfach versucht habe - aber ich habe darauf kein Monopol. Vielleicht fällt euch ja was ein ...

  • Wer meinst du denn könnte dir bei den Problemen helfen?
    Wer steckt so tief in der Materie und hat die Zeit und den Willen?
    Ich teste gerne wenn ich die Zeit habe und finde es gut wenn man die vorhanden Technik an das Limit bringt statt immer wieder neuen Elektroschrott zu produzieren.

  • Wie schon gesagt, das Problem ist in Teilbereichen ja gelöst. Bootloader wie uboot können ja auf ubifs filesystem zugreifen, also ist reichlich code vorhanden um das image auf file level zu handhaben. Nur daraus ein userspace Tool zu basteln ist nicht so simpel, weil das war auch einer der Versuche wo ich schon gescheitert bin. Der Aufwand liegt wahrscheinlich irgendwo im Mannwochen-Mannmonate Bereich bei jemanden der das schon so weit gecoded hat.


    Trotzdem bin ich nicht sicher ob es nicht auch einfacher geht ...


    Und das hat nichts mit Technikschrott zu tun, die Dreambox ist halt nicht dafür gedacht dort auch noch images auszupacken und auf PCs reichen die vorhandenen Mittel aus und funktionieren auch klaglos weswegen die Motivation der Leute es anders/eleganter zu lösen eben nur gering ist.

    Einmal Rupert und Zurück

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

  • Ich glaube aber trotzdem, dass es auch mit dem I/O auf USB zu tun hat, warum das extrahieren auf den kleinen Boxen mit (langamen) Swap auf USB nicht klappen will.


    Ein 0815 8GB USB-Stick mit 7,5MB/s write. 1GB swapfile darauf erstellt, swapon und mit nfidump 0.10.3 das dm800sev2 4.0.0 release versucht zu extrahieren -> error 19


    rebootet und dann das 1GB swapfile auf der HDD aktiviert und wieder das 4.0.0 release auf den Stick extrahiert, klappte auf Anhieb sogar mit laufendem Enigma2


    Habe es dann auch noch mit einem 1,5GB Swapfile auf dem Stick versucht, klappte auch nicht.

  • ich habe noch weiter getestet


    mit gestoppten Enigma2 und 1GB swapfile auf dem USB Stick hat es nun auch geklappt. Das hat aber wesentlich länger gedauert als mit dem 1GB Swap auf der HDD - gefühlsmäßig mind. dreimal so lange. Gestoppt habe ich aber nicht. Und auch nicht getestet, ob's bootet.


    Wobei der Stick mit 7,5MB/s write und 16,3 MB/s read ja relativ schnell ist, hab' auch welche hier die mit 4 MB/s und weniger writespeed daherkommen


    Ich schätze, mit einem aktiven Swapfile auf einem "noch langsameren" Stick wird das dann gar nicht mehr klappen

  • Na ja theoretisch kann es sein dass deswegen dann der kernel im ubifs dumped weil der malloc request nicht schnell genug geht. Nur das ist zu kompliziert und fehleranfällig wenn man keine harddisk oder schnellen Stick hat.


    Insofern wäre das immer noch keine wirklich tragfähige und befriedigende Lösung :-(

  • Hatte zufällig noch eine Telnetsession offen. Da hatte ich versucht mit einem 2GB swapfile und laufendem E2 das v2 Image zu extrahieren, was nicht klappte


    anbei die relevante dmesg Ausgabe


    und das spuckte dmesg aus, nachdem es mit gestoppten E2 und 1GB swap klappte

  • Ich kann die Crashes ja auch leicht reproduzieren wenn mein swapfile zu klein ist. daran liegt es nicht.


    Aber ich probier jetzt ernsthaft mal den Ansatz der NSA, sprich wenn du nicht weist was wo in einem Datenstrom steckt suche nach etwas Bekanntem. Weil im Gegensatz zu den anderen Ansätzen geht das mit einer Handvoll Codezeilen.


    Vielleicht kommt man so einfach ans Ziel indem man die ganzen Fakten und Infos übers ubifs sowie den ganzen bestehenden code dazu einfach mal ignoriert!


    Ich weis das klingt SEHR seltsam, aber es funktioniert auf diese Art und Weise nach einem halben Tag coden bereits ein Listing aller files ineinem ubifs image zu bekommen, mal sehen wie weit man das treiben kann.


    Dann könnte ich jetzt theoretisch schon ein ubidump machen :thumbup:

    Einmal Rupert und Zurück

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

  • Ich sollte meinen Mund nicht so voll nehmen, weil das war mühsamer als ich dachte :-)


    Jetzt habe ich weitere 4h daran gekämpft die fehlenden "Kleinigkeiten" userid groupid und mode des files auch noch rauszukitzeln.


    Dabei ist es ganz einfach .... wie meistens.


    Und ich stehe jetzt erst bei nicht einmal einer Seite Sourcecode :D


    Es funktioniert also mit der Brute Force Methode die infos aus dem UBIFS Image zu holen.


    Damit könnte ich am Wochenende also jetzt wahrscheinlich das versprochenen ubils binary machen.


    Damit wäre dann theoretisch der erste Apfel fast gepflückt, aber ich muss mir bis dahin auch ernsthaft überlegen ob ich da in Summe wahrscheinlich ein Mannmonat einfach so reinbuttern will, weil ich habe schon mehr als eine Woche mit den fehlgeschlagenen Versuchen verpulvert, aber wenn ich für jeden Apfel 1 Mannwoche brauche ist das eine realistische Größenordnung.


    LG
    gutemine

    Einmal Rupert und Zurück

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

  • Jungfrauen als Belohnung für Helden sind aber heutzutage aus der Mode gekommen :-)


    Ich habe den Namen nur gewählt weil sie es ihren Verehrern nicht so leicht gemacht hat und ich auch schon 3x gescheitert bin und ich daher Demut üben sollte.


    Aber so weit wie jetzt war ich noch nie, wie gesagt ein Apfel ist greifbar, der zweite Apfel ist wenn ich das auch mit den Daten der Files schaffe und der dritte wenn es direkt aus dem image funktioniert. Damit Brute Force funktioniert musst du die Umegbung so weit wie nur irgendwie möglich vereinfachen, ich extrahiere im Moment noch aus dem output image vom mkfs.ubifs ohne es mit ubinize in ein volume zu stecken - die Daten aus einem ubifs volume oder gar dem nfi image raus zu holen sind dann der dritte Apfel ...


    Aber man kann immer nur einen Apfel gleichzeitig essen :-)

    Einmal Rupert und Zurück

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

  • Nachdem der Thread erstmals nur so eine Art Blog über den Projektstatus ist hier ein kurzer Update:


    Das binary ist soweit in der Grundfunktion fertig, und wenn man es auf ein simplifiziertes ubifs Image loslässt wo nur directories und leere Files drinnen sind kann es schon alle filenamen, typen, user und groupid sowie filemode mehr oder weniger richtig auslesen.


    Wenn man es auf ein echtes ubifs Image loslässt kommt natürlich eine Menge Müll raus, weil es LEBS mit Daten als Fileinfos abarbeitet wo natürlich Blödsinn rauskommt. Es werden aber auch schon Daten wie Filenamen, etc angezeigt. Ich muss dem code halt beibringen auch mit Daten LEBS umzugehen, nämlich erstmals richtig den Unterschied zu erkennen und sie für das Listing zu ignorieren, später halt auch sie extrahieren zu können.


    Mal sehen wie weit ich am Wochenende damit komme. Was vor allem etwas pervers ist - bis jetzt habe ich noch kein einziges include oder eine lib vom ubifs code verwendet, es ist also 100% von mir selbstgeschriebener Code und es funktioniert trotzdem :-)

    Einmal Rupert und Zurück

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

  • OK, ich wäre jetzt so weit das man das Ganze testen kann.


    Reicht Euch ein mipsel binary für die Dreamboxen oder wollt Ihr auch ein Intel Linux binary haben, wobei theoretisch könnte ich sogar ein Windows Binary machen ?


    Am PC ist es halt relativ flott (listing eines images in rund 20 Sekunden), auf der Dreambox durch das Brute Force das halt CPU kostet (aber kaum Memory) halt entsprechend langsamer.


    LG
    gutemine

    Einmal Rupert und Zurück

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

  • Das Linux Intel binary habe ich gerade gemacht un zu sehen wie es performt, dann mache ich halt später auch noch ein Windows binary :-)


    ABER zum Testen kriegt ihr erstmals nur die mipsel Variante für die Dreamboxen, weil die habe ich schon fertig und dort wollen wir das Problem ja primär lösen.


    Die anderen Architekturen sind für mich eher um zu sehen ob es funktioniert und wie es performt. Und unter Windows kann man ein Linux Filesystem sowwieso nicht 100% sauber auspacken, weil Sachen wie Links, etc da nicht funktionieren. Listing geht untern Windows natürlich auch, und mehr an Funktionalität habe ich bis jetzt sowieso noch nicht fertig.


    PS: Atalante hatte viele Verehrer die sie gerne haben wollten ...

    Einmal Rupert und Zurück

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

  • OK, ich habe Euch den versprochenen Testkit für Dreamboxen auf die erste Seite gemacht.


    ubidump imagename funktioniert jetzt schon ganz brauchbar. Filemodes und userid:groupid sind zwar noch nicht 100%ig, aber das sind Sachen die man auch später fixen kann.


    Eigentlich funktioniert nur das listing (ist default auch wenn man kein -l angiebt) aber die -x option für extract ist auch dabei, allerdings macht das noch wenig außer die directories anzulegen und alle files als leere Dummies.


    Aber das wird schon noch werden. Jetzt dürfen erstmals beim Listen keine Files fehlen und auch keine falschen Files im UBI Image erkannt werden, also testet erstmals schön ob Euch der erste Apfel schmeckt.


    ubidump listet UBI Images, UBO volumes (das sind mit ubinize für den Flash eingewickelte UBI images) und auch NFI Images, sofern ein UBI Image drinnen ist. Wobei die besten Ergebnisse kriegt man für UBI Images, UBI in nfi Images die schon 2x eingewickelt wurden sind der schlimmste Fall.


    Das ist der Vorteil von Brute Force - es gibt kein Entrinnen = NSA is watching you :thumbsup:


    LG
    gutemine

    Einmal Rupert und Zurück

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

  • Hi hab mal ein gesichertes UBI Image mit -l anzeigen lassen, sieht nicht schlecht aus. Was sollen wir noch genau testen?

  • nfi images sind aber der schlimmste Fall.


    Du müsstest erstmal zählen ob die Anzahl der Files gleich ist.


    Code
    1. mkdir /tmp/root
    2. mount -o bind / /tmp/root
    3. find /tmp/root | wc -l


    Das gibt dir die Anzahl der Files im Image wenn es die Sicherung deines Flashimages ist.


    Das muss dann mit der Anzahl der Files übereinstimmen die das ubifsdump -n dir beim extrahieren anzeigt.


    In deinem log sind z.B. die rcX.d directories nicht richtig unterhalb von /etc angezeigt 8) Du müsstest dir das ubi volume mit nfdiump -i aus dem nfi holen und dan auf das root image nochmals ein ubidump machen um zu sehen ob das besser klappt, oder nur das nackte ubiimage vom sichern durch das ubidump jagen (also noch vor dem ubinize)


    Dann kannst du noch schauen ob er dir mit -x die gesamte directory struktur wieder richtig aufbaut.


    Dann wäre noch der gesamte output der directories auf fehler zu prüfen ob der Pfad immer stimmt, ob wirgendwelche falschen Pfade mit Schmierzeichen angezeigt werden.


    Ich weis das ist mühsam, aber ich kann mich nicht auch noch stundenlang damit abquälen das alles zu checken.

  • Ok .. muss nur jetzt zum einkaufen usw. aber werds mir heut abend anschauen und so machen wie du es beschrieben hast..


    bei dem
    mkdir /tmp/root
    mount -o bind / /tmp/root
    find /tmp/root | wc -l


    muss ich da nirgends das nfi angeben?

  • Nein, du sagtests doch das ist die Sicherung deines Images, also kannst du auch die Anzahl der Files im Flash zählen.


    Sonst müsstest du es mit nfidump in irgend ein Directory auspacken und dort dann mit find /directory | wc -l die Zahl der Files ermittlen.

  • hab nfidump -i Merlin-exp-dm800se-2013-07-27-14-44ubi.nfi /hdd/backup/tmp/
    gemacht aber danach löscht er automatsich das tmp verzeichnis


    mist irgendwas hats zerschossen jetzt bootet meine box nimmer

  • das sollte aber nicht sein :-)


    Wobei du recht hast das extract directory wird wieder leer gemacht, aber du findest für ein imagefile.nfi dann ein imagefile.1, imagefile.2 und imagefile.3 im directory wo das imagefile.nfi liegt. Das sid die 3 Flashpartitiponen, also ist das imagefile.3 dann das ubifs volume = die root.


    Ich habe auf jeden Fall auf die erste Seite noch eine version 0.0.3 gemacht wo auch die Größe der Files angezeigt wird, damit man sich mit dem Vergleichen leichter tut ob alles richtig erkannt wurde.

    Einmal Rupert und Zurück

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

  • Naja hab gleich mal auf das heutige Merlin Image upgedatet .. die 3 files sind da .. werd sie später an schauen .. muss jetz doch mal zum einkaufen sonst verhunger ich nocho hih

  • Bitte lies den Thread, da stehen reichlich Sachen zum Testen. Um nur das binary aufzurufen brauche ich Euch eigentlich nämlich nicht :-)


    Es geht darum ob das Listing auch STIMMT, keine Files oder Directories fehlen....

    Einmal Rupert und Zurück

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

  • Ich habe auf die erste Seite eine Version 0.0.4 vom ubidump gemacht, die auch schon richtig die daten der files erkennt und diese extrahieren kann. Allerdings wird der Overhead (LEB Header info) aus den Files erstmals nur am Anfang und Ende entfernt, womit nur Files die Kleiner als die Blocksize schon richtig sind (also typischerweise kleine config files, shellscripte,...), größere Files wie binaries und libs werden also noch corrupt sein.


    Was mich aber etwas traurig macht ist das > 20 Leute die 0.0.3 runtergeladen haben und kein Feedback gekommen ist. Ich habe jetzt bereits etwa 40h Arbeit da reingesteckt und teilweise bis nach Miternacht an dem Teil gecoded und da hätte ich mir ein bisschen mehr input und Hilfe erwartet.


    Und beschwert Euch nicht über die Performance. Erstens ist da im Code noch ziemlich viel Optimierungsbedarf und zweites extrahiert der code so wie er ist auf dem PC ein Image in < 1 min. Die Dreambox CPU ist leider nicht die schnellste :P


    LG
    gutemine

    Einmal Rupert und Zurück

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

  • Meine PERSÖNLICHE Meinung dazu:
    Viele haben Angst etwas falsch zu machen,es wird immer komplizierter mit der Dreambox zu arbeiten.
    Versteh mich nicht falsch Gutemiene,nicht jeder hat dein Wissen.



    Was mach ich faisch,befehle werden nicht erkannt?


    Usage: ubidump <parameters> imagefile


    Optional parameters


    -x [imagerdir] --extract=[imagedir]
    -l --list
    -o --overwrite
    -n --number
    -h --help
    --------------------------------------------
    root@wohnzimmer:~# -x
    -sh: -x: not found
    root@wohnzimmer:~#

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