Compression & Encryption

Hey,

Ever tought of packing and decrypting your whole game-data because you're tired of seeing your models/textures/levels in other applications, but you do not own the 3DGS-Profesional edition?

Here is your solution:
This file packer (in fact it's a small wizard) allows you to pack all your important data into a small file, protected by several up to date decryption algorithmns.

Additionally the dll that comes with this tool, allows you to directly encrypt / decrypt your data in a very very safe way.
This way you would be able to decrypt important data, like e.g. the installation time.

Decryption Algorithmns supported:

• Blowfish
• Rijndael
• AES (256/196/128 bit)
• FastCrypt
• and ofc: none if you just want to pack your data

Compression This tool compressed your data to 25% of it's orginal size. E.g. a model file which had the size of 40 MB, has a size of 10 mb compressed.

Images
here are all steps of the wizard

• choose where to save
  
• add all files you want to compress / decrypt
  
• choose decryption method
  
• set key
  
• get summary
  
  
• implement in your app:
  
  

thanks for any resonance,
the tool will be release in the next few days,
TechMuc

You did some very handy tools, very nice.
Looking forward to test them out.

awesome tool
a lot of people will use it, i'm sure

Release it now!!

Wow, that's another great and useful tool!

Keep up developing such great tools

wow, that is great!

So.. When??

That looks very interesting!Of cause LionTS seems not to work on his programm to the A7! Please tell us,when it becomes finished and what it cost's!

Quoting Techmuc: "the tool will be release in the next few days".
It's free!!

ah cowa, the quote that it'll be release in the next few days is correct, but there were nothing about pricing at first i have to talk with my employer, and finish some more programming-tasks...

Actually i wrote it to have a slight overview about the interest in such a product (which would make one of the most important parts of the pro edition obsolent - in my opinion, as the scripts are already packed in the published version...).

Yes, i know. That why i said:


Anyway, keep us updated

Sorry for the bump. But, TechMuc, are you still working at it?

GED has priroity, therefore i'm not working on it atm. But it'll be released definatly, don't be afraid

Cool! Can't wait for it!

Was there any further progress?

Regards,
Pegamode.

The problem is, that i intended to sell the final project. That means that i (at least partly) have to guarantee the security of the encryption.

Because of security issus I encountered in my algorithmns, i'm pretty sure an advanced (depending on the user implementation of the security algorithm even beginner) cracker can annul the whole concept pretty easily.

Actually I'm planing to implement the Compressing / Encryption tool to LED, but [b]if anyone is willing to pay for such a tool, i would give this tool another try.

How about you remove the encription functionality(just a packer), and release it as a freeware,
or warn that the encryption is not 100% secure and release it as cheapie-ware?

Then the interest in the freeware, or the money you make on the cheapieware,
can help you decide on whether to spend the time securing your algorithms...

As well as it means your core-code can get good a testing before being implemented in LED.

my lite-c file packer script also offers encryption. the used XTEA algorithm is very secure but of course it depends a bit on how well the key and the decryption process are hidden in the exe. it also would be easy to add some wizard functionality to my script.

...but no matter how secure your encryption system is, your data will end up in ram/graphics ram unencrypted anyway and there you can grab it with various tools quite easily. so i think this whole packing thing is quite overrated by most people. most AAA games also seem to only use some kind of unprotected zip files.

ventilator: "it depends a bit on how well the key [..] are hidden in the exe."

Actually that is the real main point. My encryption methods are extremly safe (theoretically not crackable). But: The key is always in the exe file. Of course you can encrypt it, but that you would need an encryption code for the key ==> again unsafe. And even if you would encrypt your key 10 times, the hacker / cracker would just attack the if(key == correct) point.. therefore i'm ruining my brain in a search for a better / more safe method.

Greetings,
Timo

I wonder how secure stuff are nowdays with CUDA accelerated attacks together with Tesla cards + all cores on CPU anyway.

cuda won't help either. there are many encryption algorithms that are extremely safe and theoretically not crackable like techmuc has already mentioned. maybe in the future with quantum computers.

...but all of this doesn't matter much. with tools like glintercept (forgot the names of the many directx pendants) you can simply grab meshes, textures, shaders from graphics ram for example and there also are tools for grabbing stuff from system ram.

3d ripper dx for dx9,

also one can read the pc ram and search for mdl signatures and rip from there? (i mean if you are worrying that they would search for the key in exe, they would do this too.)

So it doesnot really matter much. just make it to have good compression/speed ratio.

Putting the key in the executable is a bad idea. If you do this the choice of encryption algorithm does not play a role as the system itself is senseless. Provide a funtionality for entering the key via an api or via a textbox. All other methods are insecure.

you cannot expect player to input a key for the game to run. In fact it's even worse, when the user knows the key he/she can hack the resouces easier. Key HAS TO be in the exe.

In fact if the algorithm requires a key, some way other it will be used somewhere in your app, which if you look from this point, is always hackable.

It's rather more logical to use a harcoded function as key instead of a number/string.

Even after all this, files will be decrypted to ram, which defies the use of the encryption.