[Repost] Wiping of disk cache does not work?

Sorry mods, please delete my earlier thread

Alright this is what I originally posted, but decided that I needed more 'confirmation' before I did so, and confirmed I have.

We all know that the hidden RVSystem.CCH is the disk cache, and it probably operates together with RVSystem.dat to keep track of the changes while your virtualization (i.e. System Safe) is enabled.

First I ensured that SystemSafe is enabled ('Virtual System Enabled' is shown, and I click the link 'Enable when I start Windows' so that it changes to 'Disable when I start Windows'). To ensure that everything is working the way it should be, I did several restarts, each with some changes, and the changes, including system settings etc, were removed upon restart.

Under Preferences>System Safe, I enabled 'Wipe all disk changes at computer startup' and started making changes to the computer (over several restarts) and each time I would check the CCH file for any evidence of my earlier data being present.

Since RVS is supposed to wipe all disk changes ('in the cache file', as stated in the user guide) I should expect that
1. The changes I made are unrecoverable
2. Parts of the CCH file should have random bytes overwritten (as stated in the user guide)

However, I found neither of these were true, as the entire contents of the data 'added' to the computer were found in the CCH file. And I couldn't find any part of the CCH file that was randomized, all the data "made sense", i.e. you can see file names here and there, and you can see 0x00 in "clusters' indicating file breaks that many files contain.

(I did find, however that the RVSystem.dat file looked randomized)

In a seperate finding, I indicated RVS to use 25% of my HDD for the virtual system. A simple calculation calculates this to be 60GB. The file size as seen from EnCase is somewhere along 55GB but it is a reasonable estimate.

Now, with a new chunk of data that I added to the computer, I copied 25GB of data onto the computer. 25GB is reasonably smaller than 55GB, and a quick investigation on EnCase shows that more than half of the CCH file is empty, and unused (full of 0x00), which is expected. The problem, however was that some of the 25GB (about 5GB worth) was dumped into Unallocated Clusters.

This means that even if the Wiping worked correctly, there was a possibility that RVS would first write all your changes into the CCH file, and then 'shift' the start and end points of the CCH file such that you have some data leaked into Unallocated Clusters, which RVS would then not include in the wiping process.


To summarize all my findings.
1. I found zero evidence that any wiping activity was taking place in RVSystem.CCH, and that all data inside was intact and recoverable.

2. RVSystem.dat is possibly wiped

3. The handling of the CCH file location can change, possibly causing data to 'leak' into Unallocated Clusters, and being unable to wipe.

I'm not too concerned about points (2) and (3) yet, so lets address (1)

Someone in an earlier posting on Wilders mentioned that his computer started without any 'slowdown' caused by the wiping. I, too, did not experience any slowdown upon restart, even though I had copied 25GB worth of changes onto the computer.

I'm reporting this because I'm concerned that people are attracted to RVS due to the wiping ability, thinking that all traces of their data are unrecoverable. However, this has not been true in my case.

I'm using RVS 3.1.8774.5254-REL Free Version, and tested this on seperate HDD's on Windows XP SP3, Windows 7 Home Premium 32-bit, and Windows 7 Pro 64-bit, all with the same results

Would appreciate if anyone could verify this.

 

Hello schrecklichkeit,
Please see your PM and send us the logs requested.

Thanks
Mike

 

Hello schrecklichkeit,
Apologies for the delayed reply. Please retry your test with the System Safe feature configured to start with Windows (always on). What you are describing is due to the fact that the cache wipe will only function when you have the virtualization active.

When the virtualization is off, there is no cache to wipe...

Mike

 

So the reason that it did not work (wipe) is because Returnil was not set to "Enable when I start Windows"?

 

I am pretty sure System Safe was enabled across all restarts as I have described in my post and my e-mail reply.

I'll do another set of results and send to you again, Coldmoon just to be sure.

Could it even be a case where I DID enable it across restarts, but those files that I sent you did not register this, such that wiping did not take place?

 

You report actually indicated that your settings put you in Session Lock mode rather than always on. Change the setting in the System Safe section (check the option to start with Windows), restart, and then verify that the tray icon/desktop toolbar have red shields.

 

I have verified that the shield is always red, and the other observations you have mentioned as well. I knew this would have been the main 'please make sure you have' reply so I have cross checked this multiple times each time.

No offence, I know I sound frustrated

It could be a problem where RVS does not update the 'state' of the system safe appropriately in the necessary files and when the computer restarts and checks the files to see 'should I wipe?' it reports it as 'No'. While this might sound far-fetched, it would explain both our observations.

(you really have to trust that I got the 'Enable across sessions' thing right, it's not just a single session lock)

 

Hi schrecklichkeit,
Thanks for the feedback. The team is investigating and will get back to me as soon as possible.

Mike

 

Hi,

Have you managed to investigate my case further since?

 

The report is still under research and internal discussion. It may be some time yet before a resolution is available.

Mike

 

Hi Coldmoon,

Sorry to dig this thread up again. Haven't heard back for some time.

I'd just like to check if the team was able to confirm this observation, and that it is not only on my side? I'm alright if there has not been any resolution, just a confirmation of the issue will do

 

There should be a fix included in the next build.

Mike