Spellbounced Game Demo + SQLite wrapper

[keless]

Considering you decrypt the database in memory, it does provide nice protection for your database's contents against anyone who would try to perform a quick SQLite query on it to unpack all the data-- as long as they dont know how the .ec2 file is encrypted.

So this should save you from newbies with a compiler, however anyone who is willing to pull out a hex editor and tumble thru the assembly should be able to figure out the encryption --especially if you use a library encryption system-- at which point they can write their own code to use that same library to decrypt and save the regular databse to file and use any SQL manager to gain access to the contents. So for your stated purpose, I think this solution is fine.

Curious-- how did you manage to get SQLite to modify itself from a buffer instead of a file? Or does your program create an unencrypted file on the system somewhere (doesnt seem to) which would basically make your security system useless (so I dont think you do it this way). Is DB-from-buffer an option when loading an SQLite database? (I only saw DB-from-file).

Also, if its working the way I think-- that means the entire file is in memory while running your application, which defeats the purpose of using a database file (which is to store LARGE ammounts of data in a format that is quickly retrievable from the HDD). Is that correct?

[evo]

Thanks for the comments keless

Considering you decrypt the database in memory, it does provide nice protection for your database's contents against anyone who would try to perform a quick SQLite query on it to unpack all the data-- as long as they dont know how the .ec2 file is encrypted.

So this should save you from newbies with a compiler, however anyone who is willing to pull out a hex editor and tumble thru the assembly should be able to figure out the encryption --especially if you use a library encryption system-- at which point they can write their own code to use that same library to decrypt and save the regular databse to file and use any SQL manager to gain access to the contents. So for your stated purpose, I think this solution is fine.

Basically you are right. However the encryption is 256 bit AES. Which is pretty much unbreakable for the time being. Maybe if you have access to a mainframe.....
But somebody with a decompiler can surely find the decryption key and use the library to get to the sqlite database.

Curious-- how did you manage to get SQLite to modify itself from a buffer instead of a file? Or does your program create an unencrypted file on the system somewhere (doesnt seem to) which would basically make your security system useless (so I dont think you do it this way). Is DB-from-buffer an option when loading an SQLite database? (I only saw DB-from-file).

The unencrypted database is only restored in memory. This is done by, not only encrypting, but also encoding the database. This is part of the documentation:

Code: Select all

File format for encoding
4 bytes   : Start of next table
4 bytes   : Length of Create table statement (L)
L bytes   : Create table statement
4 bytes   : Number of columns in table
1 byte    : Number of bytes for Field Length Encoding (B)
B bytes   : Field length of first field (FLE)
FLE bytes : Data first field
.......   : rest of table data

Upon restoring a series of SQL statements are fed to an empty database. First a <create table> statement, followed by an <insert into> for each record.

Also, if its working the way I think-- that means the entire file is in memory while running your application, which defeats the purpose of using a database file (which is to store LARGE ammounts of data in a format that is quickly retrievable from the HDD). Is that correct?

I admit that my method is very memory unfriendly. But how much data (apart from sound/texture/model stuff) does a game really need? Couple of thousand records ?? Same as what people store in xml files. Even several megabytes can be easily and quickly acomplished.

It is still possible to use large HDD databases, only without encryption.

[keless]

Okay, so to be clear, it should be stated that its is NOT recommended to store model/texture resources in this way because it will wreck your memory.

[evo]

Okay, so to be clear, it should be stated that its is NOT recommended to store model/texture resources in this way because it will wreck your memory.

Well, as long as there is only a couple of Mb's of data your fine. I think loading times and memory use of my demo game are perfectly acceptable.

If there is more data you can either segment you data into seperate encrypted archives and unload an archive after using it's contents. Thus freeing memory.
Or use an unencrypted disk archive. Only advantage of this method is that you don't need to distribute lot of seperate files (.X, .XMl, .jpg, etcetera) for each object.


In conclusion I think the statement should be: do not use archives with a combined size larger than ~5Mb.

[evo]

I have released the source code for Spellbounced and for the modifications to Irrlicht:

My homepage: http://home.wanadoo.nl/iherweij/
MIRROR: http://www.megaupload.com/?d=ZE5MUGFU

[Pazystamo]

Hi,
I'am trying to use irrlicht with your sqlite wrapper with DEV C++. I managed to compile your stand alone version of sqlite, but it dont work then i connect it with irrlicht. I dont want to use modifed irrlicht (engine recompile). Is it posible to compile irrlicht with stand alone sqlite wrapper?