14 replies to this topic

[friske]

I use:
qemu.exe -vga cirrus -m 256 -localtime -M pc -usb -hda \\.\physicaldrive0
to emulate boot from hard disk.
When i modify a grub4dos menu.lst the change not have effect immediately.
I have to rerun
qemu.exe -vga cirrus -m 256 -localtime -M pc -usb -hda \\.\physicaldrive0
a number of times to obtain changes.
it is as if reload the old files.
Do it is possible to fix?

[cdob]

Flush the file system data to disk first: sync
http://technet.micro...s/bb897438.aspx

However: are you sure about physicaldrive0?
Isn't this asking for file system corruption?

[friske]

I emulate my primary partition to check my boot.ini

[Wonko the Sane]

I emulate my primary partition to check my boot.ini

NO.
Things should be called with their names.
What you are doing is directly mounting your ONLINE primary boot media in a foreign environment (QEMU) with read/write capabilities.
This in jargon is usually referred to as "asking for troubles" or "risking filesystem integrity" ....


Wonko

[friske]

no problem with my test

Edited by friske, 25 November 2012 - 12:02 PM.

[steve6375]

QEMU will not write to /physicaldevicex - it automatically uses read-only mode and all writes are lost - I have not found any way to force it to rd/wr mode.
It is better to use the -snapshot with QEMU when mapping to a physical device, then at least, writes will appear to work within a QEMU session (but no permanent change will be made). If you don't use snapshot then you can boot to FreeDOS under QEMU, edit a file and then look at it again immediately afterwards and the file will not be altered!
P.S. The 'Test using QEMU' button in RMPrepUSB uses snaphsot mode.

[Sha0]

no problem with my test

If you are only performing read-only operations inside QEmu, then you might be lucky. BUT, suppose your hosting Windows currently has the filesystem in an inconsistent state (such as might happen with FAT)... Then when NTLdr reads filesystem meta-data, it could read inconsistent data. This could result in NTLdr malfunctioning. If NTLDR malfunctions, it is possible that it could accidentally write to the disk.

Thus it is only safe for multiple computers to access the same single-system disk filesystem if and only if none of those systems has write access to that filesystem. This has happened to me, and I deeply regret it.

QEMU will not write to /physicaldevicex - it automatically uses read-only mode and all writes are lost - I have not found any way to force it to rd/wr mode.

Which versions are you talking about and where did you get them? Every QEmu for Windows I've ever had is read-write with .PhysicalDriveX ...

[steve6375]

I have tried most of them. Can you give me a step-by-step example of using QEMU with a physicaldrive mapped as a QEMU drive and persistently make changes?

[friske]

I do test only to boot.ini, i test syslinux and not write nothing in qemu.

[Wonko the Sane]

I have tried most of them. Can you give me a step-by-step example of using QEMU with a \physicaldrive mapped as a QEMU drive and persistently make changes?

First thing different versions/builds of Qemu may have this safety turned off or on.
Second thing, if you access a "filesystem object" (disk image) inside the \\.\physicaldrive and mount it there is no such protection.

More generally better be safe than sorry:

http://diddy.boot-la...les/testing.htm
http://wiki.qemu.org...d/qemu-doc.html
http://wiki.qemu.org...host_005fdrives

3.6.6.2 Windows
CD

The preferred syntax is the drive letter (e.g. ‘d:’). The alternate syntax ‘\\.\d:’ is supported. ‘/dev/cdrom’ is supported as an alias to the first CDROM drive.

Currently there is no specific code to handle removable media, so it is better to use the change or eject monitor commands to change or eject media.
Hard disks

Hard disks can be used with the syntax: ‘\\.\PhysicalDriveN’ where N is the drive number (0 is the first hard disk).

WARNING: unless you know what you do, it is better to only make READ-ONLY accesses to the hard disk otherwise you may corrupt your host data (use the ‘-snapshot’ command line so that the modifications are written in a temporary file).

You know, kids, matches, etc.... :
http://reboot.pro/to..._75#entry119581

And no, I am not going to trash a working \\PhysicalDrive to give you a PoC.


Wonko

[steve6375]

You can map a USB Flash drive as a physicaldrive and test using that - in my experience I have never managed to (for instance) permanently edit or rename a file on a USB drive booted under QEMU to DOS.

[Sha0]

I have tried most of them. Can you give me a step-by-step example of using QEMU with a physicaldrive mapped as a QEMU drive and persistently make changes?

Sure thing. Here is one example:

• Download QEmu 0.9.1 for Windows from this site's "QEMU on Windows" link (on the left).
• Scan the file for viruses.
• Extract the contents of the archive to a new directory.
• Open up a Windows CLI like cmd.exe
• Umount any volumes that you expect to write to from QEmu using the mountvol command.
• Run these two commands

  set devmgr_show_nonpresent_devices=1
  
  devmgmt.msc

