PG simply does not work

Indeed. And I suspect it won't even be long. To me, that program uses methods that are way beyond the acceptable limits.

 

As we're talking about a termination method not detected...

While doing some tests, I've noticed that the trojan XPKiller (Trojan.Win32.killXP.a) is able to terminate/kill Windows automatic updates (wuauclt.exe), without PG detecting anything !

Wuauclt.exe is protected against termination in PG here (and modification), all global protections are enabled in PG (including SMH for wuauclt.exe), so I guess there are a few methods not handled by PG yet .

I guess Kill XP is taking advantage of a system process's privileges, but PG logs don't allow to see it:

Cheers,
nicM

 

@gunner and all other.
ICE was a false alarm. ( In the sens of a security threat )
It's a simple PostMessage( WM_Quit ) to the window.
I guess that what was preventing PG form working is a non standard way for delphi to handle the API.
Or the antidebug code around the call...

@NicM

Do you have PG full. Pg free is vulnerable to kernel modification attack

 

Sure , I said I had all Global protection options enabled.

I don't get any alert from PG once XPKiller is executed.

Cheers,
nicM

 

THen i do not know what to say.


I'm not yet enthousiam to the point of installing a trojan to test my security settings. It's possible that XPKiller does an action that seems legit.. but has a result of crashing the target wuauclt application ? DO you have any error or just the thing disabled ? Windows update need some services like Backgroud intelligent transfer to work. Does the disabling of services is covered in PG or just the creation of new ones ?

 

No, I don't get any errors, and I can tell you that I've reproduced it several times, since I didn't believe it at first .

I just did redo, PG logs are as follows:

Seems wuauclt.exe is started... But you see it's taskbar icon disappearing right when you launch XpKiller, it's process instance is gone too.


I've logged process/threads creation, here is what I get in the pic. But in the same time, I've nothing showing in Icesword's "Log process termination" neither ...

Looks like this termination method is a very refined one!!

I'll try later with different settings for svchost.exe, I've default settings now and I see it's allowed to terminate. As it's the process re-starting wuauclt.exe, results should be different then.


Cheers,
nicM

 

My guess for you is to inform yourself about command line of wuauclt.
I unfortunately does not have much time rigth now. Maybee later.


I especially look at this switch:
>/runstoreascomserver : run store as com server

Wich sound like
Round as backround task.
Prepare yourself to "serve"(communicate) with another application


I other word .. wuaclt have a server mode. It have a special interface to communicate with another program. A bit like a remote control. I guess this can be used by admin to mass deploy windows updates.



So my guess is that the taskbar icon that dissapear in a normal result of the command line. THen do you knwo if the program is willed. IS the process in task manager ? If the process is killed...

Then you could try to see if wuauclt self terminate itself.
http://www.sysinternals.com/Utilities/PMon.html

 

