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

[p80286]

Zitat:

Zitat von jaenicke (Beitrag 1326358)

Zitat:

Zitat von mael (Beitrag 1326325)

Ich wollte nur mal fragen ob hier noch Interesse besteht, so als Endspurtmotivation ;)

Absolut! Insbesondere das Feature eine interne Struktur, einen record aus Delphi z.B., auszuwerten, wäre Gold wert. ;-)

AuJa, wobei mir schon reichen würde, wenn ich die Struktur definieren würde und die Anzeige wäre entsprechend.

Gruß
K-H

[mael]

Vielen Dank für die positiven Rückmeldungen :D

Mein Ziel ist es jetzt eine stabile Version in 2 Wochen rauszubringen. Weitere Features sind daher für später.

[Luckie]

Mach weiter! Es ist ein schöner light-weight Hex-Editor. Ich bin Geocacher und wenn ich bei Mysteries, also Rätsel-Caches, Dateien untersuchen muss, ist er meine erste Wahl. Ich kenne eigentlich gar keinen anderen. :roll:

[mael]

Ich komme gut voran und in einer Woche sollte die Beta tatsächlich bereit stehen.

Die 64-Bit Version könnte etwas länger dauern, weil ich einige x87-Funktionen implementieren und testen muss (der 64-Bit Delphi-Compiler hat "praktischerweise" keinen Support für den Extended-Datentyp mehr, es ist aber der einzige Gleitkomma-Datentyp der Int64 verlustfrei speichern kann, und sehr nützlich um einiges zu berechnen.)

[jaenicke]

Zitat:

Zitat von mael (Beitrag 1327229)

der 64-Bit Delphi-Compiler hat "praktischerweise" keinen Support für den Extended-Datentyp mehr, es ist aber der einzige Datentyp der Int64 verlustfrei speichern kann, und sehr nützlich um einiges zu berechnen.

Nur rein interessehalber: Warum braucht man dafür einen 10 Byte Datentyp? Ich hatte bisher mit Int64 noch keine Probleme.

[mael]

Zitat:

Zitat von jaenicke (Beitrag 1327236)

Zitat:

Zitat von mael (Beitrag 1327229)

der 64-Bit Delphi-Compiler hat "praktischerweise" keinen Support für den Extended-Datentyp mehr, es ist aber der einzige Datentyp der Int64 verlustfrei speichern kann, und sehr nützlich um einiges zu berechnen.

Nur rein interessehalber: Warum braucht man dafür einen 10 Byte Datentyp? Ich hatte bisher mit Int64 noch keine Probleme.

Ich verwende auch fast überall Int64. Aber z.B. bei der Berechnung des Fortschritts geht das so nicht. Anstatt langwieriger Erklärungen hier mal Pseudocode (einige Sonderfälle nicht beachtet):

Delphi-Quellcode:

var
  MinPos, MaxPos, Range: Int64;
  ProgressStep: Extended; // Feld einer Klasse, keine lokale Variable
begin
  Range := MaxPos - MinPos; // Repräsentiert z.B. die minimal und maximal mögliche Position innerhalb einer Datei
  ProgressStep := Range / ProgressBar.Max;
end;

procedure SetProgressBarPos(Pos: Int64);
begin
  ProgressBar.Position := Round(Pos * ProgressStep);
end;

Bei ganzzahligen Operationen kann ProgressStep den Nachkommaanteil nicht speichern und sich dieser Fehler in SetProgressBarPos() stark "summieren".

Warum ich diese Skalierung überhaupt brauche? ProgressBars können höchstens Int32 verarbeiten, aber HxD kann Dateien über 4GiB darstellen. Ähnliches gilt für Scrollbars oder andere Positionsbestimmungen im Code die relativ zu etwas anderem sind.

[jaenicke]

Danke für die Erklärung.
Ja, so ein Problem hatte ich auch schon. Bei mir ließ sich das so lösen, dass ich die Zwischenberechnungen weggelassen habe und direkt nur am Ende alles so berechnet habe, dass keine zu großen Zahlen entstehen. Aber das geht natürlich nicht immer...

[mael]

Durch deine Frage ist mir ein Vergleich zu Arduino eingefallen, hatte nie genauer darüber nachgedacht.

Interessanter Weise hat die map()-Funktion dort ein paar Probleme, und ich dachte schon die löst das clever :/ :
http://www.jetmore.org/john/blog/201...-distribution/
http://forum.arduino.cc/index.php/topic,72153.0.html

[Blup]

Gerade beim Progressbar ist eine hohe Genauigkeit nicht erforderlich, mehr als 100 Positionen sind optisch kaum unterscheidbar.
Die Berechnung der neuen Progressbarposition darf sich dabei aber nur auf den neuen Absolutwert stützen.

Delphi-Quellcode:

{Die resultierende Position des Progressbar mit Wertebereich 0..1}
function NormalProgress(ACurrentPos, AMinPos, AMaxPos: Int64): Float;
begin
  Result := (ACurrentPos - AMinPos) / (AMaxPos - AMinPos);
end;

procedure SetProgressBarPos(APos, AMinPos, AMaxPos: Int64);
begin
  {z.B. Progressbar.Max = 100}
  ProgressBar.Position := Round(NormalProgress(Pos, AMinPos, AMaxPos) *  ProgressBar.Max);
end;

[mael]

Theoretisch sind so viele Stellen relevant wie Pixel am Schirm für den Fortschrittsbalken/Scrollleiste dargestellt werden, wird natürlich trotzdem < 10000 bleiben bei üblichen Auflösungen.

Aber das Problem ist auch die Rückkonvertierung, also aus der aktuellen Position der ScrollBar die Position innerhalb der Datei zu bestimmen. Ein Int64 kann nur näherungsweise in einem Double gespeichert werden. Da passiert es auch mal das hochgerundet wird und man dann nicht mehr in ein Int64 konvertieren kann, obwohl es gehen sollte. High(Int64) = 9223372036854775807 wird zu 9223372036854780000 wenn man es in ein Double konvertiert. Also größer als der größte Int64-Wert.

