GRF: GRF Editor

[Gidz Cross]

6 hours ago, Tokei said:

Please use "Copy exception" and paste the result here; I'm unable to reproduce.

Thank you so much for your prompt response. Additional Information.

 

And here are the result from four errors from copy exception
 

To Tokei.rar

 

I did come from version 1.8.6.6 and did experience this. I just updated to the latest to check if the problem still persist.

 

[Tokei]

On 5/1/2024 at 1:04 AM, Gidz Cross said:

Thank you so much for your prompt response. Additional Information.

And here are the result from four errors from copy exception
To Tokei.rar 3.98 kB · 2 downloads

I did come from version 1.8.6.6 and did experience this. I just updated to the latest to check if the problem still persist.

Fixed in 1.8.7.3. The issue comes from selecting "red objects/textures", objects/textures that cannot normally be selected because their resources aren't found in your current GRF(s). But by clicking on the "guildhall.gnd" node, it selects everything anyway. If you want to extract everything, I'd recommend adding more resource GRFs:

(Version 1.8.7.3 also allows to read Alpha GRFs, for anyone interested...)

[Gidz Cross]

4 hours ago, Tokei said:

Fixed in 1.8.7.3. The issue comes from selecting "red objects/textures", objects/textures that cannot normally be selected because their resources aren't found in your current GRF(s). But by clicking on the "guildhall.gnd" node, it selects everything anyway. If you want to extract everything, I'd recommend adding more resource GRFs:

(Version 1.8.7.3 also allows to read Alpha GRFs, for anyone interested...)

Thank you so much tokei!

[Gidz Cross]

It fixes my problem. But every time i will open GRF Editor i see this error were detected. I thought you should know.

[Chaos92]

3 hours ago, Gidz Cross said:

It fixes my problem. But every time i will open GRF Editor i see this error were detected. I thought you should know.

What does it shows when you click the ! button ?

[Gidz Cross]

6 hours ago, Chaos92 said:

What does it shows when you click the ! button ?

Something to do with the header thingy.

Also i always do this settings to prevent opening the previous opened grf.

[Tokei]

7 hours ago, Gidz Cross said:

Something to do with the header thingy.
 

Also i always do this settings to prevent opening the previous opened grf.
 

That is... a strange issue, I'm not able to reproduce it. If you opened GRF Editor without the "Always reopen latest opened GRF", you will get a template GRF as such:

As you can see, the window title is "GRF Editor - new *", with a star at the end, meaning it hasn't been saved yet. It also has a "data" folder in it. In your screenshot, you have neither. That means you've opened an actual GRF, but that also doesn't make sense since an opened GRF will display the full path in the title. As much as I'd like to fix this issue, it doesn't seem possible to reproduce.

The error shows that the magic string is empty instead of "Master of Magic". That looks like an empty file...? That also doesn't make much sense. I would need additional information (well, assuming that error is worth fixing since it doesn't seem to trigger normally at all).

[Gidz Cross]

9 hours ago, Tokei said:

That is... a strange issue, I'm not able to reproduce it. If you opened GRF Editor without the "Always reopen latest opened GRF", you will get a template GRF as such:

As you can see, the window title is "GRF Editor - new *", with a star at the end, meaning it hasn't been saved yet. It also has a "data" folder in it. In your screenshot, you have neither. That means you've opened an actual GRF, but that also doesn't make sense since an opened GRF will display the full path in the title. As much as I'd like to fix this issue, it doesn't seem possible to reproduce.

The error shows that the magic string is empty instead of "Master of Magic". That looks like an empty file...? That also doesn't make much sense. I would need additional information (well, assuming that error is worth fixing since it doesn't seem to trigger normally at all).

I will do a quick re install.

Edit*

Yep! It was fixed. Thanks @Tokei!

Edited May 5, 2024 by Gidz Cross
Added more info

[Tokei]

Heya,

I've been receiving a lot of messages regarding encryption (again), so I wanted to clarify a few things:

• Your PMs regarding encryption matters will be redirected to this post.
• I will not be making a paid version of GRF Editor for encryption.
• Yes, I am aware there is someone selling a decryption tool.
  • No, this has nothing to do with GRF Editor being open source. GRF Editor has been open source for a very long time.
• No, I will not be updating the encryption DLL for the foreseeable future.
  • GRF Editor now has an updated encryption tool to block this decryption tool.
• GRF Editor is open source (https://github.com/Tokeiburu/GRFEditor), there's no need to pay to see the source (a few people made this request already...).

As of GRF Editor 1.8.7.2 and above, it is now possible to make your own custom encryption library and link it with GRF Editor (this is meant for developers). Here is the project file:

comp_x86.rar

This is a C++ project made for Visual Studio 2022. You can use a lower toolset for older clients as it was originally made using Visual Studio 2010, which should be more than enough. The respective Visual C++ Redistributables should be installed (x86 for the client and x64 for GRF Editor).

When making the encrypt.dll for GRF Editor:

• Use "Release" and "x64".
  • The DLL will be compiled at comp_x86\Release\x64_GrfEditor\encrypt.dll
• "#define GRF_EDITOR" in cps.h must be defined in cps.h. This exposes the encrypt/decrypt functions for GRF Editor.
• The DLL can then be loaded in GRF Editor from Tools > Settings > Application > Encryption method...
• GRF Editor uses these methods for encryption/decryption:
  • DLL int encrypt(BYTE* key, UInt32 key_len, BYTE* compressed_data, UInt32 compressed_len, UInt32 uncompressed_len);
  • DLL int decrypt(BYTE* key, UInt32 key_len, BYTE* compressed_data, UInt32 compressed_len, UInt32 uncompressed_len);
  • The compressed_data length cannot be modified. The uncompressed_len can be used for your encryption algorithm, but otherwise it isn't useful for anything.
  • The encryption happens after the compression (raw data > zlib/lzma compression > encryption). It is the final method applied on the data. You can make a custom compression library to change the compression data length.
  • The "key" parameter is the one used by GRF Editor when loading an encryption key from the software. You're free to ignore this parameter if you're not going to use this. The key from GRF Editor is 256 bytes in length.

When making the cps.dll for your client:

• Use "Release" and "Win32".
  • The DLL will be compiled at comp_x86\Release\x86_Client\cps.dll
• "#define GRF_EDITOR" in cps.h must NOT be defined. Comment it out if it isn't automatically undefined (using Win32 should undefine it by default).
• The most important function is "void decryptSub(BYTE* key, UInt32 key_len, BYTE* data, UInt32 data_len, UInt32 seed)" in cps.cpp. The function decrypts the data in the GRF using the key provided by GetGrfEncryptionKey(). This part needs to be defined on your end as the key provided is just a dummy one. Hide it, do whatever you want. By default, the encryption uses an RSA encryption method.
• This project has no protection on the DLL whatsoever. That part is entirely up to you.
  • Make sure the client-side version of your cps.dll cannot be loaded in GRF Editor directly as a custom compression library as this would... make the whole thing rather pointless.
• The methods of interest for the client side would be:
  • DLL int uncompress(BYTE* output_data, UInt32* output_len, const BYTE* compressed_data, UInt32 compressed_len)
  • int _encryptedUncompress(BYTE* uncomp, UInt32* uncompLength, const BYTE* comp, UInt32 compLength)

If you're a developer and you think your version is better than the one provided by GRF Editor, feel free to PM me as I'll make it as a default option (I will request to see the source however). Likewise, you're also free to sell those encryption DLLs if you want to, that's entirely up to you (I will not be responsible for issues related to third party encryption libraries).

Edited October 26, 2024 by Tokei

[musloveploy]

thank  Seems working fine, but you need improve on GUI...

[Tokei]

11 hours ago, musloveploy said:

thank  Seems working fine, but you need improve on GUI...

Care to elaborate on that? I'm always up for improving GRF Editor, but without any information, this doesn't really mean anything for me.

Edited August 8, 2024 by Tokei

[Gidz Cross]

On 8/4/2024 at 12:19 AM, Tokei said:

Heya,

I've been receiving a lot of messages regarding encryption (again), so I wanted to clarify a few things:

• Your PMs regarding encryption matters will be redirected to this post.
• I will not be making a paid version of GRF Editor for encryption.
• Yes, I am aware there is someone selling a decryption tool.
  • No, this has nothing to do with GRF Editor being open source. GRF Editor has been open source for a very long time.
• No, I will not be updating the encryption DLL for the foreseeable future.
• GRF Editor is open source (https://github.com/Tokeiburu/GRFEditor), there's no need to pay to see the source (a few people made this request already...).
• I am considering removing the default encryption feature until there is an alternative.

As of GRF Editor 1.8.7.2 and above, it is now possible to make your own custom encryption library and link it with GRF Editor (this is meant for developers). Here is the project file:

comp_x86.rar 88.93 kB · 24 downloads

This is a C++ project made for Visual Studio 2022. You can use a lower toolset for older clients as it was originally made using Visual Studio 2010, which should be more than enough. The respective Visual C++ Redistributables should be installed (x86 for the client and x64 for GRF Editor).

When making the encrypt.dll for GRF Editor:

• Use "Release" and "x64".
  • The DLL will be compiled at comp_x86\Release\x64_GrfEditor\encrypt.dll
• "#define GRF_EDITOR" in cps.h must be defined in cps.h. This exposes the encrypt/decrypt functions for GRF Editor.
• The DLL can then be loaded in GRF Editor from Tools > Settings > Application > Encryption method...
• GRF Editor uses these methods for encryption/decryption:
  • DLL int encrypt(BYTE* key, UInt32 key_len, BYTE* compressed_data, UInt32 compressed_len, UInt32 uncompressed_len);
  • DLL int decrypt(BYTE* key, UInt32 key_len, BYTE* compressed_data, UInt32 compressed_len, UInt32 uncompressed_len);
  • The compressed_data length cannot be modified. The uncompressed_len can be used for your encryption algorithm, but otherwise it isn't useful for anything.
  • The encryption happens after the compression (raw data > zlib/lzma compression > encryption). It is the final method applied on the data. You can make a custom compression library to change the compression data length.
  • The "key" parameter is the one used by GRF Editor when loading an encryption key from the software. You're free to ignore this parameter if you're not going to use this. The key from GRF Editor is 256 bytes in length.

When making the cps.dll for your client:

• Use "Release" and "Win32".
  • The DLL will be compiled at comp_x86\Release\x86_Client\cps.dll
• "#define GRF_EDITOR" in cps.h must NOT be defined. Comment it out if it isn't automatically undefined (using Win32 should undefine it by default).
• The most important function is "void decryptSub(BYTE* key, UInt32 key_len, BYTE* data, UInt32 data_len, UInt32 seed)" in cps.cpp. The function decrypts the data in the GRF using the key provided by GetGrfEncryptionKey(). This part needs to be defined on your end as the key provided is just a dummy one. Hide it, do whatever you want. By default, the encryption uses an RSA encryption method.
• This project has no protection on the DLL whatsoever. That part is entirely up to you.
  • Make sure the client-side version of your cps.dll cannot be loaded in GRF Editor directly as a custom compression library as this would... make the whole thing rather pointless.
• The methods of interest for the client side would be:
  • DLL int uncompress(BYTE* output_data, UInt32* output_len, const BYTE* compressed_data, UInt32 compressed_len)
  • int _encryptedUncompress(BYTE* uncomp, UInt32* uncompLength, const BYTE* comp, UInt32 compLength)

If you're a developer and you think your version is better than the one provided by GRF Editor, feel free to PM me as I'll make it as a default option (I will request to see the source however). Likewise, you're also free to sell those encryption DLLs if you want to, that's entirely up to you (I will not be responsible for issues related to third party encryption libraries).

Thank you so much for this. I saw some individuals already making money out of this release of yours. But then again i saw this:

On 8/4/2024 at 12:19 AM, Tokei said:

Likewise, you're also free to sell those encryption DLLs if you want to, that's entirely up to you (I will not be responsible for issues related to third party encryption libraries).

Hoping to have tutorials for noobs such as myself on how to build your custom encryption.

[Sapito Sucio]

Could you elaborate on how the compression works? I would like to try and maybe add some other compression options.

[konomi_con]

Japanese RO after 240917 update

cannot work

[Tokei]

Updated to 1.8.7.6:

• Added support for using different GRF magic headers (Master of Magic). It can be modified via Container options > Grf type properties > Magic header
  
• (This also means that modifying your GRF header now has no real purpose.)
• Added support for GRF version 0x300 (from jRO).

 

On 9/12/2024 at 4:12 AM, Sapito Sucio said:

Could you elaborate on how the compression works? I would like to try and maybe add some other compression options.

You can refer to this post:

Look at the compress/uncompress methods. The project files are mostly about encryption, but if you ignore that part, the compress/uncompress methods are still going to be used by the client. Just copy the method signatures and make a new project from scratch, or copy this one.

• uncompress is meant for decompressing the GRF entry.
• compress is meant for compressing emblems (it is used by the emulator, so leave zlib compression for this; unless you want to change the compression server-side as well).
• compress2 is where you'd define your own compression method (this is a custom exported method used for GRF Editor, to not conflict with the default compress method; if not defined, it will load compress instead).

Edited September 18, 2024 by Tokei

[Tokei]

Updated to 1.8.7.7:

• Updated the encryption library for added security.
• This new version may not work in older clients (hard to test on my end, do let me know).
• This version requires Microsoft Visual C++ 2022 (x86): https://aka.ms/vs/17/release/vc_redist.x86.exe
  • This is also required for your players. It is usually already installed for most, but some may not have it. The previous version of the encryption required VC++ 2010 (x86).
• A custom approach as mentioned in the above post (https://rathena.org/board/topic/77080-grf-grf-editor/?do=findComment&comment=432591) will always be more secure.
• If you do decide to rename cps.dll to something else, then you'll have to ensure your previous encryption cps.dll no longer exists. Otherwise, this will be pointless. You can leave the regular cps.dll from Gravity, that will not conflict.

Edited September 22, 2024 by Tokei

[nadomendes2]

On 9/22/2024 at 4:35 PM, Tokei said:

Updated to 1.8.7.7:

• Updated the encryption library for added security.
• This new version may not work in older clients (hard to test on my end, do let me know).
• This version requires Microsoft Visual C++ 2022 (x86): https://aka.ms/vs/17/release/vc_redist.x86.exe
  • This is also required for your players. It is usually already installed for most, but some may not have it. The previous version of the encryption required VC++ 2010 (x86).
• A custom approach as mentioned in the above post (https://rathena.org/board/topic/77080-grf-grf-editor/?do=findComment&comment=432591) will always be more secure.
• If you do decide to rename cps.dll to something else, then you'll have to ensure your previous encryption cps.dll no longer exists. Otherwise, this will be pointless. You can leave the regular cps.dll from Gravity, that will not conflict.

How would it be to encrypt with a custom encrypt.dll via grfcl.exe?

[Hexer02]

Unreadable files are encrypted. How can I do it

[Hexer02]

 

[Tokei]

21 hours ago, Hexer02 said:

 

If you're asking how to make a similar GRF, that is from File > Save advanced > Encrypt File Table.

If you're asking how to read a similar GRF, that is not made available.

[LearningRO]

On 10/3/2024 at 8:41 AM, Tokei said:

If you're asking how to make a similar GRF, that is from File > Save advanced > Encrypt File Table.

If you're asking how to read a similar GRF, that is not made available.

damn i try to do this, so no way to revert ?

[Syafiq Ouh]

Hi anyone can share graymap for ragnarok episode 19? Try to make graymap but grf is lock with password. Thanks in advance.

[Syon]

Tokei, thank you for your hard work and contributions to solving this problem. Your tools have made a huge difference in building our private server. Thank you so much!

[Syafiq Ouh]

Anyone can help me with this error? Just trying to make flat grf..

[jmsngls]

Hello, whenever I encrypt my GRF with latest version, my emblem appears all white, I'm using client 2021-11-03