Error while decompiling .rpyc

[bynejake]

error found while decompiling rpyc file

after decompling the renpy file, found the script.py has been modified

def write_rpyc_data(self, f, slot, data): ...

f.seek(len(RPYC2_HEADER) + 12 * (slot - 1), 0)

   f.seek(len(RPYC2_HEADER) + 69 * (slot - 1), 0)
   f.write(struct.pack('III', slot, start, len(data)))

def read_rpyc_data(self, f, slot): .... if header_slot == 0: return None

pos += 12

        pos += 69

so how to fix this error? please help me.

[madeddy]

More infos about this problem would be helpful. A sample file or the name of the app where this happens could also help to collect more data...

For now you can try and change at the following position https://github.com/CensoredUsername/unrpyc/blob/3a49cfade57c67332702b65d51084435e1ce1e8b/unrpyc.py#L100 the + 12 to + 69 and also three lines later the same. https://github.com/CensoredUsername/unrpyc/blob/3f79b213994946ffc38af1168222789dfea0738b/unrpyc.py#L103

[bynejake]

only the xxgame/renpy/script.py changed.

try unrpyc.py line 100 : slot, start, length = struct.unpack("III", raw_contents[position: position + 12]) 12 to 69, it will show the error i think the method stuct.unpack("III", "sample") only accept the 12 length second arg.

try unrppyc.py line 103: position += 12 12 to 69, it will show the error i think maybe read string out of range?

sample.zip

[madeddy]

Like expected. Wanted to see what happens. I believe(d) the changes in the script.py to be a trap to distract from the real change. Sry i could not be of any help.

Anyway, the problem should not unrpyc i'd say but some nonsense from the games developer. I dont know if the main dev here able is to help with this, but you can just wait if he has some free time too look some day in github. Greets

[bynejake]

found the solution, change unrpyc.py to :

have no idea why this work, lol

[CensoredUsername]

Basically, they put the header in a different location in the file, and then didn't put a terminal header entry (0, 0, 0) in there. Have you tried the --try-harder flag? it'd've probably caught it anyway using zlibscan.