Why no byte offsets on ly HEX?

[Uzver123]

Every hex editor i used in the past offers to use byte offset when Ctrl+G (go to) and when copy address you can quickly convert HEX offset to bytes but in imHex it only allows to copy address as hex and use hex offset for Ctrl+G its so inconvenient. Why not make selection to allow user use byte or hex.

Funny thing is in data processor input is expecting binary offset and you only offer to copy HEX offset.

[paxcut]

do you mean decimal when you say byte? What is binary offset? for number systems binary is 0's and 1's and I don't think thats what the data processor expects. goto lets you type decimal values as numbers or hexadecimal numbers by writing 0x prefix. For converting decimal to hex or vice-versa there is the calculator in the tools that I think should do that but I havent checked.

[paxcut]

To copy the offset right click on the byte located at the offset and select Copy As>Address. That will give you the offset at which the byte is located.

[Uzver123]

However this offset Copy As>Address will give offset as HEX not binary/decimal format, and i want to be able to copy binary offset.

[paxcut]

I think that what you are really asking to have implemented in ImHex is the ability to display the offsets (AKA addresses, that is, the top row that usually shows 00 to 15 and the column of values to the left of the data that corresponds to the offset of the first byte in the row) as decimal numbers (or even as octal). The reason I say this is because the only way to copy offsets as decimal numbers in all hex editors I tried is to first change the usual hexadecimal offset display to decimal so that when the offset is copied the copied value is in decimal.

[Uzver123]

Could simply make another option for right click Copy As > Address as HEX and Copy As > Address as Bytes.

Or can select it here, just add option to switch between hex and bytes (decimal) offset. it can be copied from there very easy select with double click and Ctrl+C

[ebergerly]

I totally agree with the suggestion. I am reading an entire binary file into an array of bytes (byte[]) in my software. I want to select a byte in ImHex and have it tell me the index of the selected byte in the file AS AN INTEGER, not as hex or as a "decimal". That way I can say "this value shown in ImHex starts at array index X in my byte[]". As shown in the image above it displays the index as a hex value on the bottom left of the Hex Editor, so why can't it do a simple conversion and display the equivalent INTEGER value? Instead I have to use the Windows Calculator in Programmer mode to do that simple conversion. I don't understand the references to "decimal". An array index is an integer, not a decimal. By the way, I also tried using the Data Processor to do this, and added a "Selected Region" node and wired it to an "Integer Display" node, hoping it would grab the hex address and convert to integer. Instead it just gives the hex version.

[paxcut]

Decimal stands for the case when the base of the number system used in the number representation is 10 (deca in Latin) Hexadecimal is for base 16, binary for base 2, octal for base 8, etc.... So when you say you want to display the offset as an integer you really mean as a decimal number because regardless of their representation the numbers 0x10, 16, 0b10000 and O20 are all integers representing the same number (the decimal 16)

If ImHex was able to display the offsets in bases other than 16, which is already possible for the values of the input file, then you wouldn't need any conversions because when decimal notation is chosen for the offset then all values displayed for the offset (as in the values displayed in the selection information display) would be displayed in decimal as well which is less confusing than showing the offset in hex and displaying the selection offset in decimal and also is the way other hex editors work.

[ebergerly]

And here's a simple example. I select a byte in ImHex, the hex version of its "index" in the file is shown on the bottom left ("B5"), and I have to use the Windows Calculator to convert that to an equivalent integer index so I can locate it in my byte[].

[paxcut]

I'll repeat again, if the numbers could be selected to be displayed as decimal numbers (aka "integers" in the software developer world) then you wouldn't need to do any conversion.

[ebergerly]

So it sounds like you are merely making distinctions in terminology, while I'm trying to support a suggestion that ImHex add a minor feature to convert the hex display of byte addresses to decimal or integer or whatever you want to call it. Or do you know of an existing way in ImHex that I'm missing?

[paxcut]

I am merely suggesting a way for imhex to be able to do exactly what you want. I have been doing that since this post:

 think that what you are really asking to have implemented in ImHex is the ability to display the offsets (AKA addresses, that is, the top row that usually shows 00 to 15 and the column of values to the left of the data that corresponds to the offset of the first byte in the row) as decimal numbers (or even as octal). The reason I say this is because the only way to copy offsets as decimal numbers in all hex editors I tried is to first change the usual hexadecimal offset display to decimal so that when the offset is copied the copied value is in decimal.

[ebergerly]

In C# it's one line of code to convert from a hex string to an integer.

[WerWolv]

The easiest way to solve this is probably using a custom data inspector row. You can read up on that here: https://docs.werwolv.net/imhex/views/data-inspector#adding-new-rows

Something like u64 currOffset = $ [[name("Current Offset"), export]]; should work I think.

[ebergerly]

Thanks, but what I don't understand is why this: I assume most people who are using a hex editor like ImHex for reverse engineering & decoding binary files are doing it so they can write a piece of software that reads the binary file and parses it and accesses the data however they want. And to do this they would likely read the file into a byte[], then access various elements of the array that held the data they wanted to extract and parse. Which means it's crucial to be able to find the equivalent array index for any byte they looked at in ImHex. What am I missing?

[ebergerly]

By the way, this got me thinking...it might be easier for me to write a custom binary file decoder in C#, where I just read the file into a byte[] and convert those bytes into whatever format I want and display them in a simple textbox. Most of these conversions are just one line of code in C#.

[WerWolv]

