Bouncer (previously Tuersteher Light)

If you remove C:\Windows\*>C:\Windows\* from parent check do you still get all those blocked events from the Windows folder? Remember to stop, and start the driver after making the policy change.

 

I have since disabled parent checking AND SHA256 hashing as there are too many issues with it currently. I know the developers working on releasing a new version but I'm not sure when. I'm actually surprised with the issues I experienced as I thought they would have been picked up during the beta testing.

 

There was a little of a learning curve for myself to understand the parent check feature well. I'm using a beta version with some fixes in it. I am only using the following rule for the Windows directory under PARENTWHITELIST C:\Windows\*>* I'm not sure about the other one you are using. Make sure you don't have any spaces in your rules. I had one that I overlooked, and it caused me all kinds of issues. I have to step out for a while.

 

@ParaXY You're right, there was an issue with the hashing functionality that made it necessary to hold back on the build at the moment. As I understand it, the API utilized in the most recent driver had a limitation in the amount of data that it was allowed to store in the kernel. For small hash lists, it would not be much of an issue. But for full system hashes, that is where the problem came to light. A certain amount of that data was being cut off and therefore could pose a significant problem.

However, the developer has fixed that issue now. But he is going to hold off on release and put the driver through additional testing. I feel like I should take the majority of blame here because I was beta testing this longer than most users and I failed to discover the issue. I am generally quite thorough and often too thorough at times, yet failed here. I was doing the majority of my full system hashing tests with a previous build back almost a year ago almost but apparently it was just after the introduction of wildcards where this came into play. So with recent builds, I did a lot of testing with the hashing but unfortunately in my testing it was much smaller hash lists as opposed to full system hashing. Regardless, I am still really excited to follow progress and see as each release comes and time goes on. I am still using that most recent release that got pulled because it is perfect in my own testing but as I new testing build comes out I will move along and try that with the full system hashing because that is something that I have been looking into long term. In the meantime, I am going to try creating more scripts to help with the hash lists and do more brainstorming with regard to the longer term maintenance of a hash list and figure out good logic for that aspect.

 

I'm only able to do limited testing since I don't have a license. I would hash programdata directory if I did have a license. What script are you using to generate your hashes? I only use Hashcalc for now since there's no need for me to generate a list of hashes due to the .ini file size limitation in the free version.

 

@Cutting_Edgetech See here for download and instructions: https://www.wilderssecurity.com/thre...-tuersteher-light.359127/page-18#post-2523321

In your situation, you would want the elevated command prompt to run like this:

Code:

hash C:\ProgramData

The second part of the step (which has a manual step or two due to my lacking scripting abilities) you need to use either Excel or LibreOffice Calc to copy the SHA256 column. The second part of the script basically just removes duplicates and sorts the hashes to make it more efficient.

If you still have a copy of Bouncer that has the 20KB config limit, that would likely be sufficient if all you are wanting to hash is ProgramData. Sounds like a pretty logical idea as well.

 

I'm trying to figure it out. I tried running "hash C:\ProgramData" from an elevated command prompt, and it did not work. Should there be a space after hash?

 

Yes, the space is needed. The archive needs to be extracted. So for example, let's say C:\Hash or D:\Hash

Start elevated command prompt and navigate to Hash directory:

Code:

cd\
(pressing Enter after cd\)
cd hash
(pressing Enter after cd hash)
You will now be in the C:\Hash directory
or:
D:
(pressing Enter after D:)
cd hash
(pressing Enter after cd hash)
You will now be in extracted directory
Then that is where you run:
hash C:\ProgramData

Also ensure that nothing is blocking the executables from within that directory from running. They are old school open source GPL apps.

 

Would it be possible to get the fixed full version so that I can test? I was running a relatively large hash list (23000 entries) so I'm sure this could be a good test.

The area I am most confused about (or concerned) is how the hash and path based rules interect (ie: what takes priority over what). I just found it so confusing that my path based blacklist stopped working altogether when I added hashes to the config. I really wish the Admin Tool had more funtionality as I find it clumsy/akward to use. For instance, you can't maximise the window so you have to scroll around the rules and theres little feedback that Bouncer is working correctly (I only know for sure if I try to run something I know is blocked but I shouldn't have to check this continuously). Not complaining, just providing feedback that can hopefully assist to make Bouncer even greater than it is. I'm a minimalist and like Bouncers basic and powerful design but it just needs a few more features to make it really GREAT!

I'm really interested/keen to hear more about your script(s) to create the hashes. I'm even more keen to hear how one can (and should) maintain the hash list!

Is there an ETA for the fixed hash based stable version of Bouncer?

 

Thanks! Yea, I've been reading through the thread. I'm up to page 20, now.

