Hi,
Although I have done a couple of simple XNA games, I'm not too experienced with publishing/deploying/installing - so bear with me.

After I have published a solution (for cd-rom/etc release), I get my setup- and manuscript-file and folder in the /publish directory. Then I can use this setup file (with folder and manifest file) to install the game on a target machine. Works fine.

As I understand it, the folder/directory structure I got in my Content node is then replicated on the target machine, right? This makes it possible to navigate into these folders and see my resources - images, sounds etc.

However, for a game I'm developing now, it's quite imperative that the user cannot go in and see/change these images/soundeffects - or at least make it cumbersome to do so. How to do this best?

I looked at XnaZipLib, but I understand it uses standard zip compression, thus making it easy just to unpack this/these zip files, look at the content, and modify it. Not good.

I see two alternatives:
* either I crypt my image resources somehow and then hard-code a deciphring key into my code

* or I leave my images in original shape, but when the program starts, it calculates some sort of checksum of these resources and compare it with a hard-coded checksum, to make sure (or highly probable) that the images are the original ones.

Comments on these possible solutions? Any better way?

Demesta:

As I understand it, the folder/directory structure I got in my Content node is then replicated on the target machine, right? This makes it possible to navigate into these folders and see my resources - images, sounds etc

They get to see the XNB files, but not the raw image and sound files. At least not unless you are copying them to the output directory yourself.

Demesta:

However, for a game I'm developing now, it's quite imperative that the user cannot go in and see/change these images/soundeffects

Why? I have a feeling you're going to waste far too much time on something like this when it's really simple:

1) If your game is only moderately popular, odds are nobody will bother hacking it.
2) If your game is popular enough that people want to hack it, there's a point where you just can't stop it.

Lots of games nowadays ship with completely unencrypted .WAV, .PNG, and .OGG files. If EA isn't worrying about it, why are you? I would advise you to just make a good game and not worry about someone editing the sounds or images.

Demesta:

* either I crypt my image resources somehow and then hard-code a deciphring key into my code

Which would only take a person a few seconds with Reflector to dig out.

Demesta:

* or I leave my images in original shape, but when the program starts, it calculates some sort of checksum of these resources and compare it with a hard-coded checksum, to make sure (or highly probable) that the images are the original ones.

Depending on how you generate those, it could work, but I'm still not convinced it's even worth the time.

Nick Gravelyn:

Demesta:

However, for a game I'm developing now, it's quite imperative that the user cannot go in and see/change these images/soundeffects

Why? I have a feeling you're going to waste far too much time on something like this when it's really simple:

...

Because it's imperative for the game experience that these images cannot be changed. I know it sounds weird, but it's well thought through and this is why I need for the game project to function properly.

Demesta:

Nick Gravelyn:

Demesta:

However, for a game I'm developing now, it's quite imperative that the user cannot go in and see/change these images/soundeffects

Why? I have a feeling you're going to waste far too much time on something like this when it's really simple:

...

Because it's imperative for the game experience that these images cannot be changed. I know it sounds weird, but it's well thought through and this is why I need for the game project to function properly.

If a user edits the images and their game experience is ruined or the game crashes, it's their problem. I just don't feel like it's your job to stop them from editing those files.

Cripes - what is this?!

I'm sketching on a game project where it is imperative that these images cannot be changed! That's my issue, and that's the issue I'm trying to solve! It IS my problem to make sure that these images cannot be changed - it is IMPERATIVE for my project! If they can be changed, my project is pretty pointless!

I'm most grateful for constructive replies, but let us stick to the issue at hand: that is, how can I make sure that the user cannot change these image files. But please don't lecture me on how to design my general project and what you feel is my job in the project I am working on.

Demesta:

Cripes - what is this?!

Constructive advice. You're wasting time solving a problem that doesn't exist. Until such time that Player A editing their files affects Player B, it shouldn't matter whether Player A's experience is ruined; they ruined it for themselves. I'll leave it from here on, but just believe me that there are dozens of other experienced developers who would tell you the exact same thing. Even AAA studios are realizing that content encryption and obfuscation is just a waste of time, as seen that lots of AAA titles ship with regular old WAV, PNG, and other art assets right there for the editing.

Demesta:

how can I make sure that the user cannot change these image files.

You can't. At the end of the day, you can't. If someone wants to change them badly enough, and have the know how, they will change them. Anything you hard code into your assembly is easily retrievable through a tool like Reflector.

So what you really need to figure out is what level of protection do you want? Do you just want to stop the complete n00bs? The standard compressed XNB content should suffice for that.

You could try using encryption, but given that .NET assemblies are trivial to decompile, anything you hard code (such as a key) would take minutes to find and pull out.

You could also try building your own packed content file. Basically you scoop up all your content and put it all inside one big binary file (compression is usually good to use here just as an added bonus to file size and to make it a little trickier to get at). You can make a post-build process that does this for you and then just read that big blob in at once to get the content out for the game. Though, again, your game is easily decompilable and it wouldn't take much effort to make a tool to decompress and read this file, spitting out raw assets.

Like I said, your goal can't be to stop everyone, so you have to figure out how many people (or rather, what kind of people) you're trying to stop. Once you know that, it's much easier to find a solution that solves that problem.

Nick Gravelyn:

Demesta:

