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

[mael]

Ist sicher sehr nützlich! Structure view/editor ist als Erweiterung des Dateninspektors geplant.

[lowmax_5]

Zuerst einmal grosses Lob für Dein Tool HxD. :thumb::thumb::thumb: Es gehört zu den täglichen Werkzeugen als Standard dazu!

Kurze Frage: Beim Download bekomme ich nicht auf die neuste Version V2.0 Beta - nur 1.7.7.0 ist verfügbar. Was mache ich falsch?

[Neutral General]

Zitat:

Zitat von lowmax_5 (Beitrag 1365953)

Kurze Frage: Beim Download bekomme ich nicht auf die neuste Version V2.0 Beta - nur 1.7.7.0 ist verfügbar. Was mache ich falsch?

Geh nicht auf die Seite sondern klick auf den Link den er gepostet hat.

[lowmax_5]

Code:

Geh nicht auf die Seite sondern klick auf den Link den er gepostet hat.

https://mh-nexus.de/en/hxd/ ==> keine V2.0

http://mh-nexus.de/de/downloads.php?product=HxD ==> keine V2.0

[Neutral General]

Zitat:

Zitat von lowmax_5 (Beitrag 1365975)

Code:

Geh nicht auf die Seite sondern klick auf den Link den er gepostet hat.

https://mh-nexus.de/en/hxd/ ==> keine V2.0

http://mh-nexus.de/de/downloads.php?product=HxD ==> keine V2.0

:roll: :arrow:

Zitat:

Zitat von mael (Beitrag 1365886)

HxD ist als 2.0 RC verfügbar.

Es gibt im Prinzip nur noch einen Cachingfehler der Rest sollte stabil sein.

Der Cachingfehler bewirkt einfach nur, dass Dateien, die gelöscht oder nicht lesbar sind, mit Fragezeichen dargestellt werden, bis sie wieder lesbar sind. Sonst sorgt der Cache dafür dass die schon gelesenen/dargestellten Bereiche erhalten bleiben und macht es so etwas praktischer.

https://mh-nexus.de/downloads/HxDSetup.zip

[lowmax_5]

Danke! (Da habe ich wohl Tomaten auf den Augen...:shock:)

[Delphi-Laie]

Hoffentlich gibt es auch bald die portable Version 2.0.

Ich installiere grundsätzlich nichts, sofern es auch portabel möglich ist.

[Neutral General]

Zitat:

Zitat von Delphi-Laie (Beitrag 1365987)

Hoffentlich gibt es auch bald die portable Version 2.0.

Ich installiere grundsätzlich nichts, sofern es auch portabel möglich ist.

Der Installer hat eine Option für Portable

[Delphi-Laie]

Zitat:

Zitat von Neutral General (Beitrag 1365988)

Der Installer hat eine Option für Portable

Danke, das sah ich nicht! Ich sah nur den Installer, und das Interesse erlosch schlagartig.

[Delphi-Laie]

Maël, was soll denn "Schreibschützen" bei der portablen Version bedeuten?

Aus Neugier(de) klickte ich es an. Das für die portable Version erstellte Verzeichnis "HxD" ist "halb" schreibeschützt (graue Checkbox in den allgemeinen Eigenschaften). Die darin enthaltenen Dateien und Verzeichnisse sind es nicht. Trotz - oder wegen - dieses halben Schreibschutzes ist das Verzeichnis insgesamt löschbar.

[Neutral General]

Es geht um die Konfigurationsdatei, nicht um das Programm oder das Verzeichnis

[mael]

Genau, es geht um die Konfigurationsdatei.

Somit kann man HxD nun auch auf schreibgeschützten Medien verwenden, wie CDs oder USB-Sticks, die den Schreibschutzschalter aktiviert haben.

Das geht auf einen Wunsch von Himitsu zurück, siehe hier: http://www.delphipraxis.net/1331729-post345.html

Die Setuplösung war aufwendig zu erstellen, aber klappt am besten.

Habe einen Fehler beim Speichern korrigiert, wer es schon runtergeladen hat, am besten nochmal neu runterladen:

https://mh-nexus.de/downloads/HxDSetup.zip

[mael]

HxD 2.2 ist verfügbar.

Download: https://mh-nexus.de/en/downloads.php?product=HxD20
Changelog: https://mh-nexus.de/en/hxd/changelog.php#v_2.2.0.0

[DasZiesel]

