Hello All,
I need to write a flag, representing some status variable(s), to master boot record upon shutdown (or sometimes while the system is running). My question is which part of the MBR is safe to store 1 or 2 bits (or more conveniently 1 or 2 bytes).
I have already investigated a couple of options:
* There are two bytes after disk signature. These seem to be always zero, though according to Wikipedia (http://en.wikipedia.org/wiki/Master_boot_record) 0x5A5A means copy-protected.
* There are 2 bytes close to the end of bootstrap code area (bytes 0x1B3 and 0x1B4) which seem to be zero, but I have noticed that Windows (or other programs) sometimes write to these two bytes.
* I could write over bootstrap code messages (for example bytes 0x1B0 and 0x1B1)
If writing to MBR is not the best solution, what other options do I have?
Thanks a lot,
Hossein
Why can’t you write it into a file?
It is a disk level filter driver, and I do not have access to file system all the time (at least on shutdown).
There are no standards for what you want to do, and no way to guarantee that what you do will work on every system, everywhere, all the time.
First of all, I hope you understand that booting disks for the MBR (and the legacy PC BIOS) is rapidly “going out of style.” Most new systems boot using UEFI and GPT-formatted disks.
Second, the MBR itself is probably not safe to use. None of it. Your best bet will be to try to find an unused sector between the MBR and the start of the first partition. But even this is subject to major problems. Suppose another non-standard utility (like yours) decides to use this same “unused” sector? Oooops.
Peter
OSR
@OSRDrivers
You can carve out your own sectors on the disk if you are willing to hide
those sectors from everyone above you. That means you have to get at the
disk before somebody else has claimed all the sectors on the disk for
“partitions” or “volumes” of one sort or another, and you have to support
both legacy disks and GPT disks. All very fragile unless you own the
platform.
Mark Roddy
On Thu, Oct 23, 2014 at 5:30 PM, wrote:
>
>
> There are no standards for what you want to do, and no way to guarantee
> that what you do will work on every system, everywhere, all the time.
>
> First of all, I hope you understand that booting disks for the MBR (and
> the legacy PC BIOS) is rapidly “going out of style.” Most new systems boot
> using UEFI and GPT-formatted disks.
>
> Second, the MBR itself is probably not safe to use. None of it. Your
> best bet will be to try to find an unused sector between the MBR and the
> start of the first partition. But even this is subject to major problems.
> Suppose another non-standard utility (like yours) decides to use this same
> “unused” sector? Oooops.
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
Thanks Mark, but I am not sure if this can be done in an Upper-level Disk Filter driver; at least I do not know how.
What I could possibly do, as suggested by Peter, is to write to a sector after MBR (it seems that there are plenty of free sectors after the MBR and before the start of the first partition, and nobody uses them), and then prevent/modify writings to that sector. Using this solution we should be pretty much fine with GPT as well, right?
[quote]
What I could possibly do, as suggested by Peter, is to write to a sector after
MBR (it seems that there are plenty of free sectors after the MBR and before the
start of the first partition
[quote]
Just DO NOT, under any circumstances, use sector 13!!
I used that one in a project a few years ago.
Peter
OSR
@OSRDrivers
(Yes, that was a joke.)
>(or sometimes while the system is running). My question is which part of the MBR is safe to store 1
or 2 bits (or more conveniently 1 or 2 bytes).
No part of MBR, and no part of boot block at sector 0.
Also, no free space, which can be TRIMmed on SSDs and Storage Spaces.
So, use a file for this.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
> Just DO NOT, under any circumstances, use sector 13!!
Same is true on sector 42, which is the Ultimate Answer To The Question of Being and thus can be used by some other people 
I used that one in a project a few years ago.
Was it inspired by “int 13h”?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
On 24 Oct 2014 02:39, wrote:
>
> It is a disk level filter driver, and I do not have access to file system
all the time (at least on shutdown).
This should work. It is meant for such situations only.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff549541(v=vs.85).aspx
It not only was inspired by “int 13h”, it made extensive use of “int 13h”… including hooking that interrupt.
I don’t think so. If a sector is not allocated by the file system (and is, in fact, not part of the file system’s logical block address space at all) then the sector can’t be deallocated by the file system. That means it won’t be “trimmed”… So, the SSD sees the write, the block is “in use” in the SSD… and there’s nobody who owns it who can deallocate and “trim” it.
Isn’t that right?
Peter
OSR
@OSRDrivers
>system’s logical block address space at all) then the sector can’t be deallocated by the file system.
What if there is a tool which can scan the FS and send TRIMs to its free space?
Are you really sure there is no such tools?
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Well, of course not. I’m not “sure” of very much when it comes to software… after all, changing anything that’s in software is only a matter of time and money.
But:
a) In such a silly scheme as that proposed by the OP, this is really the least of his worries.
b) A tool to trim free space? Remember, these sectors are IN the File System’s free space pool. In an SSD, they wouldn’t (ordinarily) be “in use” at all. Such a tool would have to find all the sectors that are OUTSIDE of a file system, and NOT used for metadata, on the volume and trim them. And how would this tool know precisely what comprises metadata? For example, exactly how many sectors after the VBR have “real” data in them? Is it 8, or is it 13? And how much space is reserved before the first partition and after the MBR? This depends on the OS version used to initialize the disk. Such a tool would be even more risky and dangerous than the solution being proposed by the OP… Given that I can have partitions on a volume that a given OS doesn’t understand (which could even be raw disk areas that might be used for something arbitrary) I can’t imagine such a tool being something other than a niche diagnostic item.
I’m not arguing that taking some arbitrary sector and using it is a great idea. I’m just saying, that if the OP *really* thinks he wants to do this, it’s “been done” this way for decades.
OP: To Mr. Shatskih’s point… How about allocating a file, locking it, finding its physical location, and writing to it during shutdown? I’ve done THAT too…
Peter
OSR
@OSRDrivers
@Amritanshu:
I have already tried writing to a file. The problem is that the handle to the file is not valid when I get IRP_MJ_SHUTDOWN, and even if it was, I cannot write to a file upon shutdown for some other technical reasons.
An alternative solution could be if I obtain offset of the file, and write to that sector upon shutdown. I can create the file, and read from/write to it; but I am not sure if I can find the file offset from within a disk-level filter driver, can I?
And of course this would be much more work than simply writing to a sector.
Thanks all,
Hossein
>Such a tool would have to find all the sectors that are OUTSIDE of a file system, and NOT used for metadata, on the volume and trim them.
That’s what “cipher /w” does (it overwrites the data, not trims it). Trim may only work on granularity larger than an allocation unit.
> OP: To Mr. Shatskih’s point… How about allocating a file, locking it, finding its physical location, and
writing to it during shutdown? I’ve done THAT too…
Me too, me too
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
Yup, you can.
Doing something correctly, with the proper level of engineering rigor, is almost always more work initially than doing something a shitty way.
OTOH, doing something a shitty way will cost you more time/effort in the end.
Peter
OSR
@OSRDrivers
>find the file offset <
The risk here is surely that the OS may move the file between finding its
sectors and writing it by bypassing the file system. I do this on embedded
systems where I am in control of the file system, but can you stop Windows
moving the file?
Mike.
----- Original Message -----
From: xxxxx@osr.com
To: Windows System Software Devs Interest List
Sent: Friday, October 24, 2014 6:03 PM
Subject: RE:[ntdev] Need to Wirte a Flag on MBR
Yup, you can.
Doing something correctly, with the proper level of engineering rigor, is
almost always more work initially than doing something a shitty way.
OTOH, doing something a shitty way will cost you more time/effort in the
end.
Peter
OSR
@OSRDrivers
NTDEV is sponsored by OSR
Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Yes, you can… as long as you have the handle open.
Send an FSCTL_MARK_HANDLE with MARK_HANDLE_PROTECT_CLUSTERS.
Peter
OSR
@OSRDrivers
Then you would be filtering at the wrong level to claim parts of the disk
as your own. So if you want to continue to claim parts of the disk and not
parts of a volume on the disk, and if you have been convinced of the
foolishness of trying to reuse the mbr region, you might consider filtering
at a level that would allow you to effectively hide sectors on a disk.
Mark Roddy
On Thu, Oct 23, 2014 at 6:49 PM, wrote:
>
>
> Thanks Mark, but I am not sure if this can be done in an Upper-level Disk
> Filter driver; at least I do not know how.
>
> What I could possibly do, as suggested by Peter, is to write to a sector
> after MBR (it seems that there are plenty of free sectors after the MBR and
> before the start of the first partition, and nobody uses them), and then
> prevent/modify writings to that sector. Using this solution we should be
> pretty much fine with GPT as well, right?
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>