Another question. So I'm on version 1.5.4 and I'm trying out the parent filters however it seems that it isn't interpreting them properly. I've included [PARENTWHITELIST] and [PARENTBLACKLIST] after my [BLACKLIST] entries and they show up as deny rules inside the Admin Tool. So I then moved my parent rules into the normal whitelist section (no other rules present) and I think it's interpreting the parent rules as standard rules, which happen to not break my system. Am I not on the right version for these rules to work?

My ini file:

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[PARENTCHECK]
[WHITELIST]
C:\Windows\*>*
C:\Program Files\*>*
C:\Program Files (x86)\*>*
[BLACKLIST]
*powershell*.exe
*regedit.exe
*iexplore.exe
*script.exe
*vbc.exe
*jsc.exe
*ilasm.exe
*csc.exe
*bitsadmin.exe
*hh.exe
*cipher.exe
*syskey.exe
*vssadmin.exe
*bcdedit.exe
[EOF]

 

I think there's a bug in Admin Tool. Here's my video, with graphics is better than words lol:
https://www.youtube.com/watch?v=khLRGzLdFkc&feature=youtu.be

 

@Mister X Yes, I can confirm this behaviour as well. I think that it has something to do with the timing of how often the driver polls the log file. I usually Stop, Clear Log, and Start driver fast as well and shows the red icon and have to click to view Log to go to regular status. However, just to test it out right now, I click Stop, Clear Log, then waiting a full 10 seconds and then pressed Start and this time the status was proper. It definitely a bug, some sort of timing issue. It turns red to indicate that there is a problem with the log file (log out of sync) which is what would happen if, for example, the log was delete or something. I can mention this to the developer and it should be an easy fix to change the timing of it. Thank you.

 

On the contrary, thank you for your kind support as Florian's spokesman
I and many in here really appreciate your help, priceless...

 

Well, I use this script (autoit). It hashs all executables found on any drive and writes filepath+filename,sha256-hash to file "hashes.txt". Sorry for my coding skills, it quick and dirty. Maybe some other users can help (and/or) improve. It is public domain, so do whatever you want with it:

Code:

#NoTrayIcon

#include <EditConstants.au3>
#include <WindowsConstants.au3>
#include <MsgBoxConstants.au3>
#include <GUIConstantsEx.au3>
#include <Constants.au3>
#include <WinAPIFiles.au3>
#include <Crypt.au3>

Global Const $CALG_SHA_256=0x0000800c

Global $hFileHashes = FileOpen(@ScriptDir & "\hashes.txt", $FO_APPEND)

; GUI
$idMainGUI = GUICreate("SHA256-List of EXE", 410, 180)
GUISetIcon(@SystemDir & "\SHELL32.dll", 23)

GUICtrlCreateLabel("Status:", 5, 10)
Local $idTextEdit = GUICtrlCreateEdit("", 5, 30, 400, 100, $ES_READONLY + $ES_AUTOVSCROLL + $WS_VSCROLL + $ES_MULTILINE + $ES_NOHIDESEL)
$idClose_Btn = GUICtrlCreateButton("Stop", 5, 140, 100, 30)

GUISetState(@SW_SHOW)

;Search and scan all drive for exe
$aDrive = DriveGetDrive("ALL")
If (IsArray($aDrive)) Then
    For $i = 1 To $aDrive[0]
        Search($aDrive[$i], "*.*")
    Next
EndIf


GUIDelete()

Func ProcessMessages()
  $iMsg = GUIGetMsg()
  Select
    Case $iMsg = $GUI_EVENT_CLOSE
        GUIDelete()
        Exit
    Case $iMsg = $idClose_Btn
        GUIDelete()
                FileClose($hFileHashes)
        Exit
  EndSelect
EndFunc

Func Search($current, $toFind)
  If StringRight($current,1) <> "\" then $current &= "\"
  Local $search_handle = FileFindFirstFile($current & "*.*")
  While 1
    ProcessMessages()

    $file_found = FileFindNextFile($search_handle)
    If @error Or StringLen($file_found) < 1 Then ExitLoop
    If StringInStr(FileGetAttrib($current & $file_found), "D") And ($file_found <> "." Or $file_found <> "..") Then
        Search($current & $file_found, $toFind)
    Else
       $sFileName = $current & $file_found
       $hFileHandle = FileOpen($sFileName, $FO_BINARY)
       If ($hFileHandle >= 0) Then
           GUICtrlSetData($idTextEdit, "Scanning '" & $sFileName & "'...")
           $tag = FileRead($hFileHandle, 2)
           If ($tag = "MZ") Then
               $imgHash = StringMid(StringLower(_Crypt_HashFile($sFileName, $CALG_SHA_256)), 3)
               FileWrite($hFileHashes, $sFileName & "," & $imgHash & @CRLF)
           EndIf
           FileClose($hFileHandle)
       EndIf

    EndIf
  WEnd
  FileClose($search_handle)

  ProcessMessages()
