Delphi-PRAXiS
Seite 35 von 41   « Erste     25333435 3637     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Software-Projekte der Mitglieder (https://www.delphipraxis.net/26-software-projekte-der-mitglieder/)
-   -   HxD - schneller Hexeditor, Disk-Editor und RAM-Editor (https://www.delphipraxis.net/39594-hxd-schneller-hexeditor-disk-editor-und-ram-editor.html)

mael 29. Feb 2016 14:28

HxD 2.0 Beta ist da!
 
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 29. Feb 2016 14:59

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor
 
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 29. Feb 2016 16:43

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor
 
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 29. Feb 2016 19:24

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor
 
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 29. Feb 2016 19:52

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor
 
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 1. Mär 2016 13:50

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor
 
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 1. Mär 2016 14:21

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor
 
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 3. Mär 2016 19:08

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor
 
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 3. Mär 2016 20:37

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor
 
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 3. Mär 2016 22:12

AW: HxD - schneller Hexeditor, Disk-Editor und RAM-Editor
 
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


Alle Zeitangaben in WEZ +1. Es ist jetzt 03:00 Uhr.
Seite 35 von 41   « Erste     25333435 3637     Letzte »    

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz