We help IT Professionals succeed at work.

We've partnered with Certified Experts, Carl Webster and Richard Faulkner, to bring you two Citrix podcasts. Learn about 2020 trends and get answers to your biggest Citrix questions!Listen Now


How Can I Edit .exe File by Using C/C++? - Code is Posted, I Need Explanation

F-J-K asked
Medium Priority
Last Modified: 2012-05-06
I got this code in the internet. I mostly understood the code, but i need clarification on some parts. These spot i need somebody to explain it to me:


1. Can you explain what these parameters do?


2. I know this points to the offset. Any sugestions on where does this function usually used?

WriteFile(hFile, szBuff, variableSize , &ret, NULL);

3. What is ret return? What is NULL represent?

4. Is patching still used nowadays for updating applications? I never find companies out there giving me patches to update apps i have. I think its done online. Anyhow, any comments will be appreciated.

Please note this code i got in one of the IT websites, i know its not a proper one to use it in a serious application since there are security flaws in it.
#include <windows.h>
#include <stdlib.h>
#define variableSize 20
#define BYTE_OFFSET 0x0000FE2A   //assume this is the address of the place we want to edit
int main()
    LPSTR szBuff = new char[20];   memset(szBuff, 0, 20);
    DWORD ret=0;    
     if(hFile == INVALID_HANDLE_VALUE){
       printf("\t\tError opening file.\n");
       delete[] szBuff;
       return 0;  
    printf("Enter The Change You Want to Make in Application.exe");
    fgets(szBuff, 19, stdin);
    if(strcmp(szBuff, " ") == 0 || strlen(szBuff) == 0){
      printf("Error, you did not enter any data\n");
      delete[] szBuff;
      return 0;
     SetFilePointer(hFile, BYTE_OFFSET, NULL, FILE_BEGIN);
     WriteFile(hFile, szBuff, variableSize , &ret, NULL); 
      delete []szBuff;
     printf("Exe Edited :)\n");
     return 0;

Open in new window

Watch Question

AndyAinscowFreelance programmer / Consultant

1, 2, 3 - why not look the functions up in the help files.  If anything is not clear then ask for further clarification.

4 - the online is still a patch, just supplied via the internet rather than disc in the post.  The delivery method is different.


I forgot to mention. I will google the functions anyway, but your help won't harm. Anyway, i will get back with questions after looking up the functions
Top Expert 2012

The parameters to 'CreateFile()' are decribed at http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx

The variables to 'SetFilePointer()' can be found here http://msdn.microsoft.com/en-us/library/aa365541.aspx

That function is used to advance towards the offset into the file, since when you open it for writing, the starting offset is '0', which means writing to the beginning of the ile instead of to the desired position.

In your call to 'WriteFile()' (http://msdn.microsoft.com/en-us/library/aa365747(VS.85).aspx), 'ret' will contain the number of bytes that were actually written after the function returns. If that number is different from 'szBuf', something went wrong. 'NULL' as the last parameter here means that you are performing a synchronous operation. If that parameter would point to an 'OVERLAPPED' struct (where Windows stores data for async operations), this function would return immediately and you'd get notified later about the result.

opens the existing application.exe from the current folder for write.


It is not an absolute path, hence the current directory of the prog which makes the write would be the target folder.  


If you run the prog whcih creates the exe you need to have 'write access' to the folder (and to the old file if it was an update).

>>>> 0, NULL,
It is share mode (0 means the file cannot be opened or accessed while it is not closed by your prog) and security attributes (NULL means, the file handle returned yb CreateFile cannot be inherted from child processes).


means the application.exe must exist.


Means no (special) file attributes like hidden, read_only or system and no use of a file template which could provide file attributes or extended attributes (a NTFS special).

>>> SetFilePointer(hFile, BYTE_OFFSET, NULL, FILE_BEGIN);
change the position in the file where the next write would start.


return of the CreateFile


offset in the (binary) file in bytes. That is the address where the update should start. If you would look at the application.exe using a hex editor, you could try to find out what part of the exe it is (I assume it is resources).

Note the BYTE_OFFSET is a LONG thus limited to a 32bit integer == 4GB (what seems pretty enough for an executable file). But, for database file you may have bigger files and use the next argument to point to another LONG which is supposed to be the higher 32 bits of a 64bit integer.

The technique to pass a 64bit integer as a pair of 32bit integer and pointer to the higher 32bit part is somewhat strange but is made for compatibility reasons as for all former calls the files rarely are greater than 4 GB so that the efforts are only for those who newly need to handle huge files as well.  


That tells from where the offset was counted. Alternatively you have FILE_CURRENT and FILE_END.

>>>> WriteFile(hFile, szBuff, variableSize , &ret, NULL);
writes the buffer pointed to by szBuff, sized by variableSize to the file at the current position.


Handle returned by CreateFile


a void pointer pointing to a buffer. The szBuff wrongly is prefixed with sz what means 'zero-sized string', i. e. a char array terminated by the first (binary) zero character. I really doubt that you would update a text within a (binary) exe file, but even if so, you hardly would write terminating zero characters (or any garbage after the terminating char) up to the size of the buffer to an executables. Many executables have only wide char strings in their binary file and strings generally were terminated by length and not by zeros when stored in a binary file (which has a lot of zeros).

>>>> variableSize

looks like the size of the buffer was variable what is strange as well. For an update write in a binary file you either need to use exactly the previous sizes (e. g. replace 20bytes with 20bytes or "Text" by "text" same length) *or* you have to newly write all the rest of the updated file.


That argument is supposed to return the (number of) bytes really written. It could be different to the 'variableSize' for two reasons: (1) there is some error - e. g. not enough disc space or disc quota (2) the buffer written was transformed to a  buffer of different length.

(2) happens when writing in text mode. Then, any LF (linefeed char = 0xA = decimal 10) turns to a CRLF pair (carriage return = 0xD = decimal 13) when written to file.

Also in case of (automatic) encryption and/or packed drives you might get a different length back. The argument is a pointer cause it is a C interface and pointer arguments were the means in C to define output arguments. After the call you might check

   if (ret <= 0)  // something was wrong

cause the normal would be that the variableSize was returned in ret if all was ok.

>>>> What is NULL represent?
The last argument is a pointer to an 'OverLapped' structure which was used for very fast asynchronously happening file access. For the above prog it has no importance.

>>>> Is patching still used nowadays for updating applications?
Rarely. As told the strings often were in Unicode where each second byte was zero in case of ANSI text. Furthermore you have to consider that the above prog was not able to change the length of a text found in the executable (UNICODE or not). You could try to update resources which are appended at end of exe file. But actually the Visual Studio can do that much better than a prog like the above.

Moreover, newer executable may have checksums and or encryption to prevent a virus from hijacking an executable. Then your prog wouldn't work either, i. e. the output executable would be corrupt after write.

Not the solution you were looking for? Getting a personalized solution is easy.

Ask the Experts


Can't thank you enough
>>>> I never find companies out there giving me patches to update apps i have. I think its done online.

For patches there are 3 variants:

1. A full setup with all executables (.exe and .dll)
2. Exchanging only one or more dlls
3. Exchanging only resource data.

(3) for example is done with anti-virus scanners. They only download and install signatures if new viruses and use still the old versions.
(2) often was done after an installation from CD. The freshly installed application asks whether it should get updates from the internet. If they installed a new dll, you often need to reboot in order to make the changes valid.
(1) is only done if the changes were too big or if it were some basic errors to fix.
Access more of Experts Exchange with a free account
Thanks for using Experts Exchange.

Create a free account to continue.

Limited access with a free account allows you to:

  • View three pieces of content (articles, solutions, posts, and videos)
  • Ask the experts questions (counted toward content limit)
  • Customize your dashboard and profile

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.