HxD - schneller Hexeditor, Disk-Editor und RAM-Editor

[himitsu]

Zitat von mael:

files can be created that have gaps

Meinst du Sparse Files?
Ich dachte Windows füllt die Lücken, beim Lesen, mit Nullen auf.

Aber klingt super, falls man z.B. etwas von einer defekten Platte runterholen möchte.



Die Technik der Sparse Files werden intern auch für die NTFS-Komprimierung genutzt, um die eingesparten Speicherlücken nicht auf die Platte zu schreiben.

[mael]

Zitat von himitsu:

Zitat von mael:

files can be created that have gaps

Meinst du Sparse Files?

Intel Hex-Dateien werden vor allem dazu verwendet Microcontroller zu programmieren. Ähnlich dazu wie der virtuelle Speicher eines Prozesses unter Windows nicht durchgehend alloziert ist, sondern nur gewisse Speicherbereiche, kann man das auch bei Intel-Hex-Dateien machen.

So kann man Lücken haben, entweder weil nicht der gesamte Flash-Speicher des µC beschrieben werden soll, oder weil einige Speicherbereiche z.B. für den Zugriff auf die Peripherie reserviert ist, wie beim PC für Grafikkarten.

HxD kann nun solche Dateien mit Lücken importieren und wieder exportieren, ohne dass diese Lücken mit Nullen aufgefüllt werden müssen.

(Mit Sparse-Files oder Dateisystemen hat es nichts zu tun - wäre aber vielleicht eine Idee zur Darstellung solcher Dateien, falls HxD jemals direktes/rohes Lesen von NTFS und anderen unterstützt.)

[Redeemer]

Könntest du eine Möglichkeit einbauen, markierte Daten in ein neues Tab zu dekodieren oder Daten aus einem anderen Tab kodiert einzufügen? Kodierungen wären z.B. Base64 oder Zlib, die findet man ja irgendwie ständig.

[mael]

Zitat von Redeemer:

Könntest du eine Möglichkeit einbauen, markierte Daten in ein neues Tab zu dekodieren oder Daten aus einem anderen Tab kodiert einzufügen? Kodierungen wären z.B. Base64 oder Zlib, die findet man ja irgendwie ständig.

Wäre ideal wenn das als Feature Request im Forum auf meiner Seite wäre, gibt viele die ich verwalten muss

[mael]

Momentan arbeite ich wieder an einem Feature dass eine Weile geruht hat: Struktur-Editor/Viewer.

PE-Dateien sind momentan die Vorlage um zu schauen welche Funktionalität notwendig ist. Bisher kann ich dynamische Array definieren bzw. Strukturen variabler Größe, wo andere Teile der Datei diese Größe angeben, bzw. Zeiger darauf verweisen, anstatt dass alle Offsets/Größen fest/konstant sind.

Das nächste Feature wird das dynamische Dekodieren von RVA (relativen virtuellen Addressen) in der PE Datei sein, mithilfe einer Mapping-Funktion die jeder Pointer-Typ haben kann.

Um Dateien strukturiert anzuzeigen, werden Strukturen in einer deklarativen Sprache (die noch im Fluss ist), der HxD-Struktur-Definition-Syntax (HSD), definiert.

Ein funktionierendes Beispiel für den PE-Header sieht wie folgt aus:

Code:

