146 replies to this topic

[andrewmc]

how many characters or numbers can the key be?

<{POST_SNAPBACK}>

I didn't set a limit. If you want it could be 100 characters.

[Knightmare]

Wouldn't it be invulnerable to Cheat Engine users? Since they can see lines of code in the memory.

[andrewmc]

Wouldn't it be invulnerable to Cheat Engine users? Since they can see lines of code in the memory.

<{POST_SNAPBACK}>

I would say no but if anyone wants to do any tests on this then go ahead. There are many programs that use encryption, and I just dont see why they would use it if they are vulnerable to memory scanning. If they arnt then I dont see any reason why this DLL would be.

[IsmAvatar]

If you read his post, you see that he was using a GM6 file as the seed, not a string. Like I said, there are so many 0's in GM6 files, that using a simple addition algorithm would produce no change when a 0 is met, so that many 0's would cause a poor encryption. That's not a sign that you should use a different file - it's a sign you should use a better encryption algorithm, like IsmCrypt did.

[andrewmc]

If you read his post, you see that he was using a GM6 file as the seed, not a string. Like I said, there are so many 0's in GM6 files, that using a simple addition algorithm would produce no change when a 0 is met, so that many 0's would cause a poor encryption. That's not a sign that you should use a different file - it's a sign you should use a better encryption algorithm, like IsmCrypt did.

<{POST_SNAPBACK}>

Using a different file thatdidn't contain so many 0's would be a solution. I really don't know too many reasons why someone would pick the file method over the string though. I really just added that in so the dll wouldn't be so plain.

[Potnop]

Awesome, U fixed that read-only problem right?

The only problem with not having an output file is that if the game crashes and the file is decrypted its not protected. I'll probably jsut do a copy paste of a file into the temp directory somehow.

[andrewmc]

Awesome, U fixed that read-only problem right?

The only problem with not having an output file is that if the game crashes and the file is decrypted its not protected.  I'll probably jsut do a copy paste of a file into the temp directory somehow.

<{POST_SNAPBACK}>

I never thought of that. You might want to try quickly decrypting it then loading the rescource them immediatly encrypting it again. And yes, the files shouldn't be read only.

[andrewmc]

anyone else try the dll?

[TyrantX]

I just tested it and it works perfectly. It has a VERY strong encryption even with only a few letters. I will most likely use this!

[Smarty]

I have trouble seeing any practical use in this.

It's fun to use if you want to send someone a file and both parties have the key string or file. But as a local encryption method it has major vulnerabilities.

For example, if the encryption is file-based, you know that the key file is contained within the game folder. So all you have to do is run this DLL past the other files in the same directory.

Or, since GML scripts in running executables aren't quite as protected as people think they are, you could simply look up the file or string used as a key and run it past the file - and you're done.

There are many programs that use encryption, and I just dont see why they would use it if they are vulnerable to memory scanning.

<{POST_SNAPBACK}>

If you are referring to this forum, then the problem is a complete lack of knowledge on the subject. Any encryption is vulnerable when you deliver the key with it, no matter how good you hide it.

And a file and a GML script aren't good places to hide a key.

Edited by Smarty, 03 October 2006 - 10:10 AM.

[Invero]

Very Nice I Already Found Very Good Use For This To Protect My Small Little Game Files

But What Sucks About This Is That It Cannot Protect / Encrypr .bmp's ect... or Sprite Images ???

Will The Next Update Be Able To Encrypt Image Files ?
It Would Be More Helpfull And It Would Be Then Considered the Best Encryptor For Me

But Besides Everything Else Awesome Work !!!!

Hope You Answer Back Before Tommorow That Is If Your On lol

[Reshure]

It can encrypt image files. It works for me.

[Alex]

Edited by Alex, 25 January 2009 - 06:22 AM.

[mattn]

Hi,
I've spent the past two years researching encryption methods and writing 4096 bit encryption and am attempting 10000 bit encryption, but sorry for sliding away from the topic at hand. I'd suggest that you try to re-write the program using the Rijndael encryption algorithm at least at 512 bits, preferribly 1024 or 2048 or if you have the skills 4096 bit encryption. It's just about the strongest encryption algorithm created to date, but only runs really smoothly at 2048 bit encryption or higher, without any corruption and on any file.

from mattn

[Alex]

Edited by Alex, 25 January 2009 - 06:22 AM.

[39ster]

"Best File Encryption For Gm" - What encryption algorithm are you using?

[THE Stefan]

It's funny to see how just saying its secure makes everybody think it is.

it is still possible to make strong encryptors which can survive brute force

<{POST_SNAPBACK}>

I have to correct you there, brute force can crack any encryption algorithm. It just takes time, lots of time.

It doesn't encrypt the spaces allowing for stronger encryption.

In fact, not encrypting half the file makes the encryption weaker.

[Mentat]

Geez man... give people a piece a lettuce and they demand a salad...

It is true that no encrytion method is completely invulnerable or unbreakable... however that point of sufficient encrytion is to prevent the vast majority of people from being able to break it. He has accomplished this.

I think he has done the community a great service by providing this DLL.

Good Job!

[localmotion34]

...and am attempting 10000 bit encryption

man, you must be hiding some heavy **** on your computer if you need somthing that strong.

Although, key length dosn't mean anything if you don't know how to hide it. However, even with GM's security issues, it is still possible to make strong encryptors which can survive brute force. At least, I know how.

<{POST_SNAPBACK}>

If you encrypt a file using RC4 in a DLL, it an only be correctly decrypted with the right key. that key gets passed to the DLL as an argument from the program.

There is no known way as of now for a person to peek into memory areas through a network to internal stack registers to grab the key in memory.

if the hacker has the program and file in hand, he must know where to look on the system to find the key, or where in the code. else, the key can be based on user input, in which case the hacker has no idea what the key is.

if you use EXE cryptor to morph the sections of your code that contain the key, almost no one except Seek 'N Destroy, iNfEcted or RELOADED would be able to break it.

additionally, encryption keys can be hardware dependent, as a combination of hard drive serial, processor seral, windows activation key ect.

even if a hacker stole a copy of your file, he would have absolutely no idea how to reconstruct your hardware fingerprint.

Edited by localmotion34, 28 October 2006 - 01:00 AM.

[Alex]

I have to correct you there, brute force can crack any encryption algorithm. It just takes time, lots of time.

There is a line where brute force would be as effective as going through every byte combination to unlock a file.

It's like saying, if I make a program to generate a file by going through all the byte combinations, then I will eventually get the decrypted file. Which is true..., but, its possible for brute force to detect many valid files because of the large number of combinations, and so you wouldn't know which file it really is. Keep in mind, were talking about billions of billions of combinations. Too many valid files would be impractical.

Correct me if i'm wrong though...

Edited by /\lex, 28 October 2006 - 03:20 AM.