Ruby within Ruby

[Mike Zink]

The following is a description of my situation. You may not need to read
it, in which case, just skip to the part where it says "Enough of that,"
but you probably will need to read this.

I am trying to make an online text based "hacking" game. Like, the kind
where you infiltrate other people's computers and destroy their stuff.
Basically, the game will be like a mud, but P2P, since I don't have/want
to maintain a server for that kind of stuff. The game engine will be
stored locally on the players computer. During distribution, I will use
Ruby2Exe or similar so that players won't be able to tamper with files.
They will connect to a metaserver which will give them a list of
connected players, and add them to that list. It will store actual IP
addresses, so that the metaserver need not be contacted again. Also,
after the client gets the IP list, it will connect to the other players
on the list and tell them that they have connected. I am not expecting
the amount of players that mainstream MMOs have, so this shouldn't be a
problem. Actually, I'm not expecting any players, this is more of a
learning experience.

Now the important part. The premise of the game is hacking. Real hackers
(at least in this virtual world I'm creating) make their own tools.
Everything, with the exception of a few basic tools (like a "connect"
program for connecting to other players), will be player created.
Hopefully. Now to do that, I want the players to be able to write their
own Ruby scripts (and eventually maybe Python and Javascript) that will
only be able to use a few modules and classes that I will create, to
prevent people actually messing up other player's computers, and to keep
the game more balanced.

Those classes, by the way, are going to be pretty much the basic ruby
stuff, those for using an in-game filesystem, much like the File class,
and for communicating with other players, and any I feel necessary later
on.

Enough of that. The main obstacle I need to pass before being able to
make the game playable, other than some general design flaws, is letting
the player have interpreted Ruby scripts that they can create within the
game, and that will be run in the game. Basically, they need to have
access to the libraries that I created, but not any actual Ruby
libraries. The tricky part is that the libraries I created need access
to the actual Ruby libraries.

Is there any way to do this? Or another way to allow players to run Ruby
programs?

 

[Justin Collins]

The following is a description of my situation. You may not need to read
it, in which case, just skip to the part where it says "Enough of that,"
but you probably will need to read this.

(I skipped most, but sounds neat)

Enough of that. The main obstacle I need to pass before being able to
make the game playable, other than some general design flaws, is letting
the player have interpreted Ruby scripts that they can create within the
game, and that will be run in the game. Basically, they need to have
access to the libraries that I created, but not any actual Ruby
libraries. The tricky part is that the libraries I created need access
to the actual Ruby libraries.

Is there any way to do this? Or another way to allow players to run Ruby
programs?

Maybe try why's sandbox? Otherwise, safe levels, eval, threads maybe...

http://redhanded.hobix.com/inspect/theThrillingFreakyFreakySandboxHack.html

-Justin

 

[Jan Svitok]

The following is a description of my situation. You may not need to read
it, in which case, just skip to the part where it says "Enough of that,"
but you probably will need to read this.

I am trying to make an online text based "hacking" game. Like, the kind
where you infiltrate other people's computers and destroy their stuff.
Basically, the game will be like a mud, but P2P, since I don't have/want
to maintain a server for that kind of stuff. The game engine will be
stored locally on the players computer. During distribution, I will use
Ruby2Exe or similar so that players won't be able to tamper with files.
They will connect to a metaserver which will give them a list of
connected players, and add them to that list. It will store actual IP
addresses, so that the metaserver need not be contacted again. Also,
after the client gets the IP list, it will connect to the other players
on the list and tell them that they have connected. I am not expecting
the amount of players that mainstream MMOs have, so this shouldn't be a
problem. Actually, I'm not expecting any players, this is more of a
learning experience.

Now the important part. The premise of the game is hacking. Real hackers
(at least in this virtual world I'm creating) make their own tools.
Everything, with the exception of a few basic tools (like a "connect"
program for connecting to other players), will be player created.
Hopefully. Now to do that, I want the players to be able to write their
own Ruby scripts (and eventually maybe Python and Javascript) that will
only be able to use a few modules and classes that I will create, to
prevent people actually messing up other player's computers, and to keep
the game more balanced.

Those classes, by the way, are going to be pretty much the basic ruby
stuff, those for using an in-game filesystem, much like the File class,
and for communicating with other players, and any I feel necessary later
on.

Enough of that. The main obstacle I need to pass before being able to
make the game playable, other than some general design flaws, is letting
the player have interpreted Ruby scripts that they can create within the
game, and that will be run in the game. Basically, they need to have
access to the libraries that I created, but not any actual Ruby
libraries. The tricky part is that the libraries I created need access
to the actual Ruby libraries.

Is there any way to do this? Or another way to allow players to run Ruby
programs?

Once there was an online game of this kind, hackthisbox IIRC, and the
best fun was that even though there were some 12 levels to go, some of
the brightest have achieved level 15... Apparently the page had some
problems itself ;-) So, sometimes some "bugs" are nice, just one needs
to make sure the possible damage isn't too high.

 

[Rick DeNatale]

Once there was an online game of this kind, hackthisbox IIRC, and the
best fun was that even though there were some 12 levels to go, some of
the brightest have achieved level 15... Apparently the page had some
problems itself ;-) So, sometimes some "bugs" are nice, just one needs
to make sure the possible damage isn't too high.

