Bypassing PatchGuard 3

2:16 27 Jan '09

The story that “malware is able to bypass PatchGuard” is something strange.
I never saw a signed virus. And even if so, there is no way to do something against it if malware already is in the kernel.
In this case you just lost the fight. Malware instead should NEVER get into the kernel.

Malware should never get into kernel, but it can - simply by dropping exploitable signed driver.
Therefore the whole PatchGuard is broken.
Security companies want to go into kernel to do behavioral analysis on an user-mode malware, which is the most popular.

2:43 27 Jan '09

>"simply by dropping exploitable signed driver"

I don't think that this is simple... BTW I didn't say that malware can not get into the kernel, I it shouldn't be able to. Tp prevent this is microsofts duty and if you look at their singularity project (or something similar may work too) you will know how its done. Give us some years and we have a secure kernel...

And after all; As I said if malware already is in kernel-mode, you seriously lost the fight! There is simply no need for security at this level... And PatchGuard 3, if modified continously, will provide the only thing you can do in such a case. Detect the malware and restart the PC...

> Therefore the whole PatchGuard is broken.

If microsoft continues to update patchguard on a regular basis, it will be almost impossible for malware to target a broad range of PCs with countless different PatchGuard implementations.

>Security companies want to go into kernel

They still can, but not on end-user PCs. They just have to enable kernel debugging and PatchGuard is vanished.

regards
chris

6:46 27 Jan '09

I totally agree, that malware shouldn't be able to get into kernel, but it is. When the kernel is at the same level as drivers, you can't do anything. There won't be countless different PatchGuard implementations. This project is too "system deep" to update it in regular basis. Host based security software is a must, when systems are configured by users, not by experienced admins. regards, Jakub
Sign In·View Thread·PermaLink

7:04 27 Jan '09

> This project is too "system deep" to update it in regular basis

Microsoft could easily setup some of the approaches I described in my article, so that there will be nearly no maintainence overhead for regular upates... There is no need to change the whole patchguard logic... It is much easier to defnend code that tries to bypass patchguard!

> Host based security software is a must

Yes of course... But are not talking about having host security or not... The subject is about host security hacking itself into the kernel. But I am not alone Wink

. I just wanted to agree with microsoft step to protect the kernel against third party hacks. The kernel is still accessible in A DOCUMENTED manner by using the patchguard API or the new windows filtering platform etc... And as you see there is plenty security software out there protecting 64- Windows without nasty kernel hacks...

regards
chris

12:23 27 Jan '09

> Microsoft could easily setup some of the approaches I described in my article, so that there will be nearly no maintainence overhead for regular upates

There are so many ways to bypas PatchGuard, that any predefined approach will fail. It's a typical "war against detection" approach, that AV companies do. Moreover, you can hook the kernel without changes in actual code, that can be verified. Changing only pointers that are used by kernel (which are much harder to verifiy) you can get most of the control over OS.
Hiding symbols is not the solution (relatively simple to disasm) and using the morphing engine is unacceptable because of many reasons (f.e. digital sign).

> The kernel is still accessible in A DOCUMENTED manner by using the patchguard API or the new windows filtering platform

which is not enough to protect from a user-mode malware, while kernel-mode malware can bypass PatchGuard Smile

> And as you see there is plenty security software out there protecting 64- Windows without nasty kernel hacks

Yes, but 64 bit Windows security software is much more limited than 32 bit versions. It's not enough. In fact I'm a bit surprised that Symantec has acquired WholeSecurity or AVG that acquired Sana. They won't be able to do anything on 64 bit Vista/Windows 7, and... that's the future.

regards,
Jakub

23:33 27 Jan '09

> using the morphing engine is unacceptable because of many reasons (f.e. digital sign)

Microsoft doesn't need to sign the windows kernel... A combination of such code morphing and random invokation stubs will do the work...

> while kernel-mode malware can bypass PatchGuard

But you can't honestly say that one can protect a system from such malware if it is already in the kernel...

> They won't be able to do anything on 64 bit Vista/Windows 7, and... that's the future.

Microsoft will improve the documented part of such kernel hacks in future versions.

BTW... Do you have any proofs that 64-Bit system are more affected by malware than 32-bit?

The point is that if malware is in the kernel, you lost the fight... To create a solid user-mode-kernel barrier is the only approach which will prevent malware from getting in there... And I am very optimistic that in some years, Microsoft will introduce a managed kernel (Singularity Project) written in their OS extended C# language, with isolated processes and separation through hypervisor. And from there on, malware will be a thing of the past!

Please get me right Wink

. I am not saying that the current situation is a good one. But Microsofts only chance to ever get the kernel secure is to lock out all third party hacks and then start to redesign it from scratch, by keeping all documented stuff available even if through compatibility layers!

regards
chris

23:37 27 Jan '09

I personally think that the main reason for introducing PatchGuard was a compatibility thing. The jump from 32 to 64 bits was the only chance in history, where fundamental shifts could be made. By introducing PatchGuard Microsoft somehow "bought" an option to delay this shift, by locking out third party from the kernel. This will provide Microsoft the chance to redesign the almost 15 year old code Big Grin

1:36 28 Jan '09

> Microsoft doesn't need to sign the windows kernel... A combination of such code morphing and random invokation stubs will do the work...

If the code was morphed and not signed, you wouldn't be able to verify it.

> you can't honestly say that one can protect a system from such malware if it is already in the kernel

Yes, but the problem is that PatchGuard limits only security vendors with the current "two rings system" architecture.

> Microsoft will improve the documented part of such kernel hacks in future versions

Will improve... or will not. The range of improvements is also unknown. Currently there is no long-time expected new KPP API.

> Do you have any proofs that 64-Bit system are more affected by malware than 32-bit?

64bit market is much smaller than 32bit and on 64bit many 32bit malware works fine on WOW.
It's also impossible to prove that statement, because it's not possible to test well enough behavioral blockers.

> And from there on, malware will be a thing of the past!

You are too kernel oriented.... Malware doesn't need to work in kernel to be a malware. 99% of malware today doesn't use any kernel-mode components.

regards,
Jakub

Discussion about kernel mode hooking

3:33 28 Jan '09

> If the code was morphed and not signed, you wouldn't be able to verify it.

That's true but I doubt the ntoskrnl.exe is currently signed at all... And also I don' see any need to do so. BTW, why should you be unable to sign the morphed code? I mean the thing is simple:

1) Let the compiler put random invokations stubs into the windows source code (based on a user defined seed).
2) Sign the thing, if it is currently signed at all...
3) publish it...

But okay Wink

.

> Yes, but the problem is that PatchGuard limits only security vendors

I think there is a pretty nice analysis about your statement in the net, but I don't know where it is. Frown

It shows that nearly 90% of all "security" software with the mentioned kernel hacks, in fact opens backdoors for malware because they contain many leaks in their device driver code...
So much about security software in the kernel.
Another sheet shows that over 90% of all blue-screens are caused by third party drivers and not by microsoft.

> You are too kernel oriented....

