Ich schreibe eine C # .Net App, die unter Windows läuft, die ein Image eines Wechseldatenträgers aufnehmen und auf einen Linux Live USB laden muss. Der Live-USB wird in den Zielrechner gesteckt und bootet, beim Start führt er ein Skript aus, das den dd-Befehl wie folgt benutzt, um es auf ein anderes Laufwerk zu flashen:
dd if = / Pfad / zu / Datei / von / csharp / Programm von = / dev / sdX
Das Problem, das ich habe, ist das Erstellen des Bildes auf der Windows-Seite. Ich habe mein Live Linux mit Dateien ausprobiert, die ich auf einem Linux-System mit dd erstellt habe, und das funktioniert gut, aber ich muss in der Lage sein, diese Dateien in einer C # .Net-Anwendung unter Windows zu erstellen. Ich würde lieber nicht auf Cygwin oder eine andere Abhängigkeit angewiesen sein, also habe ich versucht, die Win32-CreateFile-Funktion zu verwenden, um das physische Gerät zu öffnen.
CreateFile wird mit dem ersten Argument aufgerufen, das auf "\. \ F:" gesetzt ist (wenn F: das Laufwerk ist, das ich darstellen möchte), so:
%Vor%Aber wenn die Ausgabedatei mit dem Live Linux USB auf einen Datenträger zurückdiskutiert wird, ist das Ergebnis nicht wie erwartet (der Datenträger ist nicht bootbar usw.), aber durch die Untersuchung der Ausgabedatei in einem Hex-Editor sieht es so aus es gibt einen MBR am Anfang usw.).
Ist das ein Problem mit Endianess oder sollte ich etwas anderes als einen FileStream verwenden, um die Daten in die Datei zu kopieren?
Alternativ gibt es ein Beispiel für dd für Windows-Quellcode (C # oder C ++, ich habe mir das Delphi für Ссылка angesehen und verstehe es nicht vollständig oder habe eine anständige Delphi-IDE, um den Code auseinander zu nehmen, damit ich sehen kann, wie das funktioniert?
AKTUALISIEREN / BEARBEITEN:
Hier ist eine hexadezimale Zeichenfolge der ersten 512 Bytes, die die dd-Ausgabe enthält:
%Vor%und hier ist was mein Code produziert:
%Vor%Dies wurde von genau der gleichen CF-Karte übernommen, ohne dass es irgendwelche Bearbeitungen / Schreibvorgänge gab, also bin ich verwirrt, warum sie so verschieden sind, aber beide enden mit den korrekten 55 AA-Bytes. Verletzt Windows die MBRs auf Karten, wenn sie auf diese Weise aufgerufen werden, oder sind andere seltsame Dinge unter der Motorhaube passiert, von denen ich nichts weiß?
Ich denke, was Sie haben, sollte funktionieren - ich habe es selbst mit einem bootfähigen Disketten-Image versucht (als virtuelles Laufwerk gemountet mit ImDisk ) und die resultierende Datei ist binär identisch mit dem Originalbild.
Zur Vollständigkeit hier ist der Code, den ich verwendet habe (in seiner Gesamtheit):
%Vor%Wenn das nicht funktioniert, dann scheint dies zu bedeuten:
Der wahrscheinlichste Täter ist Schritt 2. Was genau machen Sie mit dem resultierenden Disk-Image?
Update: Dies ist in den Kommentaren geschrieben, aber aus Gründen der Vollständigkeit dachte ich, ich würde es zu meiner Antwort hinzufügen - es sieht so aus, als ob der Inhalt der ersten Partition der Festplatte ist geschrieben werden, wenn statt dessen der Inhalt der gesamten Festplatte gesucht wird.
Wenn Sie sich die zweite hexadezimale Zeichenfolge (die mit Beispielcode erzeugte) in etwas wie HxD ansehen wir sehen das:
%Vor%Das sieht für mich wie der Boot-Sektor einer FAT16-Partition aus - das Vorhandensein der Strings "MSDOS5.0" "NO NAME" und "FAT16" in der Nähe des Start ist ein totes Werbegeschenk.
Vergleiche dies mit der Ausgabe der ersten hexadezimalen Zeichenfolge (der von dd erzeugten):
%Vor%Und wir sehen etwas, das mir sehr ähnlich aussieht wie ein Master Boot Record . Warum? Weil im MBR alle ersten 440 Bytes Boot-Code sind, im Gegensatz zu einem FAT-Boot-Sektor, der den unverwechselbaren Bios-Parameterblock enthält (es sieht wie Müll oben aus, aber wenn Sie das durch einen Disassembler tun, erhalten Sie etwas, das wie gültiges 16 Bit aussieht Code).
Beide sehen auch wie gültige und völlig verschiedene Bootsektoren aus (komplett mit Fehlermeldungen). Es gibt keine Möglichkeit, dass ein Programmierfehler den einen "entstellt" hätte, um wie der andere auszusehen - es muss nur sein, dass das Falsche gelesen wird.
Damit CreateFile den Datenträger anstelle der Partition zurückgibt, sieht es so aus, als müssten Sie ihm nur einen anderen String übergeben, zum Beispiel @"\.\PhysicalDrive0" öffnet den ersten physischen Datenträger.
Siehe:
Dies ist, was ich geschrieben habe, um den Pfad \. \ PhysicalDriveX für einen gegebenen Laufwerksbuchstaben zu erhalten. Wenn Sie den Laufwerksbuchstaben in diesen übergeben und den Rückgabewert nehmen und in CreateFile als erstes Param übergehen, sollte ich jetzt etwas ähnliches wie dd unter Linux bekommen.
%Vor%