PDA

View Full Version : Client. vs Clientr.


wild8900
01-02-2008, 10:59 PM
Hey this is probably a really stupid question but Ive never been too sure.
From what I know, clientr. variables are more secure but you can only change them serverside, usualy with triggeractions (pain in the ass). But Im told client. variables can be edited clientside.

I was thinking of using some values in client. vars, should I? Its quicker and doesn't use triggeractions. Less lag right?

Codein
01-02-2008, 11:00 PM
Well, first you should weigh up what you're using them for. If it's information you wish to be kept secure.

What are you storing in it? Then maybe I can help you decide what prefix to use.

Angel_Light
01-02-2008, 11:02 PM
If you are storing gralats or or money you should use clientr. also if you arn't invoking an action on a x/y you should use triggerserver, not triggeraction.

Chompy
01-02-2008, 11:04 PM
Well, as Codein said, it depends on what you are making. Clientr is often used for security, ie storing MD5 encrypted passwords for comparision or if you don't want it to be edited clientside.

Should provide more info tho :)

Twinny
01-02-2008, 11:41 PM
Think of it this way: What don't you want hackers changing with a memory editer :p. If it's something like a flag saying your radio is playing then client.radio =1 is fine. If it's something like your characters expierence, clientr.exp would be more appropriate. If it's important: clientr. it.

DustyPorViva
01-03-2008, 12:15 AM
Ya, less important things that wouldn't effect gameplay if hacked is what you'd use client.vars for. Things that would give benefits for the player if they were able to hack them are for clientr.vars, like a speed var for your movement, damage vars, and so on.

cbk1994
01-03-2008, 01:47 AM
Just a note, for things which you need client. for, but you need secure, I would use base64encode() and base64decode() ... would work best if you did it a certain number of time such as this:


function encodeText( text )
{
temp.t = text;
for ( temp.i = 10; temp.i < 10; temp.i ++ )
{
temp.t = base64encode( temp.t );
}
return temp.t;
}
function decodeText( text )
{
temp.t = text;
for ( temp.i = 0; temp.i < 10; temp.i ++ )
{
temp.t = base64decode( temp.t );
}
return temp.t;
}


I've used this for gun systems and such where you need to store things that change on the dot (such as ammo), yet need to be hard to hack. For HP or experience, clientr all the way.

Codein
01-03-2008, 02:25 AM
Just a note, for things which you need client. for, but you need secure, I would use base64encode() and base64decode() ... would work best if you did it a certain number of time such as this:


function encodeText( text )
{
temp.t = text;
for ( temp.i = 10; temp.i < 10; temp.i ++ )
{
temp.t = base64encode( temp.t );
}
return temp.t;
}
function decodeText( text )
{
temp.t = text;
for ( temp.i = 0; temp.i < 10; temp.i ++ )
{
temp.t = base64decode( temp.t );
}
return temp.t;
}


I've used this for gun systems and such where you need to store things that change on the dot (such as ammo), yet need to be hard to hack. For HP or experience, clientr all the way.

I could think of ways to make ammo serversided, which includes a way to overcome the initial client - server lag.

A smart game hacker could use the lead that servers use base64 encoding. If the hacker was worth his salt, he'd easily find the the amount of times you've base64 encoded a value and then decode it from there. I had an example in my head on how I'd get round but a) It's lost now and b) I'm not sharing it publicly.

My idea was this:

Say if you have your finger on the shoot button, a temp variable would count how many bullets have been shot and then after you release the button, it'd subtract this amount from your clientr.ammo. I don't know how practical it is though. Also, this way, it doesn't matter who's shooting and who's not. It might cause a bit more lag than you'd want for the whole server but definitely less lag than taking off the ammo every time a projectile is launched/fired and definitely more secure than client. flags. Maybe a combination of my idea and base64 encoding so that hackers can't just hold down the ammo button and find the address for the client variable.

I'm not sure though, just a thought.

Skyld
01-03-2008, 02:33 AM
I could think of ways to make ammo serversided, which includes a way to overcome the initial client - server lag.

