RollBack RX and Malwarebytes AntiMalware Issues.
One of the most common obfuscations put in place by a RootKit is a file entry with a FileSystem path that looks kinda normal, but underneath that entry, the RootKit does not follow what appears to be its path. In the process of chasing these down, a good RootKit scanner will check the FileSystem path, then use the Windows API for disk surface reading and see if that FileSystem path is real as far as the item being checked.
If you haven't already figured it out, the FileSystem path, by design, is obfuscated by Rollback due to its Redirect-on-Write technology... it tells users of the FileSystem that pieces of the object are in one place, but if the item (or its parts) has ever been changed, it's really located somewhere else on the disk. Now the RootKit scanner takes the FileSystem information, and uses the Direct Disk read API to see if the item is really there. Since that API is not obfuscated by Rollback (I use it all the time to look at direct blocks on the surface of the disk), the RootKit scanner sees a disconnect in the item being checked and immediately flags it as a RootKit.
There's really no way to solve this problem unless HDS was to rewrite the Direct Disk API and obfuscate it the same way it does the FileSystem... I do not think they are capable of doing this. You either need to turn off your RootKit scanning in Malwarebytes, or give up your snapshots following a Windows update either with an uninstall/install at the current snapshot, or with a Rollback Baseline Update... both cases you need to be willing to give up your snapshots.
Source: RollBack RX and Malwarebytes AntiMalware | Wilders Security Forums
One of the most common obfuscations put in place by a RootKit is a file entry with a FileSystem path that looks kinda normal, but underneath that entry, the RootKit does not follow what appears to be its path. In the process of chasing these down, a good RootKit scanner will check the FileSystem path, then use the Windows API for disk surface reading and see if that FileSystem path is real as far as the item being checked.
If you haven't already figured it out, the FileSystem path, by design, is obfuscated by Rollback due to its Redirect-on-Write technology... it tells users of the FileSystem that pieces of the object are in one place, but if the item (or its parts) has ever been changed, it's really located somewhere else on the disk. Now the RootKit scanner takes the FileSystem information, and uses the Direct Disk read API to see if the item is really there. Since that API is not obfuscated by Rollback (I use it all the time to look at direct blocks on the surface of the disk), the RootKit scanner sees a disconnect in the item being checked and immediately flags it as a RootKit.
There's really no way to solve this problem unless HDS was to rewrite the Direct Disk API and obfuscate it the same way it does the FileSystem... I do not think they are capable of doing this. You either need to turn off your RootKit scanning in Malwarebytes, or give up your snapshots following a Windows update either with an uninstall/install at the current snapshot, or with a Rollback Baseline Update... both cases you need to be willing to give up your snapshots.
Source: RollBack RX and Malwarebytes AntiMalware | Wilders Security Forums
