Custom? IO steam Encryption/Conversion??

Hey yo, hello, so....

I am wondering if anyone is aware of alternative IO steam 'encryption' methods. Similar to Marshal.dump/load.

Preferably one written in ruby that I can use as reference for how to write my own.

Alternatively, if you are aware of any good articles on writing custom IO steam encryption systems, please share. :)

Thanks for reading, and even more thanks if you can provide any information on this matter. :D

You are looking for solutions specifically for steam?


Encryption is a very common. Just search encryption algorithms.


Marshal isn't encryption.

Is it not? Whats the difference then. Perhaps thats where I have been going wrong...

Edit, yea, I am looking for things for writing to/reading from files that will alter the contents in some manner to make it more difficult to distinguish whats going on. :)

Edit 2:

Ok, so its serialization. 

I understand that YAML and JSON are not supported in Ace, so are there any known custom serialization scripts or anything that anyone knows of?
 

Rather than coming up with your own serialization format I would recommend just trying to support one of the standard ones.

Welp, I know nothing about encryption and such.

But I guess this script had done something similar, perhaps?

http://forums.rpgmakerweb.com/index.php?/topic/28990-est-encrypter/

http://forums.rpgmakerweb.com/index.php?/topic/28779-est-script-control/

@Theo - EST uses Marshal... :)

@Dekita - AFAIK, Marshal is the default serialization used by Ruby. Maybe you can study how JSON works and try to implement that in RGSS3? YMAL is like Marshal according to what I've read. Though it seems like Marshal is still somehow the best choice for the case of RGSS3.

I'd suggest just going on with marshal, then if you need some protection or something, add an encryption before dumping the data like what EST did. 

Yea... I have been doing something similar.
http://dekitarpg.wordpress.com/2014/11/12/dekyde-engine/

Just trying to get some more things I can use to provide additional layers of protection to my things :)

Study means looking at the grammar and implementing a reader/writer.


http://json.org/


However, the problem you are trying to solve is not just being able to read or write JSON; it's being able to actually serialize your ruby objects in a sensible way while supporting all of the possible types of data that can be thrown at you, and if you can't...then you'd have to be able to allow others to easily provide support for it.

Will have to have a good look over that later. :)

I'm also wondering if there are other serialization methods available outwith ruby? maybe some C serialisation methods that wouldnt be too tricky to utilize via some dll. 

Sounds like you want to create your own stream class. Feel free to take apart the IO subclasses I created a while ago: http://pastebin.com/AaNrudWc

*hugs*

 - Zeriab

Yea that seems like the route I require.  Thanks for sharing. That wil be much hep I think :)

You should test performance but any sort of encryption beyond 1 MB will likely require you to move to a DLL otherwise it would be too slow.

Yea I will probably be doing that anyway to try secure the method a little more - or at least try to :)

Cryptoanalysis is an unlikely attack vector. Considering only encryption parts of the files may be performance-wise important.

*hugs*

 - Zeriab

Do you mean, reversing the algorithm and then providing an unpacker?

@Zeriab - what would you say is a more likely target?

He means that if you encrypt only a part of the file, then its less of a chance that the hacker will figure it out because he/she would have to analyze which part of the file is encrypted or not, and map it out. Multiple types of encryption is significantly more secure, but quite slower. The middleground, using just one (or maybe two) type of secure encryption over a piece of a file (not the whole thing) is slightly more secure than encrypting the whole thing and it is sufficiently faster as well, if done right.


Hackers don't look for only pieces of files to be encrypted, so it'll slow them down. Can't guarantee it'll completely deter them though.

ahhh ok I get you now...

You mean like additional encryption for various areas of the file. ?

I kinda done that with my patching system - the scripts have one more level of serialization and compression compared to the rest of the patch :p

There is a bunch of interesting information available about Cryptanalysis

Let me give an extreme example of what I mean, as it is something different.

Say we want to encrypt our png-files. PNG-files have a particular header with the first byte being 0x89.

Encryption: Change first byte from 0x89 to 0x79.

Decryption: Change first byte from 0x79 to 0x89.

Doesn't get much simpler than that. Should someone try to open the picture file they'll get a corrupted error or something like that.

Now let's say that they open the file in a text editor or hex editor. PNG is there in plaintext.

Why can't it be opened?

*opens a working PNG-file*

*compares and notices the different first byte*

*changes first byte and checks if that works*

Hey.... encryption broken :D

I claimed that while this example is so simple it might actually happen. The more likely breach is that someone simply uses whatever code the game uses for decryption to decrypt the files.

While you certainly can pipe different encryptions together and increase the code path between the different encryptions, protecting against an attacker studying your code directly or through a VM is simply impractical.

The game must contain all secrets and therein lies the issue.

*hugs*

 - Zeriab

Lol, so your underlying point is, its pointless. ?

I get what you mean about how the game must contain the secrets so in the end, someone whom is able to interpret the secrets to their true meaning will always be able to cause 'damage' wherever they see fit (should they so choose to). But I mean, isnt it at least worth making it a little more time consuming in the hope of being able to deter a few folk? :)

Also, I never thought of something to simple for an encryption method :D

Certainly got me thinking now...