Delphi-Quellcode:

procedure FloatTests;
var
  i, i2: Int64;
  e: extended;
begin
  i := High(Int64);
  e := i;
  assert(e <= i); // wird nicht bemängelt obwohl eindeutig falsch unter x64
  i2 := Trunc(e); // erzeugt exception unter x64 (überlauf)
  assert(i = i2); // stimmt immer unter x86, egal welche Int64 man dem e zugewiesen hat
end;

Das könnte man vielleicht noch umgehen indem man zusichert dass der Double-Wert immer kleiner als der maximale Int64-Wert ist vor der Konvertierung.
Da Trunc und andere Rundungsmethoden aber alle Exceptions werfen, muss man also immer vorhersagen wann es (implizite) Rundungen geben könnte die den Wertebereich überschreiten. In diesem Fall wäre es problemlos bis High(Int64) - 512. 10-byte Extended hat das Problem nicht.


Also, so oder so, es sind deutlich mehr Prüfungen und Codereviews notwendig, da auch häufig mal implizit in Extended gerechnet wird in Delphi, wenn man keine expliziten Gleitkommatypen angibt. Also etwa sowas:

Delphi-Quellcode:

var
  i: Integer;
begin
  i := Round(i / 20);
end;

[himitsu]

Kommst du überhaupt in diesen Größenbereich?

RAM und Festplatten/Dateigrößen im Bereich von paar Exabyte.

[Luckie]

Zitat:

Aber das Problem ist auch die Rückkonvertierung, also aus der aktuellen Position der ScrollBar die Position innerhalb der Datei zu bestimmen.

Moment. Um den Fortschritt anzeigen zu können, musst du doch schon vorher wissen an welcher Position du in der Datei bist. Was muss man da wieder zurück konvertieren? Oder habe ich hier jetzt ein Verständnisproblem?

[mael]

Zitat:

Zitat von Luckie (Beitrag 1327465)

Zitat:

Aber das Problem ist auch die Rückkonvertierung, also aus der aktuellen Position der ScrollBar die Position innerhalb der Datei zu bestimmen.

Moment. Um den Fortschritt anzeigen zu können, musst du doch schon vorher wissen an welcher Position du in der Datei bist. Was muss man da wieder zurück konvertieren? Oder habe ich hier jetzt ein Verständnisproblem?

Ich bin da vielleicht etwas konfus in meiner Beschreibung. Fortschrittsanzeige und ScrollBars haben nicht direkt was miteinander zu tun, haben nur verwandte Probleme insofern dass ich Gleitkommazahlen benötige.

Wenn ich mit der ScrollBar Thumbtracking mache (also diesen "Schieber" die Leiste entlangbewege -- Hey! Schiebeleiste wäre doch eine gute Übersetzung für ScrollBar... naja Bildlaufleiste gibt es ja schon, oder Rollleiste wäre eine Idee, hört sich aber komisch an, dann wäre der "Schieber" ein "Roller"... Übersetzungen sind immer so eine Sache :D).

Also, wenn man den "Schieber" die Bildlaufleiste entlangbewegt kann man so eine Art wahlfreien Zugriff (random access) auf die Datei erzeugen. Abhängig davon wo man den Schieber mit der Maus hinbewegt und wie schnell kann es deutliche Sprünge von TScrollBar.Position geben. Man kann also nicht wie beim Klicken der "Hoch"/"Runter"-Knöpfe oder Scrollen per Mausrad schrittweise inkrementieren und so das Problem umgehen.

Also muss sowas in der Art berechnet werden:

Delphi-Quellcode:

DateiPosition := Round(ScrollBar.Position * Skalierungsfaktor);

Zitat:

Zitat von himitsu (Beitrag 1327448)

Kommst du überhaupt in diesen Größenbereich?

RAM und Festplatten/Dateigrößen im Bereich von paar Exabyte.

Ist natürlich ein berechtigter Einwand. Hätte halt gerne vermieden solche Abschätzungen machen zu müssen ab wann ich Probleme mit Doubles bekomme.

Theoretisch ist die Grenze des virtuellen Arbeitsspeichers 8 EiB, praktisch ist er momentan unter Windows bei 8TiB bzw. 128 TiB (Memory Limits for Windows and Windows Server Releases).
D.h. momentan sind alle virtuellen Adressen <= $800000000000 (128TiB). $8000000000000000 (8EiB) ist $10000 mal größer als 128TiB. 128TiB würde also wohl noch in einen Double passen. Hmm, wäre also zumindest für den Moment kein Problem. Zukunftssicher wäre natürlich schöner.

P.S.: Man kann die hohen Adressen auch nicht in den meisten Fällen ignorieren da dort die System-Dlls geladen werden oder auch Programme vom Speicherallozierer fordern können Speicher in hohen Adressen zu bekommen (also vom Maximum abwärts "wachsend").

[himitsu]

In Windows ist bei 16/128 TB (44/48 Bit) scheinbar einfach so Schluß, auch wenn 64 Bit mehr könnte.
https://msdn.microsoft.com/de-de/lib...#memory_limits

[edit] ups, nicht fertig gelesen und schon angefangen mit schreiben .... aber so als Bestätigung :stupid:



Du kannst auch die Maus nur um ganze Pixel verschieben, so dass selbst in FMX die unscharfen Fließkommapixel nix helfen.

[Medium]

Zitat:

Zitat von himitsu (Beitrag 1327508)

Du kannst auch die Maus nur um ganze Pixel verschieben, so dass selbst in FMX die unscharfen Fließkommapixel nix helfen.

Nicht ganz richtig. Wenn man einen LowLevel-Hook auf die Maus macht, bekommt man deren Koordinaten immer im Intervall 0..65535. Das ist was intern immer als Basis benutzt wird. Für die Benutzung in höheren Schichten wird das dann erst auf die Desktopgrenzen gemapped.

