Olly plays foul

[jj2007]

I'm sorry but there seems to be confusion. You cannot pass values to a child process via registers.

That's what I wrote:

Don't pass values in esi edi ebx to a thread or new process.

But I'm not a native English writer, so that might be the reason for your confusion. Apologies.

[Ghandi]

No apologies necessary jj, i just meant that there isn't actually a way to pass values to the registers without using one of the thread context API, because processes are (supposedly) isolated from each other, self contained in their own little memory space. Its just convenient for us that API exist to be able to examine other processes information, else we'd all be in trouble when time came to debug our applications. ;)

HR,
Ghandi

[jj2007]

or to pass a pointer through the STARTUPINFO structure

Hi Gandhi,
Can you explain what you meant here with "pass a pointer"? AFAIK there is no dedicated user-defined value in STARTUPINFO; and of course, you cannot pass pointers.

What works is misusing certain rather superfluous members:

Parent:

Code Select Expand

LOCAL sinfo:STARTUPINFO
  lea ebx, sinfo
  invoke GetStartupInfo, ebx ; fill the structure
  mov sinfo.dwXCountChars, esi ; pass some values
  mov sinfo.dwYCountChars, edi ; to the child process


Child:

Code Select Expand


.data?
sinfo STARTUPINFO <?>
.code
mov ebx, offset sinfo
sub esp, sizeof STARTUPINFO
invoke GetStartupInfo, esp
mov ecx, [esp.STARTUPINFO.dwXCountChars]
mov edx, [esp.STARTUPINFO.dwYCountChars]
add esp, sizeof STARTUPINFO


Now ecx and edx contain the values that were in the parent's esi and edi.

[Ghandi]

http://www.catch22.net/tuts/undoc01

Specifically though:

Pass arbitrary data to a child process!


The last undocumented trick is quite different to the previous ones so I thought I'd save it until last. The STARTUPINFO structure contains two members, lpReserved2 and cbReserved2:



WORD    cbReserved2;
LPBYTE  lpReserved2;
These two members provide a mechanism for passing arbitrary amounts of data from one process to another, without having to call VirtualAllocEx / WriteProcessMemory. The cbReserved2 member is a 16bit integer and specifies the size of the buffer pointed to by lpReserved2. This means that lpReserved2 can be as big as 65535 bytes.



The example below demonstrates how to pass a buffer from one process to another. When process-B is executed by process-A, it will display a message box saying "Hello from Process A!":



Process A:



int main()
{
    STARTUPINFO          si = { sizeof(si) };
    PROCESS_INFORMATION  pi;
    char                 buf[4444] = "Hello from Process A!";
   
    // setup the buffer to pass to child process
    si.lpReserved2 = buf;
    si.cbReserved2 = sizeof(buf);
   
    // create a new process with this data
    if(CreateProcess(0, szExe, 0, 0, 0, 0, 0, 0, &si, &pi))
    {
        CloseHandle(pi.hProcess);
        CloseHandle(pi.hThread);
    }
}
Process B:



int mainCRTStartup()
{
    STARTUPINFO si = { sizeof(si) };
   
    GetStartupInfo(&si);
   
    // display what process A sent us
    MessageBox(NULL, si.lpReserved2, "Process B", MB_OK);
}So far so good - we have a nice method for passing arbitrary binary data between applications, without having to use the command line. There is a problem though. In the example above process-B must be compiled with absolutely no C-runtime support. The reason is quite complicated but I will explain it now:



The Microsoft C runtime (including Visual Studio.NET) uses the lpReserved2 feature in it's implementation of the C functions: exec, system and spawn. When a new process is executed using these routines, the C-runtime has to be able to give the child process copies of it's open file handles (opened using fopen/open rather than CreateFile).



lpReserved2 is used as a mechanism to pass this file-handles information between programs compiled using MSVC. Before the exec/spawn runtime functions inevitably call CreateProcess, the lpReserved2 buffer is constructed using the following format:



DWORD  count;
BYTE   flags[count];
HANDLE handles[count];

