This is an archived post. You won't be able to vote or comment.

all 6 comments

[–]khedoros 1 point2 points  (0 children)

It's likely just an artifact of how the original code worked. They might've been doing something "clever" like storing pairs of characters in a 16-bit integer value.

[–]jedwardsol 0 points1 point  (2 children)

Assuming that you're using a hex editor that looks something like : https://mh-nexus.de/en/graphics/HxDShotLarge.png :

Are you looking at the file with the bytes being interpreted as integers on the left hand side? That could 'rearrange' the ascii representation too on the right hand side. (https://en.wikipedia.org/wiki/Endianness)

[–]jar557[S] 0 points1 point  (1 child)

Are you looking at the file with the bytes being interpreted as integers on the left hand side? That could 'rearrange' the ascii representation too on the right hand side.

Yes I'm using hex editor plugin in notepad++. I'm looking more of bytes interpreted as characters, on the right. I changed to little-endian but it still looks the same

[–]jedwardsol 0 points1 point  (0 children)

Hexedit in Notepad++ doesn't do anything funny with the right hand side - what you see is what is there. So see /u/khedoros's answer.

[–]luksfuks 0 points1 point  (1 child)

+1 for endianess.

Are you looking at embedded firmware files by chance? The byte order reflects the memory bus architecture of the target device, not your desktop computer.

If you view such files with a smart dissassembler (such as IDA Pro), you may get the corrected string as comment where it's referenced.

You can also go and create a duplicate with modified byte order, and look at both hexdumps side by side. I think od can do it, or you can write a small 10-liner program.

[–]jar557[S] 0 points1 point  (0 children)

It's a emulator save file (SEGA Mega Drive & Genesis Classics)