Prev: Online survey jobs & data entry jobs
Next: Math.random() and Math.round(Math.random()) and Math.floor(Math.random()*2)
From: Stefan Weiss on 1 May 2010 14:39
On 01/05/10 20:06, Pedro Machado Santa wrote:
> Concisely, I want to protect fake score submission, either by using
> javacript console to run calls/commands and by altering the code and
> running it locally and thus submit fake scores, from players with
> hackers skills wanting to figure on a top ten.
>
> I thought of a possible solution wich was to send to the server the
> game state in each play - or in my case in each frame, since it's a
> racing game - and run the game and validate the "trajectory" on the
> server, but I was wondering if there was a less call intensive way to
> accomplish this.
>
> Right now, I think that the most cost effective - even though not high
> but reasonably secure - would be to, on a game start, send to the
> client some sort of random key that would be used to verify game
> condition calls, and somehow hide that key from the user.

I don't see any way to do what you propose that couldn't be broken by a
sufficiently motivated player. Keys and hashes won't work: the client
must have everything that's necessary to post the score - code, key,
etc. Everything you send can be easily read and modified to suit a
hypothetical attacker's needs.

If you monitor the player's progress, you'll need to decide on the
server side what "too fast" or "too good" means - and even then the
client side code could (in theory) be modified to emulate a "very good"
player. The only way to prevent bots from playing better than a human is
to add game elements that can't be solved by a computer fast enough to
be useful.

IMO, the best you can do is make it not worth their while, i.e. don't
offer any incentment like prizes. Using a script minifier to replace
(obfuscate) the JS identifier names can help, but it's only a minor
annoyance for hackers with too much time on their hands.


--
stefan
From: VK on 1 May 2010 15:29
On May 1, 10:16 pm, Pedro Machado Santa <pedro.sa...(a)gmail.com> wrote:
> I think that making the source code not visible it's a very weak way
> to secure the game because Javascript is plain text and I don't know
> of a proper way to do that "cloaking".

Right. I mentioned this option only to say - you would confirm that -
that it does not help.

> Another way to do that it's make sure that the server calls are only
> originated from the javascript code, and not from any type of console,
> and to make sure that the Javascript wasn't altered - I was thinking
> if I can use some sort of hashcode to do that.

And how that would be implemented? It is easy to store the "proper"
hashcode server-side. But it is as easy to find the hashcode
calculating function client-side and to replace it with
{
// The first statement is fully optional of course.
scoreSubmitAjax.setRequestHeader('Freedom-rulez', 'Ha-ha-ha');
return precalculatedHashCodeOfUnalteredSource;
}

You can write a Java applet with an empty display area of the page
background color of size 11px x 11px (the minimum size implied by
security restrictions) and place it somewhere where it doesn't affect
page layout. Let it periodically monitor the game state by querying
JavaScript functions and variables and submit results to
ServerListener over non-standard TCP/IP packets using DatagramSocket
on a particular non-HTTP port. That's something JavaScript cannot do
by definition. If someone hacks Java code as well, alters it to the
needed way and runtime planted into page then just give him/her that
damn prize - the worked really hard for that... :-)

Just one of crazy ideas of mine... Overall I do agree with Stefan
Weiss.
From: nick on 1 May 2010 18:39
On May 1, 12:43 pm, Pedro Machado Santa <pedro.sa...(a)gmail.com> wrote:

> I want to distribute a simple game on the web using Javascript and
> HTML5 and to keep record time scores on the web. But for that I want
> to protect client-side execution of some scripts and Ajax calls.

I think the game would have to use a server / client model where the
game state info is maintained by the server and then pushed out to the
clients.

Say the whole game is this: While you hold the 'D' key, your player's
X velocity increases by 1 game unit per tic every tic, up to a max of
30 units per tic. When you release it, the X velocity decreases by 1
unit per tic until it reaches 0.

Now, you could just let everyone play, and whenever someone crosses
the finish line, their client sends the server 'i won,' the server
sees how long the race has been going and adds the winner to the
scoreboard. Obviously this can be hacked.

The thing to do is have the client always send *messages* to the
server... Every tic the 'D' key is held, client tells server "I'm
moving right." Immediately client uses client-side game physics
routine to move the actor right for visual feedback. When message
arrives from client, server does its physics routine (same routine as
client if client is unaltered) and calculates actor's position also.
When it is done, it calls back to client and the displayed position
based on client physics is replaced with server's calculated position,
which will ideally be close to identical to what the client calculated
(user shouldn't notice the change) if the network latency is low.

Now, if the client tries to cheat and sends the server some crazy
message like "hey, I'm moving at 1000 game units per tic," and even if
their hacked client supports showing this to the user and sending it
to the server, the server will reject the bogus input and the client
can be disconnected or left to suffer with broken gameplay.
From: Thomas 'PointedEars' Lahn on 1 May 2010 18:58
VK wrote:

> [...] Let it periodically monitor the game state by querying
> JavaScript functions and variables and submit results to
> ServerListener over non-standard TCP/IP packets using DatagramSocket
> on a particular non-HTTP port. That's something JavaScript cannot do
> by definition.

Nonsense, it can. But an API that provides the capability (such as XPCOM)
and a privileged environment are required.


PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: VK on 1 May 2010 21:42
On May 2, 2:58 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> VK wrote:
> > [...] Let it periodically monitor the game state by querying
> > JavaScript functions and variables and submit results to
> > ServerListener over non-standard TCP/IP packets using DatagramSocket
> > on a particular non-HTTP port. That's something JavaScript cannot do
> > by definition.
>
> Nonsense, it can.  But an API that provides the capability (such as XPCOM)
> and a privileged environment are required.

I am not aware of XPCOM tools
https://developer.mozilla.org/en/XPCOM_API_Reference
providing the functionality of Java's Datagram and Socket tools:
http://java.sun.com/j2se/1.4.2/docs/api/java/net/DatagramPacket.html
http://java.sun.com/j2se/1.4.2/docs/api/java/net/DatagramSocket.html
http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html

Is there a better documentation than of MDC?
First  |  Prev  | 
Pages: 1 2
Prev: Online survey jobs & data entry jobs
Next: Math.random() and Math.round(Math.random()) and Math.floor(Math.random()*2)