PDA

View Full Version : LINK: Bypassing PatchGuard on Windows x64


Kayaker
January 6th, 2006, 15:57
An interesting bit of analysis and reverse engineering for the RK fans here...

Bypassing PatchGuard on Windows x64

Abstract: The Windows kernel that runs on the x64 platform has introduced a new feature, nicknamed PatchGuard, that is intended to prevent both malicious software and third-party vendors from modifying certain critical operating system structures. These structures include things like specific system images, the SSDT, the IDT, the GDT, and certain critical processor MSRs. This feature is intended to ensure kernel stability by preventing uncondoned behavior, such as hooking. However, it also has the side effect of preventing legitimate products from working properly. For that reason, this paper will serve as an in-depth analysis of PatchGuard's inner workings with an eye toward techniques that can be used to bypass it. Possible solutions will also be proposed for the bypass techniques that are suggested.

http://uninformed.org/index.cgi?v=3&a=3&t=sumry

Kayaker

JMI
January 6th, 2006, 17:09
Thanks Kayaker. As always you find interesting things for us to read and consider.

Regards,

Opcode
January 6th, 2006, 17:49
Thanks Kayaker. It is really a very interesting article.

Kayaker
January 6th, 2006, 19:30
I suspected you'd find that interesting Opcode.

You may have noticed one of the other papers there referring to your own, er, kernel spelunkings as well

Cheers,
Kayaker

HAVOK
January 7th, 2006, 06:53
Also don't miss this one, from the same journal (website http://uninformed.org/index.cgi?):

Article: "Windows Kernel-mode Payload Fundamentals - bugcheck & skape"

Quote:
This paper discusses the theoretical and practical implementations of kernel-mode payloads on Windows. At the time of this writing, kernel-mode research is generally regarded as the realm of a few, but it is hoped that documents such as this one will encourage a thoughtful progression of the subject matter. To that point, this paper will describe some of the general techniques and algorithms that may be useful when implementing kernel-mode payloads. Furthermore, the anatomy of a kernel-mode payload will be broken down into four distinct units, known as payload components, and explained in detail. In the end, the reader should walk away with a concrete understanding of the way in which kernel-mode payloads operate on Windows.


The assembly snippets on the article are too optimized to be readable, but the descriptions are really interesting.

@Kayaker:

The article you mention is very interesting. I haven't a 64-bit processor myself and so i can't do much more than reading it, but it's important to find out how to get rid of the IDT/... protection.

Ok, some general comments about implications of the article:

As you (all) know, themida/xprotector has changed on its latest version. Now it hasn't ring0 protection any longer - it preserves the oreans32.sys driver, but it does more or less nothing -, instead they have moved to the horrendous VM. This has been done to preserve compatibility with the 64-bit windows, regarding the new protections described in the article mentioned by Kayaker.

However, themida happiness hasn't gone too far. The demo version has been cracked by a chinese guy *with the only help of OllyDbg*. This was unconceivable in previous versions, where one had to reload by hand the IDT, SST(shadow), hal.dll and ntoskrnl.exe in order to attach to the process.

I do hope the article you mention helps to get back to the ring-0 protection, as well as having the VM. It will also presumably help to port the rootkit technology to the new platform.

Thanks for the link

JMI
January 7th, 2006, 18:27
While visiting http://uninformed.org/index.cgi? one should also check out the contents of VOL 1 and VOL 2, by clicking the buttons at the top of the page.

VOL. 1 has titles such as:

Introduction to Reverse Engineering Win32 Applications

Post-Exploitation on Windows using ActiveX Controls

Loop Detection

Social Zombies: Aspects of Trojan Networks

While VOL. 2 has such articles as:

Temporal Return Addresses

Bypassing Windows Hardware-enforced DEP (Data Execution Prevention)

among others.

Regards,

Alorent
January 8th, 2006, 05:08
Nice article Kayaker

So, I guess that Regmon x64 also patch the SSDT, hence it should not work on latest Winx64? Well, maybe they also implemented techniques to bypass the PatchGuard...but I doubt it...

Kayaker
January 11th, 2006, 19:04
Quote:
[Originally Posted by Alorent]So, I guess that Regmon x64 also patch the SSDT, hence it should not work on latest Winx64? Well, maybe they also implemented techniques to bypass the PatchGuard...but I doubt it...

Hi

I had a look at the x64 version of the driver, which as usual is bundled as a resource with the main regmon file and can be dumped with a hex editor. Both the x64 and I believe the Server 2003 versions use the new functions CmRegisterCallback and CmUnRegisterCallback for operation, rather than hooking the SSDT as does Win2k/XP. So, PatchGuard isn't an issue for Regmon.

Code:

