A few questions from a prospective user

First off, thanks in advance for your help.

I run windows 7 x64 and am considering adding returnil as part of my layered security model alongside Comodo Firewall and Defense+, avira 10 personal, sandboxie, prevx and immunet. I do not believe I should experience any problems with any of these programs. I do currently have acronis true image 2010 installed and wonder if that would conflict with or fail to work properly with returnil.

Additionally, I am curious as to differences between the x64 and x32 versions of Returnil. I am rather dismayed at the reduced secrurity of my other products due to PatchGuard. I saw a reply from someone from returnil in another thread
(coldmoon, I believe) that said there was no effect on x64 due to PatchGuard. I am wondering how Returnil operates so effectively in x64. I would appreciate it of you could provide some details on how returnil maintains such an absolute level
of protection without patching the kernel. How does it enforce the system-wide virtualization?

I use an ssd in this machine so am concerned with the amount of writes done to the drive. Does returnil amplify the amount of data written to the drive as compared to a normal system?

A rather simple question: how easy is it to commit changes to the actual drive and what protections are in place to prevent malware exploiting this and committing changes to the drive? Is there a toggle switch which unconditionally prevents all changes to the drive until after a reboot? Such an option would be wonderful to switch on before performing an unsafe activity such as web broswing and completely guarantee the integrity of the system.

My final question is that of performance. I play recent, system intensive games. How does returnil affect performance? Not disk performance, which I am not overly concerned about, but CPU and graphics performance? I am rather ignorant of the means by which returnil and similar products operate and hope to be enlightened.

Thanks for your time.

 

Hello ace55 and welcome to the forums

Just remember to deactivate the RVS System Safe virtualization before attempting to create a backup or image as RVS will stop these programs from performing said activities when the system is virtualized to prevent potential damage to the real system files. Also be aware that disk defragmentation is similarly blocked for the same reason.

The difference is wholly due to the way RVS virtualizes the system. There is no conflict with patch guard because RVS does not need to "patch" the kernel or monitor the file system. Though not an exact description, think of RVS as a drive filter, rather than a file system filter. As a result, the RVS System Safe virtualization does not care what Windows does or what is happening within Windows as said changes will be removed at restart of the computer.

This property of the SS component is counter-balanced by the detection capabilities in the Virus Guard component to provide the canary-in-the-coal-mine warning of potential malware from newly created or introduced content so it can be "flushed" from the virtual environment and keep your real system clean over time.

RVS uses a cache to store and track changes during the applicable virtual session (with SS on and until the next restart = one virtual session). Like (but not exactly the same as) the Windows Pagefile, the RVS cache is written to in a form of "streaming consciousness" until the computer is restarted and then begins again at the start of said cache with the following virtual session. This starting point may change due to the fact the the RVS cache is created "on-the-fly" as needed, but can result in the same sectors of the disk being used disproportionately to other sectors of the disk.

As you are probably aware, SSDs have a more limited life cycle (~100,000 writes) for any given sector than a traditional platter drive and as a result, can wear out faster. We are working to address this in future versions of RVS and are testing the initial changes to the virtualization engine in the RVS Labs beta which includes multi-partition virtualization. Further, said virtualization supports the creation and maintenance of caches on alternate partitions.

So what does this mean in English?

Let's say we have a slightly customized computer with three partitions:

C:\ = System (Windows & programs)
D:\ = Factory restore image
E:\ = Data drive & supplemental file storage

The new engine will not support moving the cache for the System partition in the first upgrade versions, but will allow this for non-system drives and partitions. This means that you could virtualize the D:\ drive to protect it from unwanted/malicious changes while storing the cache for the D:\ drive on the E:\ drive.

Now take this to a further logical step and let's assume the E:\ drive is actually a supplemental platter drive. In this case, the platter drive can be used as a sacrificial drive to absorb the writes that would tend to degrade the SSD over time. We are working to make this possible for the System Partition to complete full SSD support in RVS as we go forward.

We have designed RVS to be intentionally more difficult to commit content to the real disk as compared to other implementations of virtualization in our space. To commit content you must add that content to the File Manager and then deliberately force that content to be saved to the disk by clicking a link in the tray icon, desktop toolbar, or from within the RVS GUI.

This makes it orders of magnitude more difficult for malware or PUPS to make changes to the real disk. Further, the RVS System Safe feature includes a lock on the MBR by default whenever you activate the virtualization and thus protects the real disk from this type of attack.

