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

[himitsu]

Hab HxD gerade im ReactOS Applications Manager gesehn und gleich mal das Häckchen drangemacht, auch wenn ich ihn gestimmt dort nie benutzen werde. :duck:

[Delphi-Laie]

Zitat:

Zitat von mael (Beitrag 1465033)

Das Feature wird viel kleiner wirken als der Aufwand dahinter

Sei unbesorgt: In einem Programmierforum wie diesem werden viele, wenn nicht die meisten den tatsächlichen Programmieraufwand kennen und so auch Deinen realistisch einschätzen und zu würdigen wissen.

[mael]

Die Version 2.5 ist jetzt verfügbar. Offiziell steht sie noch nicht auf meiner Seite, weil ich noch auf einige Übersetzungen warte.

Aber hier schon mal der Changelog:

Code:

Version 2.5.0.0
---------------

  * Hex editor: implement horizontal mouse wheel scrolling (including handling Logitech driver bug)

  * Data inspector:
    • New: added LEB128/ULEB128 types (variable width integer types used in WASM and dwarf debug information)
    • New: added (U)Int24
    • New: introduce readonly type converters (to allow uniform error messages when attempting to change values, also for converter plugins)
    • Enhancement: better error handling so that typical errors are caught and a more specific error message is given
      - error message for plugin DLLs of wrong machine type (x86-32 vs. x86-64)
  
  * Exporters:
    • New: skip undefined or unreadable sections, such that Intel Hex and S-Record files can be created that have gaps
    • New: source code exporter option to set the maximum text column or bytes per lines (= array elements per line)
    • New: SRecord and IntelHex exporters can now have maximum of 250 and 255 bytes per line, respectively
      - therefore there is also a new default block size/bytes per line setting for each of the exporters, which have a more common size of 32 (for both)
      - allows user to select very large block sizes, yet default to a commonly used size

  * Importers:
     • New: Intel Hex and S-Record support undefined regions of arbitrary size, by creating undefined foldable regions, instead of creating zero filled blocks for them
     • Enhancement: rewrite logic to allow for data records that are out of order (addresses aren't strictly increasing), or overlapping, even when there are gaps of undefined data; previously this could lead to errors, or would only function without undefined data gaps
     • Enhancement: Intel Hex and S-Record importers ignore leading and trailing whitespace in a line
  
  * Checksums / digests:
    • New: custom checksum
      - can generate a checksum, with settable bitwidth for the checksum result, the checksum addends, and the endianness
        - useful for various exotic formats, such as ROM files

  * Search window:
    • use same code as datainspector to convert from string to integer
    • improved the naming of floating point and integer types (closer to data inspector)

    • Searches for both signed and unsigned integers, choosing the right type depending on which fits best (negative numbers => negative type, positive numbers => unsigned type; this is ok, because the positive numbers in the signed type have the same encoding as in the unsigned type; this is a feature of two's complement encoding of integers)

  * Tool windows
    • New: menu items and shortcuts to activate and cycle through tool windows
      - activates (and shows when hidden) either of: data inspector, checksums, or search results
      - implements MRU logic for activation (like Alt+Tab in Windows)
      - can be canceled (and originally activated tool window will be restored)
      - can handle dockable panels, pagecontrols, and childs of those to handle and keep track of activation
      - properly handles switching between back and forward cycling, by switching from Alt+F7 to Alt+Shift+F7, and interrupting cycling when pressing another shortcut
      - extended shortcut handling of VCL/Delphi to handle repeated uses of two shortcuts as part of a shortcut sequence, to properly implement MRU handling, and canceling sequencing (which restores the originally activated tool window), or committing the last chosen tool window, as the activated one
    
      - Global shortcut key Esc to focus editor window

  * PasteFromClipboard:
    • do not delete then insert data in pmOverwrite mode, instead, only overwrite
    • also ensure selection/caret is restored, and therefore always begin a group if selection is available

  * Extensive work to support undefined sections in hex editor that can be deleted, or overwritten, all with undo capability; concerned a lot of supporting internal data structures/algorithms
    • allows for support in importing and exporting files with gaps (=undefined sections)
      - allows for round-trip handling of Intel Hex or S-Record files
    
  * Settings:
    • Data type converters only store their friendly type names in the settings/INI file, when the user changes them
      - this allows for updating those names from version to version, and having them appear automatically without resetting the data inspector in the options
        - also useful for translating HxD, which read the names from the settings when not resetting them, making it appear the translation is not complete
      
  * Fix: entering positive numbers for (U)Int64 results in an out of range error message
  * Fix: Search window: "any" bitwidth does not accept positive integers >= 2^63 (since it was limited to signed numbers only, now supports unsigned ones, too)
  * Fix: HxD would sometimes not detect it was installed (and not in portable mode), because of a case sensitive path comparison
  * Fix: access violation when deleting sections (sections were fixed before, so this bug never triggered)
  * Fix: custom checksum computation uses wrong step size to advance in the byte stream it processes; it would advance in steps of the final checksum's bitwidths, instead of the addend's bitwidth
  * Fix: when overwriting one nibble (key press in hex column) in unaccessible data, set the other nibble to 0 automatically
  * Fix: dockable panels could change fonts in docked and undocked/floating modes
  * Fix: several type and pointer shorting issues, due to types not compatible with x64; they would cause hard to track bugs in the x64 version of HxD under certain versions/configurations of Win 10 (ensuring everything is allocated in memory above 4GiB, during testing, allowed to track them down)
    • issues were in some own code, some third party code, and some Delphi RTL code (TRttiContext, TValue.Make)

  * Various other small enhancements and minor fixes

Und der Download:
Deutsch portable (ohne Setup momentan):
https://mh-nexus.de/downloads/HxD25Deu.zip
Englisch portable (ohne Setup momentan):
https://mh-nexus.de/downloads/HxD25Enu.zip

[himitsu]

Zitat:

Zitat von mael (Beitrag 1481097)

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. :D



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:

Zitat von himitsu (Beitrag 1481132)

Zitat:

Zitat von mael (Beitrag 1481097)

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:

Zitat von Redeemer (Beitrag 1481763)

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;
}