AppDefend v1.000 Public Beta

Home Page and Click About!!

HTH,

 

The About dialog box title bar for each, AD & RD.

 

Hi also have the same problems can someone explain to me how to solve this? I have seen to manually run the file gssupdater.exe, how do you do that

Thanks,
Atomas31

 

Hi guys,have i missed an update or something? lookin at triple helix's post above (the one with the screenshot of home page of GSS) i noticed the ver. is 1.110 whereas mine is 1.100,and also the tabs at the top are different.

 

Yep, 1.110 was released today.

 

Duh. I did click ABOUT and somehow I missed seeing it at the top. Thanks.

 

I'm guessing the lack of a way to control logging is why GSS.EXE is taking 100 MB on my system, after running for about 9 hours. There are many, many entries related to my BitTorrent client...

 

Which means I should disable logging for that event, but still, should be a way to control when entries are dropped off...

 

Going OT somewhat, while that previous post was somewhat tongue-in-cheek, it has occurred to me that most "hook/rootkit analysis" software only shows the entry point for system functions. If multiple security applications (or malware) are hooking the same call (resulting in a chain of hooks), a proper analyzer needs to follow this chain to identify each one and so far, none seem to do so - perhaps a good entry point for a new product?

 

Paranoid2000 wrote:

A very good idea P2K, this would certainly give you a better idea, on what is going on, on your system.

But for me this is next thing isn't clear yet,
what will be the result, if such a chain of hooks will occur?

Does that mean, that all app's that are hooking the same call,
still work, as they would do, if they were the only one?

Or is it something like, the last one, is the only one that
can hook a call?

If that last scenario is true, you can certainly have problems
if you are using multiple Anti Malware tools.

And i don't even want to think about Malware using the same
hook calls.

Then you certainly need your (Paranoid2000) invented program 'hookdefend'.

BTW: it would be a strange coincidence if programs like
PG and AppDefend and Kav or TPF didn't use the same
hook calls ?

Perhaps i have to run some test with the mentioned apps
to see if there is a overlap.
by installing those one at a time, write down the items found with hook analyzer.

 

I haven't analised it in much detail, but I would hazard a guess that hooking occurs ina chained fashion. If not, then that is certainly bad design on MS's part, although in this case I'm reasonably certain they have done the right thing.

I'm sure Jason could chime in to let us know whether it's on a FCFS (first come, first served) basis, although I would also guess this is probably the most liklely implementation when overlap occurs.

 

I'm pretty certain that each and every application hooking would run with the most recently installed going first.

 

Another interesting option would be to be able to selectively disable hooks. This would allow expert users to selectively enable/disable features (like background file scanning on anti-virus software) even if that ability was not offered by the software itself - and could allow for normally conflicting programs to run together by removing the hook triggering the conflict on one of them.

Hmmm... *dashes off to nearest Patent Office to make an application*

 

It is almost "impossible" to step through a chain generically, simply because each driver/application stores the pointer to the next in an unspecified location. If you knew all the offsets these apps stored the pointer, then you could theoritically walk the chain and change it's working order. Another way might be to disassemble code on the fly to work it out, or possibly even emulation depending upon the way it was created. Either way, it isn't a simple thing to do.

 

SDTRestore works by loading another copy of the ntoskrnl.exe into memory to find the original pointers. Couldn't this information be used to find the offsets for each hooking program? Alternatively, could stack backtracing be used to identify the entry points of every program hooking a function - or changing the interrupt called so that "HookDefend" could intercept every call made? (this would likely be pretty inefficient though).

Pardon me if I appear to be rambling, but this is starting to sound like an intriguing application.

 

The original pointer (found searching physical memory in SDTRestore) would only be stored once in the very first installed hook. It is up to each program to determine where it stores the pointer it grabs from any hook table, as such there is no standard way to retrieve that information.

Stack backtracing could be one alternative way to implement it, however it would be difficult to sort the wheat from the chaff, and it still doesn't allow you to change the chain order without modifying other kernel code, only to "know" what the order is. To change the chain order you need to change at least 2 offsets.

Hooking interupts is another way to "be first" but it is costly, and it is also chained and hence suffers from the same real issues as SDT hooking (for this particular HookDefend application).

 

Thanks for the reply Jason. I guess the best option would be to have a "hook monitor" feature which would be triggered when installing an application - this would then take before and after snapshots to identify what hooks, if any, the application added and this information could then be used for any future hook manipulation. This would only work from a clean install but should avoid any of the problems you mention.

 

The unfortunate issue with dealing with it in this manner is that you have to "rehook" the SDT or whatever you are hooking, every boot. And a driver in an installation may not be activated until the next boot, in which case you would also need a very early boot driver to be able to then monitor the areas you are interested in. I can see timing issues here making any such use of this as unreliable.

The best way that I can think of to go through the chain, would be an emulation or disassembling of the code in question to find all the offsets. It is theoritically possible to walk the chain and modify it, but it is quite a bit of work and messing around to make sure that it would work and that it is stable. I have seen some competitors drivers actually continue rewriting themselves into the SDT also (nice use of resources there), which means you would need to neuter any such driver from doing this if you wanted to make a successful modification.

 

For before and after snapshots, timing should not be an issue. The "before" would be taken when the installer starts (this would probably require user action though, like selecting a "monitor this install" function) and the "after" would occur once the application was completely installed (which again would be at user request). As long as these snapshots are taken of one application install at a time, it should be possible to identify exactly what hooks each application is setting and their offsets.

This would certainly pose problems when modifying hooks - but couldn't this be tackled by creating a "shadow" SDT which would be affected by application read/writes with the real SDT only being updated when HookDefend decides to copy changes across?

 

Well in theory it sounds that simple, however some drivers load earlier than others, unless there was a way to exactly manage the order in which drivers loaded every boot, the results of viewing what has been hooked could be haphazard and not conclusive to the last installed application.

A shadow table (not to be confused with the win32k table) is a pretty good idea. To implement it however would require your driver to always be loaded first and before anything else has a chance to hook anything. You would then either need to modify Microsoft code, or change the original pointer to where the SDT table is and point it to your own. If you modified Microsoft code (some would consider this about 100 times worse than SDT patching) you would have better control over where to send various calls coming in (the shadow or real table for example).

 

Good point - some method of taking a snapshot between drivers loading would help, but this would probably involve even more hooking...

Not to mention the joy of having to patch it with every Windows Service Pack or even hot fix. A better bet might be to modify code outside of Windows itself, like Ntldr - but the possibilities are perhaps best left to another thread. Time to leave this to get back on-topic. Thanks for your feedback.

 

.

If a program that
watches a new program installation? (like: Track'n Reverse etc.)
would see changes, you are perhaps not sure that this was
done by the last installed prog.
But at least give you an idea on WHAT is changed.

And for the record, it might not be the application install
that did this, but i it would be very interessting to see the changes.

Of course, but i am glad i haven't missed this.

Thanks!

 

Wow! ProcessGuard now has a very worthy competitor! Currently, I am a user of PG, but I agree with what an earlier poster said about competition in this area being good for all. One question I have about AppDefend is: Does it alert you while you are using a restricted or limited user account?

 

Hi octogen, At the moment GSS does not support multiuser accounts but I expect that will change as Jason develops this beta or as point update later.

HTH Pilli

 

Pilli, with regard to GSS updates I can confirm that (since admin rights are needed), but aside from that I haven't had any problems under my limited account.