Java applet caching

Networking & Multiplayer
#1

Hi All!

I recently was surprised to find out that it’s possible to replace a cached applet with another modified version. I was able to decompile my cached game applet, recompile it with an modified version (that fx send a very high score to my score upload script), place it back in the cache directory and the jvm would just run that modified applet! :o (I always thought the jvm used the hash from the cached jar to compare to the one on the server, if they wouldn’t match download the server version and run that one instead)

I know I should obfuscate the classes to make it more difficult (I already did this), but any decent hacker would find out where the uploading part takes place anyway.

The problem seems to be one that many of you have encountered before (but i’ve never really read anything about it) How can the server tell the score it receives is really from the untampered applet? I got the communication part all encrypted and 99% waterproof, but that obviously wont stop an tampered version from sending the correct data.

I’ve thought of 2 solutions, but I find both a bit clumsy:

1.) use a burnt-in key for each game downloaded. This gets injected before each download, so decompiling wont help because the next time you start it it will download another applet with a new key. This is ofcourse a costy operation on the server (id have to modify the class each time someone wants to download, further I couldn’t sign the thing and it would take much more bandwith as the game can’t be cached. Or a similar approach to use a rotating key (have fx 100 versions of the game all with a different key in them, still not practical and more easy to hack)

2.) use a loader class thats loaded from a different url each time. I believe the jvm caches files relative to the url they came from (so /123ab/loader.jar would be cached seperate from /123cd/loader.jar) so if we could make that url variable each time the loader will never be cached and we’d be sure its the untampered version that runs. (i haven’t tested this yet)

Im sure there must be some better way of cooping with this. I mean I can’t believe sites as pogo that offer big $ for highscores take the risk that some smart hacker being able to run his own version of their applet…

Any help is greatly appreciated!

-Thijs

#2

You can never trust the applet, or any other client. They can all be hacked.

Best bet is to send additional information with the highscore to verify it. Hove many times “fire” is pressed, how long it took to aptain the score etc. Then you can make a judgment call wether the score is valid or not.

Btw. An easy way to “hack” the score is to find where the variable is located in memory and modify it. So mangle your score variable.

Good luck.

#3

[quote]Hi All!

I recently was surprised to find out that it’s possible to replace a cached applet with another modified version.
[/quote]
This is mildly interesting but a waste of time. What I would do (to cheat) is:

  1. view source
  2. copy applet JAR url
  3. paste
  4. Select “save as…”
  5. …modify to heart’s content…
  6. run applet

So, you really shouldn’t care less about this caching affair. It’s easier for someone to get the applet and mess with it without bothering with this.

#4

Yes they can do that, but point is they have to start a game on the server to communicate with the scripts.

The server creates a session and establishes a sessionkey(used for encryption of further data) with the excecuted applet (it tells the applet the phpsession through some encrypted params). So if they’d want to run their own version and communicate with the server, easiest way would be to replace the modified version in cache.

I think I’ll just have to stick to obfuscation and mangle my internal gamelogic / scores as much as possible. Spreading it out over multiple variables and apply some bit operations over them with generated bit masks… And Ofcourse trying to send as much as posible reference possible for score validation server sided…

#5

I had another idea on this recently:

Lets say I have a loader applet wich loads the games. I also have an interface declared called Checker. We can also assume the loader applet has enough rights to perorm all actions, fx if the loader applet is signed:

-Now when the loader applet loaded the game jars (and cached them in some directory) it requests a new gamesession on the server.
-The server sends an serialized (Checker) object (instanciated with some arbitrary parameters only known on the server, which implements the interface Checker.)
-The loader runs the Checker object by calling methods defined in the Checker interface, fx Check(). The implementation defined at the server defines that it should return some object or value by doing checks at the loaded game classes with the arbitrary paramters in the object.

If the returned values dont match the expected result it stops the server sided gamesession. The check could fx do some checksum on the loaded game classes. The checksums should always be constant for non tampered classes. The user hasn’t got an easy way of interferring with this, since it should always execute the server injected object and has no clue what result the server expects back. There is no implementation defined at the client which should make things more difficult. Also the parameters which affect the result are only known on the server (and are executed in the instanciated object send)., but are very difficult to retrieve for the client right? Ofcourse they could intercept the serialized object and disassemble it, but that would get very difficult wouldn’t it?

What do you guys think of this approach?

#6

It’d probably help slow them down but in the end its always going to be cracked.

In the case you described I’d probably just write a wrapper round your Checker interface that told me what values were getting passed back to the server. Then I’d write a Checker implementation that always passed the correct values back to the server no matter what I did to the code. If you were then to change the checker (which it’d be worth checking for to prevent tampering detection) I’d let it run through the proxy again, recording the values and then connect again with my newly modified Checker implementation.

Not that it matter whether the above would or wouldn’t work, there’s always going to be a way. What you’ve described would make it harder but no client can ever really be trusted. The better design (as has been pointed out to me over and over) is simply not to trust the client and crosscheck everything on the server.

Kev

#7

[quote]It’d probably help slow them down but in the end its always going to be cracked.
[/quote]
True, I just want to make it as difficult for hackers as possible, but still keep it “practical”.
The point of it being possible to just run a modified version simply by replacing the version in cache makes it very easy for hackers. A test I did with some friends showed just that, without any knowledge of Java they where able to decompile, modify, recompile and run their own versions. Ofcourse i’d need to obfuscate and mangle gamelogic some more but it’s still not enough to rely on. Server sided checks are obviously best bet to pick out hackers, but since not all gamelogic is run server sided i’d like to secure the client part as much as possible.

[quote]I’d let it run through the proxy again, recording the values and then connect again with my newly modified Checker implementation
[/quote]
That wouldn’t work, because its not possible to extend the already instanciated object. The loader can only call the objects methods because it only knows the interface the object implements. Each game will return back different value’s though. The object itself is instanciated with random parameters on the server, valid only for that session. But you’re right, there’s always going to be a way around it… but it would surely be much more secure than the rely on obfuscation case.

Im just wondering how sites like miniclip-tournaments or pogo handle this kind of security issue’s. I dont think they handle all gamelogic server sided…?

#8

i think u are rite about the cathed applet that is exactly what happened to me and my applet ;D

#9

I think we should all come together and hack one of the better games at Pogo.com and win money to pay for JGF :wink:

#10

[quote]I think we should all come together and hack one of the better games at Pogo.com and win money to pay for JGF
[/quote]
Hehe, I can’t deny I’ve been peeking at their sources :wink:
Problem with pogo is that you win tokens which in their turn are your chance at winning something… this is why people outside the US can’t win prizes as such activities are illegal in most countries.

Actually i’ve found some online game sites where you could win stuff, that where very easy to hack! Just by monitoring the http traffic, then sending my own data… I won 80 euros of p0rn toys LOL :slight_smile:

But your idea made me thinking (no nothing illegal! :))… the project im involved in right now allows our company and resellers (sites that host our competitions) to get a % of the profit from these competitions. Rest of the money is for prizes (its a very big concept so I wont go in on that any further here).

Anyway if we’d make JGF a special reseller (maybe with more profit than usual ;), I think I could ‘convince’ my team mates to allow this ::slight_smile: )
And If JGF could pull enough visitors / players it might be an interesting alternative to advertising to get money for the site. (and hey it fits in! it are pure Java games after all!)