trogan hunter and PG

[donsan709]

I downloaded a copy of trogan hunter and when i run it process guard go's crazy log after log even after ticking all the allowed flags and no blocks.It logs so fast i can't even run the program. I have disabled PG started TH and then restarted PG thinking that might help but that didn't help. I have bo clean running in memory so not to worried about not being protected but i wanted a on demand scanner and by the way i did shut down bo clean before i started trogan hunter guard. Any idea's on what might be happening and how to fix it? one thing for sure i will not give up PG just to run trogan hunter.

[Wayne - DiamondCS]

This is due to the strange nature of how TH attempts to protect itself - it attempts to inject a DLL into every process in your system which then tries to modify code in the process so as to change its behavior, and tries to do this every few seconds which is why your PG log screen is quickly filling up with TH entries. TH is the only program we know of that does this, and it's a very ineffective protection method (for example it fails all of the termination methods in Advanced Process Termination (http://www.diamondcs.com.au/index.php)) but I believe there's an option in TH where you can turn off such protection, so if you do that you'll no longer see all those TH alerts and you can then just use PG to protect TH.

Regards,
Wayne

[donsan709]

Thank you Wayne for the quick respone i new i should have bought tds.I think i will just leave trogan hunter alone and not mess with it and just wait for tds 4 to come out because i would like to get rid of all this loging in pg i still have that problem with bo clean but not near as bad.Maybe i can burn TH to disk and give it to my son.

[Gavin - DiamondCS]

Hi,

The protection is in a file called THSec.dll. If you simply rename this file or delete it, THGuard self protection wont be active. Then just add it to PG to protect it and you should have no problems. Some TH users may come along to help you further if you need :)

[donsan709]

Hi gavin i did a search for that file and couldn't find it.You know i may have downloaded TH when i had PG enabled and i have the dll protection ticked maybe thats why i couldn't find it, is it possible that PG blocked it.thanks for you help

[siliconman01]

I have Windows XP-SP1 Home, TDS-3, TH 3.70, PG 1.15 running well together WITHOUT tampering with THSEC.DLL. In PG, add THGuard.exe and TrojanHunter.exe with all ALLOWS permitted. No messages, no hassle.

[donsan709]

:) Hey thank you adding TH exe did the trick all is good now it seems.Now can i have TH guard and bo clean runniing at the same time or is that a bad idea.

[donsan709]

sorry i ment adding trogan hunter guard exe to PG did the trick no more excessive logging.

[Gavin - DiamondCS]

The reason you cant see the file is because they are not shown by Windows by default. If you prefer to really see what is going on there are a few settings most people change immediately from the Windows Explorer Tools > Folder Options menu

The one we want is "Show all files" not hide system/hidden files

