Windows Firewall Control (WFC) by BiniSoft.org

A little bug? When upgrading, Secure Profile always gets disabled.

Yes, I learnt that the hard way. BIOS update reset TPM and I had to reinstall Windows. For the record, wwahost.exe is also used by Netflix.
Also regarding this process, when block rule is in place, WFC ignores allow rule used to check for a digital signature. Not really needed, but.

EDIT: It seems that it is blocked even with no block rules in place.

 

Since the elevation in privileges comes from the bottom up

 

Thanks for the suggestions! Even after applying the rule, there's no change. The sandbox still cannot connect to the internet. When I switch to a low profile or restore the default Windows firewall rules, the sandbox regains connection

 

Thanks for the nice, new update! As mentioned earlier, I was not seeing the duplicates any more (in 6.9.9.4) most probably because I removed the Microsoft telemetry IP-range block rule. I will post back if they reappear.

About the new wwahost.exe/Windows PIN recommended rule in 6.9.9.5: I am not seeing it. Perhaps it is only available if that feature is present on compatible hardware?

I did not re-create the recommended rules during installation, but with "Restore recommended rules" in the Rules Panel.

 

Your website still says 6.9.9.4

 

Yes, I second that with bottom-up - then it would be perfect (for me).

 

When using the updater, Secure Profile remains enabled on my side. Do you uninstall first the existing version and then reinstall the new version?

It is always better to use two accounts if you use an online one. Always keep one local account accessible so that you can login to your own machine. I personally use only local accounts.

Custom allow rules, in some circumstances, don't work for certain system processes. The same applies for svchost.exe. I described in the user guide how you can find which rule blocked a connection, but is not an easy process.

Red does not work with Low Filtering profile, it does not work with No Filtering profile either. The contrast is not good between the colors. However, I could move the gray part the opposite way. Gray on top, color on bottom.

I updated the hashes, the date, but I forgot the version number. Fixed. Thank you.

 

With the new version, if you have a conflicting block rule you will not see duplicates rules anymore, because now the logic was extended to search the existing rules before creating an automatic rule.

You must recreate the WFC recommended rules. It should be here in the list:

 

Proceeding with a "clean" installation I get this message and it fails (with the 6994 completing normally)...

 

The rule which I recommended applies to UDP protocol and remote port 53. In your screenshot, your remote port is 5353 and 5355. Try to update that rule with these two extra port numbers.

The other rules which you created, to allow all connections, on any protocol, any port, for Dnscache service will not work. Service based rules must be more specific. Windows Firewall has some restrictions when it comes to allow connections for specific Windows services. DNS is supposed to work over UDP protocol. If you create a rule and set Any, this won't happen and the rule will be ignored. For example, inbound rules must be specific to a certain protocol. You will notice that none of the default Windows Firewall inbound rules are defined for Any protocol. This works only for outbound rules. And not always. Microsoft Windows services have some restrictions.

 

Indeed, let me fix it.

 

I am having a problem with v6995 on a clean install as well.

Once installer completes and I click "Run", I am left only with a tray icon with an "!" in it.

Tooltip of icon shows "Can't connect to Malwarebytes Windows Firewall Control service" - click on icon and it opens "Malwarebytes-WFC-User-Guide.pdf (binisoft.org)" https://binisoft.org/pdf/guides/Malwarebytes-WFC-User-Guide.pdf.

Clicking on created desktop shortcut does nothing.

Install of v6994 works as it should. Updating v6994 to v6995 via notification popup or install file works as it should.

 

@alexandrud

Bug with new WFC recommended rule (wwahost.exe).

There seems indeed a bug with your new recommended WFC rule (as @AmigaBoy mentioned), I also tried to recreate the WFC rules. NO such new rule as you described (for wwahost.exe).

 

Working on a fix. The current installer 6.9.9.5 has a problem with the extraction of the new service. After an update the service remains 6.9.9.4 on disk and 6.9.9.5 the tray app. Version 6.9.9.6 is coming out soon.

 

@alexandrud

Ahh, very good - thanks for clarification! No prob!

 

Windows Firewall Control v.6.9.9.6

Change log (same as 6.9.9.5):
- Fixed: When importing user settings the authorized groups list is not refreshed.
- Fixed: The experimental feature which auto creates allow rules for certain paths generates duplicate rules if a blocking rule prevents certain connections.
- Fixed: The tray icon does not offer any clue if the program runs in standard user mode or in elevated mode.
- Fixed: Learning mode tray context menu item remains disabled even after elevated rights are granted.
- New: Added a new WFC recommend rule for wwahost.exe which is required to reset a Windows PIN. Without this rule it is impossible to reset a Windows PIN.

Download location: https://binisoft.org/download/wfc6setup.exe
SHA256: accb7d4ccd9e6c5c1988c1bfe8015b2e459e52b3f8a965bd086a4746000524e6
SHA512: bd0b3ca576e5984d63f7eec9f9283abe8c2eddaf637f934c8d9811ef301f7a1927a78a0ca548f22aa1aa78788f20334f0cb275fa4662935f3a1ddc58014ba6bf

Thank you for your feedback and your support,
Alexandru Dicu

Sorry for the problem with version 6.9.9.5. It is something which I missed in code during my last commit. Now everything should be fine with this new build.

@Claudio R To make WFC installer not detect any WFC installation, you can use this command in an elevated CMD window:

reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Windows Firewall Control" /f

On the next WFC installer launch it will not detect WFC as installed anymore and will proceed on the installation path instead of the update path.

 

Perfect works perfectly (clean install)!!!

This command:
reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Windows Firewall Control" /f
Is it appropriate for this version or more generally for every subsequent installation?

Thanks for your attention anyway...

 

Installer 6.9.9.5 was not updating the service on the update path and for a clean installation did not extract the service on disk at all. This command was for your specific use case with the broken installer 6.9.9.5. It should not be required in other situations.

Thank you for confirming that the new installer works as expected.

 

OK Tnx

 

@alexandrud

All good now, thank you for fast fix!

 

After reviewing the log entries, it seems that the problem is not related to port 5353, but rather to ports 67 and 68 being blocked. I tried adding each log entry as a rule, but unfortunately, it didn't solve the issue.
I did notice that resetting to the default Windows firewall rules fixes the issue, but it's still unclear which specific rule is causing it.

 

Edit: Fixed in v6996

 

Ports 67 - 68 look like the DHCP rule. I am pretty sure it is a rule issue. It works with outbound filtering enabled on my side.

 

1. Is there any documentation regarding "the experimental notification exception feature"?
2. Or to be more precise, will it handle ninite spawned exe-files in the temp folder while in medium filtering mode?
   I get it, that it is bad behavior on ninite's part, still I use that on a regular basis.

Thanks anyways for that great program.

 

See the User Guide at the end of page 19, or search in PDF by keyword experimental