Romhacking => ROM Hacking Discussion => Topic started by: RichardMV on April 27, 2014, 05:22:43 am

Title: Dealing with an unusual file type: MFE
Post by: RichardMV on April 27, 2014, 05:22:43 am
I've recently started working on a translation patch for Atelier Marie+Elie (PS2). In opening the ISO, among the elf and irx files, there's a file significantly larger than the others with an MFE extension. I've looked it over with a hex editor, I've run it through some extraction programs, I've tried opening it with standard decompressors, but nothing seems to be working.

I'm assuming that this file contains the game data (images, music, script, etc) and that I'd be able to start on the actual translation work if I could just crack it open. Anyone know of any fancy utilities that might help me? QuickBMS looks promising, but it requires scripts to run, and there doesn't seem to be anything geared toward this particular file format.
Title: Re: Dealing with an unusual file type: MFE
Post by: Bregalad on April 28, 2014, 10:33:09 am
You should probably check this doccument out : (
Title: Re: Dealing with an unusual file type: MFE
Post by: RichardMV on April 29, 2014, 06:15:27 pm
Thank you for the document suggestion. I looked it over and I think I've made some progress, but I'm still struggling. I know that the MFE file is the virtual file system. There are two other files (and a folder called 'modules' filled with irx files) in the ISO. One, system.cnf, is the CD and boot data. The other is slpm_661.40, which is the game's product number (like the US has SCUS numbers).

the slpm file is almost 2 MB, which makes me doubt that it has the pointer info. I've looked it over in my hex editor, though, and I've found that it has some interesting text toward the end of the file. A lot of it seems like file or function names (c_set_game_mode_elie, c_set_game_mode_marie, etc.) and system messages (a lot of "[name] does not terminate" and other things). There's also reference to the irx files. This seems promising, although I'm not sure what to make of it; the names just run together without any in between data that might be a pointer (although that would be nice).

Since I'm not seeing any evidence of pointers elsewhere, I've begun looking more at the MFE file itself, hoping to find any numbers divisible by 2048 (as suggested by the guide) or otherwise indicative of pointers. The top of the MFE file has some non-text hex values, but some are duplicates (which I believe rules out sector based positioning) and none of them are divisible by 2048 (ruling out byte positioning). So, once again, I feel like I've hit a brick wall. It doesn't help that a lot of these guides I'm using seem to only skim the surface of what they want to teach me.

Of course, maybe I'm also confused by the concept of pointers themselves. I've encountered them in programming before, so it's possible that somewhere I'm mixing up the idea of c++/java (etc) pointers with hex based data pointers.

Honestly, the idea of wading through all these numbers is more daunting to me than the prospect of translating thousands of lines of Japanese. I'm pretty sure I'm still in the 'easy' part, but I get so frustrated when I can't figure something out. I'd rather spend 50 hours struggling to do something I know how to do than spend 10 hours trying to figure out how to do something with seemingly little to show for it.
Title: Re: Dealing with an unusual file type: MFE
Post by: Bregalad on April 30, 2014, 11:02:34 am
Well I can't help much since I have basically no PS2 and few PS1 knownledge. That you didn't find pointers multiple of 2048 means nothing in your case, first the pointers could be sector aligned instead of byte aligned (in which case they'd be disibislbe by 1, not of a great help), and second, I have no idea how big are the sectors on a PS2-DVD-ROM. I know the sectors on a PS1-CD-ROM are 2048 bytes, but that means nothing for the PS2-DVD-ROM.

However, the sectors are very unlikely to be smaller, they should be same size or bigger, so if the sectors were bigger and the pointers would be byte aligned, then they could be divisible by a bigger number, but also 2048, so you'd have found them.

All I can say is that with my long experience of hex hacking (soft of), you can see pointers obviously when you see a large chunks of numbers going gradually up. This is normally rather obvious to the eye if a row in your hex editor is something like 16 or 32 bytes.

Also, I can assure you that you are not in the easy part ! Chacking a virtual file system sure is extremely hard, I haven't done that but I can tell by experience that it won't be easy, especially if they used compression and/or encryption of their data, in which case you'll need to find the ASM of the code decompressing/decrypting it.

However there's some hope, this (http://"") translation has been released recently, and is by the same developers, so there is a tiny chances they used the same file system. I can't checked my AIEM disc right now cause I'm not home, but if they use the same file system, then you should hack the authors of this translation if they managed to crack it, and then you'll be able to use their knownledge for your own translation.

I am a huge fan of the Atelier series (well, at least the first two Eternal Mana games as they're the only two I could find so far), so I sure hope you'll be able to translate the game ! Cheers up.
Title: Re: Dealing with an unusual file type: MFE
Post by: alfador on April 30, 2014, 03:16:20 pm
The standard DVD data sector size is still 2048, according to what documentation I can find. Not sure about error detection and correction data, but you'll only have to worry about that if you're working with a raw disc image.

As Bregalad more-or-less said, your last-ditch hope for finding the pointer forest is probably to look for a series of increasing words near the beginning of the file--that is, a series like 00 00 00 12, 00 00 00 FE, 00 00 01 52, etc. The increasing nature of the series may be concealed by number endianness or additional data. (I'm basing this on my knowledge of how Chrono Cross, which uses an LBA scheme, is set up. A typical sample of its TOC, containing 80-bit little-endian disc-sector pointers followed by 48 bits of auxiliary data, looks like:  98 03 00 6D, A0 03 00 56,  A1 03 00 7E,  E6 03 00 73.  The pattern is easy enough to spot if you're looking for it, but if you aren't... Also, the Cross TOC has some duplicate entries that seem to correspond to deleted files, so the presence of duplicates does not rule out sector-based addressing.)

Hope that helps, and best of luck to you--I'm another fan of the Studio Gust RPGs and would like to see this game translated.