Working on verison 3.00. Why jump to v3.00 now? Big change...
Will use SendTo shortcut to a single batch file that will allow blocking multiple files or/and files within folders at once (working on FORFILES command to process any hidden files).
Dropping WinFire options on the right-click main menu.
May add the shortcut to "Windows Defender Firewall with Advanced Security" for files and folders, but it will need to be manually added.
Most likely will drop the clear rules options. It is simple enough to sort and delete manually in "Windows Defender Firewall with Advanced Security". Update: I'll be adding it with a switch within tag option
Old WinFire will need to be removed with "uninstall.reg". There should be no registry changes required with v3.00
Last edit: Andrew 2018-06-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Winfire v3.10 is almost complete. It's turned into a beast of a CMD line batch script. Elevating with paremeters carried over by from local permission launched CMD.
It now displays all files, folders (searches for dll and exe files) and all files directed by shortcut and files found within shortcuts to folders (searches for dll and exe files). It displays them all in a clear format before more possibilities. Default tag for block, clr or del option to clear all existing rules, open file location for all direct files/folders or target location for shortcut file/folders.
It works on hidden and system hidden files without having to unhide them using a tested FOR loop with 'DIR /all hidden /subfolder' command.
This I believe is going to be the BEES KNEES of batch file file/folder Windows Firewall blocking scripts. Excited!
P. S. Still adding features and will test rigorously with file folder various names and locations. Cannot guarentee 100% effectiveness across all configurations especially where OS is concerned. This one's targeted for Windows 10 without any testing on previous Windows OS's.
I'll be adding that Winfire has no affiliation with Microsoft, Microsoft's subsidiaries any other product using the name or part thereof 'WinFire'. WinFire is a text file which is launch by Microsoft's CMD executable, is free for any use, is not to be sold and is definitely not a commercial product. It has no licence. It is simply lines of text processed by Microsoft's CMD executable within Microsoft Windows or emulated environment. Any content included within WinFire remain the property of their origin/owner and are not to be sold.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's important to state something right now. My previous batch/s file used a cmd line exe utility 'elevate.exe' either 32 or 64bit varients included in "elevate-1.3.0-redist.7z" downloadable from "http://code.kliu.org/misc/elevate/" dated 5-Mar-2011. That utility and my script/s where NOT MALWARE in any form. Yes, elevate.exe could've been used maliciously and I will allow sourceforge.net that credit. Now that I found, edited and provide a direct way for users to elevate the CMD prompt batch file with parsed paremeters, within clearly visible non melicious lines of basic text, I believe this to now not be falsely tagged as mALwARE.... see what I did there... AL ARE! or nothing? WinFire is now a legitimate Windows Firewall block rule creation utility and does not modify any registry data directly. It is all visable if you open the 'WinFire.bat' file with any text editor. It can create a shortcut in user SendTo folder. It can/will create two possible tmp text files; " dirlist.tmp" printed stdout from a DIR command within FOR loop/s and " list.tmp" printed from cmd stdout within FOR loop/s. Both the " dirlist.tmp" and " list.tmp" files as a basic text files are evaluated and used for the rule creation. It requires ELEVATION (and I believe this elevation only works with a user that has administrator access [primary user] / untested!) to create firewall rules primarily. Anything else it does is not malicious and not intended to be malicious in any form. Final word. If anyone from sourceforge.net actually read this far, please open the 'WinFire.bat' file yourself and evaluate it instead of just tagging it as "mALwARE" and pissing me off!
Last edit: Andrew 2018-06-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
WinFire v3.10 will no longer requests to sit within %HOMEDRIVE% (C:\WinFire), and will ask to be installed to Program Files using (%PROGRAMFILES%). Since the CMD exe on a 64bit OS runs as 64bit but can use 32bit commands, it will house correctly within "Program Files" either on a 32bit or 64bit OS. It is possible in the future to install to any directory, but for now it'll be "Program Files/WinFire/"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
v3.10 uploaded as RAR file. Needs to be extracted to Program Files manually. And WinFire.bat run manually. When adding it to a self-extracting archieve, Avast was detecting it as "Win32:Evo-gen [Susp]" most likely because of the elevation code and the fact the SFX was set to execute the batch file. So just review it yourself with a text editor and run it if you want. Update: Found that Avast only flagged as evo-gen when SFX was created with an SFX Icon. Found this... https://forum.avast.com/index.php?topic=142243.0
Nothing to do with the files, just Avast taking a shot at it cause it seems suspect for the file type and size. It's so small. I could pad it out and try that I guess.... edit... did not work
Might try using another SFX option such as 7zip
Last edit: Andrew 2018-06-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Will be trying Powershell in the near future to overcome the 8191 character limit (not an issue if your blocking a few folders containing millions of files)
Edit: I found a basic way to send all arguments (paths) to a text file for the batch to loop through. Instead of a complete rewrite using Poweshell with a cmd shell method for rule creation or some native Poweshell implementation I'm sticking with tried and tested CMD line.
Last edit: Andrew 2018-06-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
v3.20 now includes an Install File. Simply extract anywhere and run the install file.
The install file dynamically writes a VBS file that is used to write all arguments to text file.
The VBS launches WinFire.bat which asks for Elevation. WinFire.bat then uses the text file in for loops to create a dir.txt and file.txt. Those files are used to make the rules :)
8191 limit overcome :)
Last edit: Andrew 2018-06-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Forgot to change the version from 3.14 BETA to 3.20.
Issue is if you install WinFire into Program Files or other protected folder, the VBS will fail because it does not have the permission to write in that location. Installing to HOMEDRIVE\WinFire works.
To allow WinFire to work in Program Files:
1. Right-Click the WinFire folder and select 'Properties'
2. Click the 'Security' tab, scroll downand select 'Users (name\users)', click 'Edit'
3. Tick 'Full control' box under 'Allow'
4. Apply, OK and OK. Done
Last edit: Andrew 2018-06-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Simply going to notify user in Install_Winfire.bat that they need to manually run as admin to add shortcut. It's a one off. Actually 'they don't NEED to, they could create the shortcut manually. But then they'd actually have to manually make the vbs too first. There will also be notification about requirement to allow write access to folder permission of WinFire if it's in a folder like Program Files. Not going to force hack anything with that. Only reason WinFire requests elevation in function is to allow rule creation. And because it's done with a right-click option there isn't a way for the user to elevate it themselves. As I've said before, anyone concerned open any of the files in text editor and read what it does. Nothing malicious, but no need to just take my word for it.
Need to add a check while writing temp text files to ensure lines (paths) aren't already defined. Mostly if multiple shortcuts point to same directory or files. It wastes time relisting at the moment, I'll try to write something that takes less time too.
Update: So I have made the install ask for elevation and will change the permission for the folder. Didn't have to 'hack' anything it's pretty basic stuff.
Last edit: Andrew 2018-06-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Install_WinFire.bat" - Added Auto prompt ELEVATE cmd and Grant Users modify permission on the WinFire folder. Can now extract WinFire to any place, run Install and it 'should' work.
"WinFire.bat" - Added a check to see if files are already in the temp list, and not relist if found.
.
Anyone find any issues or have any suggestions?
Last edit: Andrew 2018-06-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Working on verison 3.00. Why jump to v3.00 now? Big change...
Old WinFire will need to be removed with "uninstall.reg". There should be no registry changes required with v3.00
Last edit: Andrew 2018-06-17
Winfire v3.10 is almost complete. It's turned into a beast of a CMD line batch script. Elevating with paremeters carried over by from local permission launched CMD.
It now displays all files, folders (searches for dll and exe files) and all files directed by shortcut and files found within shortcuts to folders (searches for dll and exe files). It displays them all in a clear format before more possibilities. Default tag for block, clr or del option to clear all existing rules, open file location for all direct files/folders or target location for shortcut file/folders.
It works on hidden and system hidden files without having to unhide them using a tested FOR loop with 'DIR /all hidden /subfolder' command.
This I believe is going to be the BEES KNEES of batch file file/folder Windows Firewall blocking scripts. Excited!
P. S. Still adding features and will test rigorously with file folder various names and locations. Cannot guarentee 100% effectiveness across all configurations especially where OS is concerned. This one's targeted for Windows 10 without any testing on previous Windows OS's.
I'll be adding that Winfire has no affiliation with Microsoft, Microsoft's subsidiaries any other product using the name or part thereof 'WinFire'. WinFire is a text file which is launch by Microsoft's CMD executable, is free for any use, is not to be sold and is definitely not a commercial product. It has no licence. It is simply lines of text processed by Microsoft's CMD executable within Microsoft Windows or emulated environment. Any content included within WinFire remain the property of their origin/owner and are not to be sold.
It's important to state something right now. My previous batch/s file used a cmd line exe utility 'elevate.exe' either 32 or 64bit varients included in "elevate-1.3.0-redist.7z" downloadable from "http://code.kliu.org/misc/elevate/" dated 5-Mar-2011. That utility and my script/s where NOT MALWARE in any form. Yes, elevate.exe could've been used maliciously and I will allow sourceforge.net that credit. Now that I found, edited and provide a direct way for users to elevate the CMD prompt batch file with parsed paremeters, within clearly visible non melicious lines of basic text, I believe this to now not be falsely tagged as mALwARE.... see what I did there... AL ARE! or nothing? WinFire is now a legitimate Windows Firewall block rule creation utility and does not modify any registry data directly. It is all visable if you open the 'WinFire.bat' file with any text editor. It can create a shortcut in user SendTo folder. It can/will create two possible tmp text files; " dirlist.tmp" printed stdout from a DIR command within FOR loop/s and " list.tmp" printed from cmd stdout within FOR loop/s. Both the " dirlist.tmp" and " list.tmp" files as a basic text files are evaluated and used for the rule creation. It requires ELEVATION (and I believe this elevation only works with a user that has administrator access [primary user] / untested!) to create firewall rules primarily. Anything else it does is not malicious and not intended to be malicious in any form. Final word. If anyone from sourceforge.net actually read this far, please open the 'WinFire.bat' file yourself and evaluate it instead of just tagging it as "mALwARE" and pissing me off!
Last edit: Andrew 2018-06-20
WinFire v3.10 will no longer requests to sit within %HOMEDRIVE% (C:\WinFire), and will ask to be installed to Program Files using (%PROGRAMFILES%). Since the CMD exe on a 64bit OS runs as 64bit but can use 32bit commands, it will house correctly within "Program Files" either on a 32bit or 64bit OS. It is possible in the future to install to any directory, but for now it'll be "Program Files/WinFire/"
v3.10 uploaded as RAR file. Needs to be extracted to Program Files manually. And WinFire.bat run manually. When adding it to a self-extracting archieve, Avast was detecting it as "Win32:Evo-gen [Susp]" most likely because of the elevation code and the fact the SFX was set to execute the batch file. So just review it yourself with a text editor and run it if you want.
Update: Found that Avast only flagged as evo-gen when SFX was created with an SFX Icon. Found this... https://forum.avast.com/index.php?topic=142243.0
Nothing to do with the files, just Avast taking a shot at it cause it seems suspect for the file type and size. It's so small. I could pad it out and try that I guess.... edit... did not work
Might try using another SFX option such as 7zip
Last edit: Andrew 2018-06-20
Just doing some tests on large set of files. Ran into limitation as 8,191 characters is maximum for CMD can accept on Windows 10. So maybe around 100 to 150 files/folders depending on path and filename lengths.
https://support.microsoft.com/en-au/help/830473/command-prompt-cmd-exe-command-line-string-limitation
Just fixed the SetLocal situation for checking shortcuts and file count in v3.13
Last edit: Andrew 2018-06-22
Will be trying Powershell in the near future to overcome the 8191 character limit (not an issue if your blocking a few folders containing millions of files)
Edit: I found a basic way to send all arguments (paths) to a text file for the batch to loop through. Instead of a complete rewrite using Poweshell with a cmd shell method for rule creation or some native Poweshell implementation I'm sticking with tried and tested CMD line.
Last edit: Andrew 2018-06-23
v3.20 now includes an Install File. Simply extract anywhere and run the install file.
The install file dynamically writes a VBS file that is used to write all arguments to text file.
The VBS launches WinFire.bat which asks for Elevation. WinFire.bat then uses the text file in for loops to create a dir.txt and file.txt. Those files are used to make the rules :)
8191 limit overcome :)
Last edit: Andrew 2018-06-23
Forgot to change the version from 3.14 BETA to 3.20.
Issue is if you install WinFire into Program Files or other protected folder, the VBS will fail because it does not have the permission to write in that location. Installing to HOMEDRIVE\WinFire works.
To allow WinFire to work in Program Files:
1. Right-Click the WinFire folder and select 'Properties'
2. Click the 'Security' tab, scroll downand select 'Users (name\users)', click 'Edit'
3. Tick 'Full control' box under 'Allow'
4. Apply, OK and OK. Done
Last edit: Andrew 2018-06-23
Simply going to notify user in Install_Winfire.bat that they need to manually run as admin to add shortcut. It's a one off. Actually 'they don't NEED to, they could create the shortcut manually. But then they'd actually have to manually make the vbs too first. There will also be notification about requirement to allow write access to folder permission of WinFire if it's in a folder like Program Files. Not going to force hack anything with that.Only reason WinFire requests elevation in function is to allow rule creation. And because it's done with a right-click option there isn't a way for the user to elevate it themselves. As I've said before, anyone concerned open any of the files in text editor and read what it does. Nothing malicious, but no need to just take my word for it.Need to add a check while writing temp text files to ensure lines (paths) aren't already defined. Mostly if multiple shortcuts point to same directory or files. It wastes time relisting at the moment, I'll try to write something that takes less time too.
Update: So I have made the install ask for elevation and will change the permission for the folder. Didn't have to 'hack' anything it's pretty basic stuff.
Last edit: Andrew 2018-06-24
v3.21
.
Anyone find any issues or have any suggestions?
Last edit: Andrew 2018-06-25