I know but the whole concept of this singularity project is a monster of code authentication, process isolation, cryptography and security leak free managed code (of course this doesn't prevent semantic errors); even device drivers are written in managed languages!

The thing is that within such a real trusted environment, malware is NOT able to cause any harm except to the process where it is currently working in. And even this is doubtful, because the NET Runtime can safely protect any corruption attempts. So the only chance for malware would be to delete some user files in the name of the hijacked trusted process. But this could again easily be defeated by defining per-process file access rules.

And you shouldn't forget the point, that malware is only harmful, when it can be spread around the world. How should it, if it is not signed and though has NO privileges at all...

But this stuff is all very experimental and I doubt that the Windows 7 successor already contains any of this aspects.

Frown

Aelthegrin

6:17 7 Aug '08

First of all, I'd like to thank you for this great article.

I read it once, but I certainly have to read it once again to understand everything - after all, obfuscation and misdirections used in PatchGuard coupled with undocumented kernel structures are definitely not the easiest thing to cope with Smile

I have one (theoretical) comment/question about kernel mode hooking...
In the article you say following (sorry, but I don't know how to quote someone on CodeProject):

Don’t ever release a PatchGuard bypassing or 64-Bit undocumented kernel hooking product to customers! 
An option may be the PatchGuard API, but I think it is not publicly available. 
BTW I disagree to Symantec’s opinion that they need to use undocumented kernel patching to develop security products. 
The only thing is that they already had such products and it would be very expensive for them to reinvent the wheel, by not using kernel patching. 
Microsoft just did the right thing by not listening to Symantec. 
Undocumented kernel patching can never be an option to raise security in a trusted environment like Vista 64-Bit

I never worked with x64 OS, so I may be wrong with what I am trying to say.

Though I very much agree with commercial intentions of Symantec, I don't know any reliable way of developing security products without using undocumented interfaces and structures.

For my diploma thesis, I'm developing a security application - rootkit detector with special emphasis on proactive defense, and basically all my work is based on undocumented stuff.
I know this is not recommended or even reliable way to write software which is going to be released publicly, but as far as I know, almost every other security product vendor (comodo, avast, symantec, f-secure, kaspersky...) uses such approach.

Take for example the process creation event. One could create notify routine through PsSetCreateProcessNotifyRoutine() which is documented and prefered method of doing it. This approach has so many drawbacks it's practically unusable (only 8 routines are allowed, one could overwrite your routine with his own routine - actually reserve all 8 slots, routine is called when the process is already created i.e. the thread is about to run it's first instruction, etc.)...

The only good method for hooking process creation is using undocumented structures and functions, such as NtCreateProcess(Ex)(), NtCreateSection() through SSDT or even perform "low-level" hook by "detouring" unexported PspCreateProcess() (this requires kernel space scanning, this method of hooking something is about the lowest you can get, but it's "so undocumented" even I'm not suggesting it Smile

).

This is actually just the tip of the ice berg, in order to actively stop malware from doing bad things, you must use a whole bunch of undocumented features, instead Microsoft provided nice and documented way of hooking certain portions of the system.

If your comment applies only to 64-bit systems, then I'd have to agree with you, because I didn't have chance to take a closer look at one, yet.

But if you think that using undocumented interfaces in commercial (or other sort of publicly available products) is A Bad Thing Smile

, what would you suggest for replacement?
User mode applications usually don't need to tamper with undocumented stuff (and usually they even can't), but driver providing security features has no other option IMO.

Great article, once again Smile

ael

6:34 7 Aug '08

First thanks for your interest!

>I'm developing a security application - rootkit detector

But that is a special kind of software. Of course you will have to use undocumented things to accomplish this task. But what AV software should care about is that a rootkit can never ever be installed! As I said, then you will already have lost the fight... And this is possible WITHOUT using any undocumented kernel API/hooking. Refer to Sophos Anti-Virus for more information.

>comodo, avast, symantec, f-secure, kaspersky

Well they all had to redesign the whole thing for 64-Bit Wink

>drawbacks it's practically unusable (only 8 routines are allowed, one could overwrite your routine with his own routine

Again you already have lost the fight if malware is able to do that. Security software can thread the 64-bit kernel mode as demilitarized zone. No malware should ever get there...

>this requires kernel space scanning, this method of hooking something is about the lowest

Well if you are on 32-Bit an easy option would be the Microsoft Debugging API which will be able to give you the exact address of such symbols...

> If your comment applies only to 64-bit systems, then I'd have to agree with you

Of course 32-Bit systems are something else. But 64-Bit is really secure! It is designed from the very beginning that the kernel mode is free of malware. You would need to sign a virus to get there...

> what would you suggest for replacement?

What about the Vista Filtering Platform or the Vista SP1 PatchGuard API which is in fact available since 64-bit?!

But again, 32-Bit is something else ^^. I agree with you that you will have to use undocumented kernel stuff there.

In contrast on 64-Bit only signed software can get into the kernel, the UAC will protect most users from running malware as admin, and so on... Windows Vista 64-Bit is a nice piece of work Wink

...

All in all, PatchGuard may seem to be a bad thing for security at the surface. But don't forget that Microsoft had no chance but to take that step. There will be people out there who will cry out some time but after all we are having a secure/stable kernel...

regards Laugh

chris

Aelthegrin

3:36 8 Aug '08

I think we have somewhat different view on the "problem" Smile

