At any rate in general it just means that the binary version is directly modified instead of, say, modifying the source and recompiling it. When the source is not available you don't really have a choice.
It doesn't mean however that you'll just open a big binary dump of the program in emacs and start flipping bits manually. In general you'll first disassemble the code to figure out what it does, isolate the part that you want to modify, implement the modification and then you end up with a binary patch.
That's easier said than done though, reverse engineering a complex binary is very time consuming.
It reminded me of this anecdote: https://en.wikipedia.org/wiki/Wing_Commander_%28video_game%2...
>As development for Wing Commander came to a close, the EMM386 memory manager the game used would give an exception when the user exited the game. It would print out a message similar to "EMM386 Memory manager error..." with additional information. The team could not isolate and fix the error and they needed to ship it as soon as possible. As a work-around, one of the game's programmers, Ken Demarest III, hex-edited the memory manager so it displayed a different message. Instead of the error message, it printed "Thank you for playing Wing Commander."
And still ppl who crack games do it very often. They start with a obfuscated binary, decrypt it and patch it to remove the protection.
Very different from trying to figure out everything a program does.
Surely this is easier then a full understanding of the code?
CPUs have a fixed instruction set. Add, subtract, increment by 1, and so on. These instructions in turn are represented in machine language as a binary string, which represents signals that get sent to the CPU's processing center, the ALU (Arithmetic Logic Unit). The ALU has a number of input ports, with each one corresponding to a different fundamental operation.
There are a number of programs capable of taking an executable and providing a step-by-step breakdown in machine language (which makes sense intuitively because the machine has to do this for itself anyway in order to execute the program). So once you have the machine language instructions, you then study it to see what different sets of instructions are doing. This is made somewhat easier by the fact that computers run through instructions linearly (with the exception of jumps, but you also know that jumps represent some sort of logic operating on input, so those are informative as well).
Although this would take forever to do manually, there are programs that aid in breaking machine language into easier-to-understand chunks, like IDA.
Anyway, once you understand what different chunks of instructions are doing, then you can decide how you want to alter the program. You can use a hex editor for the actual editing (I assume professionals use something different, but some game modders use hex editors), which simply lets you change the individual bits on your drive (if this sounds impressive, realize that every time you save a file or something, that's what's going on at a large scale).
If you want a gentle, newbie-friendly introduction to CPUs which will make a lot of this stuff click better, I highly recommend the NAND to Tetris course, which has a video series on Coursera: https://www.coursera.org/learn/build-a-computer
There's probably a way to try it with tools you already know. Know vim for example?
cp /bin/grep ./mygrep
vim -b ./mygrep
[find a string to change, like something from the output of ./mygrep -V]
[don't change the length]
[change a few letters]
<esc>: %s/Free Software/Tree Software/g
[save it]
:wq!
[run it]
./mygrep -V
https://en.wikipedia.org/wiki/Hex_dump
Then you need to have an idea of the executable file format so that you can extract information from the respective file sections.
Of course, there are tools that will extract those sections. So manual work only occurs if the tools fail to do their work.
In the case of executables, reverse engineering tools like IDA give an helping hand.
https://www.hex-rays.com/products/ida/
Then it goes from there, with lots of Assembly love and knowledge of OS internals.
Radare is a free disassembler.
Hopper is good a good disassembler for Mac.
IDA is great, but very expensive.
Manual work happens almost always with weird malware and or packers. They almost always do something that makes trivial reversing harder.
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.
https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06...
Gives pretty good insight into what steps go into this kind of work.
To get started reverse engineering, modifying binaries, linking, etc. you need to start with learning x86_64 assembly. There are some pretty good courses and tutorials online. Since there are only a few opcodes that are used frequently, it might help to search for "reverse engineering bomb lab" and go from there. Here is the first search result, maybe it is good, maybe not: http://zpalexander.com/binary-bomb-lab-phase-1/
It can something as simple as changing several bytes using a hex/bin editor or something more involved like disassembling the binary, patching the assembly and then assembling it back.
When I read stuff like "Petya (binary edited)" I feel like a complete noob. Anyone care to elaborate how editing binaries would be done?
Sounds like a daunting task. Even on a normal program. Much more so on malware that is obfuscated to begin with. Just curious :-)