(12-01-2012, 15:27)kokole Wrote: [ -> ]2. Currently I dont think you can directly see how many .iwi files there are, but you could try to find how many "IWi" strings are there. To see the size of the iwi files you should check out the iwi header, which starts at 128 bytes before the iwi header, and is 128 bytes long.
What do you mean with that?
"you should check out the
iwi header, which starts at 128 bytes before the
iwi header"
(12-01-2012, 15:48)Tomsen1410 Wrote: [ -> ] (12-01-2012, 15:27)kokole Wrote: [ -> ]2. Currently I dont think you can directly see how many .iwi files there are, but you could try to find how many "IWi" strings are there. To see the size of the iwi files you should check out the iwi header, which starts at 128 bytes before the iwi header, and is 128 bytes long.
What do you mean with that?
"you should check out the iwi header, which starts at 128 bytes before the iwi header"
Sorry lol my mistake, iwi pre-header, or it might be a file pre-header, that tells what type of file it is and its size
you should check out the
iwi pre-header, which starts at 128 bytes before the
iwi header
Hey, I just noticed that if you divide the length of section 1 by 16, you will get how many iwi's (or files) are in the .ipak. That's because section 1 is some array of structures of 16 bytes for each file.
EDIT: lol much easier way, the 4th dword of a section header (that was unknown when I posted the header structures) is numOfEntries, which can be, number of files for example. In section index 2 numOfEntries means how many files there are in the .ipak, and in section index 1 numOfEntries means how many file descriptor structures are there.
This is all what I know about the file descriptor structures (they are located in section index 1):
Code:
typedef struct _ENTRY_DESCRIPTOR
{
DWORD checksum; // not sure what type of checksum
DWORD unknown2; // probably file index, like file n1, file n2
DWORD fileOffset; // to get offset in file, you must do section start + fileOffset
DWORD fileSize; // including pre-headers and padding
} ENTRY_DESCRIPTOR; // 16 bytes
Lets keep this thread as official iwi reversing thread
I've found this string in black ops II exe "Interlace handling should be turned on when using png_read_image" near other strings about textures and compression so I think they are using png instead of dds now on some iwi files
(12-04-2012, 21:21)kokole Wrote: [ -> ]Lets keep this thread as official iwi reversing thread
I've found this string in black ops II exe "Interlace handling should be turned on when using png_read_image" near other strings about textures and compression so I think they are using png instead of dds now on some iwi files
Black Ops II seems to use libPNG for PNG operations.
The function containing the string "Image is too high to process with png_read_png()" is png_read_png in libPNG. Use that as a reference for diassembly. Also, the game uses libPNG version 1.5.12, as specified from the game's executable.
Taken from Black Ops II Zombies:
Code:
if ( !dword_244D5FC
|| (v0 = sub_5B2890("1.5.12", 0, nullsub_3, nullsub_3, 0, sub_85C590, sub_85C5B0), (dword_244D5F8 = v0) == 0) )
return 0;
Code:
char __cdecl sub_6747E0(int a1)
{
int v2; // esi@6
int v3; // edi@6
int v4; // ebx@6
int v5; // ebp@6
int v6; // eax@6
dword_244D5E0 = *(_DWORD *)a1;
dword_244D5E4 = *(_DWORD *)(a1 + 4);
dword_244D5EC = *(int (__cdecl **)(_DWORD, _DWORD, _DWORD, _DWORD, _DWORD, _DWORD))(a1 + 12);
dword_244D5F0 = *(int (__cdecl **)(_DWORD))(a1 + 16);
dword_244D5E8 = *(_DWORD *)(a1 + 8);
if ( !sub_85C660() )
{
if ( dword_244D5F0 )
dword_244D5F0(dword_244D5E8);
return 0;
}
sub_481CB0(dword_244D5F8, 0, sub_85C5C0);
sub_54D960(dword_244D5F8, 1);
// 1st param is png_structp, 2nd param is png_infop and 3rd param is int
png_read_png((void *)dword_244D5F8, (void *)dword_244D5F4, 0);
@
master131 png uses zlib compression, you can get raw pixel data from a png applying "offzip" (a tool), but I've tried it with iwi's and it didnt work
