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.