- Feb 20, 2021
- 4,091
- 6,157
- Dec 13, 2017
- 1,387
- 1,385
I've played almost all Renpy games, but I can't.
AHouseInTheRift-0.5.13r3-pc, Weekend-Lollygagging-0.65-pc
- Dec 13, 2017
- 1,387
- 1,385
AHouseInTheRift uses an old version of the engine, you need a different version of the tool. v.0.11-new only works on the 7.4+ engine, which I wrote in big red letters.
- Aug 6, 2017
- 5,827
- 6,289
just use proper tool for proper game, you got 2 old and new, new is for renpy engine 7.4+ only
if you dont know which is which let me show you easiest way,
you run game 1nce , go to main folder and you will see file named "log.txt" - open it and read what it says
You don't have permission to view the spoiler content.
Log in or register now.
and if after proper usage you still got issues feel free to report
I'm not sure if it's something on my end or what but 0.11 new V3 is throwing errors when trying to decompile rpyc files from DSCS...
It keeps throwing an error that makes no sense to me ...
Edit: dropped in the entire trace instead of just the last line...
Edit2: Looking at this more, I'm wondering if the pickle.py location is a thing the dev forced by edits somewhere, because I'm not running anything linux ...
It keeps throwing an error that makes no sense to me ...
Python:
Traceback (most recent call last):
File "<redacted>\DSCS-0.1.1-win\unrpyc.py", line 194, in worker
tag_outside_block=args.tag_outside_block, init_offset=args.init_offset, try_harder=args.try_harder)
File "<redacted>\DSCS-0.1.1-win\unrpyc.py", line 157, in decompile_rpyc
ast = read_ast_from_file(in_file)
File "<redacted>\DSCS-0.1.1-win\unrpyc.py", line 130, in read_ast_from_file
data, stmts = magic.safe_loads(raw_contents, class_factory, {"_ast", "collections"})
File "../decompiler/magic.py", line 599, in safe_loads
encoding=encoding, errors=errors).load()
File "/home/tom/ab/renpy-build/tmp/install.linux-x86_64/lib/python2.7/pickle.py", line 864, in load
File "/home/tom/ab/renpy-build/tmp/install.linux-x86_64/lib/python2.7/pickle.py", line 1139, in load_reduce
File "../decompiler/magic.py", line 113, in __new__
raise FakeUnpicklingError("{0} was instantiated with unexpected arguments {1}, {2}".format(cls, args, kwargs))
FakeUnpicklingError: <class 'eval'> was instantiated with unexpected arguments ('0',), {}Edit2: Looking at this more, I'm wondering if the pickle.py location is a thing the dev forced by edits somewhere, because I'm not running anything linux ...
Last edited:
- Dec 13, 2017
- 1,387
- 1,385
- Dec 13, 2017
- 1,387
- 1,385
Unfortunately, even the original un.rpyc tool could not cope with this code, we can only wait for when and if CensoredUsername comes up with something about this game.
- Feb 20, 2021
- 4,091
- 6,157
- Dec 13, 2017
- 1,387
- 1,385
No, the unpacking is going fine, now there are problems with decompiling the code. And unfortunately the problem is at a higher level than I can afford.
- Dec 13, 2017
- 1,387
- 1,385
This is not an archive. These are compiled code files. And yes, the archive in that game is also not ordinary. There is a regular header, but the indexes for files were not considered according to the usual formula.
An archive can consist of compiled rpyc files.
But most interesting is, did the developer alter the renpy code in order for us to not be able to get to his code? It would seem like it, but it will be the first I've heard about such measures taken.
Looking at the renpy folder, it seems that loader.py is missing and there's only the bytecode (loader.pyo). Maybe the dev altered the archiver and the loader to make it impossible to extract the files.
We can do so anyway I guess by hooking into the game thru the cache folder and exporting the code as rpy files, but that doesn't work for assets. We could however export the assets thru a rpy file when they are decompiled.
Thing is, I am not sure if it's worth it. This is a very small game currently.
Anyway, I tried both by putting the un.rpy and un.rpyc in the game folder, no change.
I then tried to insert the bytecode into the cache folder. Then the game won't start.
I am pretty sure this is manual tamper proofing, good for the dev but pointless for a game at this stage really.
This is the errors from unrpyc.log.
Problem may be that the CensoredUsername code that you use is designed for Python 3 but it seems that you call the internal renpy interpreter, which is still Python 2. At least, the below is a typical error when trying to run Python 3 code in Python 2 and vice versa.
+ Decompiling "build.rpyc" - 2208 bytes
Decompiling D:\Games\Defective Sexbot Chop Shop\game\build.rpyc to D:\Games\Defective Sexbot Chop Shop\game\build.rpy...
Error while decompiling D:\Games\Defective Sexbot Chop Shop\game\build.rpyc:
Traceback (most recent call last):
File "D:\Games\Defective Sexbot Chop Shop\unrpyc.py", line 194, in worker
tag_outside_block=args.tag_outside_block, init_offset=args.init_offset, try_harder=args.try_harder)
File "D:\Games\Defective Sexbot Chop Shop\unrpyc.py", line 157, in decompile_rpyc
ast = read_ast_from_file(in_file)
File "D:\Games\Defective Sexbot Chop Shop\unrpyc.py", line 130, in read_ast_from_file
data, stmts = magic.safe_loads(raw_contents, class_factory, {"_ast", "collections"})
File "../decompiler/magic.py", line 599, in safe_loads
encoding=encoding, errors=errors).load()
File "/home/tom/ab/renpy-build/tmp/install.linux-x86_64/lib/python2.7/pickle.py", line 864, in load
File "/home/tom/ab/renpy-build/tmp/install.linux-x86_64/lib/python2.7/pickle.py", line 1139, in load_reduce
File "../decompiler/magic.py", line 113, in __new__
raise FakeUnpicklingError("{0} was instantiated with unexpected arguments {1}, {2}".format(cls, args, kwargs))
FakeUnpicklingError: <class 'eval'> was instantiated with unexpected arguments ('0',), {}
Last edited:
- Dec 13, 2017
- 1,387
- 1,385
The thing is, I've sorted out the archive. It will not be difficult to unpack the game. But decompilation is already a more complex process. Especially considering the difference in the size of the tools for unpacking and decompiling. Un.rpyc I also used. The game doesn't really start with it, and an error message is written in the log file. If I could solve this problem myself, I would solve it. But unfortunately, I don't even know where to start looking for the source of the problem. As for the loader.pyo file, this is a script for working with archives, which I use to unpack archives on the 7.4+ engine
Alright. I added to my post above as I successfully unpacked the files with your CLI tool available in this thread. I am omitting proof to avoid any potential legal hassle.
I have the structure. It seems that the first 18 bytes and the structure of the compiled files are identical to any other compiled file (first 16 bytes the text "RENPY RPC2" followed by 0x01 0x00 0x00 0x00 0x2E 0x00 0x00 0x00)
So if there's any difference, it's not in the file header I think.
Another thing is, all code and assets are in a modules folder inside the game folder, except for a few init scripts. Not exactly following the standard, but never mind.
It is impressive that such a new game with no actual assets to speak of and not especially groundbreaking code protects itself like this
But maybe we get a bit wiser if we look at the further binary composition of the compiled files. I doubt it, though, and I don't know if the renpy engine includes the compiler with the packaged game.
Last edited:
- Dec 13, 2017
- 1,387
- 1,385
Perhaps the developer decided to challenge us, the people associated with hacking RenPy games.Alright. I added to my post above as I successfully unpacked the files with your CLI tool available in this thread. Proof (webp) attached.
I have the structure. It seems that the first 18 bytes and the structure of the compiled files are identical to any other compiled file (first 16 bytes the text "RENPY RPC2" followed by 0x01 0x00 0x00 0x00 0x2E 0x00 0x00 0x00)
So if there's any difference, it's not in the file header I think.
Another thing is, all code and assets are in a modules folder inside the game folder, except for a few init scripts. Not exactly following the standard, but never mind.
It is impressive that such a new game with no actual assets to speak of and not especially groundbreaking code protects itself like this
But maybe we get a bit wiser if we look at the further binary composition of the compiled files. I doubt it, though, and I don't know if the renpy engine includes the compiler with the packaged game.
At first, he messed with the archives, and when I was able to cope with this (he even gave me a like with a heart on my message about bypassing his protection), he began to compile the code.
- Nov 9, 2021
- 365
- 942
One of main reasons is to avoid unauthorized code mods, as i already have my hands full with json modding support.Perhaps the developer decided to challenge us, the people associated with hacking RenPy games.
Plus some stuff there is used in other games, including commercial, so i would rather keep code hidden.
Generally, if person able to reverse it, they are able to write such code themselves. And if they want to learn/steal, well, they wouldn't be able to reverse.
Technically it is automatic 3kb python script what adds quite simple protection. rpyc files are valid, no dirty tricks like buffer overflows/invalid data relying on specific renpy version.
Not really a proper hackme/crackme challenge, but still it's fun to see how people poke it, maybe will add new layer or two next update