Short answer: no

Long answer: Jar files are basicly just zip files and zip files support certain encryption. You can''t encrypt the jar file that holds your code (since the runtime environment needs to be able to run the code) but you could possibly place your data files in a separate encrypted jar/zip file. However, then you need to write a special zip-decryption module (is not included in the standard APIs) and work with the zips manually from Java code. Your solution would also be easy to defeat by extracting the password from your code or from memory.

Personally I think your time would be better spent on making the game better and solving problems where you actually stand a chance of finding a decent solution.

Henry

As Henry said above, there''s no point encrypting data when you''re also going to give users the decryption key. It amounts to doing nothing. There is no solution to this problem. There can''t be. Don''t waste your time.

Furthermore, zip encryption is weak. It only requires knowing 11 bytes of plain text for one of the files to extract the decryption key directly from the zip file.

Oh, and don''t worry about people extracting your resources anyway. If they do it for something that''s just for fun, don''t complain. Your work is getting out there. That''s called advertisement, and it''s a GOOD thing. If they do it for something commercial, you can prove that you developed those resources first, and that they are using them without your permission.

You''re still kind of missing the point. You can''t give users partial access to your resources. If they can get enough information to use it, they''ve got enough information to make a local copy of it. That''s a fundamental truth about data protection...

If someone else is imposing that restriction on you, find some other place to get the resources you need. There''s simply no way to not give clients information you''re giving them.

It all depends on who you need to protect your resources from. If you just need to protect your resources from curious non-programmers armed with Windows Explorer and Winzip, then you might get away with just implementing Adobe-style encryption (encryption that is ridiculously easy to break, such as ROT-13) in the routines that handle the I/O between memory and disk. This could be easily implemented if you use Java''s stream architecture to handle I/O as it would allow your current input and output streams to be wrapped with streams that handle encryption and decryption.

This scheme will probably not stop a programmer though. It will also not protect your graphics from being extracted from the game using the screenshot feature of most OSs. Even if you could disable the screenshot feature, people could still snatch the graphics off the screen by photographing the screen with a regular camera. It is really hard to secure anything that you send to computers that you do not control. It is mainly a question of how interested people are in extracting your resources and how much work they are willing to put into it.

While it might be worthwhile to give your resources minimal protection against casual users, such as the scheme described in the first paragraph, you would probably be wasting your time if you would implement any defenses that are harder to get around than scanning the memory of the computer. After all, your program is going to have to access the resources in memory so an attacker that can scan the memory can always extract the resources from there.

Henry

If you are looking for a easy way to secure files from casual capturing then all you need to do is obscure the files.

I''de create a new iostream filter for your application and use something as simple as a 1 byte "key" that get''s xor''ed with all of your data comming through it. For each set of graphics you assign it a key that will allow your io strams to decode it. If you are parinoid you could even have the applet download the keys one at a time from the server after some sort of handshake.

Going up from there you could obscure the file per block ( say 1k ) using a xor''ed number based on your key and a PRNG.

Up from that you are really talking about encryption of the files with a real encoder.

This will, and nothing will, stop the persistant people.

quote:
Now, I might be very confused about this. Are you saying that users who open this applet in a browser will have the same access to all the resources, even though they are not getDocumentbase ed or paint() ed,
that they have the same access that they would if I handed out the .jar file?

Well, you realize that applets and the resources they request off of their server are loaded via HTTP GET requests. If you know the URL, you can get everything through a standard web browser. And disassembling the .class files will get all the necessary URL''s, with a bit of work. (And don''t think obfuscating the .class files will stop that. They still have to be legal .class files, which means that they can be easily disassembled by those who know the JVM instruction set. Because of my work, which happens to be working on a program that modifies .class files at the bytecode level, I''m one of them.)

If someone''s looking, they''ll have no trouble getting the resources. I recommend snowmoon''s approach, or even something simpler. Just use a custom file format. Those who don''t have technical skill won''t be able to deal with that. Those who do have technical skill can''t be stopped anyway, so don''t waste your time trying to prevent it.