Developing a secure gaming platform in Second Life

Warning! Some geekiness ahead. One of the projects I’ve been working on heavily lately is RPCS, a roleplaying and combat system in Second Life. Not something I’ve blogged about here before, but it’s actually proved to be a fairly fascinating project on a technical level. One of the biggest reasons is because hacking, particularly hacking of games, is a huge challenge. I want to spend a little bit of time writing about the specific challenges involved, and how I’ve addressed them here, because I had a great deal of difficulty finding much on the web which addressed these issues. This is a fairly new frontier in a rapidly growing area. So… the objectives were simple:

• Prevent people from being able to modify the system or to hijack it by impersonating commands (for instance, by stealing experience points, using hijacked commands to kill other players, etc.)
• Prevent people from accessing the source code or in an way modifying the system itself
• Secure communications between the meters which are worn by avatars
• Secure communications between the meters and the internet hosted database server

That’s a lot to cover, and it’s a challenging task. The fact is that the most popular combat systems in Second Life have been hacked to death, cheated, exploited on a regular basis. Going into this I knew that I had my work cut out for me. Not to mention that we’re using multiple technologies, all of which have to be secure in order to keep the system from being exploited. The technology used in this project includes Microsoft SQL Server and Coldfusion 8 on the back end, and Linden Scripting Language (LSL) for the in-world portion.

For the internet side, most of the pieces are fairly well known (though I’ll cover those)… the things I primarily needed to address were:

• Unauthorized access to the back end website which communicates with in-world devices
• SQL-injection attacks
• Internal permissions and access to specific portions of the public website

For the in-world portion, it gets more complicated. Some of the most commonly used methods of hacking an in-world system include:

• Listening to/impersonating meter-to-meter communications (open chat)
• Listening to/impersonating internal communications (linked messages)
• Insertion of unauthorized scripts
• Stripping scripts out of the device to recreate a new one

On top of that, as anyone who has scripted in LSL knows, both lag and available memory space are HUGE problems. Because each LSL script has a memory space of only 64k (if compiled in mono) for both the script bytecode and all variables, and because the average simulator runs thousands of scripts at a time, performance and memory tweaking are major priorities which can often come at the cost of security.

The next couple of entries will address these various risks and ways they can be addressed.