3

I've been messing around with traffic interception over USB (using Wireshark) when I noticed that one MP3 player was sending some odd packets in response to read request on the first block of the mass storage.

Around 4Kb in size, with SCSI payload containing repeating strings like:

X MSDOS 5.0
NO NAME    FAT32   
BOOTMGR    
Remove disks or other media.
Disk error
Press any key to restart

Or what seem to be entire char sets, they seem to go beyond ASCII range so I'm not sure, but they definitely contain all of the printable ASCII chars.

The kicker is that I'm running Fedora, and no other devices are connected at the time.

The device doesn't seem to register properly with the bus either. Throwing errors like:

device descriptor read/64, error -110

And although it does get mounted, it disconnects intermittently, even lsblk has trouble enumerating it, although when it does it does describe it as using FAT32, which I think is a reasonable assumption.

The device, manufactured/designed by Rockchip, does have a backup of firmware stored on the only accessible partition, but it is using image format I am not familiar with. Can't mount it, and it doesn't seem like an archive either, there are "tools" floating around, but I'm not eager to touch them.

Configuration files have comments in Chinese, and there is surprising amount of logs present on the device, concerning factory testing it seems. But none of this is really helping me figure out what do those packets mean.

Is it possible for MS-DOS to be present on an early 2010s MP3 player? That doesn't seem likely. But the BOOTMGR message points in MS direction, and I struggle to see where else could it be coming from.

Or is it just a descriptor of the filesystem that goes a bit too far? Could be, I don't really have a point of reference.

Summary of the example packet:

1957    16:16:26.979364 1.22.1  host    USBMS   4160    SCSI: Data In LUN: 0x00 (Read(10) Response Data) 
user293815
  • 33
  • 3
  • 1
    MS DOS as a thing is probably not present, but if it has been formatted for a PC there is a slim chance that it has an MBR partition table and a Windows boot sector. for example https://thestarman.pcministry.com/asm/mbr/W7VBR.htm says that a Windows Vista/7 boot sector would contain the strings mentioned in your payload. – Mokubai Dec 22 '21 at 20:57
  • MSDOS 5.0 dates (I think) from 2011, so a 2013 device could well be based on it. I would even hazard the guess that the player uses [Mpxplay](https://en.wikipedia.org/wiki/Mpxplay). – harrymc Dec 22 '21 at 21:14
  • @harrymc I think the 5.0 was released in the early nineties? I mean, the support ended in the year 2000, I don't think there were any releases after that. – user293815 Dec 22 '21 at 21:17
  • @harrymc I'm pretty sure [MS DOS 6.22](https://en.wikipedia.org/wiki/MS-DOS) predates Windows 95. You could be thinking of [Windows version numbers](https://docs.microsoft.com/en-us/windows/win32/sysinfo/operating-system-version) of which Windows 2000 was "5.0". Around 2010 would be 7/8 at version 6.1/6.2 – Mokubai Dec 22 '21 at 21:21
  • Yes, you're right. The final release was 8.0 on Windows Me from September, year 2000. So it's pretty strange to find it on a 2013 device. I start doubting that this is indeed the version that formatted that disk. Or perhaps the device is much older than 2013. – harrymc Dec 22 '21 at 21:22
  • @harrymc the answer from user1686 [has a link](http://jdebp.info/FGA/volume-boot-block-oem-name-field.html) which provides a lot of interesting backstory into why we have such useless numbers held in those fields. Chances are it's just a hacky cludge version number to make things "work". – Mokubai Dec 22 '21 at 21:24
  • @harrymc More I think about it, the more the answer from user1686 seems plausible. After all, it wouldn't be the only such case when older system has far reaching impacts decades after it's out of use (column limits for example). – user293815 Dec 22 '21 at 21:27
  • Perhaps, but make things "work" as they did about 15 years before the device was fabricated seems somewhat extreme. – harrymc Dec 22 '21 at 21:28

1 Answers1

3

That's just a very typical VBR (Volume Boot Record), i.e. sector 0, of a FAT-formatted partition. Specifically, it's the VBR that all recent Windows Vista/7/8/10 systems would write when formatting a partition as FAT (hence the reference to BOOTMGR) – chances are you'll find the same contents on many of your USB sticks. In fact, I wrote this answer mostly using a freshly formatted USB stick as reference.

Technically the whole VBR would be treated by BIOS as executable code, just like the disk-level boot code in MBR, but on FAT volumes it also includes a varying amount of metadata fields (preceded by a jump instruction to make the CPU skip right over it).

Here MSDOS5.0 at 0x003 is the "OEM Name" field which roughly indicates what OS formatted the volume. (Most likely it refers to MS-DOS in much the same way that web browser user-agents refer to Mozilla/5.0.) NO NAME is apparently a copy of the volume label (stored at 0x047 in the Extended Boot Parameter Block).

Finally, BOOTMGR is actually part of the executable boot code – the standard FAT32 VBR written by Windows will search for a file named 'BOOTMGR' that holds the rest of the bootloader (previously this was NTLDR in the Win2000/XP era). If that file is not found, the boot code will print the message that follows ("Remove disks" etc).

In conclusion, you're really just looking at the result of an SCSI "read" command, and you would see the same data if you inspected the MP3 player's storage at "block device" level (e.g. by reading from /dev/sdb1 on Linux). Keep in mind that the VBR is sector 0 of the first partition, so it's probably LBA 2048 at SCSI level.

And note that the player itself doesn't care about the contents of this sector as far as its boot process goes – this is a data volume, not a boot volume, so the mention of "MSDOS" doesn't imply in any way that the player would be running MS-DOS, in the same way that it doesn't cause your PC to suddenly boot MS-DOS.

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • 1
    Interesting, in other words, it's just a boilerplate shared in common with other FAT32 partitions. Basically an artifact of the spec defining it. – user293815 Dec 22 '21 at 21:24
  • 1
    @user293815 I'd agree with that summary and user1686s answer, that payload is just a "standard" block written at the start of a disk, potentially with filler (the character set) to pad it out. The unreliability of the disk itself is probably unrelated to the contents and may well be a sign of age, cold solder joints, or just general failure of the device. – Mokubai Dec 22 '21 at 21:29