Extracting on-device FAT partitions

[stefand]

This isn't a bug per se, but this seems like the best place to send this information for it to be potentially found by others.

I tried to extract the FAT partition data from the dumps of my Philips E2106 phone. The attached extract-fat.c file is a very crude implementation:

1. Figure out the start of the data section. In my case it was at 0x00382000. I figured it out by guessing with a hex editor. I am sure there are some offsets stored in the mediatek headers.
2. Copy the data section to a separate file: dd if=dump.bin n of=input.bin bs=1 skip=3678208
3. Build and run the attached .c file - it has the input and output filenames hardcoded
4. Output.fat is now a disk image with an MBR partition table. One partition (in my case) starts at sector 1 (offset 512), the other at sector 71.

mount -o loop,offset=512 output.fat /mnt/
mount -o loop,offset=36352 output.fat /mnt/

5: The first partition is the one the phone exports when attached as a USB mass storage device. The second one is its "internal" data store.

The format is pretty simple. I think it is a crude wear-leveling algorithm:

The data section is divided into blocks of 4096 bytes. Each block contains a 32 byte header, 480 byte padding, followed by 7 sectors of 512 bytes. Yeah, that's plenty of padding.

The header has a uint32_t value that I didn't figure out, followed by two uint16_t (little endian) values giving the disk sector number and some flags field. Although the flags I saw are either 0 (which means the sector is unused), 0xffff (which means it has never been written, so treat it as unused) or 0c000 (which means it is in use). The structs at the start of the .c file should give some idea.

My original goal was to extract SMS from the phone's internal storage. I found my text messages in NVRAM/NVD_DATA/MPA3_001. Note that they are PDU encoded, so simply grepping for a known string won't find it. It is easier if you send yourself a unicode-encoded SMS (e.g. with a 😊 character) and then grep for UCS-2 strings.

The phone book seems to be in MP0C_003 (UCS-2 or maybe UTF16 names) and MP0H_006(ascii string numbers).

Now that I have figured out the interesting part and the the tedious work of writing a user-friendly tool remains I'll probably lose interest and move to other adventures. I hope that by dumping this information online my time wasn't entirely wasted.

extract-fat.c.txt

[ilyakurdyukov]

I have had a program for unscrambling an internal disk for a long time. I just haven't published it.

[stefand]

Publishing it would have saved me a weekend 😆 . Do you know any other magic bits?

Other stuff I've been looking for to make more than dumb phonecalls with this dumbphone:

• Throw various AT commands e.g. from nokiatool.sh at the phone. While some respond, Phone book commands seem completely missing. SMS send commands respond with the correct ">" at first, but I never got them to do anything else than reply CME Error: 100 after sending the message body. It is possible a magic setup command is needed first, like selecting a SIM card, but I couldn't find anything.
• The only vaguely useful thing disk access could do is extracting and writing phone book entries and sms. I wouldn't be able to actually send it, just queue it in the outbox. The phonebook is dreadfully limited (just a 20 char to number char mapping).
• What's the calendar good for? All it can do is arrange dates into weeks, it can't even store a reminder
• Bluetooth can maybe do hands free audio and file obex, nothing else
• I don't care about the usual thing that gets talked about online like changing IMEI, extracting passwords or running Doom.

The Spreadtrum MOCOR counterpart seems a lot more capable than MAUI. It has buggy, but workable bluetooth PBAP, MAP, can store actual calendar entries. I looked at its disk structure for about 5 minutes, but all I can say so far is that it doesn't look like it is a FAT derivative.

[ilyakurdyukov]

Here is my code: unscramble.c.txt

[SwiftScriptr]

Hi, (responding here as this is a general tool query too, also easier being in one place IMO, hope you don't mind) i noticed that both the libusb implementation of this tool for mediatek and the spreadtrum devices flashtool (on linux) are not suitable for 'smartphones'. Any reason why that is so, and how smart does the device need to be?

I have compiled the spreadtrum tool and note that the OG device string is different (i guess based on chipset in the compile files i read).

Another tool I found is this:
https://github.com/kagaimiq/sprdproto
This tool claims supports my device and even has the same device string in the files, i would like to know what the difference would be between them pls (does having a touchscreen equate to being a smartphone?).
Also, if i were able to understand how to use the tool as theres no listed commands, but i feel it's inspired /the same as your spreadtrum_flash tool.

Btw as @stefand stated, the readback functions are different between this tool and mtkclient

https://github.com/bkerler/mtkclient/issues/1414

So in theory, how can another phone (a generic/modern/actual smartphone) be read with your tool here if that mtk tool can't read a device for some reason?

What changes can be made considering this issue (the device in question):

https://github.com/bkerler/mtkclient/issues/1397.

Any hope/possibility in reading any partitions?

Since you responded after knowing your tools for half a year now, thought i'll reach out unlike the other maintained repo @bkerler, have had no response for a month now to any issues i've raised.

[stefand]

I don't have a mediatek (nor uniflash)-based smartphone so I can't say much about them. The boundary between smart and feature phones has been pretty fluent. A touchscreen or not doesn't matter.

For my purposes the difference is mostly if the phone runs a Linux-based OS(*) or a much simpler (and smaller) software. What matters for you is probably that anything powerful enough to run Linux also has a more thought out security architecture with signature verification, separating apps from each other. Most feature phones I dealt with just run whatever you send to them over the USB wire and once you have physical access to them security is pretty much nonexistent. (There are exceptions to this, e.g. I have a Unisoc phone (Nokia 106 2023) that needs signed FDLs).

(*): Or iOS or a form of Windows, but the former is limited to iPhones and the latter abandoned by Microsoft.