types
  PVirtualAddress = pointer<UInt32, UInt32>


  IMAGE_DATA_DIRECTORY = struct {
    VirtualAddress: UInt32;
    Size: UInt32;
  }

  IMAGE_FILE_HEADER = struct {
    Machine: UInt16;
    NumberOfSections: UInt16;
    TimeDateStamp: UInt32;
    PointerToSymbolTable: UInt32;
    NumberOfSymbols: UInt32;
    SizeOfOptionalHeader: UInt16;
    Characteristics: UInt16;
  }

  IMAGE_OPTIONAL_HEADER32 = struct {
    Magic: UInt16;
    MajorLinkerVersion: UInt8;
    MinorLinkerVersion: UInt8;
    SizeOfCode: UInt32;
    SizeOfInitializedData: UInt32;
    SizeOfUninitializedData: UInt32;
    AddressOfEntryPoint: UInt32;
    BaseOfCode: UInt32;
    BaseOfData: UInt32;

    ImageBase: UInt32;
    SectionAlignment: UInt32;
    FileAlignment: UInt32;
    MajorOperatingSystemVersion: UInt16;
    MinorOperatingSystemVersion: UInt16;
    MajorImageVersion: UInt16;
    MinorImageVersion: UInt16;
    MajorSubsystemVersion: UInt16;
    MinorSubsystemVersion: UInt16;
    Win32VersionValue: UInt32;
    SizeOfImage: UInt32;
    SizeOfHeaders: UInt32;
    CheckSum: UInt32;
    Subsystem: UInt16;
    DllCharacteristics: UInt16;
    SizeOfStackReserve: UInt32;
    SizeOfStackCommit: UInt32;
    SizeOfHeapReserve: UInt32;
    SizeOfHeapCommit: UInt32;
    LoaderFlags: UInt32;
    NumberOfRvaAndSizes: UInt32;
    DataDirectory: IMAGE_DATA_DIRECTORY[:NumberOfRvaAndSizes];
  }

  IMAGE_NT_HEADERS32 = struct {
    Signature: UInt8[4];
    FileHeader: IMAGE_FILE_HEADER;
    OptionalHeader: IMAGE_OPTIONAL_HEADER32;
  }


  PIMAGE_NT_HEADERS32 = pointer<UInt32, IMAGE_NT_HEADERS32>

  IMAGE_DOS_HEADER = struct {
    e_magic: UInt8[2];
    e_cblp: UInt16;
    e_cp: UInt16;
    e_crlc: UInt16;
    e_cparhdr: UInt16;
    e_minalloc: UInt16;
    e_maxalloc: UInt16;
    e_ss: UInt16;
    e_sp: UInt16;
    e_csum: UInt16;
    e_ip: UInt16;
    e_cs: UInt16;
    e_lfarlc: UInt16;
    e_ovno: UInt16;
    e_res: UInt16[4];
    e_oemid: UInt16;
    e_oeminfo: UInt16;
    e_res2: UInt16[10];
    _lfanew: UInt32;
  }

  IMAGE_SECTION_HEADER = struct {
    Name: Char8Ansi[8];
    Misc_PhysicalAddressOrVirtualSize: UInt32;
    VirtualAddress: UInt32;
    SizeOfRawData: UInt32;
    PointerToRawData: UInt32;
    PointerToRelocations: UInt32;
    PointerToLinenumbers: UInt32;
    NumberOfRelocations: UInt16;
    NumberOfLinenumbers: UInt16;
    Characteristics: UInt32;
  }

  IMAGE_IMPORT_DESCRIPTOR = struct {
    OriginalFirstThunk_ImportLookupTable_RVA: UInt32;
    TimeDateStamp: UInt32;
    ForwarderChain: UInt32;
    Name_RVA: UInt32;
    FirstThunk_ImportAddressTable_RVA: UInt32;
  }

  OVERALL_FILE = struct {
    ImageDosHeader: IMAGE_DOS_HEADER;
    ImageNtHeaders32: IMAGE_NT_HEADERS32 @ :ImageDosHeader._lfanew;                                                        
    ImageSectionHeaders: IMAGE_SECTION_HEADER[:ImageNtHeaders32.FileHeader.NumberOfSections];
  }

instances
  $root: OVERALL_FILE

Das sieht dann nach dem parsen von PropEdit.exe (ein anderes meiner Programme -- kann aber ein beliebiges sein), so wie in den Anhängen aus.

[mael]

Was besonders ist (neben der grundsätzlichen Fähigkeit Strukturen zu definieren und Dateien entsprechend geparst anzuzeigen), sind Ausdrücke wie folgender:

Code:

DataDirectory: IMAGE_DATA_DIRECTORY[:NumberOfRvaAndSizes];

Wie man im vierten Bild sieht, wird obwohl die Arraygröße von DataDirectory dynamisch aus der Datei bestimmt wird (NumberOfRvaAndSize ist vorher als Feld in der Datei definiert worden), das Array richtig angezeigt. Mit normalen Programmiersprachen muss man da etwas nachhelfen, Strukturen mit eingebetteten dynamischen Arrays (nicht einfach Zeiger auf einen anderen Bereich) gibt es nicht. Bei HSD geht das deklarativ.

Die Position von ImageNtHeaders32 ist auch abhängig von ImageDosHeader._lfanew, was man auch in einer normalen Programmiersprache nur durch zusätzlichen Code darstellen kann. In HSD reicht diese Deklaration:

Code:

ImageNtHeaders32: IMAGE_NT_HEADERS32 @ :ImageDosHeader._lfanew;

Dass es funktioniert sieht man im zweiten Bild.

ImageSectionHeaders ist auch wieder dynamisch definiert, aber so dass es von zwei vorherigen dynamischen Definitionen abhängt: sowohl um den Startoffset zu bestimmen, als auch die Länge.

Edit:
Die Screenshots sind von einem Hilfsprogramm, das Steuerelement das da sichtbar ist noch in der Entwicklung und so wie der allgemeine Code noch weit von einer Alpha entfernt (und somit bewusst buggy, weil unvollständig). Wenn Interesse besteht, kann ich das Programm zum ausprobieren trotzdem mal hochladen.

[mael]

So, jetzt kann man auch eingebaute Funktionen verwenden, um z.B. Adressen zu mappen:

Code:

PVirtualAddress = pointer<UInt32, UInt32, RVAToFilePointer>

Erstes UInt32 ist die Adress-breite, zweites ist das Ziel des Pointers (hier wieder ein UInt32), und RVAToFilePointer ist die Funktion die Berechnungen mit der Adresse anstellen kann.

Hier wird die eingebaute Funktion RVAToFilePointer aufgerufen um die Adresse (eine RVA/relativ virtual address) in der PE-Datei in einen absoluten File-Offset zu übersetzen.

Man kann jetzt also die Data-Directories in der PE-Datei wie folgt definieren, und der Strukureditor wird sie somit automatisch finden und richtig anzeigen, alles deklarativ:

Code:

IMAGE_DATA_DIRECTORY = struct {
  VirtualAddress: PVirtualAddress;
  Size: UInt32;
}