3 ms·
A binary file on disk is just a file, like any other file, and you may read and hex-dump it, like any other. (Probably, your text editor has this built in.) And
by masswerk 9y ago
A binary file on disk is just a file, like any other file, and you may read and hex-dump it, like any other. (Probably, your text editor has this built in.) And, of course, you may alter a file, either by overwriting part of it (using open, seek, write, close) or writing a modified version of it back to disk.
If we open a file in a hex-editor, we may locate an embedded string, like this:
0180: 54 68 69 73 20 69 73 20 61 20 73 74 72 69 6E 67 00 This is a string.
Now we may obviously change some of the string, and even shorten it, by filling the rest by zero-bytes:
0180: 54 68 69 73 20 69 73 20 61 20 70 65 74 00 00 00 00 This is a pet....
The interesting thing about this is that we may change the content, but have to maintain the original length and order of the code, else the binary won't work any more. I guess, padding, like this, is what gives the editing away -- at least at the level of arguments and embedded data. (However, if there were some hash signatures checked by the runtime, we will run into some trouble with our edit.)
Just the same, we may edit any instruction code. Let's say, your hex-editor has a built-in disassembler module, displaying mnemonics next to the byte code, just like the ASCII text in the string example. Even while some of the code may be encrypted, there must be some top-level code which isn't, and we should be able to discern this from any obfuscated code. Now, say, we want to skip a call to a subroutine or module, by overwriting the call instruction by a few bytes representing a jump instruction to skip ahead. Notably, again, we'll have to maintain the overall length and byte order, leaving behind some unused bytes as a signature of this being edited code.
Historical note: Classic MacOS (up to System 9) used a separate resource fork for any content embedded in files and executables. There was also a free tool by Apple, ResEdit, for displaying and editing the various resources and so-called res-hacks were not uncommon. (E.g., you may have accessed the resource providing the label for a menu item and replace it by your own, etc. This worked generally great with most of the programs, while some rather expensive software obviously applied some checks, prohibiting edited versions from working.) There was also a disassembler module for ResEdit, allowing code edits like described above.
- icebraining 9y agoRe: ResEdit - EXE files also have resource records, there's even a tool by the same name for Windows :)