ZenHAX

Final Fantasy XV - *.earc(CRAF)

This script was made with this "benchmark app" of "Final Fantasy XV Windows Edition" as a base. No "endian-guessing" support for now.

In case you get ridiculous names when you make a separate folder for the extracted ".earc" file through this script, make sure to always extract the files on either the "datas" folder, or on a separate folder of its own.

However, if you think that extracting just one ".earc" archive like this isn't enough, you might want to go further. In that case, execute quickbms through way of command-line, use the script on ALL ".earc" files(if any), and then extract all these files with the script you just plan on using in either of these folders. Here's an example:

quickbms.exe E:\SQUARE_ENIX\ffxv_earc.bms "E:\SQUARE_ENIX\WINDOWS\FINAL_FANTASY_XV\BENCHMARK\datas\*.earc" "E:\SQUARE_ENIX\WINDOWS\FINAL_FANTASY_XV\BENCHMARK\datas2"

_________________
the number one killer is time
it destroys us all

Heyo! Curious if you know of a way to recompile the files into the .earc archive

not as i know of

_________________
the number one killer is time
it destroys us all

Hi, popping in here in light of the release of the game. I tried running it on those files, but they didn't work whatsoever. Trying to came out with this error:



Tried it on several different earc files as well. No luck for any of them. I checked other earcs from other folks as well, and they all had the same deal. Attached here is Noctis' earc for his model. I quickly took a glance at the hexes and I think nearly everything is identical to the demo earc files save for a few lines. If you need more samples, let me know. Thank you for your efforts.

whoops, turns out there's an "encryption" flag i have never heard of by offset 0x7(it goes by the byte 0x80). this is why you see shit like this.
you can bring up some more .earc files if you wish, and yes that includes not only these said files from actual release but from the "PLAYABLE DEMO" version of the game as well.

and if possible, do bring up the .exe from that "PLAYABLE DEMO" thing. i heard from some forums that the actual PC release of the game contains Denuvo protection.

_________________
the number one killer is time
it destroys us all

I don't have the demo anymore so I can't help there. What I can do is upload a few randomly selected samples from the full game if that helps. I can upload more from the full game if needed but the exe is too big for my poop upload speed (250 MB).

http://www.mediafire.com/file/8nl844bmhm6fjb4/FF15.rar

If they Denuvo'd up their game files and not just their exe I believe there's going to be a lot of pissed modders.

we're giving Square Enix one too many ideas by this point lol

_________________
the number one killer is time
it destroys us all

Is it still gonna be possible to open the earc files at some point soon or would it require more than just some retooling? We had some small fully functioning mods for the demos and I had hoped that Square wouldn't reformat anything

(also if you need any .earc files from the playable demo, i think I have a few backed up)

Your scimitar.bms worked nicely for Assassin's Creed 1. But some extracted files are compressed, and while assassin_creed2.bms seems to work, I see you mention scimitar_compressed.bms. I can't find it though, could you upload it?

here you go

it's kinda rough around the edges though

_________________
the number one killer is time
it destroys us all

ICO - *.DF files

this format is actually quite simple really...
in fact, there are about two archive formats with the same extension used in the game so this script has got you covered.

_________________
the number one killer is time
it destroys us all

Gacha Mecha Stadium Saru Battle/Ape Escape: Pumped & Primed - dskimg[.inf/.bin]
Saru! Get You! Million Monkeys - data0.bin/data1.bin, data2.bin/data3.bin

as these archive formats tend to store gzip-compressed files most of the time, this script tries its best to decompress them all.
apart from that you get hashed filenames. enjoy!

_________________
the number one killer is time
it destroys us all

Pipo Saru 2001 - PANTS.PAC

apparently the structure of the archive format itself uses a line to refer to the actual file itself. here's an example:

CrowdServer/RuntimeDatabase/textures/sunset4.bmp,236507136,3128

in other words, the TOC is a literal .txt file.

_________________
the number one killer is time
it destroys us all

LEVEL-5(PS2) - *.MVI

this .mvi format was only used on Dragon Quest VIII and Rogue Galaxy, although it's basically an .pss file at its very core. based on what i researched out of this format, this one uses an static encryption key with "xor" as its encryption algorithm.

although it was only intended for .mvi file decryption, it can also be used to encrypt .pss files into its target format.

_________________
the number one killer is time
it destroys us all

Siren 2/Forbidden Siren 2 - SPK.ROM/ROM.###

this format as used in the second Siren game is actually much simpler compared to the first Siren game. the format itself is built around SPK.ROM, much like how the archive format as used in the first Siren game was built around siren.tbl.

the ROM.### archives themselves weren't split into a fixed size anymore(which meant that one file could not be stored in the middle of a split archive anymore, now it has to be stored in its entirety within that archive file as well), and the referenced offset values (as seen in SPK.ROM) were accommodated for each split archive part rather than encompassing the whole archive like those all siren.### archives. there were even "name locations" for these said archives for each file as well.

_________________
the number one killer is time
it destroys us all

Siren/Forbidden Siren - siren.tbl/siren.###

the first Siren game used a rather simple structure for a .tbl file; you have the usual "offset/size/name location" values and the accompanying filename itself which was located in said "name location" value as indicated for each file.

however, the siren.### archives themselves were an entirely different matter. basically they were the result of a "fixed size" splitting method whose size was about 512MB, and as a result only the last splitted part of the archive had inferior size than that. not helping matters is the fact that the offset value itself references said offset of a file as if these archives were a single entity. as a consequence of this, i had to improvise my quickBMS skills so the files stored in that archive could be extracted without any problems whatsoever.

UPDATE(10/07/2018): this script will now not cause any more crashes with quickbms.exe. this means that the "file-extraction-in-the-middle-of-splitted-archive" part has now been improved.

_________________
the number one killer is time
it destroys us all

Nice job...
but not enough. because the files are still not enough to import. in other words, it is still not about raw. or exported files need to be re-extract.
for example: viewtopic.php?f=9&t=7424 but you've already seen it.

Could you do something about it? or is there someone you can recommend?
Thank you in advance.

for now, i'm not too interested about it. sorry.

_________________
the number one killer is time
it destroys us all

_________________
the number one killer is time
it destroys us all

Beyond Good & Evil - *.bf/*.bf#/*.###

uncovered variants are not included in this script
again, PM me if there is one format like this that's actually used in one of those Ubisoft games

_________________
the number one killer is time
it destroys us all