Page 2 of 2
Posted: Tue Apr 11, 2006 8:10 pm
by 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?
Posted: Tue Apr 11, 2006 8:52 pm
by evo
Thanks for the comments keless
keless wrote: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.
keless wrote: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.
keless wrote: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.
Posted: Thu Apr 20, 2006 10:39 pm
by 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.
Posted: Mon Apr 24, 2006 10:38 am
by evo
keless wrote: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.
Posted: Tue Apr 25, 2006 9:42 pm
by 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
Posted: Thu Mar 27, 2008 7:56 pm
by 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?