RM Susano'o (New Encryption System for RMXP)

[ZenVirZan]

Hm, sorry for sounding like an idiot XD
I was talking about the Game.exe that came with it. Not my own project.
Testing with my own project now.

Edit: Nah, not working. I did everything, and ran the Encrypter and got a 'noobpass' variable may be corrupted error. Okay, so I ran it in compatibility with Win XP and it encrypted. I had NOT copied over the Modded Game.exe with it. After the encryption, I ran the Game.exe (RMXP Original) and it said something in another language I'm guessing said it couldn't load/find scripts. So i copied over the Modded Game.exe and then it just had the error I mentioned before, about it crashing as soon as it starts.

This is an awesome script (and I have an online game, all the more useful) but it just doesnt work for me.
Am I doing something wrong?

 

[ForeverZer0]

Its a little bug that occurs if you give it an invalid password. (its also a security risk, by the way)
The password can only be 3 digits, so if you give it more or less, it tells you that you need to redo, and after doing so correctly, the bug occurs.

 

[ZenVirZan]

No, i made a password 'AO7' first shot, it encrypted and still doesn't work. It does the same thing as when you try and run the Game.exe from the RAR.

 

[PedroHLC]

No, i made a password 'AO7' first shot, it encrypted and still doesn't work. It does the same thing as when you try and run the Game.exe from the RAR.

I'm trying to understand your problem, let's see, you put the 'AO7' as the password, in the end of the process, you'll a new file, called 'key.cfg' (do not delete this file, never), and when you try to run the program, it says that it's not responding? Have you tested it w/ an empty project? if it doesn't work too, can you post you're 'debug.txt' file? Have you tried to encrypt a project in your computer and let anyone else test it for you?

 

[Drago del Fato]

@Twin Matrix
I see you're using FMod for sound. Probably some kind of Audio module rewrite. That script is NOT compatible with this. You will need to modify it if you want it to be used with this.

@PedroHLC
I wanted to do this kind of protection you made for a long time. From what I saw your program is encrypting every resource file in the project with a key that project maker specified.
This is a good thing, the bad thing about this program, the key is stored in a key.cfg file and despite you KINDA encrypting it, it can be broken easily.

Here this Ruby script reads the key.cfg and writes out the key:

[rgss] 
# Key.cfg reader
 
start_c = 54;
 
v = File.open("key.cfg", "r")
g = v.readlines()
v.close
 
m = ""
for i in 0..((g[0].length / 3) - 1)
 min = i * 3
 max = i * 3 + 2
 m += ((g[0][min..max]).to_i - start_c).chr
 start_c += 1
end
 
puts "Key:" + m
 
[/rgss]

So you might spend a little more time working on making a better key protection.

So as a suggestion try:
- Encrypting a key.cfg with an internal encryption program key. That would make it more secure.
- Ask for a longer password, at least 6 characters. 3 characters encryption is easily broken by brute-force password checking.

Also a question from myself. Is this a complete rewrite of the Game.exe with your functions or you used some other kind od protection?
If you rewritten it. You can make this even better if you modify some classes to SPEED up the Game.exe, for instance, using DirectX instead of GDI+ for image drawing.

Hope I helped you.

 

[PedroHLC]

@PedroHLC
This is a good thing, the bad thing about this program, the key is stored in a key.cfg file and despite you KINDA encrypting it, it can be broken easily.
Also a question from myself. Is this a complete rewrite of the Game.exe with your functions or you used some other kind od protection?
If you rewritten it. You can make this even better if you modify some classes to SPEED up the Game.exe, for instance, using DirectX instead of GDI+ for image drawing.

Hope I helped you.

As I said for other one in chaos, there is no motive to get the key back to it original state, you can't do anything w/ it and I need this size for other things.... And, this just a Game.exe rewrite not RGSS, so i don't know any ways of using the DirectX in this case, sorry :P

 

[ForeverZer0]

If you used the key in any way to modify the .rxdata, then it is a huge security threat. People don't need to crack the executable to to crack the program. After discovering how the Marshal data is changed, its a small matter to inject some scripts into it that will output all the files using the embedded decryption process. You wouldn't need to try and chase pointers around, you can do it plain old Ruby.

 

[Drago del Fato]

@PedroHLC
I can't do anything with it? XD
Are you sure about that? XD

Oh that's a baaad way to think. Let me give you this scenario....

1. Create a new project
2. Put a code similar to this in a "special place" in Scripts.rxdata. XD
[rgss] 
  def copy_file(src, dest)
   o_f = File.open(src, "rb")
   d_s = File.open(dest, "wb")
   d_s.write o_f.readlines
   o_f.close
   d_s.close
  end
 
  def decrypt(arg1)
      if File.exist?('./' + arg1 + '.rmi')
        decrypt_img(arg1)
        entini($TEMPIMG)
        copy_file($TEMPIMG, './' + arg1 + "_d.png")
      end
   end
 
  # After this goes the code which gets all the files from Data, Graphics, Audio folder.
  # Then uses above method to decrypt them.
  # I don't really want to write that, it's long and pointless thing to do for this post. So I'll skip it.
 
[/rgss]

3. Encrypt the whole projects USING the key which I got from a project that I want resources from.
4. Copy & Paste encrypted Scripts.rxdata to that project and I can easily get stuff from it when I run it.

You can do lots of other things with it when you have access to Scripts.rxdata.
So like ForeverZer0 said, when the key is found, it is easy to do the rest.

 