You are mainly talking about Vista and later versions of the operating system, while I am mostly thinking about XP. You can say it's "obsolete" and I might agree that, to a certain degree, it is, but my focus is XP because it must be (college requirements Smile

), and I don't think there is so much difference between XP and Vista (32-bit, not familiarized with 64-bit, as I said).
Vista has some nice features I would probably use, but "under the skin" it's pretty much the same OS.

>>I'm developing a security application - rootkit detector

>But that is a special kind of software. Of course you will have to use undocumented things to accomplish this task.
>But what AV software should care about is that a rootkit can never ever be installed! As I said, then you will already have lost the fight...
>And this is possible WITHOUT using any undocumented kernel API/hooking.
>Refer to Sophos Anti-Virus for more information.

I agree with you about AV detection.
Sad truth is that most AVs detect only known malware. As another assignment I was doing a research about AV rootkit detection and the results were pretty much disappointing.
Because every AV is based on definitions, and rest of the job is left to heuristics, it is possible, with some clever (and some not so clever) modifications to change known rootkit to make it undetectable.
Or even worse: for "proof of concept" i wrote three "rootkits", one hiding processes, one hiding files, and a keylogger. Almost none of them was detected by any of the AVs (I'm talking only on AVs now, not about hybrid products with proactive defense). The one hiding processes was detected by avast (I can't remember for sure, but I think it was avast...) and it was probably detected ONLY because I used the exact same method used in known rootkits, and didn't try to obfuscate it in any way.