I recommend you UNtick "hide extensions for known file types" and "hide protected operating system files" in this same box, then OK to the changes. A folder could look empty and be deleted if you cant see whats really in it :o :-[

Unhiding the extensions means an EXE file will look like FILE.EXE and a JPG will look like FILE.JPG

As it stands, those would look like FILE and FILE respectively, however FILE.JPG.exe would look like FILE.JPG, probably the oldest trick in the book for attackers to trick someone.

[Randy_Bell]

-{ Quote: " quoting: donsan709 link=board=40;threadid=18995;start=0#msg116805 date=1073387043]Now can i have TH guard and bo clean runniing at the same time or is that a bad idea.
" }-

"bad idea", IMHO ... just like running two antivirus (AV) realtime monitors (RTMs) at the same time, they can "collide" and cause problems. Use one product (TH or BOC) as resident protection and the other as manual backup. Since BOC has no manual scanner and is designed to be resident, you might as well go with BOC and not use the Guard. If you had TDS you could use the resident Execution Protection of TDS .. but don't run more than one of the realitme monitors of different antitrojan products at the same time; they could collide and cause unpredictable results, even system instability, hangs, lockups .. JMHO.

[siliconman01]

IMHO, I have mixed "emotions" on what should or should not be run together.

For example, NAV 2004 is a virus/trojan/worm/adware cleaner and runs resident. AdAware's Ad-Watch is for spyware/adware, etc., and runs resident. Pest Patrol's PPmemcheck and CookiePatrol are trojan, adware/spyware/cookie guards and run resident. TrojanHunter's THGuard is a trojan guard and runs resident. WormGuard is a worm guard and runs resident. And of course TDS-3 has Execution Protection running resident. Plus now we have Process Guard running resident and guarding.

I have them all running together and have not seen any conflicts or system problems on my Windows XP-SP1 Home system. I even have SpyWareGuard running for BHO and Browser Hijack Protection (do have the realtime scanner turned off).

I dunno....maybe there will be a WOW problem if I get hit with a big Trojan. But for now, my opinion/feeling is that unless a problem surfaces or the system acts abnormal, grab all the protection your system can handle. ;)

The only one I am explicitly cautious about is Windows XP firewall being turned off because I use NIS 2004 as my firewall and Norton expresses strong warnings about conflicts with Windows XP firewall. I guess it boils down to the software vendor specifically stating that X program cannot/should not be run with Y software concurrently.

Just my experience...thus far.

[Randy_Bell]

-{ Quote: " quoting: siliconman01 link=board=40;threadid=18995;start=0#msg116975 date=1073423401]
IMHO, I have mixed "emotions" on what should or should not be run together.

For example, NAV 2004 is a virus/trojan/worm/adware cleaner and runs resident. AdAware's Ad-Watch is for spyware/adware, etc., and runs resident. Pest Patrol's PPmemcheck and CookiePatrol are trojan, adware/spyware/cookie guards and run resident. TrojanHunter's THGuard is a trojan guard and runs resident. WormGuard is a worm guard and runs resident. And of course TDS-3 has Execution Protection running resident. Plus now we have Process Guard running resident and guarding.

I have them all running together and have not seen any conflicts or system problems on my Windows XP-SP1 Home system. I even have SpyWareGuard running for BHO and Browser Hijack Protection (do have the realtime scanner turned off).

I dunno....maybe there will be a WOW problem if I get hit with a big Trojan. But for now, my opinion/feeling is that unless a problem surfaces or the system acts abnormal, grab all the protection your system can handle. ;)

The only one I am explicitly cautious about is Windows XP firewall being turned off because I use NIS 2004 as my firewall and Norton expresses strong warnings about conflicts with Windows XP firewall. I guess it boils down to the software vendor specifically stating that X program cannot/should not be run with Y software concurrently.

Just my experience...thus far.
" }-

Whew Boy siliconman, you have quite a lot of *stuff* running resident there! I suppose, conceivably since TDS doesn't do memory scanning, and TH Guard is just a memory scanner, those two might not conflict: TDS Execution Protection scans the disk image before the program is allowed to execute {load into memory}; TH Guard only scans the same process once loaded in memory.

BOClean and TH Guard, however, are *BOTH* scanning memory. Since these two ATs are scanning the same process space at the same time, it would be ill-advised for those to run resident together at the same time, IMHO. ;)

[mozarT]

As for APT and THs THSec.dll - seems like this software is very vulnerable. According to the software developer from Trojan Hunter, this .dll has to be rebuild completely in order to cope with this, as he does state on his support forum himself:

-{ Quote: "It actually seems that APT uncovered a condition under which the protection was not working as expected (but not due to any inherent limitation in the method used - simply a simple programming error that, although it wouldn't surface during normal operation failed in this instance)." }-

Personally I have nothing against TH. For the benefit of TH users though, such a public statement should be known. Users should know what is going on, besides in a developers forum.

I really do wish this issue will be solved - soon!

mozarT

[Jason_DiamondCS]

Well I just read on the TrojanHunter forum that the developer says we patch the kernel with Process Guard. This is true, we insert Process Guard as a link in a chain, this requires us to change a 4 byte pointer. The difference between changing a "pointer" compared to inserting your own code is great. We are not overwriting any other code with Process Guard, so the kernel stays in the same state always. Hooks like the ones used in "user-mode" based hooking actually rewrite code, the reason they are forced to do this because there is no mechanism for them to change a simple pointer so they can put themselves in a chain like condition.

So just to clarify, when the operating system provides a mechanism for new functions to be added to extend its behaviour, even if its undocumented, this is the IDEAL way to do it. Inserting your own code in every function you want to hook is not a reliable way of doing it, malware can (and probably will in the future when they get smart enough :) ) easily remove these hooks. No user mode program can stop a process from modifying itself with basic instructions, this is a fact. Regardless of what anyone else tells you.

What you have with "user-mode" based solutions is a process trying to stop another process from doing something by changing that process's code. This will never work 100%, ever. We have exhausted all "user-mode" research and whilst it is easier to implement such systems, they do not meet certain vital security and performance criteria.

When in kernel mode it is like you CAN be any process you want, and since there are areas of memory which "user-mode" programs cannot touch without causing a crash you are safe from "user-mode" programs trying to do things to your protection.

