Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

Resource Cryptor - encryption of game client files

Newbie Spellweaver
Joined
Sep 26, 2020
Messages
15
Reaction score
8
Resource Cryptor is a small utility for encrypting read-only application files to make them harder to steal/modify/etc.

OS supported:
--- Resource Cryptor GUI: Windows 7 [x64] and higher ( is required)
--- Application modules (DLL): Windows 7 [x32/x64] and higher (Linux and macOS soon)

Download:

==================== A short guide on how to use it ====================
>>> BACK UP YOUR FILES BEFORE ALL MANIPULATIONS! <<<

1)
For simplicity of description as an example, we will assume that the executable file of your application is called MyApp.exe
2)
and run Resource Cryptor
3)
Go to the tab: Tools -> Attach Lib
4)
Click Select File and select the executable file of your application - MyApp.exe
5)
Click Attach Lib
6)
There are 2 libraries in the "modules/windows" directory (resource-cryptor-x32.dll and resource-cryptor-x64.dll). Depending on your application (x32 or x64), place the appropriate library near MyApp.exe
7)
Go to the Project tab, click Create New Project and choose where to save it.
8) Click Open Project and select the created project.
9) Go to the tab: Project -> Executable Files
10)
Click Add File and select the MyApp.exe executable file.
11) Go to the Encryption tab and drag and drop the files of your application that you want to encrypt.
12) Click Encrypt and wait for the process to complete.
13) At the end of the process, 2 additional files will be created for each source file.
For example, if we encrypt somefile.txt , then at the end of the process somefile.txt.rcmetadata and somefile.txt.xxxxx.origin (where xxxxx is some number) will be created next to it.
> somefile.txt - is an already encrypted file
> somefile.txt.rcmetadata - metadata for the client module, this file should be left next to the encrypted one.
> somefile.txt.xxxxxx.origin - the original unencrypted file (in case you forgot to make a backup).
14) The *.xxxxxx.origin files can be deleted (if you already have saved originals), the rest of the files should remain.

This completes the integration process, you can start your MyApp.exe application.

>>> And most importantly! <<<
Never any cryptor will give a 100% guarantee that files will not be extracted.
It will not save you from an experienced person tasked with stealing something from your client.

1 - Resource Cryptor - encryption of game client files - RaGEZONE Forums

2 - Resource Cryptor - encryption of game client files - RaGEZONE Forums

3 - Resource Cryptor - encryption of game client files - RaGEZONE Forums

4 - Resource Cryptor - encryption of game client files - RaGEZONE Forums

5 - Resource Cryptor - encryption of game client files - RaGEZONE Forums
 

Attachments

You must be registered for see attachments list
Last edited:
Banned
Banned
Joined
Jul 5, 2014
Messages
88
Reaction score
75
I'm getting this error when I try to encrypt a file

1701567485451 - Resource Cryptor - encryption of game client files - RaGEZONE Forums
 

Attachments

You must be registered for see attachments list
Newbie Spellweaver
Joined
Sep 26, 2020
Messages
15
Reaction score
8
I'm getting this error when I try to encrypt a file
In the ini file of the project in the "EXECUTABLE_FILES" section you need to specify the full path to your elementclient.exe file. This is required so that encrypted files can only be opened in your game client.

Example:
INI:
[EXECUTABLE_FILES]
1 = C:\Program Files\Perfect World\element\elementclient.exe

(this behavior can be disabled simply by setting "BIND_TO_EXECUTABLES = NO" in the ini file of project)

Update v0.5.1:
(first post in the thread updated)

  • Added more informative error messages
 
Last edited:
Newbie Spellweaver
Joined
Sep 26, 2020
Messages
15
Reaction score
8
7. Place the resource-cryptor-x32.dll lib next to your elementclient.exe (or resource-cryptor-x64.dll for x64 game client).

First you need to patch elementclient.exe, and only then encrypt files (specifying in the EXECUTABLE_FILES section of the project file the path to the patched elementclient.exe)

Because if you encrypt the files first and then patch elementclient.exe, the checksum for elementclient.exe will change
 
Joined
Oct 14, 2009
Messages
5,493
Reaction score
2,299
I figured I'd give you the benefit of the doubt and the chance to take it down yourself, but since you apparently want to argue about it:

It serves the same purpose - which is to obfuscate files - which is the OPPOSITE of DEVELOPMENT

Which is why that RULE was made and enforced in the first place...

Like I said, you want to argue? That's fine, I'll just report it and have it taken down then...
 
Last edited:
Newbie Spellweaver
Joined
Sep 26, 2020
Messages
15
Reaction score
8
It serves the same purpose - which is to obfuscate files
I'll let you in on a great secret - neither packers nor my utility does . Obfuscation implies irreversible changes while preserving the logic of operation.

