Why does this run net1.exe?

[xpdev]

Why does typing this run net1.exe?

Code: Select all

"n<z

C:\Windows\System32\net1.exe doesn't have any letter Z in it.
I set the PATH to just System32 and it still runs net1.exe
Same thing with:

Code: Select all

"n<l

[penpen]

The lower than ('<') is an undocumented wildcard, see:
viewtopic.php?t=6207.

On first look it seems as if that expression is able to match for characters not in filename after an '<'.
Actually i don't remember those rules in detail, but i'm not sure that should be possible.

A first dive into the analysis shows, that on my pc "net.exe" is called (which then starts "net1.exe") instead of directly "net1.exe".
You might check that with "Process Monitor" available at https://docs.microsoft.com/en-us/sysint ... ds/procmon.

Also the following commands all do that on my system (meanwhile i checked for all unicode characters now):

Code: Select all

"n<1"
"n<2"
"n<4"

"n<D"
"n<F"
"n<L"
"n<M"
"n<X"
"n<Z"

"n<d"
"n<f"
"n<l"
"n<m"
"n<x"
"n<z"

penpen


Edit: Added the last paragraph.
Edit2: Tested all Unicode characters. The above is the full list on my computer. Also removed the edit-notifications.

[penpen]

If someone wants to test that behaviour, then you need to copy the following original files (from C:\Windows\System32" to a test folder):

Code: Select all

net.exe
netutils.dll

However these files won't be able to execute "net.exe" with the strings in my above post.

Once you added files with the following names, you will be able to trigger that behaviour:

Code: Select all

net1.exe
netapi32.dll
netcfgx.dll
netdiagfx.dll
NetDriverInstall.dll
netfxperf.dll
netid.dll
netplwiz.dll
Netplwiz.exe
netprofm.dll
NetSetupShim.dll
netshell.dll
nettraceex.dll
Netwuw04.dll

None of these files need to be an original file, so an empty file with that name will do the trick.
You also don't need all files, as the existence of each single one of them is sufficient

I don't see, why those should be special - there are other files with filenames (without extension) also starting with an 'n' and ending in '1', '2', '4', 'D', 'F', 'L', 'M', 'X', 'Z', 'd', 'f', 'l', 'm', 'x', 'z', like:

Code: Select all

NL7Data0011.dll
NL7Lexicons0011.dll
NL7Models0011.dll
ntasn1.dll

I then thought that this behaviour might be caused by files starting with "net", but there are also some counterexamples:

Code: Select all

netbios.dll
NetCellcoreCellManagerProviderResources.dll
netcenter.dll

However those filenames that trigger the above behaviour are all files that start with "net" and end on '1', '2', '4', 'D', 'F', 'L', 'M', 'X', 'Z', 'd', 'f', 'l', 'm', 'x', 'z'.
I tested all other unicode letters - none other caused that behaviour in my tests.

It also seems like that the extension doesn't matter:

Code: Select all

net1.txt
net1.doc
net1.unknown

Also shortnames probably are not the cause, else i would have expected "NetSetupMig.log" (with short name "NETSET~1.LOG") to trigger "n<1".
A file with the long name "NETSET~1.LOG" enables "n<1" to call "net.exe".


I don't see any regularities i could blame for.
@all: Any additional ideas?


penpen

[CJM]

What's happening here has been nagging me for over a year now, with seemingly so random results I didn't even post about it because I couldn't even formulate how to say what I've been seeing. I finally took some time to test and observe on my current Windows 10 system (unless otherwise indicated). Here's what I found.

The undocumented wildcard characters < and >, mentioned here viewtopic.php?f=3&t=6207, appear to function as valid "command" execution wildcards, where the command can also be a filename launched by file type .ext association. As execution wildcards (prefixed with no specific path), the normal system sequence for searching executables is invoked, which includes the current directory, followed by the directories in the current PATH (https://docs.microsoft.com/en-us/previo ... h-sequence). When a matching file is found in one of these directories, only the "first" file is executed.

Which file is returned "first" is likely file-system-dependent, probably is affected by short8.3 names too. This makes wildcard command execution rather uncertain since there is a possibility of inadvertently invoking an unintended file which happens to match (and instead of) the intended file in the current directory or PATH.

Only < and > can be used within a command name, and only if quoted - escaping will not work.

I was able to successfully carat-escape the < and > wildcard characters, except when used as the first character.


EXAMPLES (with .ext specified)

Opening files:

• dx^<.txt
  Works on the wildcard search dx*.txt opening only dxdiag.txt found in the PATH
• setup^<.log
  Works on the wildcard search setup*.log opening the first matching file, setupact.log, found in the PATH. setuperr.log in the same folder is ignored.
• "<err.log"
  Works on the wildcard search *err.log opening the first matching file, setuperr.log, found in the PATH.

Starting notepad.exe:

• no^<.exe OR "no<.exe"
  Works on the wildcard search no*.exe finding only notepad.exe in the PATH which is executed
• no^>.exe OR "no>.exe"
  FAILS [ERRORLEVEL 9009 "'no>.exe' is not recognized as an internal or external command..."] on the wildcard search no?.exe in all PATH directories
• ^<pad.exe
  FAILS [ERRORLEVEL 1 "The syntax of the command is incorrect."] because the < and > characters as the first character are initially interpreted as redirection characters and therefore must be quoted in order to function as wildcard characters
• "<pad.exe"
  Works on the wildcard search *pad.exe finding only notepad.exe in the PATH
• ">pad.exe"
  FAILS [ERRORLEVEL 9009 "'>pad.exe' is not recognized as an internal or external command..."] on the wildcard search ?pad.exe in all PATH directories
• ^<^<^<^<pad.exe
  FAILS [ERRORLEVEL 9009 "<<<<pad.exe was unexpected at this time."] because the < and > characters as the first character are initially interpreted as redirection characters and therefore must be quoted in order to function as wildcard characters
• ">>>>pad.exe"
  Works on the wildcard search ????pad.exe finding only notepad.exe in the PATH

Starting cmd.exe:

• "cm<.exe" OR cm^<.exe
  Works because cmd.exe is my first file (of 5 present) returned from \Windows\System32\cm*.exe in PATH
• "cm>.exe" OR cm^>.exe
  Works because cmd.exe is my first (and only) file returned from \Windows\System32\cm?.exe in PATH
• "c<d.exe" OR c^<d.exe
  Works because cmd.exe is my first file (of 2 present) returned from \Windows\System32\c*d.exe in PATH. However,
  FAILS on my Windows2000 system, invoking instead clipbrd.exe which was the first matching file returned, subsequently removed from a later version of Windows.
• "c>d.exe" OR c^>d.exe
  Works because cmd.exe is my first (and only) file returned from \Windows\System32\c?d.exe in PATH
• "<md.exe"
  Works because cmd.exe is my first file (of 7 present) returned from \Windows\System32\*md.exe in PATH
• ^<md.exe
  FAILS [ERRORLEVEL 1 "The syntax of the command is incorrect."] because the < and > characters as the first character are initially interpreted as redirection characters and therefore must be quoted in order to function as wildcard characters
• ">md.exe"
  Works because cmd.exe is my first (and only) file returned from \Windows\System32\?md.exe in PATH
• ^>md.exe
  FAILS [ERRORLEVEL 1 "The syntax of the command is incorrect."] because the < and > characters as the first character are initially interpreted as redirection characters and therefore must be quoted in order to function as wildcard characters

At this point, everything I explained above applies to wildcard commands specified WITH the target extension.


Enter PATHEXT

Wildcard command execution goes awry when the extension is omitted, invoking search of PATHEXT for the first file found in one of the search directories. Again, which file is returned "first" is likley file-system-dependent, likely affected by short8.3 names too. When searching PATHEXE, (only) the first file found with the wildcard filter (internally appended with ".*") is used as the source to replace the number of characters in the original wildcard specification, meaning each < or > is replaced by a single character from the corresponding position in the returned matching file name. [EDIT 2021-06-28: To clarify, the wildcard search in each directory checked is appended with ".*", returning files with ANY extension which could end-up being the first file returned, and all other matching files are ignored.]

Due to the character replacement from the matching file that occurs when searching PATHEXT, I have not been able to successfully test the idea of matching either < or > wildcard on 0 characters (as mentioned in viewtopic.php?f=3&t=6207) since the PATHEXT search process will inevitably replace the wildcard character with the corresponding position from the first resulting file name found. Even if it were at the end of the name, the wildcard character is replaced with ".", resulting in a typically futile PATHEXT search: filename..com, filename..exe, filename..bat, etc.)

EXAMPLES with no extension (invoking PATHEXT search):

Starting notepad.exe via PATHEXT:

• ">>>>pad"
  Works on the wildcard search ????pad.* finding only notepad.exe in the PATH, and replacing each of the wildcard characters with the corresponding character before trying each as "notepad.PATHEXT" (notepad.com, notepad.exe [found and executed])
• no^< OR "no<"
  FAILS [ERRORLEVEL 9009 "'no<' is not recognized as an internal or external command..."] although it succeeds on the wildcard search no*.* in all PATH directories finding only notepad.exe in the PATH, when replacing each of the wildcard characters with the corresponding character before trying each "not.PATHEXT" this ultimately fails
• "no<<<<<" OR no^<^<^<^<^<
  Works on the wildcard search no*****.* in all PATH directories finding only notepad.exe in the PATH, and replacing each of the wildcard characters with the corresponding character before trying each as "notepad.PATHEXT" (notepad.com, notepad.exe [found and executed]) [EDIT 2021-06-28: As pointed out by penpen below viewtopic.php?p=64635#p64635, this actually fails to be found in \Windows\System32 due to the wildcard pattern returning a different file first, ultimately executed from \Windows instead]
• "note>>>" OR note^>^>^>
  Works on the wildcard search note???.* in all PATH directories finding only notepad.exe in the PATH, and replacing each of the wildcard characters with the corresponding character before trying each as "notepad.PATHEXT" (notepad.com, notepad.exe [found and executed])
• "n>t>p>d"
  Works on the wildcard search n?t?p?d.* in all PATH directories finding only notepad.exe in the PATH, and replacing each of the wildcard characters with the corresponding character before trying each as "notepad.PATHEXT" (notepad.com, notepad.exe [found and executed])
• "n<t<p<d"
  Works on the wildcard search n*t*p*d.* in all PATH directories finding only notepad.exe in the PATH, and replacing each of the wildcard characters with the corresponding character before trying each as "notepad.PATHEXT" (notepad.com, notepad.exe [found and executed])
• "n>t>p>d>"
  FAILS [ERRORLEVEL 9009 "'n>t>p>d>' is not recognized as an internal or external command..."] although it first succeeds on the wildcard search n?t?p?d?.* in all PATH directories finding only notepad.exe in the PATH, when replacing each of the wildcard characters with the corresponding character before trying each "notepad..PATHEXT" this ultimately fails
• "n<t<p<d<"
  FAILS [ERRORLEVEL 9009 "'n<t<p<d<' is not recognized as an internal or external command..."] although it first succeeds on the wildcard search n*t*p*d*.* in all PATH directories finding only notepad.exe in the PATH, when replacing each of the wildcard characters with the corresponding character before trying each "notepad..PATHEXT" this ultimately fails

Starting cmd.exe via PATHEXT:

• cm^> OR "cm>"
  Works because cmd.exe is my first (and only) only file returned from \Windows\System32\cm?.* in PATH
• cm^< OR "cm<"
  FAILS because cmcfg32.dll is my first file returned from \Windows\System32\cm*.* in PATH, resulting in PATHEXE being searched for each of (non-existent) "cmc.EXT" (cmc.com, cmc.exe, cmc.bat, cmc.cmd, ...)
• c^>d
  FAILS because cdd.dll is my first file (of 2 present) returned from \Windows\System32\c?d.* in PATH, resulting in PATHEXE being searched for each of (non-existent) "cdd.EXT" (cdd.com, cdd.exe, cdd.bat, cdd.cmd, ...)
• c^<d
  FAILS because cdd.dll is my first file (of 6 present) returned from \Windows\System32\c*d.* in PATH, resulting in PATHEXE being searched for each of (non-existent) "cdd.EXT" (cdd.com, cdd.exe, cdd.bat, cdd.cmd, ...)

Therefore it seems:

• To use < or > as execution wildcard characters, each must be escaped with ^ (but cannot be escaped when used as the first character, likely being interpreted as redirection characters)
• Quoting the command avoids the need to escape any < and > wildcard characters and allows their use as the first character.
• Upon matching a file using the normal PATH search, the first matching file found is executed, with "first" likely being file-system-dependent, probably skewed by short8.3 names too. Any remaining matching files from the same directory are ignored.
• if PATHEXT is invoked to find a matching executable file extension, each wildcard character is replaced with the first corresponding matching character(s) from the matching file name in order to build names paired with extensions from PATHEXT to match. This is true even if the resulting file matched a wildcard character on less than or more than one character; the wildcard character is still replaced with one character, meaning if the match occurs on zero characters at the end of the name, the wildcard character is replaced with "." making it likely that all PATHEXT matches will fail unless the matching file is unusually named filename..exe (which DOES get invoked if present!). It is likely that only single-character exact wildcard matches are possible for typical files when PATHEXT is invoked.

Code: Select all

"n<z

C:\Windows\System32\net1.exe doesn't have any letter Z in it.
I set the PATH to just System32 and it still runs net1.exe
Same thing with:

Code: Select all

"n<l

These are functioning equivalent to being fully quoted:
"n<z"
"n<l"

Also the following commands all do that on my system (meanwhile i checked for all unicode characters now):

Code: Select all

"n<1"
"n<2"
"n<4"

"n<D"
"n<F"
"n<L"
"n<M"
"n<X"
"n<Z"
...

I could only get these last characters to work on my system: 1 2 D F L M X Z, matching the following files:

• Net1.exe
• Netapi32.dll
• NetiD.dll
• NetfxperF.dll
• NetdriverinstalL.dll
• NetprofM.dll
• NetcfgX.dll
• NetplwiZ.dll

It's likely there's a matching file ending in "4" on your system. I do not believe the casing matters, and I didn't attempt to test anything Unicode.


To backtrack and determine why ????.exe (or ????.cmd) is being run by such a command:
1. Find the directory where you believe the resulting command was executed from (for net.exe, it's C:\Windows\System32)
2. DIR that directory using the same wildcard, but appending ".*": DIR "C:\Windows\System32\T<2.*"
3. The first file in that list likely was the matched file (I find that the so-called "first" file is also the same one that appears first in DIR with no ordering specified).
4. Starting with the character position of the original wildcard character, replace the wildcard character with the corresponding character from the matching file name (including, if necessary, the "." in ".ext") for the remaining length of the original string
5. To that, append each of the PATHEXT extensions in order until you find a matching file that exists in the same directory, which should be the one ultimately invoked.

Applying this to the OP's example (on my system): "n<z"
1. net.exe is in: C:\Windows\System32
2. DIR "C:\Windows\System32\n<z.*"

Code: Select all

	03/14/2021  07:30 PM           315,392 netplwiz.dll
	12/07/2019  05:08 AM            40,960 Netplwiz.exe
	03/14/2021  07:30 PM             6,144 normaliz.dll

3. Using the first matched file: netplwiz.dll
4. With the first wildcard in position 2, and the original command string, "n<z", length=3, replace the last 2 characters total "<z" from the same position as the matched file, in this case "et". Result: "net"
5. Append each PATHEXT to "net", and if the file exists in the same directory, invoke it. Since C:\Windows\System32\net.com normally does not exist, thus the invoke file was: C:\Windows\System32\net.exe

Bottom line: I do not see any way to take constructive advantage of this particular undocumented wildcard capability. The results vary widely depending on:

• The file system in use
• The mix of software installed, including versions of Windows Components
• The mix of files that happen to be in the current directory
• Possibly the order in which files were created in any given directory which happen to be in the PATH
• The wildcard specification used
• Whether the extension is specified or omitted, in which case PATHEXT search is invoked for a portion of the first matching file returned (with any extension) therefore making the result highly unpredictable.

Wildcard command execution is obviously an unintended (an unanticipated) capability since it only launches the "first" matching file found, and especially seeing how it functions so erratically once PATHEXE is involved.

[penpen]

It's likely there's a matching file ending in "4" on your system.

Yes, the file "Netwuw04.dll" ends on the character '4'.

Applying this to the OP's example (on my system): "n<z"

While i agree with most you said, there is a nitpick.
I have a file named "netbios.dll" in "C:\Windows\System32".
Therefore "n<s" should also trigger the execution of "net.exe" on my system,
but it doesn't.
(I also guess that probably is also true for your win10.)


penpen

[CJM]

While i agree with most you said, there is a nitpick.
I have a file named "netbios.dll" in "C:\Windows\System32".
Therefore "n<s" should also trigger the execution of "net.exe" on my system,
but it doesn't.

On your system, what is the FIRST file returned from: DIR "%Windir%\System32\n<s.*" If you follow the 5 backtracking steps I showed, does it result in net.EXE?

On my system, the first file returned (of 12 files, including netbios.dll) in DIR "C:\Windows\System32\n<s.*" is NarratorControlTemplates.xml
Replacing the wildcard to the end of the original string with the corresponding characters in the matching returned first file name would result in "nar"
Appending to that and searching PATHEXT: nar.COM, nar.EXE, ... which is ultimately not found.

[findstr]

Code: Select all

"no<<<<<"

Launches notepad.exe, but in the top left corner of notepad window the icon does not look like notepad's. Also in the taskbar, the notepad window does not have the notepad icon.

Code: Select all

"notepad.exe"

Launches notepad.exe with the normal notepad icon.

Maybe there are other side effects of "no<<<<<"?

[CJM]

... in the taskbar, the notepad window does not have the notepad icon.

Whoa! I didn't notice that. Good catch!

I'm betting the icon resource lookup doesn't recognize wildcards.

This extends to Task Manager's Details pane where if you look-up the Properties of that task, the Properties window also has the wrong icon. I thought the properties window was simply showing the properties of the image file ultimately launched. Apparently not.

[penpen]

On your system, what is the FIRST file returned from: DIR "%Windir%\System32\n<s.*" If you follow the 5 backtracking steps I showed, does it result in net.EXE?

On my system, the first file returned (of 12 files, including netbios.dll) in DIR "C:\Windows\System32\n<s.*" is NarratorControlTemplates.xml
Replacing the wildcard to the end of the original string with the corresponding characters in the matching returned first file name would result in "nar"
Appending to that and searching PATHEXT: nar.COM, nar.EXE, ... which is ultimately not found.

In my above post (viewtopic.php?f=3&t=9964#p64030) i created a test folder initially with the following files:

Code: Select all

:: copied from C:\Ewindows\System32
net.exe
netutils.dll

:: empty files
net1.exe
netapi32.dll
netcfgx.dll
netdiagfx.dll
NetDriverInstall.dll
netfxperf.dll
netid.dll
netplwiz.dll
Netplwiz.exe
netprofm.dll
NetSetupShim.dll
netshell.dll
nettraceex.dll
Netwuw04.dll

(You might also set the path variable to your test folder.)

Adding the file "netbios.dll" to that folder makes it the first listed using 'dir "n<s.*"', but it doesn't execute net.exe (at least on my system).


penpen

[penpen]

Code: Select all

"no<<<<<"

Launches notepad.exe, but in the top left corner of notepad window the icon does not look like notepad's. Also in the taskbar, the notepad window does not have the notepad icon.

I'm betting the icon resource lookup doesn't recognize wildcards.

According to "Process Monitor" (link in my first post in this thread) the command "no<<<<<" starts "C:\Windows\notepad.exe" instead of "C:\Windows\System32\notepad.exe".
When executing "C:\Windows\notepad.exe", you get that different icon.


penpen

Edit: My PATH variable contains ";C:\WINDOWS\system32;C:\WINDOWS;" in that order, so it should search system32 folder first... .
Edit 2: Checked the order (again with "Process Monitor"), which confirms the search order... .

[CJM]

Adding the file "netbios.dll" to that folder makes it the first listed using 'dir "n<s.*"', but it doesn't execute net.exe (at least on my system).

I tried your scenario, adding my \Test directory to the PATH before any \Windows paths, then I started with the current directory as %UserProfile%:

Code: Select all

>"n<s"
'"n<s"' is not recognized as an internal or external command,
operable program or batch file.

I then copied in all of the files you have listed, making the first and only file returned by the "n^<s.*" wildcard search to be netutils.dll which enabled net.exe to launch (even without Netbios.dll):

Code: Select all

>dir \test\n^<s.*
...
 Directory of C:\test

03/14/2021  07:30 PM            41,816 netutils.dll
               1 File(s)         41,816 bytes
---
>"n<s"
The syntax of this command is:

NET
    [ ACCOUNTS | COMPUTER | CONFIG | CONTINUE | FILE | GROUP | HELP |
      HELPMSG | LOCALGROUP | PAUSE | SESSION | SHARE | START |
      STATISTICS | STOP | TIME | USE | USER | VIEW ]

Then I copied in Netbios.dll, and it ended-up being first, which still worked:

Code: Select all

>dir \test\n^<s.*
...
 Directory of C:\test

12/07/2019  05:09 AM            18,944 Netbios.dll
03/14/2021  07:30 PM            41,816 netutils.dll
               2 File(s)         60,760 bytes
...
>path
PATH=C:\Test;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;...

>"n<z"
The syntax of this command is:

NET
    [ ACCOUNTS | COMPUTER | CONFIG | CONTINUE | FILE | GROUP | HELP |
      HELPMSG | LOCALGROUP | PAUSE | SESSION | SHARE | START |
      STATISTICS | STOP | TIME | USE | USER | VIEW ]

[CJM]

... executing "C:\Windows\notepad.exe", you get that different icon.

I just tried that, and it sure does. That's so weird, especially since it's a hardlink, effectively pointing to the SAME file!

Code: Select all

>fsutil hardlink list C:\windows\notepad.exe
\Windows\notepad.exe
\Windows\System32\notepad.exe
\Windows\WinSxS\amd64_microsoft-windows-notepad_31bf3856ad364e35_10.0.19041.746_none_4d13d847cecf0038\notepad.exe

[CJM]

... My PATH variable contains ";C:\WINDOWS\system32;C:\WINDOWS;" in that order, so it should search system32 folder first...

On my system as well, except if I DIR "C:\Windows\System32\no*****.*", the first file (of 11) returned is NOISE.DAT, causing PATHEXT to be searched for: NOISE.D.COM, NOISE.D.EXE, ... which all fail, so it moved on to the next PATH directory, C:\Windows, where notepad.exe is the first and only file returned from the wildcard search, and that IS found in the PATHEXE search, so THAT's the one invoked.

[kwsiebert]

... executing "C:\Windows\notepad.exe", you get that different icon.

I just tried that, and it sure does. That's so weird, especially since it's a hardlink, effectively pointing to the SAME file!

Code: Select all

>fsutil hardlink list C:\windows\notepad.exe
\Windows\notepad.exe
\Windows\System32\notepad.exe
\Windows\WinSxS\amd64_microsoft-windows-notepad_31bf3856ad364e35_10.0.19041.746_none_4d13d847cecf0038\notepad.exe

On Windows 7, these appear to be separate files rather than hardlinks, and there is no visible difference between them when run.

[penpen]

I rechecked the results for the "netbios.dll"/"n<s" on my system with a path set to the test drectory only:
Confirmed not executing "net.exe" in that scenario.
(Maybe it's somehow is connected with the fact that i upgraded to win10 prof from win8.1 - but that's a shot into the blue.)

Also, since "n<<<<<<" matches an ".exe"-file, i would expect "n<<<<<<.exe" to match the same executable, but on my system the first executes "C:\Windows\Notepad.exe" while the last starts "C:\Windows\System32\Narrator.exe".

I just checked a similar scenario, so all results are:
- "n>>>>>>" executes "C:\Windows\Notepad.exe"
- "n>>>>>>.exe" executes "C:\Windows\System32\nbtstat.exe"
- "n<<<<<<" executes "C:\Windows\Notepad.exe"
- "n<<<<<<.exe" executes "C:\Windows\System32\Narrator.exe"


penpen

Edit: Added the last paragraph.