Von mir einmal ein ganz großes Lob für das Programm. Ist mein Standard Hex Editor auf allen System. Klein, fein und gut durchgedacht. Gerade durch die Verbesserung in der zweiten Version mit den Anzeigen der Datentypen.

Vielleicht eine kleine Inspiration für die nächste Version. Dass man in einer Datei, Bereiche (farblich) markieren und kommentieren könnte. Das würde das analysieren von Dateien sehr vereinfachen und die Exceltabelle nebenbei überflüssig machen.

[isilive]

Kann mich Ziesel nur anschliessen - dickes Lob!! :thumb:

[mael]

Es gibt nun ein Plugin-Framework um den Dateninspektor von HxD zu erweitern:
https://github.com/maelh/hxd-plugin-framework

Wem es gefällt kann gerne einen Stern verleihen oder es forken, damit mehr Leute es sehen.

[Luckie]

Ups. Ich sollte mal die aktuelle Version installieren. Hat das Ding einen Updatet und gibt es ihn schon in 64 Bit?

[Luckie]

OK. Er hat einen Updater und er ist jetzt 64-Bit. :thumb:

[mael]

Zitat:

Zitat von Luckie (Beitrag 1432046)

OK. Er hat einen Updater und er ist jetzt 64-Bit. :thumb:

Ja seit 1.7.7.0 hat sich einiges getan:
Changelog: https://mh-nexus.de/en/hxd/changelog.php#v_2.0.0.0

[Luckie]

Ich hatte noch eine 1.x.x.x 32-Bit Version installiert. ;-)

[p80286]

Hätte es HxD vor 35 Jahren schon gegeben, ich hätte mich nie ans Programmieren gemacht.
:thumb:

Gruß
K-H

[mael]

Version 2.3 von HxD ist nun verfügbar.

Changelog und Download befinden sich wie bisher auf meiner Seite.

[dummzeuch]

Das Plugin-Interface muss ich mir unbedingt mal ansehen. Wir haben eine Menge binärer Dateien mit festem Record-Aufbau.

Tolles Tool übrigens!

[mael]

Freut mich zu hören.

Bisher kann man nur einfache Datentypen konvertieren, oder man findet einen Weg alles in eine Textzeile zu schreiben.

Zitat:

Zitat von p80286 (Beitrag 1432155)

Hätte es HxD vor 35 Jahren schon gegeben, ich hätte mich nie ans Programmieren gemacht.
:thumb:

Freut mich. Wollte schon vorher kommentieren, aber war mir nicht ganz sicher warum du deswegen auf das Programmieren verzichten würdest, und habe deswegen gewartet ob es irgendwie klarer wird (ist es nicht haha).

[mael]

Hallo,

Falls jemand Kommentare zur Entwicklung des UTF-8 Supports (und anderer Multibyteencodings) hat und wie das von der Benutzerperspektive sein wird, hier ist ein Forumsthread der dies detailliert:

https://forum.mh-nexus.de/viewtopic.php?f=4&t=1004

[p80286]

Zitat:

Zitat von mael (Beitrag 1436235)

Freut mich zu hören.

Bisher kann man nur einfache Datentypen konvertieren, oder man findet einen Weg alles in eine Textzeile zu schreiben.

Zitat:

Zitat von p80286 (Beitrag 1432155)

Hätte es HxD vor 35 Jahren schon gegeben, ich hätte mich nie ans Programmieren gemacht.
:thumb:

Freut mich. Wollte schon vorher kommentieren, aber war mir nicht ganz sicher warum du deswegen auf das Programmieren verzichten würdest, und habe deswegen gewartet ob es irgendwie klarer wird (ist es nicht haha).

Ich hab damals die Tools für die Daten/Disketten-Konvertierung selbst geschrieben. Mit TPascal ging das besser als mit Basic, weil der Kompiler so schnell wie ein Interpreter war.
Dann 3 oder vier Bausteine in eine Batchdatei und man konnte sich ein echtes Produktivitätstool basteln.

Ok ich hab damals viel gelernt, aber der Aufwand für mich war enorm, denn jede Information mußte aus 2 m Büchern destilliert werden.
(Ich habe die IBM-Doku geliebt und gleichzeitg gehasst)

Mit HxD hätte ich viele Analysetools schenken können.
Gruß
K-H

[mael]

Version 2.4 von HxD ist nun verfügbar.

Changelog und Download befinden sich wie bisher auf meiner Seite.

[mael]

