Native API hooked by Regdefend

I'm running the tool KprocCheck , on running kproccheck -t which Native APIs should be hooked by Regdefend?

The reason I'm asking is that I used to test several security software that might fight for the same things, I uninstalled most of them , but i'm afraid the ones I settled on in the end, might have somehow got damaged.

 

Whats going on here?

Why do you ask?

Because someone (guest) asked the same Q about ProcessGuard,and someone called xmen replied that they didn't need to know,now xmen is asking the about it for RegDefend?

Are you legit or programing the next wave of viruses or whatever to take down PG and RegDefend (plus whatever other progs your planning on) or is there a bit team work going on here?

I don't think anyone should disclose this info just incase.!!!!!!!!!!!!

 

@tonyjl

I don't know what's going on with you ;-) But if you read all the post again everything will make sense to you. Please also compare the date/time of the postings.

 

Any decent software will be able to copy with multiple programs "hooking" into the kernel API. In the past, some poorly written software had issues with such things, but those issues today aren't as common.

 

Thanks Jason.

I was actually also concerned about whether another malicious program might have replaced Regdefend in terms of hooking. If so would kproccheck detect it?

If two programs both hook say Zwsetkey, will both work? Or will the last one to be installed have priority?

To Tonyji , quit being so paranoid. Just because I'm curious and want to learn more, does not mean that I'm out to "program the next wave of viruses and worms to take down PG and Regdefend". If i'm truly capable of that, I certainly doesnt need to ask such a basic question.

I also find it laughable that someone who has dreams of reverse engineering PG or Regdefend would need to ask such a basic question.

Besides as one of the other mysterious guests points out,

Sometimes I wonder if the policy of Wilders Security forum is to hawk as many products as possible while keeping users as ignorant as possible. Maybe this makes it easier to fool the users? This certainly explains why any halfway technical question is being treated as an attempt to "hack".

Truly barely nine out of ten people can use security software, and havent a clue what API functions are (i'm one of them btw). But arent the people here supposed to be above the norm? Arent we supposed to learn more? Arent we oh so proud about how knowledgable and educated we are compared to the average Joe?

(It certainly seems that way, when we go to people's homes and start telling them how their Antivirus and firewall sucks.)

Is this vaunted knowledge merely limited to talking about "layers", pointing to "AV comparitives" as a judge for AV superiority and being able to comment on how memory light a software is?

Would it really hurt, for people who walk around here sprouting terms like "hooking" as opposed to polling to promote Regdefend, actually have some idea about what is actually hooked? Why is an attempt to learn more, automatically treated as suspicious?

Of course, you could be like 99 out of 100 people who bury their head in the sand and hope or THINK that the products they buy works without understanding on even the most basic level how the vodoo magic works.

Is that what we really encourage?

As it is, since you guys are so closelipped, I'll simply, format , reinstall PG and Regdefend , run kprochceck and I'll have my answer.

I fully understand that this isn't the place to start lectures on what hooking is, but given that PG and Regdefend as hordes of fans selling the product on the strength of "hooking", a little discussion wouldnt be out of place.

In any case, at least Jason hasn't closed this thread, unlike the sister thread in the PG forum. I appreicate that.

Thank you.

 

I just tested by running Sysinternals Regmon. When I run kproccheck, it lists ZwSetValueKey as being hooked by regsys.sys (regmon) instead of regdefend.sys (regdefend).

I presume both will work normally, but Regmon as priority?

So it seems this tool can be useful if used together with a knowledge of what APIs are normally hooked by Regdefend and Processguard.

 

I can assure you the owners of this site Welcome any and all threads in the non specific software forums that might be thought provoking as long as such threads adhere to the TOS. To think otherwise shows lack of knowledge and history of Wilders concerning the 2 owners.

Very true....and as a Global Moderator....I like you must adhere to the wishes of the software specific forums in regards to what they feel can be discussed and what can't....but....Please feel free to start a thread in a more appropriate General Forum concerning lectures on what hooking is.

 

Nice discussion guys I missed it for a while.

Doesn't mean a thing if you're logged in or not

Anway

Quote by Xmen: "Or will the last one to be installed have priority?"

Good question: at the moment the only thing to do is to check it on our own. That's ok.

But that's not the question...

there are many questions .. waaaaay to many and it's good to ask doesn't hurt and we can always learn from it ..
Of course someone skilled enough won't ask those questions. That's why there is no problem at all. At one stage or another...this would be asked by everyone.

THANK YOU

 

In a hooking chain, the last installed item gets "called" first. So if RegDefend was running, it would be the last link, if you then run say Regmon, it becomes the last link. The last link gets to see the item first, if the last link blocks something from occuring, the next links in the chain won't see it. This isn't a security risk, since if something is blocked it doesn't occur and no changes occur. However, the other links in the chain wouldn't see this block, so it might be a little confusing, which is why you shouldn't run multiple programs which protect the same thing.

The only security risk is if something can allow something around the other links in the chain, which isn't really possible (it could theoritically be done, if you have kernel access and find the original function, but it isn't that reliable).

 

I had to look up Native API to find out what it is. I think this article gave me a beginning to understanding what Native API is:

http://www.sysinternals.com/Information/NativeApi.html




Starrob

 

Jason, the theorectical security risk with this chaining would cause a buffer overflow cause of all the hooking and possible conflicts?

Yes Starrob, Sysinternals is a great place and I found a lot of info there. Nice tools and available for everyone cause it's free.

 

Starrob,
You might find some interesting reading in the Sysinternals "Microsoft Windows Internals, Fourth Ed" book online at Oreilly's Safari here if you want to use up part of your free 14 day trial or if you have an account already

There is another book Windows NT/2000 Native API Reference (referenced on the sysinternals site) but this is a book that can be useful when you are armed with a kernel debugger wanting to see what is going on and understand the details of how things work (ie: it isn't really useful unless you have some sort of a programming background and are willing to invest non-trivial amounts of time into learning)

Regards

 

Jason:

Thank you for not closing this thread. Your expert advice is highly appreciated.

I have the following question relating to the various ways to implement a hook:

Which ways to implement a low-level hook can be accessed from user-mode? In order to facilitate the answer I refer to the following picture from a Sysinternals' article ( http://www.sysinternals.com/Information/NativeApi.html ):

http://www.sysinternals.com/images/screenshots/NativeApi.gif

I ask this question because I understand that you do not necessarily require a kernel-mode driver to install a low-level hook (notwithstanding the fact that the System Service Dispatch Table (SSDT) can be accessed only from a kernel-mode device driver because this table is protected by the operating system so that user-level applications cannot read or write these memory locations).

 

You don't necessarily need a "device driver", all you need is kernel access, which most applications gain by installing a driver. As far as I am aware the system will only allow addresses from the kernel memory region (>0x80000000 by default) to be put into the SSDT, though I havn't personally tried putting usermode addresses in there so take that with a grain of salt.

 

Thanx Jason! No prb, I guess it's still for everybody a difficult thing .. but you were always as close as complete .. again for the same money you would be talking about bunnies and how it was in the old days

while my knowledge is limited in this area would putting usermode addresses not defeat the whole 'security' aspect of kernel driven apps?
Thanx anyway.

 

Jason:

"You don't necessarily need a "device driver", all you need is kernel access"

Thank you for this confirmation. I wonder whether a system firewall like Process Guard will always prevent unauthorized kernel access (although no driver installation is required)?

 

It actually prevents most unauthorized attempts (blocking physical memory access also helps). I think one or two of the newer ones might get past it, however they are fairly complex to utilize and probably still more theoretical than anything.