Page 1 of 2

Spellbounced Game Demo + SQLite wrapper

Posted: Fri Mar 31, 2006 10:26 pm
by evo
Hi all,

Finally. My first demo game is finished. It is called Spellbounced. It is not to be taken 'very seriously' as game :D . I intended it mostly as a demo for the integration of the Irrlicht 3D engine with the SQLite database engine. Still i'am glad I got it finished in ~2 months.

The main purpose of the demo is showing the capabilities of using a database for loading Irrlicht data. Debugging was also a main target.
I have created (yet another) wrapper class for SQLite. This offers easy database access completely integrated with Irrlicht, database archives and AES encryption.
Database archives can be compared with zip archived. So anything that has an IReadfile 'filetype' can be loaded from a database. But with the added bonus of encryption.
Personally I have no need for xml files any more. But you can load xml from a database archive.

I have released the executable here: http://home.wanadoo.nl/iherweij/downloa ... _Win32.zip
[EDIT] Mirror is here: http://www.megaupload.com/?d=X1RGUSNT

The source files, including additions to Irrlicht 0.14, will be published in a couple of weeks. I am curious to your opinions about the level of security of this demo. Surely, no piece of software is 'unhackable', but encryption will scare most people off ? :?:

Initially I used Devc/cpp for development, but recently switched to MSVC. I have found that some errors that occur in devc, have completely vanished with visual studio.


Even though it's only a demo, most elements of a full game can be found in this demo, like:
Loading/saving game data
Object animation
Sound
Artificial intelligence / path finding
Menu system
Level system
Score system
encryption of game data


Well enjoy the game and let me know what you think.

Evo

Posted: Sat Apr 01, 2006 5:09 am
by bitplane
nice demo game :)
I like the encryption idea, a lot of people have asked about it in the past. Do we get our grubby hands on your wrapper, or are you into the idea that 'obscurity = security' and protecting your IP rights and all that?

Posted: Sat Apr 01, 2006 1:56 pm
by Guest___
Cool it's about time someone write a database wrapper
for irrlicht.

Posted: Sat Apr 01, 2006 2:28 pm
by dawasw
Too bad, download is not avaible anymore :(

Posted: Sat Apr 01, 2006 6:38 pm
by evo
I will make the source available in a couple of weeks. Updating the documentation and tutorial will take me some time.
Also I hope to get better response to the security level of my demo without access to the sourcecode.


As to the 403 error: This is due to the homepage download limit from my internet provider. Apparently it resets every midnight (GMT+1). So try again the next day if it is unavailable.

Posted: Sat Apr 01, 2006 7:23 pm
by keless
IrrRPG is using SQLite as well, though currently its for regular database (user/account) info. However, it would be interesting to check out the resource packing idea too-- so I'd like to check this out when its available (getting 403).

Posted: Wed Apr 05, 2006 7:13 pm
by evo
Anybody beat the high-score yet ?? If so you can mail me the 'HiScores.ec2' file and i will make a public high-score list :)
You can zend it here: iherweij wanadoo nl.


Also I would appreciate every comment as to the security of the demo. Anybody who knows any hackers :roll:


Tutorial for the databasewrapper is comming along nicely. Now I only have to learn how to create a patch file

Posted: Wed Apr 05, 2006 7:37 pm
by evo
I have mirrored the zip file here: http://www.megaupload.com/?d=X1RGUSNT
You may use this in case of a 403 error

Posted: Fri Apr 07, 2006 12:28 am
by keless
so, is the .ec2 file a straight SQLite database file that you merely put compressed/encrypted data into? or is there something different to it?

Posted: Fri Apr 07, 2006 6:23 am
by evo
keless wrote:so, is the .ec2 file a straight SQLite database file that you merely put compressed/encrypted data into? or is there something different to it?
No. It is the other way around. The ec2 file is the encrypted+encoded version of a normal SQLite database file. At runtime the database is restored in memory.

Posted: Fri Apr 07, 2006 7:36 am
by jam
evo wrote:Anybody beat the high-score yet ??
does 320,000,400 count as beating the high score?

Also I would appreciate every comment as to the security of the demo. Anybody who knows any hackers :roll:
As long as you have implemented your block cipher (AES) in the right mode, CBC works well, I don't think you can really go wrong with the encrypted data on the disk it's when you load it into memory that security becomes a problem.

Posted: Fri Apr 07, 2006 11:02 am
by evo
jam wrote:does 320,000,400 count as beating the high score?
It should :shock: . How did you manage this ? Could be an overflow errror. Variable 'score' is an irr::s32 (I think, can't look at the source at the moment)

As long as you have implemented your block cipher (AES) in the right mode, CBC works well, I don't think you can really go wrong with the encrypted data on the disk it's when you load it into memory that security becomes a problem.
I agree. The data is vulnerable in memory. Another weakness is the that the decryption key is hidden within the .exe somewhere.

As I said earlier these security measures can only scare off (most ?) people. It is not possible to keep everybody out.

Posted: Fri Apr 07, 2006 5:41 pm
by jam
evo wrote:It should :shock: . How did you manage this ? Could be an overflow errror. Variable 'score' is an irr::s32 (I think, can't look at the source at the moment)
there is no error in your program, s32 can hold values over 2 billion. Besides I doubt anyone will ever score so high, through normal play, as I had to poke new values into memory to obtain that score.

I agree. The data is vulnerable in memory. Another weakness is the that the decryption key is hidden within the .exe somewhere.

As I said earlier these security measures can only scare off (most ?) people. It is not possible to keep everybody out.
If you used something simple to encode you score, etc in memory, you could complicate efforts to poke new values into memory.

It is good that you hide the decryption key and didn't store it as a literal string, where anyone with a hexeditor could find it. That should be enough for what you are planning to do with this.
As I said earlier these security measures can only scare off (most ?) people. It is not possible to keep everybody out.
You are correct, all you can aim for is to take up some of their precious time. I would suggest that you find some way to protect your important variables, because at the moment the encryption seems to me to be overkill, when it's just a 30 second job to just poke the values you want into memory.

Posted: Fri Apr 07, 2006 7:50 pm
by evo
Thanks jam. Interesting suggestions.

To protect the highscores against trainers I could change 2 things:
1. Only decrypt/load the highscore database when it is needed: when displaying the menu followed by closing and when adding a new score followed by saving/encrypting/closing.

2. To protect variables in memory is apparently a more difficult matter. After searching around if found this: http://www.programmers-corner.com/tutorial/30
Detecting when the score variable has been altered and terminating the program seems to be the best option.


Originally I developed the encryption thing to protect game data like textures, sounds, .x, etc. I now realize that it is even more difficult to protect live data against trainers. For online games this is probably even more important.

Posted: Tue Apr 11, 2006 4:32 am
by jam
evo wrote: Originally I developed the encryption thing to protect game data like textures, sounds, .x, etc.
If this was your intention then it might be best to stay with that because to get into protecting against cheating can consume a ton of time, time better spent working on a game. :wink: