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.
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