Discussion:
Inject a DLL into another process - notepad refuses to cooperate ...
(too old to reply)
R.Wieser
2018-01-12 11:19:12 UTC
Permalink
Hello All,

On XPsp3 I'm trying to inject a simple, (currently) not-doing-anything DLL
into notepad, and am running into a problem:

When I CreateProcess notepad normally, it al works well. But when I create
it in suspended mode it doesn't show up at all (not on yhe screen, nor in
the task manager) -- even though, before my program ends, I can see all the
modules it has loaded, including the injected DLL. Which means to me that
the code I'm using - creating a remote proces by calling kernel32's
LoadLibrary entry point - must be working in both cases.

Does anyone know what is going on here, and(/or) how to solve it ?

Regards,
Rudy Wieser
JJ
2018-01-12 14:53:46 UTC
Permalink
Post by R.Wieser
Hello All,
On XPsp3 I'm trying to inject a simple, (currently) not-doing-anything DLL
When I CreateProcess notepad normally, it al works well. But when I create
it in suspended mode it doesn't show up at all (not on yhe screen, nor in
the task manager) -- even though, before my program ends, I can see all the
modules it has loaded, including the injected DLL. Which means to me that
the code I'm using - creating a remote proces by calling kernel32's
LoadLibrary entry point - must be working in both cases.
Does anyone know what is going on here, and(/or) how to solve it ?
Regards,
Rudy Wieser
If the remote process is suspended, the LoadLibrary() hasn't been called yet
when you check the process' DLLs.

And what do you mean by "creating a remote proces by calling kernel32's
LoadLibrary entry point"? It doesn't make sense. LoadLibrary() can't be used
to create a new process.
R.Wieser
2018-01-12 17:28:48 UTC
Permalink
JJ,
Post by JJ
If the remote process is suspended, the LoadLibrary() hasn't been
called yet when you check the process' DLLs.
I have no idea what you are talking about here. I *can* see the target
processes DLLs (after I've I've injected my DLL that is, not before).
Post by JJ
And what do you mean by "creating a remote proces by calling
kernel32's LoadLibrary entry point"? It doesn't make sense.
LoadLibrary() can't be used to create a new process.
Hmmm. You're right, reading that back it doesn't make much sense.

What I'm doing is calling CreateProcess while pointing it at the LoadLibrary
entry point (and with the argument pointing at a string holding the
to-be-injected DLLs path, which I preloaded into the target processes memory
space).

... which is a method I picked up from thar interwebz.

Regards,
Rudy Wieser
JJ
2018-01-13 21:13:36 UTC
Permalink
Post by R.Wieser
What I'm doing is calling CreateProcess while pointing it at the LoadLibrary
entry point (and with the argument pointing at a string holding the
to-be-injected DLLs path, which I preloaded into the target processes memory
space).
Still doesn't make sense. CreateProcess() can't directly specify the entry
point for the child process.

Anyway, I'l assume that the entry point is changed using other means. Is the
return address for the LoadLibrary() has been set up in the child process'
stack?

If you also use a debug flag for the CreateProcess(), you'll need to execute
WaitForDebugEvent() in a loop. Otherwise the child process will be paused
when it triggers a debug event, because it's waiting for the result from the
debugger process.
Post by R.Wieser
.... which is a method I picked up from thar interwebz.
There are variations of DLL injection which is close to what you've
described. I can't possibly tell the exact method you're using. FYI, there's
at least 3 methods that I can think of.
R.Wieser
2018-01-14 07:34:45 UTC
Permalink
JJ,
Post by JJ
Still doesn't make sense. CreateProcess() can't directly specify
the entry point for the child process.
You're right. I've been saying 'CreateProcess' where ment
'CreateRemoteThread'. Don't quite know how or why that happened ... :-(
Post by JJ
Anyway, I'l assume that the entry point is changed using other means.
Nope. No changing of the (code at) entry point of the targetted process
involved. Just allocating some remote memory, copying the DLLs name into it
and than calling CreateRemoteThread while pointing it at the kernel32
LoadLibrary function, and providing it the remote memories address (which
equals a ptr to the dlls filename) as the argument.
Post by JJ
There are variations of DLL injection which is close to what you've
described.
Is the above method one of them ? :-)

By the way, I've been googeling about the problem, and think I've stumbled
over the reason why it fails: the thread I've been starting (using
CreateRemoteThread) is, as its the first one started, regarded as the main
one for the injected-into process. When it ends some automatic cleanup is
done, throwing some programs outof whack.

In my case I was lucky enough to have choosen 'notepad', which is a program
which suffers from it.
Post by JJ
Anyway, I'l assume that the entry point is changed using other means.
Nope. But in the light of the above I've been busy trying to create a
solution doing just that. Although a testprogram (doing some local
injection) looks to be behaving nicely, I've still need to test it on a
different process.
Post by JJ
FYI, there's at least 3 methods that I can think of.
One of them is overwriting the entry point of the target process (as you
just described)
One of them is probably using SetWindowsHook.
What is the other, last one ?

Regards,
Rudy Wieser
JJ
2018-01-15 15:22:53 UTC
Permalink
Post by R.Wieser
JJ,
Post by JJ
Still doesn't make sense. CreateProcess() can't directly specify
the entry point for the child process.
You're right. I've been saying 'CreateProcess' where ment
'CreateRemoteThread'. Don't quite know how or why that happened ... :-(
Try black coffee. :)
Post by R.Wieser
Is the above method one of them ? :-)
Yes. It's one of them.
Post by R.Wieser
By the way, I've been googeling about the problem, and think I've stumbled
over the reason why it fails: the thread I've been starting (using
CreateRemoteThread) is, as its the first one started, regarded as the main
one for the injected-into process. When it ends some automatic cleanup is
done, throwing some programs outof whack.
In my case I was lucky enough to have choosen 'notepad', which is a program
which suffers from it.
Odd. I'm not encountering that problem with that method - although I don't
use Notepad as the target process when I tested it. I use my own home made
program which is also a text editor. Perhaps a third party tool is
interferring?
Post by R.Wieser
One of them is overwriting the entry point of the target process (as you
just described)
One of them is probably using SetWindowsHook.
What is the other, last one ?
Debug the target process and change its context. i.e. use the main thread to
load the DLL. Process any debug event and detach the debugger before
resuming the target process.
R.Wieser
2018-01-15 17:05:35 UTC
Permalink
JJ,
Perhaps a third party tool is interferring?
Not likely, as I've got no such 'always on' tools installed in this machine.
For pretty much exactly the reason you stated, possible interference with
other programs.
Odd. I'm not encountering that problem with that method -
Thats quite possible, as it seems to need some rather specific circumstances
to be triggered. Notepad being a GUI program which seems to refer to
elements by using a 'global atom' seems to be one of them:
http://www.openrce.org/blog/view/1336/CreateRemoteThread_into_not_yet_initialized_process_
Post by R.Wieser
What is the other, last one ?
Debug the target process and change its context.
I always thought that a process could refuse to be debugged (aka: must have
flag somewhere inside its PE header to allow it being loaded with debugging
permissions), so I never seriously considered going that way.

Regards,
Rudy Wieser

Loading...