trogan hunter and PG

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.

 

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) 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

 

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.

 

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

 

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

 

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.

 

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.

 

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

 

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

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.

 

"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.

 

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.

 

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:

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

 

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-

 

hmmm, Magnus closed that thread

 

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?).

 

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

... 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.

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

 

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 ...

 

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)

 

"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.)

 

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-

 

> 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.

 

"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 ...

 

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

 

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.