System Safety Monitor and Shadow Defender

I'm using SD about two years and in last months I'm using also SSM. Today I noticed very surprising behaviour...for me...both apps. OK...from the beginning:
- I wanted quickly to test TF in Shadow Mode so...
- first I switched to Learning Mode in SSM and then to Shadow Mode in SD with setting "exit from SM on restart"
- I installed TF, checked what I wanted and then I restarted system
- now of course I was in real system with still enabled Learning Mode in SSM
- I switched to normal mode and SSM showed me window with proposition of rules to delete...and it was surprise for me...in window I had entries with all file changes made by TF during shadow mode
- I thought "why and how?!"...I was in virtualised system and nothing should be saved on disk C...
My questions are:
- is SSM so strong and able to bypass virtualisation of SD?
- or SD is so "weak" in confrontation with this HIPS?
- or it depends of localization of configuration/settings file of SSM - by me on data disk D?
Below there are some screenshots with some...maybe important...settings of SSM and window with files to delete after learning mode

 

I believe SSM and SD use drivers to provide protection.
One of controls SSM is offering is driver loading and, if I remember correctly, direct disk access. If SSM can do both of those, maybe it is using same technique to write configuration file to disk.

It's hard to say which program is "stronger" or "weaker", when they both operate in kernel mode. In your case SSM seems to be stronger in the case of writing to the disk.

 

Whether SSM can "see" into a virtual system depends on how much of that system is contained within the hosts own file system. With full virtualization such as provided by VirtualBox or VPC, SSM does not see the individual processes in the virtual environment. In these system, all the activity takes place inside the apps own files and on its own virtual file system. On a system using SandBoxie for instance, the sandbox exists on the host PCs file system. The processes all take place on the host system. All the files physically exist on the host system. Applications running in the sandbox can't "see out" but the host system, which SSM is a part of can "see in", like a 2-way mirror. Without knowing how SD works, I can't be sure, but I'm suspecting that SD creates copies of the original system, then swaps them in when in shadow mode. If shadow mode physically exists on the hosts file system, SSM will see it and will have control over it.

Regarding the prompt to delete rules.
On SSM's options, under applications, is the option "Alert on changed and temporary files in Learning Mode" checked? If so, that's the reason for that prompt.

 

Off topic, but noticed this in the settings you posted. You might want to shorten the time you're storing those logs. With SSM set to log almost everything, those logs will get quite big.

 

@tomazyk and noone_particular
Very thanks for explanations...I think it was probably "unknown feature" of SSM and now I know that "good old SSM" is even more usefull for me...and I like it more

Yes - this options is "on" in my SSM...I wanted that because I would know what is happen in this mode.
BTW...if SSM can have "inspection view" into SD virtualisation and if someone will be able to know "how it works"...is it not a good scenario to break SD protection? By this way one could "freeze" - read and save - all changes that should be undone during virtualisation exiting.
------------------
edit:
Maybe someone have similar experience with other HIPS/monitor?

 

Without setting up a test unit that duplicates what you have, I can only speculate on what is happening. I don't think this is a question of "breaking SD protection". From your screenshots, I see that the SSM config file is kept on drive "D". Didn't notice that yesterday.

You mentioned drive "C" on shadow mode. If drive "D" was not in shadow mode, everything SSM observed was logged onto a "normal" drive. If SSM was storing its files on the shadow mode drive, it would probably not remember the shadow mode changes.

 

Yes, I think you are right. I also didn't notice that configuration file is on D drive. I believe that this explains everything.

 

I mentioned about this in firs post

My configurations/settings/log files of every security apps exist in this location, but I don't remeber similar situation with other HIPS/monotr/blocker that was used by me in last few years. So I still think that this feature if SSM is very unique and usefull

Thanks for every opinion and suggestions

 

Yes, you are right. I'm a sloppy reader

I was using SSM a year ago but did not move configuration file on other location. In your situation it is indeed useful feature.

Malware Defender doesn't have an option to move configuration file on other location. To achieve something similar to SSM, the whole program should probably be installed on separate partition.

 

I don't want be so boring but I checked this interaction between SSM and Wondershare Time Freeze - the result was the same...SSM was able to "capture" virtualised installation of ThreatFire and Ashampoo WinOptimizer. So I consider that the most important in this behaviour is where is located SSM config file...as you earlier mentioned - it's possible when a file is only on non-system disk...like in my cause.

 

With Malware Defender, change your setting in MalwareDefender.ini as follows.

RuleFile=?:\\\MD-Rules.dat

 

Wow, thanks. I didn't know that. It's good to know, if I ever need this option.

Thanks again

 

And how about Malware Defender or some others? Any info?

 

Following kakaka's advice I believe MD can be set up the same way as SSM. I can't test it though, as I don't have Shadow Defender installed.

 

Hi...
I noticed one more thing...
- when we are in virtualised mode we expect that all changes...all settings, configuration...in system or apps will not saved in real system - yes?...
- yes, but not in SSM with config file located on nonsystem disk like in my cause (disk D)
- what was hapenned?...I entered to Shadow Mode ("exit on reboot") and than - after that - I switched SSM to learning mode next...
- I installed new KS Cloud AV and system was rebooted
- and...SSM i still in learning mode
- in rule tab we can see all executed installers

It really looks that in SSM...or maybe in other similar software with similar config file settings...all detected/made changes (files, rules) are saved even if its was done in virtual system.