The reason APT works is not due to any error in TrojanHunter that can be fixed. It is an INHERENT flaw in user-mode protection. The next version of APT will solidify this as the current public version still uses quite simple "anti usermode" protection. Any trojan can do this same "anti usermode" protection and be safe from any protection scheme relying on it.

-Jason-

[DolfTraanberg]

hmmm, Magnus closed that thread :'(

[ano1]

1.
I have already stated that I like PG. It's good that SetWindowsHookEX will be covered soon.

2.
It may be true that you will find a way to terminate TH (even when it uses the new .dll that has been introduced by Magnus). On the other hand, no trojan has ever used such methods. Moreover, AV termination is stupid since it warns the user that something is wrong. The most dangerous trojans will not terminate anything.

3.
In all fairness we should mention that TH's termination protection has never caused huge problems. It did not make the computer unstable since it was properly implemented.

PG's kernel mode method is probably even more effective but - sometimes - it still causes blue screens, doesn't it? I believe that no TH user has ever experienced a blue screen.

4.
Personally, I believe that TH's termination protection is good enough.

PG is much more than just termination protection. It stops any DLL trojans from injecting themselves. The same applies to several rootkits (but not Hacker Defender?).

[Wayne - DiamondCS]

-{ Quote: "It's good that SetWindowsHookEX will be covered soon." }-
A lot of progress has been made towards this, and we've essentially got it working, now just need to implement it in Process Guard. When this is done, virtually all keyloggers will have their keylogging capabilities rendered null and void. Firewall leaktests that use SetWindowsHookEx (like Firehole) will also be unable to work, and termination attempts via SetWindowsHookEx are also blocked. Three birds with one stone :)

-{ Quote: "On the other hand, no trojan has ever used such methods." }-
... that you know of ... :)
There are several trojans that terminate security processes (Bionet and The Beast spring to mind), and most termination methods are actually very easy to program in virtually any programming language, so if trojan authors want to use them then they're their for the taking.

-{ Quote: "Moreover, AV termination is stupid since it warns the user that something is wrong. The most dangerous trojans will not terminate anything." }-
So you're saying The Beast isn't dangerous? :)
Actually, most terminations aren't visible unless the security program is being used by the user at the time. Most security apps simply minimise to the system tray, so all you can see anywhere on your screen that this program is running is a system tray icon. If you then terminate the process you'll find that there is actually no visual indication - the systray icon will still remain (until you hover your mouse over it). It just makes sense for a trojan to terminate security applications as it "clears the road" to allow it to accomplish it's objectives, and if it means waiting for the screen saver to become active before terminating security programs, then it can wait also :)

So the conclusion - because all user-mode protections can be undone/skipped by other user-mode applications (such as trojans) they're unacceptable for use in security software as a means of protection. The only real option is a kernel-mode driver, which is what we've had to do for Process Guard. We would've implemented user-mode hooks if it was a viable option as they're certainly a lot easier to develop, but this is a question of security, not ease-of-programming.

Regards,
Wayne

[ano1]

1.
Keylogger protection -- very good.

2.
IMHO Beast is moderatetly dangerous. But not due to its process termination feature. I believe it has also a CD open feature ;-)

ColdFusion is really dangerous ...

[Wayne - DiamondCS]

However, termination is one thing, but a trojan could just as easily suspend the program instead (thus neutralising it but without causing any visual changes, so the user would be less aware).

And then there's modification ... :)
In the Process Guard helpfile there's a page that shows how a trojan could modify just a couple of bytes in a known firewall to essentially make the firewall allow all traffic. Such a trojan could also modify an anti-trojan program so that it didn't detect anything. Process Guard's kernel-mode driver prevents this class of attack, but it's impossible to properly protect against it with user-mode hooks so the kernel-mode driver was basically our only option to properly block the attack. (Mission accomplished) :)

[ano1]

"And then there's modification ..."

Exactly ... that's why I like PG.

In addition, I did not say that it is useless to protect a firewall against suspension attacks etc. (I was merely talking about AV scanner termination protection. TH cannot protect other programs.)

[Jason_DiamondCS]

In my opinion, security programs should be protected by something, especially against memory patching, termination, suspension,etc. It doesn't take much for a malware author to identify where in memory/file an antivirus checks to see what files are malware. All it needs to do is simply patch those values and no malware will get detected again.

This could only be the "ideal" method for malware too.. it could fall back onto other things like suspending the app, crashing it, terminating it, adding its own thread which consumes memory and cpu, the list goes on.