We are exploring folder exclusions in the Labs beta as well and will introduce this feature with the engine upgrade for user convenience and a good user experience for those new to the concept of virtualization. The installation however will be to default to no exclusions for the highest level of security - changes beyond this are entirely up to the user and their level of risk aversion.

If using only the virtualization (Virus Guard and malicious behavior/sample analysis are deactivated), you should not even notice that RVS is running. You will need to ensure that your game sessions are saved on a non-system partition/drive as this information would be lost at restart as expected...

You should do some experimentation using training sessions to tweak the settings so you are satisfied with the performance. As a Gamer, you should already be well aware of the risks of on-line gaming and the minimums you need to have in place to ensure your computer is protected while your attention is diverted...

Mike

 

Thanks!

Interesting. Thanks for the information.

Interesting and this is how I hoped RVS would work. I am curious as to how RVS acts as a drive filter. How can RVS protect itself from malware in order to allow itself to protect the system? Does RVS act outside of Windows, modifying the raw drive or MBR in some way? Then the RVS application inside Windows could be protected by the elements outside of Windows and thus guarantee integrity.

I will admit I am confusing myself here and hope you don't mind explaining the implementation further. I have a feeling RVS does not work in the way I think it does but I hope it is as secure as my imagined implementation.

Also, I am curious what portions of RVS inside windows should be protected by my Comodo HIPS. Does RVS rely on any drivers or aspects inside virtualized windows that present ways for an extremely dedicated attacker to potentially exploit which could be additionally protected by comodo?

I will admit I am not very concerned with the virus guard portion of the software. Assuming it does not conflict with my other av software, it cannot
hurt though. The real draw of Returnil to me is the virtualization. I see myself using Returnil so that when I turn on my computer, I can perform any sensitive tasks, such as typing in passwords, before I begin gaming. If I need to log into anything again, I would simply reboot to ensue my system is clean. I typically only use this system for gaming and prefer to avoid windows otherwise, so this is not an inconvenience.

I am glad to see attention is being paid to SSD compatibility. In particular the use of another platter-based disk for cache is an elegant solution and I believe a smart addition to your product. I was looking at the returnil 2008 user's guide on your website and noticed an option for caching to RAM. I have 6 gb of ram And rarely use that much of it. Is this option still available in RVS 2010? I looked through the current user guide and do not recall seeing any such option. perhaps say, 2 gb is not enough for a cache? How large does the RVS cache tend to be?

I also noticed an option for password protection. This seems like it should
make it impossible for malware to force changes to be committed to disk, correct?

I hope my understanding of Returnil is close to correct, otherwise I fear much of this post, including the following, will be irrelevant/confusing. That said, is the passage of data between the GUI and implementation of RVS protected?

Consider the following: malicious code is running on a system protected by RVS with unrestricted access to Windows in the address space of a program
present on the real disk. Most importantly, this malware is aware of and tries to subvert RVS. Is the RVS GUI and any other aspects of RVS present in virtualized Windows sufficiently protected so that RVS cannot be subverted, perhaps by tricking it in some way into believing communication sent from the malware telling changes to be committed to disk is coming from the RVS GUI and thus the user? It seems like in this situation the option to use the anti executable opton of RVS would not help. Does the RVS implementation protect the RVS GUI from the running system? How does the password protection help this situation? Does the password protection encrypt the communication between the RVS elements that must be resident in the virtualized, running Windows and the RVS implementation or is there some other way in which the identify of the application telling RVS to commit changes to disk can be verified. Or do I have this all wrong?

A useful feature! I wonder about the security implications of this but that seems to be a question for another day.

Indeed I should have no problem saving single player saves to another partition or even playing single player games without system safe on. Luckily, it seems lately most online games do not store much other than settings locally. I do think I am well aware of the dangers, however you can never be too careful.

Thanks again for taking the time to answer my questions so thoroughly. It reflects quite well upon your company and your product that a venue such as this is available for discussion and support.

EDIT: Quotes fixed. I just noticed the free one year license offer, very generous! I will certainly take advantage of this.

 

Hi ace55,
Just a note to let you know I have read your post and will reply as soon as possible. There is allot of ground to cover so please be patient while this is completed.

Thanks
Mike

 

No worries Mike, I am in no hurry.

 

Thank you for your patience

When RVS System safe is active, any changes malware attempts to make will be dropped by default. So if a virus attempted to delete or edit an RVS related file, the changes would be lost at restart of the computer. Further, the following also apply:

