How to start any program from the Command Prompt (cmd) or the Run dialog – “Sometimes My Genius… It’s Almost Frightening”

We’ve all been here before. We installed some application e.g. OpenSSL and you want to start the application in a directory other than where the OpenSSL executable is actually located. Bam! Error. You can resolve this by adding the folder where the executable is located to the PATH environment variable.

Error: ‘applicationName’ is not recognized as an internal or external command, operable program or batch file.


PATH is an environment variable on Unix-like operating systems, DOS, OS/2, and Microsoft Windows, specifying a set of directories where executable programs are located. In general, each executing process or user session has its own PATH setting.

Wikipedia – PATH (variable)

Well, that’s still not very clear on what it does. Basically, a PATH is a variable that can be set to directories in which executable programs are located so that it can be started without specifying the entire path to the file. This will work in the Command Prompt (cmd) and in the Run dialog in the Start Menu.

To do this you will have to go to the Environment Variables dialog to add new directories to the PATH variable. You can open Control Panel > System > Advanced > Environment Variables or I prefer the more simple method of running the following command in the Run dialog:

%windir%\System32\rundll32.exe sysdm.cpl,EditEnvironmentVariables

Select the PATH variable in the User variables list and click on Edit…

Click on New and add the directory path of where the executable is located. We will use OpenSSL as an example.

Click on OK to finish.

And we’re done! You’ve successfully added the OpenSSL bin directory, where the OpenSSL executable is located, to the Path variable. Now we can start OpenSSL from the Command Prompt or the Run dialog without specifying the directory path.

OpenSSL is able to start because the directory of where the executable is located is added to the PATH variable
CategoriesWindows Update

Windows Update 2020 July – DNS is as leaky as a basket

Microsoft released a patch for CVE-2020-1350, a Critical Remote Code Execution (RCE) vulnerability in Windows DNS Server that is classified as a ‘wormable’ vulnerability and has a CVSS base score of 10.0.

Let’s start with the vulnerability also known as SIGRed. According to the researcher Sagi Tzadik from Checkpoint Research, this bug existed for over 17 years and it’s an integer overflow vulnerability. What does this all mean?

The DNS service (dns.exe) in Microsoft Windows Server fails to validate a 16-bit register for a SIG Record. An attacker can exploit this and because the DNS Service runs under the SYSTEM context, remote code execution is a possibility or even granting Domain Administrator rights. The CVSS score of 10.0 means that this must be patched as soon as possible. As of writing, Microsoft confirms that the vulnerability hasn’t been exploited yet but I’m sure that this will change soon. A proof-of-concept has shown that this vulnerability can be exploited remotely through an HTTP payload to non-chromium browsers.

Affected Systems

  • Windows Server 2008 for 32-bit Systems Service Pack 2
  • Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core)
  • Windows Server 2008 for x64-based Systems Service Pack 2
  • Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core)
  • Windows Server 2008 R2 for x64-based Systems Service Pack 1
  • Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core)
  • Windows Server 2012
  • Windows Server 2012 (Server Core)
  • Windows Server 2012 R2
  • Windows Server 2012 R2 (Server Core)
  • Windows Server 2016
  • Windows Server 2016 (Server Core)
  • Windows Server 2019
  • Windows Server 2019 (Server Core)
  • Windows Server version 1909 (Server Core)
  • Windows Server version 1903 (Server Core)
  • Windows Server version 2004 (Server Core)


It is highly recommended to patch the affected Windows DNS Servers to prevent the exploitation of this vulnerability as soon as possible. The July update should already been made available in Microsoft Update and WSUS. See Microsoft’s Security Update Guide for more information regarding which security update you need. A system reboot is required after installing the update.


You can define a maximum length of a DNS message over TCP in the registry. Make sure to restart the DNS Service for the registry change to take effect.

Subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters 
Value: TcpReceivePacketSize 
Type: DWORD 
Value data: 0xFF00

You can also do the same by running the following command in an elevated command prompt.

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" /v "TcpReceivePacketSize" /t REG_DWORD /d 0xFF00 /f
net stop DNS && net start DNS

After applying the patch, you can remove the workaround by removing the TcpReceivePacketSize value and its corresponding data.