Reverse Engineering RET Homepage RET Members Reverse Engineering Projects Reverse Engineering Papers Reversing Challenges Reverser Tools RET Re-Search Engine Reverse Engineering Forum Reverse Engineering Links

Go Back   Reverse Engineering Team Board > Reverse Engineering Board > File Unpacking
FAQ Members List Calendar Search Today's Posts Mark Forums Read

Thread Tools Display Modes
Old 12-10-2003, 07:40 PM
Karosa Karosa is offline
Junior Member
Join Date: Dec 2003
Posts: 2
Default Need help with proprietary file format

Okay.. Here it goes..

We have a container file (bgm.arc) which contains audio files merged to it.
(It's not packed with the old ARC archiver, it just has the same extension)

It has a catalog section, that keeps track of all files in the
container file, using 6
numbers.. :roll: BUT I have no info on how this works..
This game stores the audio in this file uncompressed, so it's just a container,
I could easily split up the file to get the audio, but then again, what I want
to write will be a universal code, that automatically splits the files, because while I
possibly can split up the BGM file successfully (even a blind can spot OGG Vorbis
headers) I will surely fail if I try to do this with the scripts (Which are
encoded, if i'm not mistaken, and they don't have a header that I can look for) (another file with same format)

So.. What we have inside is:

Audio file 1 starting at byte: 288 (Hexa:120)
Audio file 2 starting at byte: 754 324 (Hexa:B8294)
Audio file 3 starting at byte: 1 782 750 (Hexa:1B33DE)

First Catalog Entry (We need to calculate 288 from the below numbers somehow)

BGM001 116 129 11 32 1 0

In hex: 74 81 B 20 1 0

Well, let's experiment:

116+129+11 = 256

32*1+0 = 32

256+32 = 288

Second Catalog Entry (We need to calculate 754324, somehow)

BGM002 74 177 15 148 130 11

In Hex: 4A B1 0F 94 82 0B

Let's try the routine that worked the first time:

74+177+15 = 266 (Hex:10A)

148*130+11 = 19251 (Hex:4B33)

(148+130)*11 = 3058

266*3058 = 813428

19251+266 is too low
19251*266 is too high

We can't calculate it this way..
Let's look for something that still solves the first catalog entry, but is
different. But then again, maybe it was just a mistake that the first worked.
Maybe These numbers store beginning and end of the file in some way, not just
the beginning position.. I don't know..

Third Catalog Entry

BGM003 182 240 12 222 51 27

In Hex: B6 F0 0C DE 33 1B

222+51 * 27 = 7371

The objective is to find a calculation that works for all entries, or a
calculation sequence that can be defined to work for all entries.

ANY help whould be greatly appreciated.

Karosa Alabaster
Reply With Quote
Old 12-10-2003, 08:45 PM
sna sna is offline
Join Date: Jun 2003
Posts: 76

hint: in all places where you noted "in hex" - read it backwards

Reply With Quote
Old 12-11-2003, 03:06 AM
Karosa Karosa is offline
Junior Member
Join Date: Dec 2003
Posts: 2

I SEE!!! :shock: I must have been blind until now :roll: Thanxxxx
Reply With Quote

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.