ntdll write protection preventing AppV hooking in Office 2016 32bit #21
Comments
|
Hi Michael, and thank you. Certainly ntdll-protect=0 can be set in Office settings. Another possibility is in-monitor exe path check similar to how browser hook modes are set, there is even a monitor yara sig that sets this option (IcedID). Still better might be to hook LdrpDetectDetour and enable this option in that hook - I will look into this last option and let you know how I get on. |
Jack28
pushed a commit
to Jack28/CAPEv2
that referenced
this issue
Aug 31, 2021
There is an issue regarding the "ntdll write protection preventing AppV hooking in Office 2016 32bit kevoreilly#21" in the capemon repository. kevoreilly/capemon#21 It states "Starting Winword and Excel 2016 32 bit with capemon loaded on recent Windows 10 quickly ends in an error message The operating system is not presently configured to run this application". "... in the unhooked Winword.exe, disassembly of ntdll exports contain hooks redirecting into module appvisvsubsystems32. In the monitored process, they do not"
Jack28
added a commit
to Jack28/CAPEv2
that referenced
this issue
Aug 31, 2021
There is an issue regarding the "ntdll write protection preventing AppV hooking in Office 2016 32bit kevoreilly#21" in the capemon repository. kevoreilly/capemon#21 It states "Starting Winword and Excel 2016 32 bit with capemon loaded on recent Windows 10 quickly ends in an error message The operating system is not presently configured to run this application". "... in the unhooked Winword.exe, disassembly of ntdll exports contain hooks redirecting into module appvisvsubsystems32. In the monitored process, they do not"
kevoreilly
added a commit
that referenced
this issue
Sep 7, 2021
|
This is now fixed - the monitor now checks process path and enables Office settings including disabling ntdll write-protection. Sorry it's taken me so long to publish this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Starting Winword and Excel 2016 32 bit with capemon loaded on recent Windows 10 quickly ends in an error message
The operating system is not presently configured to run this application:Enabling loader snaps shows that various DLLs can not be found:
... and so on for
mso30win32client.dll,mso40uiwin32client.dll,mso99Lwin32client.dlland more.Looking at the supposed location they indeed do not exist there. Instead they live at
C:\Program Files (x86)\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16.This is confirmed by looking at the loader snaps of an unmonitored
Winword.exein x32dbg which read:The mechanism behind that apparent redirection is reverse engineered and explained at https://lucasg.github.io/2018/08/22/magic-behind-appvisv/.
Indeed, in the unhooked
Winword.exe, disassembly ofntdllexports contain hooks redirecting into moduleappvisvsubsystems32:In the monitored process, they do not. This is likely explained by the following earlier debug output and exceptions:
This in my interpretation shows how
AppVIsvSubsystems32.dllis locating the exports of the functions it wants to hook and then trying to patch them, which is denied.In a jumping conclusion this lead me to
NtProtectVirtualMemorywhere I had seen anntdllprotection functionality. And indeed, settingntdll-protect=0inoptionsofanalysis.confof the CAPEv2 analyzer makes all the above misbehaviour disappear. Disassembly of thentdllentrypoints shows thatAppVIsvSubsystems32.dllis once again able to install its hooks and the loader snaps show the DLLs being loaded successfully from their actual locations. (Word and Excel still don't start up successfully but that seems to be an unrelated problem for another day.)Should
ntdll-protect=0perhaps become part of the specialofficesettings profile?Or could/should there be a more general detection of AppV Detour hooking attempts as explained in above article?
(I would suspect that 64bit Office suffers from the same problem but can not easiliy test that because the only workaround for #12 I currently have incidentally consists of disabling the hooking of
NtProtectVirtualMemorywhich also disablesntdllwrite protection.)The text was updated successfully, but these errors were encountered: