This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=4201

luckcolors, posted Mon May 15, 2017 1:15 pm (23231)

---

Hello!
It's been a while since my last post but i'm back with another puzzling file, i hope you guys want to help.

So short story short, there's this guy http://unknown-developer.itch.io/ wich is making some very criptic horror games, and there's a community of people trying to solve them (there's a discord and a reddit if you want either of those feel free to ask in the thread), now going back to the games.

For the info about the game packaging structure there's a gdoc with generic info we have collected. https://docs.google.com/document/d/1q4YEHga9Q-ltPFAaXdtavLNDePwRXOWrj2STyVnbxtQ

Now about the dat files: they just seem to be a bunch of files concated toghether but we never managed to extract any of the images, we've been successful with the wav audio files though. As mentioned in the gdoc we have used wavextract and x-ripper for that https://github.com/vfspirit/wavextract.

A pattern that makes the files similar is that they all start with the game strings at the beginning, i suspect some kind of bytecode is present because i was once able to find some game numeric pins there.

If you want to help here's a collection of all the dat files we have found https://drive.google.com/drive/folders/0BxHVcrywWokwdnBzQTZ1WlZtOGs?usp=sharing and here for the wav extract build i have made https://drive.google.com/drive/folders/0BxHVcrywWokwNUJIaUFnZ0ZPWXc.

It would be amazing if we could come up with a BMS script file.

aluigi, posted Mon May 15, 2017 3:27 pm (23237)

---

This is the script for extracting all the files:
http://aluigi.org/bms/unknown_developer.bms

I have no experience with models and graphics stuff but I suspect that HDR is probably a known image format without compression, just a raw bitmap. In case you get no help on it just post in the Graphics section and I'm sure someone will help you on the fly.

luckcolors, posted Mon May 15, 2017 6:03 pm (23245)

---

Thanks man for the script!
Well it is kinda working but every file is corrupted. Also the wav files aren't getting dumped correctly.
Here's a folder containing all of the dumped wav files made by wavextract this might help figure out what is the problem with the script. https://drive.google.com/open?id=0BxHVcrywWokwMHhPbE1rMV9nUGs
I'll also investigate and report back.

luckcolors, posted Mon May 15, 2017 6:17 pm (23248)

---

I've checked a wav file and the size is correct but the data seems to be shifted by 8 bytes. Maybe the offset calculation is wrong?
Eg.
My wav files start with: RIFF.iO.WAVEfmt
Bms ones start with: WAVEfmt

aluigi, posted Mon May 15, 2017 6:49 pm (23250)

---

As far as I can see the problem happens only with [].[] because all the other 4 archives I tested are correct.
Can you confirm it?

aluigi, posted Mon May 15, 2017 7:02 pm (23252)

---

Ok fixed in 0.1.1.
Yeah it was an 8 bytes shifting, unfortunately reversing, testing and writing of the script is all made together in real-time and some mistakes happens

luckcolors, posted Mon May 15, 2017 7:32 pm (23254)

---

Yeah i understand ya.
So now the extracted wav file is not corrupted buuuut. the files differ of about 12 bits. Is it correct that bms files are supposed to be longer?
Maybe wavextract has a problem. Also i'll defintely need help with the images.

aluigi, posted Mon May 15, 2017 8:42 pm (23256)

---

What you mean with 12 bits?
And what exact archive file are you testing?

luckcolors, posted Mon May 15, 2017 8:45 pm (23258)

---

Sorry i meant bytes. The files BMS makes are 12 bytes bigger than the wavextarct ones. I was trying to understand if that's supposed to be right. I've been testing with the Against the door dat file.

I'll also make a thread in the image section of the forum as you suggested, i've never seen an ILM image file.

Sorry about the "bits" it was a typo, i've meant bytes.

camdenorrb, posted Tue May 16, 2017 11:53 pm (23290)

---

I would also like to see this extraction script be a thing, thumbs up :3

aluigi, posted Wed May 17, 2017 6:46 am (23299)

---

Well done.
Ok it wasn't a big issue, basically the information about the size of the files were contained at the specified offset, while I completely skipped that 12 bytes header and you found the header of the next file at the end of the current one.
I preferred to rewrite the script from scratch, version 0.2

camdenorrb, posted Wed May 17, 2017 2:43 pm (23301)

---

aluigi wrote:

Well done.
Ok it wasn't a big issue, basically the information about the size of the files were contained at the specified offset, while I completely skipped that 12 bytes header and you found the header of the next file at the end of the current one.
I preferred to rewrite the script from scratch, version 0.2

Is there a way to extract the RTF in the "Do not play this game"?

luckcolors, posted Wed May 17, 2017 3:15 pm (23303)

---

camdenorrb wrote:

aluigi wrote:

Well done.
Ok it wasn't a big issue, basically the information about the size of the files were contained at the specified offset, while I completely skipped that 12 bytes header and you found the header of the next file at the end of the current one.
I preferred to rewrite the script from scratch, version 0.2

Is there a way to extract the RTF in the "Do not play this game"?

Would it possible to dump the uncovered parts of the file? Every .dat file gets around 99% of coverage.
I think there might be some stuff in the uncovered data, eg. Against the door has 28kb of uncovered data.

aluigi, posted Wed May 17, 2017 4:13 pm (23304)

---

It's data without any meaning between the index and the first file, feel free to check it with a hex editor so you can see that there is nothing useful.