(Interessant wird das, wenn Desktops mit real mehr als 32767 Pixeln in Breite oder Höhe gebraucht werden, weil dann wird nach Shannon-Nyquist (bei linearem Mapping und naiver Rundung) nicht mehr jeder Pixel garantiert abbildbar :stupid:)

[mael]

Ich dachte schon ich hätte nun so gut wie alles durchgesehen, da ist mir aufgefallen dass die Logik für Locking/Sharing von Dateien/Disks noch unvollständig war.

Es funktioniert zwar, aber so dass sie permanent acquired/released werden, was zu unheimlichen Lags führt. War schon Jahre her dass ich diesen (damals unfreiwillig unbeendeten Teil) geschrieben hatte, und daher nicht mehr klar.

Kurz gesagt: mehr Design ist notwendig um das abzuschließen :/

Aber die nächste Version kommt auf jeden Fall, das wird jetzt bis zum Schluss durchgezogen.

(P.S.: Entschuldigung für das Denglisch.)

[himitsu]

So lange es noch in diesem Jahrtausend kommt, ist doch alles in Ordnung.

Ansonsten solltest du schon mal langsam Three-State-Quantenbits implementieren. (True, False, Maybe :stupid:)

[mael]

Zitat:

Zitat von himitsu (Beitrag 1329295)

So lange es noch in diesem Jahrtausend kommt, ist doch alles in Ordnung.

Ansonsten solltest du schon mal langsam Three-State-Quantenbits implementieren. (True, False, Maybe :stupid:)

Das sollte sich einrichten lassen, ebenso wie ein paar Heisenbugs ;)

[Delphi-Laie]

Zitat:

Zitat von mael (Beitrag 1329268)

Aber die nächste Version kommt auf jeden Fall, das wird jetzt bis zum Schluss durchgezogen.

Was heißt das - ist eine Ende abzusehen?

Oder ist der "Schluss" aus heutiger Sicht offen?

[mael]

Zitat:

Zitat von Delphi-Laie (Beitrag 1329436)

Zitat:

Zitat von mael (Beitrag 1329268)

Aber die nächste Version kommt auf jeden Fall, das wird jetzt bis zum Schluss durchgezogen.

Was heißt das - ist eine Ende abzusehen?

Oder ist der "Schluss" aus heutiger Sicht offen?

Das heißt dass das Ende abzusehen ist, aber länger dauert als ich vermutet habe und ich gerne hätte dass es schneller geht ;)

[mael]

Es ist endlich soweit, die HxD 2.0 Beta ist da!

Der einzige offene Punkt ist, dass besonders bei Festplatten, das Scrollen etwas langsam sein kann -- dies wird noch bis zur Stable behoben.

Wenn ihr Fehler findet könnt ihr sie beh.. berichten :D. Es soll ein gutes (aber auch baldiges) Release sein.

Es ist sehr viel Arbeit und Sorgfalt eingeflossen darin den Code durchzusehen und vieles zu überarbeiten und zu verbessern. Viel Arbeit wurde auch in das "Tooling"/die Werkzeuge gesteckt, da ich z.B. ein eigenes Übersetzungsprogramm habe (Babelfish) und das ein großes Codereview benötigt hat um sicherzustellen dass es mit allen Änderungen von Delphi 7 zu XE3 umgehen kann.

Von 64-Bit bis Unicode war das nicht ganz einfach, ich musste auch Code aus dem XN-Resource-Explorer anpassen (zur Resourcenverwaltung/updaten) und korrigieren. Außerdem gab es viele Innereien der VCL wo ich Patches hatte für kleine störende Fehler, Änderungen in Windows, usw.
Zwischenzeitlich hatte ich auch versucht per Freepascal eine 64-Bit Version zu machen als Delphi noch kein 64-Bit konnte, und dafür IPC-Code geschrieben (mit eigener IDL etc.), der aber schnell genug sein musste um Daten zu streamen. Aber das hat die ganze Architektur etwas komplex gemacht. Genauso wie die eigene Implementierung für Unicode, die natürlich mit den neuen Delphiversionen nicht kompatibel war.
Mit Delphi XE3 fing dann das große Umschreiben, Anpassen, und Fertigstellen von Features an.
Vieles davon ist also unter der Haube passiert und nicht so sichtbar.

Wegen all den Prüfungen/Überlegungen gehe ich davon aus, dass die Fehler die sich eventuell zeigen werden, sich auch ohne allzu großen Aufwand beheben lassen.

Was ist (sichtbar) neu?
Es gibt sicher noch Teile die ich vergessen habe, und die im langen SVN-Log seit dem letzten Release stehen.
Hier die Wichtigsten/Auffälligsten:

• HxD komplett in 32 und 64-Bit
• 64-bit RAM-Editor
  • Auch 32-Bit HxD kann mit 64-Bit Prozessen umgehen (bis zur 4 GiB-Grenze)
  • Zeigt nun auch die Prozess-ID an
• Dateninspektor
  • Daten werden als verschiedene Datentypen interpretiert angezeigt und sind editierbar
    • Alle Integer und Float-Typen
    • Datums-/Zeittypen
    • Zeichen (WideChar/AnsiChar)
    • GUID
    • Disassembly (x86-16, x86-32, x86-64)
• Mehr Informationen im Datenträger-Öffnen-Fenster
• Import-Funktion
  • Motorola S-Record
  • Intel Hex
  • ETL Extended
• Exportieren/Kopieren als
  • PureBasic
• Alle suchen
  • Listet alle Funde zusammen mit Fundkontext auf
• Abwechselnd gefärbte Spalten
• Beim Setzen des Windows-Explorer-Kontextmenüs in den Optionen wird nun UAC aufgerufen anstatt zu erwarten dass HxD als Admin gestartet wurde (und stillschweigend fehlzuschlagen)
• Beachten des Zeichensatzes in der Statistik
• Einige weitere kleinere Änderungen an der GUI und den Optionen

Hier der Download der deutschen Portable-Version: http://mh-nexus.de/downloads/HxD20BetaDeu.zip

[Neutral General]

Super, habs mir direkt runtergeladen! :)
Hab logischerweise erst grob drübergeschaut aber was mir aufgefallen ist:

1) Nachdem man im Optionsfenster war und dort auf OK geklickt hat (egal ob man was geändert hat oder nicht)
wird im Dateninspektor bei AnsiChar immer "Ungültig" angezeigt, egal wo der Cursor steht bzw. was man selektiert.
Wenn man dann eine Datei öffnet oder eine neue Datei erstellt funktioniert es wieder.

2) Was an Features vllt. noch ganz cool wäre:
Einen selektierten Bereich disassemblieren. Da muss dann keine große Intelligenz dahinterstehen.
Einfach die Bytes so wie sie kommen übersetzen.

3) Ich erhalte beim Exportieren den Fehler

Zitat:

---------------------------
HxD
---------------------------
Fehler bei Bereichsprüfung.
---------------------------
OK
---------------------------

[p80286]

Starkes Teil!

Nur bei Export schau ich nicht so richtig durch. Ich wollte eigentlich nur einen primitiven Hexdump erstellen und das geht nicht????

Welches EBCDIC unterstützt Du?
70 76 oder ML?


Gruß
K-H

[mael]

Zitat:

Zitat von Neutral General (Beitrag 1331692)

1) Nachdem man im Optionsfenster war und dort auf OK geklickt hat (egal ob man was geändert hat oder nicht)
wird im Dateninspektor bei AnsiChar immer "Ungültig" angezeigt, egal wo der Cursor steht bzw. was man selektiert.
Wenn man dann eine Datei öffnet oder eine neue Datei erstellt funktioniert es wieder.
3) Ich erhalte beim Exportieren den Fehler

Zitat:

---------------------------
HxD
---------------------------
Fehler bei Bereichsprüfung.
---------------------------
OK
---------------------------

Danke, korrigiert. Ich warte noch auf weiteres Feedback und veröffentliche dann die Korrekturen zusammen.
Nr. 2 ist was für eine zukünftige Version, ich möchte jetzt keine neuen Fehler einführen.

Zitat:

Zitat von p80286 (Beitrag 1331709)

Nur bei Export schau ich nicht so richtig durch. Ich wollte eigentlich nur einen primitiven Hexdump erstellen und das geht nicht????

Abgesehen vom Fehler der oben gemeldet wurde, funktioniert das einfach durch Kopiern&Einfügen. Man muss dazu nur im Hexbereich (nicht Textbereich) des Hexeditors sein, es wird dann in der Zwischenablage sowohl als Text(hexdump) bzw. als Bytefolge gespeichert. Die Windows-Zwischenablage unterstützt verschiedene Datentypen gleichzeitig.

Will man einen formatierten Hexdump, dann wählt man "Kopieren als/Exportieren|Editoranzeige".

Zitat:

Zitat von p80286 (Beitrag 1331709)

Welches EBCDIC unterstützt Du?
70 76 oder ML?

Entweder was LOCALE_IDEFAULTEBCDICCODEPAGE zurückgibt, oder als Fallback EBCDIC 500

[himitsu]

Zitat:

Zitat von mael (Beitrag 1331726)

ich möchte jetzt keine neuen Fehler einführen.

