2

Someone told me that viewing a binary file of a program, or similar, in a hex editor exposes the entire sum of data/instructions a program has. For example, like in game hackers/modders of old retro games, like Sonic The Hedgehog, the binary executable is half a megabyte (approximately).

That means that the file has just a scotch over 520,000 bytes in it, and, going by the encoding used by the compiler/assembled used to get executable code for the Sega Genesis (Motorola 68000 binary opcodes), you can go byte-by-byte in a hex file and edit the values of data/instruction encoding used in the game(e.g. checksum, magic number data, JUMP/MOVE instructions & offsets, DATA entries like lives, etc.)?

Is this correct 100%, or is there some falsehood?

2
  • 2
    tl;dr: yes, except when the code was written to modify itself. Dec 14, 2013 at 22:06
  • The binary executable is half a megabyte. That means that the file has just a scotch [sic] over 520,000 bytes in it. Yes, two fingers (4,288) more.
    – Synetech
    Dec 27, 2013 at 5:03

1 Answer 1

1

Your hard disk is just a device that can hold bytes. At the hardware level there's no concept of files or even partitions, just bytes[1].

Now we're introducing a concept of partitions (check out the Introduction here if you want to know why). There's a partition table which is also a bunch of bytes. They don't make sense unless you know how to interpret them. All modern operating systems use MS-DOS compatible partition tables[2], so they can recognise each other's partitions. Still, you can just pretend there are no partitions but only bytes. That's what hard disk holds.

Each partition has to be formatted to some filesystem that describes how files are saved. Modern versions of Windows use NTFS filesystem, older ones were based on FAT family (FAT12, FAT16, FAT32) and consumer-grade Linux setups are usually using ext family (ext2, ext3, ext4). Filesystem decides how files are laid out on the partition and where the "table of contents" is (and how to interpret it). Again, it's all just bytes unless you know how to interpret them.

Files can have additional metadata (name, path, creation date, last access date etc.) Filesystem states how the metadata should be stored and how you can find file boundaries, but not how to interpret file contents. You have to find out what's the file format (hint: look at the file extensions or magic numbers!). Until you know the format, it's just a bunch of bytes.

My point is that there's no deeper magic behind file storage. There are many levels of abstraction involved here, but if the computer can access the drive at any of them, then it can also let you view or edit data on that level of abstraction!

Programs like Paint or Word operate on the highest level of abstraction, they interpret the file data according to the format. But hex editors don't interpret data at all, they stop at the file level and present you with raw bytes in hexadecimal format (that's the most user-friendly format you can get at this level). Interpreting any file = interpreting its bytes. That's how executables are executed, text files read or pictures displayed. When CPU is executing an application, it sees exactly the same data a hex editor will present to you. When you're opening a JPEG, the picture viewer is reading the same data that hex editors show!

It sounds like you're interested in reverse engineering. There are some tools (debuggers, decompilers, disassemblers) that make this process less painful. Working with bytecode is hard, especially when you're dealing with CPUs that use variable-length instructions (I'm looking at you, Intel!)


[1] Not really, but let's assume that for the sake of simplicity. If you're interested in details, then old drives have used CHS scheme that was later superseded by LBA.

[2] ...or modern GPTs that work nice with UEFI, but again, it's not that important, let's just skip them. Oh, and MS-DOS tables are more commonly referred to as MBR partition tables.

1
  • Strictly speaking, the CPU doesn't see exactly the same bytes as are seen in the program image file through a hex viewer. Program loaders perform relocations and load-time dynamic linking. And some executable file formats (such as Linear Executable) have compression capability and the ability to entirely leave out zero-fill pages from the program image. This doesn't change the gist of this answer, though. However, what does change it is that you've overlooked resource forks. The questioner did ask about editing program data, and hex viewers usually show data forks by default.
    – JdeBP
    Dec 15, 2013 at 3:42

You must log in to answer this question.