11-27-2012, 14:12
11-27-2012, 15:02
11-28-2012, 15:21
(11-27-2012, 15:02)JariZ Wrote: [ -> ]If somebody did it would've been posted here already.
Short answer: No.
![[Image: crying-meme_large.png]](http://ihazhoumous.files.wordpress.com/2012/02/crying-meme_large.png)
11-28-2012, 15:43
11-28-2012, 16:07
11-28-2012, 17:55
11-28-2012, 18:30
11-28-2012, 21:40
Ok, so what I have posted before might be wrong: an .ipak contains different sections, and deppending on how many sections are there, the size of the header is different.
Info here:
Looks like the index for .iwi files is 2
This is what I get after examinating the file for 10 minutes
Example for lazy people:
![[Image: qnAVU.png]](http://i.imgur.com/qnAVU.png)
The bytes in memory are reversed so we need to reverse 00 00 04 00 and we
get 00 04 00 00 which is 40000 in hex
We go to the position 40000 in the file and...
![[Image: X5j2V.png]](http://i.imgur.com/X5j2V.png)
We know why its the .iwi files section because its section 2 (index 2, reversing the bytes):
![[Image: ma40n.png]](http://i.imgur.com/ma40n.png)
You could write a tool now, or I could write it when I have time...
Info here:
Code:
Each section has a 16 bytes header, depending on the number
of sections in the .ipak header, the size of the full header
is different, example:
[.ipak header] - 16 bytes
[section 1 header] - 16 bytes
[section 2 header] - 16 bytes
Each header is of 16 bytes, so the above example file has a
48 byte header
The headers of an .ipak file are the first bytes...
.ipak 16 bytes header:
0x00 DWORD - identifier ("KAPI")
0x04 DWORD - unknown
0x08 DWORD - file size
0x0C DWORD - number of sections
secion 16 bytes header:
0x00 DWORD - section index
0x04 DWORD - data start pointer
0x08 DWORD - data size (data end = data start pointer + data size)
0x0C DWORD - unknown
Maybe each index means sound, images, and other stuffLooks like the index for .iwi files is 2
This is what I get after examinating the file for 10 minutes
Example for lazy people:
The bytes in memory are reversed so we need to reverse 00 00 04 00 and we
get 00 04 00 00 which is 40000 in hex
We go to the position 40000 in the file and...
We know why its the .iwi files section because its section 2 (index 2, reversing the bytes):
You could write a tool now, or I could write it when I have time...
11-29-2012, 16:03
Really, really nice @kokole ! +1
But there is something I dont get:
Why is the pointer reversed?
The 4th section has to do soemthing with the IWI stuff aswell.(if it does exist)
Looks like the content and the locations in memory of the .IWI file or something like that.
![[Image: lololoolo.png]](http://img211.imageshack.us/img211/9867/lololoolo.png)
I dont know a lot about these things, so someone could tell me what the 4th section could be?
But there is something I dont get:
Why is the pointer reversed?
The 4th section has to do soemthing with the IWI stuff aswell.(if it does exist)
Looks like the content and the locations in memory of the .IWI file or something like that.
I dont know a lot about these things, so someone could tell me what the 4th section could be?
11-29-2012, 22:06
@Tomsen1410
When you read from memory the bytes get reversed, for example if you use ReadProcessMemory from some address that has an int32 with a value of 2, it will appear like 02 00 00 00 instead of 00 00 00 02 in memory. Don't really know why is this but just deal with it
This .ipak file is like uhm, "ready" for memory usage.
When you read from memory the bytes get reversed, for example if you use ReadProcessMemory from some address that has an int32 with a value of 2, it will appear like 02 00 00 00 instead of 00 00 00 02 in memory. Don't really know why is this but just deal with it
This .ipak file is like uhm, "ready" for memory usage.