On 3/16/20 4:44 PM, Gabriel Ivăncescu wrote:
Hi Nikolay,
On 16/03/2020 15:21, Nikolay Sivov wrote:
On 3/16/20 4:05 PM, Gabriel Ivăncescu wrote:
I'm introducing an exported internal ntdll function, since I didn't want to duplicate the table for kernelbase. I don't know if this is the best way, so let me know if I should proceed differently.
I think custom export is unnecessary in this case. You only need a public ntdll call that returns unaltered version, that you can later clamp to Windows 8.1, unless manifest version is specified. Is RtlGetVersion() itself affected by manifest?
Only the functions changed by the patch series are affected. Just clamping to Windows 8 isn't going to work, consider the case where:
- We have Windows 10 prefix.
- Application only specifies GUID for Windows 8.1, not Windows 10.
- Returned Version must be Windows 8.1, not Windows 8 (no manifest).
The reason I exported it from ntdll was to have access to the version table there. Otherwise we'd have to duplicate the table from WIN8 and up.
It also makes it trivial to extend it, should Microsoft release new Windows versions: just add new GUIDs.
Guid/version mapping is not going to be used from ntdll, right? So far you'll only need to duplicate two 8.1 and 10, with a good chance that no version will follow as Windows continues to be 10. By the way if you set manifest entry to anything below Win 8.1 (Vista/7/8), does it affect reported version?
P.S. another question is if PEB fields are left intact.
Good question, I'll test it. Though of course it would be a separate patch if so.
Thanks, Gabriel