Och menno. :(

Zitat:

HxD wurde nicht installiert und wird damit automatisch in einer portablen Art arbeiten, so daß es auf Wechselmedien wie USB-Sticks verwendet werden kann. Damit dies funktioniert muß eine Konfigurationsdatei im Anwendungsverzeichnis von HxD erstellt werden die für alle Benutzer gilt. Falls Sie HxD in einer Mehrbenutzerumgebung verwenden oder eine Integration in das Betriebssystem wünschen (z.B. Explorer-Kontextmenü) ist eine Installation vorzuziehen.

Konfigurationsdatei im Anwendungsverzeichnis erstellen um HxD portabel zu machen?

Hab auf Abbrechen gedrückt und dachte ich kann erstmal so...
Hätte mir also eher ein

Delphi-Quellcode:

 [Ja] [Nein]

oder

Delphi-Quellcode:

 [Ja] [Nein] [Abbrechen]

gewünscht, wo das Programm bei "Nein" auch ohne gespeicherte Settings läuft. (es soll noch Leute geben, die CDs benutzen oder USB-Sticks mit Schreibschutz :stupid:)

Werden das mit der Zeit so viele Settings, dass die in ein Unterverzeichnis müssen? (geschrieben stand auch "Programmverzeichnis" und nicht "Unterverzeichnis" :tongue:)
Das in der .lang war so viel, dass es nicht in die .ini passte?

PS: Das HxD Hex Editor.lang wird schon vor diesem Dialog gespeichert. :shock:

Zitat:

Nicht lesbare Bereiche ausblenden

Wäre schön, wenn man das im Menü Ansicht nochmal hätte. (vielleicht als 2 Menüpunkte, Lesbares einblenden und Nichtlesbares Ausblenden, am Besten aus den selektierten bereich, wenn z.B. mehr als 100 Byte markiert sind)
Und ausblenden vielleicht als "ganz weg" und nicht nur zusammengeklappt.

Suchen nur in angezeigten/aufgeklappten Bereichen.

Es gibt auch "Sparse-Files", bei denen Teile der Datei nicht "real" auf der Platte existieren. (ReadFile liest da immer nur Nullen aus)
Prinzipiell vergleichbar mit den "nichtlesbaren" RAM-Bereichen.

Beim Ändern von Bytes in PAGE_EXECUTE* ein FlushInstructionCache ausführen?

Strg+Runter/Hoch > springe zum nächsten/vorherrigen Bereich
Strg+Shift+Runter/Hoch > markiere bis zum Ende/Anfang des Bereichs (bzw. wenn schon am Anfang/Ende, dann den ganzen nächsten Bereich)

---

Du bist also jetzt fertig und hast die nächsten Jahrzehnte nix mehr zu tun? :stupid:
Hätte ich mir schon immer was zur Prozessanzeige (RAM) gewünscht.

Was zuerst gut wäre: Ein DUMP, also 'nen Snapshot des RAM speichern und später wieder laden, samt der Metainformationen.
HDD-Abbilder werden auch mit Metainfos gespeichert? (Größe der Sektoren, Name der Platte/Partition usw.)

Dann vielleicht noch ein bissl Farbe und Trennung in die Anzeige?

• Trennlinie zwischen die Bereiche
• nichtlesbare Bereiche gräulich hinterlegt

.
.
.

Aber voll geil wären Metainfos zu den einzelnen RAM-Bereichen (da helfe ich auch gern)
Bzw. die Sektoren bei Festplatten/Dateien "Sektor 2 (Byte 00020000 bis 0002FFFF)"

• angefangen mit VirtualQueryEx
  • MEM_COMMIT MEM_RESERVE MEM_FREE MEM_PRIVATE MEM_MAPPED (kann man schön farblich machen ... abgesehn von FREE besser nur als Streifen am Rand)
  • EXE und DLL sind oft als MEM_MAPPED+PAGE_EXECUTE_WRITECOPY in den RAM gemappt
    • Kann man hier irgendwie rausfinden, ob Bytes einer geladenen EXE/DLL "manipuliert" sind?
• ModulName (EXE, DLL, Named-MMF)
  • wenn man ganz hart drauf ist, kann man auch die PE-Header auslesen und bei EXE/DLL die Sektionen der Module/Dateien mit anzeigen
    • TImageFileHeader TImageOptionalHeader TImageSectionHeader TImageExportDirectory TImageDataDirectory uvm. (Windows.pas)
    • Start-/Einsprungadresse, #CODE-Section, #DATA-Section, Resource-Section, Sprung-Tabellen der importierten DLL-Funktionen, ...
  • und die ganz harten, würden dann noch die Debuginfos suchen und Code-Adressen der einzelnen Funktionen/Bezehle suchen
• man wird bestimmt auch irgendwie die Stacks aller Trhreads suchen/markieren können
• Speicher manipulieren (erweitert)
  • VirtualProtectEx, VirtualAllocEx, VirtualFreeEx
  • PAGE_EXECUTE PAGE_EXECUTE_READ PAGE_EXECUTE_READWRITE PAGE_EXECUTE_WRITECOPY PAGE_GUARD PAGE_NOCACHE

Wenn man diese Metainfos hat, dann könnte man das "Nicht lesbare Bereiche ausblenden" bestimmt nützlich noch erweitern. :D

• zeige nur Module (EXE/DLL) an
• zeige nur veränderte Module (EXE/DLL) an
• zeige nur "RAM" an (ohne Modul-Abbilder und MMFs)

[mael]

Einige Korrekturen, unter anderem für die oben genannten Bugs.
Gleicher Download wie vorher:
http://mh-nexus.de/downloads/HxD20BetaDeu.zip

(Die Bereichsfehler sind sozusagen Tests ob jemand testet... ;)

[Neutral General]

Zitat:

Zitat von mael (Beitrag 1331799)

(Die Bereichsfehler sind sozusagen Tests ob jemand testet... ;)

Würde ich auch behaupten :P
Klappt jetzt soweit alles, super :)

Zitat:

Zitat von himitsu (Beitrag 1331729)

Du bist also jetzt fertig und hast die nächsten Jahrzehnte nix mehr zu tun? :stupid:
Hätte ich mir schon immer was zur Prozessanzeige (RAM) gewünscht.

...

Ja doch, die Features würde ich auch nehmen :)

[mael]

Zitat:

Zitat von himitsu (Beitrag 1331729)

Zitat:

<Startmeldung zum Anlegen einer INI-Datei>

Hab auf Abbrechen gedrückt und dachte ich kann erstmal so...
Hätte mir also eher ein

Delphi-Quellcode:

 [Ja] [Nein]

oder

Delphi-Quellcode:

 [Ja] [Nein] [Abbrechen]

gewünscht, wo das Programm bei "Nein" auch ohne gespeicherte Settings läuft. (es soll noch Leute geben, die CDs benutzen oder USB-Sticks mit Schreibschutz :stupid:)

Das Problem ist wie folgt: Die meisten wollen die Konfiguration ändern können, daher ist die Standardeinstellung, dass man eine Konfiguration schreiben kann (schon alleine wegen "Zuletzt geöffnete Dateien"). Eine mögliche Option wäre in der INI-Datei zu speichern, dass sie als schreibgeschützt betrachtet werden soll. Aber man kann nicht einfach still fehlschlagen wenn Schreiben nicht möglich ist (weil das Medium/Verzeichnis schreibgeschützt ist). Aus diesem Schreibschutz kann man nicht schließen ob dies Absicht ist oder nicht, daher muss dies als Fehler gemeldet werden. Diesen Fehler immer wieder zu melden wäre aber lästig für den Benutzer, und daher müsste man zumindest einmal in die INI-Datei schreiben, dass zukünftig nichts in sie gespeichert werden soll.

Das Problem ist natürlich, dass sich eventuell HxD schon auf einem schreibgeschützten Medium befindet, wenn das passiert. Daher wäre es praktischer, wenn ein Setupprogramm das Kopieren auf ein Medium erledigen würde und eine INI-Schreibgeschützt-Option explizit anbietet.

Ich denke so werde ich es machen, ob in diesem Release oder dem nächsten wird sich noch zeigen.

Zitat:

Zitat von himitsu (Beitrag 1331729)

Werden das mit der Zeit so viele Settings, dass die in ein Unterverzeichnis müssen?

