Tool GAME RIPPER (decrypt and extract Ren'Py, Godot, Unity, Unreal, WolfRPG, RPGM XP/VX/Ace/MZ/MV, SRPGStudio, Bakin, PGMMV, GMS, APK, JAR, WASM, EXE etc.)

[justaplayer69]

I wonder if the newer version of SRPG that the newer games are being created with is using a different type of encryption.

Yes, sort of, but GR already handles that as well. (The method is the same, ARC4, it's just the key is obfuscated differently and the default key is different too.)

As for this game, it has encrypted .srk files and an unencrypted data.dts file. The latter is extracted perfectly (although it contains only scripts, no imagery). The issue is, so far i have only seen games where both .srk and .dts were encrypted, so GR is trying to decrypt .srk files with the encryption key that works on the .dts file. Here there's no such thing because the .dts is unencrypted, and .srk files does not use the default key either. This is new, I have never seen this configuration before. I'll look into it.

 

[justaplayer69]

Just a heads up, some good news and sadly some bad news too.

ロリマゾ協奏曲【体験版】 - About the SRPG game, I've managed to fix the key detection, now both this game and Heelfall decrypted and unpacked correctly.

Goodbye_Eternity - Godot game Goodbye_Eternity version 0.11 is not encrypted, at least it does not use Godot encryption (I confirmed that encrypted flag in the pck directory header is not set). Instead it uses a custom made extension to obfuscate the assets. Version 0.13 does not use this extension, that's why GR can extract it, but v0.11 does, so GR can't do anything with it. How I know this, I've also checked GDReTools, and I've managed to pinpoint where it started to work: v0.7.0-prerelease.1 does not, but right the next release v0.7.0 does work on v0.11. I've compared the sources and there's nothing encryption related in it, mostly just Godot bytecode changes. But I've figured out that since GDReTools is a Godot application itself, it actually does execute the extensions shipped with the game, that's how it can deobfuscate. Not sure what to do with this in GR. As GR is not based on the Godot engine, it's rather problematic to run Godot extensions in it.

Castle of temptation - With the Unity game I managed to locate the crash issue. I'm about 99% sure that it happens in _unity_parsedef function, but unfortunately the error ruins the backtrace on stack, so it's not easy to debug. But I'm on the right track, it's just the fix is lot more complicated that I've anticipated.

As soon as I've finished fixing the Unity issue, I'll upload a new release. Keep tuned!

 

[Mkmd13]

I'm glad to hear that you've managed to decrypt and unpack the SRPG game correctly! Really looking forward to the new release!

 

[justaplayer69]

Thank you for your patience, here's a bugfix release!

Windows: https://attachments.f95zone.to/2025/08/5159098_gameripper-windows.zip
Linux: https://attachments.f95zone.to/2025/08/5159099_gameripper-linux.zip
Source: https://attachments.f95zone.to/2025/08/5159100_gameripper-src.zip
Repo: codeberg.org/gameripper/gameripper

Changelog:
- Unity: no more crashes
- Godot: some more heuristics
- SRPG: support more encryption combinations
- Bakin: hopefully no more false positive engine detection

The Unity parser is still EXPERIMENTAL, it does not work perfectly with Castle of temptation, but at least it does not crash any more. The reason for the crash (and why it's still not working) is that for some reason "sharedassets0.resource" file can't be parsed, so all objects and assets referencing a resource in that file won't be parsed either. I've not just fixed the crash in this case, but I have also added failsafes to prevent future crashes as well.

As for Godot, if a game uses a custom extension to obfuscate the assets, then one will have to use

You must be registered to see the links

(as that's a Godot game itself, it can run the extension, while GR cannot, GR only supports the Godot AES encryption). Sorry for the inconvenience!

 

[Dybbuk]

Hi. First thing thanks for doing this. I am pretty lazy as well and I find the principle really good. I have used in the past AssetStudio to rip unity games, but I was struggling with Corruption Town. They must have done something on their end to change the encoding, I assume... but it is not working for me anymore with Asset Studio 16 or 16.47. Your program works, but I have noticed that the quality of some of the sprites is really poor. Certainly I didn't see that issue in the past with Asset Studio.
Is this something you could look into? I have been reading previous posts and follow the instructions suggested for other games....

Spoiler: Examples

You don't have permission to view the spoiler content. Log in or register now.

I get that it is highly experimental for Unity, but just letting you know of the issues I have found. No demands on my side

 

[justaplayer69]

Your program works, but I have noticed that the quality of some of the sprites is really poor.

What do you mean? GR does not change the quality of the sprites. Textures will be extracted under the "unpacked" directory encoded as PNG, which uses a loss-less compression therefore there can be no quality loss.

Taking a look at your attachments, what's more likely is that GR's Unity decoder is buggy. More precisely it looks like there's an overflow somewhere and that's what causes these glitches. Texture codecs are implemented in

You must be registered to see the links

(and in the crunch directory), and were ported directly from AssetStudio's source (see

You must be registered to see the links

). It is possible that I've messed something up when I was converting from C++ to C.

Is this something you could look into?

I'll try to take a look as soon as I have enough spare time. In the meantime there are forks of AssetStudio which try to keep up with latest Unity releases. Maybe give a try to

You must be registered to see the links

(I've already posted this url here, and you can find it in GR's README as well).

 

[Dybbuk]

What do you mean? GR does not change the quality of the sprites. Textures will be extracted under the "unpacked" directory encoded as PNG, which uses a loss-less compression therefore there can be no quality loss.

Taking a look at your attachments, what's more likely is that GR's Unity decoder is buggy. More precisely it looks like there's an overflow somewhere and that's what causes these glitches. Texture codecs are implemented in

You must be registered to see the links

(and in the crunch directory), and were ported directly from AssetStudio's source (see

You must be registered to see the links

). It is possible that I've messed something up when I was converting from C++ to C.

I'll try to take a look as soon as I have enough spare time. In the meantime there are forks of AssetStudio which try to keep up with latest Unity releases. Maybe give a try to

You must be registered to see the links

(I've already posted this url here, and you can find it in GR's README as well).

Cheers. I have tried using some of the mentioned forks, but they do not seem to work with this particular game (at least the windows versions, I am not "technically minded" enough to use anything else...
Will wait patiently for any further developments... I fully understand that free time is a veeery valuable thing

 

[justaplayer69]

Alright, here's a new version.

Windows: https://attachments.f95zone.to/2025/08/5163550_gameripper-windows.zip
Linux: https://attachments.f95zone.to/2025/08/5163551_gameripper-linux.zip
Source: https://attachments.f95zone.to/2025/08/5163552_gameripper-src.zip
Repo: codeberg.org/gameripper/gameripper

This uses exactly the same C++ codecs like AssetStudio (AS might be a C#/.NET application, but the codecs are witten in C++).
Hopefully this solves your issue. At least "resources.assets/dpm_bust_body_spreadmasturbate_100.png" (first asset which uses the BC7 codec) had the same glitches as your attachments, and now looks file.

PS: this is not the proper solution, just a hack, I'll fix tex2d.c when I'll have the time. Using the original C++ source means less efficient code, but for now it works, and that's what matters.

 

[Dybbuk]

Cheers! That was fast. Works like a charm

 

[whitemage88]

What do you mean? GR does not change the quality of the sprites. Textures will be extracted under the "unpacked" directory encoded as PNG, which uses a loss-less compression therefore there can be no quality loss.

When attempting to extract acerola's games, such as Monica's newlywed life (as a throwback to an earlier exchange we had), they include blushes in their cg yet the extracted blushes are all grey, attached is one such blush file (you may need to open it on a white background to see it).
I'm certain this is no fault of the extraction process and they probably coded it such that there was a red layer overlaid or something, but I thought to ask just in case.

Also your post ending with "sorry for the inconvenience" when this is the best ripping program out there I've seen so far reminded me of an old Mitch Hedberg joke. He delivers it better than just the text so here's a video of it if curious:

You must be registered to see the links

Edit: Also there was another new update to the Wolf engine encryption.
I'm not sure how they do the encryption process; do you need a new decryption key manually entered (on the developer's part) rather than being able to auto-find it like you managed to do for GODOT games?

 

[justaplayer69]

Cheers! That was fast. Works like a charm

Because this isn't a proper solution, just a quick fix. Figuring out what I messed up with the BC6/7 decoders would need significantly more time.

When attempting to extract acerola's games, such as Monica's newlywed life (as a throwback to an earlier exchange we had), they include blushes in their cg yet the extracted blushes are all grey

All I can say is, the assets are indeed grey. It is possible that they are using a colorize effect from script (probably based on a game variable how much) on the texture in the game when displayed.

Also your post ending with "sorry for the inconvenience" when this is the best ripping program out there I've seen so far reminded me of an old Mitch Hedberg joke.

First thanks, I glad you like GR! That supposed to be a quote from the Hitchhicker's Guide to the Galaxy, and I said sorry because that particular game will never work with GR.

Edit: Also there was another new update to the Wolf engine encryption.
I'm not sure how they do the encryption process; do you need a new decryption key manually entered (on the developer's part) rather than being able to auto-find it like you managed to do for GODOT games?

Key is autodetected for Wolf games too. If that fails, there's a list of default keys too, manually entering the key is just the last resort.

Most of the time new versions come with a new key and that's all; but sometimes they change the encryption method too. I've already implemented multiple Wolf RPG Pro methods, but it is possible that they have changed the method again with their latest release. I often backport methods from SinFlower's awesome UberWolf tool (

You must be registered to see the links

), which now has code for some new WolfX encryption that I have never heard of before.

 

[ValkyrieSCPD]

Others - Queen's Tactics [v20] [AtelierEva] | F95zone | Adult Games | Comics | Mods | Cheats
Got some problems when unpacking this bakin game
The game ripper just got frozen and shut down

 

[justaplayer69]

Others - Queen's Tactics [v20] [AtelierEva] | F95zone | Adult Games | Comics | Mods | Cheats
Got some problems when unpacking this bakin game
The game ripper just got frozen and shut down

Works perfectly fine for me, see attachment.

I'm not saying that I don't believe you, it's just hard to fix something that you can't see.
Could you please run "gameripper.exe -vvv" (with three "v" flags), try to rip the game and attach the generated gameripper.log file here? Maybe I can tell more from the messages.