Analyse SD-Karte MBR/FAT32

[DodgerTheRunner]

Hi Leute,

ich habe hier den Dump einer 64GB SD-Karte, den ich gerne low-level analysieren möchte.
Den MBR habe ich schon geprüft, der Dump enthält eine Partition, FAT32 (Typ 0x0B).
Erste verwunderung: der Typ wäre ja für CHS und somit könnte die Partition doch gar nicht die vollen 64GB belegen?
Hier die Partitionstabelle:

0000:01B0 |                                              80 FE |               .þ
0000:01C0 | FF FF 0B FE  FF FF 00 80  00 00 00 D0  6E 07 00 00 | ÿÿ.þÿÿ.....Ðn...
0000:01D0 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
0000:01E0 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
0000:01F0 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 55 AA | ..............U

Weiterhin sehe ich, dass die Partition bei 0x8000 starten soll.
Wenn ich mir aber nun den Inhalt des Dumps bei 0x8000 anschaue, dann ist dort nichts zu finden:

0000:8000 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
0000:8010 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
0000:8020 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
0000:8030 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
0000:8040 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
0000:8050 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
0000:8060 | 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................

Der erste Hinweis auf eine Partition ist hier:

0100:0000 | 00 F7 B7 89  FF 94 35 93  89 2E 34 00  02 40 20 00 | .÷·.ÿ.5...4..@ .
0100:0010 | 02 00 00 00  00 F8 00 00  20 00 FF 00  00 80 00 00 | .....ø.. .ÿ.....
0100:0020 | 00 D0 6E 07  73 3B 00 00  00 00 00 00  02 00 00 00 | .Ðn.s;..........
0100:0030 | 01 00 06 00  00 00 00 00  00 00 00 00  00 00 00 00 | ................
0100:0040 | 80 00 29 19  18 A1 38 43  48 41 49 52  20 37 20 20 | ..)..¡8CHAIR 7  
0100:0050 | 20 20 46 41  54 33 32 20  20 20 FA 31  C0 8E D0 BC |   FAT32   ú1À.м
0100:0060 | 00 7C FB 8E  D8 E8 00 00  5E 83 C6 19  BB 07 00 FC | .|û.Øè..^.Æ.»..ü
0100:0070 | AC 84 C0 74  06 B4 0E CD  10 EB F5 30  E4 CD 16 CD | ¬.Àt.´.Í.ëõ0äÍ.Í
0100:0080 | 19 0D 0A 4E  6F 6E 2D 73  79 73 74 65  6D 20 64 69 | ...Non-system di
0100:0090 | 73 6B 0D 0A  50 72 65 73  73 20 61 6E  79 20 6B 65 | sk..Press any ke
0100:00A0 | 79 20 74 6F  20 72 65 62  6F 6F 74 0D  0A 00 00 00 | y to reboot.....

Wo ist mein Denkfehler bzgl. des Beginns der FAT32 Partition?

Gruß
Dodger

 

[elgorro]

Tatsächlich gibt es FAT32 und FAT32X.

Da es aus den Zeiten stammt, wo noch Disketten bzw Festplatten die Heimcomputer eroberten. CHS verschenkt minimal mehr Platz, so dass es heutzutage keine Rolle mehr spielt. FAT32 ist beschränkt auf maximal 4GB pro Datei und 8TB für eine Partition!

 

[up.whatever]

Wenn ich mir aber nun den Inhalt des Dumps bei 0x8000 anschaue, dann ist dort nichts zu finden

Vielleicht ist da ein bisschen Platz für legacy bootloader etc reserviert?

 

[elgorro]

Ja und nein, dass erste Byte gibt nur an ob bootfähig oder nicht (80hex=10000000binär=bootfähig, 00hex=nicht bootfähig). Ich glaube die anderen Bits wurden für zukünftige Updates reserviert, kann aber sein das ein paar auch eine Rolle spielten in Rechenzentren bspw.

 

[DodgerTheRunner]

https://knowitlikepro.com/understanding-master-boot-record-mbr/

danach aufgeschlüsselt steht in meinem MBR:
0x80: Boot indicator: bootable
0xFE: Starting head
0xFF: Starting Sector
0xFF: Starting Cylinder
0x0B: System ID: FAT32
0xFE: Ending head
0xFF: EndingSector
0xFF: EndingCylinder
0x00 0x80 0x00 0x00: start adress LBA (Little endian -> 00 00 80 00 -> Startsektor 32768)
0x00 0xD0 0x6E 0x07: Length LBA (little endian -> 07 6E 00 D0 -> 124649680 Sektoren, bei 512 Byte pro Sektor -> 64GB)

Mein Problem ist die Start-Adresse 32768. Da befindet sich im Dump nämlich keine Partition....

 

[elgorro]

Was ist deine konkrete Sektorgröße, Cylindergröße und Partitionsgröße?

 

[DodgerTheRunner]

Sektor Größe ist 512 Byte.
Cyilinder Größe gibt es ja nicht, da SD Karte.
Daher auch die Berechnung nach LBA.
Und dort ist die Partitionsgröße mit 64GB angegeben, was zur Größe der Karte passt.

 

[elgorro]

LBA = (C × HPC + H) × SPT + (S − 1)
C = LBA ÷ (HPC × SPT)
H = (LBA ÷ SPT) mod HPC
S = (LBA mod SPT) + 1

Okay - hatte es eilig, was ist deine LBA dann natürlich?

 

[DodgerTheRunner]

