madshi.net

I don't know..

It's part of the TIModule.SetProcAddress() function in madKernel.pas.

Dearest madshi,

Having upgraded to your latest Delphi complains that "InitUnprotectMemory" is missing in madRemote.dcu when building for x64.

32 bit builds without any problems.

Am I doing something wrong ?

Respectfully

No no, that was my own frag-up as usual..

Yes, absolutely, the drivers are fine.. It is just that, for some odd reason, the bug that I've been experiencing (or, odd behavior) was very intermittent, sometimes showing after 5 minutes and at other occasions after 5 or 10 hours, but when using the drivers it showed up quite quickly, which again...

Iconic, Thanks, but I'm not spawning another process, if you got that impression I apologize. It's basically just a very simple service that starts and checks if the injection driver is running, if not it attempts to start it and then if successful, submits an injection request for the driver to inj...

I'm using madCodeHookBeta 2.7.12.11 I would tend to agree with you, except that if I perform system wide injection after login, everything works without any problems.. Anyway, I'll try the latest build for sure and see where that takes me. I'm using Delphi XE5 btw, I wasn't to call Initialize/Finali...

I know what you mean.. My challenge was that I need the injection driver to perform the injection, ideally when my application is running, but in order to communicate with the driver through the API the application needs to run with administrative (or elevated) privileges, that is not possible or by...

Dear madshi, Having the injection driver survive reboots is absolutely a great thing, so it automatically starts when the system starts, very convenient for many purposes. It would appear that it doesn't remember injection requests from the last session, or at least the beta driver doesn't, is that ...

Yes, so far I'd have to say that they're fine

I'll be making a new build here tonight, I got a couple of other bugs I need to fix as well, but I'll for sure keep you updated, I'll be getting feedback from the beta testers regularly.

Thanks madshi

I might not have expressed myself in a clear manner, for that I apologize. The problem CAN be reproduced with the release drivers, since I can reproduce it by "manual" injection into a single process (Chrome.exe) without using the driver all together, so the problem would definitely be pre...

Okay.. I commented out all the LoadLibrary hooks and the problem appears to be gone. I'm thinking that what I have been seeing might be some kind of race condition, where my code is hooking LoadLibrary and when the libraries I "subscribed" to by calling HookAPI() on .dlls that was not load...

Well now, that was a nice feature hooking the LoadLibrary calls, I was not at all aware of that.. I don't know it that's the culprit, but I might mess things up doing just that.. Most of the rest of the hooking .dll is based on code that I have already tested over a long period and have already been...

I guess my reference was very well placed :D Quite frankly, I don't know if it's the hook .dll that's misbehaving par se, I can only observe that certain processes starts to misbehave and nothing have been changed but the injection driver, so it was kinda natural to me to suspect that it was somethi...

Hey madshi, A quick update. I updated the drives using the latest Beta drivers, but there's no change, it still does it. I then took the PrintMonitor demo and replaced renameme32+64.sys with those from the Beta Package, signed .dlls, configured drivers and signed drivers, no problem when that is run...

No, I only re-configured the Beta drivers, I did not recompile using the beta codeHook code.

I'm running it on Win7 x64 and using Delphi XE5.