Der Sinn ist dass man gerade bei der portablen Version die EXE-Dateien möglichst sauber und getrennt von all dem Rest hat. Das ist übersichtlicher und erspart einem extra Verknüpfungen zu erzeugen die dann ja doch wieder nur in einem extra Verzeichnis sind (sonst hat man keinen Vorteil bei der Übersicht).
Unter anderem kommen z.B. noch Übersetzungen in ein Lang-Verzeichnis hinzu (momentan 23), daher sollte das alles getrennt sein. Ein Ordner wird auch automatisch anders sortiert als Dateien (immer vor oder nach Dateien, nie gemischt), wodurch es übersichtlicher wird. Ein weiterer Grund ist, dass konzeptionell Einstellungen und Programme nicht im gleichen Verzeichnis sein sollten, wenn man z.B. aus Sicherheitsgründen Rechte einschränken will. Also: es bleibt so :p

Zitat:

Zitat von himitsu (Beitrag 1331729)

Das in der .lang war so viel, dass es nicht in die .ini passte?

Das ist Teil des Systems das sich in das Delphi-Sprachdateiladen einklinkt. Dieser Teil passiert sehr früh im System, und man sollte so wenige Units wie möglich (besonders solche mit Abhängigkeiten) laden, so ähnlich wie bei Memorymanagern. Ist eine Unit dabei die resourcestrings enthält kann man sich nicht mehr einklinken.
Der Grund für diesen Hook ist unter anderem, dass man ein extra Lang-Verzeichnis angeben kann um nicht das Hauptverzeichnis mit Übersetzungen "zuzuspammen".

Wegen dem frühen Systemhook ist es unpraktisch das mit der deutlich komplexeren Klasse die Einstellungen (in INI, Registry, XML) speichert (und Fehler meldet und damit resourcestrings hat) zu verbinden. Da es sowieso einen Settings-Ordner gibt ist das ja kein Problem ;)

Wie gesagt bisher 23 Sprachen und dann noch die 64- und 32-Bit-Version, irgendwann sieht man nichts mehr. Das soll so gehen: Ordner auf, kurzer Blick, Doppelklick => HxD ist offen. Daher die Ordner.

Zitat:

Zitat von himitsu (Beitrag 1331729)

PS: Das HxD Hex Editor.lang wird schon vor diesem Dialog gespeichert. :shock:

Guter Hinweis.

[mael]

Zitat:

Zitat:

Nicht lesbare Bereiche ausblenden

Wäre schön, wenn man das im Menü Ansicht nochmal hätte. (vielleicht als 2 Menüpunkte, Lesbares einblenden und Nichtlesbares Ausblenden, am Besten aus den selektierten bereich, wenn z.B. mehr als 100 Byte markiert sind)

Eine Funktion um anzugeben was gefaltet und entfaltet werden sollte wäre denkbar, so wie man in Quelltexteditoren auch alle Kommentare/Funktionen usw. auffalten/zufalten kann.

Zitat:

Und ausblenden vielleicht als "ganz weg" und nicht nur zusammengeklappt.

Möchte ich eher nicht. Die Lücken haben einen Sinn und sind vorhanden, da eine Kontinuität zu suggerieren ist mißverständlich. Das ist der Grund warum ich mir überhaupt die Arbeit mit dem Datenfalten gemacht habe: man hat Übersicht und gleichzeitig Korrekheit.

Zitat:

Suchen nur in angezeigten/aufgeklappten Bereichen.

Er sucht sowieso nur in lesbaren Bereichen, oder wenn man möchte/es angibt, in der Auswahl (und schließt dabei selbstverständlich nicht lesbare Bereiche automatisch aus).

Zitat:

Zitat von himitsu (Beitrag 1331729)

Es gibt auch "Sparse-Files", bei denen Teile der Datei nicht "real" auf der Platte existieren. (ReadFile liest da immer nur Nullen aus)
Prinzipiell vergleichbar mit den "nichtlesbaren" RAM-Bereichen.

Sparsedateien sind nur eine Art Speicher zu sparen, aber es *soll* als Speicher mit 0-Werten gedeutet werden. RAM-Bereiche die nicht lesbar sind haben keine Daten zugewiesen, weder 0 noch sonst einen Wert.
Man könnte natürlich Sektionen/faltbare Bereiche einführen, wofür das nützlich sein soll frage ich mich allerdings.

Zitat:

Zitat von himitsu (Beitrag 1331729)

Beim Ändern von Bytes in PAGE_EXECUTE* ein FlushInstructionCache ausführen?

Gute Idee.

Zitat:

Zitat von himitsu (Beitrag 1331729)

Strg+Runter/Hoch > springe zum nächsten/vorherrigen Bereich
Strg+Shift+Runter/Hoch > markiere bis zum Ende/Anfang des Bereichs (bzw. wenn schon am Anfang/Ende, dann den ganzen nächsten Bereich)

Gute Idee. Sollte zusammen mit einer Navigationsleiste implementiert werden, wie beim Diskeditor.

Zitat:

Zitat von himitsu (Beitrag 1331729)

Du bist also jetzt fertig und hast die nächsten Jahrzehnte nix mehr zu tun? :stupid:

Wieso? Was du bis hierher vorgeschlagen hast reicht doch schon dafür :p.

Zitat:

Zitat von himitsu (Beitrag 1331729)

Hätte ich mir schon immer was zur Prozessanzeige (RAM) gewünscht.

Inwiefern?

Zitat:

Zitat von himitsu (Beitrag 1331729)

Was zuerst gut wäre: Ein DUMP, also 'nen Snapshot des RAM speichern und später wieder laden, samt der Metainformationen.

Sicher sinnvoll. Aber da das Aufwand bedeutet, warum brauchst du das? HxD ist ja kein Debugger.

Zitat:

Zitat von himitsu (Beitrag 1331729)

