It sounds like you're trying to prevent tampering with the file. If that's the case then you should verify the data in the file, not where it came from. To me, that implies that you should be signing the file and checking its signature when you load it. If the file is signed with your certificate then it does't matter whether the bytes were loaded from the Internet or localhost because you know that nobody has tampered with the data in transit.

To me, that implies that you should be signing the file and checking its signature when you load it.

Doesn't work since this is client side. Debuggers and other advanced diagnostic tools (sometimes called 'hacking tools') can easily freeze your program, detect how the file is touched and poked and decoded, then modify the executable to accept an unencrypted file.

Encryption ensures safe delivery of the package between two trusted endpoints through a hostile environment. If the end point is not trusted, such as a player's client machine, encryption doesn't help.

As a parallel, a secure connection between you and your bank works because you trust your side and you trust the bank's side. The dangerous zone is in the middle. A one-time session key prevents bad guys from intercepting and immediately using the content, and the short term use-and-discard nature of session keys makes them non-reusable and (usually) too expensive to justify cracking. However, the bad guys can also get a client, reverse engineer the protocols, send invalid but correctly encrypted messages, and see everything that is internally happening inside the client. The bad guys can build their own trusted communications links. They'll be assured by the encryption that nobody is doing anything untoward with their communication stream (just like your communication stream is safe from them), but they can modify content of their own stream and modify their own copy of the client, so your server better be prepared to limit the data sent and to validate every transaction.

If the client has access to the data and protocols in any form then an attacker also has access to the data and the protocols. No amount of encryption will protect the data within the stream from an attacker who has a valid client.

If you can't trust the end-point then *everything* goes out the window. I don't think there's any way to be secure under those conditions, so I don't spend much time worrying about it. But that doesn't mean you shouldn't do everything you can to protect the data between the server and the customer's machine.

For example, my day job is doing web application development and browsers "helpfully" include a full suite of debugging tools built right in. Couple that with the fact that all application logic is delivered in source code form and you have an environment that is *very* friendly to hackers. There's not much we can do about it except run the code through an obfuscator and monitor the situation as best we can. So far we haven't seen any serious hack attempts, but then we're not a AAA game title.

Security is always a balancing act because you often have to live with the fact that your security isn't perfect. The trick is to find a balance between the risk (what damage an attacker could do) and the threat (how likely you are to be attacked). If you're working on the next Dota with millions of dollars in prize money riding on the results of your matches then you need to take a very different approach to prevent cheating compared to a small personal project that's only ever going to be distributed to your friends.

I'd concentrate more on securing the content on the server, rather than preventing the client from connecting to hacked servers.

Any Tom, Dick or Harry can make an offline copy of a website, using tools like HTTrack, so if your web server does nothing to hide the game content from those tools, then you're just making the hacker's job easier. Your mention of curl is actually a dead-give-away that a tool like that (perhaps coupled with a monitoring tool like Wiresark to discover all of the URLs that must be downloaded) is sufficient to download all of your game content off the server - a hacker wouldn't even have to look at modifying your game client.

A few techniques come to mind to avoid this:

- A single game client usually doesn't need all of the game content downloaded at once, so you know that whoever tries to do that probably uses a hacked version of the client, and you can interrupt them (or start sending them random data) before they get to replicate the whole game content.

- To protect against URL monitoring, you could randomize&encrypt the URLs.