Copy bytes using Groupings

[palmerj]

What feature would you like to see?

Ability to copy bytes (hex) from the editor to the clipboard so they can be pasted using the endian and selected visualizer settings. For example when the hexadecimal (16bit visualizer setting is selected)

31 94 E7 C7 8F 27 14 2A

will be copied as

3194 E7C7 8F27 142A (or vise versa depending on endianness)

How will this feature be useful to you and others?

Useful for copying and pasting into other editors or messages.

Request Type

• [ ] I can provide a PoC for this feature or am willing to work on it myself and submit a PR

Additional context?

No response

[paxcut]

I'm not sure if this is a good idea. What happens if you paste the data on top of itself? Right now regardless of settings the data remains unchanged. Are you proposing that we change the data on pasting because we chose some visualization? Also suppose you choose floats in visualizer. Are you sure that strings with the floats are what should be copied? If you paste them on the data how are you going to paste the float strings on the data?

There are two main issues and a third one that seems unrelated. First is the groupings. It is not a big deal to have to remove spaces to get any grouping you want. Second is byte ordering. If you want to obtain strings that shows the numbers under a a different byte ordering I suggest you use the byte swapper tool which was designed for that purpose. Third is the visualized format. This is only changing how the data is viewed. Copying the data itself makes more sense and lets you paste it as data.

The way I understand it is that, regardless of what visualization you choose, the underlying data does not change. Copying and pasting should reflect this property.

Maybe this feature should be for another entry in the Copy as menu that reads visualized

[WerWolv]

Hey I personally like the idea but I'd probably have it as another option instead of it being the default when switching the visualizer. I'll keep this request around for the next versions.

[palmerj]

@paxcut agreed with your concerns.

Maybe this feature should be for another entry in the Copy as menu that reads visualized

Maybe that's the approach, So copy as visualized.

[palmerj]

Second is byte ordering. If you want to obtain strings that shows the numbers under a a different byte ordering I suggest you use the byte swapper tool which was designed for that purpose.

Thanks for the tip. I tried using this, but feel it could have been more user-friendly. I had to copy and paste the bytes into the tool (maybe there should be a from selection button?). Also, the output pad zeros on the head and tail for some reason when I have more than 8 bytes. Lastly, it produces weird results when an odd number of bytes are entered.

[paxcut]

If 'from selection' you mean the clipboard then just ctrl-v (or equivalent mac shortcut) to paste. Keep in mind that the tool is not meant to be used with the main ImHex hex display only so it can't detect arbitrary selections.

The tool assumes that the number of bytes is even and a multiple of 8. Endian conversions dont occur for arbitrary sized data and those usually are bytes, words, double words, quads and dquads (128 bits), hence the multiples of 8 bytes shown. Any missing data is assumed to be zero and occurring before the input. For example ab01234567 is assumed to be 000000ab01234567 and outputs 67452301ab000000 correctly.

[palmerj]

If 'from selection' you mean the clipboard then just ctrl-v (or equivalent mac shortcut) to paste. Keep in mind that the tool is not meant to be used with the main ImHex hex display only so it can't detect arbitrary selections.

I know I'm being picky, but it's annoying to have to do extra commands. But yeah it works.

The tool assumes that the number of bytes is even and a multiple of 8. Endian conversions dont occur for arbitrary sized data and those usually are bytes, words, double words, quads and dquads (128 bits), hence the multiples of 8 bytes shown. Any missing data is assumed to be zero and occurring before the input. For example ab01234567 is assumed to be 000000ab01234567 and outputs 67452301ab000000 correctly.

I feel like it shouldn't return a result unless there are an even number of bytes in the input. I also wonder if there should be a "treat as" data type options for all of the typical signed/unsigned int and float/double/quad datatypes

[paxcut]

I feel like it shouldn't return a result unless there are an even number of bytes in the input. If The choices are zero pad or display nothing the I think that it is doing the right choice.

I also wonder if there should be a "treat as" data type options for all of the typical signed/unsigned int and float/double/quad datatypes What would that do? we just want to reverse the byte order without really taking into account what the data actually means. For that task we always can use the data inspector.which can also switch between little and big endian.

[palmerj]

What would that do?

This function is helpful if you are coping a stream of bytes with data items longer than the encoded data types. e.g If I paste four bytes but it's two u16 rather than one u32, then I would like to get a different result. Of course, I could copy them one by one, but that could be more user friendly.

For that task we always can use the data inspector.which can also switch between little and big endian.

That's true. I just found the toggling switch between decimal and hex, so that helps me for some use cases - but no the copy and paste out of the software.

[paxcut]

Granted there is no tool in ImHex that would read in an arbitrary number of arbitrary long sets of bytes and write the byte reordered sets out but ImHex is not a ready-to-wear, all-around-Swiss-knife tool that meets everybody's needs (can such a thing even exist?), but what it is is a tool that lets you write such a utility rather easily using the pattern language. PL has functions to grab selections from the main hex window. It can group the bytes of the selection into sets that can be byte swapped to a different endianess. Then open a file for writing and copy the resulting data to it.

If you have lots of files to process use the command line interface that allows ImHex to batch process them all and do the entire process in mere minutes. Don't want to deal with PL? Then write a .net script instead. It doesn't get any user-friendlier than this. Ok, sure it could be if you found (or even better, forced) somebody to do it for you, but for the rest of us lowly humans there's always ImHex.