SD-Karte Filesystem Block/Cluster-Versuche

Spoiler
01
DCIM/150___05/IMG_0193.JPG: 329216 352 slack bytes in last used sector
DCIM/150___05/IMG_0194.JPG: 1345024 469 slack bytes in last used sector
aus/an
DCIM/150___05/IMG_0195.JPG: 6292992 465 slack bytes in last used sector
DCIM/150___05/IMG_0196.JPG: 7276032 6 slack bytes in last used sector

02
DCIM/150___05/IMG_0197.JPG: 329216 21 slack bytes in last used sector
DCIM/150___05/IMG_0198.JPG: 1345024 259 slack bytes in last used sector
aus/an
DCIM/150___05/IMG_0199.JPG: 5735936 78 slack bytes in last used sector
DCIM/150___05/IMG_0200.JPG: 6718976 414 slack bytes in last used sector


Es lässt sich jetzt schon mal sagen, dass der RAM-Slack eines Folgebildes Bildinhalte des vorherigen Bildes enthält, wenn der Slack größer ist, also:

RAM-Slack 194 enthält 117 Bytes des Preview-Bild-Endes (ohne RAM-Slack) von 193 inkl. FF D9.
198 enthält 238 Bytes von 197.
200 enthält 336 Bytes von 199.

Der Rest des RAM-Slacks ist dann das unbekannte Session-Pattern.

Oder hattet ihr das schon rausgefunden? :D

Offshore7 schrieb:Oder hattet ihr das schon rausgefunden?

Es ist ja nie verkehrt Sachen mehrfach gegenzuchecken... ;-)

@cyclic

Stimmt, ohne Praxis war mir nicht klar, dass die Bildreste (evtl. Bufferreste) genau die Differenz zwischen den RAM-Slack-Größen zweier Bilder ausmachen, dieser Teil also berechenbar ist. Wie sich das bei 3 Folgebildern verhält / berechnet konnte ich nicht testen.

Offshore7 schrieb:Es lässt sich jetzt schon mal sagen, dass der RAM-Slack eines Folgebildes Bildinhalte des vorherigen Bildes enthält, wenn der Slack größer ist, also:

Bezogen auf den Tumbnail-Slack? Dann ist das ja eigentlich ähnlich wie beim RAM-Slack am Ende. Nur an den kämen wir ran, wann man die originalen Bilder hätte.

sceptical schrieb:Bezogen auf den Tumbnail-Slack?

Nein, bezogen auf den RAM-Slack am Ende. Mir war nicht klar, dass man den Bild-Anteil des RAM-Slacks genau berechnen kann.

Offshore7 schrieb:Nein, bezogen auf den RAM-Slack am Ende.

Na klar kann man den berechnen, wenn man die Dateigröße mod 512 nimmt. Ich verstehe nicht ganz, worauf du hinaus willst? Das hatte ich ja bereits im Sektor bezogen auf das Bild dargestellt. Oder meinst du, dass du einfach nochmal gegengeprüft hast?

@sceptical

Wenn Bild 1 100 Bytes im RAM-Slack hat und Folgebild 2 400 Bytes, dann stammen die ersten 300 Bytes im RAM-Slack von Bild 2 aus dem Preview-Bild-Ende von Bild 1.

Das meine ich. Zumindest MIR war das nicht klar.

Offshore7 schrieb:Wenn Bild 1 100 Bytes im RAM-Slack hat und Folgebild 2 400 Bytes, dann stammen die ersten 300 Bytes im RAM-Slack von Bild 2 aus dem Preview-Bild-Ende von Bild 1.

Das kann nicht sein. Wenn Bild 1 nur 100 Bytes im letzten Sektor hat, wie werden daraus plötzlich 300 Bytes?

@sceptical

Im RAM-Slack des letzten Sektors. Die 300 Bytes kommen aus dem Preview-Bild des vorherigen Bildes, also bis FF D9.

@sceptical
Ich habe übrigens @Offshore7 die Daten bereitgestellt die er sich gewünscht hat. Ich hätte sie hier in den Blog hochgeladen, aber Allmy verhindert das. Daher habe ich sie per PN verschickt. Solltest du die auch haben wollen, kann ich sie dir auch schicken.

Bisher bestätigt @Offshore7 aber nur was wir auch schon gesehen haben (jedenfalls nach meinem Verständnis).

Die Berechenbarkeit / Deterministik ist ein wesentlicher Punkt: Es gibt Fälle in denen sich Dinge nicht feststellen lassen (u.a. kein oder nur minimalster RAM-Slack) aber man weiß dann, dass genau dieser Fall vorliegt.

Offshore7 schrieb:Im RAM-Slack des letzten Sektors. Die 300 Bytes kommen aus dem Preview-Bild des vorherigen Bildes.

Zeig mal einen Screen-Shot

Also nochmal, es geht um den letzten Sektor, in dem die vollständige Datei endet.

Offshore7 schrieb:Wenn Bild 1 100 Bytes im RAM-Slack

Dann stehen im letzten Sektor 100 Byte dieses Bildes und darunter das Pattern (das Pattern mit 0x55AA ist übrigens tatsächlich der Boot-Sektor, wenn nur ein paar Bytes übrig bleiben, dann tauchen da noch mehr Daten am Anfang auf). Wenn jetzt das zweite Bild 400 Bytes im letzten Sektor übrig lässt, dann werden die 100 Byte des ersten Bildes vollständig überschrieben. So macht es meine Kamera. Bei deiner Schilderung müsste man schon davon ausgehen, dass die Bildreihenfolge falsch ist.

cyclic schrieb:Ich habe übrigens @Offshore7 die Daten bereitgestellt die er sich gewünscht hat. Ich hätte sie hier in den Blog hochgeladen, aber Allmy verhindert das.

Na klar, dass mus ich mir anschauen, allerdings hat er nach einem komprimierten Image gefragt, du müsstes kurz dazuschreiben, wie ich es dekomprimieren kann.

sceptical schrieb:Na klar, dass mus ich mir anschauen,

Brauchst du nicht mehr, hatte die Angaben auf den Dateianteil und nicht den Slackanteil bezogen. Stimmt also. Danke für die Gegenprüfung,

Das ungewöhnliche ist, dass dies unabhängig von den Relationen der Gesamtgrößen passiert.

Eventuell kannst du dich näher mit dem Tumbnail-Slack beschäftigen. Da gibt es wesentlich mehr Daten und die Chance, dass man irgendwann einmal an die originalen Bilddatein kommt, ist mE größer.

sceptical schrieb:Stimmt also.

Übrigens: Nicht ganz, mir ist aufgefallen, dass diese Berechenbarkeit unterbricht, sobald dazwischen eine Katalogdatei abgelegt wird. Das habe ich mir aber nocht nicht genauer angeschaut.

cyclic schrieb:Es ist ja nie verkehrt Sachen mehrfach gegenzuchecken... ;-)

Völlig richtig, je mehr Leute das gleiche Ergebnis erhalten, umso mehr Gewicht hat es.