The good part with this is that the MBR protection kicked in when running some tests. I totally forgot that since it was a good long while since even using my Windows 10 machine, that it was installed to Legacy MBR-based partition table. HeiDef-With a GPT UEFI i assume that particular feature of RansomOff has no bearing of coming into play. Keep up the good work in the Lab with the improvements.
Hey @EASTER. RansomOff's MBR protection protects the first 512 bytes of a disk which is where the MBR always resides whether you are using GPT or not. GPT disks still have a MBR-like structure for backwards compatibility purposes and while it's not a real MBR, the space is still reserved. It's important to have this byte area protected regardless because threats like Petya do not attempt to distinguish what type of boot record you are using. In fact, it will completely trash a GPT disk because it will overwrite important data areas that are not important with a MBR disk. So while GPT disks do provide more protection that MBR (and that's probably just a matter of time kind of thing), some threats do not bother to identify one way or the other and just assume MBR. What utility were you using that caused the alert to pop?
Exactly what I been reading up on today. You must been reading my mind after the post. Brushing up on that particular potential critical issue raised my awareness which is openly published in some articles that point out to that very thing which is some of those don't bother with ID but scratch code to that area which in turn still can disrupt a GPT. Thanks for the timely reply and insight and by the way how is the next release coming along for you guys? As you might guess many of us are anxiously if not cautiously looking forward to those ever increasing improvements.
Next release is coming along well. Hopefully by the end of this week it'll be ready. There are two big additions which is why this one is taking a bit longer; cloud integration to share threat intel and a Secure Folders like capability to add additional protections to particularly sensitive locations.
The solution was to remove the certificate that RO had added. The certificate was added to make sure our drivers, which are signed by certificates issued by DigiCert, can be installed properly without any confirmation popups or validation errors. This is necessary on systems that may not have all or the latest CA certificates installed. Part of the issue is that is was installed in the Intermediate CA folder but it is actually a Root CA certificate. While it appears that doesn't matter for validating signed drivers, it causes issues with SSL validation.
Just coincidentally, for info, turning from off to on Secure Folders protection on my external USB drive just triggered a ransomware warning . I have allowed / whitelisted it.
What Secure Folder program are you using @paulderdash? The one by SubiSoft or the one by Promosoft or possibly another?
Thanks @EASTER. There are a few programs called Secure Folders with different ones doing different things so just curious which one he was running that got the alert. Has RO given you an alert from SF?
HeiDef- I did a manual uninstall of RansomOff because I fear there was a clash of titans. As it stands and if can be of any help, Appguard + CFW 10 are also in place. I don't concern over Comodo as much but feel like Appguard's MBR filter might have bumped up with RansonOff's OR the Cerber I threw at the system might have fudged something causing RansonOff to hang up on me when trying to uninstall normally. It wasn't until booting into Safe Mode and pulling out the driver that upon bootup I got this BSOD INACCESSIBLE_BOOT_DEVICE Waiting on the next release to install fresh again.
I though it guards the MBR too? No? I don't know if it even has a filter or the way it works, if it does cover MBR but RansomOff most certainly does because I had to drill my way down to remove it on safe mode. After that on reboot is when the INACCESSIBLE_BOOT_DEVICE screen greeted. I suppose a quick MBR Repair would have cleared it up but I restored a good image to return it back at square one all fresh and tidy again.
You probably mean MBRFilter (but this is a third-party tool) and not related to Appguard. https://malwaretips.com/threads/anyone-using-mbrfilter.67925/ When uninstalled incorrectly you will get INACCESSIBLE_BOOT_DEVICE. Only the MBRFilter value should be removed from the the following key => HKLM\System\CurrentControlSet\Control\Class\{4d36e967-e325-11ce-bfc1-08002be10318/UpperFilters and not the PartMgr or the whole key or the system will be rendered unbootable.
If you also delete the driver file but leave the registry value intact that @doesntmatter mentioned, you'll also get the INACCESSIBLE_BOOT_DEVICE error. That's true with any upper disk filter and not just RansomOff's MBR driver. That's why manually uninstalling by just deleting files can cause problems.
NEVER manually delete files. Always use the provided uninstaller and make sure you have backups in case something goes wrong.
Does RansomOff rely on a driver or user-mode API hooking to prevent modification to the physical drive (PhysicalDrive0)?
New release update yet? We're anxious to see what new improvements you guys have been busy working on in that Lab.
We will probably release it later tonight or early tomorrow. We are holding off on the cloud integration for a bit so the big change in this release will be the Secure Folders like capability. We'll be sure to post a note once we release it.
You guys excel at responding to our Q's and taking necessary steps seriously to better this program every release and so my sincere thanks on behalf of everyone.