RM Susano'o (New Encryption System for RMXP)

[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.

I read everything, but what you posted was the reason you think they did it. DREAM and Susano'o is there to prove that encrypt audio with a reasonable security (at last better than the default one) is possbible. But let's be pratical, they could encrypt the audio if they wanted to, specially with that weak encryption. In fact the encryption should be like the one on Susano'o from the start, changing the file format and making them readable only by the project.
Or you really think that someone that use "DEAD CAFE" as magic key is really worried about security?

Otherwise your whole "rage" against Enterbrain is not founded by anything else than rage for the sake of hating something.

Ok, so my "rage" has no reason, and Eb! had a lot of reasons for making that poorly coded classes, and removing a lot of features from RMXP and VX... oh wait, they didn't really had any reason except for the lazyness...

If Enterbrain is lazy and I'm wrong then you make it better and prove it.

If i had 1/10 of the financial support Eb! have, i could do it very easly... But sadly i have to work to eat and pay bills, even my free time i'm having to spend making money, and can't pay employees to work on it, like a big company could... And also we're talking about a TEAM of developers, that are PAID to do something good. But the fact that i can't do better, no matter the reason, doesn't mean automatically that the program is perfect...
Also if you think everything is sooo good, why you're making systems to change that? Like this one: viewtopic.php?f=179&t=74432
Eb! script installation is perfect no? Oh, no... a single person made something that should be there since from the start... Eb! claim that RM is for people to make games without programing skills, but someone totally without it can't install scripts at ease with a few clicks...

@PedroHLC
I don't see a point in that, since it's already possible to use non-ecrypted audio. (or at last was, i didn't test the latest version) I think that you should only make possible to choose what encrypt, if people don't want to encrypt audio it would be skiped.

 

[Drago del Fato]

Hmm let's see your point here...

Enterbrain, which mainly deals in publishing MAGAZINES (and I say that because that means they are not ultimately focused on developing software), is concerned with a program security? Really now? XD
What you people need to understand is that RPG Maker XP/VX is made for people which want to do stuff without needing to learn a book or two about how to do it. Both RMXP and RMVX is made in that fashion so:
- Yes, it lacks tons of features many people would want.
- Yes, classes are written poorly (hmm I guess that has something to do with them mainly NOT BEING software company)

For everyone else who wants to expand their game by CHANGING SOMETHING or by adding simple scripts, Enterbrain added RGSS. You are seeing them as lazy but they went on a simplified stuff for non-programming people. Pedro's Audio encryption is a totally different way of encrypting audio, and a way that works, and you can say what you want but it does slow down the game. They did not want to do it, were they lazy or they really thought of that, neither you nor I know that. I am telling you the reason they probably did want to do it.

The reason I'm writing extensions for it is because I want to enhance it, and I like doing it. So do you. Enterbrain provided the simplified starting tools. You need to do the rest.

And one more thing, if you wish to make a commercial game (for example online game) RMXP/VX is definitely not a tool for that. It just has too many security holes and it's too limited for it (again Enterbrain was not dealing with security, they just provided basic security so that non-programmer people cannot open other people's projects). Lousy encryption is just one the many holes the RPG Maker XP/VX has.

 

[Atoa]

Enterbrain, which mainly deals in publishing MAGAZINES (and I say that because that means they are not ultimately focused on developing software),

And this justify it? I think not... The company as a whole may not be focused, but the developing team wich the function of working with software should be focused on that. No matter what is the main focus of a company, if it have many divisions, each division should make the better of their function. But well if you think that it justify it... so be it.

Pedro's Audio encryption is a totally different way of encrypting audio, and a way that works, and you can say what you want but it does slow down the game.

Did you really test the system or it's just speculation? Because i've not experienced any slowdown... even with a 12MBs MP3 i used for a test and i had no slowdown. It's not my opinion, i'm just playing it right now.

 

[ForeverZer0]

Can anyone name a game that a multi-million dollar a year company has made that has not been cracked?

Didn't think so. And keep in mind that they have teams of people working on it, industry experience, and large amounts of money on the line, and they can't stop it. Given, there is much more incentive and more people trying to crack large commercial games than RMXP ones, but the point is that even if Enterbrain would have encrypted the hell out of RMXP, somebody would have cracked it by now, we would be here in the same situation, so there is not much point in arguing about it.

I applaud this new encryption system, but it too will be cracked sometime in the near future, if not already. We are designing a custom encryption for ARC, and while it will be far more difficult to crack than RMXP's, I hold no illusions that nobody is going to.

 

[Zeriab]

It's cool to see a new encryption system and I hope you have had a bunch of fun doing it :3
You can look at the source code for my encrypter if you want to. Maybe it'll give you an idea or two: http://pastebin.com/YRDSv3Dv (Java)

As for the recommendations using encryption system such as AES it doesn't really matter. I really REALLY doubt that anyone broke the RGSSAD encryption by cryptoanalysis. It's just way easier to look at how the program does decryption.
An encryption system using something similar to a mono-alphabetic substitution cipher with the end points heavily wrapped and obfuscated will probably last longer than using AES for the encryption where you have a decryption library similar to the my encrypter which you just call.
Remember, this is not about preventing some malicious outside user from decryption a message sent from my friend to me. It's about preventing the user from decryption the encrypted content except for a certain context.

@Zer0: Or maybe there's a loophole which makes it easy.

*hugs*

 

[Drago del Fato]

Yeah but as long as encryption relies on a specific key to be used for decryption, any kind of encryption is good. Whether you had that decryption library or not if you don't have the key for decryption and no way of obtaining one instead of using brute-force check, your encryption can be considered safe.

The reason I said that he should use some encryption library is because people spent a lot of time on optimizing them to be fast in encryption and decryption.

For instance AES:

On a Pentium Pro, AES encryption requires 18 clock cycles / byte,[29] equivalent to a throughput of about 11 MiB/s for a 200 MHz processor. On a Pentium M 1.7 GHz throughput is about 60 MiB/s.

Which is more than enough for use in RMXP. The only thing that he needs to pay a lot of attention to is to make the encryption key safe. And as a suggestion for this - add salt to the key that uses specifies or make a randomized key for each project. The user of your program doesn't really need to know the key, he just needs the project to be encrypted safely.

 

[Zeriab]

Yeah but as long as encryption relies on a specific key to be used for decryption, any kind of encryption is good. Whether you had that decryption library or not if you don't have the key for decryption and no way of obtaining one instead of using brute-force check, your encryption can be considered safe.

And how to achieve that when you have the game just lying there for inspection. It must be able to decrypt the contents or you won't be able to play the game.
If you are relying on a key (or order hidden information) for decryption then that must be present in some form in the game or the resources it accesses. For an attacker it becomes a matter of finding which leads us back to obfuscation.
My thesis is that good obfuscation and bad encryption is typically stronger than bad obfuscation and good encryption. By good and bad encryption I mean from a cryptoanalysis point of view.

In terms of speed the bottle neck for my Java code is the harddrive speed.

*hugs*

 

[Atoa]

Can anyone name a game that a multi-million dollar a year company has made that has not been cracked?

Do someone really expect a PROFESSIONAL cracker to lose it's time cracking an RM Game?

People cracking company games, generally want the profit they can get by doing so OR the chagellenge it would be to make that, that's generally the two main reasons for people to crack those games.

This security is to avoid general people from stealing, not to make a defense stronger than the Pentagon or Nasa... And it does it greatly, if someone broke this by now, it's surely a person that did it for the challenge, and wouldn't spread the results for everyone.

 

[ForeverZer0]

Where can I find a job as a PROFESSIONAL game cracker? What kind of health-care do they offer? 401k or pension?
/sarcasm

As I pointed out just below the line you quoted there, there is far less motivation to crack am RMXP game. The point I was making is that far more powerful encryptions are cracked by general people. They are the ones who do it. In fact, there are many of these general people in the RMXP community who possess the know how to do it. I was only saying to you two that there is no point in arguing over "why didn't Enterbrain create a super strong encryption?". Because there is no point.

 

[Atoa]

And the error returned...

The previous version solved this issue, but it's look that the changes you've made brought it back.

 

[DJ]

This thing looks quite amazing. I'll try this on my demo.

 

[PedroHLC]

The project is now open-source, this will make this beta version complete unprotected, it is recomended to compile it yourself without the custom key system, i'm looking for code contributors...
Open source code available at github: RM-Susano-o

 

[Dahrkael]

open source encryption, madness

 

[Atoa]

@PedroHLC
I really don't get it. what's the point of having an OPEN source encryption like this?
Mas you system was really reasonably safe, considering the standards of the maker, and now you just open it to whoever want to break it...

open source encryption, madness

[2]

 

[ForeverZer0]

Any good encryption should be able to be open source and still just as strong. Look at all the popular encryptions out there. A quick Google will explain exactly how they work, yet they are still used with full confidence.

 

[Dahrkael]

popular encryptions are usually used in cases (except games) where the others cant reach the key. As you should know, every encryption from every mmorpg has been broken without too much trouble, because the key is there.

You already discussed this, in our case it isnt about the encryption itself, but about keeping the key (or whatever is used) safe.
tl;dr: hide the key or forget it.

 

[PedroHLC]

xD you can remove the "custom key-password" system and put a fixed password, compile, and it will be as protected as the original one ("or almost..."). But what can I do, when I can't continue updating the system by myself? Let's see what the community can do...
EDIT: I've checked the project and it looks like the project is still as protected as it was before releasing the source... But if you want, compile the Encrypter by yourself, so it'll be completely protected again, and try to use a EXE Packer on the resultant Game.exe before compiling the Encrypter, to protect it a little more.