Personally I never had to do something like that myself but that's why ImHex allows you to add new things on your own. I obviously can't think of all the possible usecases people might need :)
I'm not saying ImHex shouldn't be able to display things in decimal, just that it's not possible right now

[ebergerly]

Okay here's my initial C# binary file decoder, which displays the hex value of each byte (similar to ImHex) with a ":", and then the array index as an integer. A separate textbox has the ASCII version. Certainly needs some cleanup, but like I say only one line of code for the conversions.

[paxcut]

Here is another way. Select the region up to the offset and read the value where shown

[ebergerly]

That doesn't tell you the INDEX of the last value selected, it tells you the number of bytes selected, which is a value greater than the index (since the first value selected is index 0).

[paxcut]

Just like WerWolv suggested I was able to add one line to the data inspector to print the offset of the selection in decimal and it took one minute tops.

[paxcut]

To do this, add the following line to a file with extension .hexpat in %appdata%\..\local\imhex\scripts\inspectors

struct MyCustomInspector {} [[format_read("custom_inspector_formatter")]];

fn custom_inspector_formatter(MyCustomInspector customInspector) {
	return std::format("{}",$);
};

MyCustomInspector customInspector @ $ [[name("Current Offset")]];

[ebergerly]

Glad that works for you, but I've decided to finish my own custom C# app that makes the whole process of converting from binary files to byte[]'s and then parsing them a whole lot easier. I'll drag-select some bytes, decide if they're ASCII strings or doubles or int's, etc., and automatically assign those types to those bytes, and it will save those designations in a text file so whatever app I'm developing can access the conversion data for that type of binary file via the text file. And I'll probably also convert the binary file to a CSV where appropriate.

[paxcut]

No, not for me as I can read hex numbers so I dont need a decimal converter. I wrote it so that people that come here looking for solutions pertaining this feedback discussion about ImHex have a couple of ways to obtain decimal offsets that they may use. This discussion has as title "Why no byte offsets in Iy Hex?" which probably really mean "why no decimal offsets in ImHex?". The answer is that right now it is not possible, but there are ways to obtain something like it in ImHex using almost no effort.

[ebergerly]

In case anyone is interested in writing their own code in C# to do some custom decoding, what I did is first read the entire binary file into a byte[], then step thru that array and take groups of 16 bytes, convert each to a hex string and put them in a string[16], then add each array to a List<string[]> until the end of the file. I then convert that List<string[]> into a DataTable, and use that as the source for a DataGridView. Then do a "CellMouseClick" event for when any cell is clicked, and get (16 * RowIndex + ColumnIndex) and that gives you the array index of the selected cell. You don't even need to convert from hex to int/decimal, just use the row and column indices supplied by the event arguments. Now I just need to add a Data Inspector-type textbox and convert to the values I care about and that's it.

[WerWolv]

Don't exactly know what you gained by redoing the whole thing from scratch now but glad you got it working

[ebergerly]

What I gained is that I'm writing a C# application that loads a binary file where I don't have any info on the file format, other than it has some header data plus some time, value data for plotting results from an engineering simulation software. When I see, for example, in ImHex there are some ASCII strings, I need to determine where those characters are in the byte[] (ie, what indices) so I can process them in my application as strings. And when I select the last 4 bytes and see that they get converted into an expected float value, I need to know the indices so my app can convert those bytes into a float.

And my plan is to, with the application I'm developing, when I select some bytes and figure out they represent an expected value I'll press a button and store the indices and the type in a text file so anytime I work with similar files I'll have a record of which bytes are which data type. And if somebody asks me "hey, how do I decode these types of binary files?" I can give them the text file showing indices and data types. Easy.

[ebergerly]

And here's an example of where I hope to be when this is done. It automatically prints a CSV file describing the starting indices and lengths of all the variables and their types, as well as a descriptive name. To me, that is what reverse engineering and decoding of binary files is all about.

[WerWolv]

If you have suggestions for what ImHex is missing right now, let me know. Otherwise the thing you're doing right now can mostly be done throught the find view. E.g finding strings that match a certain regex or floating point numbers in a certain range. Exporting is possible as well but not in the exact format you have here.

[Uzver123]

To do this, add the following line to a file with extension .hexpat in %appdata%\..\local\imhex\scripts\inspectors

I created file D:\Portable\imHex\scripts\inspectors\.hexpat and put code you suggested, however binary offset field does not appear in data type.

[paxcut]

two things:

1. create a file with .hexpat as extension but don't leave the name empty. for example use myInspector.hexpat
2. You need to make a selection in the input file for the offset to be displayed. You don't need to restart ImHex if you make changes,but you need to redo the selection to update new content added to the inspectors folder.

Also note that this adds an entry in the data inspector window. If this window is not opened select it from the views menu to open it.

[Uzver123]

Okay created file D:\Portable\imHex\scripts\inspectors\byteoffset.hexpat

Conents:

struct MyCustomInspector {} [[format_read("custom_inspector_formatter")]];

fn custom_inspector_formatter(MyCustomInspector customInspector) {
	return std::format("{}",$);
};

MyCustomInspector customInspector @ $ [[name("Current Offset")]];

Result in data inspector.
Runtime error cant call unknown function 'std::format' try defining first.

[paxcut]

Sorry about that I forgot to add the import statement that defines the format function. Add

import std.string;

At the top of byteoffset.hexpat and it should work.

[Uzver123]

select some bytes, decide if they're ASCII strings or doubles or int's, etc.,

Could you share code how exactly you determine each data type?