Gambler 34 A/GAMBLERCD34A.BIN/Utils/GP/Progs/MRipper/UTILS/LIBS.TXT

Text File | 1996-03-26 | 18KB | 517 lines

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
▒    ▒ ▒▒ ▒   ▒▒ ▒▒▒ ▒    ▒   ▒▒   ▒▒▒   ▒   ▒▒   ▒ ▒▒ ▒ ▒▒    ▒   ▒▒  ▒▒  ▒  ▒
▓▓▓▓ ▓ ▓▓ ▓ ▓▓▓▓ ▓▓▓ ▓ ▓▓ ▓ ▓▓ ▓ ▓▓ ▓▓ ▓▓▓ ▓▓ ▓ ▓▓▓ ▓▓ ▓ ▓▓▓▓▓ ▓ ▓▓▓ ▓▓ ▓ ▓ ▓ ▓
████ █ ██ █ ████ █ █ █ ██ █ ██ █ ███ █ ███ █ ██ ███ ██ █ █████ █ ███ ██ █ █ █ █
    ░ ░░░░ ░░░  ░ ░ ░ ░  ░ ░  ░ ░   ░ ░░░ ░ ░░ ░░░ ░  ░ ░     ░ ░░░ ░░░░ ░ ░ ░
    ▓ ▓  ▓ ▓    ▓ ▓ ▓ ▓  ▓ ▓  ▓ ▓   ▓ ▓   ▓  ▓ ▓   ▓  ▓ ▓     ▓ ▓   ▓  ▓ ▓   ▓
    █ █  █ ███  ██ ██ ████ █  █ ████  ███ █  █ █   ████ ███   █ ███ █  █ █   █
≡≡≡≡▒≡▒≡≡▒≡▒▒▒≡≡▒▒≡▒▒≡▒▒▒▒≡▒≡≡▒≡▒▒▒▒≡≡▒▒▒≡▒≡≡▒≡▒≡≡≡▒▒▒▒≡▒▒▒≡≡≡▒≡▒▒▒≡▒≡≡▒≡▒≡≡≡▒≡
====▒=▒▒▒▒=▒====▒=▒=▒=▒==▒=▒==▒=▒===▒=▒===▒==▒=▒===▒==▒=▒=====▒=▒===▒▒▒▒=▒===▒=
----▒-▒--▒-▒▒---▒-▒-▒-▒--▒-▒--▒-▒---▒-▒▒--▒-▒--▒▒▒-▒--▒-▒-----▒-▒▒--▒--▒-▒-▒-▒-
-▒▒▒▒-▒--▒-▒▒▒--▒---▒-▒▒▒▒-▒▒▒--▒▒▒▒--▒▒▒-▒▒▒▒-▒▒▒-▒--▒-▒--▒▒▒▒-▒▒▒--▒▒--▒▒-▒▒-
···············································································

                               Library Structures
                      Figured out by ·─═■│Æ∩■═─· @ T(/\)T
                                 Revision  1.2
                            Tuesday, March 26, 1996
                            Email: [e-mail]


 This document has been written only because there isn't any about these
 structures... and writing down things helps remembering them!!

 Use these informations in any way you want, e.g. make your own ripper,
 like I have done (MultiRipper 1.30 already extract these!)

 Libraries are found on EXE files ,tipically on demos.
 These files are made of several files linked together to form a single EXE.
 The main program searches every part needed inside itself using an index,
 made at least with names and lengths of every single file that forms the
 main EXE.
 Sometimes library are not linked to the main EXE but are separate huge
 data files, actually containing all necessary files. In demos this is
 quite unused, I found only few ones using external libs, and they're almost
 older versions of the EXE type libs. External libs are mostly found on games
 like DOOM and DARK FORCES (ever heard of *.WAD files???)
 Well, not surprisingly, also these external libs contain an index.
 The structure of this index, the Lib structure index, can also be used to
 rip off the single files.
 Unluckily, not all structures all identical, but there are few programmers
 that make standard libraries to reduce the hassle of linking demoparts
 together , so they're quite easy to decode...

 Lib Structures described in this document: (11)

 1)  Future Crew Lib
 2)  Realtech Lib (EXE)
 2a) Realtech Lib (DAT)
 3)  Psychic Link FLIB
 4)  ElectroMotive Force LIB
 5)  The Coexistence XLink 2.02
 6)  The Coexistence XLink 1.0
 7)  Pelusa Resource Compiler 0.1ß
 8)  ACME Virtual File System 1.0ß
 9)  LucasArts GOB files
 10) iD Software WAD files
 11) Cascada Resource file



 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                          ┌─· ┌───────────────┐ ·─┐
                          ╘══[┤Future Crew Lib├]══╛
                              └───────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("Unreal" , "Panic" , "FishTro" , "The Party'92" tested)

