Opening .exe in notepad and saving it back to .exe

Quote:

and that's not my code's problem since I checked whole thing using notepad too

That just shows that neither Notepad nor your program saved the contents correctly. For Notepad that doesn't come as a surprise as it specialized to edit text files. Notepad wants to see a file as line that are separated by <cr> <lf>. And it probably tries to save some of the contents just like that.

Why your program did not succeed is hard to guess without seeing the source code. If you'd amend your question (use the green Improve question button below your original question) I'd be willing to take a look at it.

As phil.o already pointed out, you are trying to re-invent a binary editor (sometimes named also hex editor). There are several good hex editors around that you could download for free and that would probably get you there faster.

The other answers tell you pretty clearly that you can't (or shouldn't) do that, but don't really explain why, here it is:

When an application is compiled, there are static references to parts of the executable, calculated as offset in bytes. These can be as broad as the .text and .data sections of the executable, or more low-level like function call addresses and jumps.

You should open an exe in a real disassembler once to figure out why you can't just add data to an executable and tell it to run. You'll see that there are hard coded jumps in bytes, function addresses in bytes, etc. When you add data, these jumps make the processor start running random code, which causes an exception. In your case I think you are editing something in the header that causes Windows to believe its not a valid executable anymore.

It doesn't work with notepad, you can try to find other tools,eg UltraEdit.

Long ago under DOS I've used the builtin text editor of Volkov Commander to open (F4) smaller executables to overwrite some bytecodes. That is the only editor I know to correctly keep the contents of binary files. All other text editors handle some of the characters as special chars and they either skip it or screw up something by trying to interpret the binary data as a piece of encoded text.

These days on windows I use HxD for binary editing of files/memory/disk. It's a free superb tool, also supports inserting into files not only overwriting.

And by the way some EXE might have a protection against unauthorized modifications by using a some kind of checksum or digital signature.

Windows also keep information to repair broken application. I don't know if it can detect modified files but it surely detect deleted files and is able to restore them when you start the application.

Usually, it is illegal anyway to modify an EXE file as you are typically not allowed to do reverse engineering on commercial softwares and if it is your opwn EXE, then you should typically modify the source code anyway.

As other has point out, you need a binary editor (or works in binary mode) to modify a binary file. If it does not works, the first thing to check is what has changed in the file. In particular, it is usually not possible to change the file size as it will broke links inside the file.

By the way, modifying an EXE file is a suspicious activity. Why would you modify someone else software. If you do so, then you have to ask the permission to the software Creator.

You need to understand that the ACII/Hex representation is only that: a representation. If you save that as is, the resulting file will be more than twice as large as the original binary file.

If you have a hex representation of a binary file, the correct way to store it works like that:

1. remove the decoration, e. g. whitespace, linebreaks, line numbers, offset addresses, and similar bits that your hex representation may include. E. g. part of a representation may look like this:

000000D8 48 45 4C 4C 4F 20 57 4F HELLO WO
000000E0 52 4C 44 21 00 00 00 00 RLD!

Here the first long number in each line is the offset to the file start (in hex)), the following eight pairs of alphanumericals represent the value of one byte each, and the last 8 characters show the ASCII interpretation of that byte sequence.

To store that, you need to compress it to just the byte values, i. e. :

48454C4C4F20574F524C442100000000

2. Convert the characters of this byte representation into hexadecimal values. e. g. the character '4' corresponds to the hex value 4, and 'C' corresponds to 12.

3. Convert the hex representation of the byte sequence into actual bytes: since each character of a byte representation represents a nibble of the actual byte, the corresponding byte value for the hexadeciaml digit sequence h1, h2 can be calculated as

unsigned char byte_value = 16*h1 + h2;

So, for example, the byte value of the digit sequence {4, 12} is 4*16+12 = 76

4. Store the resulting bytes in consecutive order