It is a problem to unlink a process simply because you don’t know the value
that MS use to XOR the original pointer, but I suppose if you felt the
desire to take a swing at it then you might get lucky - someone will crack
it / workaround it (session 0 exploits e.t.c) since so many rootkits are
based on DKOM.
Although I don’t see much* need (unless you are writing something that
desperately needs to hide from attack) for this type of code in any
application.
*lest you be a rootkit discovery type of tool and are “prone” to attack, but
even in that instance, you may easily be found, and there are far wiser
methods of self protection than this technique.
Crispin.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@resplendence.com
Sent: Monday, July 07, 2008 18:53
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Newbie mistake? error C2065: ‘PsInitialSystemProcess’ :
undeclared identifier
Thanks for this info. I wish MS would be wiser than adding such half-baked
bonehead protection schemes. For a rootkit I suppose it must be no problem
to unlink a process and reXOR the list to set things straight. For a
security software that wishes to do a sanity check it simply becomes an
unfeasible task as it can easily crash and break with an update. If they at
least were using strong encryption but silliness such as this as well as
Patchguard (which can easily run for an hour before it detects a major
violation) only compromises our systems further and further.
//Daniel
“Crispin Wright” wrote in message
news:xxxxx@ntdev…
> Just out of interest - the Flink and Blink pointers in the EPROCESS
> struct
> for Vista onwards are XOR’ed specifically to stop people unlinking
> processes
> from the list in this fashion. A lot of online game cheats use this
> method
> in earlier versions of Windows…
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jehjoa
> Sent: Monday, July 07, 2008 13:01
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Newbie mistake? error C2065: ‘PsInitialSystemProcess’
> :
> undeclared identifier
>
> Well, I deleted the #include <wdm.h> line, and now it works! I knew it
> would just be a stupid little thing…
>
> About the UNICODE_STRING. I already figured that using %S was wrong,
> but when I looked at the docs for DbgPrint() I somehow completely
> missed that %wZ option… So I looked at the CRT’s printf() type
> specifiers, found nothing about UNICODE_STRING ofcourse, and thought:
> “Meh, I’ll figure this out later and use %S for now…” I guess I was
> lucky that pRegistryPath just happens to be zero terminated. 
>
> Yes, I know I have a lot of reading to do. What I have now is just the
> mere basics of the basics. I’m not even sure what PASSIVE_LEVEL is…
> Well I know it specifies an IRQL, probably the lowest one, but I don’t
> yet know how to figure out at which level my code is running. I’m
> slowly reading and learning, but this is just a hobby of mine… I
> also have a full-time job, other hobbies and a social life to
> maintain… 
>
> Anyway, you gave me a few great bits of info, David. Thanks for
> helping a newbie out. I will undoubtedly be back shortly with some new
> stupid questions!
>
> - Gerard
>
>
> On Mon, Jul 7, 2008 at 9:43 AM, David Craig wrote:
>> Also, why do you think that a UNICODE_STRING has a EOS (end of string)
>> terminator? It is not required and should NEVER be expected. You should
>> almost never refer to the ‘Buffer’ entry in a UNICODE_STRING. Look for
> %wZ
>> in the WDK docs. Note the requirement for PASSIVE_LEVEL. Also look at
> the
>> samples in the WDK for how to do a SOURCES file. Look at several,
>> especially those in a category of interest to you.
>>
>> “David Craig” wrote in message
> news:xxxxx@ntdev…
>>> It appears that wdm.h defines the same define that ntddk.h uses to see
>>> if
>>> it has been compiled in multiple times. The ‘old’ general rule is that
>>> you can only include ntddk, wdm, or ntifs. In the WDK you can include
>>> more than one and may have to some of the time, but order is critical.
>>>
>>> “Jehjoa” wrote in message news:xxxxx@ntdev…
>>>> Sorry, I should have made this clear in my first post. I am currently
>>>> using version 6001.18001 of the WDK, which I have installed in
>>>> C:\WinDDK. My sourcecode is in a folder called
>>>> D:\Code\Win32k\testsdrv, which contains the following files:
>>>>
>>>> SOURCES -
>>>> TARGETNAME=testsdrv
>>>> TARGETPATH=OBJ
>>>> TARGETTYPE=DRIVER
>>>> SOURCES=testsdrv.c
>>>>
>>>> MAKEFILE -
>>>> !INCLUDE $(NTMAKEENV)\makefile.def
>>>>
>>>> testsdrv.c - See my first post.
>>>>
>>>> XPSP3_x86_ntdefs.h - Pasted here: http://pastebin.com/f1ccf2f85. This
>>>> file is probably unrelated to the problem, but I thought I’d post it
>>>> for completeness sake.
>>>>
>>>> The way I (try to) build the driver is by starting a Windows XP x86
>>>> Checked Build Environment, navigating to the sourcecode folder and
>>>> typing build.
>>>>
>>>> Using Visual Studio for the build process seems like a very good idea,
>>>> especially if that allows me to use IntelliSense, so I will definitely
>>>> check that out. But as far as I know, the way I do it now should also
>>>> work, which would mean that the problem is in the code, somewhere…
>>>>
>>>> Thanks for the help so far!
>>>>
>>>> - Gerard
>>>>
>>>> On Mon, Jul 7, 2008 at 8:25 AM, David Craig
>>>> wrote:
>>>>> First, are you using Visual Studio to compile? If so, read the simple
>>>>> intros available on the internet to learn how to use the WDK build
>>>>> environments. Visual Studio can be used as an editor and can even
>>>>> invoke
>>>>> the build process if you use Mark Roddy’s ddkbuild.bat. There are
>>>>> detailed
>>>>> steps given on his web site. Do NOT skip any of the steps or try any
>>>>> shortcuts until you understand how it works and get it working
> correctly
>>>>> for
>>>>> a few weeks.
>>>>>
>>>>> “Jehjoa” wrote in message news:xxxxx@ntdev…
>>>>>> Hello everybody,
>>>>>>
>>>>>> First of all let me start by saying that I am new to OSR and Windows
>>>>>> driver development in general. I’ve been programming Windows
>>>>>> applications as a hobby for a few years now, but every so often I am
>>>>>> still stumped by some seemingly very simple problem.
>>>>>>
>>>>>> I have started writing a simple kernel mode driver to experiment with
>>>>>> things I read about in books and on the internet. Yesterday I decided
>>>>>> I wanted to try to hide a process by unlinking it from the linked
>>>>>> list
>>>>>> which starts at PsInitialSystemProcess.
>>>>>>
>>>>>> So, I spent quite a while getting info about EPROCESS and its
>>>>>> associated structures from WinDbg in kernel mode, and putting that in
>>>>>> a header file. After that I went to work on the C source file. It
>>>>>> only
>>>>>> has the DriverEntry function and the Unload function, so I’ll just
>>>>>> paste it here:
>>>>>>
>>>>>> #include <wdm.h>
>>>>>> #include <ntddk.h>
>>>>>> #include “XPSP3_x86_ntdefs.h”
>>>>>>
>>>>>> VOID OnUnload(IN PDRIVER_OBJECT pDriverObject) {
>>>>>> DbgPrint(“Unloading driver…\n”);
>>>>>> }
>>>>>>
>>>>>> NTSTATUS DriverEntry(IN PDRIVER_OBJECT pDriverObject, IN
>>>>>> PUNICODE_STRING pRegistryPath) {
>>>>>> EPROCESS * pepSystem = PsInitialSystemProcess;
>>>>>>
>>>>>> DbgPrint(“Hello Windows XP kernel world!\n”);
>>>>>>
>>>>>> DbgPrint(“Registrypath: %S\n”, pRegistryPath->Buffer);
>>>>>>
>>>>>> DbgPrint(“%s\n”, pepSystem->ImageFileName);
>>>>>>
>>>>>> pDriverObject->DriverUnload = OnUnload;
>>>>>>
>>>>>> return STATUS_SUCCESS;
>>>>>> }
>>>>>>
>>>>>> When I try to compile this, I get the error C2065:
>>>>>> ‘PsInitialSystemProcess’ : undeclared identifier message. The MSDN
>>>>>> docs state that PsInitialSystemProcess is defined in ntddk.h, and as
>>>>>> you can see I have it included. It is defined as: extern NTKERNELAPI
>>>>>> PEPROCESS PsInitialSystemProcess;
>>>>>>
>>>>>> From searching the header files I have figured out that NTKERNELAPI
>>>>>> is
>>>>>> just a #define for declspec(dllimport), and from googling I learned
>>>>>> that PsInitialSystemProcess is exported by NTOSKRNL.EXE. If I
>>>>>> remember
>>>>>> correctly, NTOSKRNL.EXE is automatically loaded with every driver
>>>>>> file, is that right? If not, does that mean I need to use the
>>>>>> kernelmode equivalent of LoadLibrary? Or am I completely on the wrong
>>>>>> track and did I just forget some stupid little thing?
>>>>>>
>>>>>> Any help would be very appreciated!
>>>>>>
>>>>>> - Gerard
>>>>>>
>>>>>> PS: I’m sorry if this message got a little too long… I just wanted
>>>>>> to show you guys that I’ve tried to figure it out by myself, but I
>>>>>> need some expert advice.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> —
>>>>> NTDEV is sponsored by OSR
>>>>>
>>>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>>>> http://www.osr.com/seminars
>>>>>
>>>>> To unsubscribe, visit the List Server section of OSR Online at
>>>>> http://www.osronline.com/page.cfm?name=ListServer
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>_____ Information from ESET NOD32 Antivirus, version of virus
> signature
> database 3246 (20080707)
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Information from ESET NOD32 Antivirus, version of virus signature
database 3247 (20080707) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com</ntddk.h></wdm.h></wdm.h>