.X files encryption?

The same way you'd encrypt any files? Just decrypt them when you go to load them.

Quote:

Original post by kevinawad This is really needed for selling applications or games.

I don't agree that it is "really needed". Most games do not encrypt anything and rely on copyright law to ensure people don't steal their assets.

You can encrypt the data however you want, so long as you can decrypt it and then feed the binary data to D3DXLoadMeshFromXInMemory.

Keep in mind that any encryption scheme you could use is breakable.

I'd concentrate more on making your game than worrying about people stealing it, at this point in time.


Possible? Yeah. Worth it? Probably not.

I'm talking about an online game...people would just mess around with files...

how will it be possible to read each data example of a texture...i know how to decrypt, but how to manage to make it while loading from files..or after loading the file. Where's the data located?

Quote:

Original post by kevinawad how will it be possible to read each data example of a texture...i know how to decrypt, but how to manage to make it while loading from files..or after loading the file. Where's the data located?

When a files is decrypted you can do one of two things, ether leave it in the memory and pass a pointer to it, or write it into a temporary file.

As far as online gaming your best bet is not single file encryption, it would be best done with a customized database file, but that can be very cumbersome in the first stages of game development.

-Stev0

Quote:

Original post by kevinawad I'm talking about an online game...people would just mess around with files...

Why would that matter? The player will only be modifying their own local copy of the game, and you'll be verifying all movement, etc on the server anyway to prevent cheating / hacking anyway.

Quote:

Original post by kevinawad how will it be possible to read each data example of a texture...i know how to decrypt, but how to manage to make it while loading from files..or after loading the file. Where's the data located?

1. Load encrypted file into memory
2. Decrypt into another memory buffer
3. Pass the memory buffer to D3DXCreateTextureFromFileInMemory, etc.

Well, you could also try to use some sort of checksum on the client files as well, to see if they have been tampered, but Evil Steve is right - you will most likely have to do a lot of your validation on the server anyway.

Quote:

Original post by Moe use some sort of checksum on the client files as well, to see if they have been tampered

I reckon this is your best bet. Implementing a CRCn algorithm is pretty simple and you can have the client upload the resultant values to the server at which point it decides to accept/refuse the connection accordingly.

This can double-up as a method for checking if the client is the correct version as well. If the files are wrong then you can auto-download the latest patch (etc..) and then attempt a re-connect.

Ultimately though you're only creating a deterant against the lazy - just look at the amount of effort some commercial games go to in order to stop hacking, and then look at how many of them still fail. Where there's a will, there's a way [wink]

hth
Jack

Quote:

Original post by jollyjeffers Quote: Original post by Moe use some sort of checksum on the client files as well, to see if they have been tampered I reckon this is your best bet. Implementing a CRCn algorithm is pretty simple and you can have the client upload the resultant values to the server at which point it decides to accept/refuse the connection accordingly.

But if the client is already hacked, they can just send whatever checksum the server is expecting. No need to calculate it.

There is, unfortunately, nothing you can do to protect the client-side assets. All you can do on the server is ensure that the client isn't doing anything that is "impossible" (walking through walls, etc) based on what the client-side assets should be.

Just found a way to do it.

int filesize = 0;

ifstream file("blabla.jpg", ios::end);

filesize = file.tellg();

if(filesize != normalfilesize)
{
file.close();

ofstream file("blabla.jpg");

file <<"Did you try to modify this file?"<
file.close();

}
else
{

cout <<"Files loaded!"<
}

I will have to use jpg to do this...jpg filesize change everytime you do one modification. example, you change an rgb color from black to red, the byte filesize will change.

So actually, modifying the file will delete all the client files...the guy will need to reinstall it.

Yeah, that's not going to work at all. It's not even close. It's a much, much more ineffective approach than anything suggested here so far.

You think this won't work? Having your game files all deleted won't work? will you keep editing the files after having reinstalled it alot of times???

I know this isn't an encryption for .x files...but it's a good security for loading image files.

No, I'll simply notice the uninstall the first time, reinstall the game, and then overwrite your check with a jump instruction to skip it and load it regardless. This takes about ten seconds to do with a hex editor. Hell, I can do it live to your program via another program if I want. It's absolutely trivial. Then I can upload my version to any of a thousand warez sites and your protection is now completely worthless.

Good security? Please. There's a million bored high school programmers who could bypass it without batting an eyelid, let alone the people who do this stuff for real. But do try to come up with something better. This kind of thing is educational for everybody involved.

I know about encryption/decryption...

It's just that i didn't know how to access the memory in direct3d to encrypt the data.

Now that i know, it will be easier for me.

+ By the way, this could add a little bit of security.

And as far as encryption, I can put a fake D3DX in between your program and the real D3DX that modifies the data on the fly to be whatever I want. Again, really easy attack. Do you plan on fighting that?

hooking your dll?...it will be worthless for the kind of game im devlopping.

I'm 15 years old by the way. So putting stuff in my head might take a bit of time.That's why i need alot of help with Direct3d...I normally work with networking / win32.

I think the question is more, Why the hell would you wanna? Surely we are talking here about purely the client meshes/textures - why not leave them unencrypted and let the players mod the textures as much as they like? That way, if the game is successful, chances are the players will make gorgeous high-res textures for you... And why do you care what their game looks like? Does it affect the gameplay of other players?

Modding games is a fact of life - some commercial studios even provide mod tools with their single player games now - and there have been MMOs that allow complete customisation of textures. Although I can't remember what it was called - it was one of the 2D manga style games.

Unfortunately there is no way to encrypt game files securely. If you use weak encryption then breaking it will be no problem. If you use strong encryption, the key is the weak point since you need the key to decrypt the game files, this must either be hardcoded in the executable or retrieved from the server before beginning gameplay. Either way, it can be read from the memory of your program.

If you desperately want to prevent casual end-user theft of your textures etc, why not just XOR-encrypt the binary files? A ridiculously weak encryption method, but it'll stop "click-and-change". Again, the haxx0rs will just decrypt, alter and encrypt again and your client will be none the wiser, but hell, saves you a lot of headaches.

Mathmo

EDIT: Of course, if you want Double-Protection(tm), you could XOR-encrypt them twice... hehehehe

I am working on an online game, with my friend who is doing the graphics.

I am working with the whole engine programming + networking.

I am having no problems with it right now.

People editing the files will actually start posting screenshots about in-game items that don't even exist...stuff like that...

But it's fine, i just know now how to read the texture data...that's all i needed to encrypt and decrypt, thank you.