Last 4 bytes in Future crew's (old) demos are an absolute offset;
if seeking to this offset there is "└/╚ " (C02FC800) we have a Future crew
library structure... and exactly:
---------------------------------------
0: Lib Header: (dWord) Magic C02FC800
4: # of records (dWord)
8: start of lib (dWord)
{ Record structure:
  Filename: 12 Bytes
  Filler  :  4 Bytes
  Start off  dWord (absolute offset)
  Lenght     dWord
} * # of records
start of header (dWord) , absolute offset in file
EOF




 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                     ┌─· ┌───────────────────────────┐ ·─┐
                     ╘══[┤Realtech Lib (in EXE files)├]══╛
                         └───────────────────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("DX Project" , "Aquaphobia" and "Countdown" tested )

Last 4 bytes in RealTech's Demos are a LIB dimension; seeking backwards
with this value will find "REALTECH95" (and now "REALTECH96" maybe...)
------------------
00h: Lib Magic "REALTECH95"
0Ah: "=" 03Dh (unknown)
0Bh: # of Records (Word)
0Dh: structure lenght (dWord) (from 00h to start of 1st file)
{ Record structure:
  Filename: 12 Bytes
  filler:    1 byte
  Lenght:      dWord
} * # of Records
Start of file pointed by record #1
....
Start of last file
last4bytes  (lib off)
EOF
 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                     ┌─· ┌───────────────────────────┐ ·─┐
                     ╘══[┤Realtech Lib (in DAT files)├]══╛
                         └───────────────────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("Megamix" and "Dimension" tested)

The structure is the same but the file starts with "REALTECH94", so it's a
kinda older version of the EXE type (REALTECH95)
Please refer to the EXE type structure, assuming that lib magic is found
at offset 0 of file.



 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                         ┌─· ┌─────────────────┐ ·─┐
                         ╘══[┤Psychic Link FLIB├]══╛
                             └─────────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("ACT1" and "Juice" tested)

Last 8 bytes in Psychic Link's Demos are a dWord + "FLIB"
This dWord is the # of Records , and every rec is 20h bytes long, so lib
start is (nRec*32)+8 bytes from EOF

{ Record structure:
  Filename: 12 Bytes
  filler:    4 bytes
  Start off  dWord (absolute offset)
  Lenght     dWord
  Unknown    dWord
  Unknown    dWord
} * # of Records
# of Records
Lib Magic "FLIB"
EOF




 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                      ┌─· ┌───────────────────────┐ ·─┐
                      ╘══[┤ElectroMotive Force LIB├]══╛
                          └───────────────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("Verses" , "ASM95 InvTro" and "Caero" tested)

Last 12 bytes in EMF demos are 2 dWords + "EMF!"
The 1st dWord is the # of Records
The 2nd dWord is Abs offset of start of lib

{ Record structure:
  Filename: 12 Bytes
  filler:    4 bytes                        ┌
  Start off  dWord (absolute offset)────────┤not very accurate!!
  Lenght     dWord                          │sometimes is 1 byte
  Filler     dWord                          │after realstart !!
  Unknown    dWord (Start off duplicate?)   │(at least in Verses)
} * # of Records                            └
# of Records
start of Lib abs Offset
Lib Magic "EMF!"
EOF




 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                     ┌─· ┌──────────────────────────┐ ·─┐
                     ╘══[┤The Coexistence XLink 2.02├]══╛
                         └──────────────────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("TC-BABES" (T.C.),"Groove" (Fudge),"Hurtless" (TFL-TDV),"BLUES" (sYmptom),
 "The Party 95" and many more tested)

First of all, this lib is NOT standard, but having thoughly tested it I can
surely admit it's the best available! (... actually it's the ONLY one
available because other Lib linkers have never been released!)

XLC 2.02 adds a standard loader of 2392 Bytes, already pklited+optimized
This loader can be unpacked without problems, so we cannot use fixed offsets.
If exelenght varies from 2300 to 2800 (original=2392; max unpacked=2750)
is worth checking...
Overlay starts with "XLé    " (0x584C0282 0x00000000)
this is the header of lib (off 0)

