Page 3 of 32

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Sat Mar 02, 2013 8:57 pm
by Ekey
Updated filelists for PS3: Added names for Patch 1.01

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Sun Mar 03, 2013 11:52 am
by Axsis
Ekey wrote:Yeah but after decompressing with ZLIB, files have new compression. You can see here examples (_dec.dat) . Compressed data begin from offset 0x24.

Code: Select all

4 Bytes - PS3T (Always)
4 Bytes - Compressed Size (Without Header (size 0x24) - Endian Big)
4 Bytes - Decomrpessed Size ? (Endian Big)
4 Bytes - Unknown (Endian Little)
4 Bytes - Unknown (Endian Little)
4 Bytes - Unknown (Endian Little)
4 Bytes - Unknown (Endian Little)
8 Bytes - Nulls
It's DXT compressed texture (PS3T = PS3 texture?)
Image

DXT5 with mipmaps in Untitled5_dec (main texture) and DXT1 with mipmaps in Untitled6_dec (normal map)

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Sun Mar 03, 2013 2:52 pm
by Ekey
huh nice (:

BTW: they are divided i just join all into one (anyway offzip unpacked by blocks)

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Tue Mar 05, 2013 12:35 am
by Rick
patch.000.tiger in PC version has ~111MB of dead/unused data. :eek:

Edit: this can't be right... if it is, PC version has 4GB+ of dead/unused data.

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Tue Mar 05, 2013 1:25 am
by sephiroth99
Rick wrote:patch.000.tiger in PC version has ~111MB of dead/unused data. :eek:

Edit: this can't be right... if it is, PC version has 4GB+ of dead/unused data.
If you only check the header, yes there is a lot of dead data. but if you look inbetween the gaps of the files listed in the bigfile header, you will find files. It also doesn't make sense that the main model (laracroft.drm) is only 161KB (xbox version).

Here's my guess with what is currently known. The main, indexed entry is the new drm format (version 22), which only contains pointers to data in the bigfile, which is of the new format too. My other guess is that the "NEXT" blocks indicate the chain ("linked list") of pointed entries, so the drm only points to the first file.

But my main guess is that it's completely wrong lol, and it's way more simple than that. It always is.

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Tue Mar 05, 2013 2:37 am
by Gh0stBlade
This is how the Bigfile works I think, sorry I should have posted this earlier when I figured it out.

1. What you do is, you read the entries normal like File Hash, Locale, Size, Offset.
2. You subtract 0x80 from the offset which will point you to the actual file.
3. This will take you to another file however, it may not be a file table, I recommend reading the first Int which is 0x16 for the file table. It's just some identifier. So if you are at a file table you....
4. Goto 0x17 (relative from start) which is the amount of entries in the file table, there is information about the offsets (you still minus 0x80). Most importantly, these point to the CDRM container offsets etc.
5. Now you need to figure out the size of the .CDRMs i haven't had a look into it I'm currently playing the PC version.

It just uses offsets pointing to a sub file table kind of thing where you can then unpack the CDRMS.

Blah *Goes back ingame*

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Tue Mar 05, 2013 6:32 am
by michalss
Rick wrote:patch.000.tiger in PC version has ~111MB of dead/unused data. :eek:

Edit: this can't be right... if it is, PC version has 4GB+ of dead/unused data.

Hi Rick,

I did check your repository and i can see you update it with TR9, are you also considering to make packer for PC,X360 please ?

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Tue Mar 05, 2013 11:12 am
by Rick
michalss wrote:Hi Rick,

I did check your repository and i can see you update it with TR9, are you also considering to make packer for PC,X360 please ?
Packer will not be possible until the DRM stuff is understood.

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Tue Mar 05, 2013 2:15 pm
by Gh0stBlade
Would be great for a repacker, it seems that no Crystal Dynamics Tomb Raider game has no modding community or any tools to unpack, repack the files because they are so big. I hope that with this game, we get the chance to do this kind of stuff.

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Tue Mar 05, 2013 2:38 pm
by michalss
Rick wrote:
michalss wrote:Hi Rick,

I did check your repository and i can see you update it with TR9, are you also considering to make packer for PC,X360 please ?
Packer will not be possible until the DRM stuff is understood.

Most likely asking about BIG file only for repack at least something, coz i guess you know structure since you have unpacker done :) Thx Just my humble guess :)

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Tue Mar 05, 2013 10:37 pm
by Ekey
Well game completed. Here PC filelists update (copy in bin_tr9\projects\Tomb Raider 9\files)

Code: Select all

bigfile - +391
bigfile_english - +1066
patch - +56
title - +58
pack8 - +10

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Tue Mar 05, 2013 11:22 pm
by Gh0stBlade
So is there an unpacker yet?

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Wed Mar 06, 2013 12:23 am
by Kamillho
Somebody gonna do model extractor for new TR(PC version)?

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Wed Mar 06, 2013 1:38 am
by howfie
model format looks really easy
models start with 0x0600000
stages start with 0x0300000
textures all start with PCD9 + DXT1/DXT3/DXT5
i'm sure somebody will do it since it don't look hard at all

however, you guys must wait for rick and ekey to figure out how the data is organized as I ran Rick's tool today and it doesn't get all the data. There's like 68,000 CDRM sections in bigfile.002 lol. when all the data is decompressed the amount of extracted CDRM data is around 10 GB. There's like 7,341 texture files and they are absolutely lovely (on PC only).

Image

Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)

Posted: Thu Mar 07, 2013 8:23 am
by howfie
ekey, if you don't mind me asking, how did you get the filenames? did you peek in the exe or did you grab them from the second section of the first bigfile (the sections that have items that start with 0x16 can have a list of strings in between the file offsets and size data, but i parsed all the strings and a lot of names that appear in your list are not in my list).

