Page 2 of 2

Re: Suggestion for HxD:User templates for data inspector

Posted: 26 Feb 2021 16:28
by dukk
no questions yet.

You clarify all.

(sorry ALL for my possible bad english)

Re: Suggestion for HxD:User templates for data inspector

Posted: 16 Mar 2021 11:48
by JakeTheDog
Woah, that looks awesome you really put a lot of thought into the design.
Eagerly waiting for the release :D

Re: Suggestion for HxD:User templates for data inspector

Posted: 02 Apr 2021 09:16
by Maël
Add option to specify memory layout of arrays: ... ajor_order

Re: Suggestion for HxD:User templates for data inspector

Posted: 06 Apr 2021 11:39
by Maël
Support ROM images (SNES, N64, Amiga, etc.) with lookup tables for sprites, text tables, levels, etc.

Possibly, but not for an 1.0 release, with the ability to resize data structures, while keeping length and size fields up to date, and adapting memory allocation inside the file accordingly.
A simpler version of this would target PNG files or RIFF/WAVE files, that allow for easier resizing/memory allocation, while still needing a couple length and offset fields updated to stay valid.

From a high level view, resizing structured files is adding a kind of linker capability, since you need to section the file into parts, update offsets, possibly consider alignment issues, and memory allocation/section sizes, but also need to add constraints (that express logical dependencies between fields/parts of the file), such that the file remains valid. This includes updating indeces/lookup tables, length fields, range or size constraints but also checksums.

Editing resource sections in PE files is the "light" version of this, editing anything inside a PE file is the more complete/complex version, since program code might be dependent on this as well. Without additional "debugging" or "compiler/linking" information this might be difficult, since pointers in assembly code might need to be updated as well (and disassembling in general is not feasible without human assistance). In PE files there is a notion of relocations, but they can be stripped, or not available for other file types, like ROMs.

So it might be that files can be partially edited, with some sections remaining read-only (and just be moveable as entire sections, but besides changing the starting offset, remain unchanged), while others can be edited in fine grained detail, like resource sections (that were designed to be edited, independent of other parts of a PE file -- besides indices close to the PE header).