The Re engine is just a modified version of the Unity engine. If the metadata isn't protected, it makes reverse engineering a lot easier. All I did was look for method names to determine what they were using since the strings weren't protected. To verify blowfish and murmur hash, I just searched...
When I looked into it more a few weeks ago, it seems to be using a 128-bit block cipher. The developers call it XS if you look at their strings. At offset 0x08 in the save file, that will tell the game what type of encryption, if any, to use. If I remember correctly, 0 is for not encrypted, 2 is...
Not sure how far you've gotten, but I just started looking into the PC version. From what I noticed, it reuses encryption from monster hunter world. Once the save is encrypted, it uses a murmur hash as verification.
Edit 1:
Added item ids, names, and descriptions
Edit 2:
Search for "SaveItemStatus". You should then see a structure like "ID, IntProperty,Stock, IntProperty".
If you can provide me the save, I can take a look at it. The stat rise doesn't show your actual stats, but it shows the addition. So if you see zero for say, speed, it will be base + 0.
The program itself can be used on other games if those games uses the same format. It would have to store the uncompressed data size at offset 0x08 then the data would have to follow it.
I've attached a program I created that will allow you to edit the JP of the jobs you've already unlocked...
If you search for the word money in the save file, the value is located 0x1f bytes from the start of that offset. I've attached a tool to (de)compress the save file. Just need to drag the save into the program and it will do the work. You will need .Net 5 to run it.
Edit 1:
Attached a fresh...
I've attached the 010 Editor template that I created to show the header information; works on all platforms for DQ11 S. I've also attached a picture of what it looks like.
It does, but not in that area since it's the same between platforms. The offset at 0x39 does not always land around 04. I've seen it land 12 bytes ahead because the save point info is a long string.
The value at 0x39 is not an offset, but the size of the save information. 0x3d + [0x39] will always land you at the 8byte indicator (0x4) for the string table. Adding any bytes could corrupt the save.
At the time, IDA was acting up so I couldn't turn the ASM to C.I decided to translate it to C++ to improve my ASM translation skills. It was only when I finished the program and tried to optimize it a few weeks later did I realize it was AES-256 ECB 0 IV.