You can register a callback function using PsSetLoadImageNotifyRoutine
to receive any image for execution. So, you have opportunity to get
ImageBase and to interpret the PE inside it. And after, you can identify
the EntryPoint of it and make some changes to load your private DLL
during the first steps of this application.
I just done this hooking ZwMapViewOfSection, and I'm not sure if this
would works with this way, but I'd try.
Cheers,
Fernando Roberto da Silva
-----Mensagem original-----
De: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] Em nome de xxxxx@gmx.de
Enviada em: sexta-feira, 9 de fevereiro de 2007 10:06
Para: Windows File Systems Devs Interest List
Assunto: [ntfsd] When to change ETHREAD Win32StartAddress?
I need to inject a DLL into another process space very
early. I know that it's possible to hook NtCreateProcess
as well as NtCreateThread and change parameter
ThreadContext->Eax which obviously sets ETHREAD
Win32StartAddress of the initial thread before
ProcessCreateNotifyRoutine triggers.
Is there any other way to achieve the same thru legal
code? I tried to change Win32StartAddress directly in the
ProcessCreateNotifyRoutine which did not work for some
reason. As I understand process creation user mode
EP should not have been called at that time yet.
Thanks
Questions? First check the IFS FAQ at
You are currently subscribed to ntfsd as: xxxxx@opencs.com.br
To unsubscribe send a blank email to xxxxx@lists.osr.com
That depends on your requirements, really (such as how early in process
initialization you really need to be).
The normal sequence when a process is created (undocumented implementation
details, beware changes in future Windows releases without warning):
User APC queued for ntdll!LdrpInitializeThunk. The APC is given an
argument to a stack-based CONTEXT record describing the context to `realize’
after NTDLL initialization.
User APC runs, notices that NTDLL has not yet been initialized, and runs
NTDLL/loader initialization. This includes processing static DLL imports on
the main process image, calling DllMain for those DLLs, etc.
User APC `realizes’ the CONTEXT record passed to
ntdll!LdrpInitializeThunk via NtContinue.
Control is now transferred to (typically) kernel32!BaseProcessStartThunk
and then to kernel32!BaseProcessStart (or in Vista, ntdll!RtlUserThreadStart
and then to kernel32!BaseThreadInitThunk).
The kernel32 thread init stub transfers control to the `real’ entrypoint
in the main process image.
Now, as far as I know, there is no real documented good way to change the
entrypoint of a process. The safest approach is to do something like call
SetThreadContext on the thread to set the initial' context. This will put you in at step 4 (in the above list), and when you transfer control to the original’ entrypoint you’ll be kicking off step 4. This approach is
reasonably robust and doesn’t involve hooking or patching things. At this
point, you can safely call kernel32 APIs (like LoadLibrary) too, so that
sounds like the best bet for you.
If you need to run code before dll initializers, then that is more tricky.
At that point, you’re pretty much stuck with patching NTDLL (e.g.
LdrpInitializeThunk). I would not recommend doing this, as unless you know
exactly what you’re doing, you’re very likely to introduce strange and hard
to debug problems.
I would stay away from kernel hooking entirely here. I don’t see it buying
you anything, and if there is possibly a more elegant and reliable solution
than hooking you should take it.
–
Ken Johnson (Skywing)
Windows SDK MVP http://www.nynaeve.net
wrote in message news:xxxxx@ntfsd… >I need to inject a DLL into another process space very > early. I know that it’s possible to hook NtCreateProcess > as well as NtCreateThread and change parameter > ThreadContext->Eax which obviously sets ETHREAD > Win32StartAddress of the initial thread before > ProcessCreateNotifyRoutine triggers. > > Is there any other way to achieve the same thru legal > code? I tried to change Win32StartAddress directly in the > ProcessCreateNotifyRoutine which did not work for some > reason. As I understand process creation user mode > EP should not have been called at that time yet. > > Thanks >
> The normal sequence when a process is created (undocumented
implementation details, beware changes in future Windows releases
without warning):
Hey, this is my first trip to kernel land! Will take a while until I get that.
Anyway that’s exactly what I want, no patching/hooking at all, preferable
some documented way which unfortunately doesn’t seem to exist
Fernando, is PsSetLoadImageNotifyRoutine available in NT?
Now, as far as I know, there is no real documented good way to change
the entrypoint of a process. The safest approach is to do something
like call SetThreadContext on the thread to set the `initial’
context. This will put you in at step 4 (in the above list)
Thanks for the excelent education.
Principally I got it working today, however with the expense of registering
three notify callbacks for process, thread, and load image. In load image notify
callback of the process image I call ZwSetThreadContext.
Can somebody please tell me whether these three notify routines are available
in NT4 as well? If not, any idea how to achieve the same in NT?
