Page 1 of 1

How unprotect a handle using MCH

Posted: Fri Dec 14, 2018 1:11 pm
by pambol
How can i unprotect a protected handle?

Re: How unprotect a handle using MCH

Posted: Fri Dec 14, 2018 6:12 pm
by iconic
What do you mean "unprotect" a handle, exactly? Do you mean from closing it? If so, see the code below:

Protect

Code: Select all

SetHandleInformation(hObject, HANDLE_FLAG_PROTECT_FROM_CLOSE, HANDLE_FLAG_PROTECT_FROM_CLOSE);
Unprotect

Code: Select all

SetHandleInformation(hObject, HANDLE_FLAG_PROTECT_FROM_CLOSE, 0);
--Iconic

Re: How unprotect a handle using MCH

Posted: Fri Dec 14, 2018 6:15 pm
by pambol
iconic wrote:What do you mean "unprotect" a handle, exactly? Do you mean from closing it? If so, see the code below:

Protect

Code: Select all

SetHandleInformation(hObject, HANDLE_FLAG_PROTECT_FROM_CLOSE, HANDLE_FLAG_PROTECT_FROM_CLOSE);
Unprotect

Code: Select all

SetHandleInformation(hObject, HANDLE_FLAG_PROTECT_FROM_CLOSE, 0);
--Iconic
i called your routine after:

Code: Select all

if DuplicateHandle(hProcess, StrToInt(InfosHandle[1]), GetCurrentProcess(), @hObject, STANDARD_RIGHTS_REQUIRED, FALSE, DUPLICATE_SAME_ACCESS) then
but handle flags still the same, i tried retrieve actual flags using GetHandleInformation but always return 0, and the handle are set as inherit (i'm looking using Process Hacker).
i'm trying close a protected handle, i can list it fine, but the question is to close if the handle are protected.

Re: How unprotect a handle using MCH

Posted: Fri Dec 14, 2018 8:05 pm
by iconic
Unprotecting hObject (which you have duplicated from the remote process) in your own process' handle table will not work. You'd need to call SetHandleInformation() in the context of the remote process with the original source object handle, i.e> remote thread creation etc. Each process has its own unique handle table much like their own address space (on NT)

--Iconic

Re: How unprotect a handle using MCH

Posted: Fri Dec 14, 2018 9:32 pm
by pambol
iconic wrote:Unprotecting hObject (which you have duplicated from the remote process) in your own process' handle table will not work. You'd need to call SetHandleInformation() in the context of the remote process with the original source object handle, i.e> remote thread creation etc. Each process has its own unique handle table much like their own address space (on NT)

--Iconic
Can you show me an example of how do it?

Re: How unprotect a handle using MCH

Posted: Fri Dec 14, 2018 11:25 pm
by iconic
What does (un)protecting an object handle have to do with using MCH? I see no correlation nor do I see a benign use in creating such code. What is your purpose for unprotecting a handle? Is the other process the same bitness as your own process (64 <-> 64, 32 <-> 32 etc.)? Is the other process in a different user session from your own? Many criteria would need to be addressed in writing such a code example. Even if I had more time to write an example for you, how would me writing it for you benefit you in any real way?

--Iconic

Re: How unprotect a handle using MCH

Posted: Sat Dec 15, 2018 5:50 pm
by pambol
iconic wrote:What does (un)protecting an object handle have to do with using MCH? I see no correlation nor do I see a benign use in creating such code. What is your purpose for unprotecting a handle? Is the other process the same bitness as your own process (64 <-> 64, 32 <-> 32 etc.)? Is the other process in a different user session from your own? Many criteria would need to be addressed in writing such a code example. Even if I had more time to write an example for you, how would me writing it for you benefit you in any real way?

--Iconic
I mean if MCH have some function who do it.
Both application are 64 bits and are on the same session.

If you can't help me no problem, i'll try it do it alone :-x

Thanks anyway.

Re: How unprotect a handle using MCH

Posted: Sun Dec 16, 2018 12:13 am
by iconic
There isn't any MCH API for this specifically.

--Iconic

Re: How unprotect a handle using MCH

Posted: Mon Dec 17, 2018 11:01 pm
by madshi
Iconic is perfectly right, as always... 8)