HDD-Abbilder werden auch mit Metainfos gespeichert? (Größe der Sektoren, Name der Platte/Partition usw.)

Anwendungsszenario? Gibt Massen an Features die warten, auch eine Menge eigener Ideen die mal weg von elementaren Features gehen (was sehr lange dauert und nicht so sichtbar ist) und sich mehr auf Analyse und Datenstruktur konzentrieren. Daher muss ich Prioritäten setzen und es braucht schon gute Gründe für solche Features. Das kann schnell im Aufwand wachsen wenn man alle Arten von Medien betrachtet und vorallem kompatibel bleiben will und das nicht nur auflisten will.

Zitat:

Zitat von himitsu (Beitrag 1331729)

Dann vielleicht noch ein bissl Farbe und Trennung in die Anzeige?

• Trennlinie zwischen die Bereiche
• nichtlesbare Bereiche gräulich hinterlegt

Stimmt, gerade Bereiche im gefalteten Zustand kann man nicht als lesbar/unlesbar einordnen. Eine Farbe oder eine andere Art der Hervorhebung oder Tooltip mit Eigenschaften wäre eine Idee. Oder vielleicht direkt Text in der gefalteten Darstellung, also mehr also nur der Adressbereich.
Trennlinie? Mal sehen, wird ja schon durch diese +/-Buttons getrennt.

Zitat:

Zitat von himitsu (Beitrag 1331729)

Aber voll geil wären Metainfos zu den einzelnen RAM-Bereichen (da helfe ich auch gern)
Bzw. die Sektoren bei Festplatten/Dateien "Sektor 2 (Byte 00020000 bis 0002FFFF)"

Du meinst die entsprechenden Dateisysten-Cluster/Sektoren einer Datei? Ist geplant. Passt in die ganzen Struktur- und Analyseziele die ich habe.

Zitat:

Zitat von himitsu (Beitrag 1331729)

• angefangen mit VirtualQueryEx
  • MEM_COMMIT MEM_RESERVE MEM_FREE MEM_PRIVATE MEM_MAPPED (kann man schön farblich machen ... abgesehn von FREE besser nur als Streifen am Rand)
  • EXE und DLL sind oft als MEM_MAPPED+PAGE_EXECUTE_WRITECOPY in den RAM gemappt

So eine Art Übersichtskarte? Gibt es verschiedene Visualisierungsmöglichkeiten, Treemaps ganz allgemein, aber nicht nur Farben, sondern auch Strukturanzeige (bin kein Freund von tausend Farben, dann sieht man nichts mehr, aber das kann ja dann jeder einstellen, gibt ja Optionen ;).
Ist ganz allgemein eine Idee um Struktur in jeder Art von Datenstrom darzustellen. Speicherbereiche im RAM-Editor wären eine Anwendungsmöglichkeit. Passt also grob in meine Ziele, am Anfang wird es aber wohl eher eine Liste sein.

Zitat:

Zitat von himitsu (Beitrag 1331729)

Kann man hier irgendwie rausfinden, ob Bytes einer geladenen EXE/DLL "manipuliert" sind?

Soweit ich weiß nur ob aber nicht wo genau, außer man verwendet Datenhaltepunkte (die man in begrenzter Anzahl verwenden kann), oder verwendet Guard-Pages oder ähnliches. Also höchstens Page-Granularität. Aber das zu machen könnte den Prozess verwirren, da viele Guard-Pages und Co. für Prüfungen von Stacküberläufen verwenden.
Wenn es einfach machbar ist, dann vielleicht, aber momentan hat das keine größere Priorität. Das geht schon in Richtung Debugger mit all dem verbundenen Aufwand.

Zitat:

Zitat von himitsu (Beitrag 1331729)

ModulName (EXE, DLL, Named-MMF)

Ja, wäre bei so einem Prozess-Info-Feature mit dabei.

Zitat:

Zitat von himitsu (Beitrag 1331729)

wenn man ganz hart drauf ist, kann man auch die PE-Header auslesen und bei EXE/DLL die Sektionen der Module/Dateien mit anzeigen

Meinst du CODE,.text,.reloc und solche Sections?

Zitat:

Zitat von himitsu (Beitrag 1331729)

[*] TImageFileHeader TImageOptionalHeader TImageSectionHeader TImageExportDirectory TImageDataDirectory uvm. (Windows.pas)[*] Start-/Einsprungadresse, #CODE-Section, #DATA-Section, Resource-Section, Sprung-Tabellen der importierten DLL-Funktionen, ...[/LIST][*] und die ganz harten, würden dann noch die Debuginfos suchen und Code-Adressen der einzelnen Funktionen/Bezehle suchen[/LIST]

PE-Datei-Strukturanalyse war sogar einer der wesentlichen Gründe HxD anzufangen.

Zitat:

Zitat von himitsu (Beitrag 1331729)

man wird bestimmt auch irgendwie die Stacks aller Trhreads suchen/markieren können

Bestimmt, aber das werde ich eher nicht machen. Absolute Debuggerfunktionalität.

Zitat:

Zitat von himitsu (Beitrag 1331729)

[*] Speicher manipulieren (erweitert)

• VirtualProtectEx, VirtualAllocEx, VirtualFreeEx
• PAGE_EXECUTE PAGE_EXECUTE_READ PAGE_EXECUTE_READWRITE PAGE_EXECUTE_WRITECOPY PAGE_GUARD PAGE_NOCACHE

[/LIST]

Auch eine Idee, hat aber eine Menge Einflüsse auf das Programm. Mal schauen.

Zitat:

Zitat von himitsu (Beitrag 1331729)

Wenn man diese Metainfos hat, dann könnte man das "Nicht lesbare Bereiche ausblenden" bestimmt nützlich noch erweitern. :D

• zeige nur Module (EXE/DLL) an
• zeige nur veränderte Module (EXE/DLL) an
• zeige nur "RAM" an (ohne Modul-Abbilder und MMFs)

