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.

Alright, I was finally able to give it a try:
http://s0beit.me/d/d-module-injector/

I released the source code as well as the binary here if anyone wants to try. It worked for me in a game I was playing with.

Thanks, interesting blog :)

2012/12/2 s0beit <s0beit@myg0t.com>:
> Alright, I was finally able to give it a try: http://s0beit.me/d/d-module-injector/
>
> I released the source code as well as the binary here if anyone wants to try. It worked for me in a game I was playing with.

On Sunday, 2 December 2012 at 22:30:56 UTC, maarten van damme wrote:
> Thanks, interesting blog :)
>
> 2012/12/2 s0beit <s0beit@myg0t.com>:
>> Alright, I was finally able to give it a try:
>> http://s0beit.me/d/d-module-injector/
>>
>> I released the source code as well as the binary here if anyone wants to
>> try. It worked for me in a game I was playing with.

Thanks! Please let me know the results if you end up trying it, I want to confirm it works depending on certain conditions.

Strangely, the main in my dll is getting executed multiple times and msvcr71.dll gets injected too. Is this normal?

2012/12/3 s0beit <s0beit@myg0t.com>:
> On Sunday, 2 December 2012 at 22:30:56 UTC, maarten van damme wrote:
>>
>> Thanks, interesting blog :)
>>
>> 2012/12/2 s0beit <s0beit@myg0t.com>:
>>>
>>> Alright, I was finally able to give it a try:
>>>
>>> http://s0beit.me/d/d-module-injector/
>>>
>>> I released the source code as well as the binary here if anyone wants to try. It worked for me in a game I was playing with.
>
>
> Thanks! Please let me know the results if you end up trying it, I want to confirm it works depending on certain conditions.

On Monday, 3 December 2012 at 11:08:34 UTC, maarten van damme wrote:
> Strangely, the main in my dll is getting executed multiple times and
> msvcr71.dll gets injected too. Is this normal?

mcvcr71.dll is probably loaded by your library, I don't know if D uses visual studio dependencies... one would think not... What are you injecting into?

Your DLL should only be executed once, I would go as far as to say it's impossible that it's being executed multiple times because calling LoadLibrary multiple times will not invoke the DLL_PROCESS_ATTACH action multiple times, after the initial load it will only return the pre-existing handle.

Are you making sure to check if the "dwReason" in DllMain is DLL_PROCESS_ATTACH? If you aren't, it will seem like it's being called multiple times when new threads are created.

Yes, that was the problem :p

I have no idea about mcvr71, maybe because of std.process but that isn't that huge a concern