• Advertisement

Archived

This topic is now archived and is closed to further replies.

Different uses for script-bytecode...

This topic is 5486 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Would it be a good idea to use bytecode for ones scriptingsystem to send data over the network, ie, client/server-communication. ...and then just running the chunk of data through the VM to update the states on the current machine? I can think of other uses as well, why not let a separate AI-thread (or what ever) communicate state-changes to the engine using just bytecode. How does it sound to you? am I overlooking something? other possibilitites? /Niklas Andersson

Share this post


Link to post
Share on other sites
Advertisement
No thoughts at all?

Has it been done? Would it compilcate matters more than it would help?

oh, well *bump*

/Niklas

Share this post


Link to post
Share on other sites
No thoughts at all?

Has it been done? Would it compilcate matters more than it would help?

oh, well *bump*

/Niklas

Share this post


Link to post
Share on other sites
I think I''ll bump this one last time...

I really want to believe that someone else have had thoughts about this kind of ...thing


/Niklas

Share this post


Link to post
Share on other sites
Tell you what, I''ll play a game on that engine with you, and I''ll bet you a million I''ll win. Depending on how powerful your scripting system is I could do anything from sending your game character into outer space to running "format C:".

Running any kinda crap you pick up from a network socket through a VM parsing it as instructions is what most security experts spend all their time making sure they can avoid doing. And what about memory accessing? Are you sure things will be in exactly the same places on the receiver end as on the sender end? This classifies as one of those remarkably bad ideas...

What do you have to win on the idea anyway? You''d just send more data than necessary over a network socket.

Share this post


Link to post
Share on other sites
First of all the scripting-system would not have privileges to format c: or anything else that don''t have anything to do with the game engine for that matter.

Second, at some point you will just have to trust the data recieved to be "correct", that goes for any kind of network communication. Every kind of error- / correctness-checking you can do on "normal" recieved data you can do on the recieved bytecode. And to put it the other way aroud, if you could send fake bytecode to put my game character in outer space, I can''t see that it would be any harder sending fake data in a "normal" network comunication scenario.
If the VM is stable I actually think my approach is safer than sending raw data, since the updates would not be written directly to memory

The same goes for for the memory issue. It would be plain silly to send pure memoryadresses, you don''t have to when you send data the more conventional way, so you would I need to do it when sending bytecode?

The advantage with sending bytecode as I see it is that the updating of the worldstate could be kept to one single codepath.

/Niklas

Share this post


Link to post
Share on other sites

This is a good idea. What you have is a portable RPC module and it makes thing very element because things can act as if things are running on the client but they really are done somewhere else. Passing the actual code string is also interesting, but it depends on how you script works.

Stary :
In a client/server environment for a game, the client knows which object it can act upon and the server of course has all the objects.

So if the client sais ( objectA.ShootGun ) the server will have no problem whatsoever to find objectA.

The issue that could write a tool to send anything to the server is the same as if you were just having a special client/server command language.