The CmRegisterCallback routine registers a RegistryCallback routine.

NTSTATUS
CmRegisterCallback(
IN PEX_CALLBACK_FUNCTION Function,
IN PVOID Context,
OUT PLARGE_INTEGER Cookie
);

Parameters
Function
Pointer to the RegistryCallback routine to register.
Context
Specifies the value to pass as the CallbackContext parameter to
RegistryCallback.
Cookie
Pointer to a LARGE_INTEGER variable that receives the value identifying the
callback routine. When you unregister the callback routine, pass this value
as the Cookie parameter to CmUnRegisterCallback.

This routine is available only on Microsoft Windows XP and later operating
systems.

A driver calls this routine to register a RegistryCallback routine, which is
called every time a thread performs an operation on the registry.

Call CmUnRegisterCallback to unregister a callback routine that was registered
by CmRegisterCallback.

Code:

The RegistryCallback routine runs every time a thread performs a registry
operation.

NTSTATUS
RegistryCallback(
IN PVOID CallbackContext,
IN REG_NOTIFY_CLASS Argument1,
IN PVOID Argument2
);

Parameters
CallbackContext
Supplies the value that was passed as the Context parameter to
CmRegisterCallback when you registered this RegistryCallback routine.
Argument1
Supplies the REG_NOTIFY_CLASS value for the registry operation. This value
specifies two pieces of information: the type of registry operation, and
whether the call to RegistryCallback is pre-notification or post-notification.
Argument2
Pointer to a structure that contains parameters specific to the type of
registry operation. The type of the structure depends on the
REG_NOTIFY_CLASS value in Argument1, as shown in the following table.

REG_NOTIFY_CLASS Value Structure Type
RegNtDeleteKey REG_DELETE_KEY_INFORMATION
RegNtPreDeleteKey REG_DELETE_KEY_INFORMATION
RegNtPostDeleteKey REG_POST_OPERATION_INFORMATION
RegNtSetValueKey REG_SET_VALUE_KEY_INFORMATION
RegNtPreSetValueKey REG_SET_VALUE_KEY_INFORMATION
RegNtPostSetValueKey REG_POST_OPERATION_INFORMATION
RegNtDeleteValueKey REG_DELETE_VALUE_KEY_INFORMATION
RegNtPreDeleteValueKey REG_DELETE_VALUE_KEY_INFORMATION
RegNtPostDeleteValueKey REG_POST_OPERATION_INFORMATION
RegNtSetInformationKey REG_SET_INFORMATION_KEY_INFORMATION
RegNtPreSetInformationKey REG_SET_INFORMATION_KEY_INFORMATION
RegNtPostSetInformationKey REG_POST_OPERATION_INFORMATION
RegNtRenameKey REG_RENAME_KEY_INFORMATION
RegNtPreRenameKey REG_RENAME_KEY_INFORMATION
RegNtPostRenameKey REG_POST_OPERATION_INFORMATION
RegNtEnumerateKey REG_ENUMERATE_KEY_INFORMATION
RegNtPreEnumerateKey REG_ENUMERATE_KEY_INFORMATION
RegNtPostEnumerateKey REG_POST_OPERATION_INFORMATION
RegNtEnumerateValueKey REG_ENUMERATE_VALUE_KEY_INFORMATION
RegNtPreEnumerateValueKey REG_ENUMERATE_VALUE_KEY_INFORMATION
RegNtPostEnumerateValueKey REG_POST_OPERATION_INFORMATION
RegNtQueryKey REG_QUERY_KEY_INFORMATION
RegNtPreQueryKey REG_QUERY_KEY_INFORMATION
RegNtPostQueryKey REG_POST_OPERATION_INFORMATION
RegNtQueryValueKey REG_QUERY_VALUE_KEY_INFORMATION
RegNtPreQueryValueKey REG_QUERY_VALUE_KEY_INFORMATION
RegNtPostQueryValueKey REG_POST_OPERATION_INFORMATION
RegNtQueryMultipleValueKey REG_QUERY_MULTIPLE_VALUE_KEY_INFORMATION
RegNtPreQueryMultipleValueKey REG_QUERY_MULTIPLE_VALUE_KEY_INFORMATION
RegNtPostQueryMultipleValueKey REG_POST_CREATE_KEY_INFORMATION
RegNtPreCreateKey REG_PRE_CREATE_KEY_INFORMATION
RegNtPreCreateKeyEx REG_CREATE_KEY_INFORMATION
RegNtPostCreateKey REG_POST_CREATE_KEY_INFORMATION
RegNtPostCreateKeyEx REG_POST_OPERATION_INFORMATION
RegNtPreOpenKey REG_PRE_OPEN_KEY_INFORMATION
RegNtPreOpenKeyEx REG_OPEN_KEY_INFORMATION
RegNtPostOpenKey REG_POST_OPEN_KEY_INFORMATION
RegNtPostOpenKeyEx REG_POST_OPERATION_INFORMATION
RegNtKeyHandleClose REG_KEY_HANDLE_CLOSE_INFORMATION
RegNtPreKeyHandleClose REG_KEY_HANDLE_CLOSE_INFORMATION
RegNtPostKeyHandleClose REG_POST_OPERATION_INFORMATION

