Previously, server 2016/19 was not correctly detected and falsely
reporting as vulnerable, because the check was overly trusting the
reported OS name - see PR #355 for a description of the problem.
Furthermore, I discovered a self-introduced bug in the regex of build
detection, which would in some cases first match on '2016' and not the
build number, which would be less than the five-digit build number for
the forseeable future.
Testing data included in PR comments.
Feedback from @bwatters-r7
Feedback from adfoster-r7
Testing of detection:
```
msf5 exploit(windows/local/ms16_075_reflection_juicy) > check
[*] Target appears to be patched or not vulnerable (Windows 10 (10.0
Build 18363).)
[*] The target is not exploitable.
```
Testing of (forced) nil-case:
```
msf5 exploit(windows/local/ms16_075_reflection_juicy) > check
[*] Reloading module...
[!] Could not determine Windows build number - exploiting might fail.
[*] The target is not exploitable.
```
This addresses issue #12698, where the Windows OS and build was not
being parsed correctly due to changes in the client.sys.config lib.
Tested against Windows 10 (patched):
```
msf5 exploit(windows/local/ms16_075_reflection_juicy) > rcheck
[*] Reloading module...
[-] Target appears to be patched or not vulnerable (Windows 10 (10.0
Build 18363).)
[*] The target is not exploitable.
```
This commit changes a few things:
1. The module first writes the dll to a
temp location.
2. The module writes a batch file to a
temp location.
3. The batch file copies the dll until
the copy command fails (presumably
because the dll is now in use by
PrintIsolationHost.exe).
4. The dropped files are deleted.
5. Docs updated to reflect changes.
Thanks to @tsellers-r7 for testing XP and producing output to compare
against. Without a 32-bit test, the architecture guess was incorrect.
Additionally, product type had yet to be determined. The trailing bytes
were indeed significant! Thanks, Tom!
bwatters-r7