// in memory these are layed out sequentially:
[ count ][ flags... ][ handles... ]The first field in the lpReserved2 buffer is a 32bit count of the number of file-handles being passed. Next comes a BYTE-array of flags, one for each file-handle. These flags represent the file attributes that were used when the file was opened using fopen/open - i.e. read-only, write-append, text-mode, binary-mode etc. Immediately following the flags array is the HANDLE-array containing each open file. This array contains the actual file handle identifiers, again there are handle_count items in the array.



Any amount of data can follow this structure, up to a maximum of 65536 bytes. The cbReserved2 member must be set to the length (in bytes) of this structure. The actual steps need to construct the lpReserved2 are as follows:





1.Any currently open "runtime" file-handles are enumerated.


2.Each underlying win32 HANDLE is marked as inheritable.


3.The number of file-handles being passed between processes is stored as the first 32bit integer in lpReserved2.


4.The attributes of each open file-handle are stored sequentially in the flags BYTE-array.


5.The file-handle integers are stored sequentially in the handles 32bit int-array.


6.Finally CreateProcess is called, with the bInheritHandles parameter set to TRUE.




It is at this stage that the C-runtime becomes important. When the child process executes, as part of it's initialization before main() is called, the I/O runtime support needs to be initialized. During this initialization the C-runtime calls GetStartupInfo and checks to see if an lpReserved2 buffer has been specified. If lpReserved2 is not NULL (i.e. it points to valid memory) then the C-runtime parses the contents of the buffer and extracts the file-handles contained within - this is so the file-handles will be available to the new process.





1.Call GetStartupInfo and check if lpReserved2 points to valid data.


2.Extract the first 32bit integer - this is the number of file-handles in the buffer.


3.Intialize the current process's I/O state with this number of open files.


4.Loop over the flags[] array in lpReserved2.


5.Loop over the handles[] array, populating the open-file table.




The problem might now be apparent to the more astute readers. Any program compiled using Microsoft's C-runtime will check it's lpReserved2 when it first starts - it should come as no surprise that this probably represents 90% of the C/C++ Windows programs in existence. The lpReserved2 member may also be used by other compiler vendors for the same purpose.



Should you wish to use lpReserved2 in your own programs (using CreateProcess instead of spawn/exec) you will need to be careful because the lpReserved2 buffer must be properly constructed. Failure to do so will result in the child processes crashing, or at the very least becoming unstable - the reason being that the child process is expecting to find lpReserved2 in a particular format.



Getting around this problem is simple. Setting the first 4 bytes in lpReserved to zeros (nulls) indicates that the handle-arrays are empty, and any c-runtime startup code will simply skip this phase. Your arbitrary binary data can come immediately after this zero-marker. The code now looks like this:



Process A:



int main()
{
    STARTUPINFO          si = { sizeof(si) };
    PROCESS_INFORMATION  pi;
    char                 buf[4444];

    // construct the lpReserved2 buffer
    *(DWORD *)buf = 0;
    lstrcpy(buf+sizeof(DWORD), "Hello from Process A!";

    // setup the buffer to pass to child process
    si.lpReserved2 = buf;
    si.cbReserved2 = sizeof(buf);
   
    // create a new process with this data
    if(CreateProcess(0, szExe, 0, 0, 0, 0, 0, 0, &si, &pi))
    {
        CloseHandle(pi.hProcess);
        CloseHandle(pi.hThread);
    }
}
Process B:



int main()
{
    STARTUPINFO si = { sizeof(si) };
   
    GetStartupInfo(&si);
   
    // display what process A sent us
    if(si.lpReserved2 != NULL)
        MessageBox(NULL, si.lpReserved2 + sizeof(DWORD), "Process B", MB_OK);
}The example above can now be compiled without having to worry about C-runtime considerations.



Note: Apparently this method does not work under 64bit Windows Vista.

Sorry for the large quote but i didn't want to cut of any of the information i meant.

HR,
Ghandi

[jj2007]

Interesting, thanks. I chose dw?CountChars because they are safe if STARTF_USECOUNTCHARS is not set in dwFlags. Using a "reserved" member is imho a bit risky. I also would like to see a working example showing the string in the parent's address space ::)