Ubu-tester
Anmeldungsdatum: 7. Januar 2011
Beiträge: 2237
Wohnort: NDS
|
moin, ich bastel mir ein Prg. um HDD's auszulesen. Dabei ist mir bei 'EFI' und 'Grub' aufgefallen, das in Dokumentationen, oder in meinem Programm was nicht stimmt. In GPT,Sektor 2 mit Grub steht obiger Text 'Hah!IdontNeedEFI' - ok. Dazu wird in den Beschreibungen eine Hexdarstellung von
21686148-6449-6E6F-744E-656564454649
angegeben. Ich lese aber
48616821-4964-6F6E-744E-656564454649
aus. (Die Minuszeichen '-' mal ignorieren) Wenn ich die einzelnen Bytes umwandel zum Text, stimmen meine ausgelesenen Bytes und nicht die aus den Beschreibungen!
Auch nachzuvollziehen mit:
sudo hexdump -s1024 -n512 -C /dev/sdX
Für 'X' ist das GPT-Laufwerk anzugeben. Klappt nur bei erfogreicher EFI-GRUB Installation.
Gibt es dafür eine Erklärung?
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
Ubu-tester schrieb: 21686148-6449-6E6F-744E-656564454649
angegeben. Ich lese aber
48616821-4964-6F6E-744E-656564454649
[…]
Gibt es dafür eine Erklärung?
Wie man sieht sind hier lediglich Zahlenpaare vertauscht, sprich die Byte-Reihenfolge ist anders. Das ist auch bei – beispielsweise – FAT-Dateisystemen der Fall. Insofern nichts ungewöhnliches, oder führt das hier zu einem Problem?
|
Ubu-tester
(Themenstarter)
Anmeldungsdatum: 7. Januar 2011
Beiträge: 2237
Wohnort: NDS
|
ok, das habe ich auch gemerkt, aber die Aussage in den meisten Dokus stimmt doch nicht! Warum wird dann da was Falsches angegeben? Das könnte man doch auch richtig dahinschreiben, es soll doch in den meisten Fällen was zum Nachschlagen sein.
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
Ubu-tester schrieb: Warum wird dann da was Falsches angegeben?
Nicht falsch, denn: Wie Daten gespeichert werden hat nichts mit deren Repräsentation zu tun.
Das könnte man doch auch richtig dahinschreiben, es soll doch in den meisten Fällen was zum Nachschlagen sein.
Nicht direkt. Man soll die UUID ja zudem auch nicht direkt vom Datenträger auslesen, dafür gibt es entsprechende Werkzeuge und Schnittstellen. Damit kann man dann arbeiten.
|
Ubu-tester
(Themenstarter)
Anmeldungsdatum: 7. Januar 2011
Beiträge: 2237
Wohnort: NDS
|
nene, ich lese die Daten direkt mit 'dd' aus. Damit erhalte ich ein Ergebnis wie aus dem Beispiel. Und in den Dokus steht, das die (falsche) Zahlenkombination hinterlegt ist. Ich weiss, daß viele Angaben im 'Little-Endian' -Format gespeichert werden, aber, das kann so hier nicht für die ganze Zahl gelten, höchstens für ein Teil. sudo hexdump -s1024 -n512 -C /dev/sdX
D.h., es ist so hinterlegt, wie ich es, bzw mit obigen Befehl auslese. Also ist es auch so auf der Platte drauf, nicht wie in vielen Dokus. Das ist irreführend. Denn wenn ich auf der Platte nach den angegebenen Zahlen (Hex-Zahlen) suche, finde ich diese nicht! Meine ausgelesenen Zahlen finde ich aber. Hast Du denn 'hexdump' mal ausgeführt?
|
barcc
Anmeldungsdatum: 13. Juli 2007
Beiträge: 696
Wohnort: Dortmund
|
21686148-6449-6E6F-744E-656564454649
Das ist eine GUID bzw. UUID. In der Spezifikation (RFC 4122) findet man folgenden Beispielcode:
| typedef struct {
unsigned32 time_low;
unsigned16 time_mid;
unsigned16 time_hi_and_version;
unsigned8 clock_seq_hi_and_reserved;
unsigned8 clock_seq_low;
byte node[6];
} uuid_t;
|
Wenn man jetzt Big-Endian decodiert wie in der Spezifikation vorgeschrieben, erhält man:
time_low = 560488776,
time_mid = 25673,
time_hi_and_version = 28271,
clock_seq_hi_and_reserved = 116,
clock_seq_low = 78,
node[6] = 'eedEFI' Auf einem Little-Endian-System liefert ein Memory-Dump die Zeichenfolge 'Hah!IdontNeedEFI' bzw. Hex-Darstellung 4861682149646F6E744E656564454649. Die Trennstriche habe ich weggelassen, weils ja keine GUID ist. Ich habe hier übrigens eine andere GUID und die ist auch "vertauscht".
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
|
Ubu-tester
(Themenstarter)
Anmeldungsdatum: 7. Januar 2011
Beiträge: 2237
Wohnort: NDS
|
moin, alles gut und schön. Wenn in den Dokus ein Hexdump angegeben wird, dann sollte doch das angegeben werden, was wirklich auf der Platte steht, und nicht was da irgendwohin gewandelt wird. Das finde ich irretierend. Die Eintragungen der Startsektoren (und anderes) der einzelnen Partitionen werden auch so angegeben, wie sie auf der Platte stehen. Obwohl diese auch gewandelt werden, umd den Startsektor zu erhalten.
|
Developer92
Anmeldungsdatum: 31. Dezember 2008
Beiträge: 4101
|
Ubu-tester schrieb: Wenn in den Dokus ein Hexdump angegeben wird, dann sollte doch das angegeben werden, was wirklich auf der Platte steht, und nicht was da irgendwohin gewandelt wird.
Dann bist du hier aber an der falschen Stelle. Dazu müsste man Kontakt mit den Entwicklern aufnehmen, damit die das entsprechend umschreiben oder eine entsprechende Erklärung liefern. Allerdings sehe ich nach wie vor das Problem nicht. Bei den mir bekannten Artikeln steht das alles richtig drin, mit entsprechenden Hinweisen wie die Bytes auf der Platte gespeichert werden und wie man sie vertauschen muss, um auf die UUID zu kommen.
|
Ubu-tester
(Themenstarter)
Anmeldungsdatum: 7. Januar 2011
Beiträge: 2237
Wohnort: NDS
|
@ Developer92: ich wollte aber erst mal eine Meinung der User lesen.
Allerdings sehe ich nach wie vor das Problem nicht. Bei den mir bekannten Artikeln steht das alles richtig drin, mit entsprechenden Hinweisen wie die Bytes auf der Platte gespeichert werden und wie man sie vertauschen muss, um auf die UUID zu kommen.
Ich habe genau für diesen Eintrag nirgends gesehen, daß man die Bytes tauschen muß. Bei den Einträgen zu den Positionen und Größen steht es meistens dabei, aber nicht für den hier besagten Eintrag. Da steht klipp und klar was da stehen soll, und das ist falsch! Das hat wohl einer mal reingeschrieben und alle anderen haben es kopiert, ohne es mal zu testen. Ich bin dabei mir ein Prg. zum auslesen und Auswerten von Partitionseinträgen zu schreiben. Unter anderen kann ich diese GPT-ID dann mit einer Liste vergleichen. Nehme ich meinen Eintrag findet das Prg. nichts, nur der verdrehte Eintrag wird gefunden. Sowas ist doch blöd. In der Verrgelichsliste sind noch zig andere Typen-Einträge. Wie viel sind da noch verdreht? Zum Glück werden normalerweise 99% davon unter normalen Umständen nicht gebraucht.
|
Bachsau
Anmeldungsdatum: 2. November 2008
Beiträge: 356
|
Es dürften alle "verdreht" sein. Wenn dein Programm sich nicht an die Standards hält, ist dein Programm Mist, nicht die Dokumentation. Du musst die Daten so von der Disk lesen wie sie sind und dann als Integer oder Long entsprechend der Vorgaben zur Endianbess von UUIDs parsen, dann hast du auch kein Problem.
|