InjectLibrary and UnInjectLibrary into single process

[bedlam]

Hi Mad,

Just a quick Q concerning the InjectLibrary and UnInjectLibrary in
the MadCodeHook component.

In my service Start Event I use:

Code: Select all

InjectLibrary((ALL_SESSIONS Or SYSTEM_PROCESSES) and (not CURRENT_PROCESS), 'MYINJECTED.DLL');

In my service Stop event I use:

Code: Select all

UnInjectLibrary((ALL_SESSIONS Or SYSTEM_PROCESSES) and (not CURRENT_PROCESS), 'MYINJECTED.DLL');

Now I don't wish to Inject into the System processes winlogon.exe or csrss.exe so I am wondering
if it is possible to UnInject just these two processes instead of UnInjecting All ????

Below is a snippet of the begin block in MYINJECTED.DLL but I don't think it is very stable
as windows sometimes throws memory errors at me.

Code: Select all

var
  tmp: array [0..MAX_PATH] of char = '';
  isOK: boolean;
  ModuleFileName: string = '';
  ProcessFileName: string = '';
  SystemFolderPath: string = '';
  ModuleID: Cardinal = 0;
  ProcessID: Cardinal = 0;
begin
  isOK := false;
  SystemFolderPath := GetSystemFolderPath;
  ModuleID := GetCallingModule();
  ProcessID := GetCurrentProcessId();
  GetModuleFileName(0,tmp,MAX_PATH);
  ProcessFileName := tmp;

  isOK := SameFileName(SystemFolderPath+'winlogon.exe', ProcessFileName);

  if isOK then
     begin
     WriteToLog(LOGFILE,'----- DLL UnInjected: '+ProcessFileName+':'+inttostr(ProcessID));
     UnInjectLibrary(ProcessID, 'MYINJECTED.DLL');
     end
  else
     begin
     CollectHooks();
     WriteToLog(LOGFILE,'----- DLL Injected: '+ProcessFileName+':'+inttostr(ProcessID));
     HookAPI('USER32.DLL', 'SetWindowsHookExA', @SetWindowsHookExACallback, @SetWindowsHookExANext);
     HookAPI('USER32.DLL', 'SetWindowsHookExW', @SetWindowsHookExWCallback, @SetWindowsHookExWNext);
     FlushHooks();
     end;
end.

(is this the right way or am I barking up the wrong tree ?):
HELP ME !!!!! I'M GOING MAD

[dcsoft]

I'm not sure it's OK to call UninjectLibrary from DllMain(). Why don't you just leave the DLL injected but inactive in CRSS and WinLogon?

-- David

[madshi]

dcsoft is right, don't use UninjectLibrary in the dll's initialization. Instead you can set "ExitCode := 1". This will tell Windows to unload your dll again.

Btw, UninjectLibrary wants a process handle, not a process id!

Finally: Are the logging functions thread safe? I hope so...

[bedlam]

Why don't you just leave the DLL injected but inactive in CRSS and WinLogon?

Don't know what you mean by "inactive" ??

I thought the process id (PID) had to be passed to the Inject/Uninject
How do I get the Process Handle ?? What is a Process Handle ??

NO, the logging functions are not thread safe...they simply write a line
of text to a file....no GUI stuff.

I'm also getting "windows will shutdown in xxx seconds" messages when
the DLL is injected into alg.exe and svchost.exe through Windows XP SP2 (Windows 2000 no problems) in fact all errors I receive in Windows XP, I do not get any errors in Windows 2000.

Seems to me that XP is aware of all this injection code and it just don't like it.

[madshi]

How do I get the Process Handle ?? What is a Process Handle ??

Why telling you? You don't need it, anyway. Do not call UninjectLibrary in your dll!!!

NO, the logging functions are not thread safe...

Well, that's bad. Everything which your hook dll does must be thread safe. Otherwise you're impacting system stability.

Seems to me that XP is aware of all this injection code and it just don't like it.

Try my precompiled demos and you'll see that XP doesn't have the slightest problem with them. It's quite probably your code which is the problem...

[bedlam]

Your Docs say that you can Inject into a single process. How can I do this when it does not take a PID as a parameter. Please tell me what a Process Handle is

Yes, I tried your demos but they are limited in their functions. My code works 50% of the time. Just when I think that all is well, no errors appearing...i come the next day and all hell breaks loose, AV's, Shutdowns...etc.

This problem with injecting into alg.exe is new....all other errors I had, I managed to resolve. Something is causing it and it ain't my code

[madshi]

Your Docs say that you can Inject into a single process. How can I do this when it does not take a PID as a parameter. Please tell me what a Process Handle is

You can inject into a single process. Just use OpenProcess to get a process handle from the PID. Don't forget to close the handle again via CloseHandle.

But again: Please do not call UninjectLibrary in your hook dll.

Yes, I tried your demos but they are limited in their functions.

A hook dll should only do what is absolutely necessary. I've written some "serious" hook dlls (used in real life software), too, and they work just as fine as my demos are.

My code works 50% of the time. Just when I think that all is well, no errors appearing...i come the next day and all hell breaks loose, AV's, Shutdowns...etc.

