Bouncer (previously Tuersteher Light)

Thanks for the update! That's great news.

 

Excellent! @WildByDesign . Thanks

 

I will be getting a pre-release copy of the Pumpernickel driver with Read access filtering prior to it showing up on the Beta Camp just to put it through some additional testing scenarios before it goes public. I'm sure that anybody else interested in trying it prior to Beta Camp can talk to Florian and explain your willingness to test, although I assume that it would be in Beta Camp about a week after.

Anyway, I wanted to ask and see if there is anything specific that any of you suggest that I should test with regard to blocking read access. Maybe some of you who were familiar with using Secure Folders previously could suggest some particular scenarios that I should add to my testing scenarios. Unfortunately I did not have much experience with Secure Folders. I probably wont have the pre-release Pumpernickel driver for about a week. Florian has added the read access filtering to Pumpernickel initially as like a "quick and dirty" coding proof of concept to ensure that it works successfully first. His next step now is to clean up the code and ensure perfection in his code base.

So with this, we should be able to define which programs/executables/drivers have read access to which files/directories and therefore control whether read access is allowed or denied. I can see this one feature opening up quite a bit more possibilities with the Pumpernickel driver and the overall control over the security and privacy of our computers and file systems.

@Mister X @Cutting_Edgetech @EASTER You're welcome, guys.

 

Thanks a lot for the news @WildByDesign

 

@Windows_Security If you have a moment, Kees, I would like to ask for your opinion on something.

I know that you may not be using Pumpernickel at the moment, but you did have a very good understanding of how it works and how to configure it. If I remember correctly, at one point you had also shared a Pumpernickel configuration that was intended to protect the Chrome directory.

I received the pre-release copy of the Pumpernickel driver from Florian this morning to test it prior to reaching Beta Camp and essentially this release just adds the feature of filtering/blocking Read Access. So what I am wondering is how this Read Access filtering feature might have affected your configuration scenarios that you had experimented with previously.

Essentially, what I'm wondering is if this Read Access filtering would have caused problems for your previous configurations of Pumpernickel protecting Chrome directory or whichever other configurations you had tested. At the moment, with this pre-release driver of Pumpernickel, it filters/blocks all of the previous functionality that it had but also adds Read Access to the filtering ability. I'm trying to figure out if I should suggest to Florian whether or not Read Access filtering should be configured separately. For example, maybe filtering everything for most scenarios would be good, but if certain scenarios if the Read Access filtering was not actually needed than maybe it would be better to define it separately. I hope that I explained that appropriately. I figured that you would be the best person to ask because you had always shared such thoughtful and creative configurations and you have a good understanding of what's going on under-the-hood. Thanks!

 

Yes, read access needs different configuration than write access.

Either through different ini sections or by parameters.

 

@Windows_Security That is what I was suspecting. Thank you for confirming, sir. I will pass that important suggestion along to Florian.

 

Nice by effect of read blocks, is that blocks just in time execution of dot net DLL's

 

Now that is certainly a nice, positive side effect. I hadn't even thought that far ahead yet.

This morning, I have suggested to Florian about the separate config for read access, whether that be a different section within the ini file or possibly some character added to the rule lines which the user would like to add read access filtering. I'm sure this is something that Florian will have no problems breaking down within the config.

Either way, I must admit, this addition of read access blocking is absolutely rock solid. As per usual, I have experienced zero bugs with his pre-release driver and the data that is protected by Pumpernickel is locked down tight. Not even elevated Admin can get read access. I am very impressed so far. I will test thoroughly some more for a few more days and allow for Florian to break down the config for read access, then suggest that it's moves forward to Beta Camp. The possibilities seem endless and this is exciting for me. Adding in the fact that you mentioned regarding JIT execution of .NET binaries, WOW!

When this reaches Beta Camp, I will share some config examples for users here to help show what all can be done. And I'm sure that you, Kees, will likely come up with some fantastic configuration examples as well.

 

I've been testing this latest Pumpernickel pre-release for about two days now with great results, and I remembered your question and wanted to follow up with you on this. Can you please describe some scenarios so that I can better understand what you mean by stopping low level writes?

