Re: InjCode.cpp

From: Paul Mayer (p_c_mayer_at_yahoo.com)
Date: 01/16/04 

Date: Fri, 16 Jan 2004 12:08:18 +0000

On Fri, 16 Jan 2004 11:28:55 -0000, Simon wrote:

>> Im a little new to this so please bear with me. Why would it matter if
>> user32.dll was remapped?
>>
>>
>> hUser32 := GetModuleHandle('user32');
>> DataLocal.fnSendMessage := TSendMessage(GetProcAddress( hUser32,
>> 'SendMessageA') );
>>
>> Surely this would always get us the valid start address of the sendmesage
>> function in process (a). If I have understood correctly you are saying we
>> should get the start address of the sendmesage function from the target
>> process (b). Why does it matter?
>>
> Because the addresses could be different. A process can not call an address
> in another processes address space - that will produce an access violation.
>
>> When you talk of sufficient rights, would that be the security attributes
>> parameter in CreateRemoteThread?
>>
> The security attribute in the CreateRemoteThread is for processes that want
> to use that handle (hThread), not for the injection itself.
> IIRC, the application that does the injection normally inherits security
> attributes from the logged on user - this security must have rights for the
> injection process.
> You can make the app use another account by LogonUser and
> ImpersonateLoggedOnUser - check the Windows SDK help for descriptions.
>
> Good luck, Simon

Thanks Simon

I think I just about get it. One thing though. The InjCode copies a pointer
to the InjCode thread we create in the target process(b), which is the
pointer to the sendmessgage function in process(a) (usr32.dll), rather than
the sendmessage function in process(b) (usr32.dll)

But surely both sendmessage functions will always be loaded at different
addresses? When the injected thread runs it will call the sendmessage
function from process(a), which should cause an AV.

Sorry to be such a pain.

Paul Mayer