• In Device Manager, choose View -> Show hidden devices
• Navigate to Storage volumes
• Uninstall the Generic volume corresponding to the volume you unmounted with the mountvol command, above. You can examine the volume's Properties, the Details tab, the Device Instance Id detail to get an idea if this generic volume is one you unmounted with mountvol.
• After uninstalling the generic volumes, minimize Device Manager.
• Change into the new QEmu 0.9.1 directory you made.
• Determine which physical drive you wish to use by using TinyHexer's File -> Disk -> Open drive... or by using WinObj and correlating DeviceHarddiskX entries to GLOBAL??PhysicalDriveY entries.
• Invoke QEmu with the physical disk you determine you wish to use:

  qemu -hda .PhysicalDriveX

• Never have the QEmu perform writes to a single-system disk filesystem that is mounted by the host.
• Never have the QEmu perform writes to a single-system disk filesystem that is mounted by the host.
• Never have the QEmu perform writes to a single-system disk filesystem that is mounted by the host.

I do test only to boot.ini, i test syslinux and not write nothing in qemu.

Maybe you'll be lucky. I hope so!

[steve6375]

Sure thing. Here is one example:

• Download QEmu 0.9.1 for Windows from this site's "QEMU on Windows" link (on the left).
• Scan the file for viruses.
• Extract the contents of the archive to a new directory.
• Open up a Windows CLI like cmd.exe
• Umount any volumes that you expect to write to from QEmu using the mountvol command.
• Run these two commands

  set devmgr_show_nonpresent_devices=1
  
  devmgmt.msc

• In Device Manager, choose View -> Show hidden devices
• Navigate to Storage volumes
• Uninstall the Generic volume corresponding to the volume you unmounted with the mountvol command, above. You can examine the volume's Properties, the Details tab, the Device Instance Id detail to get an idea if this generic volume is one you unmounted with mountvol.
• After uninstalling the generic volumes, minimize Device Manager.
• Change into the new QEmu 0.9.1 directory you made.
• Determine which physical drive you wish to use by using TinyHexer's File -> Disk -> Open drive... or by using WinObj and correlating DeviceHarddiskX entries to GLOBAL??PhysicalDriveY entries.
• Invoke QEmu with the physical disk you determine you wish to use:

  qemu -hda .PhysicalDriveX

• Never have the QEmu perform writes to a single-system disk filesystem that is mounted by the host.
• Never have the QEmu perform writes to a single-system disk filesystem that is mounted by the host.
• Never have the QEmu perform writes to a single-system disk filesystem that is mounted by the host.

I don't think that friske would be doing this! So for all 'normal' uses of QEMU, it won't write to a physicaldeviceX...
It might be really handy if there was a cmd script that could automate this though...

[Wonko the Sane]

I don't think that friske would be doing this!

Well, as a matter of fact what friske is doing requires NOT an access to a Physicaldrive at all, one can have a NTLDR+NTDETECT.COM+BOOT.INI on a floppy image and do the tests on the floppy image allright.

So for all 'normal' uses of QEMU, it won't write to a physicaldeviceX.....

Again, NO , there are situations in which this is possible, come on, WHY exactly would have the good AUTHOR of the nice tool have put a single WARNING: in the whole documentation, and this WARNING is recommending to use the -snapshot option (both for Linux and Windows OS)?

Psychological terrorism?

Please notice how the WARNING is worded exactly:

WARNING: unless you know what you do, it is better to only make READ-ONLY accesses to the hard disk otherwise you may corrupt your host data (use the ‘-snapshot’ command line so that the modifications are written in a temporary file).

This is something like:

Please, do not lean out of the window

http://www.msfn.org/board/topic/158485-international-translations-of-common-signs/
as an Englishman, you should comply with it....


Wonko

[Sha0]

I don't think that friske would be doing this! So for all 'normal' uses of QEMU, it won't write to a physicaldeviceX...
It might be really handy if there was a cmd script that could automate this though...

I'm afraid that you've misunderstood the purpose of my instructions. Their purpose is not to circumvent QEmu's automatic write-protection against using .PhysicalDriveX (there is no such protection that I'm aware of), their purpose is to demonstrate to you that there is no such protection. When you say that you have never been able to write to, let's suppose, a USB stick using its physical drive with QEmu, I believe that you've actually been mistaken. What you have is a race condition: Whoever writes filesystem meta-data last will "win," either QEmu or Windows. For example, you can try writing to it in QEmu, quitting QEmu, running sync in Windows without having made any changes to the USB from Windows, then ripping the stick out, then checking it in another computer. You might be surprised at the results. However, this goes against my instructions' steps 14 through 16.