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.

sceptical schrieb:Ü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.

Ich habe gerade mal was versucht. Ich hatte bereits 4 Bilder auf der Karte (aufgenommen in 2 Sessions) - das sind die Bilder für @Offshore7 (zweiter Run)
Nun habe ich 3x folgendes gemacht:

1. Kamera an
2. Bild
3. Bild
4. Viewer Modus aktiviert / deaktiviert
5. Bild
6. Bild
7. Kamera aus

Ich habe nun folgende Bilder auf der SD-Karte

• 197
• 198 (AUS/AN)
• 199
• 200 (AUS/AN)
• 201
• 202 (VIEWER MODUS - erstmalig -> CANONMSC/-Ordner und CTG wird angelegt)
• 203
• 204 (AUS/AN - evtl. vergessen???)
• 205
• 206 (VIEWER MODUS)
• 207
• 208 (AUS/AN)
• 209
• 210 (VIEWER MODUS)
• 211
• 212 (AUS)

Und das Ergebis ist wiedermal ausgesprochen merkwürdig. Ich hatte instinktiv und nachdem was du schon berichtet hattest, erwartet im RAM-Slack nach Viewer-Modus Teile der CTG zu finden (weil zuletzt geschriebene Datei, genauso wie das Ende einer JPEG enthalten ist, wenn direkt vorher ein Bild geschossen wurde).

AAAAABEEEER dem ist nicht so. So ganz verstehe ich nicht was ich da sehe und ich muss das auch nochmal gegenchecken und weiter prüfen, aber es sieht momentan so aus:

201/202 haben, wie erwartet, irgendein Pattern im RAM-Slack.

Nach der ersten Aktivierung des Viewer-Modus sehe ich auf einmal einen Teil vom Ende der allerersten Datei (197) im RAM-Slack von 203 (aber nichts von der CTG). Das bleibt dann auch beim zweiten Bild nach Viewer-Aktivierung (204).

Als ob das noch noch reicht: Nach Kamera aus/ein sehe ich bei den nächsten beiden Bildern (205/206) immer noch dasselbe Pattern. Und das bleibt auch so bei den nächsten beiden Bildern (207/208) nachdem ich abermals den Viewer-Modus aktiviert habe.

209/210 zeigen dann irgendein anderes Pattern, das sonst nirgends in bestehenden Dateien und auch nicht im Slack vorkommt (also das schon bekannte Session-eindeutige Zufalls-Pattern).
Nach Viewer-Modus haben 211 und 212 dann aber wieder dasselbe Pattern, dass aus dem ersten Bild (197) zu stammen scheint.

Ich kann nicht 100%ig ausschließen, dass ich nach 204 vergessen habe die Kamera aus- und einzuschalten, obwohl ich eigentlich der Meinung bin ich hätte. Mal angenommen ich habe es doch vergessen, dann wäre das Pattern trotzdem nicht mehr Session-eindeutig nachdem der Viewer-Modus aktiviert wurde. Falls ich nach 204 "ordnungsgemäß" aus und eingeschaltet habe, dann hieße das, dass das Pattern überhaupt nicht unbedingt eindeutig für eine Session ist.

Wie gesagt: muss ich alles nochmal sorfältig gegenprüfen und weitere Versuche machen...

@sceptical
@Offshore7

Also nach 204 habe ich vermutlich doch vergessen die Kamera auszuschalten. Ich habe heute noch 9x je 4 Bilder gemacht, und wieder jeweils nach 2 Bildern den Viewer-Modus aktiviert. Der Pattern-Wechsel trat immer erst nach dem Viewer-Modus auf.

Weiterhin sehe ich nach dem Viewer-Modus in den nächsten Bildern (bei mir immer 2) das Ende des allerersten Bilds auf der SD-Karte (197). Und zwar wiederholt sich im RAM-Slack das Ende von 197 bis zum und inkl. FF D9 und dann weiter auch noch der RAM-Slack von 197.

Wenn ich die ersten Bilder lösche (ich habe 197, 198 und 199 gelöscht), dann taucht nach Viewer-Modus stattdessen dass Ende von dem nun ersten Bild 200 im RAM-Slack der Folgebilder auf (auch hier wieder das Ende von Bild 200 und der RAM-Slack von 200).

Bedeutet da müsste man aufpassen. 100%ig beweisen lässt sich eine Viewer-Modus-Aktivierung nur wenn das zu dem Zeitpunkt erste Bild auf der Karte noch existiert, sonst könnte man es auch für Kamera Aus/Ein halten. Was ich noch nicht getestet habe ist, ob es einen Unterschied macht, wenn man mehrere Monatsordner hat (dann ggf. auch mehrere CTGs).

Seltsames Verhalten der Kamera. Vermutlich würde man es eher verstehen wenn man wüsste wie das genau implementiert ist. Ist aber für unsere Zwecke auch nicht wirklich nötig, es im Detail zu verstehen.

cyclic schrieb:Vermutlich würde man es eher verstehen wenn man wüsste wie das genau implementiert ist.

Die NSA stellt Reverse Engineering Tools zur Verfügung. Firmware-Dumps (32 MB) sind kein Thema. Das Problem ist, wer uns 3 Jahre bezahlten Sonderurlaub spendiert. :D

Wie hast du eigentlich die Schwarzbilder produziert? Weil die haben ja quasi dieselbe Größe wie #510.

Offshore7 schrieb:Wie hast du eigentlich die Schwarzbilder produziert? Weil die haben ja quasi dieselbe Größe wie #510.

Ist mir noch gar nicht so aufgefallen, aber stimmt.

Dunkler Raum (fensterloses Bad, ohne Licht) und dann noch die Hand vors Objektiv gehalten. Nur offenbar nicht ganz so gründlich wie neulich, wo ich Bilder minimaler Größe erzeugt hatte. Bzw. liegt wohl eher daran, dass ich damals noch auf manuell gestellt hatte und eine minimale Belichtungszeit und max. geschlossene Blende eingestellt hatte.

Jedenfalls muss #510 schon wirklich verdammt dunkel sein, was die unverifizierten Angaben unterstützen würde, wonach #510 ohne Blitz aufgenommen worden sein soll.

Offshore7 schrieb:Die NSA stellt Reverse Engineering Tools zur Verfügung. Firmware-Dumps (32 MB) sind kein Thema. Das Problem ist, wer uns 3 Jahre bezahlten Sonderurlaub spendiert

Einer der Fälle wo ich annehme, dass die neuen AI-Programmierknechte sogar die korrekte Erklärung finden könnten, wenn man ihnen den reverse-ge-engineerten Code gibt - nachdem sie eine hypsche Anzahl Credits verbrannt haben versteht sich. Aber so sehr interessiert mich dieses Detail jetzt eigentlich auch nicht.