I need to protect my .jar from reverse-engineering, because it accesses my server to save game data.  Over a thousand people are creating characters on the server per day, and while I'm thrilled about the interest, the risks seem to be increasing also.  Can anyone recommend a .jar obfuscation program/method for Processing's exported applications?

In addition, it would be nice to include a password for the saved-game folder, and tell the postdata script to use it when accessing the data.  Is this possible with URLconnection?  I want to do this because otherwise anyone can potentially write a script to mess with the chmod 777 folder.

Thanks,
Ben

PhiLho  wrote on May 14^th, 2009, 5:07am:


What I mean by the second question is: currently, users post data to a folder set with full read/write access, because that's required by the postData process and the .php script it uses.  So if someone extracted the URL of that folder, they could easily mess with my server and all the game data stored there.  The players' saved game passwords are all Sha-256 encrypted, so they're secure.  It's just my server backdoor that worries me.

Would the "clear data" method allow users to post data to my server  Would it make the read/write access unnecessary  I'm not familiar with it.

thanks for your help (again!) -- Ben

Ok, so should the chmod of the save folder not be 777 (read/write for all users)?  I tried changing that and found the php script didn't work...  The reason I still see a security problem with the .jar is that a really enterprising individual could take it apart, find the bit of script that talks to the .php file, and write their own java / processing program to send bogus data to it.  Thanks, Ben

(remember: just because you're paranoid doesn't mean they're not out to get you)

Ok, that's reassuring.  Still, it wouldn't be hard to write a script to erase someone else's game data (by replacing it with a legitimate-looking saved state).  Or to boost one's own game.  I guess I will look into serializing the data or encrypting it in some way that can be un-done...to at least make that more difficult.

I obfuscate values from Cheat Engine at work by creating a random number variable and storing the value added to that random number. Here's a Processing paraphrase of what I'm doing in Flash:

Code:

class HiddenFloat{
  float r, v;
  HiddenFloat(float v){
    setValue(v);
  }
  HiddenFloat(){
    setValue(0);
  }
  void setValue(float v){
    r = new random(1, 1000000);
    this.v = r + v;
  }
  float getValue(){
    return v - r;
  }
}
 

The actual value is never in memory to retrieve, and the random number that is used to hide it cannot be guessed. All values that have an impact on the game I wrap in a hidden number object.

Values we submit to the server are sent via some standard encryption code which was written before I got there. But the highscores still got hacked until I started using this method.

CheatEngine is quite a useful tool in itself though.

Of course, if somebody has too much free time on their hands, they can still decompile the class (but these can be obfuscated to make this reverse engineering harder, eg. with ProGuard).
But I suppose the method given by st33d is effective if the Cheat Engine just searches in memory a given number (the score, the bonus...).

Some things that will confuse most would be decompilers:

Short variable names. 'a' instead of 'apple' or better yet; 'q' instead of 'apple'.

Pick out some unicode characters that will look like regular letters but aren't. (Processing doesn't like this, I had to test it in another IDE)

I might get razzed about this but you can even use '$' and '_' characters.


Use bit-wise functions rather than multiplying/dividing.
(bonus points if you know what these do):
int x = (m << 3) + (m << 1);

int y = (b >> 1) + (b >> 2);



To get the benefit of these, you may have to edit the program outside of Processing. Especially to compile with variable names only for debugging info. Several decompilers I have tested will fill in their own variable names (ones easier to track).

It is easier to create a functional program with the variables you are familiar with, then use an IDE with a refactor function to change the names (or find an obfuscator as mention before).

Remember though, if someone is persistent, there is no way to stop them. Java is just too well documented.

Edit: another fun trick is to use the same variable names in as many locations as possible (allowed by scope). Of course, don't do this while debugging.