On Saturday, 1 December 2012 at 12:29:51 UTC, js.mdnq wrote:
On Saturday, 1 December 2012 at 11:24:51 UTC, s0beit wrote:
Alright, at the end of my long search I have finally concluded
that this is some sort of threading problem.
Any D module loaded in a new thread, from a C/++ application
will crash. The solution, I believe, in this case might be to
hijack the program's "main" thread and execute your
LoadLibrary call there.
When you call LoadLibrary on a D module from a C++
application's "main" function, everything is fine. When you
call it with a newly created thread (CreateThread or
CreateRemoteThread) it will crash universally. I have not
found a remedy to this issue, but the method to inject your
module by hijacking the thread might work. It's an older
method of injection since before CreateThread APIs came along,
but the basic idea is that you get the handle to the program's
primary thread, get the context and force the Eip to your
destination which calls LoadLibrary. Then you JMP back to the
old Eip.
I'll post here if I have any success with it, I am currently
too busy to test my theory.
Would it be possible for you to write wrapper in C that hooks
into the process then that wrapper loads up your D code? Since
you are saying you can do this in C, and C should be able to
interface well with D, it seems like it should work.
You can probably make something in D to do that, but I must be
clear that it will only work if you're injecting in the main
thread. Anything outside of the main thread will crash.
If you, say, hook a function that is called by the primary
application thread and call your LoadLibrary there it might work
fine.
I think my method of injection (Context hijack on a main thread)
is probably the best to use for D, I'll post some injector code
if/when I get that far.
