This content has been marked as final. Show 8 replies
give up, it's never going to work.
the MBR code contains the sector number of the start of a certain file, which will be different on every machine.
Is the sector start randomly chosen on each Safeboot installation or will it have the same location on identically imaged machines? Essentially we're determining whether or not we need to back up the MBR of each and every machine we deal out.
It depends, it's the location of a file, so if windows happens to store the file in the same place, it will be the same number. Unlikely though not impossible I guess.
Why would you want to back up the MBR though? what are you hoping to achieve by that? The only thing you'd need that for is if you are doing things that could change the MBR and those things don't have a proper unwind process of their own.
The company I work for is pretty large with various technology teams world-wide. IT and machine support, on the other hand, have a universal, one-size-fits-all mandate for imaging and securing laptops for developers, systems, and non-technology alike. As a result, many teams often run up against a wall when they request Linux machines--a wall they get around in a number of ways that often involve wiping out the encrypted Windows installation. We have no intentions of supporting dual boot systems or changing our (re-)imaging policy, but we would like to provide our developers and systems people with the flexibility to not only dual boot but also to recover in the event they lose their Safeboot MBR. One option, of course, is to backup every Safeboot MBR before delivery. This is problematic given the size of the company and the availability of people trustworthy enough to execute the task. The other, we theorize, is to maintain a single copy of the Safeboot MBR under the assumption that imaging process writes the fall to a predictable location. We would then make this file available to developers to use at their own risk. Not an ideal solution, of course, but something worth testing.
So to answer your question, we're trying to address the scenario where developers do not follow a proper unwind process--i.e., by backing up the Safeboot MBR. I'm specifically testing whether this process will work with any arbitrary installation of Windows XP Professional, regardless of disk characteristic, subsequently protected by Safeboot. Of course, if the answer is a definite no I can report that and call it a day. wink
The MBR is linked to the particular activation, so you're going to need one per machine per activation to sure to be safe. You can't rely on it being static either - EEPC might update it if needs be, and as I say, if you for any reason disable and re-enable the product you're going to need to grab a new MBR copy.
Even if they do mess up the MBR though, it's still recoverable with an Emergency boot (part of the diagnostic toolkit), so for all the effort to capture the MBR's you might as well simply use the built in recovery processes to repair the damange. After all, that's what it was designed for.
Why not load a VM inside their Windows install, if they want to play with Linux? VMWare Server is free and there are other virtualization products that should also work. This also protects the data on those partitions, as the VM drives/partitions would exist as files in the Windows filesystem (therefore also encrypted).
It removes the necessity for funny hacks, and more developer freedom in what they load or how. Since most developers don't seem to know much about the OS or filesystems, this would probably be the safest bet. This way they don't have to hack around with Linux dd commands to backup and restore MBR information.
I was doing something alike... but I found (as other people already said) that MBR (first 512 bytes) are different between two computers with same specs.
So I found also that difference is only in 0x14 - 0x16 bytes. But I don't know what they are... sad (probably could be an address where safeboot stores the following bootstrap code or just a key).
it results to a sector address for our private disk image. It will be unique per activation.