EndFunc

I thinks you could also use PowerShell (or WSciprt), but i am no expert. I like autoit

Todo: duplicate entries need to be removed, maybe @WildByDesign scripts can help here.

Additional note:

The result contains both filename and hash like:

C:\Windows\explorer.exe,094f76418d50bf771ff7dfad8384227f04e702c8b3795ad
C:\Windows\notepad.exe,7188189191919ad755b7a3e94f7d09de

For Bouncer you just need the hashes. I import the result file to excel, then export the hashes.

 

+1 @WildByDesign

 

@CrusherW9:

No, Admin Tool does not visualize normal white/blacklist and parentwhite/blacklist. This is confusing. As I understood the developer: The Admin Tool was just made to have something in place because too many people asked. He recommends to use notepad or notepad++ to edit the ini (I use notepad++ and I am happy, no need for the admin tool).

Your configuration is wrong, it should look like, for example:

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[PARENTCHECK]
[WHITELIST]
C:\Windows\*
C:\Program Files\*
C:\Program Files (x86)\*
C:\ProgramData\Microsoft\*
<ENTER OTHER PATHS TO APPLICATIONS AND DRIVERS IF NEEDED>
[BLACKLIST]
*powershell*.exe
*regedit.exe
*iexplore.exe
*script.exe
*vbc.exe
*jsc.exe
*ilasm.exe
*csc.exe
*bitsadmin.exe
*hh.exe
*cipher.exe
*syskey.exe
*vssadmin.exe
*bcdedit.exe
[PARENTWHITELIST]
C:\Windows\*>*
C:\Program Files\*>*
C:\Program Files (x86)\*>*
[PARENTBLACKLIST]
*cmd.exe>*calc.exe
[EOF]

I modified your list a little bit. If you have drivers in C:\OEM (C:\Intel) also add C:\OEM\* (and C:\Intel\*) to whitelist. Also add C:\OEM\*>* (and C:\Intel\*>*) to parentwhitelist. Just example, your paths can be different.

The example in blacklist just demonstrates that you can block calculator to start from command line promt (cmd.exe), but can be started with explorer.exe. give a try to better understand what is happening. At beginning bouncer looks cumbersome and confusing but it is very powerful with good overall performance (in contrast to other tools).

 

Aside from the extra entry in the blacklist, that is what I originally had. I updated my ini file with exactly what you have (minus the line about drivers) and I am still able to start calc.exe from the command prompt. I've restarted the driver multiple times and still no dice. I'm also on my laptop this time. Does the current public release support the parent feature or is it beta only?

EDIT: Hang on, none of the filters are working on my laptop....

 

I just wanted to clarify this particular point. The initial beta version from Beta Camp page where Parent Checking was first introduced, there was a bug in Admin Tool where anything in the Parent sections that was intended to be Allow rules were visually showing up as Deny. Behind the scenes, the driver was enforcing the rules appropriately and it was just more of a visual glitch. That had later been fixed after it was reported here at Wilders and so there was a newer build on Beta Camp page which had a fixed Admin Tool for that visual bug. But the important thing to note there is that the rules were still being enforced as intended even though the Admin Tool showed Deny for that certain section.

The current public release does not have parent check feature or the SHA 256 hashing. So it would be based upon the previous bouncer.ini config structure. The developer had to pull the current release that had the parent check and hashing feature due to a problem with the hashing, in particular with large hash lists.

So hopefully to clear up any confusion, that bouncer.ini config file structure was like this:

Code:

