Important information: this site is currently scheduled to go offline indefinitely by end of the year.
Tomb Raider (2013) (PC) (PS3) (XBOX) (*.tiger)
-
- M-M-M-Monster veteran
- Posts: 1823
- Joined: Wed Mar 31, 2010 6:54 am
- Has thanked: 92 times
- Been thanked: 1058 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
Updated filelists for PS3: Added names for Patch 1.01
You do not have the required permissions to view the files attached to this post.
My Github repo
-
- advanced
- Posts: 48
- Joined: Fri Oct 21, 2011 12:55 pm
- Has thanked: 2 times
- Been thanked: 26 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
It's DXT compressed texture (PS3T = PS3 texture?)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
DXT5 with mipmaps in Untitled5_dec (main texture) and DXT1 with mipmaps in Untitled6_dec (normal map)
-
- M-M-M-Monster veteran
- Posts: 1823
- Joined: Wed Mar 31, 2010 6:54 am
- Has thanked: 92 times
- Been thanked: 1058 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
huh nice
BTW: they are divided i just join all into one (anyway offzip unpacked by blocks)
BTW: they are divided i just join all into one (anyway offzip unpacked by blocks)
My Github repo
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
patch.000.tiger in PC version has ~111MB of dead/unused data.
Edit: this can't be right... if it is, PC version has 4GB+ of dead/unused data.
Edit: this can't be right... if it is, PC version has 4GB+ of dead/unused data.
https://blog.gib.me/
Don't ask me about localization tools; if you don't have the resources to develop them yourself you don't need them.
Don't ask me about localization tools; if you don't have the resources to develop them yourself you don't need them.
-
- ultra-n00b
- Posts: 8
- Joined: Fri Sep 23, 2011 8:23 pm
- Has thanked: 2 times
- Been thanked: 2 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
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).Rick wrote:patch.000.tiger in PC version has ~111MB of dead/unused data.
Edit: this can't be right... if it is, PC version has 4GB+ of dead/unused data.
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.
-
- Moderator
- Posts: 719
- Joined: Mon Jul 05, 2010 8:55 pm
- Has thanked: 20 times
- Been thanked: 496 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
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*
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*
Click the thanks button if I helped!
-
- Moderator
- Posts: 954
- Joined: Sun Mar 27, 2011 8:42 pm
- Has thanked: 10 times
- Been thanked: 161 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
Rick wrote:patch.000.tiger in PC version has ~111MB of dead/unused data.
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 ?
Quick BMS Editor GUI - simple easy to use
Goto : viewtopic.php?uid=34229&f=29&t=6797&start=0
Downloads from DropBox : https://dl.dropboxusercontent.com/u/
Goto : viewtopic.php?uid=34229&f=29&t=6797&start=0
Downloads from DropBox : https://dl.dropboxusercontent.com/u/
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
Packer will not be possible until the DRM stuff is understood.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 ?
https://blog.gib.me/
Don't ask me about localization tools; if you don't have the resources to develop them yourself you don't need them.
Don't ask me about localization tools; if you don't have the resources to develop them yourself you don't need them.
-
- Moderator
- Posts: 719
- Joined: Mon Jul 05, 2010 8:55 pm
- Has thanked: 20 times
- Been thanked: 496 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
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.
Click the thanks button if I helped!
-
- Moderator
- Posts: 954
- Joined: Sun Mar 27, 2011 8:42 pm
- Has thanked: 10 times
- Been thanked: 161 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
Rick wrote:Packer will not be possible until the DRM stuff is understood.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 ?
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
Quick BMS Editor GUI - simple easy to use
Goto : viewtopic.php?uid=34229&f=29&t=6797&start=0
Downloads from DropBox : https://dl.dropboxusercontent.com/u/
Goto : viewtopic.php?uid=34229&f=29&t=6797&start=0
Downloads from DropBox : https://dl.dropboxusercontent.com/u/
-
- M-M-M-Monster veteran
- Posts: 1823
- Joined: Wed Mar 31, 2010 6:54 am
- Has thanked: 92 times
- Been thanked: 1058 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
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
You do not have the required permissions to view the files attached to this post.
My Github repo
-
- Moderator
- Posts: 719
- Joined: Mon Jul 05, 2010 8:55 pm
- Has thanked: 20 times
- Been thanked: 496 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
So is there an unpacker yet?
Click the thanks button if I helped!
-
- double-veteran
- Posts: 929
- Joined: Fri Jul 08, 2011 12:06 pm
- Location: Torrance, CA
- Has thanked: 10 times
- Been thanked: 274 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
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).
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).
-
- double-veteran
- Posts: 929
- Joined: Fri Jul 08, 2011 12:06 pm
- Location: Torrance, CA
- Has thanked: 10 times
- Been thanked: 274 times
Re: Tomb Raider (2012) (PC) (PS3) (XBOX) (*.000.tiger)
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 .
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.
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 .
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;
}