Steve the IT Tech Guy

Yes I still have a 2008R2 Server but they will be replacing it hopefully soon.

When I tried to restore from a GOOD Windows backup (On a 4TB drive) I get this:

bmrui.exe – Application Error

The instruction at 0xff10b494 referenced memory at 0x00000000.  The memory could not be read.

when attempt to restore system image from external hard drive.

Found the solution here

Basically I had to assign a drive letter from another PC and then re-attach it back to the server to do the restore.

From Security Now Episode 776

A link to CheckPoint’s detailed write-up is in the show notes for anyone who’s interested. It’s very detailed and wonderful and takes us step-by-step through their process. But I’ll just hit the high points here: For every query type that a DNS server makes there’s a corresponding reply.What the CheckPoint guys found was a classic math result variable sizing mistake in the parsing logic for the reply to a “SIG” (as in signature) query which is part of DNSSEC.They discovered a mishandling of values between the 16-bit fields used by the DNS protocol and the 64-bit register math used by the code compiler. Coders know that if a 64-bit value is calculated to allocate memory, and if the result is larger than 65,535 (the maximum absolute quantity that can be represented by 16-bits), then the least 16-bits of that value will be a small integer — which is the amount of the overflow over 65,535. And if THAT smaller integer 16-bitvalue was then used to allocate memory for a buffer, the resulting buffer will be much too small to hold the larger calculated amount of data. And, of course, that’s exactly what happened.They discovered that by sending a DNS response containing a larger-than-64KB SIG record, they could cause a controlled heap-based buffer overflow of roughly 64KB more than a small allocated buffer. For hackers that’s the golden keys to the server kingdom.CheckPoint concluded their write by noting:This high-severity vulnerability was acknowledged by Microsoft and was assignedCVE-2020-1350.We believe that the likelihood of this vulnerability being exploited is high, as we internally found all of the primitives required to exploit this bug. Due to time constraints, we did not continue to pursue the exploitation of the bug (which includes chaining together all of the exploitation primitives), but we do believe that a determined attacker will be able to exploit it.Successful exploitation of this vulnerability would have a severe impact, as you can often find unpatched Windows Domain environments, especially Domain Controllers. In addition, some Internet Service Providers (ISPs) may even have set up their public DNS servers as WinDNS.We strongly recommend users to patch their affected Windows DNS Servers in order top revent the exploitation of this vulnerability.As a temporary workaround, until the patch is applied, we suggest setting the maximum length of a DNS message (over TCP) to 0xFF00, which should eliminate the vulnerability. You can do so by executing the following commands:

reg add “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters” /v “TcpReceivePacketSize” /t REG_DWORD /d 0xFF00 /fnet stop DNS && net start DNS