l_inc Приложение многопоточное, поэтому сторожевые страницы нельзя использовать(после доступа к ней страница становится доступной). Да и на быстродействии это сильно скажется, ведь страница это базовая единица памяти, в ней ведь не только целевой код.
Velheart >векторным хэндлером SleepEx -- т.к. второй параметр, который ему передадут -- адрес возврата в ntdll Актуально, вторым параметром будет мусор на стеке. Например, для случая 6.0.6001.18000 (WinVi sp1) второй "аргумент" для векторного хендлера будет иметь значение, которое лежало в регистре edi на момент входа в KiUserExceptionDispatcher(). Clerk Откуда берётся память для возвращаемых сервисом данных? Если каждый раз аллоцируется из хипа, то, возможно, имеет смысл попытаться найти способ редиректа кодовыполнения в момент выделения. Ведь куча яввляется достаточно разросшейся системой, и поддерживает многие отладочные механизмы.
Sol_Ksacap Память выделяется из хипа, создаётся таймер(410ms): Код (Text): #WM_TIMER MainWnd_OnTimer() Data:g_pPages[1] Code:7CProcPage[6] TimerEvent() UpdateProcInfoArray() GetProcessInfo() GetProcessInfo() выделяет хип и получает слепок. Логика проста, мы можем двигаться по цепочке стековых фреймов в обоих направлениях. В прямом направлении это соответственно добавление фреймом и расширение стека, тоесть процедуры вызываются последовательно. Обратно - бактрейс и захват адресов возврата. Не обязательно перехватывать код прямо на целевом месте, всегда можно до него дотрассировать. Задача заключается как обычно в подобных случаях - необходимо получить управление до целевого места и как можно ближе к нему. В случае с хипом можно былобы выполнить его захват разными способами, например уже описанное разрушение сигнатуры, тогда можно выполнить бактрейс и мы окажемся в процедуре GetProcessInfo() после выделения памяти, но до вызова сервиса. Этот способ плох тем, что хип выделяется однократно и релоцируется если слепок не влазит в буфер, тоесть вызовы будут пропущены. Необходимо гдето ранее перехватить код. Ссылки на обработчики в секции данных, можно просто тут указатель заменить. Можно оконную процедуру переопределить и трассировать код до вызова сервиса получающего слепок. Это простое и эффективное решение, причём проблем с совместимостью нет никаких.
а зачем тебе менять код? такая идея есть, может и бред... в таскменеджере есть окошко-список, в котором отображаются процессы... что если, находясь в контексте процесса таскменеджера подменить функцию обработки оконных сообщений этого окошко-списка на свою... я думаю сделать можно так: 1) формируем код, который: - найдет окошко-список - подменит на свою функцию обработки оконных сообщений - вернет управление в нужное место - ну и сам в себе будет держать новую функцию обработки 2) внедряем код, допустим по методу, давно описанному Твистерем (только тогда кодом надо уложиться в 256 байт, ну или разделить его на две части) 3) переключаем контекст одного из потоков на наш код (так как по условию задачи манипулировать контекстом потоков разрешается) как тебе такой вариант?))
можешь мне в ЛС кратко описать, как ты думаешь это делать... просто интересно, и для общего развития...
ну вот я как раз и предлагаю за счет другой функции обработки оконных сообщений перехватывать сообщения о добавлении элемента в список...
Не, решение-то рабочее. Просто смешное. А если у человека сегодня TaskManager, а завтра ProcessExplorer или аналоги?
Угу При этом самая смешная часть шутки заключена в первом же посте топика. 2 Clerk Ты вояешь PoC или занялся написанием троянчиков, целенаправленно атакующих одну единственную машину?
Простое элегантное решение, которое будет работать всегда, везде, при любых сервис-паках и прочем. Называется оно гуи-хакинг, изобретено еще когда камрада клерка тут и подавно не было. Гуи хакинг придется разумеется делать изнутри таск манагера. А вот всякие извращения, которые несомненно придумал этот мегагуру в кавычках - курам насмех. Сейчас мы все наверняка увидим очередной понос про колбеки, бэктрейс и разумеется на пикоде.