Bouncer (previously Tuersteher Light)

@kakaka Just to confirm, this is traditional 32-bit Windows XP?

My recent familiarity with XP is severely lacking.

Open an elevated Command Prompt and run:

Code:

sc query bouncer

What does it show?

Ensure that you have Bouncer.ini and bouncer.log within C:\Windows directory. If the installer failed on XP to copy those files there it would cause a problem. You can manually copy those files from the extracted installer if they are missing. You can use 7-Zip to manually extract the Bouncer installer package. The files needed would be in the 32-bit directory that was extracted.

Let me know whatever details you figure out and I am happy to help get this sorted out. If there are any XP-specific issues with the installer then I can speak with the developer to look into it more closely.

@Mister X You're welcome.

 

1. Installed with the installer
2. Bouncer.ini and bouncer.log in C:\Windows directory
3. sc query bouncer result

Kernel Mode Driver:

ini file size: ~1KBs (884 bytes)

SERVICE_NAME: Bouncer
TYPE : 2 FILE_SYSTEM_DRIVER
STATE : 1 STOPPED
(NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 127 (0x7f)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

4. net start Bouncer
starting...
System error 127 has occurred.
The specified procedure could not be found.

 

@kakaka Thank you for the details. I will talk with the developer about this XP situation tomorrow.

Here is one last suggestion before I head off for the evening.

Open Bouncer.ini in the Windows directory, but most importantly you will need to open Notepad (or Notepad++) as Administrator so that you can save within that directory.

Replace the content of your Bouncer.ini completely with the following:

Code:

[#LETHAL]
[LOGGING]
[#SHA256]
[#PARENTCHECK]
[WHITELIST]
C:\Windows\*
C:\Program Files\*
C:\Documents and Settings\*\Application Data\Microsoft\*
[BLACKLIST]
[PARENTWHITELIST]
[PARENTBLACKLIST]
[EOF]

This disables SHA-256 hashing just since it's a new feature and not sure how well tested on XP systems. Also modified User directory location for XP systems. But my idea here for testing purposes is to keep the config as simple as possible to see if the driver will start. Save that updated Bouncer.ini in Windows directory and now you can try net start bouncer in elevated command prompt again to see if that helps.

Regardless, I will bring this up tomorrow with the developer. Let me know if anything changes with your testing.

Also, just to rule any possibility out, are you running any other kernel level security software on your XP system?

 

I am sure that my setting is ok because Bouncer.sys signed on Dec. 21 2014 works on the same system.

 

Nope @kakaka , Windows XP and Vista are currently "out of the game". Parent checking feature in kernel makes use of API calls that are not available there. Dev. said: maybe he manages to find way in XP and Vista. If yes he will release special edition for xp and vista.

 

Then the manual (page 6) in the released package must be revised. "Made in Germany" should mean "Work as written".

 

It seems that the newly added module, Parent Checking, is not easy to use.
Consider the case that A.exe calls B.exe. What I expect is that, if both A.exe and B.exe have already been added to the whitelist, then A can always launch B even when we do not explicitly allow "D:\A.exe>D:\B.exe".
But...in my tests, it seems that such an explicit rule is still needed.

So, if you want to try the Parent Checking function, please REMEMBER to add the following rule first:

Particularly, if you did not add the first rule listed above before you enable the parentchecking function, then the tray icon of Bouncer will keep flashing, and you CANNOT even open the admin tool!
(@WildByDesign , I hope you could submit this problem to the developer at your convenience.)

By the way, for anyone who want to enable the parentchecking feature, I think you should explicitly allow all your security softwares (like your antivirus, firewall, anti-exploit, sandbox, virtual machine, etc) to execute anything in C:\windows\system32\* and C:\windows\winsxs\*.
Otherwise, you need to deal with block events that are much much more than expected.
In addition, I also suggest to explicitly allow C:\windows\system32\services.exe, C:\windows\system32\dllhost.exe, and C:\windows\explorer.exe to execute anything in the folders of your security softwares.

 

@Online_Sword: Only the case if you install tool not into C:\Program Files\*

If you leave everything where it is recommended to be (Bouncer at c:\Program Files\) then you do not need additional rule.

Yes, Sir It is mentioned in the manual that you should be careful. Nothing new?!!!! It was already there in beta. whitelist and parentwhitelist are different parts. in whitelist you specify what is allowed, in parentwhitelist you specify what parent is allowed to start child process. You cannot mix it with whitelist from a logical point of view - this would end it total chaos. It is different, so there are different parts to config.

As @WildByDesign already mentioned a lot of times: Do initial configuration with [#LETHAL], then check your config, adjust until it is fine tuned. Do it step by step. I have the feeling that a lot of people do not really understand the inner working of bouncer driver and start off with very complicated configuration. As we all know: this driver is for experts and not easy to configure, so take your time and read the manual! Step by step, again as @WildByDesign said lots of times: start with simple config, then add rules...

 

Hi, @4Shizzle .

Have you ever tried the newly added feature "parentchecking"?
I actually leave everything in the default folder, but I still need to add new rules to suppress the unlimited alerts.

Yes, I test the parentchecking feature with "[#LETHAL]", which will NOT block anything but just log events.
Please note that, the reason why I cannot open the admin tool is NOT because I use lethal mode, but because the tray icon keeps flashing.
I think you can test it: when the tray icon of Bouncer keeps flashing all the time, user cannot right click it to get the context menu.

 

Sure, but I did use other method of installation. Sorry, you are right, if you install with installer then there was behaviour you described. I sent e-mail to developer. My fault was that I used my rules from the beta, and tried default ini from Admin Tool, there everything was okay. With installer you are right

Sorry.

 

@4Shizzle , never mind.

Thank you for submitting this problem.

 

I seem to be having a strange issue with Bouncer. I installed the new version this morning (but I have also had this issue with the previous version). Sometimes after making changes to the bouncer.ini file (edting bouncer.ini with Notepad) my rules are ignored altogether.

In the beginning I thought Notepad++ may be upsetting the formatting of the entries so I started using regular notepad again but I am still having issues getting my rules to work on a consistent basis.

As an example, I have the following config in the new version of Bouncer:

Code:

[#LETHAL]
[LOGGING]
[SHA256]
[#PARENTCHECK]
[WHITELIST]
C:\Windows\*
C:\Program Files (x86)\*
C:\Program Files\*
C:\ProgramData\Microsoft\*
C:\Program Files\Bouncer\*
0014914051CB54CD7CC25561D29099A19DCFB2E1810FF635F9B6AD3D9C6FBC4B
(many more hashes but I just listed the above one for illustrative purposes)
[BLACKLIST]
C:\Windows\System32\Macromed\*
C:\Windows\SysWOW64\Macromed\*
*aspnet_compiler.exe
*csc.exe
*ilasm.exe
*jsc.exe
*MSBuild.exe
*vbc.exe
*script.exe
*iexplore.exe
*journal.exe
*msiexec.exe
*bitsadmin*
*iexpress.exe
*mshta.exe
*systemreset.exe
*bcdedit.exe
*hh.exe
*powershell*.exe
*reg.exe
*regedit.exe
*setx.exe
*flash*.dll
*flash*.ocx
*searchui*.exe
*onedrive*.exe
*onedrivesetup*.exe
*MicrosoftEdge.exe
*MicrosoftEdgeCP.exe
*vssadmin*.exe
*wordpad*.exe
[PARENTWHITELIST]
C:\Windows\*>C:\Windows\*
C:\Program Files (x86)\*>C:\Program Files (x86)\*
C:\Program Files\*>C:\Program Files\*
C:\ProgramData\Microsoft\*>C:\ProgramData\Microsoft\*
C:\Program Files\Bouncer\*>C:\Program Files\Bouncer\*
[PARENTBLACKLIST]
[EOF]

Now you'd expect that the bouncer.log would show logfile entries if I launched regedit or workdpad and yet I don't see anything in the log (using the above config)!

Can someone assist please? I am baffled. My bouncer.ini is ~2923KBs (2992646 bytes) and I have the full version.

Thank you!

PS: I know I am running in logging mode but I should still see entries for the blacklisted entries.

 

So I've just discovered something interesting. If I have:

Code:

[WHITELIST]
6A5A54754BD2E0F6557B0A8438640A6AD2016D6018DED951292C0ED157687C82 (this is the hash for Autoruns.exe)
[BLACKLIST]
D:\Software\Autoruns\Autoruns.exe

Then Autoruns.exe is allowed to run and it is NOT logged in the bouncer.log. Does this mean hashes take priority over path based rules?

Interestingly, if I blacklist the Autoruns.exe hash then the file is blocked and an entry is logged in bouncer.log.

I would have thought that ANY entry in the blacklist takes priority over a whitelisted entry...

I also thought that path based entries and hash entries could be used together.

 

Here is my parentwhitelist just for suppressing alerts:

Such a rule set is a little longer than 3KB (well now we have 20KB ).
But I think maybe we can reduce the length of it be replacing some rules with

Such kind of rules are not fine-granular. I am not sure whether such kind of rules are safe enough or not.
So I hope experienced users could give some comments.

 

Thanks @Online_Sword for sharing. I will dig into it and try to give feedback. @ParaXY: Well, you are right, it is odd. I sent developer an e-mail. He told me to find solution (fix).

My rules for parentchecking are (Windows 8.1, I do not use TrayApp or Admin Tool, just config via notepad.):

Code:

[PARENTWHITELIST]
C:\Windows\*>*
C:\Program Files\7-Zip\*>*
C:\Program Files\Common Files\*>*
C:\Program Files\Google\*>C:\Program Files\Google\*
C:\Program Files\Google\*>C:\Windows\*.dll
C:\Program Files\Google\*>C:\Windows\System32\winspool.drv
C:\Program Files\Google\*>C:\Windows\System32\bthprops.cpl
C:\Program Files\HTML Help Workshop\*>*
C:\Program Files\Microsoft Help Viewer\*>*
C:\Program Files\Microsoft Silverlight\*>*
C:\Program Files\Microsoft.NET\*>*
C:\Program Files\MSBuild\*>*
C:\Program Files\Reference Assemblies\*>*
C:\Program Files\Windows Defender\*>*
C:\Program Files\Windows Journal\*>*
C:\Program Files\Windows Kits\*>*
C:\Program Files\Windows Mail\*>*
C:\Program Files\Windows Media Player\*>*
C:\Program Files\Windows Multimedia Platform\*>*
C:\Program Files\Windows NT\*>*
C:\Program Files\Windows Photo Viewer\*>*
C:\Program Files\Windows Portable Devices\*>*
C:\ProgramData\Microsoft\*>C:\Windows\*
C:\ProgramData\Microsoft\*>C:\Program Files\*
C:\ProgramData\Microsoft\*>C:\ProgramData\Microsoft\*
C:\ProgramData\CanonBJ\IJPrinter\*>C:\ProgramData\CanonBJ\IJPrinter\*
C:\ProgramData\CanonBJ\IJPrinter\*>C:\Windows\*
*cmd.exe>C:\Windows\*.dll
C:\Program Files\Excubits\Bouncer\Tools\*>C:\Windows\*
C:\Program Files\Excubits\Bouncer\Tools\*>C:\Program Files\Excubits\Bouncer\Tools\*
C:\Program Files\Excubits\Bouncer\Tools\*>C:\Program Files\Common Files\*
C:\Program Files\Excubits\Bouncer\Tools\BouncerTray.exe>*chrome.exe
C:\Program Files\Google\Chrome\Application\chrome.exe>C:\Program Files\Windows Defender\*.dll
C:\Program Files\Google\Chrome\Application\chrome.exe>C:\Users\<YOUR_USERNAME>\AppData\Local\Google\Chrome\User Data\SwReporter\*\software_reporter_tool.exe
C:\Program Files\Google\Chrome\Application\chrome.exe>C:\Program Files\Common Files\microsoft shared\ink\tiptsf.dll
C:\Program Files\Google\Chrome\Application\chrome.exe>C:\Program Files\Windows Photo Viewer\PhotoViewer.dll
C:\Program Files\Google\Chrome\Application\chrome.exe>C:\Program Files\Windows Photo Viewer\PhotoBase.dll
[PARENTBLACKLIST]
C:\ProgramData\*>*cmd.exe
C:\Program Files\*>*script.exe
C:\Program Files\*>*bitsadmin.exe
C:\Program Files\*>*reg.exe
C:\Program Files\Google\*>C:\Users\*
C:\Program Files\Google\*>C:\Windows\Temp\*
C:\Program Files\Google\*>*cmd.exe
C:\Program Files\Google\*>*conhost.exe
C:\Program Files\Google\*>*regedit.exe
C:\Program Files\Google\*>*reg.exe
C:\Program Files\Google\*>*rundll32.exe
C:\Program Files\Google\*>*script.exe
C:\Program Files\Google\*>*powershell.exe
C:\Program Files\Google\*>a:\*
C:\Program Files\Google\*>b:\*
C:\Program Files\Google\*>d:\*
C:\Program Files\Google\*>e:\*
C:\Program Files\Google\*>f:\*
C:\Program Files\Google\*>g:\*
C:\Program Files\Google\*>h:\*
C:\Program Files\Google\*>i:\*
C:\Program Files\Google\*>j:\*
C:\Program Files\Google\*>k:\*
C:\Program Files\Google\*>l:\*
C:\Program Files\Google\*>m:\*
C:\Program Files\Google\*>n:\*
C:\Program Files\Google\*>o:\*
C:\Program Files\Google\*>p:\*
C:\Program Files\Google\*>q:\*
C:\Program Files\Google\*>r:\*
C:\Program Files\Google\*>s:\*
C:\Program Files\Google\*>t:\*
C:\Program Files\Google\*>u:\*
C:\Program Files\Google\*>v:\*
C:\Program Files\Google\*>w:\*
C:\Program Files\Google\*>x:\*
C:\Program Files\Google\*>y:\*
C:\Program Files\Google\*>z:\*
[EOF]

 

Excellent parentwhilelist and thank you for sharing this. I think that, together as a community, we can share and come up with some pretty nice rules here. I see that you have figured it out quite well now and you seem to understand that fine control as well which is great. I see now also the need for some of these rules to work properly with other security software and you've done really well figuring that out so far. Personally, I still need to explore parent checking feature more and practice with those rules.

This is a very interesting question. I know for sure that Blacklist takes priority over Whitelist for obvious reasons. But it seems that you have found out further that SHA256 hash rules seem to take priority as well, so that is interesting to know. Your testing seems to prove that theory. I will run that question by the developer later for clarification, but it sounds like you are right on that. I will do more testing later as well. My mind is just boggled right now at the amount of granular control that we have now. Thank you for sharing your findings as well.

 

It is unfortunate to learn that this latest kernel level feature of parent checking is not supported in XP or Vista. I think that the download page has been updated now to reflect that. I know that the developer did have good intentions of giving protection to users of XP. My hope is that the developer can still provide a download link for now for the most recent working version for XP users but also hopefully it will be possible to compile a version of the driver that leaves out the parent checking feature if that is what is causing incompatibility on that platform. I'm keeping notes on what I need to talk with the developer about in the next few days.

 

Looks like it could be a bug after speaking to the developer. I'm not sure how long the fix will take but if the hash list isn't too big it should work. I am trying to find out what sort of size hash list WILL work.

I've spent most of my day battling with the new version today so I am back to using just path based rules. I'll wait to hear more from Florian regarding an updated hashing version as this is where the magic lies!

 

My one issue above with rules not working had to do with me saving the bouncer.ini using ANSI rather than UNICODE. This could be quite dangerous as you could make a change to the config but there is literally nothing to tell you there is an issue with the config (Bouncer just ignores all rules). Surely there should be a notification that your config isn't working? Maybe an ORANGE coloured Bouncer icon to warn of this?

My next issue has to do with parent checking. I enabled it and set the rules to:

Code:

C:\Program Files\*>*
C:\Program Files (x86)\*>*
C:\ProgramData\Microsoft\*>*
C:\Windows\*>*
C:\Windows\*>C:\Windows\*

Nice and simpe to get started but as soon as I restart Bouncer the log goes crazy with (still running in #LETHAL):

Code:

C:\Windows\SysWOW64\cmd.exe > C:\Windows\System32\conhost.exe > 17009e5be64b2dde0797c990fa0da451b96d8e9cc85dec5bb0f9d62b7c74fad6
C:\Windows\System32\conhost.exe > C:\Windows\System32\wtsapi32.dll > c3539a3af749e16f616d033fcb3b11b5139be152b927213d24e85e54cfe0991f
C:\Windows\System32\conhost.exe > C:\Windows\System32\winsta.dll > 117aeec2c7ae6c7dbacbb77a67e1bf59ac8087784aebd72b3dd566288be9d371
C:\Windows\System32\conhost.exe > C:\Windows\System32\ConhostV2.dll > 93ee8d3c87777df87b4b2a0c41a8a2218e8461740ad22922bf480f0520b27e43
C:\Windows\System32\conhost.exe > C:\Windows\System32\propsys.dll > 46689e5e6f18b9a42bffc3552b8ba9c612195246727c88fbdc86f8793a3b9980
C:\Windows\System32\conhost.exe > C:\Windows\System32\uxtheme.dll > 3e30c6635601ee063ab920de23f641bf6b6779e54e8cda338472277872cd15e2
C:\Windows\SysWOW64\cmd.exe > C:\Windows\SysWOW64\apphelp.dll > af2b1ca788401af2c7763503fce96ac2f89d6eb30563070016e99220d2bd1838
1ed30701cf33621ed7d1fe27fdb33d11024ac557455cb80fe96d83f61500ebb0
C:\Windows\SysWOW64\cmd.exe > C:\Windows\SysWOW64\sc.exe > c31d04bf1dbca0b23b09d6d20d043c6e7944a1857eb515a8e9307c1b7a1853ab
82a78d84a2b29f207b4f5d38807e355786a351338c2f3a36b801017ffbf8fa01
C:\Windows\System32\conhost.exe > C:\Windows\System32\dwmapi.dll > a8224d3f6a191fd6ea133a8175aec5e0b3852e6a1ec11049c43202f096587019
C:\Windows\SysWOW64\cmd.exe > C:\Windows\SysWOW64\wininet.dll > 236e79e3208ece717925583f248b5c78d02fa2e9b13f6611f0a259008d9bc236
C:\Windows\System32\conhost.exe > C:\Windows\System32\wtsapi32.dll > c3539a3af749e16f616d033fcb3b11b5139be152b927213d24e85e54cfe0991f
C:\Windows\SysWOW64\sc.exe > C:\Windows\SysWOW64\apphelp.dll > af2b1ca788401af2c7763503fce96ac2f89d6eb30563070016e99220d2bd1838
C:\Windows\System32\conhost.exe > C:\Windows\System32\winsta.dll > 117aeec2c7ae6c7dbacbb77a67e1bf59ac8087784aebd72b3dd566288be9d371
C:\Windows\SysWOW64\cmd.exe > C:\Windows\SysWOW64\ntmarta.dll > cd130a019245b60fd4f8bb42ef8f1a860855ff30dd4aed9a20e15ed0e72e984a
C:\Windows\SysWOW64\cmd.exe > C:\Windows\SysWOW64\iertutil.dll > 645c21fe1f28c420625bc8efe980ed808544361a4e88a4730f7e6c867b5e7b4b
C:\Windows\SysWOW64\cmd.exe > C:\Windows\SysWOW64\apphelp.dll > af2b1ca788401af2c7763503fce96ac2f89d6eb30563070016e99220d2bd1838
1ed30701cf33621ed7d1fe27fdb33d11024ac557455cb80fe96d83f61500ebb0

This repeats dozens of times per second which I can't understand as I have a whitelist rule to allow these to run? Is this a bug or have I done something incorrectly?

 

It looks as though it gets very complicated when mixing SHA256 and Parent Checking together. For the time being, I would suggest disabling SHA256 while you are playing around with parent checking. Parent checking is pretty complicated on it's own so I would suggest mastering them one at a time before trying to combine them.

I was still trying to figure out your problem from earlier regarding the rules not applying. I'm glad that you figured out the source of the issue being the difference between ANSI and UNICODE. The good thing about Notepad++ is that you can change that sort of thing easily. But I see what you mean and there should be some way to protect against this, surely it would be possible from a development perspective. I know that the Admin Tool ensure UNICODE when it creates rules or edits rules, but you're right there should be a way to ensure someone editing their rules with Notepad doesn't end up with something different. I've never come across this before because I have always stuck with Notepad++ and always edited previously created bouncer.ini config files. So I can see this potentially happening though. I will bring this up with the developer soon and see if there is a way to protect/warn from this.

 

This is the one that I was trying to wrap my head around earlier today. But as I understand it, you realized later on that it had something to do with the hash taking priority over path based rules.

I see that you have regedit.exe and wordpad.exe in your BLACKLIST section which I understand what you are doing there. Now the part that I wanted to confirm is, do you have the SHA256 hashes for regedit.exe and wordpad.exe contained within your WHITELIST section? This is what I wanted to confirm first so that I understand what's happening there entirely. So as you were thinking earlier, the hashes were taking priority over the path based rules, is that correct? Thank you for taking your time to dig into this and report issues as well.

 

I'm going to try and explain this correctly because I have tried so many rules now that my head is spinning!

I have now disabled PARENTCHECK and am only (trying) to use SHA256 and path based rules. Mixing them (hash and path rules) seems to cause great confusion. Lets take blocking flash for example. In my old ruleset I had the following BLACKLIST set which worked perfectly to block flash system wide:

Code:

C:\Windows\System32\Macromed\*
C:\Windows\SysWOW64\Macromed\*
*flash*.dll
*flash*.ocx

To test this if I run an MKV video in Potplayer I would see a log entry to block flash.ocx every single time.

Jump forward to the new Bouncer version and if I set (with SAH256 enabled):

Code:

[WHITELIST]
Various path based rules
Various hash based rules
(so a mixture of both)
[BLACKLIST]
C:\Windows\System32\Macromed\*
C:\Windows\SysWOW64\Macromed\*
*flash*.dll
*flash*.ocx

This does NOT block Flash!! BUT! If I add the Flash hashes to BLACKLIST:

Code:

4DEEC8CBF9972930720B76F8FF8B5F6A2BE6E8F561AEC7B5D9A50080F68B22EB
1EA86F707DA40DA418FCD6EA55EE8AB667C1C0232925D21EF958A5E59634D1AE
F990A3130B94BA638FCA3900AFE4E6DFE2ACDE8E4A69BB77384FB241A1819BC2
B47AAEB6683A34AEF6F1ACC17BE0ED8FDF7EEBE3516D8FD5B67085C16646CA0A
C86A83CD11CF669B9FCC4DDB5EBE9D123CC79493AE93B60249EAC84296CBC7D6
3ED35E29A030F8C931717AA0F52F8DBF8CE87B05F91F103D05550EA11A256637

This will now block Flash!

So mixing and matching path based rules with hashes is VERY confusing. I hope someone can clarify this as I thought a blacklisted items took priority over ANYTHING else.

I hope this helps someone as it has had me stumped most of the day and I am still trying to fully understand the hashing rules. Wish the documentation went into more detail....

 

I have rolled back to path based rules only. There are too many inconsistencies and bugs with the mixture of hash and path based rules. Its almost impossible to understand whats going on, even with a simple ruleset for testing.

 

I have a question and I'll admit that I haven't looked through this thread so if it has already been brought up, I apologize. Anyways, I've been having some problems with Applocker straight up not working and so I've been using Bouncer for about a week now and so far it seems pretty great. However, I'll occasionally see the Bouncer tray icon popup a notification saying it blocked an exe in my downloads folder. It's actually been a few different exe's but they've all been legitimate things I've download (Git, GPU-Z, the bouncer installer, etc). The problem is, it wasn't me that attempted to run them. I was wondering if anyone else has seen this behavior since I've verified my PC is clean. I don't know, maybe when Windows was trying to index those files it somehow triggered Bouncer? Not really sure what else would cause that unless my browser is somehow being exploited (Chrome, and without EMET catching anything) and someone is for some reason trying to execute those programs, but you know, what are the odds of that...

 

@CrusherW9 : It sounds like Superfetch on Windows 7. This is not caused by Bouncer and was discussed here some times ago.