0x00 0x80 0x00 0x00: start adress LBA (Little endian -> 00 00 80 00 -> Startsektor 32768)
0x00 0xD0 0x6E 0x07: Length LBA (little endian -> 07 6E 00 D0 -> 124649680 Sektoren, bei 512 Byte pro Sektor -> 64GB)

Ich dachte, das hier wären die LBA Infos....

 

[rg88]

ich habe hier den Dump einer 64GB SD-Karte, den ich gerne low-level analysieren möchte.

Darf ich den Hintergrund der Sache erfahren?

 

[DodgerTheRunner]

Erstmal geht es darum, low-level zu verstehen, wie das alles funktioniert.
In zweiter Linie geht es darum, einen Dump zu analysieren ohne ihn mounten zu müssen.
Und in letzter Instanz geht es darum herauszufinden, warum sich zwei eigentlich identische Karten unterschiedlich verhalten.

 

[rg88]

In wiefern unterschiedlich verhalten?
Weil bevor man hier noch ewig rumrätselt, warum dieses und jenes so oder so ist: Es gibt in dieser Größe Massenhaft gefälschte Karten. Dann könntest du noch Monate lang analysieren und wirst nie auf einen logischen Schluss kommen

 

[DodgerTheRunner]

Die SD Karte gehört zu einem ziemlich teuren Gerät.
Für eine bessere Verfügbarkeit sollte eine Kopie angefertigt werden.
Die Kopie wurde auf eine Karte gleicher Größe gemacht, funktioniert aber nicht.
Also wollte ich mal nach versteckten Partitionen ausschau halten und dabei mein Wissen zum Thema MBR und Partitionstabellen erweitern.
Das Dekodieren von Hand klappt auch soweit, bis auf die Diskrepanz beim Startsektor zwischen der Angabe in der PT und dem tatsächlichen Start im Dump...

 

[rg88]

ah, okay! ja, das ist aber häufig so, dass solche Karten keiner Norm entsprechen und diese anders arbeiten. Genau um eben Raubkopien zu vermeiden.
Manchmal nur durch verschobene Bereiche, in anderen Fällen ist der Controller darauf anders geflasht, dass er keine brauchbaren und validen Daten ausgibt.

Warum erwähnst du sowas nicht zu Beginn?

 

[DodgerTheRunner]

Weil es für mich erstmal keine Rolle gespielt hat :-)
Mir ging es nur darum zu klären, ob meine Entschlüsselung der PT Hex-Werte korrekt ist und demnach die Partition nicht dort liegt, wo sie definiert wurde.
Oder ob ich bei der Analyse einen Fehler gemacht habe.

Die Kopie per DD sieht genauso aus, dem Kopierschutz bon ich somit noch nicht auf die Schliche gekommen.
Ich hab auch leider nur den Dump und keinen Zugriff auf die Karte. Die liegt bei einem Bekannten, 50km entfernt...

 

[Evil E-Lex]

Die Kopie per DD sieht genauso aus, dem Kopierschutz bon ich somit noch nicht auf die Schliche gekommen.

Kannst du unter Umständen auch gar nicht. Oftmals werden veränderte Hersteller/Device-Informationen der SD-Karte als Kopierschutz verwendet. Da du diese nicht ändern kannst, hättest du in so einem Fall keine Chance. Die Hersteller sind nicht so blöd, dass sie sich durch eine simple 1:1-Kopie überlisten ließen, diese Zeiten sind lange vorbei.

 

[DodgerTheRunner]

Oftmals werden veränderte Hersteller/Device-Informationen der SD-Karte als Kopierschutz verwendet

genau das gilt es ja, herauszufinden.
Also welche Form von Schutz wurde verwendet, egal ob man ihn knacken kann oder nicht.
Ich könnte mir zum Beispiel auch vorstellen, dass die Daten der Karte (z.B. CID) auf der Karte selbst irgendwo abgelegt werden und dann abgeglichen.
Immerhin gibt es ja viele von diesen Karten und wenn ich das bislang richtig verstanden habe, dann gilt folgendes:
die CID wird während der Fertigung der Karte geschrieben -> glaube kaum, dass die Anzahl der Karten so hoch ist, dass der Gerätehersteller seine eigenen CIDs schreiben lässt
Die Security-Feature der SecureDigital Karte beziehen sich alle darauf, dass man den Inhalt nicht kopieren kann (DRM und so). Das Kopieren an sich funktioniert aber...

Da werde ich wohl noch ein wenig weiterforschen müssen :-)

 

[Evil E-Lex]

genau das gilt es ja, herauszufinden.
Also welche Form von Schutz wurde verwendet, egal ob man ihn knacken kann oder nicht.

Dann besorg dir das Gerät, für das die Karte bestimmt ist, mache von dem Gerät ein vollständiges Image und danach eine forensische Untersuchung, um zu verstehen, wie die Karte angesprochen wird.

Ich könnte mir zum Beispiel auch vorstellen, dass die Daten der Karte (z.B. CID) auf der Karte selbst irgendwo abgelegt werden und dann abgeglichen.

Das halte ich für ausgeschlossen, da trivial zu umgehen.

Immerhin gibt es ja viele von diesen Karten und wenn ich das bislang richtig verstanden habe, dann gilt folgendes:
die CID wird während der Fertigung der Karte geschrieben -> glaube kaum, dass die Anzahl der Karten so hoch ist, dass der Gerätehersteller seine eigenen CIDs schreiben lässt

Das wird aber höchstwahrscheinlich so sein. Es dürfte kein Problem sein, sich Kleinserien von z.B. 1.000 SD-Karten mit angepasster CID herstellen zu lassen.

 

[Markchen]

Klingt alles irgendwie nicht so ganz legal und deswegen ist hier zu.