Then a word indicates the # of records (nrec)
another word is the # of exes to be executed (nexe)

then at off 16 starts the encrypted part of lib.

Decompiling the loader we can see it allocates (nrec << 5 = nrec*32) bytes
then makes a simple decrypting using these instructions:

------------------------------------
           mov     cx,Number_of_rec
           shl     cx,5
           xor     bl,bl
           les     si,Encrypted_data

locloop::  sub     es:[si],bl
           inc     bl
           inc     si
           loop    locloop
------------------------------------

after (nrec*32) bytes, (nexe*0x8d) bytes are the executable names that are
executed and can be decrypted also, but we can skip this.

Then we have the complete Structure:

00 : 0x584C0282 ("XLé")  Start of lib
04 : 0x00000000
08 : # of records (1 word)
10 : # of exes    (1 word)
12 : header len?? (1 word) == 0x0010
14 : Unknown      (1 word)
16 : Begin of structure:
{ Filename: 12 Bytes  (1st entry: "_____XLC@SRT" -> EXE struct)
  filler:    4 bytes
  Lenght     1 dWord  (1st entry: Pointer to EXE struct)
  Start off  1 dWord  (relative offset from Start of lib)
  Filler     2 dWords
} * # of Records
{ 0x8d bytes (seems to be fixed) of filenames+parameters
  Filename: 12 bytes
  filler 1 byte
  Parameters: (PASCAL) len+string

} * # of exes
Start of file pointed by record #2
....
EOF

 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                     ┌─· ┌─────────────────────────┐ ·─┐
                     ╘══[┤The Coexistence XLink 1.0├]══╛
                         └─────────────────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("Contagion" tested)

This lib is the Prototype of v2.02, and the structure is simplier...
Overlay starts with 0x584C0081 0x00000000
Then a word indicates the # of records (nrec)
another word is the # of exes to be executed (nexe)
there is no encryption like in 2.02
Then we have the complete Structure:

00 : 0x584C0081  Start of lib
04 : 0x00000000
08 : # of records (1 word)
10 : # of exes    (1 word)
12 : header len?? (1 word) == 0x0010
14 : Unknown      (1 word)
16 : Begin of structure:
{ Filename: 12 Bytes  (1st entry: "_____XLC@SRT" -> EXE struct)
  filler:    3 bytes
  Lenght     1 dWord  (1st entry: Pointer to EXE struct)
  Start off  1 dWord  (relative offset from Start of lib)
} * # of Records
{ 0x8d bytes (seems to be fixed) of filenames+parameters
  Filename: 12 bytes
  filler 1 byte
  Parameters: (PASCAL) len+string

} * # of exes
Start of file pointed by record #2
....
EOF




 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                    ┌─· ┌─────────────────────────────┐ ·─┐
                    ╘══[┤Pelusa Resource Compiler 0.1ß├]══╛
                        └─────────────────────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("Fake Demo" tested)

Last 4 bytes in Pelusa demo are an absolute offset;
if seeking to this offset there is "REZ■" (52455AFE) we have a Pelusa Res.
library structure... and exactly:
---------------------------------------
0: Lib Header: (dWord) Magic 52455AFE
4: # of records (Word)
{ Record structure:
  Filename: 12 Bytes
  Filler  :  4 Bytes
  Start off  dWord (absolute offset)
  Lenght     dWord
} * # of records
start of header (dWord) , absolute offset in file
EOF



 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                    ┌─· ┌─────────────────────────────┐ ·─┐
                    ╘══[┤ACME Virtual File System 1.0ß├]══╛
                        └─────────────────────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("BIG Deal","Bug-fixed","Peek-a-Boo" tested; "Bug-fixed" contains only
 encrypted files...)

ACME VFS is similar to Xlink. The Header is a loader of variable size, but
never exceeding 2050 bytes. However Overlay starts with some magic bytes:

1 dWord is the Lib offset  (Abs. offset)
1 Word  is the lib length  (in bytes)
1 dWord is the # of Records
and 3 bytes are the Lib Magic: "VFS"

The lib structure index is encrypted using this method:
------------------------------------------------------
        mov     cx,Number_of_rec
        les     si,Encrypted_data
        cld
@loop:
        push    cx

        mov     cx,0Eh       ; 1st 0Eh bytes = Offset + length
        mov     bl,56h       ; Encr. value
locloop_1:
        xor     es:[si],bl
        inc     si
        loop    locloop_1

        mov     cx,0Dh       ; 2nd 0Dh bytes = FileName
        mov     bl,9Dh       ; Encr. value
