Implementing GetProcessCommandLine()

c++ / delphi package - dll injection and api hooking
Post Reply
dcsoft
Posts: 380
Joined: Sat Dec 11, 2004 2:11 am
Location: San Francisco Bay Area, CA USA
Contact:

Implementing GetProcessCommandLine()

Post by dcsoft »

I am using madCodeHook to implement :

Code: Select all

BOOL GetProcessCommandLine (DWORD dwProcessId, LPTSTR pCmdLine, size_t len);
which is just like the Win32 GetCommandLine() but also takes a process ID specifying which process's command line to get. GetCommandLine() works on the current process only.

I am implementing this using madCodeHook to inject a DLL which simply calls GetCommandLine() in the context of the injected process, then uses madCodeHook's SendIpcMessage() to send it to the injector.

The problem is that madCode won't inject into a 16-bit app, including DOS boxes on Win9x. To workaround this, does anyone know how to implement GetProcessCommandLine() in a different way? It doesn't have to use madCodeHook, but I can't figure out how to do it without injection.

Thanks,
David
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

First of all this is a task which is so easy that you can get along without using a dll. Look at the following demo which does exactly what you're asking for:

http://help.madshi.net/RemoteCmdLine.htm

The main problem still remains, though: This won't work for win9x DOS boxes. There's a different way to solve it, though, namely by using madKernel:

Code: Select all

uses madKernel;

function GetProcessCommandLine (processId: dword) : string;
begin
  result := Process(processId).CommandLine;
end;
I think this should work for win9x DOS boxes, too, because it doesn't use remote threads to solve the problem. Instead it parses the win9x internal system structures.

Are you using MSVC++ or BCB? madCollection supports BCB only. If there's no other way, you could build a little dll with BCB or Delphi which makes the needed functionality available for your MSVC++ program.
dcsoft
Posts: 380
Joined: Sat Dec 11, 2004 2:11 am
Location: San Francisco Bay Area, CA USA
Contact:

Post by dcsoft »

Thanks Madshi. Your madExcept looks really elegant; however, we don't want to incorporate Delphi into our build process at the present time.

Anyway, I investigated more and found the problem is that when you execute a program in a Win9x command prompt (by typing its name), what happens is that Windows creates a process START.EXE, and that is the parent process of yours. START.EXE dies shortly after launching the program you typed. Therefore, when I called InjectLibrary() to put a dll into the parent process (START.EXE), InjectLibrary() failed because that process no longer existed! I believe, but am not sure, START.exe is a 32-bit program). So the 16-bit command prompt really has nothing to do with this problem.

Thanks again.

-- David
dcsoft
Posts: 380
Joined: Sat Dec 11, 2004 2:11 am
Location: San Francisco Bay Area, CA USA
Contact:

Post by dcsoft »

dcsoft wrote:InjectLibrary() failed because that process no longer existed!
Oh Madshi, I meant to also say that it would be helpful if InjectLibrary() set GetLastError() to return ERROR_PROC_NOT_FOUND in this case; currently GetLastError() returned 0 (NO_ERROR).

Thanks,
David
madshi
Site Admin
Posts: 10754
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

dcsoft wrote:Oh Madshi, I meant to also say that it would be helpful if InjectLibrary() set GetLastError() to return ERROR_PROC_NOT_FOUND in this case; currently GetLastError() returned 0 (NO_ERROR).
I should really work on the last error values in general for the madCodeHook APIs. Sometimes it's set fine, sometimes its undefined.
Post Reply