Which is why that RULE was made and enforced in the first place...
According to your logic, for example, ALL archivers should be banned because they allow creating password-protected archives.
Or, for example, some elements.data editors that also allow you to protect files.

Also with a quick search of the forum, I found other threads that provide tools for encrypting files:
#1, #2, #3, #4, #5, ...
 
Last edited:
Joined
Oct 14, 2009
Messages
5,493
Reaction score
2,299
I'll let you in on a great secret - neither packers nor my utility does . Obfuscation implies irreversible changes while preserving the logic of operation.


According to your logic, for example, ALL archivers should be banned because they allow creating password-protected archives.
Or, for example, some elements.data editors that also allow you to protect files.

Also with a quick search of the forum, I found other threads that provide tools for encrypting files:
#1, #2, #3, #4, #5, ...

You'll notice those are in sections other than the PW section. The rule is specifically for the PW section...

The rule was implemented for at least TWO reasons that I know of. The first of which being that it CAN be used to "slipstream" nasty stuff in with otherwise good/clean files. And of course, should go without saying, that to attempt to "hide" stuff is entirely counter-intuitive to "development" - when someone tries to "hide" stuff, it's actually rather ANTI-development ... .. .

A password protected archive is indeed not really any different. If one was to share a password protected archive and NOT the password (also) then, it would be *pointless* to share in the first place... .. .

I don't know of a single elements editor that is publicly available that would allow you to "protect" the file(s)...

My main point being: This section is about PW DEVELOPMENT ~ Not packers, not archives or archivers, not "encrypters", not obfuscators, not Anything other than ~ PERFECT WORLD and it's DEVELOPMENT...

What would the point be of me releasing a PW server v179 in a LOCKED 7z? Exactly, it'd be POINTLESS.
 
Last edited:
Newbie Spellweaver
Joined
Sep 26, 2020
Messages
15
Reaction score
8
You'll notice those are in sections other than the PW section. The rule is specifically for the PW section...
Can I get a link to the official forum rules?
If it does state that it is forbidden to post PW file encryption utilities, then I will ask the moderators to move this thread to another section, as the utility is universal and its use is not limited to PW only.

The rule was implemented for at least TWO reasons that I know of. The first of which being that it CAN be used to "slipstream" nasty stuff in with otherwise good/clean files. And of course, should go without saying, that to attempt to "hide" stuff is entirely counter-intuitive to "development" - when someone tries to "hide" stuff, it's actually rather ANTI-development ... .. .
This utility is intended for game server owners who want to protect their client files.
It can encrypt game resources (*.data/etc) and does not allow you to hide any malicious code that could harm someone.
 
Joined
Oct 14, 2009
Messages
5,493
Reaction score
2,299
Yet ANOTHER point, would be - just like YOU YOURSELF point out

AND I QUOTE
>>> And most importantly! <<<
Never any cryptor will give a 100% guarantee that files will not be extracted.
It will not save you from an experienced person tasked with stealing something from your client.

So, moving forward - ALL this does is TARNISH the posterity/history of these files moving forward...

