By default, the file game.projectc is in plain text. It would allow users to customize and access some things which developers may not want - such as changing the bootstrap collection. I’d like the option for it to be obfuscated in some way at least to make it difficult for casual users to change the file, and maybe link it to the game.projectc file so that there must be a matching game.darc to go with a game.projectc (based on internal build id or such) and other game.darcs can’t be used as clever users may get around it by generating a new game.projectc with Defold directly.
2 Likes
Is there really a need for this? What would be the problem with someone using another bootstrap collection? You shouldn’t leave stuff in the finished product that you don’t want your users to access anyway right? And on desktop it’s even easier than modifying game.project to launch with another bootstrap collection. Appending --config=boostrap.collection=foobar.collectionc when launching would be enough.
Changing game.projectc or any other file for that matter on iOS or Android would change the signature of the package and invalidate the MAC. Since that is an operating system mechanism you can be fairly certain that no one will modify your package.
The same functionality does not exist on Windows, Linux, OS X or Web. It would be possible for us to mitigate the risk of modifications by using similar cryptographic mechanisms, but it would increase both boot times and the data portion of the package size. And even with these mechanisms it would be possible to reverse engineer the game since the data would have to be decrypted in order to run.
If anyone wants to ruin their own experience by modifying a single player game, let them. If you are building a multiplayer game your best bet is to secure the communication between the server and the client, and make sure all data verification is done on the server-side.
4 Likes
I suppose there are internal ways possible to ensure that only the collection you want is the entry point.
The reason I suggest this is that eventually other devs will ask for it too. Allowing it as an option is for the same kind of reason scripts are obfuscated and files are packed, which some devs find important even if we all know people who know what they are doing can get into anything.
@jakob.pogulis Yes, but for casual users it would be a wall they wouldn’t cross. “Locks keep honest people honest.” Doesn’t have to be encrypted, bit shift would be enough.
game.project obfuscation is still something I would like, and not something end users can solve - we can ensure data is how we want it in the file and not modified / make sure the main bootstrap is respected, but we can’t easily hide the data ourselves. It’s especially an issue as extensions begin to be made which want their secret keys listed within the game.project file. The game.project file bundled should also have certain unnecessary lines stripped such as dependencies.
Very simple obfuscation like XOR would be fine as it’s really only about obscuring to the layman pest and not the determined hacker (who probably has better things to do). It could be even an option in the game.project file so that we can choose to take the initial nominal performance hit or not. It could be an AppManifest option too, make its XOR key the engine build number.
1 Like
Surely this must be a very bad idea? Listing private keys that give some kind of write access to a framework/lib/service somewhere should be avoided.
BUT I agree that some obfuscation option would be a useful addition.
2 Likes
The Defold analytics key is also included in plaintext in the game.project for anyone who was malicious about stuffing bad data. Unlikely but it’s that much easier for bad actors to act badly.
By the same token websites store their Google Analytics UA ID in plain text and no great abuses seem to happen. I think the idea here is that if somebody wants to artificially inflate usage stats, using the ID is no different from reloading the page a bunch of times. The promise of analytics is an attempt at statistic meaningfullness, not exact measurements, anyway.
There should anyway be a “don’t trust the client” philosophy in everything you make and no amount of obfuscation will stop a determined actor. And after all, that’s fine! I think it’s acceptable to let players cheat as long as that doesn’t make the game worse for other players (where you can enforce server checks). It’s their own experience they’re ruining, after all.
3 Likes
Many of the settings in this file are harmless enough, but I’m surprised I have to make a workaround to hardcode some physics-related values, to ensure a level playing field in a bundled project. 
Not all social gaming is online and “server-checked”.
This is a fairly old answer, and outdated. You can put config values in Lua source code and encrypt the Lua files using an encryption algorithm of your choice or using the default with a project specific private key:
Or you can put config values into the application binary and access them using standard sys.get_config_string() functions:
2 Likes
Maybe I’ll read the config file in a Lua script, check the offending settings, and if any are changed, I’ll reboot the game with the correct values. I can’t find another way to ensure the fixed timestep is the correct interval for fairness, because it can’t be changed at runtime.
Then there are a few random possibly-exploitable things, like max collisions…
1 Like