Rollbacks ad (FYI)

[tubby]

System Restore Software | Fix Any PC Computer Issue Without IT Knowledge - Horizon DataSys

-Here is a link to Horizons Rollback Rx page. (The video is pretty good.)


Any thoughts?

Is product everything claimed?

tubby

(I trust this link works, if not you amy have to manually type it in)

[Baldrick]

As far as I am concerned the answer is 'Yes' or I would not use it.

But it should be used in conjunction with a periodic full image of your hard disk...as a fallback. And before someone comments on what I mean by 'periodic' I would say that is up to you but certainly no longer than a month ( personally take on every week).

[Owl]

There does seem to be a bit of hype:

RollBack Rx recognizes how your hard drive is composed at the bit level prior to the installation/update.

Obviously I have no inside information, but I think this should read "sector level" rather than "bit level".

RollBack Rx is designed to protect both the user and PC from accidental user errors and day-zero attacks. Without restricting the users’ activities, RollBack Rx will transparently take system snapshots on a schedule that you configure for your system. If a virus, malware or even *BSoD occurs – You can restore your system up-to-the-minute of the system crash. With no data loss.

You know I'm skeptical. A "zero day attack" means (to me anyway) a virus that has not been classified by the antivirus community and AV product databases updated to recognise a signature. That means that an infected file can slip through the defences and potentially be executed either automatically or by the user because the AV program will not have flagged it as unsafe. If the consequence of executing the malware is that low-level disc accesses bypass RBRx's management of the file system, then there can be no guarantees that the snapshot structure will be intact. If you are not running any AV then every attack is a zero-day attack.

But hey - I use it for what I know it can do, not for the things I wouldn't trust it to do, and the scenarios I suggest are bordering on the "unlikely".

[pvsurfer]

Originally Posted by Owl

You know I'm skeptical. A "zero day attack" means (to me anyway) a virus that has not been classified by the antivirus community and AV product databases updated to recognise a signature. That means that an infected file can slip through the defences and potentially be executed either automatically or by the user because the AV program will not have flagged it as unsafe. If the consequence of executing the malware is that low-level disc accesses bypass RBRx's management of the file system, then there can be no guarantees that the snapshot structure will be intact. If you are not running any AV then every attack is a zero-day attack.

But hey - I use it for what I know it can do, not for the things I wouldn't trust it to do, and the scenarios I suggest are bordering on the "unlikely".

Exactly (and well said)! But wouldn't it be awesome if RBRx prevented direct-writes to the HDD (imho, that would make it bullet-proof).

[nexstar]

Originally Posted by pvsurfer

Exactly (and well said)! But wouldn't it be awesome if RBRx prevented direct-writes to the HDD (imho, that would make it bullet-proof).

There used to be an option to “Disable direct disk IO” which, I think, had to be supported by the motherboard chipset. I see that the option was removed in March, is that what this effectively did?

Graham

[pvsurfer]

Originally Posted by nexstar

There used to be an option to “Disable direct disk IO” which, I think, had to be supported by the motherboard chipset. I see that the option was removed in March, is that what this effectively did?

Graham, that's a very good point that you make ...and although I cannot answer your question, as I suggested above (in my reply to Owl) if RBRx could (and would) disable direct disk writes by all other drivers/programs that might very well prevent Safesys and TDL/TDSS rootkits from messing with the integrity of RBRx's snapshots!

pv

[Owl]

SOMETHING has to be able to write to disc, and if RBRx can then so can something else.

[tubby]

now we are getting somewhere.......

[nexstar]

Originally Posted by Owl

SOMETHING has to be able to write to disc, and if RBRx can then so can something else.

But isn't this, in the case of RB, how it works? By redirecting requests to write data to the disk, it puts data where it wants thereby protecting the old data.

With my scant (non-existent) knowledge of Windows drivers, I'm guessing that there are other calls which can be made which by-pass the filing system to allow direct access for such things as MBR mods etc. If that's the case then couldn't those same calls be replaced/modified to restrict and control access to the hard drive?

I would assume that MBRGuard, which has been mentioned in other threads, would have to work along those lines. If other applications were still able to modify the MBR without its consent then it would have failed in its sole purpose in life and the MBRGuard developers seem pretty confident in its capabilities.

I remembered that I asked about the 'Disable direct disk io' a while ago (4 years ago, actually ) on the Wilders forum here and there seemed to have been some conflict issues with the option so maybe that is why it wasn't promoted and was subsequently removed.

.....and Tubby. I think RB has a pretty good crack at doing what it is supposed to. I would never use it as my only line of defence so, in my case, its main purpose is to quickly get the system back to a known state after testing new software. Would I stake my life on it never being compromised? No, but as part of a small suite of applications I use to keep me safe then it fulfills a valuable role .

Graham

[Owl]

*If* you gan get code to run at a high enough privilege then you can get access to the hardware directly without any driver involvement, which is why it is impossible to guard against absolutely everything. The way an AV suite protects against zero-day attacks is to screen the code for anything that might be subversive before it gets a chance to run, and the way the attackers get around that is to hide the code as data (possibly in the link stack) so the AV doesn't know about it in advance.

If it was possible to protect the system just by switching off accesses, don't you think it would have been done by now?

I don't know anything about MBRGuard, but the MBR doesn't do anything until boot time. It wouldn't be hard to check it on shut-down and periodically during up time to check that it had not been altered in the mean time and restore it if necessary, without having to prevent anything writing to it.

It all feels a bit like when I was designing hardware. Self-test was the flavour of the month, and then the test department realised they could use it for production testing and wanted more, and then the self-test hardware needed to be able to test itself... All of a sudden you have more hardware devoted to the testing than to getting the actual functionality running, and even then it still doesn't give you 100% coverage.