locloop_2:
        xor     es:[si],bl
        inc     si
        loop    locloop_2

        pop     cx
        loop    @loop
------------------------------------------------------

then we have the complete structure:

(loader)
00: Lib offset   1 dWord (Abs. offset)
04: lib length   1 Word  (in bytes)
06: # of Records 1 dWord
0A: Lib Magic "VFS"
[File #1]
....
[File #x]
{Lib Structure: (Record Len = Liblen / nRec = 27)
 Unknown    1 byte
 Start off  1 dWord (abs)
 Unknown    1 byte  (always 20h, maybe file attribute??)
 Lenght     1 dWord
 Unknown    1 dWord (Maybe file date/time packed ???)
 Filename  12 Bytes
 filler     1 byte
} * # of Rec

 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                            ┌─· ┌─────────────┐ ·─┐
                            ╘══[┤LucasArts GOB├]══╛
                                └─────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

 ("Dark Forces" tested)

This is an external lib, files have always a *.GOB extension and at least
can be found in the game "Dark Forces" by LucasArts and his additional
level files.

File starts with Magic "GOB"+ LF and a dWord, the Lib Abs. offset
this is the complete structure:

0: Lib Magic: "GOB"+LF (474F4210)
4: Lib Offset (dWord)
[File #1]
....
[File #x]
# of records  (dWord) Pointed by Lib offset
{Lib Structure: (Record Len = 21)
 Start off  1 dWord (abs)
 Lenght     1 dWord
 Filename  12 Bytes
}



 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                           ┌─· ┌───────────────┐ ·─┐
                           ╘══[┤iD Software WAD├]══╛
                               └───────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("Doom","Doom ][","Heretic","Rise of The Triad" tested)

The structure is defined in "The Unofficial DOOM Specs" (DMSPCS10.ZIP)
by Hank Leukart <[e-mail]>
------------------------------------------------------------------------------
[.......]

The first twelve bytes of a Doom *.WAD file (in the shareware version it is
DOOM1.WAD, the registered version's is DOOM.WAD) are as follows:

Bytes 0 to 3 - contain the ASCII letters "IWAD" or possibly "PWAD"
Bytes 4 to 7 - contain a long integer which is the number of entries in the
"directory"
Bytes 8 to 11 - contain a pointer to the first byte of the "directory"

(Bytes 12 to the start of the directory contain object data)

The directory referred to is a list, located at the end of the WAD file,
which contains the pointers, lengths, and names of all the "objects" in the
WAD file. "Objects" means data structures such as item pictures, enemies'
pictures (frames), floor and ceiling textures, wall textures, songs, sound
effects, map data, and many others.

For example, the first 12 bytes of the shareware DOOM1.WAD file are:

49 57 41 44 f6 04 00 00 6b e5 3f 00

This is "IWAD", then 4f6 hex (=1270 decimal) for # of directory entries, then
3fe56b (=4187500 decimal) for the first byte of the directory.

Each directory entry is 16 bytes long (10 hex), arranged this way:

First four bytes: pointer to start of object (a long integer)
Next four bytes: length of object (another long integer)
Last eight bytes: name of object, ending with 00s if not eight bytes.

[.......]
------------------------------------------------------------------------------

I must add that if "length of object" is 0 , as in "E1M1" etc. entries, this
object has to be skipped, since it's only a label indicating which level is
defined hereby.
Other skippable objects include shortest ones (sprites names= 8 bytes)
and some entries that have both length and start = 0 (found at least in
"Rise of the Triad")

00: Lib Magic  (dWord) "IWAD" or "PWAD"
04: # of Recs  (dWord)
08: Lib Offset (dWord)
[Files]
{ Start   :  1 dWord
  length  :  1 dWord
  Filename:  8 bytes
} * # of Recs

 *■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■*

                        ┌─· ┌────────────────────┐ ·─┐
                        ╘══[┤Cascada VRS Resource├]══╛
                            └────────────────────┘

 *■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■▀■▄■*

("Holistic" tested )

This is an external Lib. File starts with "CDADAT" +00h +00h and a dWord
indicating the # of recs.

This is the structure:

00: Lib Magic  (qWord) (4344414441540000)
08: # of Recs  (dWord)
{ Filename: 12 bytes
  Filler  :  4 bytes
  Start   :  1 dWord
  length  :  1 dWord
} * # of Recs



****** End of Text ******