Then there are most probably problems in your code.

This problem with injecting into alg.exe is new....all other errors I had, I managed to resolve. Something is causing it and it ain't my code

I'm quite sure it's your code...

[bedlam]

ok, thanks for re-assuring me it's my code causing the problems

It could be like you say, the function calls I use within the DLL are not thread safe. The only processing I do within a Hooked Callback procedure is some Registry reading and basic file logging.

I'm gonna strip it all out, and start over..step by step.

BTW...what is the best way to make my DLL code threadsafe....should I use sychronize ??? How do I know that the Hooked Callback procedure is threadsafe ??

[madshi]

Don't use Synchronize. First of all try to get along with no more global variables/resources than absolutely necessary. Local variables are usually automatically thread safe. When you access global variables or global resources (like files), you need to synchronize access to those global stuff. The usual way to do this is to use a named mutex. See CreateMutex + WaitForSingleObject + ReleaseMutex + CloseHandle.

[bedlam]

ok...I understand.

I do have a few globals...I'll try the local approach.

Just to let you know, that if I do get all this working....I'll reward you

[madshi]

Just to let you know, that if I do get all this working....I'll reward you

With a kiss? Oh no - please don't !!!

(You're not a pretty girl, or are you?)

[bedlam]

well I could arrange that if that's what you want I was thinking more along the lines of cash and a couple of orders

I've managed to sort out the errors....I got it working 100% now after
removing the WriteToLog functions...like you suggested, they were not thread safe.

All i got to do now is figure out how to make tham threadsafe (Critical Sections maybe).

I'm still using the version 2.1.20 components as the latest version 2.1.7.0 I have problems with in Delphi 2005. When I compile with version 2.1.7.0 under Delphi 6, my inject service works fine. Under Delphi 2005 the Inject service just reboots the machine at the point of DLL injection.

I am running both Delphi6 and Delphi2005 on the same machine with the components in seperate folders so they don't conflict. Delphi 2005 is using 2.1.7.0 components and Delphi6 is using 2.1.2.0 components. All BPL's are in seperate BPL folders and Paths.

Sometimes Delphi 6 won't load with errors about RTL90 and MadShell.BPL......how is this when I have completely seperated the two versions from each other. How is MadShell getting a reference to RTL90 under Delphi 6.0 ???? I do not have any Delphi 2005 components installed in Delphi 6.0.

[madshi]

All i got to do now is figure out how to make tham threadsafe (Critical Sections maybe).

Critical sections only work for one process. For system wide synchronization you need to use something else, e.g. named mutexes.

I'm still using the version 2.1.20 components as the latest version 2.1.7.0 I have problems with in Delphi 2005. When I compile with version 2.1.7.0 under Delphi 6, my inject service works fine. Under Delphi 2005 the Inject service just reboots the machine at the point of DLL injection.

Have you tried 2.1.7.0 in Delphi 6? I think the problem is not the madCodeHook version, but the Delphi version. Or am I wrong?

How is MadShell getting a reference to RTL90 under Delphi 6.0 ???? I do not have any Delphi 2005 components installed in Delphi 6.0.

No idea. Depends on how you installed it all in detail. Better is to use only one version of madCollection, of course.

[bedlam]

Have you tried 2.1.7.0 in Delphi 6? I think the problem is not the madCodeHook version, but the Delphi version. Or am I wrong?

It's the Delphi 2005 versions of MadCodeHook that reboot the system when Injecting a DLL. All versions of MadCodeHook work fine when compiled under Delphi 6.

It may be my version of Delphi 2005 that may be the problem or some conflict with another component. I don't have any Delphi 2005 updates installed either.

My procedure for installing the MadComponents is a s follows:

1. I install the Components to a Temp folder.
2. I copy all MAD Delphi 6 VCL+BPL files to Delphi/Lib/MAD_D6
3. I copy all MAD Delphi 2005 VCL+BPL files to BDS/Lib/MAD_2005
4. I then Uninstall MadComponents using your installer.
5. I start Delphi 6 and Add MAD_D6 to path and install the BPL files.
6. I start Delphi 2005 and add MAD_2005 to path and install BPL files.

The above procedure works and allows me to use your components for
both Delphi 6 and Delphi 2005.

I'm just curious if your Components create any other files anywhere other than the default install folder ?? Or are any other files or references created when compiling projects using your components ??

Thanks for all support you have given.

[madshi]

It's the Delphi 2005 versions of MadCodeHook that reboot the system when Injecting a DLL. All versions of MadCodeHook work fine when compiled under Delphi 6.

So Delphi 2005 is guilty here, since madCodeHook itself does not do anything different between D6 and D2005.

The above procedure works and allows me to use your components for both Delphi 6 and Delphi 2005.

Why don't you simply start the 2.1.7.0 installer and let it take care of everything? It will install madCollection in all Delphi versions that are installed on your PC. You don't need to do anything manually. Well, now that you have you might confuse the installer, though. So perhaps you should now better keep using your strange installation steps...

I'm just curious if your Components create any other files anywhere other than the default install folder ??

No.

Or are any other files or references created when compiling projects using your components ??

No. Except the files that Delphi might create (dcus etc).