Cripes - what is this?!

Constructive advice. You're wasting time solving a problem that doesn't exist. Until such time that Player A editing their files affects Player B, it shouldn't matter whether Player A's experience is ruined; they ruined it for themselves. I'll leave it from here on, but just believe me that there are dozens of other experienced developers who would tell you the exact same thing. Even AAA studios are realizing that content encryption and obfuscation is just a waste of time, as seen that lots of AAA titles ship with regular old WAV, PNG, and other art assets right there for the editing.

Absolutely - in general, I agree. Fully. I have never ever previously seen the need to make it explicitly cumbersome to hinder people from editing the artwork. When I was younger, in the 70-80's, I enjoyed hacking into my old Sinclair ZX Spectrum games, changing the graphics to my own.

But in this project, it is imperative that I make it cumbersome to change the graphics. Thus I need to make sure that ordinary users, the target audience, cannot change the graphics so easily. There may be many reasons behind this - propriety reasons for instance, i.e. that the owners of the images really want to make sure that these images are used in their original.

Nick Gravelyn:

Demesta:

how can I make sure that the user cannot change these image files.

You can't. At the end of the day, you can't. If someone wants to change them badly enough, and have the know how, they will change them. Anything you hard code into your assembly is easily retrievable through a tool like Reflector.

My bad: I'll rephrase. How can I make sure that it is cumbersome for an ordinary player, i.e. a non-programmer without Reflector etc, to change the images in the game.

Nick Gravelyn:

So what you really need to figure out is what level of protection do you want? Do you just want to stop the complete n00bs? The standard compressed XNB content should suffice for that.

Okay, now we're getting somewhere - thx! XNB content - have to look that up. I don't know whether this is something that automatically is applied to the Content files or something that has to be done separately. Thx - will look into it.

Nick Gravelyn:

You could try using encryption, but given that .NET assemblies are trivial to decompile, anything you hard code (such as a key) would take minutes to find and pull out.

Yes, and it feels a bit too complicated.

Nick Gravelyn:

You could also try building your own packed content file. Basically you scoop up all your content and put it all inside one big binary file (compression is usually good to use here just as an added bonus to file size and to make it a little trickier to get at). You can make a post-build process that does this for you and then just read that big blob in at once to get the content out for the game. Though, again, your game is easily decompilable and it wouldn't take much effort to make a tool to decompress and read this file, spitting out raw assets.

Like I said, your goal can't be to stop everyone, so you have to figure out how many people (or rather, what kind of people) you're trying to stop. Once you know that, it's much easier to find a solution that solves that problem.

Now I have several leads to look at! Thx a bunch, Nic!

I'll though also look whether I can do some checksum. One idea would be to go through the folder, grab the file sizes and then get a checksum or something, and then check this against a hardcoded checksum.

Demesta:

Okay, now we're getting somewhere - thx! XNB content - have to look that up. I don't know whether this is something that automatically is applied to the Content files or something that has to be done separately. Thx - will look into it.

Any content you put into a Content project will, by default, be built into XNB files. Check your project's bin directory and you should see them there. In Release mode, you'll also get compression on the XNB files which is nice for file size. If you're just worried about ordinary gamers, that probably will do the trick as there is yet, to my knowledge, been any tool released that can read/write these files without a full Visual Studio + XNA Game Studio installation.

Can I just quickly point out that if you had read Nick's very first post, he told you the answer in the first line. But as Nick said, where there's a will, there's a way. So don't rely on them *not* being able to modify them.

Nick Gravelyn:

Demesta:

As I understand it, the folder/directory structure I got in my Content node is then replicated on the target machine, right? This makes it possible to navigate into these folders and see my resources - images, sounds etc

They get to see the XNB files, but not the raw image and sound files. At least not unless you are copying them to the output directory yourself.

Absolutely - give me the task to modify an in-game image in just any game, and I'm pretty sure that I'll work how to do it eventually.

In short: what I need here is a way so I can say to the image owners that yes, I have put some effort into making sure that these images are not modified. It is actually legally okay if the final consumer grabs the images, modify them and use them in another application or situation, but it is imperative that the images in this game project are not altered - or that it is a non-noob task.

For simplicity, I will probably solve it using checksums, i.e. scanning through my image files, obtaining some sort of checksum and then compare this with a hard-coded checksum. It is theoretically possible that the altering or a change of an image would result in the same checksum, but it is improbable enough for the current project.

Demesta:

Absolutely - give me the task to modify an in-game image in just any game, and I'm pretty sure that I'll work how to do it eventually.

In short: what I need here is a way so I can say to the image owners that yes, I have put some effort into making sure that these images are not modified. It is actually legally okay if the final consumer grabs the images, modify them and use them in another application or situation, but it is imperative that the images in this game project are not altered - or that it is a non-noob task.

For simplicity, I will probably solve it using checksums, i.e. scanning through my image files, obtaining some sort of checksum and then compare this with a hard-coded checksum. It is theoretically possible that the altering or a change of an image would result in the same checksum, but it is improbable enough for the current project.

No worries - you are not rude and I understand that the whole issue is a bit weird! I didn't realize that xnb packages were packaged and zipped in the beginning so that solves a huge part of the problem actually. It might be enough for what I'm working on, but I have to check that externally so to speak.

Thx!