Torque Secure?
by Thijs Sloesen · in Torque Game Engine · 12/20/2003 (4:38 am) · 15 replies
Hi,
I was wondering if someone could provide me some insight into the following question.
I am currently thinking of creating a game (or rather a series of games) that will incorporate some sort of pay-per-play meganism. There are a lot of subscription based games out there, but I haven't seen much pay-per-play games yet.
I would like to know if there is some documentation/audit available about Torque security. Of course, the data submitted across the internet is not secure, but we might be able to put an SSL layer on top of that somehow. I'll have to hack into the engine source to see what implications that will have. But about the scripting engine... are compiled scripts easy to decompile? It would be a shame if we would release a pay-per-play game and in two days someone has cracked the client-side code and has found a way to execute the game without paying. And on another note, is there any info available about buffer overflows and such in Torque?
I hope some of you out there have any experience with this topic. I'm currently trying to find out if Torque is the way to go for my plans. I'm even thinking of writing some custom C++ code (in stead of scripts) that is called from the engine, but I'm not sure if that would help.
Any input will be highly appreciated. Thanks a lot in advance.
Regards,
Thijs
I was wondering if someone could provide me some insight into the following question.
I am currently thinking of creating a game (or rather a series of games) that will incorporate some sort of pay-per-play meganism. There are a lot of subscription based games out there, but I haven't seen much pay-per-play games yet.
I would like to know if there is some documentation/audit available about Torque security. Of course, the data submitted across the internet is not secure, but we might be able to put an SSL layer on top of that somehow. I'll have to hack into the engine source to see what implications that will have. But about the scripting engine... are compiled scripts easy to decompile? It would be a shame if we would release a pay-per-play game and in two days someone has cracked the client-side code and has found a way to execute the game without paying. And on another note, is there any info available about buffer overflows and such in Torque?
I hope some of you out there have any experience with this topic. I'm currently trying to find out if Torque is the way to go for my plans. I'm even thinking of writing some custom C++ code (in stead of scripts) that is called from the engine, but I'm not sure if that would help.
Any input will be highly appreciated. Thanks a lot in advance.
Regards,
Thijs
#2
You should assume that any client side security you write will be cracked. So design around this. :)
12/20/2003 (6:30 am)
Torque is just a game engine... if you need copy protection/DRM you should look into something like Ignition, SafeDisc, etc.You should assume that any client side security you write will be cracked. So design around this. :)
#3
And, not helpful, but YUCK at pay per play. Unless you're doing something *really* cool like you have to pay per life, which does kind of interest me as it would really change the gameplay dynamic.
(oops, is that the sound of me hijacking this thread?)
12/20/2003 (6:55 am)
If this is a game you can play on your own, there is no way to stop it being hacked (proven). If it involves playing on a server, however, it would be relatively easy to set up, just use a CD key system with a counter or something.And, not helpful, but YUCK at pay per play. Unless you're doing something *really* cool like you have to pay per life, which does kind of interest me as it would really change the gameplay dynamic.
(oops, is that the sound of me hijacking this thread?)
#4
And Ian: I was more thinking about some sort of "arcade machine" feeling for these games. You buy credits which you use to play the game, get those famous "continues" etc. :)
Thanks for your thoughts people!
12/20/2003 (8:03 am)
I guess you guys are right. With a security system around Torque it should be fine.And Ian: I was more thinking about some sort of "arcade machine" feeling for these games. You buy credits which you use to play the game, get those famous "continues" etc. :)
Thanks for your thoughts people!
#5
On the other (slightly less pessimistic) hand, when the technology of a "virtual wallet" (very easy to spend small amounts of money at the click of one button) has been widely taken up, I could imagine putting $0.5 into a virtual arcade machine. But again, MAME has thousands of free arcade machines, so I'm not so sure.
12/20/2003 (8:15 am)
Your game would have to be pretty damn good to pay per play. And bear in mind that even if it was successful, someone would simply steal the core mechanics and make a dodgy version of it for free.On the other (slightly less pessimistic) hand, when the technology of a "virtual wallet" (very easy to spend small amounts of money at the click of one button) has been widely taken up, I could imagine putting $0.5 into a virtual arcade machine. But again, MAME has thousands of free arcade machines, so I'm not so sure.
#6
12/20/2003 (12:31 pm)
I know what you mean. And you're right that free games are tough competition, but with micro payments getting more and more popular, I think there's still a chance. Especcially if you add a competition element like WorldWinner has done. People tend to spend money easily if there is a chance they'll make money by doing so :)
#7
You're much better off using SSL through an existing web browser, since they've already spent all the engineering effort to set up an ironclad system.
12/20/2003 (3:31 pm)
I think you'd have to be crazy to take payment over a network system like Torque's, SSL layer or no. If a system isn't designed from the ground up for security, don't use it for online payment.You're much better off using SSL through an existing web browser, since they've already spent all the engineering effort to set up an ironclad system.
#8
Maybe I wasn't clear enough, but my question was not so much about the payment process, but more about the process that gives the user access to the game, depending on whether or not they have paid.
I am curious how hard it is to hack Torque script code. It is possible to hack machine code, provided you have the right tools. But this is a difficult process since you'll have to get into assembly code etc. But I've seen Java decompilers for instance, which make it very easy to view the java source code. Even a 12 year old kid could decompile and possible even change the code.
But reading the previous posts I think it's better just not to trust on Torque's scripting engine being secure and take security precautions of my own :)
12/21/2003 (4:52 am)
You might have a point there. I think it's best to accept payments through third parties. So you'll probably end up using a webbrowser for that anyway.Maybe I wasn't clear enough, but my question was not so much about the payment process, but more about the process that gives the user access to the game, depending on whether or not they have paid.
I am curious how hard it is to hack Torque script code. It is possible to hack machine code, provided you have the right tools. But this is a difficult process since you'll have to get into assembly code etc. But I've seen Java decompilers for instance, which make it very easy to view the java source code. Even a 12 year old kid could decompile and possible even change the code.
But reading the previous posts I think it's better just not to trust on Torque's scripting engine being secure and take security precautions of my own :)
#9
If the game is a server-client deal, and you control the server, then it is easy to make a secure system, script or not: Tribes 2's CD key system is one good example.
However, if you are hoping to have the game just on the client's system, let me reiterate that it *will* be hacked whether you use Torque or anything else.
So my point is: this plan will straight not work unless you control the server. If you control the server, it's very easy: when someone's paid you, you give them a credit on the server and when they connect (using their unique code) the credit is used up.
Of course, Tribes 2 had a hole (which I found! But I think someone else found it first...) which let you remotely hack into the server (initiate a vote to change the mission time limit with a few well selected arguments and the fourth argument the code you wanted to execute, and voila) which they later fixed. I can't be sure Torque is 100% secure against this sort of thing, but with so many people using it it must be doing fairly well if noone's found a hole yet.
Ian
12/21/2003 (9:06 am)
Hmm, I think you're misunderstanding me slightly.If the game is a server-client deal, and you control the server, then it is easy to make a secure system, script or not: Tribes 2's CD key system is one good example.
However, if you are hoping to have the game just on the client's system, let me reiterate that it *will* be hacked whether you use Torque or anything else.
So my point is: this plan will straight not work unless you control the server. If you control the server, it's very easy: when someone's paid you, you give them a credit on the server and when they connect (using their unique code) the credit is used up.
Of course, Tribes 2 had a hole (which I found! But I think someone else found it first...) which let you remotely hack into the server (initiate a vote to change the mission time limit with a few well selected arguments and the fourth argument the code you wanted to execute, and voila) which they later fixed. I can't be sure Torque is 100% secure against this sort of thing, but with so many people using it it must be doing fairly well if noone's found a hole yet.
Ian
#10
Take this pseudo-assembly code for example:
cmp [eax], 0
ja got_credit
jmp out_of_credit
With the right knowledge and tools, this code can easily ne modified to strip the check, something like this:
cmp [eax], 0
jmp got_credit
nop
nop
This would just disable the check for credit, after the server was queried. So the server might still be 100% secure, your client code should at least be hard to decompile (or use a hardware dongle :p) otherwise it's still easy to hack.
Of course, no software program is safe from hackers that work like this. But it is interesting to know exectly how easy it is to do this with Torque script. I think I'll do some tests of my own.
Thanks for your input!
12/21/2003 (1:16 pm)
Yeah... a client/server architecture is what I had in mind. If that's what you mean, you are absolutely right. I was just curious how easy it is to hack Torque scripts.Take this pseudo-assembly code for example:
cmp [eax], 0
ja got_credit
jmp out_of_credit
With the right knowledge and tools, this code can easily ne modified to strip the check, something like this:
cmp [eax], 0
jmp got_credit
nop
nop
This would just disable the check for credit, after the server was queried. So the server might still be 100% secure, your client code should at least be hard to decompile (or use a hardware dongle :p) otherwise it's still easy to hack.
Of course, no software program is safe from hackers that work like this. But it is interesting to know exectly how easy it is to do this with Torque script. I think I'll do some tests of my own.
Thanks for your input!
#11
It sounds to me like you're letting the client have too much control over the transaction. If you are the one running all the servers, there will be no way for the client to play if they ignore the credit check, 'cause the server won't hold up it's end of the game.
On the other hand, if you want to have a server that does nothing but check credit and then the game takes place 100% on the client side machine... well, there is nothing you can really do to prevent the cracks from coming out. I'd advise you to set up a simple system, but don't spend a lot of time worrying about things you can't control.
12/21/2003 (1:25 pm)
It really doesn't matter how difficult script is to crack vs assembly. In this age, it only takes one person to figure it out, then the solution is up on the internet.It sounds to me like you're letting the client have too much control over the transaction. If you are the one running all the servers, there will be no way for the client to play if they ignore the credit check, 'cause the server won't hold up it's end of the game.
On the other hand, if you want to have a server that does nothing but check credit and then the game takes place 100% on the client side machine... well, there is nothing you can really do to prevent the cracks from coming out. I'd advise you to set up a simple system, but don't spend a lot of time worrying about things you can't control.
#12
Hmm, sad that we even have to think about these matters in the first place...
12/21/2003 (1:37 pm)
You certainly have a point there. Maybe the only thing that really works is having the server take care of a big part of the game logic.Hmm, sad that we even have to think about these matters in the first place...
#13
As a few other people have said, there is absolutely NO WAY TO PROTECT programs that is distributed to the client, just make it untrusted and the server the final say and that is about as good as you can do.
And memory loader hacks are getting more and more popular with the kids, can't hack the .exe hack it once it starts running.
12/21/2003 (3:57 pm)
Hardware dongles are easier to crack than anything! And I am pretty sure it would completely drive away any potential sales.As a few other people have said, there is absolutely NO WAY TO PROTECT programs that is distributed to the client, just make it untrusted and the server the final say and that is about as good as you can do.
And memory loader hacks are getting more and more popular with the kids, can't hack the .exe hack it once it starts running.
#14
AKA You might be better off spending your time and resources making the game better and thus attracting more legit users rather than beef up your anti-hacking code. This really holds true when your anti-hacking code drives away legit users. (Some that I have seen that drove me away from a partcular company's product was the "look in the book for a keyword on page 100 paragraph 3" or "You have to connect to the net to confirm with a server even though the game you are running isn't a network game.")
I wish there was a study on this. (Is there)?
12/21/2003 (4:48 pm)
Remember your hack vs legit user. Certain users will buy the program for the right price. Others will hack it even if its almost free. Place your money were you get your biggest return on your investment.AKA You might be better off spending your time and resources making the game better and thus attracting more legit users rather than beef up your anti-hacking code. This really holds true when your anti-hacking code drives away legit users. (Some that I have seen that drove me away from a partcular company's product was the "look in the book for a keyword on page 100 paragraph 3" or "You have to connect to the net to confirm with a server even though the game you are running isn't a network game.")
I wish there was a study on this. (Is there)?
#15
I don't know of any such study. Maybe GG could do a survey sometime? ;-)
12/29/2003 (5:32 am)
Thanks for your thoughts on this. I'll be focussing on the gameplay for now. Seems indeed like the best idea.I don't know of any such study. Maybe GG could do a survey sometime? ;-)
Torque Owner Dan -