Previous Page | Next Page
- by Atorasu at 3:25 AM EDT on June 3, 2020
- It seems that no data was cut off, I checked the hex of the bgm.dat and the next song starts immediately where that one ends. I extracted with vgm-t, a generic ogg extractor, and cutting all other parts of the hex out, but all resulted in the same file. It still loops properly if I timeshift the audio.
The filenames for the .ogg for KD2 were found in my memory dump. After XORing, I can see that the song names (i.e. "Last Phantasm") and their loop points are stored in define.dat, but not their filenames.
- by Atorasu at 4:18 AM EDT on June 4, 2020
- Update: I made another memory dump and looked for a mention of "Ogg." I found the typical beginning data of an .ogg and isolated all of it and saved it to a new .ogg. It seems that the music is indeed deobfuscated in memory.
Here's the .ogg. It's the first stage theme, and I'm assuming its internal filename is s_entr.ogg.
edited 4:18 AM EDT June 4, 2020
- by almendaz at 3:42 AM EDT on June 5, 2020
- Thanks for continuing research. I'm a little busy at the moment. It's not over yet.
- by almendaz at 10:38 PM EDT on June 7, 2020
- Just a tiny update (should have done with my last post):
The sample .ogg is concordant with "s_frst1.ogg" instead, both in filesize AND translated "OggS" locations. Should be useful somehow for figuring the algorhytm.
... BUT it's easier to just memdump in case someone does not want to bother - and risking incomplete sound rip.
So, if taking the easier path, make sure that filesizes coincide.
edited 10:38 PM EDT June 7, 2020
- by Atorasu at 12:14 AM EDT on June 8, 2020
- I never saw that filename, probably just slipped by me (or I misunderstood it as "forest" and thought that was stage 2). Are you suggesting that I make memory dumps of each song as they are played in game? I was planning to play the full game anyways so I'd be fine with that, especially since this method works.
I'll assume that the loop points are part of bgmlist.txt in define.dat, since the points in KD2 are also stored in define.dat where all the BGM names are listed. I'll see if this information is also in the memory dump, but I'll have to check tomorrow.
edited 12:47 AM EDT June 8, 2020
- by almendaz at 1:32 AM EDT on June 9, 2020
- In case we don't make progress with deobfuscation, the easier "memdump" should be the path to take.
You seem to be proficient with .ogg etxraction. (I was not paying attention to loop points since that information is external to the .ogg files in the majority of cases.) If the game has sound test menu, it would be even easier to memdump.
edited 1:32 AM EDT June 9, 2020
- by Atorasu at 1:39 AM EDT on June 9, 2020
- I've dumped every major .ogg file for stage and boss themes, but in each dump the only loop points present were for b_alice.ogg. It definitely seems as if this file must be manually deobfuscated/ de-encrypted.
The MediaFire folder has been updated to include a folder of all dumped music from KD1. If you have any idea on how to extract bgmlist.txt, having the deobfuscated music may help. At least for my use case however, there is no need to continue work on the music itself.
The files were manually named. They should all be correct, but I'm unsure exactly what b_comon refers to.
- by Atorasu at 1:17 AM EDT on June 26, 2020
- I took a look into the .dat files again, I noticed that "black.png" exists both inside system.dat and outside of it, in the folder with them.
The files definitely seem to be obfuscated with some Rot-N. However, I could not find anything to try to reverse this, maybe I'm not good at searching. Are you aware of any programs that I could use to reverse this? It would likely help with the bmglist.txt as well.
edited 1:19 AM EDT June 26, 2020
- by almendaz at 5:31 AM EDT on July 8, 2020
- I do not have any leads friend. This is a proper encryption scheme, not a simple XOR or ROT scheme.
Sorry if I did not reply earlier.
Barely I found that the process is dependant on the lookalike "hash" (i.e. the 32-bit number after the [FFFFFFFF] of each contained file in DPMX) and the original/encrypted bytes, such as
/decrypted byte [ZZ] := ff( [hash], /encrypted byte [ZZ-1], /encrypted byte [ZZ] )
...or something of the like - for byte at offset ZZ, "ff" some function, linear maybe.
Also, when [hash]==[0x0], we have /decrypted byte [ZZ] == /encrypted byte [ZZ]; i.e. no encrypted file in DPMX.
So many combinations of this hash value (2^32), so searching by byte association between decrypted and encrypted data is of no use.
Somebody with ASM/dissasembler knowledge would do better progress with this.
- by Atorasu at 9:52 PM EDT on July 8, 2020
- Alright then, I was really just taking a guess looking at the structure of the files, I could try once again to look in a memory dump, just dumped from a different point in the game. If not, I'll have to keep messing with it, or I'll just have to loop manually.
Either way, thanks for what was able to be extracted.
Previous Page | Next Page
Go to Page 0 1 2
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source