[PedroHLC]

@PedroHLC
You can do lots of other things with it when you have access to Scripts.rxdata.
So like ForeverZer0 said, when the key is found, it is easy to do the rest.

'¬¬ I really forgotten this, I'm thinking about a solution, I believe I'll have to hide the key anyway :S, on the next version I'll change the formula too :S

 

[Kingdom Ablaze]

if its not too much of a hassle i would like a much longer password length option

 

[Drago del Fato]

I am guessing you're using some kind of encryption algorithm that you made. Why don't you use some already made encryption like blowfish or AES? You can make key.cfg safer if you encrypt it using a fixed program key. You have a lot of free ciphers on the net which are good and fast. Choose one and implement that code.

http://en.wikipedia.org/wiki/Category:Free_ciphers

Here's a WHOLE Library of Ciphers.
http://www.cryptopp.com/

This way you will have a greater deal of encryption.

And again. Try to make it at least 6 characters.

 

[PedroHLC]

I'm thinking about use one-way encryption in the key (like MD5 or SHA) and my algorithm in the file looks good, I prefer to use something that the people doesn't know yet. Well, anyway, new update, I tried to change the password size for 9 characters(what wasn't a good thing, because it's hard to make calculations w/ more than 3). The 'key.cfg' was hidden. Next version will use one-way encryption in the key, I only will have to study how I'll deal with 32 characters :S

EDIT: Someone will kill me when discovery the real about the 9 characters password, but don't worry, with the one-way encryption this will not repeat...

 

[Drago del Fato]

It's better to use the premade encryption instead if making your own. For instance AES is military approved encryption. It doesn't matter which cipher you use, it's how you use it. In order to protect an RPG Maker project you must:
1. Encrypt resources in a way that they cannot be decrypted without a key.
2. Prevent anything else except the project to have access to Scripts.rxdata.

And I'm against ecrypting audio files. It is okay for MIDI files but encrypting files above 2MB using any kind of encryption slows down the game by a fair amount. Since normally encryption is made for securing files until they reach destination, not in real time. :/

 

[Atoa]

And I'm against ecrypting audio files.

This is the thing that people most would like to encrypt, since it can't be done with rm byitself.

Also, only MP3 lovers that don't know how to convert files to more light formats (.ogg and .wma) would have problem with that...

 

[ZenVirZan]

I agree with Atoa.

And I had an idea. Pretty obvious, but anyway, i'll throw it out there

If the file was larger than 2mb (and in a 'lighter' format), couldn't you make them extract all files over x filesize to the TEMP folder at the beginning of the game, rather than at real time, name them and add to a hash or what ever, and have a loading bar/icon/screen like commercial games while doing so?
That would also, in my opinion and if done well, make your game look a lot less 'rmxp'd' and a lot cooler

There would need to be a mod to the Game_System.xxx_play methods of course, to use filenames from the hash rather than the originals if the name exists.


(also @PedroHLC,
if by making it hidden you mean like the attributes in Explorer, more likely than not someone who's looking at hacking a game will have 'show hidden files' checked)

 

[Atoa]

In fact you don't need to encrypt all files.
If the ecrypted file don't exist, it uses the normal file without any problem.

So you can simply remove the encrypted file after the encryption, and add the original one if the encrypted one cause any performance loss.

 

[Drago del Fato]

@Atoa
I know that everybody wants that. But Enterbrain did not encrypt audio files for a reason. MP3/OGG/WMA are file containers and the music needs to be streamed when the file is opened which means - the file needs to be decrypted fully to a folder and stay decrypted until the music finishes playing, then deleted.

If Enterbrain would encrypt audio into their RGSSAD archive it would result in a catastrophe because:
1. The archive itself is not available to get any other resource until the music is finished playing.
2. It needs to decrypt every part of the file and send it streaming to the audio pins. This would tremendously slow down the game (assuming that the 1. reason doesn't crash it instantly XD)

The file is vulnerable to copy at the time it is decrypted so encrypting it makes little sense. When it comes to images they are fully loaded into memory in RGSS and the link to the file is closed which takes less than a second to complete. So in any case, if a person finds out where exactly are you decrypting files they can take audio files anyway, and it slows down the game runtime.

@PedroHLC
At least add that as an option, not as a must.
And why don't you do a GUI version of the program?

 

[Atoa]

I know that everybody wants that. But Enterbrain did not encrypt audio files for a reason.

And this reason is because Eb! is lazy, simple like that, and there's no way to deny that, just look that poorly coded classes.

 

[PedroHLC]

Thanks for the comments! :biggrin:

why don't you do a GUI version of the program?

I started one, but I don't remember where I saved it :P.
I think in the next version, I'll make some external script for audios like I had done for graphics, so you make whatever you want with them.
I'm thinking about make an alternative version that use one already made encryption algorithm, but I don't have enough time now, maybe I'll do it on Wednesday(12) or only next-next Saturday(23).

Again... Thanks for all those comments! :biggrin:

 

[Drago del Fato]

@PedroHLC
No problem!
You could also simplify inserting needed scripts for Bitmap and Audio with this:
viewtopic.php?f=179&t=74432

@Atoa
All your last sentence tells me is that you did not read my post fully. I explained clearly why they decided against encrypting audio files. If Enterbrain is lazy and I'm wrong then you make it better and prove it. Otherwise your whole "rage" against Enterbrain is not founded by anything else than rage for the sake of hating something.