Adding anti-usermode protection doesn't just make TrojanHunter's protection not work, there are other apps out there like SSM which use these methods. So it isn't like malware needs to target TrojanHunter or any specific app, it just checks and removes the user mode protection ALWAYS before doing what it does. This ensures that the malware will at least be protected from user-mode hooking security programs.

-Jason-

[Gavin - DiamondCS]

> No trojans "that you know of"

A coder who goes by the alias M3DU54 (Medusa) wrote papers on LSP trojans 4 or 5 years ago. This is now being implemented by the upcoming Lithium RAT. Shows how far the "public" scene is behind sometimes. Same with DLL injection which was in BO2K. Those dangers exist, security software is going to have to go on the offensive in the future. PG demonstrates our committment to provide a real solution to ANY threat we can - known, theoretical, whatever. There are no public LSP trojans yet, so what they arent a threat ? They have been a possible threat for a long time, and possible threats are bad :)

Detecting trojans after lots of people have already been infected because its ITW and gets sent in is not a good enough option. Its too late, a rootkit emphasises this. A driver based rootkit could sit there and hide for a long time, but if it was prevented in the first place it would trigger an alarm in PG and be submitted. In the area of DLL injectors.. PG even cleans them, just reboot after installing it and they wont be injected next time. This isnt possible in a user mode hook, and if that DLL trojan also uses API hooking to hide itself from FindFilexxx APIs, its already beaten many scanners.

[an9]

"So it isn't like malware needs to target TrojanHunter or any specific app, it just checks and removes the user mode protection ALWAYS before doing what it does. "

@Jason

An interesting statement. However, I am not sure whether I correctly understood it. Do you mean that it is possible to remove any user-mode api hooks in a generic manner w/o knowing any details about the application which has installed the hooks?

Or are you referring to the possibility to terminate applications which have installed api hooks?

(I do not consider mem or file patching of AV/AT scanners to be a pratical way of disabling them. It's too much work to figure out the details about every version of each scanner. It's easier to pack & patch the malware itself. More or less the same applies to firewalls -- see BlackStealth which only supports a few of them. A generic way like suspending security apps would be easier to implement. I am not sure, however, whether this will work in connection with a firewall, i.e., whether this will result in any traffic to be allowed.)

@Gavin

"Shows how far the "public" scene is behind sometimes."

Agreed ;-) But don't tell Olympus. He is rather quick-tempered ...

[Wayne - DiamondCS]

-{ Quote: "Do you mean that it is possible to remove any user-mode api hooks in a generic manner w/o knowing any details about the application which has installed the hooks?" }-
That's correct. None of this (APT, Process Guard, clearing hooks, etc) is related to any particular process - it's equally effective against all, this isn't process-specific.

