Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
andva:
Cool find! However, I'm _much_ more intrigued by fact #2....
To recap. Connecting in MSC mode, you find a file in the root directory (MTABLE.SYS) which contains the song database. In that file, you can see the following:
- the "drive letters" are "mmc:0" for the internal memory and (I think) "mmc:1" for the microSD card
- the format is (roughly) path, filename, album, artist, songname, genre and something else. The stock music is readily "seen" by the driver as being within the ##MUSIC# subdirectory. For instance:
mmc:0:\##MUSIC#\Music\Alias & Ehren\Lillian\
whereas the music copied over by using MSC are within (say) mmc:0:\MUSIC\whatever.
Besides, if you run "strings" on a firmware file, you'll see many references to ##MUSIC# and ##PORT#.
Since bclick found that these subdirectories were readily accessible, I suspected that they should be on the FAT somewhere, since that's the only place where the directory name is stored. (If it was, say, hardcoded to some sector, the directory contents could be found, but not the name). I tried making a directory called ##MUSIC# and seeing whether I could access the music. No dice. The directory was empty, and when I disconnected and reconnected, it had disappeared.
I then inspected the FAT in the device, and I have found the trick that the Sansa uses to hide the directories. They are regular files, but they have an attribute byte of 0x18. These two bits mean "directory" (0x10) and "volume label" (0x08). Since volume labels are ignored, no regular FAT driver is able to see the directory. But they are regular directories; you can go to the corresponding cluster and see the directory contents just fine.
I'm now using lde (Linux Disk Editor) to peruse the contents of the drive and I'm making some advances, although the ##MUSIC# directory is giving me problems (maybe there's another layer of protection so that the stock music can't be copied). But I can go to the PORT directory just fine. I'll keep you posted on that one.
EDIT - It is rather trivial to access the directories - just use an hex editor and change the 0x18 byte to 0x10, then remount the partition. I have successfully made a copy of ##MUSIC# and ##PORT# that way. (I rechanged the attributes byte to 0x18 before unplugging, so I don't know whether the Sansa would have reverted the change or not).
##PORT# does not look very promising, though (##MUSIC#, as could be expected, contains the stock music). It contains a few images, the icon for the device, and "Object.dat" (mine is like 80Mb long, though). But I'd say "object.dat" is some kind of image of the device status (it seems to contain all the stock music, plus one recording I made as a test). I found no firmware references in the file.
I have also found that the ##MUSIC# directory I manually created was stored in the FAT, and that the Sansa had indeed changed its attributes to 0x18 (so there were actually two ##MUSIC# directories). Interestingly, the directory did contain an empty "skeleton" with the same subdirectories (and even files) making up the structure of the regular ##MUSIC# directory. Part of me wants to try what would happen when creating a ##PORT# directory, but my intuition is that it might not be a great idea ;)
bclick:
Nice work, m8, thanks for picking up on that and making the effort...
Hopefully this pace of discoveries will continue!
andva:
OK, so I'm now trying to get more firmware images by tinkering with the Sansa Updater. I have been using a packet sniffer (Wireshark) to get info about the update process. To be honest, I did not come up with that idea myself, I have seen it previously somewhere (I can't remember the exact place, maybe in the abi forums).
My findings so far:
The update procedure is initiated by the Sansa Updater program by requesting the following URL:
http://sansa.directory.flashcp.com/cocoon/bls/directory/get-project-details?dummy=dummy&project-id=SANSA
The Sansa Updater sets the User-Agent string to "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SansaUpdater)", but the server does not seem to mind. The above URL opens just fine under Firefox.
The result is a lengthy string which contains a few url-encoded parameters. Once unmangled, the information returned is:
status=ok
application-home-prefix=https://fe.gummo.flashcp.com/cocoon/bls/updates/SANSA/fe
project-server-prefix=https://fe.gummo.flashcp.com/cocoon/bls/updates/SANSA/fe
time-server-prefix=http://time.gummo.flashcp.com/cocoon/bls/time
project-server-keys=
time-server-keys=
There is another string (project) which seems to contain the same information, URL-encoded a second time.
It is not possible to access those URLs directly, they yield a Forbidden error. I'm now looking at the strings on "sansaupdater.exe" and trying to make some sense out of them; the updates info is probably obtained by adding several suffixes to the "project-server-prefix", including USB IDs and model numbers (and, maybe, some kind of device serial). If anybody wants to join the fun, be advised that the file is UPX-compressed.
@bclick: Thanks! You were the one starting it all :)
andva:
--- Quote from: hth on January 17, 2008, 02:03:19 PM ---I then tried to find that 90MB message within the firmware, but didn't find it, yet.
--- End quote ---
Was the exact message "Not enough space for Music DB. Please free 90MB", maybe? It is on the firmware, and it is repeated in quite a few places (it seems to be the same in all locales).
The message, along with a bunch others, are UTF-16 encoded, little-endian. You can get a list of all those messages with "strings -e l e200pa.bin", or an adequate variation (Linux guy here).
I would say that everything that is meant to be shown on the player screen is UTF16 encoded.
I'm going over the non-UTF16 encoded strings. Some of them are rather interesting (for instance, something is supposed to trigger when you place a file called "ERASEME.CMD" in the flash root... and I bet that the earphones testing plays a file called "diagnosis.mp3" also located there). They are trivial to get by using "strings", but I can post the results somewhere if you want.
By the way. I was wrong when assuming that the recovery mode could be triggered by doing something before the "System shutdown" message which appears when you try to power up the device with HOLD engaged. These messages can be found on the firmware (non-UTF16 encoded) and, therefore, if they can be seen on the screen, it's already too late.
I suppose a lot of people have tried button combinations, but, just to confirm, did anybody try them while spinning the wheel? Each "click" counts like a button press.
Something very intriguing: There is a non-UTF16 encoded string which reads "Erase Firmware? Press center button to confirm". On the firmware file. If we can somehow get to the point where the firmware can be erased from within itself, I would suppose that the player would boot on the recovery mode. (Or be borked for all eternity :))
PS: I would also be in favor of contributing towards buying one or more Rockbox "senior" developers an v2 player, but I fully understand that they may not have the time, energy or inclination to assume the huge burden of porting Rockbox to the v2's.
DemonicAHole:
--- Quote from: andva on January 28, 2008, 11:01:40 AM ---
I suppose a lot of people have tried button combinations, but, just to confirm, did anybody try them while spinning the wheel? Each "click" counts like a button press.
--- End quote ---
i tried to do that but to no luck, just does the usual "hold is on..system shutdown"
-p.s. i did it with hold on and then off, wheel goin both directions
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version