[Request] unpack base.ipak

[Ich1994]

So, as far as I know now there are multiple .iwi files in one.ipak file?
And there is an .iwi header, where you can see how many .iwi files are in there AND which size each of them has.
So I could just extract the amount of bytes after the header until the size of the first .iwi and I would get the file IF they wouldnt be compressed?

Am i right?

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.

[Tomsen1410]

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"

[kokole]

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

[kokole]

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

[kokole]

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

[master131]

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);

[kokole]

@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