Здравствуйте, Аноним, Вы писали:
А>Кто нить знает способы выделения памяти в чужом процессе без всяких ring 0 под win32 ????
VirtualAllocEx ?
Re[2]: выделить память в чужом процессе
От:
Аноним
Дата:
08.04.03 09:22
Оценка:
Здравствуйте, Murr, Вы писали:
M>Здравствуйте, Аноним, Вы писали:
А>>Кто нить знает способы выделения памяти в чужом процессе без всяких ring 0 под win32 ???? M>VirtualAllocEx ?
Это WinNT!
Что насчет Win9x ?
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, Аноним, Вы писали:
А>>Кто нить знает способы выделения памяти в чужом процессе без всяких ring 0 под win32 ????
PE>Что ты хочешь сделать под 9х ?
PE>Для чего память нужна ? И какой процес, консольный или с ГУИ ?
Для чего? А да хоть для того что бы зделать hook на api
например есть такой способ делаем OpenProcess сейчас мы можем Read/WriteProcess так ?! так же мы можем и сделать hook в import table так!? но смысл в том что процедура обработки hooka должна быть в том же контексте что и этот процесс так !? Так вот необходимо встроить в чужой процес эту самую процедуру обработки hooka!!! можно конечно затереть что не юзается (там DOS header) etc...
Вообщем надо что то типа VirtualAllocEx только Win9x (желательно win32)
А>>>Кто нить знает способы выделения памяти в чужом процессе без всяких ring 0 под win32 ???? PE>>Что ты хочешь сделать под 9х ? PE>>Для чего память нужна ? И какой процес, консольный или с ГУИ ? H>Для чего? А да хоть для того что бы зделать hook на api H>например есть такой способ делаем OpenProcess сейчас мы можем Read/WriteProcess так ?! так же мы можем и сделать hook в import table так!? но смысл в том что процедура обработки hooka должна быть в том же контексте что и этот процесс так !? Так вот необходимо встроить в чужой процес эту самую процедуру обработки hooka!!! можно конечно затереть что не юзается (там DOS header) etc...
Эта задача решена давно. Записываешь небольшой кусок кода, выделяющего память, подгружающего код и запускающего поток. Потом ставишь хук на этот загрузчик. Лучше всего записывать в неиспользуемую область в конец исполняемого образа (отмотай форум на пару недель назад). DOS header портить не получается — прога сразу вылетает.
H>Вообщем надо что то типа VirtualAllocEx только Win9x (желательно win32) H>А какая разница GUI или консоль ???????
Большая. В консольном приложении нельзя хук поставить.
2ALL: есть ли простой способ, имея hwnd, определить консольное это окно или gui? (кроме ковыряния pe-заголовка)
Здравствуйте, eax, Вы писали:
eax>Здравствуйте, himan, Вы писали:
eax> А>>>>Кто нить знает способы выделения памяти в чужом процессе без всяких ring 0 под win32 ???? PE>>>Что ты хочешь сделать под 9х ? PE>>>Для чего память нужна ? И какой процес, консольный или с ГУИ ? H>>Для чего? А да хоть для того что бы зделать hook на api H>>например есть такой способ делаем OpenProcess сейчас мы можем Read/WriteProcess так ?! так же мы можем и сделать hook в import table так!? но смысл в том что процедура обработки hooka должна быть в том же контексте что и этот процесс так !? Так вот необходимо встроить в чужой процес эту самую процедуру обработки hooka!!! можно конечно затереть что не юзается (там DOS header) etc... eax>Эта задача решена давно. Записываешь небольшой кусок кода, выделяющего память, подгружающего код и запускающего поток. Потом ставишь хук на этот загрузчик. Лучше всего записывать в неиспользуемую область в конец исполняемого образа (отмотай форум на пару недель назад). DOS header портить не получается — прога сразу вылетает.
Сложность вся в том что надо несколько Kb там выделить можем конечно и как ты говоришь сделать и более того так делал и кстати DOS header портица на ура без всяких вылетов но тут надо на выделять sharemem потом ставить на что либо на какую нить api hook потом только подгружать из sharemema остальное и потом только делать hook на все остальное но что если процес A хочет лезть в процес B а вот процес A закроется быстрее чем в B вызовится первый hook значит sharemem нету так как он принадлежал A.
Вообщем то было интересно услышать какие нить новые или другие решения этого вопроса... H>>Вообщем надо что то типа VirtualAllocEx только Win9x (желательно win32) H>>А какая разница GUI или консоль ??????? eax>Большая. В консольном приложении нельзя хук поставить.
Мне было интересно узнать почему а не "нельзя".
eax>2ALL: есть ли простой способ, имея hwnd, определить консольное это окно или gui? (кроме ковыряния pe-заголовка)
Здравствуйте, himan, Вы писали:
eax>>Большая. В консольном приложении нельзя хук поставить. H>Мне было интересно узнать почему а не "нельзя".
Хуки — это модуль USER,как и сообщения и тд. Консольное приложение его не использует и в нем отсутствует очередь выборки сообщений. Поэтому устаноить хук на то, чего в процессе нет, не получится.
eax>>2ALL: есть ли простой способ, имея hwnd, определить консольное это окно или gui? (кроме ковыряния pe-заголовка)
Можно Если у тебя есть HWND, однозначно это не консольное. В этом и все отличие.
Здравствуйте, Plutonia Experiment, Вы писали:
eax>>2ALL: есть ли простой способ, имея hwnd, определить консольное это окно или gui? (кроме ковыряния pe-заголовка)
PE>Можно Если у тебя есть HWND, однозначно это не консольное. В этом и все отличие.
Нифига. Сейчас посмотрел через spy ++ — у окна FAR есть hwnd.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Здравствуйте, himan, Вы писали:
eax>>>2ALL: есть ли простой способ, имея hwnd, определить консольное это окно или gui? (кроме ковыряния pe-заголовка)
PE>Можно Если у тебя есть HWND, однозначно это не консольное. В этом и все отличие.
Неправда. Что по-вашему возвращает GetConsoleWindow()?
А определить я думаю можно по-разному:
Способ 1. (самый надежный)
Прочитать header exe файла.
Как это сделать можно посмотреть в
HOWTO: How To Determine Whether an Application is Console or GUI
Q90493
(на дисковом MSDN)
Способ 2. (самая простая и грубая реализация способа 1)
Здравствуйте, sasha, Вы писали:
PE>Можно Если у тебя есть HWND, однозначно это не консольное. В этом и все отличие.
S>Неправда. Что по-вашему возвращает GetConsoleWindow()?
Это про свой процесс. А про другой ? Как узнать, что другой процесс консольный или нет очень сложно.
Потосу что может быть и ГУИ и консоль одновременно.
К тому же этот хендл, насколько я понял, не принадлежит процессу. Иначе все процессы были бы ГУИ.
S>А определить я думаю можно по-разному:
S>Способ 1. (самый надежный) S>Прочитать header exe файла. S>Как это сделать можно посмотреть в S>
S>HOWTO: How To Determine Whether an Application is Console or GUI
S>Q90493
S>
S>(на дисковом MSDN)
А что мешает после загрузки насоздавать окон ? Надежность — 50%
Или ты думаешь, что из консольного нельзя ГУИ сделать ?
S>Способ 2. (самая простая и грубая реализация способа 1)
Тоже самое.
S>Способ 3. (imho, наименее надежный)
Это как раз самы нормальный способ, но одновременно может быть и консоль и ГУИ.
Посему — если вы держите в руках HWND — процесс не консольный, хотя консоль у него может быть.
Само окно консоли процессу не принадлежит, насколько мне известно.
Здравствуйте, eax, Вы писали:
eax>>2ALL: есть ли простой способ, имея hwnd, определить консольное это окно или gui? (кроме ковыряния pe-заголовка)
PE>Можно Если у тебя есть HWND, однозначно это не консольное. В этом и все отличие.
eax>Нифига. Сейчас посмотрел через spy ++ — у окна FAR есть hwnd.
И что с того ? Если у него есть свои HWND, то можешь загружать хуки сколько угодно.
Это же означает, что процесс ГУИ — у него есть очередь сообщений. Хотя и консоль при этом есть.
Я имел в виду, что процесс консольный, если у него нет USER-ресурсов. Вот и все.
Здравствуйте, eax, Вы писали:
eax>Нифига. Сейчас посмотрел через spy ++ — у окна FAR есть hwnd.
Я пытался раньше хук установить на ФАР, чтобы АПИ перехватить.
Тот ФАР, который работает давным давно, хукается нормально.
А свежеиспеченный процесс не хукается — длл в него не грузится.
S>Способ 1. (самый надежный) S>Прочитать header exe файла. S>Как это сделать можно посмотреть в S>
S>HOWTO: How To Determine Whether an Application is Console or GUI
S>Q90493
S>
S>(на дисковом MSDN)
PE>А что мешает после загрузки насоздавать окон ? Надежность — 50%
Что значит "насоздавать окон"? Насоздавать можно все что угодно, но приложение все равно принадлежит одной из подсистем
Здравствуйте, sasha, Вы писали:
PE>А что мешает после загрузки насоздавать окон ? Надежность — 50% S>Что значит "насоздавать окон"? Насоздавать можно все что угодно, но приложение все равно принадлежит одной из подсистем S>
Это всего лишь флажок в PE заголовке. А меня интересует то, что получится в конечном итоге.
Флажок этот нужен для того ,чтобы винда сразу выбирала модули нужные и грузила их и тд(адреса стартовые).
Я говорб про то, что консольный процесс- процесс без USER-объектов. И у потоков нет очереди сообщений.
Можно создать все это.
Потом можно закрыть консольное окно и оставить только ГУИ.
Что получается, была консоль, стало ГУИ ?
А потом я вызову AllocConsole и позакрываю все окна.
Это снова консольный получится, так чтоли ?
Или если загружался как консольный, то таким же и останется, даже если нету консоли а есть ГУИ ?
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Я говорб про то, что консольный процесс- процесс без USER-объектов. И у потоков нет очереди сообщений. PE>Можно создать все это. PE>Потом можно закрыть консольное окно и оставить только ГУИ. PE>Что получается, была консоль, стало ГУИ ? PE>А потом я вызову AllocConsole и позакрываю все окна. PE>Это снова консольный получится, так чтоли ? PE>Или если загружался как консольный, то таким же и останется, даже если нету консоли а есть ГУИ ?
Давай не будем пудрить друг другу мозги. То, о чем ты говоришь, это слишком нетипичный и явно надуманный пример. Так что если у тебя нет более конструктивных предложений, то давай считать тему закрытой.
Здравствуйте, sasha, Вы писали:
S>Давай не будем пудрить друг другу мозги. То, о чем ты говоришь, это слишком нетипичный и явно надуманный пример. Так что если у тебя нет более конструктивных предложений, то давай считать тему закрытой.
Ты вобщем то и не сказал главного — что считать консольным, а что ГУИ.
По флажку в заголовке — это неправильно.
Здравствуйте, Plutonia Experiment, Вы писали:
PE>Ты вобщем то и не сказал главного — что считать консольным, а что ГУИ.
Вот именно.
Ну, в PEB есть флажок аналогичный, можно его прочитать.
Естественно, про AllocConsole он не меняется.
Потому консольный процесс может не содержать ни одной консоли, и наоборот.
С другой стороны, если все честно, там же (в PEB) есть hStdOutput, так вот, WriteConsole и прочая чушь использует его, поэтому проверка его на NULL покажет, есть консоль или нет (точнее, имеется ли вообще смысл писать в консоль или нет), я б его юзал.
Это есть не только на NT (GetStdHandle и на 9x работает), так что претензии типа "это только для NT" не принимаются.
//**
У меня есть похожая, но более интересная задача, я даже знаю, как ее решать (мне можно NT-only, но NT4 — надо однозначно), но, возможно, есть путь проще.
Имеем Shell Extension в виде Property Page-а. Естественно, библиотека (DLL), естественно, сама она GUI или CUI — роли не играет. Существует документированный механизм вызова функций из библиотек через rundll32.exe, необходимо некую функциональность реализовать именно таким способом. Чтение передаваемых параметров через командную строку проблем не вызывает (сам механизм вызова это предоставляет), а вот выводить в консоль — уже сложнее. Практика показывает, что при запуске из far-а rundll32 выполняется не как консольная программа (то есть, если в вызываемой функции показать Messagebox, far не джет завершения rundll32 и сразу же готов к вводу дальнейших команд). Свои "флажки консольности" читать естественно бессмысленно, так как программа запускается как GUI (то, что реально гуя нет, в общем-то, никого не волнует). Необходимо, если запущено из гуевой программы, консоль не создавать, а если из консольной — аттачиться к консоли родителя (AttachConsole отдыхает так как слишком новая). В идеале — выводить именно на ту консоль с которой запущены, если консолей у родителя несколько (но это не критично). Мое решение — найти родителя, найти у него hStdOut и писать в него (WriteConsole), но это довольно сложно (не в том плане, что читать чужую память мы не умеем, а в том плане, что дело-то имхо плевое, всего-то приаттачиться к родителю, чтоб ради этого в чужой PEB лезть). Может есть проще метод, без чтения родительской памяти?
Здравствуйте, vasketsov, Вы писали:
V>Здравствуйте, Plutonia Experiment, Вы писали:
PE>Ты вобщем то и не сказал главного — что считать консольным, а что ГУИ.
V>Вот именно. V>Ну, в PEB есть флажок аналогичный, можно его прочитать. V>Естественно, про AllocConsole он не меняется. V>Потому консольный процесс может не содержать ни одной консоли, и наоборот.
Так в чем фишка с консольным процессом ?
Взяли кусок чистого железе, науглероживаем его — получаем сталь, а не железо.
Куем ее — получаем кованую сталь.
Легируем — получаем легированную.
Из стали можно уже булат или дамаск получить.
"Вот именно" — в том смысле, что "клиент" не определился с постановкой задачи.
PE>Так в чем фишка с консольным процессом ?
Если я правильно понял вопрос :shiffle: , то теоретически (да и практически) можно сделать консоль так, что кроме куска кода, ее сделавшего, и CSRSS об этом никто не узнает. То есть, вовсе не обязательно ни устанавилвать ее хэндл как StdOutput, вовсе не обязательно править StartupInfo. В этом случае и запрос заголовка консоли на 99% обломается (1% оставляю на криворукость программистов M$, если этот запрос напрямую отдается CSRSS-у без анализа, консольная — по мнению M$ — текущая программа или нет, то есть, не создавалась ли уже консоль, вроде такую проверку я где-то внутри kernel32.dll видел, и если хэндл этого окна нигде не кэшируется, за что совсем надо расстреливать без права аппеляции).
Кстати, сейчас только проверил (2000Prof+все фиксы), окно с заголовком E:\Program files\Far таки фару принадлежит. У него, как ни банально, класс "ConsoleWindowClass", если поискать все окна с таким классом в процессе, наверное, по факту наличия хотя бы одного и можно определить, стоит ли писать в консоль или нет. Опять же, printf сотоварищи юзают StdOut, а из вышесказанного, наличие консольного окна не гарантирует, что можно писать стандартным способом в эту консоль (потому как ее хэндл мало кому известен). По идее, может существовать механизм определения ConsoleHandle по hWnd такого окна (например, оно может в UserData лежать), в таком случае он все решает, но 1) сходу я его прдложить не могу (может кто знает?) и 2) его надо тестировать на окошках таких извращенных "полуконсольных" приложений, которые так любит Plutonia Experiment.