Situation with user level rootkits is even worse! With the same set of funcionalities (process/file hiding, and keylogger), the programs were simply "ignored" by the AVs:(

No definition - based or heuristics - based tool can stop malware from doing things. It could make things harder, but it's definitely not stopping the problem.
In order to make my computer "secure", I very much rely on AV, but AV is not the silver bullet and no single security application is...
I haven't used Sophos AV for a very long time (5 years at least) and if Sophos didn't change anything, than it's only an AV (and really a good one, but I cannot afford it) without "real time ACTIVITY monitoring" or proactive protection, and it doesn't need to use undocumented API. I might be wrong though...

AV coupled with proactive defense (such as comodo - actually firewall - and defense+) is much much better solution than AV alone. That's why almost every vendor uses "solutions" or similary named "collection" of security tools which combines all kinds of protection.

And for achieving good proactive protection you would probably need to use things that are, well, undocumented Wink

>>drawbacks it's practically unusable (only 8 routines are allowed, one could overwrite your routine with his own routine

>Again you already have lost the fight if malware is able to do that.
>Security software can thread the 64-bit kernel mode as demilitarized zone. No malware should ever get there...

Truth is, malware usually gets there:(
I understand what you're trying to say, but do you think it's a good idea for your security product to be based on method which can be relatively easily bypassed? Unhooking your SSDT hooks is maybe even easier, but you can monitor SSDT for changes. Even without taking security of the method in the account, PsSetCreateProcessNotifyRoutine is a REALLY sloppy method for interception of the process creation, at least on Windows XP.

All I'm trying to say is that Microsoft really did a TERRIBLE job making some of the very useful stuff undocumented... Windows is closed source, I know, Microsoft can do with their own OS whatever they want to, I know that too Smile

PatchGuard is actually a wonderful example of how Microsoft can modify kernel, modify boot procedure, and modify many other undocumented things, and thus make your computer more secure (ehem, MORE secure, but not SECURE Smile

). No other vendor can do that, simply because the structures are undocumented and "not supported", and you could one day end up with expensive program doing nothing because Microsoft decided to change something Smile

While they can modify everything, vendors are advised not to modify anything except what they "are allowed" to. There is one word related to this and MS is very afraid of it: antitrust Smile

>>this requires kernel space scanning, this method of hooking something is about the lowest

>Well if you are on 32-Bit an easy option would be the Microsoft Debugging API which will be able to give you the exact address of such symbols...

Thank you very much for the tip!
Would you mind providing some more info (actual use, code)? I'd very much appreciate that!
I apologize already for writing so much, but you seem the be a person with very much understanding of "undocumentedness" and kernel hacking, and I like to talk about it Smile

>> what would you suggest for replacement?

>What about the Vista Filtering Platform or the Vista SP1 PatchGuard API which is in fact available since 64-bit?!

>But again, 32-Bit is something else ^^. I agree with you that you will have to use undocumented kernel stuff there.

>In contrast on 64-Bit only signed software can get into the kernel, the UAC will protect most users from running malware as admin, and so on...
>Windows Vista 64-Bit is a nice piece of work [Wink] ...

>All in all, PatchGuard may seem to be a bad thing for security at the surface.
>But don't forget that Microsoft had no chance but to take that step.
>There will be people out there who will cry out some time but after all we are having a secure/stable kernel...

Thanks for the info about Vista protection (actually I totally got interested in 64-bit security which I know almost nothing about Wink

), but I have to work for XP...

I agree that Microsoft is doing extremely well in security field. Their SDL (http://msdn.microsoft.com/en-us/library/ms995349.aspx[^] and http://blogs.msdn.com/sdl/[^]) sure got things going in the right direction and days of catastrophicaly bad IE and IIS are (probably) behind us Smile

>>the only good method for hooking process creation...

>Keep in mind that AV software won't need to intercept process creation...
>AV software could use the Vista Filtering platform to intercept file accesses.
>If a process is being created, the EXE file is accessed and AV software is now able to scan this file for malware...

Again, on XP this is another topic:( I found such "filter libraries" under XP (can't remember names though), but the filters themselves are again probably very low level and, unless they're dealing with FS, using undocumented features to certain extent.
I said previously what I think about sole AVs Smile

>Or look at the documentation for PsSetCreateProcessNotifyRoutineEx():

>The NTSTATUS value to return for the process-creation operation. Drivers can change this value to an error code to prevent the process from being created.

>You will also get the command line args, the image file, and so on...

Well this is interesting.
Unfortunately it's only available for Vista and newer OSs.

Do you maybe know at what stage is the process creation method interrupted? For "original" PSCPNR it wasn't interrupted at all, the notify routine was only a callback routine called after the process has been created. I mean, is there a way to prompt user about process creation WITHOUT suspending that process' main thread? That's the thing I absolutely hated about original PSCPNR.
As I can understand from what you have quoted (where did you find it anyway, it's not mentioned in MSDN PSCPNRE documentation Smile

), process creation is interrupted just after the process and corresponding structures have been set up and just before the main thread started to execute. If that's correct, it's a very nice thing, as long as you can "suspend" process creation and wait for user decision.

Command line args, image, etc. are GREAT things, otherwise you have use really awkward methods of getting that info.

Thanks for your reply!

cheers Smile

ael

4:55 8 Aug '08

>Truth is, malware usually gets there

I don't think that it will on 64-Bit Smile

... But in 32-Bit it is really straightforward to get there...

> method which can be relatively easily bypassed

The kernel is one security level.. No matter where you place your hooks they are always bypassable if malware gets there...
That's why I said use 64-Bit and you have a secure kernel to rely on!

> PsSetCreateProcessNotifyRoutine()

Yes because the process creation is not delayed until you return?!
I actually need this feature myself, for EasyHook. Do you know if it is delayed?
I know that it is for PsSetCreateProcessNotifyRoutineEx() but this one is available
only since Vista SP1...

>V coupled with proactive defense (such as comodo - actually firewall - and defense+) is much much better solution than AV alone

Maybe, but after all the goal of AV software is to >prevent< malware from spreading
all over the world. I think is it enough to find it by signatures.
Microsoft Windows is the problem. Look at Linux for a change. It makes it simply
impossible per design, to hook other processes and so on. If Windows would also
isolate processes, malware wouldn't be able to do anything and any sane software
still wouldn't be affected. In my opinion allowing hooking or any kind of weird
process manipulation is just an invitation for malware. Microsoft will stop this with
the NGSCB, but as I said, it is a two sided sword!

> With the same set of funcionalities (process/file hiding, and keylogger)

Well you can't expect any AV to detect this. This would cause many software to
fail. Then you could take the sledgehammer in first place and simply prevent any
kind of process manipulation by blocking any CreateRemoteThread, SetThreadContext,
VirtualAllocEx, WriteProcessMemory calls with kernel hooks...

> All I'm trying to say is that Microsoft really did a TERRIBLE job making some of the very useful stuff undocumented
>anything except what they "are allowed" to. There is one word related to this and MS is very afraid of it: antitrust

Of course you can connect this with anti-trust and I already did this in the full PDF version.
The problem here is that it is a two sided sword. Microsoft MUST get 3th parties out of undocumented
kernel sections to apply major improvements. Imagine you publish a software and a lot of 3th parties
are now "hooking" into it. You are expected, like Microsoft, to keep updates backward compatible. Well,
I hope you can imagine where this road will lead to. It is a total mess when 3th parties are using undocumented
things because every update may break software and BSOD customer PCs. MS BSOD history shows that nearly
no BSOD was raised by Microsoft but only by 3th parties patching the kernel or writing bad drivers!

You can't look at this only with antitrust in mind!

>Would you mind providing some more info (actual use, code)? I'd very much appreciate that!

Actually my EasyHook library found at "www.codeplex.com/easyhook" will provide you a code snipped
in "Debug.cpp". This shows how to initialize the IDebugControl interface. You would need to
access the "IDebugSymbol" interface but thats pretty much the same. Download the latest
"Microsoft Windows Debugging Tools for 32-Bit". It also contains a comprehensive API reference.
This great utility is almost unknown!

> way to prompt user about process creation WITHOUT suspending that process' main thread?

As far as I read the MSDN article, only the new PsSetCreateProcessNotifyRoutineEx() will
provide this, because as you run at PASSIVE_LEVEL and the process creation is delayed
until your driver returns, you could provide a user-mode round-trip.

> (where did you find it anyway,)

In the latest Windows Driver Kit documentation...

regards
chris

Aelthegrin

7:46 8 Aug '08

>> PsSetCreateProcessNotifyRoutine()

>Yes because the process creation is not delayed until you return?!
>I actually need this feature myself, for EasyHook. Do you know if it is delayed?
>I know that it is for PsSetCreateProcessNotifyRoutineEx() but this one is available
>only since Vista SP1...

No, it's definitely not delayed.
Process just keeps running, your routine is just being informed about process creation, and has no "nice" way of preventing the creation.

PspCreateThread() is the routine calling your notify routine:

nt!PspCreateThread+0x361:
805ceecf 7556            jne     nt!PspCreateThread+0x3b9 (805cef27)
805ceed1 b201            mov     dl,1
805ceed3 8bcb            mov     ecx,ebx
805ceed5 e802140300      call    nt!WmiTraceProcess (806002dc)
805ceeda 833dc029568000  cmp     dword ptr [nt!PspCreateProcessNotifyRoutineCount (805629c0)],0
805ceee1 7444            je      nt!PspCreateThread+0x3b9 (805cef27)
805ceee3 c745cca0295680  mov     dword ptr [ebp-34h],offset nt!PspCreateProcessNotifyRoutine (805629a0)
805ceeea c745b008000000  mov     dword ptr [ebp-50h],8
805ceef1 ff75cc          push    dword ptr [ebp-34h]
805ceef4 e88dc60300      call    nt!ExReferenceCallBackBlock (8060b586)
805ceef9 8bf8            mov     edi,eax
805ceefb 85ff            test    edi,edi
805ceefd 741f            je      nt!PspCreateThread+0x3b0 (805cef1e)
805ceeff 57              push    edi
805cef00 e881c40300      call    nt!ExGetCallBackBlockRoutine (8060b386)
805cef05 6a01            push    1
805cef07 ffb384000000    push    dword ptr [ebx+84h]
805cef0d ffb34c010000    push    dword ptr [ebx+14Ch]
805cef13 ffd0            call    eax
805cef15 57              push    edi
805cef16 ff75cc          push    dword ptr [ebp-34h]
805cef19 e86ac70300      call    nt!ExDereferenceCallBackBlock (8060b688)
805cef1e 8345cc04        add     dword ptr [ebp-34h],4
805cef22 ff4db0          dec     dword ptr [ebp-50h]
...

Your notify routine is called after the process object is created, and before thread object is created (although I'm just "guessing", there could be things I didn't take into the account), but all that doesn't matter because the process created isn't stopped when your routine takes control and that's probably the biggest disadvantage of PsSetCreateProcessNotifyRoutine().

There is no such thing as SuspendProcess() in Windows OS. The only way of suspending process creation with PSCPNR I could think of is suspending all of the threads of that process. Although your routine is called very early in the process creation event, suspending all of the threads is not very good idea:

- some processes are simply not meant to be "suspended" like winlogon, csrss, etc. Suspending a thread in such process could be very bad

- thread *could* own some synchronization object on which some other thread depends. Suspending such thread is a very bad thing

- some kind of race condition in which thread is created after our routine suspends other threads but fails to suspend this thread

As you can see, this way of process creation notification is not very useful. SSDT hooking provides MUCH more flexibility.

>Maybe, but after all the goal of AV software is to >prevent< malware from spreading
all over the world. I think is it enough to find it by signatures.

Signatures are bad, signatures and heuristics are much better, and signatures + heuristics + proactive defense are much much better Smile

You can't simply rely on signatures, "static" defense is never going to be enough. Heuristics are heuristic Smile

Proactive defense is really good, but certainly not the "one ring to rule them all"

> Microsoft Windows is the problem. Look at Linux for a change. It makes it simply
>impossible per design, to hook other processes and so on. If Windows would also
>isolate processes, malware wouldn't be able to do anything and any sane software
>still wouldn't be affected. In my opinion allowing hooking or any kind of weird
>process manipulation is just an invitation for malware. Microsoft will stop this with
>the NGSCB, but as I said, it is a two sided sword!

I couldn't agree more about Linux kernel security. It's also a reasonable thing that an open source product is going to be more adaptable and more up-to-date with current threats, and linux kernel is one good example of that.
It's not true that hooking methods don't exist, there are plenty of Linux kernel hooking examples, through syscall hooking, with or without LKM...
But I agree that process separation is much better solved in Linux than in Windows.

For example, I always asked myself why it's allowed to read or write process memory (almost any process!) on Windows XP/2000/server 2003 even with user privileges (without SeDebug...)? Do you know the answer, I always wanted to ask someone with good knowledge of Windows Smile

>> With the same set of funcionalities (process/file hiding, and keylogger)

>Well you can't expect any AV to detect this. This would cause many software to
>fail. Then you could take the sledgehammer in first place and simply prevent any
>kind of process manipulation by blocking any CreateRemoteThread, SetThreadContext,
>VirtualAllocEx, WriteProcessMemory calls with kernel hooks...

Exactly, but that's why proactive defense is better than signatures Smile

I didn't expect for an AV to detect this, but than it's paradox to have a tool which protects me only from what is known to the world. I want to be protected, anywhere and anytime and from everything, and not only from those things that AV has in it's database. This is where AV clearly fails.
Also, I'm not talking about blocking those calls, only about interception and giving opportunity to prevent malicious activities.

>Of course you can connect this with anti-trust and I already did this in the full PDF version.
>The problem here is that it is a two sided sword. Microsoft MUST get 3th parties out of undocumented kernel sections to apply major improvements.
>You can't look at this only with antitrust in mind!

It's indeed two sided sword. I'm not looking this only with antitrust in mind, but I can't ignore the fact that Microsoft could change their product, i.e. PatchGuard prior to major kernel changes and thus having no compatibility problems, while 3rd parties cannot do that.
That's at least uneven position and brings antitrust in discussion Smile

Besides, most of the undocumented interfaces haven't changed from Windows NT to Vista, that's about 15 year timespan Smile

Only newer versions were added, and little was changed. That's no excuse, but using undocumented stuff is not so unsafe bet Smile

>Actually my EasyHook library found at "www.codeplex.com/easyhook" will provide you a code snipped in "Debug.cpp".

Thanks, I already started reading EasyHook article here on CodeProject, but the lack of time prevented me to finish it.

>Download the latest "Microsoft Windows Debugging Tools for 32-Bit". It also contains a comprehensive API reference.
>This great utility is almost unknown!

Smile

No no, I knew about Windows debugging tools, hell, WinDBG is one of my favourite tools, but I somehow overlooked its API.
It's very nice to know this approach, but it's almost as useless as "kernel space scanning" in publicly available apps. Your "customer" has to download symbols on their own at least.
If there were a method to download symbols automagically (for example, without WinDBG and dbgtools, just connecting to symbol server) it would be great, but I think it would be another bending of rules and undocumentedness Smile