[#LETHAL]
[LOGGING]
[WHITELIST]
C:\Windows\*
C:\ProgramData\Microsoft\*
C:\Program Files\*
C:\Program Files (x86)\*
[BLACKLIST]
[EOF]

While the newer version (that is currently pulled) with parent checking and hashing features, config structure is like this:

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[#PARENTCHECK]
[WHITELIST]
C:\Windows\*
C:\Program Files\*
C:\Program Files (x86)\*
C:\ProgramData\Microsoft\*
[BLACKLIST]
[PARENTWHITELIST]
C:\Windows\*>*
C:\Program Files\*>*
C:\Program Files (x86)\*>*
C:\ProgramData\Microsoft\*>*
[PARENTBLACKLIST]
[EOF]

I just wanted to post the important differences between config file structures because it could cause significant problems if you were to use a newer config on an older version of the Bouncer driver, or an older config on a newer version of the Bouncer driver.

 

I personally don't have a copy that contains the fix just yet. Florian has confirmed to me that he has fixed it and is testing it on his end. I would recommend that you contact Florian (you will find his email on his blog http://bitnuts.de/), mention that you are a paying customer, but also make note that you are willing to do some testing and that you understand that there is a possibility for bugs when using a testing version, and he may hook you up with that to test it out. Especially since, if I remember correctly, you were the one that was able to bring this important issue out and have the developer fix it. I think that it's worth writing and asking him and of course mention that you understand any risks that could come with testing versions. But since you have a config setup already ready to do to test the fixed version, I think that is beneficial as well.

No worries, you have always been 100% respectful and I can relate to that and certainly appreciate it. I think that you and I share a similar view on much of this.

This is a tricky question. To be honest, I am afraid to even take a wild guess at this because I do not want to put any added pressure on the developer to rush the release. As excited as I am over any new Bouncer releases, I have to try to contain that more myself instead of passing that pressure along to the developer. That's definitely not your fault or anybody's fault, that's just my own fault. But I will say this, I do have 100% trust in his coding skills, coding efficiency, overall plans for Bouncer and so on. I have a feeling that he will surprise us all sooner rather than later this time. I know that the main thing holding back that release initially was the documentation. He did not want to release something with powerful new features and not have proper documentation to go along with it. That, along with English not being his first language. But since documentation is already complete, it is just a matter of putting the driver through some stress testing with the latest API fix to be certain it will be fine under any circumstance. One thing that actually surprised me with that release (although currently pulled) was that the PDF manual has really come a long way, was quite thorough and well polished and the best I had seen it yet.

But anyway, to sum things up, I will always update here first whenever I find out any new and interesting Bouncer-related details about releases, features, etc.

 

OK some good news! This morning, I received a last-minute-before-public-release private build from Florian that contains the fix for configs which have extremely long hash lists, only affecting users who would be doing full system hashing. This was to verify that this issue was fixed prior to public release and put it through some stress testing.

My testing config: Bouncer.ini is approximately 2.5MB and contains a little over 20,000 SHA256 hashes. My [WHITELIST] contains only hashes, no path based rules at all. As you can image, that is extremely risky because if I make any silly mistakes, it would cause significant problems without any path based rules to fall back on. But I wanted to put it through some solid testing.

So with that said, I performed many reboots, cold starts, etc. and ran many regular programs that I use often. Everything is working incredibly well. So the one other thing that I wanted to test is what @ParaXY brought up recently, I believe. That was including some path based rules in the [BLACKLIST] section to lock down certain programs such as: *powershell*.exe, *wordpad*.exe, *regedit.exe, etc. I can now confirm that those blacklist are successfully being blocked now. Blacklist has always taken priority.

The issue before was with the examples *powershell*.exe, *wordpad*.exe, *regedit.exe, etc. being in the blacklist as path based rules, but their corresponding hashes also happened to be in the [WHITELIST] section likely because of my full system hashing script just was pretty basic. So for whatever reason, the hashes were taking priority in the whitelist and over-riding the path rules in the blacklist. That is entirely corrected and fixed now which is absolutely great to see.

So I personally want to thank @ParaXY being so patient and respectful in bringing those hashing issues to light so that they can be fixed and so that the public release that was recently pulled will be available again soon. Also, I am absolutely thrilled in how Florian has been listening to feedback and many bug fixes have been reported here at Wilders and are now fixed thanks to users taking their time to report issues. Awesome job everyone!

I will let you all know when the public release is ready and available again. It's likely this weekend.

 

Thank you for the video. I already reported this to Florian quite some time ago, and if I remember correctly he informed me this was expected behavior. I would have to go back, and find his email to be sure what his reply was.

 

Is anyone else experiencing there browser freezing often? Mine is, and I think it could be one of rules i'm using with Bouncer. Below are the rules i'm using for Firefox. They are basically the ones that come by default for Chrome. I just made a few changes to them, and used them for Firefox instead. If I had to guess it would be the first one that could be causing the freezing problem since Firefox does save data to the User's directory. Btw.. I forgot to mention i'm using the latest beta. (edited 9:26 pm 10/22)

[PARENTBLACKLIST]
C:\Program Files (x86)\Mozilla Firefox\*>C:\Users\*
C:\Program Files (x86)\Mozilla Firefox\*>C:\Windows\Temp\*
C:\Program Files (x86)\Mozilla Firefox\*>*cmd.exe
C:\Program Files (x86)\Mozilla Firefox\*>*conhost.exe
C:\Program Files (x86)\Mozilla Firefox\*>*regedit.exe
C:\Program Files (x86)\Mozilla Firefox\*>*reg.exe
C:\Program Files (x86)\Mozilla Firefox\*>*rundll32.exe
C:\Program Files (x86)\Mozilla Firefox\*>*script.exe

 

Ok, got it, thank you.

 

No problem.

 

Can someone using windows 7 pro x64 share their ini?