Return Value

If the system made a pre-notification call to this routine, RegistryCallback
returns the NTSTATUS value that the system should return for the registry
operation. If the system made a post-notification call, the return value is
ignored.

To be notified of registry operations, a kernel-mode component (such as the
driver component of an anti-virus software package) can register a
RegistryCallback routine.

The system provides two types of notifications:

A pre-notification call to RegistryCallback indicates that a registry operation
has been requested. The system passes both the parameters for the
operation and the result of the operation in the Argument2 parameter to
RegistryCallback. The callback routine can modify the result, and the system
will use the callback routine's return value as the NTSTATUS value of the
operation.

A post-notification call to RegistryCallback indicates that the system has
attempted the registry operation. The system will ignore the callback
routine's return value. (If RegistryCallback returned an NTSTATUS error code
after a pre-notification call, the system will not attempt the registry
operation, nor will it make a post-notification call).

For Windows XP, the system only makes post-notification calls only when a
registry key is created or opened. For Microsoft Windows Server 2003 and
later operating systems, the system makes post-notification calls for every
registry operation.


Kayaker

Alorent
January 11th, 2006, 19:55
Thanks Kayaker for the explanation. I inmediatelly thought that a tool like Regmon could only be done hooking the SSDT on x64 also

Thanks!

omega_red
January 12th, 2006, 04:56
Very nice article, I was curious how that thing works but didn't have win64 to experiment on. You sneaky MS coders you!

nikolatesla20
January 12th, 2006, 08:33
Well at least for a short while people's Win OS will be safe from the "protect or reboot" realm of "protectors" that are trying to slowly crawl out of the primordial mud and show their ugly face...

-nt20

laola
January 12th, 2006, 09:25
Kayaker,

your post about CmRegisterCallback etc. led me to a fascinating idea. If I read the description right, this means that I can write and install a driver that can effectively hide parts of the registry (from XP on) without even hooking anything (checking the SSDT is commonly performed these days)? Great fun

nikolatesla20
January 12th, 2006, 12:26
That is some pretty neat new ability, especially where it says you can modify the value and then return a FAIL so just like Laola said you could basically "hide" a key that way. Fortunately at least it takes a driver to do so and isnt so simple anyone can hide themselves, but it means one more way for rootkits to work. Is there also a routine for querying the callbacks?


-nt20

laola
January 12th, 2006, 13:24
I'm not even aiming for a rootkit. Just a slightly more convenient way to hide my tools from prying eyes. Classic example: SoftICE I've found a lot of apps checking service entries and so on in the registry. If I don't have to edit these but can hide them with a simple little driver (I wrote a multi-purpose skeleton for that once upon a time, because it often comes in handy to have a look at the things under the hood), it will save me a bit of hassle

nikolatesla20
January 12th, 2006, 13:30
I cant find the documentation for this callback function in the Win2003 DDK...although I did find a small now-nonexistent cached copy of some of it on google. Kayaker, where did you get the details from?

I tried looking the the XP SP1 DDK help file and the Win2003 DDK help file and nowhere to be found.

-nt20

laola
January 12th, 2006, 16:06
Seems as if MS is currently shifting MSDN pages once more. Half of my bookmarks deliver 404, manual navigation works but the TOC looks much different now.
In addition, it seems that MS has updated the W2k3 DDK without changing the build number. My DDK install at work lacks certain 64bit files as well as a version of wdm.h with that function, the DDK that comes with the KMDF download has all of that. After integrating those DDK help files, I can even find the CMRegisterCallback function (and the others mentioned) in my Visual Studio context-sensitive help.

So I'd suggest to download the KMDF (200 meg ISO download) and install the most current DDK from the DDK folder of that ISO.
At present the download can be found here: http://www.microsoft.com/whdc/driver/wdf/KMDF_pkg.mspx

Kayaker
January 12th, 2006, 18:48
Have you EVER been able to find a page at the MS site where it's supposed to be? I used their search function after getting the 404 to find the defs.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh/Kernel_r/k102_ec214e13-1342-48b5-9a31-8c6c9da57cd6.xml.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Kernel_r/hh/Kernel_r/DrvrRtns_988f8f3d-4ee8-4351-8fc0-703a88bd8421.xml.asp