XP Firewall Control

[mgillespie]

I have done some modifications to UltraVNC, so it can control the Windows XP SP2 firewall, create exceptions for itself (and remove them when it closes).

Is this usefull to anyone? It is for me, as I always forget to create firewall rules, then wonder why I cannot connect!!!

Anyway, I have modified binaries (for x86 and x64) here:

http://www.markgillespie.co.uk/WinVNC_w ... ontrol.zip

They are compiled with Visual Studio 2005 (VC8), but seem to be working well for me here. I also replaced lots of strcmp strcpy and so on, with the new secure versions in VC8.

Rudi/Sam Do you want the source? Willing to donate my changes to the project, if they are useful.

[Rudi De Vos]

Looks interesting...

Special if we could add it as seperate app with the installer.
Firewall_control check registry vnc settings and open correct ports when you click.

Firewall control direct from vnc could trigger some spyware checkers.
If we add it direct in vnc, it need to be possible to enable/disable it. Some
people don't like apps messing with the firewall rules.

Was the 64bit driver working with your x64 port?

[pgmoney]

Looks interesting...

Special if we could add it as seperate app with the installer.
Firewall_control check registry vnc settings and open correct ports when you click.

Firewall control direct from vnc could trigger some spyware checkers.
If we add it direct in vnc, it need to be possible to enable/disable it. Some
people don't like apps messing with the firewall rules.

You can already add it to the XP firewall directly in the INNO Setup script and just make it an install option, no need for separate executables. I'll get some code to you when I get back to the office.

[mgillespie]

Looks interesting...

Special if we could add it as seperate app with the installer.
Firewall_control check registry vnc settings and open correct ports when you click.

Firewall control direct from vnc could trigger some spyware checkers.
If we add it direct in vnc, it need to be possible to enable/disable it. Some
people don't like apps messing with the firewall rules.

Was the 64bit driver working with your x64 port?

Driver seems to be working fine with my x64 port. It reports ACTIVE, and the performance seems to indicate it's working.

The only problem with having the firewall exception in the INNO script, is that if you change the ports, then the rules are no longer valid. Having them in the EXE means it always opens (and closes) the correct ports. It needs tidying, adding as a option etc.

I personally dont think it will trigger and spyware concerns, as quite a few apps already exactly this, (SmartFTP is one that instantly springs to mind). It's a valid, and documented Microsoft API.

[Rudi De Vos]

Having it in the inno script would already solve
"first time" use. (open 5900 and 5500)
It's frustrating when it don't work out of the box....
Do you have the inno code for this ?

We are slow moving to realvnc4 code base. Having a seperate exe would
integrate without code changes.
The exe can natural be easy called from vnc "system()", and integration as function " replace main" is also possible.

For the move we just try to work "initial" with seperate exe if possible.
Testing and bug fixing is a lot easier. When all is ok, the seperate exe
can be intergrated as independed functions or threads.

Driver x64:
It seems you made the correct char/wchar changes.
Did you #ifdef the changes so it still compile on VC60.
I also made the VS2005 port, but still need to verify the back compatibility
with VC60.

[mgillespie]

I didn't #ifdef stuff. I just compiled, and fixes the compiler errors, the quickest way possible, just to get it to compile. I fixed some of the easier warnings about deprecated CRT stuff, the rest I left alone...

I will knock up a Firewall control EXE , should be easy enough, take either remove or add as a commandline parameter, and looks at the registry to determine the current port in use. The only downside, is that the port rule could get out of sync, if port is changed mid-VNC session.

[Guest]

Adding an exception is preferable to opening a port because:

- It is easier to do.

-You do not need to know which port number to use.

-Adding an exception helps provide security, because the firewall is only
open while the program is waiting to receive the connection.

[mgillespie]

Thinking about it, I'm going to implement it as a DLL, If anyone has security concerns, they can remove the DLL, and the caller should be able to handle it's absense.