he he he is this how older TR games were too? the big files are just a list of data sections and you construct files by combining one or more of these sections (many of these sections can be used in more than one file as well)? big files are kind of like files that are composed of one or more hard links to data, right?

the reference count appears to me to be very high... there are 171,698 data sections, but combining files (which are in the second section of the first big file) i get a total of 1,860,361 files :D.

if you don't get what i mean (cuz i mumble lol), here's code I used to go through all the data in the big files.

Code: Select all

inline uint32 LE_read_uint32(std::istream& ifile)
{
 uint32 temp;
 ifile.read((char*)&temp, sizeof(temp));
 return temp;
}

int main()
{

 //
 // READ TABLE
 //

 using namespace std;
 ifstream ifile("bigfile.000.tiger", ios::binary);
 if(!ifile) return error("shit");

 // skip all the useless shit
 ifile.seekg(0x1A800);
 
 uint32 n_files = 0;

 struct TABLESUBENTRY1 {
  uint32 p01;
  uint32 p02;
  uint32 p03;
  uint32 p04;
  uint32 p05;
 };
 struct TABLESUBENTRY2 {
  uint32 p01;
  uint32 p02;
  uint32 p03;
  uint32 p04;
 };

 struct TABLEENTRY {
  uint32 p01; // 0x16
  uint32 p02;
  uint32 p03;
  uint32 p04;
  uint32 p05;
  uint32 p06;
  uint32 p07; // number of entries
  uint32 p08;
  deque<TABLESUBENTRY1> sub1;
  boost::shared_array<char> namelist;
  deque<TABLESUBENTRY2> sub2;
 };
 deque<TABLEENTRY> entrylist;
 set<uint32> fileset;

 for(;;)
    {
     uint32 currpos = (uint32)ifile.tellg();
     cout << "Table Entry #0x" << hex << entrylist.size() << " at 0x" << currpos << dec << endl;

     TABLEENTRY entry;
     entry.p01 = LE_read_uint32(ifile);
     entry.p02 = LE_read_uint32(ifile); // string length part 1
     entry.p03 = LE_read_uint32(ifile); // string length part 2
     entry.p04 = LE_read_uint32(ifile);
     entry.p05 = LE_read_uint32(ifile);
     entry.p06 = LE_read_uint32(ifile);
     entry.p07 = LE_read_uint32(ifile); // number of sections this file is composed of
     entry.p08 = LE_read_uint32(ifile);
     if(entry.p01 != 0x16) break;
     n_files += entry.p07;

     for(uint32 i = 0; i < entry.p07; i++) {
         TABLESUBENTRY1 se;
         se.p01 = LE_read_uint32(ifile);
         se.p02 = LE_read_uint32(ifile);
         se.p03 = LE_read_uint32(ifile);
         se.p04 = LE_read_uint32(ifile);
         se.p05 = LE_read_uint32(ifile);
         entry.sub1.push_back(se);
        }

     // there can be strings here, they are already null terminated
     // wtf? why did they do this retarded ass shit lol?
     uint32 len = entry.p02 + entry.p03;
     if(len) {
        boost::shared_array<char> name(new char[len]);
        LE_read_array(ifile, name.get(), len);
        entry.namelist = name;
        cout << " ";
        for(uint32 i = 0; i < len; i++) {
            if(name[i] == 0) cout << " ";
            else cout << name[i];
           }
        cout << endl;
       }

     for(uint32 i = 0; i < entry.p07; i++) {
         TABLESUBENTRY2 se;
         se.p01 = LE_read_uint32(ifile);
         se.p02 = LE_read_uint32(ifile); // offset + bigfile index
         se.p03 = LE_read_uint32(ifile); // size of section
         se.p04 = LE_read_uint32(ifile);
         entry.sub2.push_back(se);
         fileset.insert(se.p02); // add offset and bigfile index to set of files
        }

     entrylist.push_back(entry);

     // move to next 0x800-aligned position
     uint32 position = ifile.tellg();
     position = ((position + 0x7FF) & (~0x7FF));
     ifile.seekg(position);
     if(ifile.fail()) return error("Seek failure.");
    }
 ifile.close();

 cout << "Number of entries = 0x" << hex << entrylist.size() << dec << endl;
 cout << "Number of files = 0x" << hex << n_files << dec << endl;
 cout << "Number of unique files = 0x" << hex << (uint32)fileset.size() << dec << endl;

 // WORKS GREAT!
 // now let's read all these entries
 ifstream filelist[4];
 filelist[0].open("bigfile.000.tiger", ios::binary);
 filelist[1].open("bigfile.001.tiger", ios::binary);
 filelist[2].open("bigfile.002.tiger", ios::binary);
 filelist[3].open("bigfile.003.tiger", ios::binary);
 
 for(uint32 i = 0; i < entrylist.size(); i++)
    {
     cout << "Table Entry #0x" << hex << i << dec << endl;
     
     for(uint32 j = 0; j < entrylist[i].sub2.size(); j++)
        {
         // file offset and size of data
         uint32 offset = (entrylist[i].sub2[j].p02 & 0xFFFFFF00);
         uint32 size = entrylist[i].sub2[j].p03;
 
         // big file index
         uint32 bigfile = (entrylist[i].sub2[j].p02 & 0xFF);
         if(bigfile > 3) return error("Invalid bigfile index.");
 
         // move to offset
         filelist[bigfile].seekg(offset);
         if(filelist[bigfile].fail()) return error("Seek failure.");
 
         // read CDRM
         uint32 magic = LE_read_uint32(filelist[bigfile]);
         if(filelist[bigfile].fail()) return error("Read failure.");
         if(magic != 0x4D524443) return error("Not a CDRM section.");
        }
    }

 return 0;
}