"Sure you can. Piece of piss. Why, even XP had "fixmbr" and "fixboot" commands to fix the mbr on another attached disk. Took all of a couple of seconds to run (if that).
7 and up IIRC have "bootcfg /somethingIcannotremember", worked as well. Or is it "bootrec"? Been a while.
There's tools in Linux to do this just as quickly and easily, and if you're really struggling you can look at boot repair disk which is a bootable CD/USB/PXE image which will do it all with a few mouse clicks."
It is amazing that no one else figured this out. Actually it isn't amazing because it isn't true.
When NotPetya gets on the machine it does more than just "encrypt the MBR".
1. When it initially gets on the box, it overwrites (not encrypts) the MBR with its own bootloader and scans the system for a few files. Specifically, it checks to see if the machine is running Kaspersky, Norton Security or Symantec anti-virus products. If it finds any of these products it has specific processes it uses to avoid detection.
2. If it doesn't find any of those AV products, it checks to confirm it has the privileges to perform its task and assuming it does, it drops its modified version of MimiKatz to pull any credentials out of memory.
3. If it is able to pull admin credentials from memory, it will attempt to use those credentials to spread in the network (using DHCP if it happens to be on a domain controller or scanning the local network if it isn't on a DC) and while it is doing this it is also scanning the hard drive for the ~65 specific file types it was created to encrypt and encrypts them with 128 bit AES encryption.
4. If it is unable to pull credentials from memory, it then attempts to use EternalBlue to spread to computers on the same subnet as the infected computer as a last resort.
5. After it finishes spreading and encrypting individual files, it chooses a method to reboot the machine based on the privileges it has in its user context. Initiating a system shutdown, creating a hard error that causes windows to reboot or creating a scheduled task to initiate a reboot within an hour. (up to this point, the user has no idea anything is going on unless they get suspicious because the hard drive light is thrashing)
6. System reboots
7. The system runs the NotPetya bootloader and loads its own lightweight operating system. This OS displays what appears to be a Windows chkdsk screen telling the user that it is attempting to correct errors on the disk. What it is actually doing is encrypting the MFT and then displaying the ransom note.
So you can't just boot into a disk recovery environment or slave the disk into a working system because the specific file types NotPetya targets were encrypted on top of the MFT being encrypted. It targeted file types like .7z files and VMware files. File types that would be important to a corporate environment suggesting this was targeted to take out corporate, government and infrastructure targets.