The protypical example of this kind of game was probably Darwin which
was written at Bell Labs and ran on the IBM 7090. Darwin didn't last
long though because within a few weeks one of the authors came up with
an undefeatable "contestant" program which killed the fun.

The best known is probably "Core War" a.k.a. "Core Wars" which was
inspired by Darwin and introduced to the public in the March 1984
"Mathematical Recreations" column in Scientific American.

Darwin contestants were written in 7090 assembly language, while "Core
Wars" contestants are written in "Redcode" a very simple
pseudo-assembly language.

http://en.wikipedia.org/wiki/Darwin_(programming_game)
http://en.wikipedia.org/wiki/Core_War

 

[Mike Zink]

Well, I've looked into safe levels, undef, and why's sandbox, but none
of them fit my situation very well. Safe levels won't allow players to
use game libraries, and I can't find a way to use them in why's sandbox,
and undef would be unreasonable. I would have to undef every standard
library function.

Looks like these are my only choices though, so does anyone have an idea
of how to let them use my libraries?

Oh, and Rick I looked at Core Wars, and Darwin, and that gave me some
inspiration. I don't want my game to end up like Darwin, which will be
hard to accomplish (for instance, someone could make an impenatrable
Firewall very easily, just by saying Packet.block or something). I also
need a real objective to give my players, but I don't want it to be
levels or a definitive score.

But that is a problem for the future, so letting players use my
libraries but not stdlib's is the current problem.

 

[Dave Howell]

Well, I've looked into safe levels, undef, and why's sandbox, but none
of them fit my situation very well. Safe levels won't allow players to
use game libraries, and I can't find a way to use them in why's
sandbox,
and undef would be unreasonable. I would have to undef every standard
library function.

Is it possible, once Ruby's launched, for it to redefine (or undefine)
the default search paths? If only your modules know the secret
handshake required to 'find' the standard . . . hmm. I guess I can't
think of how that'd actually work.

So you disable or redefine File.read, say. How do you stop a player
from going to the stdlib or core source code, including, embedding, or
copy&pasting that into their program, and calling it?

My head hurts. Good luck . . .

 

[Mike Zink]

Is it possible, once Ruby's launched, for it to redefine (or undefine)
the default search paths? If only your modules know the secret
handshake required to 'find' the standard . . . hmm. I guess I can't
think of how that'd actually work.

I think that would work perfectly! Thanks for the idea! I will look into
that. If anyone has any idea how that could be done, I would really
appreciate to hear it.

So you disable or redefine File.read, say. How do you stop a player
from going to the stdlib or core source code, including, embedding, or
copy&pasting that into their program, and calling it?

This part could be a real problem. But we'll see about that later. I
could make part of the updater and such search the user program files
for anything from the stdlib, but that would take a looong time. That
may be what I have to do, but I'll need to find a way to not have to
search for the whole stdlib... or something... my head hurts now too!

Suggestions anyone?

 

