Author Topic: DiskCryptor - перезапись MBR загрузчика другими программами.  (Read 2713 times)

Rhard

  • Newbie
  • *
  • Posts: 2
Работая с различными загрузчиками ОС, было установлено, что некоторые программы пишут свою информацию в недокументированные области жёсткого диска (например Solid Works 2010). Поэтому если код загрузчика выходил за пределы MBR, то запуск таких программ автоматически портил загрузчик и система больше не грузилась. В интернет сообществе было много рассуждений по этому поводу. Так было у меня с GRUB2 вчастности.
Поэтому вопрос - как на это реагирует загрузчик DiskCryptor? Кто нибудь уже сталкивался с такой проблемой? Что скажет уважаемый автор? Можно смело ставить родной загрузчик, или виндовым загрузчиком передавать управление DiskCryptor? Во втором варианте, образ MBR должен оставаться на незашифрованном разделе, что плохо, если нужно шифровать все разделы без исключения.

Topic

  • Newbie
  • *
  • Posts: 3
I have translated this via google and I will attempt to answer in English. Hopefully someone else can answer in your own language.

Quote
Working with a variety of bootloader has been found that some programs write their information in an undocumented area of ​​the hard drive (eg Solid Works 2010). Therefore, if the bootloader code went beyond the MBR, then run these programs automatically ruined the boot and the system is no longer loaded. In the Internet community had many arguments about this. So I had to GRUB2 vchastnosti.
Therefore, the question - how do you respond to the loader DiskCryptor? Has anyone already encountered this problem? What will the respected author? It is safe to put the native loader or loader to transfer control of windows DiskCryptor? In the second variant, the image of MBR should remain on the plain section, which is bad if you want to encrypt all the partitions without exception.

Disclaimer: The following answer is based on my limited experience with the DiskCryptor program and source code, it may very well be wrong.

It is my understanding that every program that uses the appropriate API calls to access the raw disk device will not cause any problems, the disk cryptor driver takes care of this. However, if the program does its own raw disk access (which to the best of my knowledge is only possible if they write their own driver) then it could ruin your data. I don't think this is a likely scenario though, programs such as SolidWorks have no reason to do that. I'm interested in hearing the opinion of someone who is more familiar with the situation and the language in which the question was asked though.

Rhard

  • Newbie
  • *
  • Posts: 2
In my case, the GRUB2 loader had no driver in Windows 7 system, so Window 7 did't now about GRUB. But the programms like Solid Works are using raw disk acces without any information about this. Probably for the license saving.

Have a look hier

http://sourceforge.net/apps/mediawiki/bootinfoscript/index.php?title=Boot_Problems:Windows_Writes_To_MBR

http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-08-28-windows-applications-making-grub2-unbootable.html

If DiskCriptor driver takes care to close the acces to own loader, it is nice. But is it?

Sadeghi85

  • Newbie
  • *
  • Posts: 21
DC puts the first part of its loader into the MBR and the rest to the end of the disk, so a program like Solid Works that writes to the extended MBR won't affect DC's loader.
« Last Edit: May 09, 2011, 05:09:02 pm by Sadeghi85 »