I wrote a disk utility that allowed you to erase whole physical drives. it uses the windows file api, calling :
destFile = CreateFile("\\\\.\\PhysicalDrive1",
GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL, OPEN_EXISTING,createflags, NULL);
and then just calling WriteFile, and making sure you write in multiples of sectors, i.e. 512 bytes.
this worked fine in the past, on XP, and even on the Win7 RC, all you have to do is make sure you are running it as an administrator.
but now I have retail Win7 professional, it doesn't work anymore! the drives still open fine for writing, but calling WriteFile on the successfully opened Drive now fails!
does anyone know why this might be? could it have something to do with opening it with shared flags? this is always what I have done before, and its worked. could it be that something is now sharing the drive? blocking the writes? is there some way to properly "unmount" a drive, or at least the partitions on it so that I would have exclusive access to it?
some other tools that used to work don't any more either, but some do, like the WD Diagnostic's erase functionality. and after it has erased the drive, my tool then works on it too! leading me to believe there is some "unmount" process I need to be doing to the drive first, to free up permission to write to it.
Any ideas?
Update:
the error code returned from WriteFile is '5', ERROR_ACCESS_DENIED
but again, if I 'erase' the drive first using WD Diag, I can then access and write to the drive fine. when I initialize the drive again, and give it a partition, I go back to getting the ERROR_ACCESS_DENIED error.
This is almost certainly related to preventing the attack found against driver signing by changing sectors in the page file. It will prevent writing to the areas of the disk containing partitions.
See http://msdn.microsoft.com/en-us/library/aa365747%28VS.85%29.aspx and look at the information starting with the text "If you write directly to a volume that has a mounted file system", basically you have to lock the disk's volumes in order to write to their sectors.
Related
There is a program (program A), that uses some specific file in some folder. Normally that file is on the hard disk.
I need to write a program (program B) that can create such file, but this file should be physically in RAM, not on HDD. So if you unplug HDD, you could not find the file.
I also have no access to program A code. But I want A to interpreting that file as a normal file.
Is it possible in Windows to do something like that?
The only way to have a file that is only in memory is to use a RAM-drive. You can find free RAM-drives and probably some open source implementations but they do require a kernel driver. NTFS mount points will allow you to mount this drive as a subfolder on drive C: if that is a requirement.
From a programming point of view, the only thing program B would be able to do is to set the delete-on-close flag after program A has opened the file. Depending on how A uses the file, you might be able to just delete the file, and if not, B would have to call SetFileInformationByHandle(FileDispositionInfo, ...) on the file handle but this will only work if program A opens the file with the share flags set to allow delete. I have never tested this so I'm not 100% sure it would work if power was lost. NTFS does have journaling that makes sure the filesystem state is correct but I'm not sure if it applies to the delete flag.
I have come across something strange. I'm writing via WriteFile to a file opened on a UNC path to a NAS device. If it runs out of space with a short write, I free up space by deleting other files, then continue writing but it is failing with windows error 6 ERROR_INVALID_HANDLE. If I do the same thing using local drives (hard drives or USB Flash Drives) it works fine.
Does anyone know why the handle becomes invalid?
Is there a type of reset of the handle that is needed in some cases after an error?
TIA!!
Are there any libraries or Windows API functions that enable writing to the sectors of a CD-R directly? I am able to read sectors from the drive using the ReadFile function provided by the Windows API but using the WriteFile function on the drive seems only to mark the disk as in-use (after executing a program in which WriteFile is used on a CD-R, I am unable to burn files onto the disk or eject it until I restart the system). When I restart the system, there is no data on the disk. Opening the disk drive for write access and calling the WriteFile function with the disk drive handle produces no system errors.
I don't know easy way, but there is a set of SCSI commands, that burning software use.
Under windows you has to get ASPI library to obtain SendASPI32Command Free one and find somewhere a description of Multi-Media Commands. Start from www.t10.org, they sell it, but working draft can be found for free.
and then start there and then look for example of MMC commands using in cdrecord sources.
It can be done but hard though.
Access to the write process is probably restricted to allow compatibility with the drag-and-drop writing that can be done in the Explorer.
You could use an alternative approach and write to an ISO image and then dump that to the CD when it is complete.
I want to move my program to USB memory stick. It will run only on memory stick and would not be copied (written on C# and has nearly 3GB of database).
Where can I find a good source for that and/or how can I do that?
What you described can't reasonably be done. If a user can run the program, they can run it. It doesn't matter whether they loaded it from your USB stick or not. You can write it such that it assumes it's being run from the USB stick (with relative paths, per #Kos's comment) but that will in no way prevent people from copying it to their hard drives and running it. Since you don't know where a USB stick will be mounted ahead of time, you can't even use absolute paths.
Allow me to disagree with nmichaels, it is possible to check in C# if your running from removable storage or hard drive.
Check this thread: How to detect if any specific drive is a hard drive?
However, it would be too easy to reverse the thing and allow it to run on hard drives.
As an additional protection, you can read the USB drive serial and if it doesn't match, kill the program.
OR... you if want to be hardcore, use a specific USB drive model, and read the VID/PID, or the chip itself (check mass production tool).
In the end, if the program worths it, someone would still reverse it and break the protection scheme :)
When I boot up Linux Mint from a Live CD, I am able to save files to the "File System". But where are these files being saved to? Can't be the disc, since it's a CDR. I don't think it's stored in the RAM, because it can only hold so much data and isn't really intended to be used as a "hard drive". The only other option is the hard drive... but it's certainly not saving to any partition on the hard drive I know about, since none of them are mounted. Then where are my files being saved to??
Believe it or not, it's a ramdisk :)
All live distros mount a temporary hard disk in RAM memory. The process is completely user-transparent and is all because of the magic of Linux kernel.
The OS, in fact, first allocates an area of your RAM memory into a virtual device, then mounts it as a regular hard drive in your file system.
Once you reboot, you lose all your data from that ramdrive.
Ramdrive is needed by almost all software running on Live CDs. In fact, almost all programs, in particular desktop managers, are designed in order to write files, even temporary, during their execution.
As an example, there are two ways to run KDE on a Live CD: either modify its code deeply in order to disallow you to change wallpaper etc. (the desktop settings are stored inside ~/.kde) or redeploy it onto a writable file system such as a ramdrive in order to avoid write fails on read-only file systems.
Obviously, you can mount your real HDD or any USB drive into your virtual file system and make all writes to them permanent, but by default no live distro mounts your drives into the root file system, instead they usually mount into specific subdirectories like /mnt, /media, /windows
Hope to have been of help.
It does indeed emulate a disk using RAM; from Wikipedia:
It is able to run without permanent
installation by placing the files that
typically would be stored on a hard
drive into RAM, typically in a RAM
disk, though this does cut down on the
RAM available to applications.
RAM. In Linux, and indeed most unix systems, any kind of device is seen as a file system.
For example, to get memory info on linux you use cat /proc/meminfo, where cat is used to read files. Then, there's all sorts of strange stuff like /dev/random (to read random crap) and /dev/null (to throw away crap). ;-)
To make it persistent - use a USB device - properly formatted and with a special name. See here:
https://help.ubuntu.com/community/LiveCD/Persistence