Ok, I just had an idea. In my head it seems to make it near impossible for someone to obtain the data from the files with out reverse engineering ARC to get the source code.
first things first:
only the game exe should be able to encrypt and decrypt data.
when ARCed generates an encrypted archive it takes a user string generates a numerical sequence and uses that sequence in a process call to the ARC exe.
so ie
Game.exe -e list|of|files|to|encrypt 1754932017649
there is no reverse of this to get the un-encrypted files only the load_data function tied into the ruby scripts can access the decryption function
2)
the encryption key is never stored anywhere in it's full form.
3)
to get the key we call a sequence of functions that when called in a specified sequence generate a key. the sequence passed to the encrypter tells it the sequence to call these functions in to get the key.
4)
the function used in the decryption process are never publicly available in the dll so linking to it will NOT give you access to call these functions. the functions will only be called internally when a file is recognized to be encrypted
5)
now we store this sequence somewhere. while this sequence IS easily obtained like the DEADCAFE key in RGSS was with it alone it is impossible to obtain the real keys for the decryption with out reveres engineering the set of functions that are called to make the key. this IS possible but only for a significantly motivated and extremely knowledgeable individual. we can the task harder for them and thus less worth it by using a code obfuscator to make following these function calls in the byte code (thus finding the byte code that needs to be reverse engineered) more difficult.
I'm not sure if that made sense to you guys but in short this method obfuscates the key quite significantly form the public AND allows uses to have unique encryption keys
EDIT:this system is only secure if all encrypted files are combined into an archive of some sort or the scripts file made so it can't be replaced. other wise a fresh script file containing instructions to load and dump the encrypted files in non encrypted form could be encrypted with the sequence which would be easy to find and replace the existing scripts file with their freshly encrypted one so as to "inject unsafe code" like a virus. once the code is in there the encryption key doesn't matter.
this is a major flaw. perhaps you guys can take parts of this idea or build on it to remove this flaw.