[edited by - Gorg on February 13, 2003 1:10:31 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Nirklas
First of all the scripting-system would not have privileges to format c: or anything else that don''t have anything to do with the game engine for that matter.


I bet you my finger that any skilled "cracker" could find a loophole to exploit your system in a day or two.

quote:
Second, at some point you will just have to trust the data recieved to be "correct", that goes for any kind of network communication.


Ouch! You really think so? You seriously need to go and take a class on network programming in the real world then - the first rule of any network programming is: Never assume that the data you receive is anything but malicious.

quote:
Every kind of error- / correctness-checking you can do on "normal" recieved data you can do on the recieved bytecode.


Then your scripting engine is so limited I can''t imagine. You can check that normal data is within the values but you can never ever check that a program code will give results that you expect. Unless your scripting language is not even Turing-equivalent, in which case it''s really not even a programming language.

If you''d go a course on computer science you''d learn about the concept of undecidability. Undecidability means that it''s theoreticly impossible to create an algorithm that would solve the question by answering "yes" or "no" even given any finite amount of time. Determining if a given algorithm will ever stop is one such problem - which makes it trivial to show that determining whether or not an algorithm will both stop and respond within any given range.

quote:
And to put it the other way aroud, if you could send fake bytecode to put my game character in outer space, I can''t see that it would be any harder sending fake data in a "normal" network comunication scenario.


Consider the following simple "pong" style network protocol:

- I receive a packet. The packet contains how much you''ve moved your pad up or down.
- I check that the data you sent me is within a set limit so that you''re not cheating.
- I move your pad in my game as well and send you my packet.

It''s impossible for me to move your pad in the above scenario, but given a stream of bytecode doing "stuff" to "update the world state" of my pong engine, i''m quite sure I could glue your pad in the lower right corner of the screen.

quote:
If the VM is stable I actually think my approach is safer than sending raw data, since the updates would not be written directly to memory


No, so where do they go, onto disk? Actually, if I receive a normal network packet it ends up where I say it should go, not wherever itself wants to be...

quote:
The advantage with sending bytecode as I see it is that the updating of the worldstate could be kept to one single codepath.


What exactly do you mean by what? Instead of:
- I get data and store it where I want it.

you want:
- I get data and run it through my scripting engine which does undefined "stuff".

I don''t see the advantage here really.

Share this post


Link to post
Share on other sites
quote:

I bet you my finger that any skilled "cracker" could find a loophole to exploit your system in a day or two.



You know why activex has loopholes? Because there are functions to give low-level access the machines.

If you build your VM has a sandbox that has only access to objects in the game then you cannot go and grab things off the machine.

Though it does not stop them from writing a trainer. And the trainer is not more easier or harder to write than the raw data way.

In your Pong example. You mention that when you receive the data and then do some checking. The VM byte code represents commands to do. The server can still check if those commands are valid within the context of the application. So If the client sends

me.Move( 100, 100 )

but the maximum a paddle can move per update is 5 units, then the server side Move function will do the check to see if it the calls fits the requirements or not.

[edited by - Gorg on February 13, 2003 1:50:02 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Gorg

I bet you my finger that any skilled "cracker" could find a loophole to exploit your system in a day or two.



You know why activex has loopholes? Because there are functions to access the machines.

If you build your VM has a sandbox that has only access to objects in the game then you cannot go and grab things off the machine.

Though it does not stop them from writing a trainer. And the trainer is not more easier or harder to write than the raw data way.
[...]


The problem with the scripting language idea is that it is more complex. The more complex something is, the easier it is for bugs to be introduced. The more bugs there are, the easier it is to abuse. If you use a static array somewhere in your VM and you don't do bounds checking every time you access it(among other checks), you could easily end up with a buffer overflow, or some other 'simple exploit'. The problem exists even if you don't use your scripting language for the network protocol, but its harder to exploit because the hacker will have to make a level with the bad script and get people to run it. If it's run automatically from the network, he/she can just join a game and send the malicious code across the internet and he now has total control over their PC and can do whatever he wants including running aritrary code.

[edited by - Extrarius on February 13, 2003 1:54:54 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Extrarius


The problem with the scripting language idea is that it is more complex. The more complex something is, the easier it is for bugs to be introduced. The more bugs there are, the easier it is to abuse. If you use a static array somewhere in your VM and you don't do bounds checking every time you access it(among other checks), you could easily end up with a buffer overflow, or some other 'simple exploit'. The problem exists even if you don't use your scripting language for the network protocol, but its harder to exploit because the hacker will have to make a level with the bad script and get people to run it. If it's run automatically from the network, he/she can just join a game and send the malicious code across the internet and he now has total control over their PC and can do whatever he wants including running aritrary code.

[edited by - Extrarius on February 13, 2003 1:54:54 PM]


I agree with you. But if I may:

A scripting language is actually simpler. Especially one where when do RPC you actuall send the line of code that gets re-interpreted by the VM. That makes for a very simple server.

You are missing the point that if the VM you wrote does not give access to os-level feature of the machine, the hacker CANNOT get access to them. That means not script function to open a file, not script function to write to file, etc. Only game related stuff. If the some scripts needs to access os feature, it should do it in a high-level way, where the details of access are not controled by the script call, but by the need to the call. e.g. if you want to load a model, you don't open the file, you request to load the model with it's name. I will agree that most of the time, it is not a trivial task, but for a video games, the actions that can be done using a script language can be implemented without giving control of the os-feature.

It has been done before you know. Python has a sandbox, Java as a sandbox, many other tech I don't know about have a sandbox.

Stop spreading fud people. A network command is a network command whatever way you send it. There is nothing different to sending a line of code then sending some chunk of data to a server with a CommandId and command arguments.

[edited by - Gorg on February 13, 2003 2:17:38 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Gorg

Original post by Extrarius
The problem with the scripting language idea is that it is more complex. The more complex something is, the easier it is for bugs to be introduced. The more bugs there are, the easier it is to abuse. If you use a static array somewhere in your VM and you don''t do bounds checking every time you access it(among other checks), you could easily end up with a buffer overflow, or some other ''simple exploit''. The problem exists even if you don''t use your scripting language for the network protocol, but its harder to exploit because the hacker will have to make a level with the bad script and get people to run it. If it''s run automatically from the network, he/she can just join a game and send the malicious code across the internet and he now has total control over their PC and can do whatever he wants including running aritrary code.

[edited by - Extrarius on February 13, 2003 1:54:54 PM]


I agree with you. But if I may:

A scripting language is actually simpler. Especially one where when do RPC you actuall send the line of code that gets re-interpreted by the VM. That makes for a very simple server.

You are missing the point that if the VM you wrote does not give access to os-level feature of the machine, the hacker CANNOT get access to them. That means not script function to open a file, not script function to write to file, etc. Only game related stuff. If the some scripts needs to access os feature, it should do it in a high-level way, where the details of access are not controled by the script call, but by the need to the call. e.g. if you want to load a model, you don''t open the file, you request to load the model with it''s name. I will agree that most of the time, it is not a trivial task, but for a video games, the actions that can be done using a script language can be implemented without giving control of the os-feature.

It has been done before you know. Python has a sandbox, Java as a sandbox, many other tech I don''t know about have a sandbox.

Stop spreading fud people. A network command is a network command whatever way you send it. There is nothing different to sending a line of code then sending some chunk of data to a server with a CommandId and command arguments.

[edited by - Gorg on February 13, 2003 2:17:38 PM]


You are not realizing that it doesn''t matter what the scripting language allows. If you have a buffer overflow, the hacker can run ARBITRARY MACHINE CODE on your system. Even if your script just allows simple math expressions like "x = y + 5" it is still possible that there is an exploit that could allow the hacker to take complete control of a system. The scripting language doesnt need features, it just needs a bug or two and a good hacker can abuse it to no end.

Share this post


Link to post
Share on other sites
quote:
Original post by Extrarius
You are not realizing that it doesn't matter what the scripting language allows. If you have a buffer overflow, the hacker can run ARBITRARY MACHINE CODE on your system. Even if your script just allows simple math expressions like "x = y + 5" it is still possible that there is an exploit that could allow the hacker to take complete control of a system. The scripting language doesnt need features, it just needs a bug or two and a good hacker can abuse it to no end.


I understand that, but it is just a bug. Buffer overflow are because you have static buffers and are not checking the bounds. Just fix it or use dynamic buffers.

This is not an argument against using his idea. It is just an agurment to write bug free software.





[edited by - Gorg on February 13, 2003 4:07:56 PM]

Share this post


Link to post
Share on other sites
Anyway, bug or not, this idea was used to build the multiplayer support for Dungeon Siege. The server/client comunication takes place on a layer built on top of Skrit, the scripting system Dungeon Siege uses. So, if it''s good for DS...

Fire burn wisdom in me,
Wisdom set mind and spirit free,
Moonlight shows me the mysteries of life,
Winternight gives me clearsight and storms to fight.

Share this post


Link to post
Share on other sites
It's an argument against making things much more complex than needed and an argument agains "but if you don't directly let them, they can't do it".

I don't think its a bad idea, I think you would just need to very very careful with the implementation. I think a better idea might be to send say mouse clicks and button presses over the network and have the game figure out what script should be run in response to that button press. It would be much less likely to be abusable imo, since you would be simulating all players on all computers. It would also be difficult to cheat (except for map-hack style cheats). Validating the data would be easy as well since an invalid key wouldn't have a script mapped to it and nothing would happen.

Edit: It wasn't good for DS. I found the game to be fairly laggy when playing with just 1 other person. Both of us have broadband and our computers are good enough to run it fairly fast, but the person that wasn't hosting would experience lag quite often, and one in a while response times would rise to minutes.

[edited by - Extrarius on February 13, 2003 5:14:02 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Extrarius

I don't think its a bad idea, I think you would just need to very very careful with the implementation. I think a better idea might be to send say mouse clicks and button presses over the network and have the game figure out what script should be run in response to that button press. It would be much less likely to be abusable imo, since you would be simulating all players on all computers. It would also be difficult to cheat (except for map-hack style cheats). Validating the data would be easy as well since an invalid key wouldn't have a script mapped to it and nothing would happen.

[edited by - Extrarius on February 13, 2003 5:14:02 PM]


Try it. You will see it is not more complex. It is actually very elegant.

Sending clicks does not help for trainers and is as difficult to validate. You are not worried about receiving bad commands, that's just something you get somethimes, what you are worried about is a tool that moves the character on it's own. The problem is the same for clicks or script

Also, sending key presses is very weak and inflexible protocol. Sending commands is more usefull because the triggering of the command is independant of the actual data of the command. Once you start using a command protocol you actually have created a script language. The only difference with full script is that there has to be a conversion from client to command languge and from the command language to server. By sending actual code, there is no conversion.






[edited by - Gorg on February 13, 2003 8:52:52 PM]

Share this post


Link to post
Share on other sites

  • Advertisement