Visual Studio Executable

[hassanAman]

Is it possible to run a program without needing extra files?

For example, if I have a 3d game that has 3d models, and those models are stored in .obj files. If I have to run the exe file, those files will be necessary, and if are not found, the program will likely crash. Is there a way to just make your exe independent from other files, and able to run the exe without needing any other files?

[Repeater]

If you've got enough control over the source files and the build process, it's possible to package everything inside one single file, even if it then needs to do some unpacking and file creation when run. It's even possible to take an existing binary that you need, bury it inside your executable, and have it recreated on the target machine when the executable is run,

This can become (very) impractical and awkward and your efforts are better spent on packaging needed files together for distribution. A simple zip file will do the job.

[hassanAman]

I get that, but what if I publish the game online, cannot people than edit the files?

[Repeater]

Of course. If you have a file, you can edit it. This is what general purpose computers do. Read, process and create data. A file is just one more lump of data to be read, processed, altered, copied, and so on.

[hassanAman]

So how can you prevent that? Or is there simply no way?

[MikeStgt]

Is it possible to run a program without needing extra files?

Short: yes.
Long: I would suggest to look in your code, the 3d game that has 3d models, how your read the .obj files to variables, strings and/or arrays, younameit. Now replace the file reading code with a call to a function which will set the variables, strings and/or arrays, younameit exaclty to the same content as before when reading the .obj file.
A suggestion only.

[Repeater]

Well, a compiled executable or library doesn't contain any of your source code. People could decide to try reverse-engineering it. I suspect that's not a problem you need to worry about. Spend your time solving problems you actually have.

[hassanAman]

Yeah it doesn't contain source code, but what about assets? Those are necessary when running the executable, as the game depends on it. And obviously then, people can edit it and that will cause the change of the whole game, I just don't want that to happen.

[Repeater]

I just don't want that to happen.

You could encrypt your assets, and have them decrypt into memory just in time to be used, and have your assets in some custom format rather than a standard format, and write your own handlers of that custom format. That would be an enormous amount of extra work for you to do and it wouldn't make it impossible for people to still take the files that exist on their own PC and edit them to their liking; just harder. And of course, if the assets are shown as images on screen, they can just take a screenshot and they've got it.

Is that a big problem you have? Is there a lot of piracy of the games you distribute online? Do a lot of people take the assets and reuse them? Do you really dislike the idea that people might take something you created and then use it to make new creations of their own?

[MikeStgt]

what if I publish the game online, cannot people than edit the files?

Sure, what you publish is not under your control any more. If you publish source code, everyone who has an idea of C++ may use it at will. If you publish only the compiled phase (.exe or .dll) the circle of people able to "use" it (almost like source) is considerably smaller. If you like to hide something, do not publish it or even better -- do not keep it on a PC attached to a network.
Or you have to encrypt it and tell all, loud and unmistakable: decrypting is unlawful and hope this helps. For an example see this remark: http://www.cplusplus.com/forum/general/252083/#msg1109691

[jonnin]

have you ever actually played a (modern) game?
there are 2 flavors... flavor one is open, and people hack the game and modify it with the approval of the company, which makes the game more popular (more stuff to do playing the modded versions) -- its like getting developers for free. Flavor two is locked down... the game verifies its own files (checksum or some kind of hash type thingy) and shuts down if the files don't match the original (in some cases locking the user from ever playing again on that account). There seem to be third party tools that developers use to do these things to secure their games. Some games also monitor your pc; I have one that if you install a program called 'cheat engine' it locks your account for 50 years just for having that running on your PC at the same time as the game.

[Duthomhas]

AN ACTUAL ANSWER

Sorry, hassanAman, for having to wade through nonsense.

Is it possible to run a program without needing extra files?

The answer is yes, absolutely.

Further, it is very easy.

Windows uses resources, which are compiled into your executable by default. You get access to the data through the standard Windows resource functions. https://docs.microsoft.com/en-us/windows/desktop/menurc/introduction-to-resources

On Linux you simply embed the data in the executable as an object, using the objcopy utility. Read more here: https://docs.microsoft.com/en-us/windows/desktop/menurc/introduction-to-resources

On OS X (or whatever they’re calling it now) you just stick it in your application bundle.

There exist a number of cross-platform solutions that do it differently, such as https://github.com/d-led/ris, which is fairly nice.

All of the above assume that the assets are fixed at the time of compile, so the final executable contains all the necessary information.

This leads to an implementation issue: your libraries must be able to read those assets, either directly or by having your program unpack them into some kind of stream/input that your libraries can use. (Often, just having it as a string in memory is sufficient.)

It is also not uncommon to compile assets into a shared library to be used in a plug-in kind of way.

