AppDefend x64 BETA Released (XP64)

[Jason_R0]

http://www.ghostsecurity.com/index.php?page=xp64patching

Here is a page I wrote about x64 patching protection ( commonly refered to as PatchGuard ) . Whilst most people might think there is nothing special about supporting x64, I can tell you it is a big deal. Reading the above webpage will indicate why. You can also download the x64 version of Ghost Security Suite from that page.

I will be supporting Windows 2000, XP, 2003 and XP64 from now on.

This x64 build, is exactly the same as the 32bit build, but it has some newer features which will be released in the 32bit build over the coming days.

[Jason_R0]

Taken from the webpage :-

-{ Quote: "Microsoft has stated that they do not want the kernel modified in future versions of Windows. See this URL for more information :-

http://www.microsoft.com/whdc/driver/kernel/64bitpatching.mspx

The reason for not wanting kernel modification is simple. By keeping the kernel area in one state defined by Microsoft, there will be less issues to deal with. The only mess they will need to clean up is there own.

So why do people want to modify the kernel area? It is quite simple really, Microsoft does not provide documented methods to do everything a software developer may want to do. If a software developer (like myself) can modify the kernel and do something different which is desired by users, then why isn't there a documented way to do these things? Only Microsoft can answer this question.
" }-

-{ Quote: "There is no particular reason why anyone would want their vulnerable kernel area modified, especially by malware. The irony in this however is that Microsoft's operating system isn't quite up to scratch in regards to security. So by allowing a trusted security software developer like myself to patch the kernel, you help RESTRICT malicious software from performing the same thing.

Up until Windows XP64, Kernel modification wasn't "documented" but it wasn't actively stopped by Microsoft either. With Windows XP64 (and Vista) this all changes. Due to some software developers having buggy and unreliable kernel modifying software, it led Microsoft to say "stop doing this, it's not safe!" and they now actively discourage the use of kernel modifying software.

Now as a developer of kernel modifying software this leaves me in a very weird position, especially since I like and use my own software. Microsoft says to contact them if you feel there is something you cannot do without modifying the kernel. That is interesting because not all of what I do can be be done any other way. Admitably Microsoft has been making progress, making more and more areas available to developers. There is still a big gap between what you are allowed to do according to Microsoft, and what CAN be done.

I do not care for Microsoft (and others who support this patching decision) telling individuals that software like mine is buggy and unstable. I have been using my own kernel modifying software for over 3 years without a single blue screen related to my software. They can tell people it is buggy all they want, I have my own proof. Some people will tell you it is a risky thing to do, and I agree, which is why you should only stick to installing software from people or companies with histories of stability.
" }-

-{ Quote: "What I have done is basically undo Microsoft's kernel protections and allow my kernel modifying software to work on XP64. This goes AGAINST what Microsoft wants developers like myself to do.

What I found interesting was there is no documented way to turn off this kernel protection. After digging deeper into how Microsoft implemented the protections I began to wonder why any user concerned with performance (like a lot of XP64 users are) would want a system thread to be filling their CPU cache with kernel code every few minutes and doing checksums and other checks. These sorts of checks could easily lead to hitches noticeable on the system when it is under stress, like when playing a game or watching a movie.

So not only have I allowed my software to work on Windows XP64, I have also disabled their checks which they do every few minutes in the background leading to BETTER OVERALL SYSTEM PERFORMANCE. This means one less unknown Microsoft event is happening on your machine with my software installed.

It was quite a big job to undo Microsoft's protections, however since there are two direct benefits in doing it (system runs faster and my software now works) I can see a lot of developers and users questioning Microsoft on their patching policies in the future.
" }-

-{ Quote: "Whilst I will agree it was somewhat difficult to undo Microsoft's protections I do not think I have something divine in me which means no one else can do this. Eventually the information on how to break Windows XP64 protection will be posted.

Even though I seem to be one of the first developers to publically bring this to people's attention, who knows if malicious authors haven't already discovered how to do it, and are using it against you right now? Microsoft's security won't tell you, but my software will. This is why I want to use my own software on Windows, it gives *me* added protection over whatever Microsoft can provide.
" }-

[muppetmaster]

Quite an accomplishment Jason. Not too long ago, such protection was dismissed as unlikely, if not impossible, for 64 bit Windows -> http://www.wilderssecurity.com/showpost.php?p=607006&postcount=3

[Tatersalad]

Okay then, 64 bits. Question will I need an unlimited home license if I want to run another install on the 32 bit frosted side of the same computer?

[Jason_R0]

-{ Quote: "Okay then, 64 bits. Question will I need an unlimited home license if I want to run another install on the 32 bit frosted side of the same computer?" }-

You won't need another license for the same computer, the same goes with Virtual Machines on the same computer. It is only when putting it onto a new "real" computer will you need a new license.

[Jason_R0]

-{ Quote: "Quite an accomplishment Jason. Not too long ago, such protection was dismissed as unlikely, if not impossible, for 64 bit Windows -> http://www.wilderssecurity.com/showpost.php?p=607006&postcount=3" }-

Hi "muppetmaster",

To most developers, before I released the AppDefend/RegDefend beta for x64 it would have seemed impossible. Since I am now doing it I think the pressure will be on for a lot of companies to try and support it also.

[Lars Viklund]

Jason,
I am stunned!!
Thank you so much for the beta (x64).
I have been waiting for this. Something that works on x64.

So far both RegDefend and AppDefend works great.

Best regards
Lasse

[Jason_R0]

-{ Quote: "Jason,
I am stunned!!
Thank you so much for the beta (x64).
I have been waiting for this. Something that works on x64.

So far both RegDefend and AppDefend works great.

Best regards
Lasse" }-

Hi Lasse,

Great to hear it works fine on your machine. The XP64 build is using some very undocumented features, however the testing we have done indicated it is pretty stable (no crashes here yet on the latest build).

[Jason_R0]

A new x64 beta has been released, available through the internal update system in Ghost Security Suite. Check for the official release thread for the changes.

[Pilli]

Thanks Jason, Considering the protection offered from GSS the resource usage appears to be even lighter than the previous beta. Works great on my Turion x64 laptop. :)

Cheers. Pilli

[Jason_R0]

-{ Quote: "Thanks Jason, Considering the protection offered from GSS the resource usage appears to be even lighter than the previous beta. Works great on my Turion x64 laptop. :)

Cheers. Pilli" }-

Hi Pilli,

One of the features of this latest build has been a massive reduction/optimization in how the GUI components for Ghost Security Suite work. This has allowed the memory usage to drop quite a bit.

[__nathan]

It's probably worth noting that this "PatchGuard" technology used by Microsoft can change at any time. Any hot fix, service pack or similar update could potentially subtilely change the PatchGuard implementation and thus break any software (such as your AppDefend utility).

Microsoft reserves the right to do this.

Moreover, if your crack for this doesn't have sufficient error checking to ensure what it is about to overwrite in kernel space is intended then it could result in bug checking the system and then your customer would be stuck with an infinitely rebooting system.

If there is some hooking functionality you would like to see be made official in Windows Vista then send your suggestions in. Systems with software installed that use kernel patching won't be supported by Microsoft any longer.

PS: The processing time used by PatchGuard is miniscule. There are far more costly things occuring in the kernel every split second that use the amount of time PatchGuard would use in a year.

[Jason_R0]

-{ Quote: "It's probably worth noting that this "PatchGuard" technology used by Microsoft can change at any time. Any hot fix, service pack or similar update could potentially subtilely change the PatchGuard implementation and thus break any software (such as your AppDefend utility).

Microsoft reserves the right to do this.

Moreover, if your crack for this doesn't have sufficient error checking to ensure what it is about to overwrite in kernel space is intended then it could result in bug checking the system and then your customer would be stuck with an infinitely rebooting system." }-

Hi Nathan,

AppDefend x64 is coded to make sure everything is how it should be before it decides to remove PatchGuard. This lessens any likelihood from BSOD's caused by AppDefend *if* Microsoft do change patchguard. Three of my beta testers have x64 systems and if there is a change there will most likely be a fix for AppDefend very quickly. If AppDefend ever did cause a BSOD, all you need to do is boot into safe mode and uninstall it, or disable the driver. There is no way a user could be locked out of the system with AppDefend being the culprit.

One thing you must remember is not everything AppDefend does is supported officially by Microsoft, which means I have to resort to undocumented means in some cases to perform some protection related activities. You might ask why? Simply because my customers demand certain features, features not supported officially by Microsoft BUT which their operating system still supports, it is quite simple really.

-{ Quote: "If there is some hooking functionality you would like to see be made official in Windows Vista then send your suggestions in. Systems with software installed that use kernel patching won't be supported by Microsoft any longer." }-

Windows Vista? What does Vista have to do with Windows XP64. My customers don't just expect me to skip a Windows generation just because something I do on it isn't officially supported. I have looked in depth at what Microsoft has added to try and remove *some* hooking behaviour on their systems, but it isn't done in a way which security software developers can use effectively for our purposes. They have added a lot more monitoring behaviour, but strangely left out ways to CONTROL this behaviour without resorting to undocumented means. My customers don't just want to know something happened, but also that AppDefend/RegDefend BLOCKED it if it needed to.

If "very big" companies, like Symantec for example, cannot get Microsoft to budge on the things they want to do in the kernel, what hope do you think Ghost Security has of making them. Zone Alarm, Kavspersky, Symantec all patch and hook the kernel on 32bit Windows. If Microsoft want to remove all "undocumented hooking" then its quite simple for them to achieve, the only problem is whatever implementation they come up with is so similar to what already exists that they probably see no point in changing it.

-{ Quote: "PS: The processing time used by PatchGuard is miniscule. There are far more costly things occuring in the kernel every split second that use the amount of time PatchGuard would use in a year." }-

I agree it is small amount of CPU time in the relative scheme of things, however there is no check to determine if the system is busy or in a state of intensive use. For example all the people who run games know what "hitching" is, PatchGuard can make your system do this. Just because most people cannot "notice" PatchGuard working because their systems are so fast and most of the time they aren't playing games doesn't mean that your CPU should be sitting there doing things you don't want it to do.

At the very least PatchGuard should be an option for all the people out there that don't want it. The reason why it isn't optional should be very clear to most people.

My job isn't to make Windows, the theoretical product, better for Microsoft in their own minds. If Microsoft really care about "enforcing foreign policies" which *they* think are important they would be contacting developers and asking them. Do you think most end users care or can even understand how a product works on their system? Do you think when most users install their firewall they are wondering "Hmm is this a TDI Filter Driver or a Winsock 2 LSP implementation?". If my job was team leader/manager of the Microsoft kernel development team maybe I would be out there finding what people want and implementing it, but it isn't.

As an independent developer I see the target platform, have the problems I want to solve, and develop a product. Regardless of what is officially available on that operating system, whatever it takes to solve those problems is performed. If it is stable and performs well then I see no problem with it.

As long as kernel developers like myself create code which is run at the same level of privileges as the core operating system they will never be able to stop hooking. PatchGuard hasn't stopped me, and it won't stop malware developers who will be rootkitting *your* XP64 system without your knowledge, unless of course you have AppDefend. ;)

[__nathan]

Well as long as you know that you could, potentially, be re-cracking PatchGuard and releasing an update to your software every time there's a hot fix or service pack ;)

Remember your customers will expect you to deliver once you have committed to supporting that platform. You won't be able to say "Sorry you'll have to wait a week before running Windows Update this Tuesday as it'll take me a while to re-crack the protection."

As I said, Microsoft aren't prepared to support systems using modified kernels any longer. Microsoft have been blamed for "blue screens" for years but 95% of the time it is caused by third party code (or a hardware problem ;)) - especially drivers using dubious coding practices in the kernel space. Now I'm not saying your code is faulty, I'm sure it is fine. What I'm saying is, you're about to get caught up effectively in a case of friendly fire. Because of bad coding reaching customers and the explosion in use of root kits - everybody has to lose out.

This may also be of interest to you: http://www.microsoft.com/whdc/system/platform/64bit/kmsigning.mspx

-{ Quote: "Unsigned kernel-mode software will not load and will not run on x64-based systems.

Note: Even users with administrator privileges cannot load unsigned kernel-mode code on x64-based systems. This applies for any software module that loads in kernel mode, including device drivers, filter drivers, and kernel services.
" }-

[tlu]

-{ Quote: "

This may also be of interest to you: http://www.microsoft.com/whdc/system/platform/64bit/kmsigning.mspx" }-
Yes, but this doesn't mean signing by Microsoft, IMHO. You can create a signature by getting a certificate from Verisign which costs about 500 $ per year. That has nothing to do with Microsoft's well-known driver signing. The document on the above mentioned site says it clearly: "To be signed with a PIC, drivers are not required to pass WHQL testing. " (PIC = Publisher Identity Certificate)

[Jason_R0]

-{ Quote: "Well as long as you know that you could, potentially, be re-cracking PatchGuard and releasing an update to your software every time there's a hot fix or service pack ;)

Remember your customers will expect you to deliver once you have committed to supporting that platform. You won't be able to say "Sorry you'll have to wait a week before running Windows Update this Tuesday as it'll take me a while to re-crack the protection."

As I said, Microsoft aren't prepared to support systems using modified kernels any longer. Microsoft have been blamed for "blue screens" for years but 95% of the time it is caused by third party code (or a hardware problem ;)) - especially drivers using dubious coding practices in the kernel space. Now I'm not saying your code is faulty, I'm sure it is fine. What I'm saying is, you're about to get caught up effectively in a case of friendly fire. Because of bad coding reaching customers and the explosion in use of root kits - everybody has to lose out.

This may also be of interest to you: http://www.microsoft.com/whdc/system/platform/64bit/kmsigning.mspx" }-

Hi Nathan,

What VISTA brings will just be another challenge. Remember, Microsoft were saying prior to the XP64 release that no-one could hook or do any fancy kernel modifications, and a lot of people believed them. I am a developer who proved that wrong.

There is also the other side of the coin that many people can get all they need from Windows XP or XP64, there is little reason for a lot of people to upgrade to VISTA at this point in time, considering it will consume even more resources. Any further steps Microsoft adds to stop 3rd party developers to make applications for their system will just mean even less users migrate to it.

[oldBear]

It will be quite some time before I will move to Vista - at least service pack one, and probably later.

The company I work for is just now migrating to XP (over 7000 seats). I'm quite sure they won't be migrating again very quickly (especially since I help make the decision).

I'm pretty sure you have a good marlet with XP for the next several years. Just focus on improving for us (existing XP base) and worry about Vista when there's a market that makes it worth your time and effort.;)

cheers

[f3x]

Well i also beleive it's a good thing to keep support of XP (32/64) for the next few years, however i was also wondering if there is any plan to offically support vista when it launches ? or not too far after.

[Jason_R0]

I have released an updated x64 build.

http://www.ghostsecurity.com/downloads/setupadrd1300a3_x64.exe

Read more about it in the 1.300 alpha release thread here :-
http://www.wilderssecurity.com/showthread.php?t=189957

[cbuddha42]

Thank you for putting out a x64 release :).

[psychosmurf]

For anyone who might be curious; Vista x64 and AppDefend x64 don't play nice. I know, I know it's been asked and Jason said it wasn't supported but I was hoping beyond hope that it would, just by a little sliver of chance, work and I wouldn't have to give up AppDefend's protection to move to the new OS but alas; AppDefend x64 crashed my brand new Vista system on the first reboot. Well, it didn't crash it, per se, but the OS wouldn't load ghostsec.sys (I think that was the filename) and consequently wouldn't boot (windows said it couldn't verify the digital signature and thus it wouldn't load the file). I had to go into last known good cofig and remove AppDefend to get back into Windows. :'(

Right now I'm torn between keeping the new OS (necessary for my job) or going back to XP for the increased security protection and running Vista in a virtual machine. I don't like this second way because I prefer to do at least SOME of my testing on a physical box but I also feel naked and exposed (not to mention ABANDONDED by Microsoft, Nathan >:( ) without my AppDefend protection.

Its amazing that we Americans think that just because we SAY a thing can't be done means that NO ONE is going to do it. MS blocking kernel access without providing a way to the security companies to still use it isn't going to stop viruses or root kits or hackers or malicious individuals from taking over our systems; it's just going to prevent US, the users, from stopping them hijacking our system by leaving us without the necessary protections to keep our systems safe and secure. It's on a par with gun control: laws preventing the sale of firearms aren't going to stop criminals from getting firearms. (I hate guns but I understand the stupidity of the argument 'outlawing guns will keep the out of the hands of criminals'. Stupidity seems to be a characteristic that MUST be possessed to be elected to a political office in the United States, but I digress.)

Don't get me wrong: I'm a windows user and have been for years and will continue to be; more out of necessity than anything else but I do understand the good that MS has brought to the industry with standards and practices that people can follow and use. In sharp contrast; Linux distributions are so different it's like using a different piece of software each time I boot into a different version of the OS and with so many out there it's virtually impossible to put any kind of practical knowledge (read: not having to be a programmer to use) into any kind of real world use. But Microsoft's half-asssed attempt at security is offensive and its leaving the people that REALLY matter, end users (you know the ones that dropped five hundred bucks on this operating system HELLO!), exposed in ways that are simply unacceptable.

So now I have a tough decision to make. I hope I make the right one.

[Jason_R0]

-{ Quote: "For anyone who might be curious; Vista x64 and AppDefend x64 don't play nice. I know, I know it's been asked and Jason said it wasn't supported but I was hoping beyond hope that it would, just by a little sliver of chance, work and I wouldn't have to give up AppDefend's protection to move to the new OS but alas" }-

If I get the driver signed.... so I can patch the Vista MS kernel... MS will most likely revoke the license for breaking a rule of theirs.... :)

Either way, the next x64 version of GSS is going to bring some nice surprises, unfortunately not for Vista at this stage.

[psychosmurf]

Thanks for the reply Jason.

I dumped Vista for the time being. It took about five minutes after I finished that post last night for me to decided that I just couldn't live without my Ghost suite. I just feel too exposed without it so I'm back to XP x64. Vista's pretty (I guiltily admit I love the aero interface but my fondness for the OS stops there); but using it (especially for someone like me who is above average in computer literacy) is a pain in the patella: It tries to take way too much control away from me and it seems to assume beyond assumption that I don't know what I'm doing. That's probably fine for Granny Grin who's first time picking up a computer was when she got one for eightieth birthday, but I've been working with them since I was fifteen (about twenty years at this point); I don't need my operating system telling me I need to be an admin to copy a damn file or telling me that I can't store a file on my hard drive. >:(

So I'm finishing up my reinstalls now (the old motherboard died this weekend and I have to reinstal everything for the replacement hence the VERY short stint testing out Vista) and I'll wait patiently for the next x64 Ghost beta. You've the best security software on the market and we're all exceedingly lucky to be protected by your wares.

Thank you for doing all that you do.

[Jason_R0]

-{ Quote: "So I'm finishing up my reinstalls now (the old motherboard died this weekend and I have to reinstal everything for the replacement hence the VERY short stint testing out Vista) and I'll wait patiently for the next x64 Ghost beta. You've the best security software on the market and we're all exceedingly lucky to be protected by your wares.

Thank you for doing all that you do." }-

I take it you've been using the very latest one provided here? It's not in an ideal condition like it will be soon, with every component being nearly identical (gui, ask_user and driver) to the 32-bit version, will make it easier to support both at the same time unlike before.

[Defenestration]

How are you supposed to install the latest version of GSS x64 ?

I downloaded and installed AD x64 from the GS website. I then downloaded and installed the latest AD 1300a3, from post #19 in this thread

http://www.wilderssecurity.com/showpost.php?p=1121775&postcount=19.

On reboot, the GSS Security Status says "Driver installed. Trying to start driver" (or something like that). After a short delay, it says "Unable to start Unified Driver. Protection is not enabled", and I get an error dialog saying "Could not START the Ghost Security Suite Unified Driver. This means that the protection is not active."

[Defenestration]

BTW, I am running XP Pro x64 SP2 with ALL updates, and I don't get any notification about new Kernel Patch Protection when installing AD x64 alpha 3, even though I imagine I must have the latest KPP.

[Defenestration]

-{ Quote: "BTW, I am running XP Pro x64 SP2 with ALL updates, and I don't get any notification about new Kernel Patch Protection when installing AD x64 alpha 3, even though I imagine I must have the latest KPP." }-I think I know the problem - I used nLite to slipstream SP2 and all updates to 2nd December 2007 onto my XP x64 SP1 CD, to create a new installation CD. I then used this to install XP x64. Therefore, the KPP updates cannot simply be un-installed by using Add/Remove Programs to remove the relevant KB's.

Is there any way around this so people, who have slipstreamed updates, can un-install the KPP updates and use GSS ?

[lucas1985]

You'll have to make a new custom CD.

[Defenestration]

Which KB's should I not slipstream to get rid of the KPP updates ?

Also, do these KB's only contain the KPP updates, or do they also contain other fixes ?

[Defenestration]

While it may not be possible to automatically remove the KPP updates from slipstreamed installations (although that would be handy), would it be possible to have some sort of special alert in the GSS x64 build, which would be displayed when a possible KPP update was being attempted. Without looking into exactly what files are being changed when the KPP is updated, would it be possible to have a list of these files, and then alert when one of these was about to be changed ?

I suppose this kind of functionality would be a specialized form of a new "FileDefend" ® © ;D module (which could allow/block creation/modification/deletion of files and folders, based on a rule-set).

[Defenestration]

-{ Quote: "Which KB's should I not slipstream to get rid of the KPP updates ?" }-Update for Windows XP x64 Edition (KB914784) is the first update to KPPv2.

Update for Windows XP x64 Edition (KB932596) is the second update to KPPv3.

NOTE: KB932596 supersedes KB914784.

[Defenestration]

-{ Quote: "While it may not be possible to automatically remove the KPP updates from slipstreamed installations (although that would be handy), would it be possible to have some sort of special alert in the GSS x64 build, which would be displayed when a possible KPP update was being attempted. Without looking into exactly what files are being changed when the KPP is updated, would it be possible to have a list of these files, and then alert when one of these was about to be changed (eg. "An update to Kernel Patch Protection is possibly being installed, which may disable GSS. Do you want to allow this update ?") ?

I suppose this kind of functionality would be a specialized form of a new "FileDefend" ® © ;D module (which could allow/block creation/modification/deletion of files and folders, based on a rule-set)." }-According to the MS Security Advisory for KB914784, only two files were updated - "Ntkrnlmp.exe" and "Ntoskrnl.exe".

Since other non-KPP updates may also modify these files, then the alert should stress that these updates may not be KPP updates, but this would be a powerful tool against KPP updates.

[Defenestration]

Jason - Would it be OK to simply replace the two files, "Ntkrnlmp.exe" and "Ntoskrnl.exe" with those from my XP x64 SP1 install CD (as it would be a pain to have to re-install XP along with all my other apps) ?

[Jason_R0]

-{ Quote: "Jason - Would it be OK to simply replace the two files, "Ntkrnlmp.exe" and "Ntoskrnl.exe" with those from my XP x64 SP1 install CD (as it would be a pain to have to re-install XP along with all my other apps) ?" }-

I think that should be fine, in theory. As they rarely change anything major in those modules (besides KPP of course). I can see an instance where Microsoft try to roll out some major update with a new version of KPP bundled along with it, but then the major update would have to have something worthwhile for us to want to upgrade to it. :)

Whenever something important comes with KPP, I will have to "fix" that version of KPP, but for now uninstalling the updates is the preferred method if you want system speed and stability.

I will probably have to use a better method to detect the version of KPP installed rather than relying on those updates being installed into the registry, file version checks, things of this nature.

[TheQuest]

Hi, Defenestration

-{ Quote: "(as it would be a pain to have to re-install XP along with all my other apps) ?" }-
There is aways Repair Install which would save you having to reinstall all of your apps, and then edit your update install. :-\

Take Care,
TheQuest 8)