RollBack Rx/HitMan Pro MBR issue

Graham over on the Horizon Data Systems Rx forum has taken a look at this issue and posted his results and thoughts there. If you are using, or thinking of using Rx you might find the post of interest. It can be found here
http://horizondatasys-forum.com/19957-post32.html

 

LOL! Graham is one of the dedicated of the Rollback Rx (RB) forum along with few others.

He faults Hitman PRO (HMP) rather than RX by saying, "I decided to look at the Hitman Pro (HMP) vulnerability of RB ....... I personally feel that RB and similar software has been around long enough that HMP should be aware of it and not flag it as such."

How many AV/Malware vendors have to be aware of RX that they should not flag it as such?

Shouldn't RX protect itself from all these AV/Malware, and/or advise the users of RX to do as such?

Doesn't the fault lies with RB rather than all these vendors of AV/Malware?

 

Because minimizing false positives is also part of measuring a good AV tool.

 

Makes you wonder why this is only happening with HM Pro then...

But at the same time, you admit that not all rootkits are bad. So get your argument straight.

 

Be a good reader and it is not only happening with HM Pro ......

Who said that all Rootkit are bad. We don't know much about HDS Rootkit, so we cannot make the decision that it is bad or good. If Sony cannot be trusted then HDS cannot be trusted either.

However, it is the responsibility of HDS to inform the users of Rollback Rx that they are implanting a Rootkit in their system. And, how to give exclusion to this Rootkit by their AV/Rootkit programs.

If they don't and their users system becomes non-bootable and corrupt from which Rollback Rx is supposed to protect then the blame neither lies on the users nor on the AV/Rootkit vendors.

Be a good reader!

 

So now I'm being accused of not being a good reader. Where in this thread does it say that it is a systematic issue with other Malware/AV tools? I went over this thread and don't see it.

And are we really talking about a rootkit or a bootkit? I thought the issue was what Rx modifying the MBR to provide a pre-boot recovery console. So are you saying that all other ISR softwares should be classified in the same boat?

 

Read the OP and follow the link in the OP to an another forum. HM Pro is the only one.

 

So now you're contradicting yourself. I read the OP and the link to the HDS forum. Still don't know what you're talking about.

 

My old Deskpro Compaq has such feature. Their "Master Boot Record (MBR) security" is enough to protect MBR virus. If some software OR virus try to change MBR, when booting a warning comes out: "Master Boot Record Hard Drive has changed. Press any key to enter Setup to update the MBR Backup.". HP info here about.

Without user agreement there aren't any way to MBR to be changed! SCSI direct access never pass this protection!

I don't know why such feature was completely abandoned in "basic hardware design of today's personal computer". A reason that is not convenient to be known?...

No surprise that the old Brain IBM-PC virus [from 1986... ] comes out again to surprise PatchGuard 'experts' - that are always fashionable and quite modern...:

 

Here is to cut this mumbo jumbo:

1. Do you think that HDS has an obligation to warn the users of Rollback Rx that it is implanting a Rootkit in their computers for Rollback Rx to work porperly?

2. And, provide the users with information how to exclude this Rootkit in their AV/Rootkit programs, so that won't accidentally delete this Rootkit, thus rendering their system non-bootable?

 

It's a bootkit, not a rootkit. It installs its own MBR to offer a pre-boot recovery console. Rx is far from the only software to do so as well. Where the flack on TrueCrypt, RestoreIT, etc?

 

Because it's not a rootkit!!

 

It is a problem with any good "bootkit detector"
https://www.wilderssecurity.com/showthread.php?t=254822&highlight=rollback mbr
https://www.wilderssecurity.com/showthread.php?t=258181&highlight=rollback mbr
https://www.wilderssecurity.com/showthread.php?t=260619&highlight=rollback mbr

Bootkits evolution
http://blog.eset.com/2012/01/03/bootkit-threat-evolution-in-2011-2
TDL4 bootkits hidden storage is very very similar with RollbackRx's subsystem.

Antivirus programs should warn the users of possible bootkit detection. With Rollback/EazFix bootkit whitelisting can cause missing detections of other bootkits.

Bottomline. When this happens it is a users fault.

Both RollbackRX and antiviruses do their job correctly, the first installs the bootkit to function correctly and the second correctly identifies a bootkit on the system.
Having said that EazSolutions could use a way of protecting the mbr with its driver by checking the mbr status at the startup; if it finds it modified in any way should rewrite it and force a reboot.