So how can you prevent [people modifying the game assets]? Or is there simply no way?

It is impossible to stop someone who is determined enough from modifying your assets.

That said, you can make it inconvenient. At the very minimum, you should apply some kind of compression on your assets.

If you wish to really secure them, though, there are different goals.

  • If the goal is to prevent your game from using modified assets, then a simple checksum is sufficient. Remember, the checksum must be stored separately from the assets, otherwise it is worthless. More on this below.
(Hint: CRC-32.)

  • If the goal is to prevent people from stealing your assets, then you should apply some kind of encryption. Use this in addition to a checksum. (Hint: get the Twofish library.)

Remember also that in certain places in the world using cryptographic options are enthusiastically regulated by the government. Make sure you don’t do something that will get you in trouble.

Of course, once you unpack your assets all bets are off. As already mentioned, sometimes just a few judicious screenshots are all that is needed to steal flat images. I don’t think you have to worry to much about 3D assets in an .obj file, as long as the OBJ data is not left anywhere obvious. That is, unpack (decrypt and uncompress) into memory, then have the OBJ readers load from memory, then clear and free the memory buffer. Same for the textures applied to your 3D objects.


Finally, consider this: your game can be very, very cool, but it might not rise to the level of being worth taking extra care to protect beyond just getting paid to play it. There are typically three marketing methods:

  • It’s free! No worries!

  • Pay to download. For this it is worth having a server running that the game can check against for things like:
     - check that the user has actually paid for the game and is running it on a registered device
     - check that the checksum (for assets or anything else) matches what your server says they should be
     - check for updates/patches/plugins

  • Pay through advertisement revenue (click here to upgrade your <whatsit>, or watch this ad to keep playing/unlock levels/etc). Again, this will require some kind of server for the advertisements. Depending on your setup, you can also do many of the things above.

Dealing with the server issues is a whole can of worms itself, and will likely dominate your time and energy. For a single executable kind of release, honestly, you are more likely looking at the first option.


Hope this helps.

[MikeStgt]

have you ever actually played a (modern) game?

No, but you knew that. ;)
(I once did a maze mod for PoP, it is still mentioned in the WayBack Machine, alas .zip files seem not to be saved.)

[MikeStgt]

Sorry, hassanAman, for having to wade through nonsense.

Why this warning in the beginning of your append? At least the quagmire is not knee-deep or ankle-deep.

I would add a link to a ready-to-use resource editor, a free one for example: http://melander.dk/reseditor
Could serve as an example (until you've done your own) how easily the content of an .exe may be accessed and/or modified.

[helios]

Could serve as an example (until you've done your own) how easily the content of an .exe may be accessed and/or modified.

That's if you store your assets as Windows resources. There's multiple ways of doing this that aren't trivially bypassed.
Consider:

const unsigned char data[] = {
0x47,0x5C,0xC1,0xDA,0xEF,0x9A,0xAF,0xC2,0xD6,0x83,0xF8,0x2A,0xD1,0x7E,0x80,0x69,
0x41,0xE6,0xBF,0xE6,0xBB,0xD6,0x83,0x37,0x18,0xB7,0xB1,0xA0,0x9D,0xF6,0x00,0x3C
};

const unsigned char key[] = {
0x46,0x4A,0x30,0x62,0x1A,0x41,0x20,0xEF,0xB6,0xDC,0xCC,0x83,0xF7,0x60,0x3E,0x9E,
0x36,0x20,0xB4,0x54,0x8D,0x03,0xCE,0xF3,0xFC,0xCD,0x4F,0x4A,0x99,0xF4,0xAC,0x0E
};

int main(){
    std::cout << aes256_decode(data, sizeof(data), key);
    //Output: "Hello, World!"
}

Now, this is a fairly trivial example, but a resource editor would already be useless here. You can increase the complexity as high as you want.

[MikeStgt]

You can increase the complexity as high as you want.

Up to brainteaser unsolvable ;) http://www.cplusplus.com/forum/general/252083

[helios]

Neither of these are unsolvable. There's nothing preventing someone from looking at the disassembly and figuring out what the code is doing.

[jonnin]

or, the lazy hacker will freeze your program and look at its memory snapshot where you decrypted it already if they can. If you want to defeat the average user, sure, but the power-users, programmers, and outright hackers will bypass any simplistic protections, and once they do, they tend to publish the how-to online for the average users. It takes some hard work to make it not worth the trouble.

[helios]

http://tigress.cs.arizona.edu/

[MikeStgt]

Nice, but 6 of 7 challenges solved: http://tigress.cs.arizona.edu/challenges.html#current
Not the best advertising. You have still the chance to make 100 USD.