EX> 1,000 years from now someone finds these archives but for some reason all they can find are "edited" "packed" or "protected" or anything along these lines (don't play word semantics with me anymore) so they can no longer "edit" them because they've all been "edited" "packed" "protected" "obfuscated" "ETC"... How will people edit elements.data when it's "encrypted" and "packed" and whatever...

Simply put, it's BAD business for POSTERITY...

Can I get a link to the official forum rules?
If it does state that it is forbidden to post PW file encryption utilities, then I will ask the moderators to move this thread to another section, as the utility is universal and its use is not limited to PW only.


This utility is intended for game server owners who want to protect their client files.
It can encrypt game resources (*.data/etc) and does not allow you to hide any malicious code that could harm someone.


Right Here ~ NUMBER TWO

And sorry not sorry, it's in VERY POOR taste. You're welcome to your own opinion but in my own opinion doing ANYTHING of this nature is just in very poor taste... We don't "OWN" these files to start with, we're operating in a GREY if not BLACK legal area ANYWAY by operating "private servers". This is about as silly as the @$$clown I saw who said GLINK © <hisnamehere> Like no dumbass YOU do not own Glink, but, whatever...

Like I said, (AND you acknowledged) People who really want it will get it anyway, so, all stuff like this really does is hurt these files in their LONG TERM posterity... 1,000 may have been a ridiculous example but think ANY time frame... 100 years, 1000 years or even 10000 years... IJS, the whole © movement is a NEVER ENDING GAME OF CAT AND MOUSE ANYWAYS... EX> movie discs (think DVD and or BRD) come with SOME form of © protection. This is broken in a subjective amount of time (hour, day, week, month, whatever). So then "they" have to invent a NEW © protection ~ then it too WILL get cracked too. It just keeps going and going and going. So, what's actually "easier" now-a-days; just downloading a RIP, why because there's no © protection on a RIP, and you'll ALWAYS be able to watch that video file (even 1,000,000 years from now). But I bet you 1,000,000 years from now you'll still manage to have trouble playing the disc WITH the © protection on it.

So my point stands about it being BAD for the POSTERITY of these files moving forward. Even if it is for one persons personal server, WE never know whose files are going to survive and whose aren't (again, THINK, posterity)

THIS is why I am AGAINST © laws and I am (personally) ALL for the 100% FREE sharing of ALL data (even that which isn't meant to be "free")... Free as in FREE speech, AND free as in FREE beer... .. .

Which points out the HYPOCRISY while we're at it too. So someone who is essentially using STOLEN files, is now all of a sudden WORRIED about "PROTECTING" *THEIR* "WORK"

SO effing laughable ... .. .

(TLDR) The main take-away is (or should be) that © protection LITERALLY does NOTHING to stop copying... (TLDR) [which you have even acknowledged yourself, at least to some degree]
 
Last edited:
Newbie Spellweaver
Joined
Sep 26, 2020
Messages
15
Reaction score
8
How will people edit elements.data when it's "encrypted" and "packed" and whatever...
I have a feeling that you don't realize what such utilities are for.
Do you realize that server administrators encrypt files so that they cannot be stolen/edited/etc? They don't delete the original files.
You may as well make claims against any compilers, since they create an executable file from source code, after which this executable file cannot be improved by other people.

Right Here ~ NUMBER TWO
molebox or ANY other 'packers'
Do you understand the difference between packaging (where a malicious DLL can be hidden in an executable file, for example) and plain encryption of non-executable files?

THIS is why I am AGAINST © laws and I am (personally) ALL for the 100% FREE sharing of ALL data (even that which isn't meant to be "free")... Free as in FREE speech, AND free as in FREE beer... .. .
That is your right, but you have no right to force others to do the same.
 
Joined
Oct 14, 2009
Messages
5,493
Reaction score
2,299
I am only going to "argue" that it's not that this doesn't belong on RZ at all, just (certainly) NOT the PW section.

If you disagree then fine, I'll escalate the matter and we'll let the higher ups decide...

Obviously if I was still modding this wouldn't even be a conversation - it would have just been moved already... Though, I am no longer modding, so, we'll let the higher ups decide for us (if you are unwilling to concede)...

Thank you and have a GREAT rest of your day...!
 
Newbie Spellweaver
Joined
Apr 29, 2018
Messages
18
Reaction score
1
It works well, but it might not let the client open it if the specific file wasn't encrypted. This way they would not be able to place standard/modified files on the client.
 
Newbie Spellweaver
Joined
Sep 26, 2020
Messages
15
Reaction score
8
It works well, but it might not let the client open it if the specific file wasn't encrypted. This way they would not be able to place standard/modified files on the client.
Hi
Could you please describe in more detail exactly which files you are having problems with?
 
Newbie Spellweaver
Joined
Apr 29, 2018
Messages
18
Reaction score
1
Hi
Could you please describe in more detail exactly which files you are having problems with?
It's not a problem, I'm talking about an improvement, if you want to apply it. Ex.: The executable will do a check before opening the client, to see if "x" file is encrypted. If it is not there, the client will not open it.
 
Newbie Spellweaver
Joined
Sep 26, 2020
Messages
15
Reaction score
8
Update v0.6.0:
(First post in the thread has been updated)

Added option:
  • ENCRYPTED_FILES_REQUIRED ["YES", "NO"; Default: "NO"]: Whether to check for the presence of other encrypted files. If "YES" is specified, the project file lists the list of files (relative paths) to be encrypted in the "REQUIRED_ENCRYPTED_FILES" section.

This option is useful if we need to encrypt certain files in the client so that the player cannot replace one of them with an unencrypted file that he can edit. That is, the player will either have to replace all encrypted files with his own unencrypted files (which may break the client), or not touch any of them.
 
Newbie Spellweaver
Joined
Sep 26, 2020
Messages
15
Reaction score
8
Update v1.1.0:
(The first post in the thread has been updated)

Changes:
  • Reworked file encryption to improve performance (especially when accidentally reading data from a file)
  • The CACHE option has been removed from the project file
  • Added sign for executable files, which gives 0 antivirus detections for client modules (VirusTotal: and )
 
Last edited:
Back
Top