Ja, eine Funktion um nur die entsprechenden Bereich einzublenden wäre denkbar, so ähnlich wie oben mit dem Falten erwähnt.


War dein Post unter dem Motto: "Mal schnell alle Wünche posten bevor ich nicht mehr darf?" haha

Einige davon werde ich umsetzen, aber ich habe auch viele eigene Ziele und Wünsche, und die werde ich im Gegensatz zu früher priorisieren, sonst macht es keinen Spass und artet in unbezahlten Stress aus. Aber ich schätze dein Interesse und werde sehen was sich mit meinem überschneidet und dann Entsprechendes implementieren.

Es sind einige schöne Sachen geplant, auch bestimmt unerwartete für übliche Hexeditoren :)

[Neutral General]

Zitat:

Zitat von mael (Beitrag 1332007)

Es sind einige schöne Sachen geplant, auch bestimmt unerwartete für übliche Hexeditoren :)

Verrätst du auch was geplant ist? :P

[himitsu]

Bildbearbeitung, Ressourceneditor, ein versteckter Flipper und 'nen übelst realistischer Flugsimmulator, als Easteregg versteckt.

http://www.alpha-flying-india.de/flu...gates-learjet/
http://www.alpha-flying-india.de/flu...or-3-0-teil-1/
https://en.wikipedia.org/wiki/Histor..._and_TRS-80.29

[Delphi-Laie]

Zitat:

Zitat von mael (Beitrag 1332007)

War dein Post unter dem Motto: "Mal schnell alle Wünche posten bevor ich nicht mehr darf?" haha

Einige davon werde ich umsetzen, aber ich habe auch viele eigene Ziele und Wünsche, und die werde ich im Gegensatz zu früher priorisieren, sonst macht es keinen Spass und artet in unbezahlten Stress aus.

Richtig! Nur so hält man ein Freewareprojekt durch.

Insofern bin ich froh, Freizeitprogrammierer zu sein. Ich hätte keine Lust, Sachen zu programmieren, die mich nicht interssieren. Na gut, das Geld, was man für kommerzielle Tätigkeit bekommt, ist auch nicht zu verachten und interessant...

[mael]

Zitat:

Zitat von himitsu (Beitrag 1332082)

Bildbearbeitung, Ressourceneditor, ein versteckter Flipper und 'nen übelst realistischer Flugsimmulator, als Easteregg versteckt.

http://www.alpha-flying-india.de/flu...gates-learjet/
http://www.alpha-flying-india.de/flu...or-3-0-teil-1/
https://en.wikipedia.org/wiki/Histor..._and_TRS-80.29

Was hältst du von der INI-Datei-Lösung und dem Setup?

Zitat:

Zitat von Neutral General (Beitrag 1332009)

Zitat:

Zitat von mael (Beitrag 1332007)

Es sind einige schöne Sachen geplant, auch bestimmt unerwartete für übliche Hexeditoren :)

Verrätst du auch was geplant ist? :P

Ganz allgemein strukturelle Analysen und Verstehen, etwas Geheimnis muss sein ;)

Zitat:

Zitat von Delphi-Laie (Beitrag 1332109)

Richtig! Nur so hält man ein Freewareprojekt durch.

:)

[mael]

---

[Neutral General]

Hallo,

Vielleicht hab ich ein falsche Vorstellungen aber kann das sein, dass HxD (2.0.0.0 beta, 64 Bit) mir bei der Suche in einer 1 GB Datei eines 5-Zeichen langen Strings eine Restdauer von 320 Stunden (und es steigt weiter) anzeigt? Läuft da was falsch oder unterschätze ich den Aufwand eine 5-Byte-Sequenz in 1GB Daten zu finden?

[isilive]

Da läuft sicher was falsch IMHO.

Der Aufwand einen String zu suchen sollte nicht wesentlich höher sein, als der Aufwand ein Byte zu suchen. Stimmt das erste Zeichen überein vergleicht man weiter - ok das kostet ein bissl Zeit, aber nicht bemerkenswert viel.

Ich kann jetzt grad keinen Testrun schreiben, aber ich würde mit einer Zeit deutlich unter 1 Minute rechnen. (Auf einem Durchschnittsrechner, die Datei hat im RAM Platz und wird nicht von Diskette geladen ;)

Edit:
Hab eine Datei mit 1.1GB aufgemacht in HxD 1.7.7.0
Die Suche nach einem 5 Zeichen String dauert 10 Sekunden.
Nach 5 Bytes gehts noch schneller.
(edit: ich habe einen Standardrechner mit einer AMD Phenom II CPU)

D.h. bei dir funktioniert da was nicht wie es soll.

[Neutral General]

Die Datei befindet sich auf einer HDD, CPU: i7, 8 Kerne @2,8GHz und 16GB Arbeitsspeicher (10GB aktuell belegt)

[mael]

Hmm, habe keine Benachrichtigunsmail bekommen, daher jetzt erst die Antwort.

Ich habe es gerade mit meiner aktuellen Version getestet, und konnte das nicht reproduzieren.

Ist die Datei in Benutzung (offen in anderen Programmen, oder wird sie vielleicht sonstwie beschrieben, gesichert oder ähnliches?)?

Die aktuelle Version gibt es hier:
http://mh-nexus.de/downloads/HxDSetup.zip

[mael]

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

[Hobbycoder]

Ich hätte da auch mal eine Idee. Gerade wenn man in den Speicher schaut oder eine typisierte Datei, wär es vlt. nützlich eine Klassenstruktur hervorheben oder durchblättern zu könnten. Und richtig cool, wenn man die dann gleich aus der PAS-Datei laden kann.

Die Idee kam mir grade. Wenn's schon geht, hab ich nix gesagt. Vielleicht ist das auch Quatsch, aber so rein theoretisch stell ich mir das für den einen oder anderen Anwendungsfall ganz praktisch vor.

Gruß Hobbycoder