Anyone know what is up with these png files? I've been searching for 3 days straight trying to figure it out. I can replicate the same result in Paint Shop Pro using the map bin files from FF6 iOS telling it that it's a raw interleaved CMYK BGR file but I can't figure out how to reverse it.
[
attachment=5196][
attachment=5197][
attachment=5198][
attachment=5199]
btw I know there are other posts about these games but I didn't want to necro them. (heard that's a bad thing)
Thanks for any and all help!
Oh yeah, I remember these... *shudders*
Well could you upload the file you extracted these from, and tell me how you extracted them? I can't find the old thread and the link in there might not even work anymore.
Here are the bin files.
ff5 bins
Forgive me if my terminology is wrong. I've just started with hex editing.
I pulled the PNGs out of the bin files using a hex editor to save specific blocks. However there is also a program called
pngcheck that can extract them all at once as well using the -x command and *.bin but there are a ton of errors. The output is usually the same as manual extracting resulting in the 3 duplicate and smaller black images although sometimes they come out blank due to all the errors. There are also a few rare ones that are pulled out as normal PNGs. More on that in a minute.
The bin files have PNG headers in them. It appears to be some kind of split file system/archive so they are easy to identify and pull out with block writes. That's what pngcheck seems to do. There is an interesting thing with them though. There are other headers before the PNGs, one "INP" and the second "ICP". Anything with the "INP" header results in normal PNG output. "ICP" headers have some data trailing it and when PNGs are extracted from those you end up with the 3 images. Could it be some kind of data that is taken out of the PNG that needs to be put back in?
Looking at data0.bin in a hex editor you will see it contains file names towards the end of the file. It's some kind of directory I think. Each bin file has a header "FFDL" which is the Final Fantasy Dimensions file structure by the looks of it. Those bins might be helpful for comparison if needed so
here they are. Most of the other bin files are MP4 audio that play fine if you remove the "FFDL" header. The Android version of FF5's data OBB is also one giant "FFDL" headered file which I can't figure out what the file type actually is.
Hope that's helpful. If you need more information I will try to share.
UPDATE:
I made some progress! Using ImageMagick I was able to convert the PNG to a RAW rgb file and using TiledGGD I was able to recombine the 3 images into one although it looks a little misaligned. Now just need to figure out how to fix that and get the correct color.
[
attachment=5205]
If someone could successfully rip from the Mobile FF remakes, I'd be so happy.
Spent a lot of time on this today, but I figured it out. It's late right now and I should go to bed, but I'll try make a converter for it tomorrow.
I might also make a QuickBMS script to extract the archives with the proper names, since I think I know how that works as well.
OMG puggsoy you're awesome!
Holy cow! I was waiting to see how to decrypt the images of that game.
Great job, puggsoy!
P.D.: Would it be possible to use the same procedure with FF Dimensions? It's also encrypted in .BIN files like FF5.
Here's a QuickBMS script I made to extract the .bin files:
Code:
# Final Fantasy 5 (iOS) .bin format
#
# Written by puggsoy
# script for QuickBMS http://quickbms.aluigi.org
open FDSE "data0.bin" 1
idstring FFDL
idstring 1 FFDL
get FILENUM basename
string FILENUM | data
goto 8 1
get NAMESPOS long 1
goto 0x14 1
savepos POS 1
for POS = POS < NAMESPOS
get NAMEOFF long 1
math NAMEOFF += NAMESPOS
get SIZE long 1
get SIZE2 long 1
get NUM long 1
get OFFSET long 1
get DUMMY long 1
if NUM == FILENUM
savepos TEMP 1
goto NAMEOFF 1
get NMSZ byte 1
getdstring NAME NMSZ 1
goto TEMP 1
goto OFFSET
getdstring TYPE 3
if TYPE == "INP"
math OFFSET += 4
math SIZE -= 4
elif TYPE == "ICP"
string NAME += ".icp"
endif
log NAME OFFSET SIZE
endif
savepos POS 1
next
Keep in mind that for this to work you
MUST have the data0.bin in the same folder of whatever .bins you're extracting, since that holds all the offsets, sizes, and names. Otherwise the script will just fail.
The script will properly extract all the unencrypted PNG files (it'll just remove the INP header) so those will be directly viewable. However all the encrypted ones will have an ".icp" extension added onto the end. You'll also see ".dat" files with this on the end, those are also just encrypted PNGs so I don't know why they originally have a ".dat" extension. In any case, I'll try make a converter soon that should be able to convert any ".icp" file into a usable PNG
(03-16-2015, 04:55 AM)Oscar92player Wrote: [ -> ]P.D.: Would it be possible to use the same procedure with FF Dimensions? It's also encrypted in .BIN files like FF5.
No idea, you can upload some (or all) of them and I can take a look.
The script works the same way with Final Fantasy Dimensions, I've already proved it. There are more .icp files than FF5.
That means they used the same method of compression in both games, so if you find a way to decrypt the .icp format, we can extract the graphics of both games.
Here's icp2png. It's a command-line program:
Code:
Usage: icp2png inFile outDir
inFile: The .icp file to convert. Can alternatively be a folder containing the files to convert
outDir: The folder to save the converted files to
This is a really weird format, I'm glad I actually managed to figure it out. What I have to do is to convert the PNG to raw pixel data, then remove all the alpha values from that (they're all 0xFF anyway), and then I get a specific format that has 4 bytes of what seems to be a header (probably just a magic identifier), then a 0x400 long 32-bit colour palette, followed by the pixel data in 8bpp format. The width and height are in the ICP header before the PNG file.
In my opinion this is a really stupid and weird way to store this format. It takes up more space than necessary, is probably slower to load properly, and does literally nothing but obfuscate it for anybody wanting to extract it.
The only (possible) problem I came across was that width and height don't actually use up all the pixel data. The width is certainly correct (it renders the images properly, and incorrect width would mess them up), but the height doesn't use all the data. However from what I can tell, all it cuts off is just empty useless stuff anyway. Still pretty strange, I don't see why they don't just remove those pixels from the data altogether.
Anyway, enjoy! If anything screws up let me know.
(03-18-2015, 05:42 AM)puggsoy Wrote: [ -> ]Here's icp2png. It's a command-line program:
Code:
Usage: icp2png inFile outDir
inFile: The .icp file to convert. Can alternatively be a folder containing the files to convert
outDir: The folder to save the converted files to
This is a really weird format, I'm glad I actually managed to figure it out. What I have to do is to convert the PNG to raw pixel data, then remove all the alpha values from that (they're all 0xFF anyway), and then I get a specific format that has 4 bytes of what seems to be a header (probably just a magic identifier), then a 0x400 long 32-bit colour palette, followed by the pixel data in 8bpp format. The width and height are in the ICP header before the PNG file.
In my opinion this is a really stupid and weird way to store this format. It takes up more space than necessary, is probably slower to load properly, and does literally nothing but obfuscate it for anybody wanting to extract it.
The only (possible) problem I came across was that width and height don't actually use up all the pixel data. The width is certainly correct (it renders the images properly, and incorrect width would mess them up), but the height doesn't use all the data. However from what I can tell, all it cuts off is just empty useless stuff anyway. Still pretty strange, I don't see why they don't just remove those pixels from the data altogether.
Anyway, enjoy! If anything screws up let me know.
Puggsoy, I can't open de program, it closes inmediatly after starting.
Double-clicking doesn't work. As I said it's a command-line program, so you need to use the command prompt or a batch file. For example in a batch file you can write this:
Code:
icp2png HELP_IMG_01.png.icp .
And it will convert that image and save it in the current folder. You can convert multiple files in the folder "icps" to the folder "pngs" like this:
However if that still doesn't work then it might be missing something. Can you see any error message?
(03-18-2015, 06:02 AM)puggsoy Wrote: [ -> ]Double-clicking doesn't work. As I said it's a command-line program, so you need to use the command prompt or a batch file. For example in a batch file you can write this:
Code:
icp2png HELP_IMG_01.png.icp .
And it will convert that image and save it in the current folder. You can convert multiple files in the folder "icps" to the folder "pngs" like this:
However if that still doesn't work then it might be missing something. Can you see any error message?
I must be doing something wrong.
I've created a batch file called "icp2png.bat" with the command line "icp2png icps pngs" and I put the icp files in the folder ICPS and created a folder called PNGS. Then, I put the program and the bat file outside that folders, and click on the bat file, but it doesn't do anything, it closes inmediatly after starting again...
I also tried using the command line "icp2png HELP_IMG_01.png.icp", with the program and the batch file in the ICP files folder, but is the same.
What I'm doing wrong?
Sorry, it's my mistake. Apparently I'm missing some files that I had to add to it, I'll try fix that. My apologies.