A smart game hacker could use the lead that servers use base64 encoding. If the hacker was worth his salt, he'd easily find the the amount of times you've base64 encoded a value and then decode it from there. I had an example in my head on how I'd get round but a) It's lost now and b) I'm not sharing it publicly.
I wrote this encryption example (http://skyld.vip.graal.net/wikka.php?wakka=ExampleEncryption) a while ago for this sort of problem.

Codein
01-03-2008, 03:12 AM
I wrote this encryption example (http://skyld.vip.graal.net/wikka.php?wakka=ExampleEncryption) a while ago for this sort of problem.

Ah, perfect. Now there's no need for my serverside ammunition, which'd cause unecessary in light of a secure clientside ammunition method. I didn't notice it on your wiki, of which I often read. Not lately though, I've noticed most of the links are underlined in read, meaning they don't exist.

cbk1994
01-03-2008, 06:28 AM
I could think of ways to make ammo serversided, which includes a way to overcome the initial client - server lag.

A smart game hacker could use the lead that servers use base64 encoding. If the hacker was worth his salt, he'd easily find the the amount of times you've base64 encoded a value and then decode it from there. I had an example in my head on how I'd get round but a) It's lost now and b) I'm not sharing it publicly.

My idea was this:

Say if you have your finger on the shoot button, a temp variable would count how many bullets have been shot and then after you release the button, it'd subtract this amount from your clientr.ammo. I don't know how practical it is though. Also, this way, it doesn't matter who's shooting and who's not. It might cause a bit more lag than you'd want for the whole server but definitely less lag than taking off the ammo every time a projectile is launched/fired and definitely more secure than client. flags. Maybe a combination of my idea and base64 encoding so that hackers can't just hold down the ammo button and find the address for the client variable.

I'm not sure though, just a thought.
I was just giving an example of a way to do it. Obviously you would want something better. I was thinking on Skyld's example he posted below, but I couldn't find it.
I wrote this encryption example (http://skyld.vip.graal.net/wikka.php?wakka=ExampleEncryption) a while ago for this sort of problem.
That's the one, I searched all over the wiki and couldn't find it. Shouldn't you add it to the official wiki, seeing as you are kinda the leader of the GST in a way, and uh ... that's sorta your job ... adding things to the wiki ... Can't just expect normal players to do it.

coreys
01-05-2008, 06:25 AM
Really I don't like to use clientr. flags to "store" information, really. I use it as a reference of sorts, I like to store important information like a players HP, money, etc, in objects and files and reflect those to clientr. flags so that they can be easily read.

But, like I've said before, I've come across an odd problem where clientr. flags can be set clientside.

Chompy
01-05-2008, 04:30 PM
Really I don't like to use clientr. flags to "store" information, really. I use it as a reference of sorts, I like to store important information like a players HP, money, etc, in objects and files and reflect those to clientr. flags so that they can be easily read.

But, like I've said before, I've come across an odd problem where clientr. flags can be set clientside.

Yeah, before I experienced that with movement systems that used and battle systems, if someone setted clientr. clientside with a wnpc, they are stored locally at the player. And when you like, press s and a trigger will be sent, and that clientr. string that is stored locally will be sent..

Dunno if this is fixed or all, because using objects and comparison serverside fix insexure stuff like that..

napo_p2p
01-05-2008, 10:00 PM
Yeah, before I experienced that with movement systems that used and battle systems, if someone setted clientr. clientside with a wnpc, they are stored locally at the player. And when you like, press s and a trigger will be sent, and that clientr. string that is stored locally will be sent.. You don't need to send clientr. flags through triggers in the first place...

However, I also use a system where important values are stored in objects and reflected to clientr. flags. Just seems more secure.

Chompy
01-05-2008, 10:21 PM
You don't need to send clientr. flags through triggers in the first place...

However, I also use a system where important values are stored in objects and reflected to clientr. flags. Just seems more secure.

Yes, but I did that sometime in 05-06, gs1 :(

Now I use objects and clientr flags.

coreys
01-06-2008, 11:32 PM
Yeah, I always use objects with variables reflected to clientr variables. But that can still be insecure, since, even if you refresh it everyone once in awhile, or whenever a change is made (what I do) someone can still set a clientr variable in a WNPC or level. But if you have a tight enough security with your staff (meaning you see everything made by your staff, including all level scripts, classes, DBNPCs and WNPCs) that shouldn't be a problem. I'm not entirely sure how hex editing or hacking works myself, I've never bothered to learn, so I don't know if that's a possibly way to abuse that "glitch" (of sorts) with clietr flags.