1. If the cache is damaged or made unavailable for any reason, RVS will automatically default to strict Memory cloning and maintain the virtual mode without interruption.

2. If you turn on System Safe and then log out of your account, the virtualization will still be active for any/all users who login after you without restarting the computer.

3. The Virus Guard and AE components are there to provide additional hardening against the small number of malware families designed to specifically circumvent virtualization technologies.

MBR modification/reliance is an older technology and not used in RVS. RVS protects the MBR and prevents most low level sector editing by locking the areas of the disk. As for acting within or outside of Windows, RVS does both. To be used, RVS must integrate with Windows and as a result is part of Windows. When functioning however, RVS places itself between Windows and the real hard disk while making Windows believe it is accessing the real disk

You should exclude RVS from interference from other security applications. When System Safe is on, protecting RVS's files is at best redundant, at worst, problematic as the "protection" may interfere with RVS's ability to function (probable issues: unable to start or stop virtualization, inability to upgrade the client, inability to access the Virtual Disk, etc).

Keep in mind that virtualization can only do three things by itself:

1. Drop all changes
2. Save some changes
3. Save all changes

It CANNOT detect or block the functioning of malware within the virtual environment. So if you were to become virtually infected by a password stealing Trojan, the fact that you are virtualized will not stop it from doing what it is designed to do. This is another major reason why RVS includes Antimalware and anti-execute functionality.

IOW - how do you know your security is working as expected unless you have some form of feedback on its effectiveness?

RVS 2010 uses dynamic caching that is designed to use both Memory and disk as required (On-The-Fly). This means that Memory only caching is not available as a specific setting outside of a need to address a disk cache corruption or blocking to maintain the virtual protection.

It is to keep unauthorized users from making changes to RVS settings and virtual protection mode. It is enhanced by the interface lock option.

All communications are internal to the program so are protected from hijack.

Yes

The GUI is irrelevant to the functioning of the System Safe virtualization. Once you enter the virtualized mode, exiting, deleting, or attempting to alter the RVS GUI is a useless endeavor.

Keeps unauthorized users from changing the virtualization mode or altering any other settings.

Once the virtualization is activated, RVS is the only application that can access the real disk. This means that any "shenanigans" attempted by malware would have no permanent effect and would be gone at restart of the computer having only happened in the virtual environment. Communications are encrypted except for log file output which is meant to be reviewed by the user and tech support when required.

Mike

 

Good questions Ace and good answers Coldmoon. I am learning a lot from this thread.

 

I'm glad you're enjoying this thread, Threedog.

Thanks for your answers Coldmoon. I installed Returnil on my main PC and it is running very smoothly. I'm checking the amount if data written to the drive with the intel ssd toolbox (reads a smart value) and so far it's perfectly acceptable.

So far I am very pleased with rvs. I do want to clarify what i meant earlier about protecting returnil with comodo defense+. I, of course, give returnil permission to perform any action on my system. Otherwise there is little doubt in my mind that I would break rvs and have to restore my system from an image, or at least safe mode. What I meant to ask with that question was how much extra protection was afforded by having a program such as comodo which asks when an application is attempting to modify, for example, a driver installed by returnil.

What you said about any modification to even core returnil files being reversed on restart is impressive. So as long as a piece of malware is unable to trick
returnil into keeping changes, which you have informed me is difficult, the system will remain clean across reboots. Very impressive.

I am glad to hear encryption is being used to make it even more difficult for
malware to subvert returnil. What you said about the ae and av portions of returnil being additional protection against subversion makes sense, however I hope the core program is strong enough that these features are, as you say, simply a warning that your system is infected and you should reboot as opposed to attempting to cover a weakness in the implementation of
virtualization.

Initially I was skeptical that the av portion only added bloat: however, I do believe now that is a valuable addition. I can see how it can easily be
integrated into the virtualization mechanism with little performance hit. Very impressive additional layer! Does rvs still use f-prot?

Also impressed with the ae tech. I was actually looking at standalone anti executable software to provide some redundancy for comodo and rvs' impementation fulfills this role perfectly.

Considering I only need to enter passwords once per session, which I do only after a reboot, combined with not storing passwords on disk, combined with comodos buffer overflow protection and thorough restriction of all net facing
applications (besides returnil, prevx and avira), I think I can be satisfied with my setup.

Thanks again for your answers, I think I'm finally out of questions. Good
product, I'm sure I will renew my license after the free year of home lux from your giveaway.