Caller — это то, что вызывает функцию потока. Она же не сама по себе вызывается, верно?
Тем более, что по выходу из потока код возврата сохраняется в TDB.
LT> Какой-какой caller? Речь идет о стеке того самого потока. LT> Если бы было так, как ты описываешь, то удаленному потоку никогда и не удалось LT> воспользоваться полученным параметром. По-крайней мере, поток вызывал бы LT> AV по выходу из функции.
А кто сказал, что он этого не делает? Вы можете достоверно это определить на всех системах линейки NT + то, что это происходит в другом процессе? Еще раз. Вам указан прототип функции, который ожидается в качестве функции потока. Любое отклонение от него — это грубейшая ошибка, которая может повлечь за собой все что угодно.
AS>>И теперь — самое главное. MSDN: AS>>
AS>>process can obtain the return value of the ThreadProc of a thread it created with CreateThread by calling the GetExitCodeThread function. A process cannot obtain the return value from the ThreadProc of a thread it created with CreateRemoteThread.
Гм. Вообще то, тут сказано, что GetExitCodeThread не работает именно для CreateRemoteThread, для CreateThread это все вполне работоспособно. Вы можете не доверять MSDN — это Ваше право, но не дай Бог Вам потом "вживую" встретить пострадавшего от этого недоверия пользователя вашей программы LT> Это надо воспринимать несколько критически, иначе бы мы и не могли пользоваться LT> ExitCode возвращаемым CreateThread, бо реализация его построена на CRT.
Какой CRT? Если имеется ввиду C run time, то тут это не при чем, если что то еще — тогда я видимо не в курсе этого чего то еще
Здравствуйте, Andrew S, Вы писали:
AS>Caller — это то, что вызывает функцию потока. Она же не сама по себе вызывается, верно?
Не сам по себе. Но, по поводу того как формируется стек нового потока-
это всего лишь домыслы (мои, твои). Посмотри отладчиком, если интересно.
AS>Тем более, что по выходу из потока код возврата сохраняется в TDB.
Ну, а в чем тут "более"? Это уже ближе к той цитате из MSDN,
не доверяющей возвращаемому значению.
LT>> Если бы было так, как ты описываешь, то удаленному потоку никогда и не удалось LT>> воспользоваться полученным параметром. По-крайней мере, поток вызывал бы LT>> AV по выходу из функции.
AS>А кто сказал, что он этого не делает? Вы можете достоверно это определить на всех системах линейки NT + то, что это происходит в другом процессе?
Необработанные исключения в процессе вызывают его завершение.
Это я знаю про все win32
AS> Еще раз. Вам указан прототип функции, который ожидается в качестве функции потока. Любое отклонение от него — это грубейшая ошибка, которая может повлечь за собой все что угодно.
Дело не в том, что я могу ошибаться, а то, что описанная тобой теория не
позволяет, например, создавать функции потока без параметра.
AS>Гм. Вообще то, тут сказано, что GetExitCodeThread не работает именно для CreateRemoteThread, для CreateThread это все вполне работоспособно. Вы можете не доверять MSDN — это Ваше право, но не дай Бог Вам потом "вживую" встретить пострадавшего от этого недоверия пользователя вашей программы
Ну, если ты такой адепт MSDN, то почему не критиковал Read/WriteProcessMemory
без остановки потоков чужого процесса, если прямо указано, что они
для отладки. Кажется, обсуждаемый способ был признан правильным?
LT>> Это надо воспринимать несколько критически, иначе бы мы и не могли пользоваться LT>> ExitCode возвращаемым CreateThread, бо реализация его построена на CRT.
AS> Какой CRT? Если имеется ввиду C run time, то тут это не при чем, если что то еще — тогда я видимо не в курсе этого чего то еще
Скучно все время писать длинно CreateRemoteThread, пишу CRT — поверь не я это первый придумал.
Честно говоря, я устал говорить то же самое на протяжении 4-х постингов. Вы можете писАть для себя как угодно, я думаю, эта тема для меня (и не только) исчерпана.
Спасибо за внимание.
Приветствую, Andrew.
> Честно говоря, я устал говорить то же самое на протяжении 4-х постингов. Вы можете писАть для себя как угодно, я думаю, эта тема для меня (и не только) исчерпана.
Экий бука. А я хотел порадовать откровением самого Прасада.
Оно могло бы, IMHO, тебя утешить.
От:Prasad Dabak (pdabak@yahoo.com)
Заголовок:Re: getting command line of a process
Группы новостей:microsoft.public.win32.programmer.kernel
Число:2001-07-17 23:59:25 PST
Hello,
You are *absolutely* right about your suspicion.
The actual thread function is called from BaseThreadStart function in
KERNEL32.DLL and once your function returns, the BaseThreadStart
function calls ExitThread. Hence, I believe, it does not matter if
there is any extra parameter present on stack.
Hence it works.
The *safest* way would be to inject some function (containing no
relocatable instructions) in the target process, inject some data
structure containing all the required data and then create a remote
thread and pass it pointer to the data structure. After the thread
returns read back the data strcuture from the target process to get
the result.
e.g.
You can inject a data structure and a function like below.
RGetCommandLineA(PGETCMDLNDATA pGetCmdlnData)
{
char *p;
int i;
pGetCmdlnData->CmdLn[i]='\0'
p=(char *)pGetCmdlnData->pfnGetCommandLineA();
if (p) {
for (i=0; p[i]; i++) {
pGetCmdlnData->CmdLn[i]=p[i];
} pGetCmdlnData->CmdLn[i]='\0';
} return 0;
}
-Prasad
Daniel Lohmann <daniel@uni-koblenz.de> wrote in message news:<bqg9lto0h6gio4kbtreo6n0un6jgpk7mdh@4ax.com>... > On 17 Jul 2001 04:29:40 -0700, pdabak@yahoo.com (Prasad Dabak) wrote: > > >Hello, > > > >Here is the sample program to do it. It accepts process id on the > >command line and prints commandline for that process. You will have to > >enable debug privilege to access commandline for processes not running > >in your own security context. > > Nice example, Prasad > > But I have a question there. I thought about doing it exactly the same > way you suggested (calling GetCommandLineA/W() as thread function via > CreateRemoteThread), but decided it would not work: An ordinary thread > function accepts a single 32 bit parameter on the stack and because it > is called as _stdcall it *must* remove the parameter from the stack. > GetCommandLine() expects nothing to be passed on the stack and > therefore does not remove anything. > > Does this work only because the thread terminates after calling > GetCommandLine() and nobody worries about the not-cleaned-up stack or > I'm missing something? > > > Daniel
--
> Спасибо за внимание.
Здравствуйте, Leonid Troyanovsky, Вы писали:
>> Честно говоря, я устал говорить то же самое на протяжении 4-х постингов. Вы можете писАть для себя как угодно, я думаю, эта тема для меня (и не только) исчерпана.
LT> Экий бука.
Тема исчерпана, так как и для 9x и для NT есть более простые решения, чем CRT(GetCurrentProcessId()).
И совершенно не важно, будет ли этот способ работать или нет. Он никому не нужен.
