PDA

View Full Version : Errors accessing a flash module (emulates an IDE hard drive)



nico.g
03-17-2005, 08:32 AM
I have a bootable Knoppix CD-ROM and I am able to boot from it.
My system has a "PQI IDE Secured DiskOnModule" installed in the primary IDE slot (hda).
This device is a flash module that emulates a 256Mb IDE hard drive.
The module contains turn-key NAS software.
When I boot Knoppix, I see many errors when trying to access the module:

hda: read_intr: status=0x51 { DriveReady SeekComplete Error }
hda: read_intr: error=0x04 { DriveStatusError }
hda: read_intr: status=0x51 { DriveReady SeekComplete Error }
hda: read_intr: error=0x04 { DriveStatusError }
hda: read_intr: status=0x51 { DriveReady SeekComplete Error }
hda: read_intr: error=0x04 { DriveStatusError }
[...]
ide0: reset: success

When I try and mount the filesystem, I get more errors:

% mount -t ext3 -r /dev/hda3 /mnt
hda: read_intr: status=0x51 { DriveReady SeekComplete Error }
hda: read_intr: error=0x04 { DriveStatusError }
hda: read_intr: status=0x51 { DriveReady SeekComplete Error }
hda: read_intr: error=0x04 { DriveStatusError }
end_request: I/O error, dev 03:03 (hda), sector 2
EXT3-fs: unable to read superblock

I know for sure the module has 3 ext3 filesystems on it: hda1, hda2, hda3. I *am* able to mount hda1 and hda2. Any advice as to how to resolve the problems with hda3 would be greatly appreciated.

Cheers,
Nico

masoet
03-17-2005, 01:04 PM
When accessing Flash or Thumb drives in Knoppix, normally all it takes is to type:

mount /dev/sda? (replace ? with the appropriate number, usually 1) and do not attempt to give it a mount point.

Knoppix usually assigns a mount point based on the device name (i.e. mount /dev/sda1 would get /mnt/sda1)

Try this and good luck.

Markus
03-17-2005, 02:10 PM
The errors look like being due to dma. Try the nodma cheatcode.

nico.g
03-17-2005, 02:18 PM
Thanks for the suggestion. I gave it a try and it didn't work.

I think the point is, that while this module is a flash memory device, it physically plugs into the IDE connector and looks to the BIOS like a regular IDE hard drive.

When Knoppix boots, it correctly identifies the device as an IDE hard drive (hda) with 3 partitions: hda1, hda2, hda3

I am able to mount the first two and inspect the contents:
# mount -t ext3 -o ro /dev/hda1 /mnt/hda1
# ls -la /mnt/hda1
[...]
# mount -t ext3 -o ro /dev/hda2 /mnt/hda2
# ls -la /mnt/hda2
[...]

No problems with those. It's just when I try to access /dev/hda3 that I'm seeing the I/O errors.

I have also requested information from the module maker but since their module is a proprietary product they are not keen to give me support on accessing the contents this way. Perhaps they have done something "special" to the filesystem on /hda3? Funny thing is, when I boot from the module (normal operation), I am able to confirm that /dev/hda3 on the module is mounted as an ext3 filesystem! Can't figure out why I can't mount it from Knoppix!

Markus
03-17-2005, 02:33 PM
Hmm, what does sudo fdisk -l /dev/hda say?

nico.g
03-18-2005, 01:26 PM
I tried "nodma" but the hda read_intr errors still occur.

nico.g
03-18-2005, 01:33 PM
# fdisk -l /dev/hda
Disk /dev/hda: 262 MB, 262144000 bytes
16 heads, 32 sectors/track, 1000 cylinders
Units = cylinders of 512 * 512 = 262144 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 61 15600 83 Linux
/dev/hda2 * 62 908 216832 83 Linux
/dev/hda3 909 984 19456 83 Linux


I found some more documentation about the IDE module. Apparently being a "secured" type, this means a section of it is indeed encrypted. This is very likely to be the hda3 partition, since I have no trouble mounting hda1 and hda2. This explains why I cannot mount it. I need to find out how to "open" or "unlock" the module before that partition is mountable.

Markus
03-18-2005, 09:39 PM
Well, the encryption certainly explains not being able to browse it. Looks like it has 3 zones and hda3 is the protected zone so you need to unlock it with a password: http://www.hdnet.co.jp/rise/DownLoad/DSheet/PQI/SDOM/SecuredDOM_Manual_1_3.pdf

nico.g
03-19-2005, 01:05 AM
Thanks Markus, I already found the same datasheet!

Yes, it is the same PQI module we are talking about.
The make of the NAS product has used the PQI SDOM as a way to protect as well as deliver their NAS software.
They have organized the module into 3 zones just as the datasheet suggests:
/dev/hda1 is the USER zone, (fully open & read/write, mountable)
/dev/hda2 is the ROM zone (read-only zone, can only be mounted ro, contains the linux boot & root partition)
/dev/hda3 is the PROTECTED zone (can't read or write, thus unmountable).

Now the real fun starts! Reverse engineering how to unlock it.

The thing is, when the machine boots from the module, it must call the PQI SDOM library function sdom_p_password() to unlock the PROTECTED zone somewhere in the boot sequence. The reason I am sure of this is that when I inspect /etc/fstab, there is a normal entry in there to mount /dev/hda3. This obviously succeeds, so this means that by the time the kernel has reached the point where the filesystems are mounted, the P zone has been unlocked. The keys and password must be somewhere in the ROM zone filesystem, because the system boots turnkey - there is no place where I am prompted to enter any password. Besides, the P zone is protecting the NAS software, not my personal data per se.

I spent a few hours running nm and strings on libraries and kernel modules etc. trying to find evidence where the call to the PQI library might be... in vain. Anyway I am more familiar with Solaris systems and my linux knowledge is light. I wonder where you would locate the code to call the unlock function? Would they have built a special linux kernel and placed it in there? Would they have placed it into a loadable kernel module? I wonder....

Markus
03-19-2005, 06:04 PM
Sorry, but I haven't a clue of where they might have inserted the passkey or call to the pqi file. I'd start looking at /etc/rc* directories for filenames like bootmisc.sh that knoppix uses for misc stuff at bootup, and /etc/modules* for a special kernel module.
As you possibly know, linux first boots the kernel read only to a initial ramdisk where it loads necessary drivers so that normal bootup can follow, although as the protected zone isn't root, it's hard to say if unlocking is done at the initial or normal bootup.