These files are weird! Both of them seem to be in a similar format, since something similar to what Sam described is happening in characters.bundle. Before each file there are two long integers (4 bytes each) which one would intuitively assume are their offsets and sizes. However for the first file, both values are the same, simply the offset at which the filenames end. The second has the first value as 0 and the second at some other offset. The third has a first value equal to the second value for the second file (hope I'm not making this confusing). From there the values don't seem to have any pattern.
The weird thing is that this is happening in both of the files. If it were only one, I could conclude that it's just some coincidence, but these patterns must have some weird meaning if it's in both.
The only thing I'm currently sure of is that the file names are null-terminated strings (they end with a null byte). I'll try look into this more and see if I can find anything.
By the way, if you have any more files to show that might help. Comparing files allows me to find similarities and differences, which helps with finding out what means what.
EDIT: Hasn't been long but I've made some progress.
The first two longs are the length of the file list (in bytes, not files) and the offset of the data starting from the begin of the file list. I'm not sure which is which, since in these two files they're identical (because the data starts directly after the file list).
After this is the file list. Each file has 3 bits of info: name, offset, and size. The name is, as I said, a null-terminated string. The offset is the offset relative to the data offset specified earlier. This is why one of the files has 0, that just means it's at the beginning of the data. The size is simple, that's just how long the file is, in bytes.
I verified this by manually extracting an XML file, and it turned out great. The issue now is decrypting the DDS files (since these seem to be the ones we want to get our hands on). As Sam said they don't seem to have headers, so in that case I can think of two possibilities, either that A) they are encrypted or compressed somehow, or B) the data their is simply the image data without the header. I think that A is much more likely than B though.
I'll write a QuickBMS script soon that will extract the files as they are. That will make it easier to look at the DDS files since they'll be separated. It'll also give directory structure and let us see what other files are in there (some, like XML, might be uncompressed).
The weird thing is that this is happening in both of the files. If it were only one, I could conclude that it's just some coincidence, but these patterns must have some weird meaning if it's in both.
The only thing I'm currently sure of is that the file names are null-terminated strings (they end with a null byte). I'll try look into this more and see if I can find anything.
By the way, if you have any more files to show that might help. Comparing files allows me to find similarities and differences, which helps with finding out what means what.
EDIT: Hasn't been long but I've made some progress.
The first two longs are the length of the file list (in bytes, not files) and the offset of the data starting from the begin of the file list. I'm not sure which is which, since in these two files they're identical (because the data starts directly after the file list).
After this is the file list. Each file has 3 bits of info: name, offset, and size. The name is, as I said, a null-terminated string. The offset is the offset relative to the data offset specified earlier. This is why one of the files has 0, that just means it's at the beginning of the data. The size is simple, that's just how long the file is, in bytes.
I verified this by manually extracting an XML file, and it turned out great. The issue now is decrypting the DDS files (since these seem to be the ones we want to get our hands on). As Sam said they don't seem to have headers, so in that case I can think of two possibilities, either that A) they are encrypted or compressed somehow, or B) the data their is simply the image data without the header. I think that A is much more likely than B though.
I'll write a QuickBMS script soon that will extract the files as they are. That will make it easier to look at the DDS files since they'll be separated. It'll also give directory structure and let us see what other files are in there (some, like XML, might be uncompressed).