From my current understanding, even Admin privileges cannot access or modify this protected data. Now, if you are referring to low level access by other kernel-mode drivers for example, that is something that I am not 100% certain of. For another kernel-mode driver to be able to bypass these restrictions, it would likely need to have a lower instance "Altitude" or essentially an earlier startup time after kernel init within the order of loaded kernel drivers. For this to occur, something would need to execute with elevated privileges in the first place, though. The lower they are within the boot order, the more control they have and the more priority they have. At least that is my understanding. One thing that I do know for sure is that Florian puts a tremendous amount of thought and care into ensuring that his drivers load as early as possible during kernel init. Now if, by low level, you are referring to booting up a Linux live OS and things of that nature, Pumpernickel would not protect against that kind of physical access. Physical access protection is, of course, a whole different ball game as you likely already know, which would require encryption of sensitive data and much more..

 

@WildByDesign thanks a lot for your concern.

No I do not mean this at all. I believe no security software can protect from that on this scenario.

I understand this, fully.

I meant to say low level formatting, please read this: https://en.wikipedia.org/wiki/Disk_formatting
Certainly, there are others mentioning low level writes here at Wilders but not sure if they are talking about low level formatting too. Would be helpful if any other member could help on this matter though.

 

Low level writes are generally referred to as disk writes bypassing Windows OS.

As far as I know these required UAC elevation on Vista. Don't know whether this is still possible on Windows 10 considering all the measures Microsoft takes to prevent boot circumvention (accessing disk while bypassing OS, is similar rights breach as to circumvent the OS at boot time).

Does Comodo still block low level writes on Windows 7 and above? Pumpernickel is a driver, so it should be able to protect against low level disk writes when OS still allows itself be bypassed.

 

Thanks. Could you elaborate a bit more please? Some links for further reading?

 

Added some info in original post. Don't have recent info on it, sorry.

 

Thanks a lot

 

It can't protect against low level disk writes. (self-tested)

Yes, admin rights are needed to do this.

 

@mood

Thx, what OS did you test it on?

 

Windows 8 x64

 

There's a bug on W10.

When you enable just logging, the Bouncer toast (fly-out) will effectively lock you out of access to the Bouncer tray icon -- if there are a lot of fly-out notifications.

And there is an absolute tidal wave of block fly-out notifications if you enable parent or command line checking.

The Bouncer toast will not stop if you enable cmd line checking -- this means there is no access to the tray icon, config.ini, log, etc; the user is locked out of the Bouncer tray icon.

@WildByDesign - perhaps you can tell Florian that logging needs to be silent (without toast notification) on W10 - otherwise user is essentially locked out of tray icon. Going to Bouncer.ini and disabling CMDCHECK will not stop the toast notifications - and terminating the Bouncer tray icon via Task Manager - will not fix the issue.

* * * * *

Also, Install Mode On - Bouncer is deactivated and then within a few seconds reactivates.

The same happens when you select Install Mode - Off.

 

I have seen this with other security-tools too.
If there are a lot of notifications in a row, nothing can be done with the tray-icon.

An option to turn off Balloon Hints (toast notifications) would be nice.

 

Code:

BouncerTray.exe nopopups

You can add the nopopups within the registry startup as well. I personally don't care much for the toast notifications. This nopopups will disable OS toasts and balloons as well.

 

@WildByDesign

Where does BouncerTray.exe nonpopups go ? As the first line item of the Bouncer.ini ?

LOL... silent logging should be the default - especially for W10. It really should...

 

@WildByDesign

How can I edit the bouncer.ini with the tray icon turned disabled ?

I am in Admin account, but every text editor that I use then Access is Denied when I attempt to modify the .ini...

* * * * *

Never mind... I got it via Admin cmd prompt > notepad.

 

There is incompatibility between Bouncer and AppGuard... even with both AppGuard and Bouncer disabled.

 

If you've used the Bouncer installer, it will create an autostart registry entry for BouncerTray in the following location:

Code:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

On the key that directs toward BouncerTray.exe, simply add nopopups at the end.

Or for testing purposes, you could alternatively create a desktop shortcut to BouncerTray.exe, add nopopups to end of Target box within shortcut properties.

Example:

Code:

"C:\Program Files (x86)\Excubits\Tool\bouncertray.exe" nopopups

Just ensure the path is correct per your system.