f3x, I did redo this test, this time with different settings for svchost.exe in PG : I removed its "terminate" authorization... No difference, XPkiller is still able to kill wuauclt.exe (yes by the way, it's actually terminated. You don't see it running in Process Explorer. I did try to run Pmon too, but for some reasons it won't launch on my computer) .

In fact this command line is normal, at least for the first part of it :

Code:

/runstoreascomserver local\[4

this part doesn't change, only the second part of the command (.ie "e0]susds0219cef0fb3c5f4a9104c67240e60ba8 ]") is different everytime wuauclt.exe is started (with or without XPkiller). Look in your own PG logs, you'll see what I mean.

All I can say is that wuauclt.exe is "restarted" by svchost.exe (PG logs), in a way that makes wuauclt.exe beeing closed; then I guess XPkiller is sending special instructions to svchost.exe to cause this event, but I don't have tools to "see it". All I can see for now is which instance of svchost.exe is doing it - which services are loaded within.

Cheers,
nicM

 

The only thing i can assure you is that we are not dealing with a new terminate method. Only a strange command line inside wuauclt. Maybee an error that will close it if it parse an unexpected symbol [ ]. See the screenshot.

Why it is svchost ? Well if i'm not wrong svchost is resposible for the Task Scheduler service. Try disabling this service. XPkiller will not be able to use svchost. You can use a tool like RD or regmon to assure you XPkiller will not switch the service back on.

 

Well, this seems at least to be a command having for result to close the process... - we're playing on words, isn't it? .

I think I'll have to do more tests to try to figure out what's happening here; the trojan is designed to close (and delete files! of) XP firewall, and system restore too (upon auto-updates). As they're not enabld on my system, I'll try to enable it, and see if they're closed too.

I was looking at the list of services loaded in this instance of svchost, and I was thinking about scheduler too; but I'm not sure, there are other services who could be involved. Will try it later, I'm not on this computer right now .

Btw I'm using teh trial of RD too, and I don't get any alerts neither form it when launching KillXP.

 

Task Scheduler is designed to execute task once in a while.
Starting a new Wauclt surely sound like a new task to run isn't it ?

The default rules of RD does not covers service enabling/disabling

The easiest way to cover that is by checking the setValue Box in the rule
HKEY_LOCAL_MACHINE\System\*controlset*\Services\*

However this will cover any service that change a setting.


Maybe monitoring
HKEY_LOCAL_MACHINE\System\*controlset*\Services\*\Start
is a better choise

 

More precisely most popular debuggers. But if there is any custom written intruder I'm afraid it will bypass this 'special code'.

Generaly what about antidebug and antireverse I think the strongest today's protection is ExeCryptor www.strongbit.com. Its main advantage it obfuscates an app code that remains wrapped even when it executes without restoring. Thus there's no debuger that could analyse the 'mess' produced by Execryptor because the code real logic is never restored since it is encrypted.

 

Disallow SVCHOST from installing drivers and try XPKiller again ?

 

did anyone try what gavin suggested? i'm curious as to how this trojan is supposedly bypassing PG. i don't have PG (or understand how to use it) or else i'd try it. gavin want me email you the xpkiller trojan and you can test it?

 

Also EXECryptor 2.x version from starting to use
Code morphing launched in July
2004 remains uncracked. Whatever anybody says in practice 2 years to be

unbroken I think it's very good for an app protector

 

Wayne though u look cold in attending most post of problem I still love process guard services.

It shows that you focus the main priority before others this is a good sign of trust to the security terms.

Thanks for fixing this out soon and thanks to the person Joe for submiting this critical highly require the attention of all users using processguard.

 

ExeCryptor is weak and already cracked, you can find some tutorials like many PE Protector, from Borland NewsGroups I find this link :

http://www.tuts4you.com/index/index.php?dir=Tutorials/Unpacking%20Tutorials

Read this too :
http://www.delphipages.com/threads/thread.cfm?ID=170205&G=170205

The problem is all ExeCryptor user don't know their applications can be crack easily... I see this thread talk about ICE License from Ionworx, this protection is very strong and difficult to bypass because it's integrate directly inside the source code, and use antidebugging and code encryption.

I attemp to crack some applications protected by ICE License, it's was impossible without a full license!

StrongBit cancel all messages from users posted "Cracked Application" to hide for other users, see here the images (file joint rename screenshot.txt to zip and unpack)... so uncracked from 2004....

PeP from SetiSoft is better than ExeCryptor and FREE!, see here :
http://www.setisoft.com/pep.php?lang=en

I think ICE License and PeP, will be provide strong the protection will be very hard to remove!

 

You must understand that in case with EXECryptor http://www.strongbit.com the unpacking is not cracking because VM remains unbeaten. Applications unpacking wrapped with EXECryptor is possible only when the protection is applied with wrong settings. This can make it vulnerable.

The assuming is when the program is morphed and protected in the aggressive mode by EXECryptor it will remain safe.

Also the new release 2.4 of EXECryptor is coming soon. There will be a new protection architecture more strong

 

"PG simply does not work" is too much of a broad statement in my opinion.

PG obviously works against MANY methods of termination, even if not all of them.

Yes, we all want UNBREAKABLE protection from the future RIGHT NOW and I want this, too. However this is not always realistic with new termination methods being devised and released as soon as possible.

I agree though that with the problems highlighted there is a lot of work to do....


At least PG passes the keylogger leaktest related to the SPT post, since I use the "autoblock new applications" feature!

http://syssafety.com/leaktests.html


Best regards,
Lee

 

Just to be a little clearer:

The keylogger will not beat PG when it is prevented from running in the first place.


Since DiamondCS maybe reading this thread, is it possible to improve hook protection methods incase new, better keyloggers are contained within untrusted applications that users may choose to run, please?

Thanks.

Best regards,
Lee