Ich arbeite seit einiger Zeit an UTF-8 Support und an Unicode-Text-Ausgabe. Das Thema, alleine das Fontrendering, ist erstaunlich komplex, besonders wenn man verschiedene Ausgabeformen für einen Hexeditor beachten muss, z.B. um Zeichen einzeln auszugeben und complex shaping (wie es von einigen nicht lateinischen Schriftsystemen verwendet wird) zu unterstützen bzw. selektiv zu deaktivieren.

Dann kommt noch die Färbung und die Mischung von verschiedenen Schriftarten, und variable Zeichenbreite bzw. Text in verschiedenen Schreibrichtungen dazu.

Ein Teil davon ist hier dokumentiert https://forum.mh-nexus.de/viewtopic.php?f=4&t=1004 falls jemand einen Blick reinwerfen will.

Jedenfalls wird wohl die nächsten Wochen eine Alpha-Version erscheinen. Eventuell auch zuerst ein allgemeines Textsteuerelement bevor es im Hexeditor erscheint.

Sinn ist es z.B. auch #0 Zeichen eingeben zu können oder einzelne Zeichen wie ein kombinierendes Diaresis (wie Umlaut, nur auf beliebigen Zeichen). Dadurch kann der Dateninspektor dann wirklich alle Chars richtig anzeigen, bzw. Strings die #0 oder Steuerzeichen enthalten. Steuerzeichen werden dann so ähnlich wie in SciTE oder Notepad++ angezeigt.

Im Laufe der Zeit habe ich auch viel von der umfassenden Unicode-Dokumentation gelesen, um rauszufinden wo sichere Grenzen sind beim Segmentieren von Byte-Streams, so dass die Textausgabe nicht variiert, je nach länge des gelesenen Abschnitts (kann z.B. bei BiDi-Texten, bzw. durch formatierenden Steuerzeichen, aber auch durch kombinierende Zeichen ergeben).

Dann habe ich mich mit Schriftarten beschäftigt und wie sie aufgebaut sind, die OpenType-Dokumentation gelesen, um feinere Details von Uniscribe (API zum Ausgeben von Unicode-Text, mit mehr Kontrolle) zu verstehen. Aber auch das detaillierte Mapping von Chars nach Glyphs, habe ich mir angesehen und damit experimentiert. Es ist keine 1-zu-1-Abbildung ist, sondern wird durch Ligaturen, positionssensitive Formen (z.B. Arabisch), oder Umordnung und kontextuelle Ersetzung von Zeichen deutlich komplexer als was man normalerweise von einem Hexeditor bzw. eine einfachen Zeichentabelle erwartet.

Zusammen mit einer sinnvollen Abbildung zwischen Bytes und Zeichen, die auch nicht 1-zu-1 ist, sind viele kleine Details auch bei der Benutzerführung wichtig, damit man trotz dieser Änderung den Hexeditor noch "versteht".

Erstaunlicherweise, ist eine richtige und stabile Textausgabe recht kompliziert, besonders wenn man nicht wie bei Texteditoren von sinnvollen Unterteilungen wie Zeilen ausgehen kann.

Das Feature wird viel kleiner wirken als der Aufwand dahinter, es wird halt Text sein, nur jetzt in allen möglichen Sprachen die Unicode unterstützt. Trotzdem freue ich mich ein bisschen wenn es endlich soweit ist :)

[p80286]

Zitat:

Zitat von mael (Beitrag 1465033)

Das Feature wird viel kleiner wirken als der Aufwand dahinter, es wird halt Text sein, nur jetzt in allen möglichen Sprachen die Unicode unterstützt. Trotzdem freue ich mich ein bisschen wenn es endlich soweit ist :)

Ist das nicht schon immer so gewesen? die letzten 10% machen 90% der Arbeit!
Vielen Dank, daß Du Dich so reinhängst!

:thumb:
K-H

[himitsu]

Hast du gewisst, dass Wikipedia, Heise und Anderen den HdD empfehlen?
Sogar ein japanisches Unternehmen und der Weltmarktführer für Serversicherheit (behauptet die Wiki), sowie andere asiatische Sicherheitsexperten.
https://success.trendmicro.com/solut...int-encryption
https://www.youtube.com/watch?v=HWfpkUZt988 (Typ aus Singapur, Superstar beim Networking and Cyber Security, Programme Manager, ä Bachelor of Information Technology und Träger des Eisernen Kreuzes ähhh Excellent Service Silver Awards)
...

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