February 11th, 2012, 2:19 am
Hi,
well, this is more a help for others than a question. I was reading the command line from a process running on my system and i was wondering why the command line memory read from the processes UNICODE_STRING "CommandLine" member on the RTL_USER_PROCESS_PARAMETERS in the PEB-Structure (if you look at the raw memory in your debugger) is perfectly ok, but somtimes when working with it and windows APIs expecting zero terminated string, the expected result is incomplete once passed to several APIs. I was wondering what the reason was for this and i dumped all the bytes into a binary file i read from the affected process and had a closer look at it with a hex editor and then there wwas the "AHA"
reaction. The "Buffer" member of the UNICODE_STRING was pointing to a "mixed" string, with a "\0" right in the middle of the buffer. So if you pass the function to a windows API function expecting a zero terminated string as the final marker of the string, the function will handle the string until it reaches the "\0" and then return the result. This is bad for sure. One way to bypass this e.g. is to walk the buffer and replace all the "\0" in the buffer with some user defined value e.g. a space character or whatever you like and then append a "\0" at the end of the buffer. So you will have a perfectly valid string for most of the windows api functions. I attached a picture of the issue to this thread.
K.
well, this is more a help for others than a question. I was reading the command line from a process running on my system and i was wondering why the command line memory read from the processes UNICODE_STRING "CommandLine" member on the RTL_USER_PROCESS_PARAMETERS in the PEB-Structure (if you look at the raw memory in your debugger) is perfectly ok, but somtimes when working with it and windows APIs expecting zero terminated string, the expected result is incomplete once passed to several APIs. I was wondering what the reason was for this and i dumped all the bytes into a binary file i read from the affected process and had a closer look at it with a hex editor and then there wwas the "AHA"
reaction. The "Buffer" member of the UNICODE_STRING was pointing to a "mixed" string, with a "\0" right in the middle of the buffer. So if you pass the function to a windows API function expecting a zero terminated string as the final marker of the string, the function will handle the string until it reaches the "\0" and then return the result. This is bad for sure. One way to bypass this e.g. is to walk the buffer and replace all the "\0" in the buffer with some user defined value e.g. a space character or whatever you like and then append a "\0" at the end of the buffer. So you will have a perfectly valid string for most of the windows api functions. I attached a picture of the issue to this thread.K.
- Attachments
-
