Best way to hide some game variables from editing in Firebug ?

[tomas.polz]

Hi guys, I was wondered, what si the best way to prevent some "clever" players to open Firebug and debug values of some variables contaitng quite secret information about game. ?

I know you can put important informations and algorithms on server side and that fronted javascript is imposiible to hide, but doing some some stuff on client side would save a lot execution time on server side.

Is there any "Phaser" way to do it ?

[lewster32]

The term you're looking for is 'obfuscation' or 'JavaScript obfuscator' so you can Google that if you want to find tools which make your code harder to read and thus interfere with. There's unfortunately no way to completely hide your code as it runs on the client in the end, and anyone with enough skill could reveal your code. You could wrap all of your code in a closure to prevent any of the variables inside 'leaking' and becoming editable if you're simply worried about people accessing and modifying things, like this:

(function() {  // your code here...})();

Providing you don't attach any variables to any of the globally accessible objects (usually window) and you ensure any variables are defined with 'var' rather than just implicitly defined, none of the objects or variables should be accessible or editable from the debugger.

(function() {  // This will be hidden within the closure and not accessible from outside  var text1 = "1";  // This will be accessible outside of the closure - don't ever define vars like this!  text2 = "2";})();text1 > ReferenceError: text1 is not definedtext2 > "2"

[chg]

The term you're looking for is 'obfuscation' or 'JavaScript obfuscator' so you can Google that if you want to find tools which make your code harder to read and thus interfere with. There's unfortunately no way to completely hide your code as it runs on the client in the end, and anyone with enough skill could reveal your code. You could wrap all of your code in a closure to prevent any of the variables inside 'leaking' and becoming editable if you're simply worried about people accessing and modifying things, like this:

(function() {  // your code here...})();

Providing you don't attach any variables to any of the globally accessible objects (usually window) and you ensure any variables are defined with 'var' rather than just implicitly defined, none of the objects or variables should be accessible or editable from the debugger.

(function() {  // This will be hidden within the closure and not accessible from outside  var text1 = "1";  // This will be accessible outside of the closure - don't ever define vars like this!  text2 = "2";})();text1 > ReferenceError: text1 is not definedtext2 > "2"

Obfuscation sounds good, it makes your files smaller and improves compression ratios too right? But I disagree with the assertion that using local variables to a self executing anonymous function in place of globals variables and functions gives you significant protection.

Firstly, if you can set and trigger a breakpoint in a function then I think you can look at that function's locals in a browsers debugger. I was recently playing with the IE11 debugger, and know that you can set a breakpoint in an initialisation function well after it has executed and returned, then simply refresh the page to hit the breakpoint - I would be very surprised if Firebug or the Chrome developer tools or whatever didn't offer the same.

Secondly, it's not that hard for a tinkerer to actually modify the code seen by the browser to something they can reverse engineer more easily - even if they can't save an entire copy of the site and run it locally (in the case of a game that needs dynamic data from the server), there a free and easy to use tools that act as a proxy, sitting between the server and your browser, and let you rewrite the server's responses as you see fit.

As an "attacker" (well not really) I have been discouraged by voluminous machine generated JavaScript - the specific case was several megabytes of GWT generated code... I only cared to dig into that a little, when I had to.

I have my suspicions that a hundred kB or so of phaser code even obfuscated, mightn't be that unreadable if the code itself is readablely well structured, at least after running through a beautifier, especially if the phaser classes and method names are not obfuscated in the code.

EDIT: I should mention, in my experience JavaScript packers (the sort that manipulate code as a string and then eval() it) are also pretty simple to get the unpacked code out of. Even before tools like Firebug; you could just copy-paste the code to the console with a minor tweak to get at the unpacked code...

[lewster32]

I never said it was a perfect method by any means, but it does stop people simply typing into the console to access and modify stuff. Like I said, there's no real fool-proof way to perfectly obfuscate code executed on the client.