Hello,

I have found this forum upon a long search in the Internet regarding the topic I am interested in.
I represent a community of mobile phone preservationists interested in collecting and trying to run various mobile applications of pre-iPhone and Android generation.

We have some phones with the data we are interested in, which use FUGUE FAT filesystem. These are Japanese mobile phones made for Japanese internal market.

We have managed to make NAND dumps of at least two devices which use FUGUE FAT (FAT16-based) filesystem. As far as we looked into it this is a filesystem similar to FAT16, and some file recovery tools even partially parse the file allocation table but do not manage to extract any useable data.

Your forum appears to be the only one which have made (or at least published) any information on FUGUE FAT.

How far did you research the filesystem format? Do you have an understanding and practical implementations in which way the FUGUE FAT is different from the regular FAT? Maybe you have made some tools to extract files from images of FUGUE FAT?

Thank you in advance for any reply,

kraze

It looks like this is the topic to which you refer: gbl08ma noted that the Casio Prizm's filesystem is Fugue FAT. Our Prizm Wiki has a page on the filesystem, and links to a PDF about the fileystem. I'll have to defer to the folks who have spent more time with the filesystem for more details.

Edit: Irritatingly, the PDF doesn't exist any longer, and archive.org doesn't have it. Perhaps someone has it on their own computer.

Maybe this is helpful?

https://bible.planet-casio.com/yatis/software/fs/fugue.html

The part about BFile isn’t relevant though, because that’s Casio’s wrapper around the Fugue APIs.

Maybe the PDF is this one? http://www.skyhighmemory.com/download/softwareTools/Brochure_for_Kyoto_Software_Research_Fugue_Flash_File_System.pdf
That’s just what comes up when I Google “Fugue Flash” though, so you probably already found that one

Thank you everybody,

@KermMartian, I did study these topics and they mainly concern Prizm's wrapper and how to interface with, not the raw filesystem.

@Heath, somehow I missed that page during my initial search. It indeed gives more information as to Yatis' earlier notes I have found earlier.

The PDF is sadly just advertising material.

By earlier notes I meant these:

https://gitea.planet-casio.com/Yatis/bible_documentations/src/branch/master/software/notes/g35EII_OS03.00.2200_Fugue_FS.txt

https://gitea.planet-casio.com/Yatis/bible_documentations/src/branch/master/software/notes/g35EII_OS03.00.2200_random_notes.txt

"""
As far as we looked into it this is a filesystem similar to FAT16, and some file recovery tools even partially parse the file allocation table but do not manage to extract any useable data.

How far did you research the filesystem format? Do you have an understanding and practical implementations in which way the FUGUE FAT is different from the regular FAT? Maybe you have made some tools to extract files from images of FUGUE FAT?
"""
Hello,

After many tests and reverse engineering using a custom "on-calc" tracer (gintrace) which uses hardware breakpoints to follow the execution of many Fugue's internal primitives, and also using a custom addin (fsctl) which strictly checks FATs validity (and other information about Fugue) plus searches for each possible FAT entry (yes, there are more than one entry in EEPROM). And after many months in reverse, I'm sad to say that I was not able to find the entry of the Fugue File System.


My theory is that the FAT-like information which resides in EEPROM is generated for USB communication (and/or for internal Fugue's cache manipulation) in RAM (?), and is saved when you power-off your calculator.

The storage (EEPROM) seems to be managed differently, and this would explain: 1) why each time you use the write() primitive, many sectors move ; 2) why the start of the Fugue area seems to contain the same obscure data pattern and 3) why the entry seems to "move" and there is no fixed FAT entry.

Moreover, I have recently searched for a vulnerability on the fxcp400 (I have found one, at least, but not tested yet) to allow me to take control of the device which seems to contains A LOT of information (like Fugue's primitives that don't seem to exist on fxcg50, a list of all the developers' names and status, SD Card driver information, extra debug menus, and more). And I have found (I thinks) a primitive which seems to initialize the internal Fugue information by scanning the EEPROM, but due to missing dumps (like RAM/RS/ILRAM/...) I was not able to reverse this part without having the complet control of the device.

I have attached my tracer (addin and source) and my tool (addin and source) which scans the EEROM in this post, maybe my work can help you (this is not the best code I wrote, so, if you want more information about code or Fugue information, ask me).


EDIT: I don't know how to attach files....so :

* tracer (addin + information) : https://www.planet-casio.com/Fr/forums/topic16575-3-fx-cg50-manager-plus-gdbserver-debuggez-vos-add-ins-et-casiowin.html#192148
* tracer (source) : https://gitea.planet-casio.com/Yatis/gintrace
* fsctl (source) : https://gitea.planet-casio.com/Yatis/fsctl
* fsctl (Fugue related stuff) : https://gitea.planet-casio.com/Yatis/fsctl/src/branch/master/include/fsctl/fugue/bits
* fsctl (Fugue related stuff) : https://gitea.planet-casio.com/Yatis/fsctl/src/branch/master/src/fugue

Thanks, I hope this will help us.

I also wonder why the search didn't bring me to the French forum. Peut-être j'aurai du chercher en français.

Hi, I am leaving the source code of the tool which we made and which fits our needs - it looks for a remapping table of FUGUE FAT in the NAND fulldump and rebuilds from said full dump a useable FAT16 image, which can further be extracted by any tool which can dump files from FAT16 images.

https://gitlab.com/usernameak/fugue-dumper

Hi,

I'm happy to see people working on this part of the device.

I've tried to build your project using `dub`, but I cannot run the tool because I get a SIGSEGV each time, and I’m not able to determine the root of the problem since I'm not comfortable with D language.

How did you find the information to “rebuilds from said full dump a useable FAT16 image”? I see that you seem to check basic FAT information and then a string “Fugue FAT File System (NAND)” which is not present in French OSes (possibly why the crash occurs), but after that I don't understand what you are trying to do...

Thank you for sharing source code, this is the first time I see D code for tooling!

I also get an error:


Code:

I am the author of the tool. It's actually meant to work with the NAND flavor of the Fugue FAT filesystem (as used in the Japanese-market Sony Ericsson mobile phones; their FS had signature `Fugue FAT File System(NAND) 2004-04-27`), so it will not work with NOR memory dumps (or possibly even other builds of the NAND version of the FS) as-is.

What it actually does is it scans the filesystem for the block relocation tables (a Fugue-specific thing that is most likely somewhat different on NOR memory) and tries to relocate the blocks into a conventional LBA block order. Your error actually means that it can't find any relocation tables (I think they might have a different header in your devices).


You can send the flash contents and I can try to add support for them too, though; note that the `Fugue FAT File System` header is not the beginning of the FS on the flash chip (it's actually up to a few hundred blocks away), so a dump of the whole flash is preferrable.