Even without knowing about any particular processes or how they hook there are many, many ways to clear user-mode hooks, as well as bypass them, as well as detect them. At its simplest, detection can be as easy as calculating checksums for particular sections of the process - if the checksum has changed then it's a usermode hook or code modification has taken place (or debug breakpoint in the case of debuggers). Bypassing can be as simple as the executable 'carrying' the required functions it needs (rather than calling them from kernel32.dll and so on). Clearing hooks can be as simple as copying code from the files on disk back into memory, over-writing any hooks that might've been put in place. Very simple, very easy for any programmer in any programming language (trojan authors won't have any problems doing this), and requires no knowledge of any particular processes or hook implementations.

Regards,
Wayne

[ano1]

Wayne:

Many thanks for the explanation. I would like to bother you with one more question (since this topic is quite interesting ;-)

Let's assume there is a keylogger which does the following:

// call win API to install hook
hkb = SetWindowsHookEx(WH_KEYBOARD,
(HOOKPROC)KeyboardProc,hInstance,0);

Is it now possible to clear this hook in the way already described: "Clearing hooks can be as simple as copying code from the files on disk back into memory, over-writing any hooks that might've been put in place."?

Thanks.

[Wayne - DiamondCS]

ano1,
SetWindowsHookEx only allows the DLL to load into the target process(es), that's all. In order for a program to hook API functions this way code modifications/patching in memory still needs to take place, and it's those modifications that can be easily detected, and bypassed, and cleared. The DLL itself doesn't actually matter - it's the changes that it makes to the process that it modifies that's the main thing.

Regards,
Wayne

[ano1]

Hi Wayne:

I mentioned SetWindowsHookEx in order to make sure that we are not talking about GetAsyncKeyState keyloggers.

I agree that we can forget about the DLL. Some keyloggers do not even use a DLL. For example, Fearless Keyspy 2 seems to be based on a separate process. ( It uses the following hook: "invoke SetWindowsHookEx, WH_JOURNALRECORD,addr JournalLogHook,hinstance, NULL".)

What I do not completely understand is your comment: "In order for a program to hook API functions this way code modifications/patching in memory still needs to take place, and it's those modifications that can be easily detected, and bypassed, and cleared." Why is it so easy to detect the hook? Where in memory do you search for it? And from which file on disk do you copy code back into memory in order to over-write the hook?

Thanks for helping me out.

[Wayne - DiamondCS]

SetWindowsHookEx and GetAsyncKeyState are different, yes. GetAsyncKeyState is a bit easier to program, but requires a timer set to 1ms to check literally every millisecond for a keypress. It's more CPU-intensive and less accurate than SetWindowsHookEx which is why most trojans use that rather than GetAsyncKeyState, even though SetWindowsHookEx is a little trickier to code. There are also quite a few OS-specific issues that you should be aware of if using GetAsyncKeyState as a keylogger (see MSDN for more).

GetAsyncKeyState, like SetWindowsHookEx, is a Windows system service (both eventually go to kernel-mode code with a jump from INT 2E/SYSENTER, so the only way to secure them is with a kernel-mode driver. We've secured the latter, and we can secure GetAsyncKeyState as well if we choose, but it's not really a priority at this stage as it doesn't allow the using process to use GetAsyncKeyState to terminate other processes (whereas SetWindowsHookEx does offer that capability), and Process Guard is more about preventing terminations than preventing keylogging, but preventing most keyloggers is just an incidental side-effect of securing SetWindowsHookEx :). We're not ruling out adding it later though, but at this stage it doesn't seem necessary.

-{ Quote: "For example, Fearless Keyspy 2 seems to be based on a separate process. ( It uses the following hook: "invoke SetWindowsHookEx, WH_JOURNALRECORD,addr JournalLogHook,hinstance, NULL".)" }-
This is still a global hook, as defined by the NULL as the last parameter. This would easily be blocked by the next update to Process Guard (probably next week).

-{ Quote: "Why is it so easy to detect the hook?" }-
Because you know what code should exist in your program, so comparing that with what is actually there, or simply checksumming to detect differences, is all it would typically take to detect any changes (such as a user-mode hook, or code modification).

-{ Quote: "Where in memory do you search for it? And from which file on disk do you copy code back into memory in order to over-write the hook?" }-
I think I've given you enough information for now in regards to this. Any programmer who needs to clear usermode hooks will figure it out pretty quickly and won't have any problems doing so, but as this info can help trojan authors I'm reluctant to go into specifics, even though such attacks aren't relevant to our own software (as we don't use user-mode hooks).

Best regards,
Wayne

[an10]

1.
"Once a hook DLL is loaded into the address space of the targeted process, there is no way to unload it unless the Hook Server calls UnhookWindowsHookEx() or the hooked application shuts down. When the Hook Server calls UnhookWindowsHookEx() the operating system loops through an internal list with all processes which have been forced to load the hook DLL. The operating system decrements the DLL's lock count and when it becomes 0, the DLL is automatically unmapped from the process's address space."

(see http://www.codeproject.com/system/hooksys.asp )

2.
How do I get the handle required for UnhookWindowsHookEx if I do not have installed the hook?

3.
Can I copy code from the file USER32.DLL to the memory in order to over-write all hooks? Would this crash the system or some applications?

4.
I wonder whether a tool which can clear all user-mode API hooks in a generic manner will actually increase security. A clean OS w/o any user-mode API hooks does not seem dangerous to me.

[Wayne - DiamondCS]

You're getting confused between API hooking and the actual SetWindowsHookEx hook itself. SetWindowsHookEx will load the library into the target process, and for example if it's hooking keystrokes then it will receive those, but that's about all - the hook alone doesn't change the behaviour of any API functions. However, at this point the DLL can then modify the code in the process as if it were its own, for example to change the behaviour of an API function used by that process (typically the API function would be 'redirected' to a function in the loaded DLL which then determines how it should be handled). So, clearing the code modifications is easy, but unloading the actual DLL is somewhat harder (but not necessary anyway).

Regards,
Wayne

[an11]

"You're getting confused between API hooking and the actual SetWindowsHookEx hook itself."

Not really ;-) Just trying to explore different methods.

Don't you think, Wayne, that a tool clearing ALL user-mode hooks would be useful? I believe it would increase security since the user would have the choice to "clean" his system. Any malware depending on user-mode API hooks would be disabled, wouldn't it?

If it's so easy to clean API hooks in a generic manner (not targeting a specific application) why not developing such a tool?

[DolfTraanberg]

-{ Quote: " quoting: an11 link=board=40;threadid=18995;start=30#msg118310 date=1073737487]
If it's so easy to clean API hooks in a generic manner (not targeting a specific application) why not developing such a tool?
" }-Hmmm, a number of applications wouldn't run as designed anymore, I suppose??
Dolf

[Wayne - DiamondCS]

an11,
User-mode hooks have valid uses such as API Monitoring, so making such a tool to clear them probably isn't ideal. Also, our development schedule is already full with PG, TDS4 and WG4 so if somebody else wants to make such a tool they're more than welcome, but we simply don't have the time. However, user-mode hooks are inherently insecure and they were never designed for security which is probably why TH is the only security program we've ever seen that tries to gain security this way.

To elaborate on some of the main reasons why it's insecure (and thus not appropriate for use in security software):
- SetWindowsHookEx only works on processes that have user32.dll loaded, and for a trojan that library isn't really necessary (and even if the trojan does need just one or two functions from user32.dll it can easily carry those functions in its own program rather than using the user32.dll one. For example, it can easily just import psapi.dll to enumerate processes and kernel32.dll for the TerminateProcess API, so that process wouldn't get hooked anyway.

- it requires modifying code in existing processes (as many as possible), and as it does this rather generically it's then easy for a trojan to specifically target the changes that were made, and reverse them.

- anything in a user-mode process can be modified/corrupted/destroyed by other user-mode processes. Kernel-mode code (such as that used by Process Guard) cannot by modified by user-mode code, and because Process Guard then puts in place protections against kernel-mode attacks also, even other kernel-mode drivers can't tamper with the Process Guard driver.

- it requires having a new DLL (not user32.dll, but the actual DLL that provides the new code used by the hooks) load as a seperate instance into every process, which is a significant resource hit.

- Such hooks can typically only be applied once. If you had a second security program that also tried to protect itself this way then there would almost certainly be conflicts, unless both programs knew exactly what hooks/code modifications were in place. So having said that, you can imagine that if the two programs were written by two different companies then they probably wouldn't have the required intimate knowledge of exactly what changes the other is making.

You could argue that "something is better than nothing", but when that something can cause so many problems as outlined above, and knowing how easy they are to remove, it actually does equate to virtually nothing.

Yes it's a lot EASIER and FASTER to implement a user-mode hook than a kernel-mode solution, but SECURITY is the issue here, and as user-mode hooks just equate to a 'bandaid' that can be pulled off even easier than it was applied, giving our users such a false sense of security is just something that isn't an option.

Regards,
Wayne

[Jason_DiamondCS]

I might just add, that for every area of memory that usermode hooks patch, it requires even more physical memory. Usually kernel32.dll/ntdll.dll/etc are not modified and the one file mapping is used for every process, limiting the amount of memory usage. For example, it is no point loading a DLL 50 times into memory for each process when it never actually changes, this is a good Windows optimization.

When you go modifying these DLL's in each processes address space Windows allocates memory for each page you modify since that DLL no longer exists as it did on the disk. Since a lot of usermode protection schemes patch every process you dramatically increase resource usage SYSTEM WIDE, you won't really notice that much difference in EACH process, but if you add them all up you could see it quite easily.

-Jason-

[Olympus]

-{ Quote: "> No trojans "that you know of"

A coder who goes by the alias M3DU54 (Medusa) wrote papers on LSP trojans 4 or 5 years ago. This is now being implemented by the upcoming Lithium RAT." }-

This is not correct. Lithium v2 will not be LSP based, this was abandoned months ago.

[Pilli]

Thanks for the information Olympus but you are replying to a post made nearly five months ago?

[Gavin - DiamondCS]

Ok Lithium WAS going to be installing a LSP.. it was supposed to be released on 31st December 2003 and has been used "beta" since before then, I doubt much would detect the beta versions unless someone found it on their machine. This is the problem for security conscious users, for everyone.

If its DLL injection, I doubt it can't be blocked quite simply with PG. Sure a lot of trojans will move on to far more powerful, stealthy advanced stuff. So will we when its needed :)

[Curious1]

Olympus:

Why did you give up coding a LSP RAT? Would you mind to tell us about the problems you faced? Do you know whether akcom has also abandoned this route?