Densha de D: Rising Stage [.Pack with KCAP header]

[Lordmau5]

A rather obscure game series that is based on a manga many probably haven't heard about.
It's where the "multi-track-drifting" originates from.

I remember that I found some tool to unpack the files around 2 years ago, but due to them seemingly being encrypted, I wasn't able to open them in anything (be it the audio, video, text files...)

Samples:
https://cloud.lordmau5.com/s/inEaFmG7aQqkSa5

Would be cool if this could be looked into!

~ Greetings, Lordmau5

[Lordmau5]

I've actually tried tackling this myself and managed to get the extraction working through a combination of the NyxQuest and Phone Game scripts.

Code: Select all

# Densha de D: Rising Stage (0.0.1)
# script for QuickBMS http://quickbms.aluigi.org

idstring "KCAP"
get FILES long
for i = 0 < FILES
    getdstring NAME 0x40
    get UNKNOWN_1 long
    get UNKNOWN_2 long
    get OFFSET long
    get SIZE long
    get UNKNOWN_3_MAYBE_ZIP long

    log NAME OFFSET SIZE
next i

It's extracting all files perfectly fine, however...
They're all still scrambled / encrypted...
Could this potentially be where the UNKNOWN longs come in play?
I wouldn't know how to utilize them in any form of decryption through the BMS script, so there's that...

[aluigi]

The files are indeed obfuscated with XOR and probably using a seed-generated sequence of bytes as key.

Without the seed and the pseudo-random algorithm used for generating it, you can do nothing.

If interested the first bytes of the generated key sequence are: 1f 35 57 f1 d1 a6 54 75 35 fe 32 01 84 58 54 53 55 0d 85 ...

I suggest you to upload the game executable and maybe someone will figure it out.

[Lordmau5]

Alright, I've uploaded the game executable just now.

Interestingly enough, I've unpacked the .pack files of 2 of the other games as well, and the PNG headers are the exact same, which should mean the same seed was used across all of them, correct?
I've also made sure to upload the executable files of the other 3 games in the series in that case.

//EDIT: I've actually made sure to upload the Selene.dlls from the game as well, since I'm relatively sure they are in charge of doing the decryption.
I mean, the game ships with encrypted files, so somehow it needs to know how to decrypt it, right?

//EDIT2: Additionally, I've thrown 2 of the executables into Snowman to see if there's something in regards to the .pack files, and interestingly enough, there sure is.
https://paste.gg/p/Lordmau5/b83fdafaeb9 ... 679c2699da

Something's going on with the "PackPass" there, and from what I can tell, the "v63", "v60", ... variables all seem to be statically written to.

Seems to be the most useful clue in this, at least to me that doesn't know how to decipher any of this, really...

[Lordmau5]

Gentle bump...

I was away over the weekend so I wouldn't have been able to look into it more even if I would've... but the last post pretty much sums up how far I my experiments / knowledge goes

[Lordmau5]

Bump again

Maybe there is someone that can figure it out with some reverse-engineering magic.
I've tried my hands at both Snowman and Ghidra, but I've come to no proper result other than the paste.gg I linked further above which seemed the most logical to me...

//EDIT: I should additionally mention that I'd only need to be able to unpack the files, seeing as the game prefers files from a folder with the same name as the .Pack files if one is available, but falls back to the .Pack in case it can't find them

//EDIT2: I actually forgot to ask back when you responded, but how did you end up figuring out the bytes for the generated key sequence, ALuigi?
And would they be beneficial to figuring out / tracing down the algorithm, XOR seed and whatever else is needed?

[aluigi]

It's a generated sequence because it's not a repeating pattern, even on long files (usually keys are short).