See also <a href="https://encrypted.google.com/search?q=DRM+writes+to+boot+sector" rel="nofollow">https://encrypted.google.com/search?q=DRM+writes+to+boot+sec...</a><p>This is a pretty nasty thing that's largely coming to light <i>just now</i> because GRUB2 uses a significantly larger portion of the space between the MBR and first partition ("embedding area," 24KB vs 10KB).<p>What we have is separate applications (GRUB2 and whatever Windows application) trying to use off-spec storage (the "embedding area") at the same time. Seems to be a bad idea on everyone's part, not just the GRUB or rogue Windows app developers.<p>The "embedding area" is not guaranteed to exist, be a certain size, or be unused: <a href="https://encrypted.google.com/search?q=embedding+area+is+unusually+small" rel="nofollow">https://encrypted.google.com/search?q=embedding+area+is+unus...</a>
Sounds like it's time to write a Windows driver that redirects all writes like this to a regular file. That way, apps keep working transparently, and their clever DRM scheme fails miserably.<p>Oh proprietary software vendors. Won't you ever learn that you can't stop "unauthorized use" on general-purpose hardware?
So. This is one software writing into a reserved area of a drive and then complaining about another piece of software that does the same.<p>Granted. One is for booting an operating system, the other for DRM purposes. But both are doing stuff they should not, so IMHO there's not much reason for complaints.<p>edit: I notice that I'm getting downvoted. Care to explain why? That embedding area isn't something you are supposed to write data to.<p>Now, some software out there still does it (grub2, truecrypt and various DRM solutions unser windows), but that doesn't give the maker of one software the right to blame the maker of another piece of software for writing there.<p>Both should find a better solution, but this certainly isn't a bug in either software - both work around the specification and are getting bitten.
This might not be entirely Microsoft's problem.<p>I faced similar issues with Dell's backup/restore software for windows 7, which I multiboot with Ubuntu.Still others had this issue with HP backup and recovery manager<p>The relevant bug is here - <a href="https://bugs.launchpad.net/debian/+source/grub2/+bug/441941" rel="nofollow">https://bugs.launchpad.net/debian/+source/grub2/+bug/441941</a><p>What is interesting is that Grub apparently doesnt have a problem, but Grub2 does.<p>I got rid of it simply by uninstalling any bundled software (Dell, HP, Sony, Lenovo) BEFORE installing Linux.
Intuit took some heat for this back around 2001~3, thereabouts. One article on the subject can be found here:<p><a href="http://www.geek.com/articles/news/turbotax-installer-destroys-non-windows-partitions-20030214/" rel="nofollow">http://www.geek.com/articles/news/turbotax-installer-destroy...</a><p>I'm kind of surprised there's software still doing this, and shouldn't Windows and its new and improved security have put an end to these kinds of shenanigans on its side?
The web server is overrun, and the article accordingly inaccessible.<p>I implemented a system for an OS bootstrap that uses a scheme similar to this, though I deliberately placed the boot partitions "underneath" (carefully double-mapped) files within the file system that were expressly created for the purpose of "protecting" the boot-level structures from the OS and its disk activities.<p>The files were located over specific ranges of disk blocks that were known to the console; so long as that mapping was maintained, everybody was happy.<p>That change would require changes to a few OS-level tools; to (for instance) a Linux partition or Windows. (I had that option.)<p>The other approach is to place the boot structures in a boot partition; to use one of the four slots available in MBR for a partition for the boot tools.<p>The consoles I was working with support EFI (and which has its areas of brain damage) and console makes allocating a GRUB2 boot partition trivial. That keeps the console and its tools from stomping on the partitions, and the applications from stomping the boot loader.<p>If you're stuck back in BIOS-land with MBR (and no easy way to launch into EFI), there's likely no good solution to these collisions other than grabbing an MBR slot, as there's almost certainly no general Windows coordination policy here other than "don't do that".<p>Microsoft Windows itself has occasionally and classically stomped on foreign-format disks; it had the galactic stupid of writing a "harmless" signature to disks it didn't find MBR structures on. If the console pilot allowed Windows to write that "harmless" signature and your foreign file system was corrupted.
Agree. Right solution would be something akin to BootMagic,
which stores the code in a separate small partition.
Or, as a half-measure the can use code compression (LZ77 or similar).