urbanware-org / wideredist

Windows Defender definition update tool for local network clients without internet access

WiDeRedist

Table of contents

• Definition
• Details
• Requirements
• Installation
• Contact
• Useless facts

---

Definition

Dedicated tool to update the Windows Defender definitions in the local network without client internet access via internal web server.

Top

Details

This project was not developed to lock out or even screw Microsoft, rather than for updating Windows Defender definitions (or signatures) in internal environments that are completely separated from the internet.

Nevertheless, this requires at least one system to access the internet, of course.

This tool currently takes advantage of a Linux server (or alternatively BSD) which downloads the definition files and redistributes them using a web server and the PowerShell on the Windows systems to obtain the definition updates from that web server.

Top

Requirements

The project does not have many requirements.

Server

• Either a Linux or BSD operating system
• Some web server such as Apache or nginx (latter has been used in development)
• The Bash shell (must be installed, but it does not have to be set as the default one)
• The following tools or packages:
  • curl or wget
  • file (optional, used to verify the MIME type of the downloaded files)
  • rsync

Client

• Windows 7 with Service Pack 2 or later versions with 32-bit or 64-bit architecture
• PowerShell 2.0 or higher

Installation

You can find the documentation containing the installation instructions and further information inside the wiki.

Please keep WiDeRedist up to date, as earlier versions may not work anymore. Usually, outdated versions should not be a problem, but in the past there was the case that WiDeRedist did not download the definition files correctly, obviously because of a change on the side of the Microsoft servers. Details can be found here.

Anyway, it is recommended to run either the server-side or client-side script manually once in a while. Since version 1.2.9 both of the scripts return if a newer version is available, unless the update check was disabled.

Top

Contact

Any suggestions, questions, bugs to report or feedback to give?

You can contact us by sending an email to [email protected] or by opening a GitHub issue (which I would prefer if you have a GitHub account).

Top

Useless facts

• The project name is an abbreviation for Windows Defender Definition Redistribution (the second and thus repetitive "De" from "Definition" was omitted).

Top

wideredist's Issues

Downloaded definition files are corrupt

The server side script fetches the definition files and returns that they have been successfully downloaded, however, the files are useless for the update, as they are HTML files containing the information that a user agent is missing.

Version check fails with errors of expecting unary operators

In some cases, the server-side script returns the following unary operator expected messages when checking for a new version (via check_version() function):

Proceeding with update of the definition files for redistribution.

/opt/wideredist/wideredist.sh: line 46: [: 1.4.4: unary operator expected
/opt/wideredist/wideredist.sh: line 64: [: -ge: unary operator expected
Process finished.
Elapsed time: 89 seconds

Client erroneously returns successful though the Defender update failed

After the Windows Defender update process has failed, the WiDeRedist client erroneously returns that the update succeeded. Apparently something is wrong with the evaluation of the return value of mpcmdrun.exe.

Installing definitions. Please wait, this may take a while.

> Windows Defender update process output
Signature update started . . .
ERROR: Signature Update failed with hr=800700D8
CmdTool: Failed with hr = 0x800700D8. Check C:\Users\ADMINI~1\AppData\Local\Temp\MpCmdRun.log for more information
< Windows Defender update process exited

Windows Defender definition update has been successfully completed.

Download only changed files from the internet

In order to avoid downloading all the definition files from the internet on every run, it would be good to check if the remote files have been changed (via timestamp) and only download those.

custom logfile location for clients

would it be possible to manually set the logfile location?

Separate config file for URLs on the server side

Maybe it would make sense to move the Microsoft URLs (from which WiDeRedist gets the definition files) into a separate config file e.g. wideredist.urls.

So, in case the URLs change for whatever reason, simply the URL file wideredist.urls needs to be replaced and the config file wideredist.conf can be kept untainted.

Since WiDeRedist is available for download, the URLs have already changed once which caused that WiDeRedist did not work anymore (the URLs were hard-coded in early versions). However, this should not happen very often.

Whether this makes sense would have to be considered. However, this has a low priority.

Enhance client side error handling and logging

Currently, there is basic error handling and logging, which should be enhanced. This applies to the server and client side.

The RecentUpdate.log log file created by WiDeRedist only contains the status information and details from the last run (is being overwritten after each run).

Furthermore, more specific return codes would make sense.

Option to ignore system-wide proxy on client side

In case a system-wide proxy is set inside the network preferences without bypassing local networks, the WiDeRedist client will not be able to download the files from the local server.

For this a corresponding option must be provided inside in the config file.

Automatically check for updates

In order to prevent a problem as in issue #2, an (optional) update check would be useful.

For example, the server side script checks the GitHub repository for a newer version and if the installed version is outdated, the server side as well as the client script will show a notice.

Use MIME type string to check type of downloaded file

Currently, the MIME type check of the downloaded file is being done as follows:

file -b "${file_name}" | grep -i "exe"

Instead, checking the MIME type string rather than the more traditional human readable one would make more sense:

file -b --mime "${file_name}" | grep -i "application/x-dosexec"

Script pretends to be already running

In some cases, the scripts pretend that they would already be running, even though, they are not.

The workaround by starting the scripts once again will temporarily fix it.

Add 'curl' as alternative download tool

So far, the server-side script of WiDeRedist uses wget to download all files and therefore requires it. However, curl might be added as an alternative.

Automatically update the PowerShell script

In case the server-side script is configured to automatically update WiDeRedist, it would also make sense to automatically distribute the update of the client-side script.

Comments inside the client config file

Inside the wideredist.conf file of the server side, there are comments on every option. It would make sense also adding such to the Update.ini file used by the client.

Version 1.6.0 seems to be broken

Version 1.6.0 seems to be broken.

Maybe the bash version is the problem.

With "bash version 4.2.46(2)-release / CentOS7" wideredist 1.6.0 works fine.
with "bash 5.1.4(1)-release / Debian11" wideredist 1.6.0 seems to be broken (Download failed).

Last working verion on bash 5.1.4(1)-release is widededist 1.5.3.

sorry my bad english.