[Patrick Hurley]

The game engine will be
stored locally on the players computer. During distribution, I will use
Ruby2Exe or similar so that players won't be able to tamper with files.

Now the important part. The premise of the game is hacking. Real hackers
(at least in this virtual world I'm creating) make their own tools.

I love Ruby -- but if you distribute a Ruby program as part of your
hacking game -- I cannot imagine what you could do to stop a
reasonably capable hacker from having a field day with your code.
Actually this is true of most any client side game code, but
particularly true of most dynamic languages and certainly of Ruby.

If you really want to use Ruby (and who could blame you), you might
want to consider a custom embedded version of the Ruby interpreter
that will only load signed code to lock down parts of the system -- of
course you will have to have a trap door to run their code (which you
cannot sign without embedding your key). There are still ways around
this, but you can raise the bar considerably.

Good luck
pth

 

[Dave Howell]

This part could be a real problem. But we'll see about that later. I
could make part of the updater and such search the user program files
for anything from the stdlib, but that would take a looong time.

And wouldn't work. "Recognized my code, eh? Fine! I'll just change
File.read to Fyle.reed" or change line breaks or otherwise jigger the
code around.

I suspect your only hope would be to enlist the aid of the OS by having
your initialization code switch over to an utterly unprivileged user;
one that's not allowed to write to the file system, read from it, or
really do much of anything outside Ruby itself. Your frozen (and
hopefully somewhat paranoid) code would know how to get around that.

Dunno how that'd work on Windows . . .

 

[Jan Svitok]

need a real objective to give my players, but I don't want it to be
levels or a definitive score.

<sarcasm>
The winner will get a botnet at his disposal. How appropriate. ;-)
</sarcasm>

 

[Mike Zink]

<sarcasm>
The winner will get a botnet at his disposal. How appropriate. ;-)
</sarcasm>

Hahaha...

Well, I've decided I'll be making my own scripting language, but this is
going to be a female dog. I am going back to school next wednesday, and
won't have much time anymore. If there wasn't such a problem with user
scripts here, I would have ample time over the school year to complete
my project, but it will be a lot slower if I make my own language. Even
more so if I end up needing to redo everything in C or C++, but
hopefully I'll still be able to use Ruby.

If I don't run into too many huge problems, and am sure I'll be able to
complete it, I'll make a page somewhere for it, and notify anyone who
wants to be involved.

Thanks for your help, everyone!

 

[William Crawford]

Well, I've decided I'll be making my own scripting language, but this is

Well, you've made up your mind, and I doubt I can change it, but I'd
like to note that learning yet another scripting language just to play a
game isn't in the cards for me. As long as you were talking about Ruby
being the language, I was very interested as Ruby is a new language for
me that I plan to be using anyhow.

Oh well. Good luck with it!

 

[Mike Zink]

Well, you've made up your mind, and I doubt I can change it, but I'd
like to note that learning yet another scripting language just to play a
game isn't in the cards for me. As long as you were talking about Ruby
being the language, I was very interested as Ruby is a new language for
me that I plan to be using anyhow.

Oh well. Good luck with it!

Actually, what I'm going to try to do is make it pretty much a Ruby
clone, since that will make it a heck of a lot easier for me. What I
want to do is make a parser that will allow only certain functions and
such, then call them, but not with eval. So a user created firewall
might look something like this:

# this is a firewall that rejects packets with "trojan" found in them
trojan = Regexp.new("trojan", Regexp:IGNORECASE)
port = Port.open("1234")

while (session = port.accept)
packet = session.get_packet
if packet =~ trojan
packet.destroy
else
packet.allow
end
end

That's just an example of what it will be like in a few days (I haven't
finished the parser yet). Here, a user could replace 'if packet =~
trojan' with 'if packet' and have an invincible firewall. I will of
course have to take the time to disallow such things with the parser,
but that won't be too hard.

Anyways, if you only wanted to play because you could kill people with
your awesome Ruby skills, you will still be able to, but I will try to
level the playing field by making it pretty restrictive. Not because I
don't want you to have fun, but because I don't want it to be the
easiest hacking game you've ever played.