C++ force variables to a fixed memory location

Question

I have written a C++ code for application, in which there are some variables that must have different values for every user will use it ( lets call it the variable X for simplicity)

X have different values for different user. This (X)should be not changed and also embedded in the exe itself ( so I can't read it from a file or any other similar solution)

I don't want to distribute the source code then compile. Instead, I want a method that makes me edit the final exe directly without need to compile ( it is just value of variable X which differs !) Is this possible ?

My idea to do this is if I can force this (X) at a constant memory location, I can then edit its value easily from Hex-editor as example. ( I mean the same ideas when hackers writes cheat tool for a certain game )

1. Is the mechanism of fixed memory position possible?
2. Is there any other idea to make what I want?

I hope my question is clear enough

Answer 1

In this answer I'll use Visual Studio 2017 Community Edition because I wanted to be sure to a have a development environment fully compatible with Windows.

I'll present five methods, from the most maintainable to the less. Of course the focus of this answer in strictly limited to the goal of "sharing" a C++ variable with an external tool.
Security of such an operation is a different topic and ultimately a futile attempt anyway.

---

Method 1 - Resources

Windows APIs¹ and the PE² support embedding resources in an executable³.
Resources are typically images, icons or localized strings but they can be anything - including raw binary data.

With Visual Studio is quite easy to add a resource: In the Solution Explorer > Resource files > Add > New item > Resource > Resource file (.rc)

This will open the Resource view, right-click on Resource.rc and select Add resource....
It's possible to create the standard resources but we need a Custom... type that we can call RAW.
This will create a new binary resource, gives it an ID and makes a few files in the solution.
Switching back to the Solution explorer we can see these new files and eventually edit the .bin file with a better hex editor than the VS's integrated one.
Of particular interest is the resource.h file that we can include to have the definition for the resource id, in my case it was IDR_RAW1.

After the bin file has been crafted we are ready to read it in the application, the pattern to use is the usual one - I don't feel like going over these API one more time a new answer so I'll link the Official documentation and provides a sample code:

#include <Windows.h>
#include "resource.h"

int WINAPI WinMain(HMODULE hModule, HMODULE hPrevModule, LPSTR lpCmdLine, int showCmd)
{
    //Get an handle to our resource
    HRSRC hRes = FindResource(hModule, MAKEINTRESOURCE(IDR_RAW1), "RAW");

    //Load the resource (Compatibility reasons make this use two APIs)
    HGLOBAL hResData = LoadResource(hModule, hRes);
    LPVOID ptrData = LockResource(hResData);

    /*
      ptrData is out binary content. Here is assumed it was a ASCIIZ string
    */
    MessageBox(NULL, (LPCSTR)ptrData, "Title", MB_ICONINFORMATION);

    return 0;
}

Resources are good because they allow for an easy integration with other automatic build tools: it's easy to add a build step before the resources are compiled to generate them on the fly.

It is also very easy to alter them after the exe file as been generated - CFF Explorer III is a simple and effective tools to edit a PE module's resources.
It's even possible to replace a resource entirely thereby not limiting ourselves to keeping the new resource the same size as the old one.

Just open the module in CFF, select Resource editor, browse to the raw resource and edit/replace it. Then save.

Method 2 - PE exports

Executable are ordinary PE module just like Dlls, the difference is really a batter of a bit.
Just like Dlls can exports functions and variables⁴ so can exes.

With VC++ the way to tag a symbol as exported is __declspec(dllexport):

#include <Windows.h>

__declspec(dllexport) char var[30] = "Hello, cruel world!";

int WINAPI WinMain(HMODULE hModule, HMODULE hPrevModule, LPSTR lpCmdLine, int showCmd)
{
    MessageBox(NULL, var, "Title 2", MB_ICONINFORMATION);

    return 0;
}

The C++ side of the matter is little affected.
The editing of the PE module is less user friendly but still very easy for everyone to follow.

With CFF open the export directory, all the exports will be listed.
C++ compilers have to mangle variables names when they can be shared due to the C++ features they support - so you won't find a nice name like var in the exports but something like ?var@@3PADA.
The export name doesn't really fulfil any goal in this context but you must be able to identify the correct export. This should be easy since it's very likely to be only one.
CFF will show you the function RVA, this is the RVA (relative to the image base) of the variable, you can easily convert it into a file offset or simply use the Address converted integrated in CFF.
This will open an hex editor and points you at the right bytes.

Method 3 - Map files

If you don't want to have a PE exports pointing right at your variable you can tell VS to generate a MAP file.

Map files will list all the symbols exported by an object file (note: an object file, not a PE module).
So you must make sure a variable, in this case, is exported by your translation unit - this is the default case for "global" variables but make sure to remember to not attach the static linkage modified to it and eventually make it volatile to prevent the compiler from eliminating it during the constants folding step.

#include "Windows.h"

//extern is redundant, I use it only for documenting the intention
//volatile is a hack to prevent constant folding in this simple case
extern volatile int var2 = 3;


int WINAPI WinMain(HMODULE hModule, HMODULE hPrevModule, LPSTR lpCmdLine, int showCmd)
{
    //A simple use of an int
    return var2;
}

A MAP file will be generated in the output dir, along with the exe, inside it's present a row like this one:

 0003:00000018       ?var2@@3HC                 00403018     Source.obj

This gives you the VA of the variable (403018) that you can use in CFF Address translator.

Method 4 - PE scan

You can initialise the variable with an unique value.
To be able to do so the variable size must be big enough that the probability that a random sequence of bits of equal size end up with the same value is negligible.
For example, if the var is a QWORD the probability of finding, in the PE module, another QWORD with the same value is very low (one in 2⁶⁴) but if the var is a byte then the probability is just one in 256.

Eventually, add a marker variable (I'd use a random array of 16 bytes) before the variable to mark it (i.e. act as the unique value).

To modify the PE use an hex editor to look for that unique value, this will give you the offset of the var to edit.

Method 5 - Reverse engineering

After each release, reverse engine the application (this is easy as you can debug it with VS along with the sources) and look where the compiler allocated the variable.
Take note of the RVA (nota bene: RVA not VA, the VA is variable) and then use CFF to edit the exe.

This requires a reverse engineering analysis each time a new release is built.

---

¹ To be correct, "Win32" APIs.
² I strongly advice the reader to be at least accustomized with the PE file format as I must assume so to keep this answer in topic and short. Having no understanding of the PE file format will likely result in no understanding of the question as a whole.
³ Actually, in any PE module.
⁴ Symbols in general.