ps. RestoreIt does not use a bootkit and does not need to. Its recovery console is nothing more than a WinPE. Even in older versions where it modified the mbr did not use bootkit techniques (it did not try in any way to hide its preboot files from the OS.

 

But if you instruct RestoreIT to take a snapshot at every reboot, it does so at pre-boot time. This is not about the recovery console.

 

This does not make it a bootkit.
The main feature of bootkits and rootkits is to remain hidden from the OS to avoid detection by the administrator/root of the system.

RestoreIt does not use stealth techniques.

Panagiotis

 

Not really. most (all?) legit apps use windows apis to access the disk and the mbr. Those modifications are intercepted by RBRX driver and are redirected to the virtual mbr that RBRX provides to the system.
The problem is with the direct access and only mallware use it without warning the user first.

Panagiotis

 

There are people who cannot tolerate any criticism of HDS and/or Rollback Rx and they have lost their objectivity.

Sorry to disagree with both Panagiotis and you, it is buyers' faults and buyers to beware!

Gone are the days of Better Business Bureau (BBB) of the 60s, 70s and maybe 80s. Now we are back to the days of 20s, 30s, 40s..... We are back to dark ages where buyers' beware!

 

ot posts removed

 

Well in this case it is users fault. The AV warns about the bootkit infection and asks to delete/restore it. Who is the one that clicked ok?
Was the AV responsible for the user action?....No because it did not take an automatic action.
Should RollbackRX prevent the modification? Off course (according to their advertisment).... Is it responsible for the result? Depends in the point of view...
from the EULA
"LIKE ANY RECOVERY / DATA RESTORE PRODUCT, THERE IS A RISK OF DATA LOSS OR DAMAGE WHEN USED IMPROPERLY OR IN UNTESTED ENVIRONMENTS OR CONFIGURATIONS. ACCORDINGLY, YOU SHOULD USE THE SOFTWARE IN STRICT ACCORDANCE WITH ITS DOCUMENTATION AND ONLY AFTER MAKING A SUCCESSFUL BACK-UP OF YOUR DATA. PLEASE CONSULT OUR KNOWLEDGE BASE FOR FURTHER INFORMATION."
"The software is provided to you by Horizon DataSys without any warranties, representations or guarantees of any kind."
"BY USING THE SOFTWARE YOU EXPRESSLY ASSUME ALL RISK OF LOSS ASSOCIATED WITH ANY DATA LOSS OR DAMAGE."

Panagiotis

 

Without any intent to take sides here, I believe this occured not because RollBack Rx uses a bootkit, but because RollBack Rx can not protect the MBR (or the very sectors 'locked' by its snapshots) from direct disk I/O actions of malware (or anti-malware). That is RollBack Rx's Achilies Heel!

TS

 

It would be convenient if it could but you're suddently into anti-malware territory, e.g. Shadow Defender's dubious approach to protecting the MBR or Appguard's protection. I'm not sure I really want that out of Rollback RX.

Interesting EULA though. Thanks Pandlouk.

 

Talking about me? I don't use Rx. I don't trust it... lol!!

 

Dear Panagiotis,

Thanks you for posting the EULA from HDS for Rollback Rx. I now know exactly what you mean by being the "users fault".

Best regards,

 

On the subject of Booting, MBR and Boot kits...I have a question!

Normally under Windows (later than XP) I understand that the MBR boot code calls on a boot loader file (NTLDR) located in the first sector of the active partition. This boot loader uses data (BCD) contained in the Boot.ini file located somewhere else on the active partition. When an application modifies the MBR boot code, I assume it is to point to its' own boot loader file, either instead of the standard Windows NTLDR, or before executing the NTLDR file!

So RollBack RX probably modifies the MBR boot code to point to its' own boot loader, rather than use the Windows NTLDR file. Then again it might use the NTLDR file Windows provides, but modify the boot.ini configuration data to achieve its' objective.

In that case it may not need to modify the MBR boot code! Does anybody have more knowledge of the specifics here?

 

Since posting this I have learnt more: There is a difference in the Windows OS that changed things after Windows XP. Versions later than XP don't use NTLDR to load the Windows kernel, they use two system files and one of them contains the BCD in a registry like format. Rollback RX has its' own small kernel that loads in the early stage of the total boot process (before calling on the Windows kernel to load as part of the OS stage of the total boot process). Rollback RX loads it's kernel first because during installation it modifies the MBR boot process to do this. It then supplies Windows with disk sector mapping info that Windows calls for during its' boot up process. Windows is none the wiser as to the source of that info!

Thus I can hypothesize that any application that changes disk sector data such as a defragger, also updates the disk sector table. However Rollback RX is now feeding Windows with this information, so unless the defragger can update the Rollback RX disk sector information, I guess Windows never sees these changes and eventually goes into a closed loop until it finds what it is looking for (and never will). To the operator this is a system freeze! You will have to uninstall and reinstall Rollback RX so it can remap the current disk sector information again. Although going back to an earlier snapshot before the defrag should restore to a working system in theory! Has anyone tried this?