Windows Firewall Control (WFC) by BiniSoft.org

I've found v6.9.2.0 on wayback machine. It works like a charm!

 

Thanks for fixing "Notification exceptions" (although I can't use it right now). It's a really useful feature. Since this has been discussed in other firewall tools, maybe I can give my 2 cents to this from daily use and lots of reading.

1. It shouldn't be limited to Notification at all.
It should be a global filter to allow/disallow applications even in "Low Filtering", not only in "Medium Filtering".
The reason is that even in "Low Filtering" you might want to ALWAYS prohibit access to a programme. As it currently only applies to the notification, you would have to create a manual rule.

For example. I don't want to allow anything below this path - no matter if I'm in "Low Filtering" or not.
C:\Users\BillGates\AppData\Local\Programs\DOS-Chrome\

"Medium Filtering" would be too strict. So making the custom ruleset "global" would be a layer between those two settings.

2. Path-pinning would make it more secure
The problem is, of course, that the rules are either too narrow (e.g. version-dependent) or too broad (e.g. "curl.exe")
For example, malware could just name itself "ms-teams.exe" in "C:\bad\" and the exception "MS-TEAMS.EXE" allows it.

Many discussions have therefore come to the conclusion that wildcards would be useful (if not regex for advanced users).

Allow Microsoft Teams, no matter that version, but only in an expected directory:
C:\Program Files\WindowsApps\MSTeams_*\ms-teams.exe

Disallow Chrome and in a specific directory:
C:\Users\BillGates\AppData\Local\Programs\DOS-Chrome\*\chrome.exe

 

The purpose of the notifications is to create allow rules for blocked connections when outbound filtering is enabled (Medium Filtering profile). It was never intended to create block rules for when the outbound filtering is disabled (Low Filtering profile). The wildcards support requires important changes in code and the UI.

You can find old WFC versions in this topic.

Related to version 6.9.8.0 it didn't work at all on your machine? And there was no exception logged anywhere?

 

Yeah, it just was a summary of some wishes I've read in some forums and personal experience.

Perfect. That will help me.

No, really not... That's what nagged my half of the day. The old version immediately started without an issue. But now I can go through version by version and check, where it stopped working. I'll do it tomorrow, I had a hard day with public transport

 

Unfortunately, it didn't work, only very few versions are available in /old/

6900 - found
6920 - found
6940 - not found
6950 - not found
6960 - not found
6970 - not found

I'll try with the "Wayback Machine" archive again. Stay tuned.

GOOD NEWS! The archive has v6.9.4.0 (17.10.2023)
BAD NEWS: This one stopped working (blue exclamation mark of death; restarting system & service didn't work).

That's from the WFC log:

Code:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="WFC" />
  <EventID Qualifiers="0">200</EventID>
  <Version>0</Version>
  <Level>2</Level>
  <Task>0</Task>
  <Opcode>0</Opcode>
  <Keywords>0x80000000000000</Keywords>
  <TimeCreated SystemTime="2023-11-17T17:26:12.9275342Z" />
  <EventRecordID>3678</EventRecordID>
  <Correlation />
  <Execution ProcessID="0" ThreadID="0" />
  <Channel>WFC</Channel>
  <Computer>tobwen</Computer>
  <Security />
  </System>
- <EventData>
  <Data>Can't connect to Malwarebytes Windows Firewall Control service. The service is not running.</Data>
  <Data>Exception: System.MissingMethodException: Methode nicht gefunden: "System.Buffers.IBufferWriter`1<Byte> Grpc.Core.SerializationContext.GetBufferWriter()". bei WindowsFirewallControl.RpcServer.__Helper_SerializeMessage(IMessage message, SerializationContext context) bei GrpcDotNetNamedPipes.Internal.Helpers.SerializationHelpers.Serialize[T](Marshaller`1 marshaller, T message) bei GrpcDotNetNamedPipes.Internal.ClientConnectionContext.InitCall[TRequest,TResponse](Method`2 method, TRequest request) bei GrpcDotNetNamedPipes.NamedPipeChannel.CreateConnectionContext[TRequest,TResponse](Method`2 method, CallOptions callOptions, TRequest request) bei GrpcDotNetNamedPipes.NamedPipeChannel.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions callOptions, TRequest request) bei Grpc.Core.Interceptors.InterceptingCallInvoker.<BlockingUnaryCall>b__3_0[TRequest,TResponse](TRequest req, ClientInterceptorContext`2 ctx) bei Grpc.Core.ClientBase.ClientBaseConfiguration.ClientBaseConfigurationInterceptor.BlockingUnaryCall[TRequest,TResponse](TRequest request, ClientInterceptorContext`2 context, BlockingUnaryCallContinuation`2 continuation) bei Grpc.Core.Interceptors.InterceptingCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request) bei WindowsFirewallControl.RpcServer.RpcServerClient.Subscribe(Int32Value request, CallOptions options) bei WindowsFirewallControl.RpcServer.RpcServerClient.Subscribe(Int32Value request, Metadata headers, Nullable`1 deadline, CancellationToken cancellationToken) bei WindowsFirewallControl.Proxy.ProxyClient.Subscribe()</Data>
  <Data>Solution: Start Malwarebytes Windows Firewall Control service.</Data>
  </EventData>
  </Event>

Additional info:

Code:

==== Installed .NET Frameworks ====
.NET FW 2.0 SP 2 (CLR 2.0)
.NET FW 3.0 SP 2 (CLR 2.0)
.NET FW 3.5 SP 1 (CLR 2.0)
.NET FW 4.6.2 Windows 10 May 2020 Update(CLR 4.0)
.NET FW 4.7 Windows 10 May 2020 Update(CLR 4.0)
.NET FW 4.7.1 Windows 10 May 2020 Update(CLR 4.0)
.NET FW 4.7.2 Windows 10 May 2020 Update(CLR 4.0)
.NET FW 4.8 Windows 10 May 2020 Update(CLR 4.0)

I'm back on v6.9.2.0 now. Seems like one of the changes starting in v6.9.4.0 killed it for me.

 

In WFC version 6.9.3.0 I replaced WCF (Windows Communication Foundation) with GRPC for inter process communication. This is a major change in the code base which comes with many improvements and paves the way for future development. For some reason, GRPC does not work on your machine. Next WFC version will contain a newer version which may solve the problem that you have. I will try to reproduce this on my side. This is the first report about WFC not working with GRPC.

 

Perfect, thanks. If you want me to test any pre-release versions, I'm happy to do so. In the meantime, I'll have a look at what could be causing gRPC's problems here.

 

There you go:

wfc6950setup.exe
wfc6960setup.exe
wfc6970setup.exe

 

Please do not post unofficial links here. There is a reason why I did not keep these versions on the Binisoft server. The latest stable version is 6.9.2.0. The current stable version is 6.9.8.0.

 

Hi there (salut) Alexandru. I have a fresh install of WFC with secure profile, secure rules, generated recommended wfc rules on install. Everything is smooth, thank you for a great piece of software.

One thing i can not get rid of. I can not set these options. They turn on and off again.



Can you help me out?

These are on by default.

 

See this answer from here. The same applies to your use case.

 

Yes i understand, thank you, still i have to figure how to make this work. It is working but wfc is deleting those rules, even if i imported authorized groups so i still can not fix this.

 

The official links to the old versions should be available to the general public, e.g. located on the official website. If they are in your signature on this forum, it will help partially, as not all WFC users know about the existence of the forum.

 

Secure Rules has a bug in version 6.9.8.0 and does not work properly. A new version will be published soon which fixes this.

 

Windows Firewall Control v.6.9.9.0

Change log:
- Improved: When exporting rules, the sorting order and filters are now preserved in the exported wpw file. On import you get back what was seen in Rules Panel at export time.
- Improved: The import and the export of the firewall rules are fully async now. This improves the UI responsiveness during these actions.
- Fixed: When duplicating multiple rules at once, they are created in the reversed order.
- Fixed: Authorized groups list has a display issue where it displays also the internal group names.
- Fixed: When creating a duplicate rule in Rules Panel the Please wait message remains displayed and Rules Panel needs to be closed and reopened.
- Fixed: Secure Rules disables custom groups names in the latest version.

Download location: https://binisoft.org/download/wfc6setup.exe
SHA1: b1a241ddf22a84dab61981a8fe34b85aa65f49eb
SHA256: 81813cd194250c8b49d096ccd484c714ffa0fa5a56cec46b607c36878caaf613

Thank you for your feedback and your support,
Alexandru Dicu

P.S.: Sorry for the broken Secure Rules from the previous version. Please let me know if there are other problems with the this build.

 

Can you please test and let me know if WFC version 6.9.9.0 fixes the reported problem? Thank you.

 

Thanks for the try, but it didn't work here. I restarted the service and system, etc. - but always with the same result:

Since it affects my system only, please don't spend too much time on it.

"The pipe endpoint "net.pipe://localhost/binisoft/1bbc4e9a705d5008dcf1681af47162f6" was not found on the local computer."

Code:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="WFC" />
  <EventID Qualifiers="0">200</EventID>
  <Version>0</Version>
  <Level>2</Level>
  <Task>0</Task>
  <Opcode>0</Opcode>
  <Keywords>0x80000000000000</Keywords>
  <TimeCreated SystemTime="2023-11-20T15:04:28.2112413Z" />
  <EventRecordID>3719</EventRecordID>
  <Correlation />
  <Execution ProcessID="0" ThreadID="0" />
  <Channel>WFC</Channel>
  <Computer>tobwen</Computer>
  <Security />
  </System>
- <EventData>
  <Data>Can't connect to Malwarebytes Windows Firewall Control service. The service is not running.</Data>
  <Data>Exception: Der Pipeendpunkt "net.pipe://localhost/binisoft/1bbc4e9a705d5008dcf1681af47162f6" wurde nicht auf dem lokalen Computer gefunden.</Data>
  <Data>Solution: Start Malwarebytes Windows Firewall Control service.</Data>
  </EventData>
  </Event>

Code:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="WFC" />
  <EventID Qualifiers="0">200</EventID>
  <Version>0</Version>
  <Level>2</Level>
  <Task>0</Task>
  <Opcode>0</Opcode>
  <Keywords>0x80000000000000</Keywords>
  <TimeCreated SystemTime="2023-11-20T15:04:46.2825807Z" />
  <EventRecordID>3720</EventRecordID>
  <Correlation />
  <Execution ProcessID="0" ThreadID="0" />
  <Channel>WFC</Channel>
  <Computer>tobwen</Computer>
  <Security />
  </System>
- <EventData>
  <Data>Can't connect to Malwarebytes Windows Firewall Control service. The service is not running.</Data>
  <Data>Exception: System.MissingMethodException: Methode nicht gefunden: "System.Buffers.IBufferWriter`1<Byte> Grpc.Core.SerializationContext.GetBufferWriter()". bei WindowsFirewallControl.RpcServer.__Helper_SerializeMessage(IMessage message, SerializationContext context) bei GrpcDotNetNamedPipes.Internal.Helpers.SerializationHelpers.Serialize[T](Marshaller`1 marshaller, T message) bei GrpcDotNetNamedPipes.Internal.ClientConnectionContext.InitCall[TRequest,TResponse](Method`2 method, TRequest request) bei GrpcDotNetNamedPipes.NamedPipeChannel.CreateConnectionContext[TRequest,TResponse](Method`2 method, CallOptions callOptions, TRequest request) bei GrpcDotNetNamedPipes.NamedPipeChannel.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions callOptions, TRequest request) bei Grpc.Core.Interceptors.InterceptingCallInvoker.<BlockingUnaryCall>b__3_0[TRequest,TResponse](TRequest req, ClientInterceptorContext`2 ctx) bei Grpc.Core.ClientBase.ClientBaseConfiguration.ClientBaseConfigurationInterceptor.BlockingUnaryCall[TRequest,TResponse](TRequest request, ClientInterceptorContext`2 context, BlockingUnaryCallContinuation`2 continuation) bei Grpc.Core.Interceptors.InterceptingCallInvoker.BlockingUnaryCall[TRequest,TResponse](Method`2 method, String host, CallOptions options, TRequest request) bei WindowsFirewallControl.RpcServer.RpcServerClient.Subscribe(Int32Value request, CallOptions options) bei WindowsFirewallControl.RpcServer.RpcServerClient.Subscribe(Int32Value request, Metadata headers, Nullable`1 deadline, CancellationToken cancellationToken) bei WindowsFirewallControl.Proxy.ProxyClient.Subscribe()</Data>
  <Data>Solution: Start Malwarebytes Windows Firewall Control service.</Data>
  </EventData>
  </Event>

 

Well, well, look at that, i scratched my head until morning to fix network shares and wireless printing just to have 6.9.9.0 waiting for me as i woke up. Everything is working smooth now. Thank you so much for the update. I will report back with anything i find but right now with some default firewall rules and secure rules, my network and wireless printing is working ok.

 

Many thanks for fixing the exporting sorting order.

 

Yes, finally it is what you see is what you get (save). I will try to find a way to reorder the rules in Rules Panel and update the changes live.

 

Rules Panel - when the User created rules filter is enabled, Policies/Export all rules is a bit misleading because it seems it's actually exporting the User created rules. Basically, it always exports what you see (even if it's a couple of rules and all else is filtered out) so probably "Export all rules" needs adjusting.

 

Also, something is going on now with the import process because the sorting of the rules within the wpw file is not fully kept after import.

 

Export all rules means export all rules that you see in the list, not hidden ones.

The sorted column is not saved in the exported file and when you make an import there is no sort applied to any column. If you sort the rules ascending by Program, you see first the ones that apply to all programs, ending with the longest path. If you make an export with this sort applied, the order in the exported file is the one from the data grid. Next time when you reimport the file, you don't need so sort the rules by Program anymore since they are already sorted in the file and at import time. It works as expected. What you see is what you get. Whatever filters or sorting you apply, what you have in the view is what is exported.

 

Ok, this is hardly an issue. If I remember correctly, the "Export all rules" option previously exported all rules no matter what was visible (the now unsupported .wfw file) but I could remember it wrong. I still believe that "Export all rules" is quite different than "Export displayed rules" (which is what happens now) but that's just an opinion.

Changelog: On import you get back what was seen in Rules Panel at export time.

This is a bit more complicated, but I think I found what's going on. I'm not doing any sorting (column or whatever) within WFC. It seems that repeated delete/import is causing some issues. Not talking about 100 repeats, just one or two. Please try:

1. Enable Filter/User created rules
2. Select all rules and export them
3. Delete all current User created rules
4. Import back the .wpw
5. Verify if rule order is maintained and if total imported rule number is correct
6. Repeat steps 2-5 above a few times

If there are let's say 300 rules, what usually happens is that after import, rules 151-300 are displayed first and 1-150 at the bottom. If you keep deleting/importing, less rules will be imported and later 500+ rules might appear.

Not really a huge problem, but it seems quit/restart WFC is the only way to guarantee correct import after the first import process (or perhaps service restart, not sure). At least that's what I'm getting now.

 

I think this might happen because a few times, even if all rules seem successfully deleted they are actually not. A F5 refresh will reveal them back.