Pull to refresh

Comments 74

Лучше в тематический блог и под замок, а то сейчас кульхацкеры получили ценную информацию
Этот способ давно известен со времён появления Windows XP.
UFO just landed and posted this here
На wasm.ru еще в 2005 году все это было описано, значительно более подробно.
не то слово опередили :-)
и это был (многими не любимый и призераемый) Delphi
способ очень баянистый) в Висте и семерке работать не будет.
Работает в Висте. Лично проверял. Правда я хэндл процесса получаю не через CreateToolhelp32Snapshot, а сам запускаю процесс, но это сути не меняет.
Со включенным UAC?
Пару (десятков) тысяч блогпостов и статей о том, как его отчключить написало, конечно, меньшинство. Да-да.

Если в 7 UAC еще как-то юзабелен, то в Висте первая моя мысль была «как это нахрен вырубить». И почему-то я думаю, что я такой далеко не один, и Гугл это подтверждает :)
Согласен с вами но я имел ввиду обычных пользователей, именно тех кто если увидит по середине табличку с ахтунгом нажмут отмена (защита UAC) а если мы с вами продвинутые то мы ставим фаерволы и смотрим какой процес куда лезет и что подгружает, а простому юзеру гораздо проще нажать отмена и продолжить браузинг…
или нажать: «Да что ты выскочило, я хочу установить этот скринсейвер!!»
>простому юзеру гораздо проще нажать отмена и продолжить браузинг…

По моим наблюдениям «простой юзер» чаще жмёт на «ОК», чем на «Отмена». Или на любой другой аналог кнопки «иннах, я лучше знаю, что я делаю» :)
Я юзаю UAC. Потому что отлично понимаю для чего эта хрень нужна и, если вырублю, за неимением антивируса рискую незаметно подцепить заразу. А антивирус не имею сознательно — предохранению предпочитаю воздержание во имя производительности :)
Хотя признаю, UAC несколько снижает удобство работы.
мерзость и лажа этот uac
я сидел в висте и мучался с ним
затем вернулся на XP, в котором годами сижу без антивируса и с отключенным файрволом, при этом вся работа связана с инетом и с компом все в порядке
Я гововорил про настроенный по умолчанию UAC в Windows 7. Предыдущая версия ОС (Vista) не только UAC-ом огорчила, она в целом неудачная. Что касается Windows 7 — давно и окончательно на неё перешёл и весьма этим доволен.
ха-ха. да вы, очевидно почётный участник ботнетов, чо.
Хзхз. UAC вполне юзабелен. Ubuntu вон например вообще пароль требует ввести на каждое действие, которое может повлиять на работоспособность системы.
А вообще как вариант не сидеть под админом. Создать простого юзера и сидеть под ним, тогда и UAC не нужен.
не прошло и трех лет!
Не лучшая идея перепечатывать уже давно известные и разобранные по кирпичикам методы инжекта и другой реверс, информация о котором уже давным давно известна.
Кому надо, всегда сможет найти все нужное на cracklab'e.
А по-моему — копипаста с wasm'а. Года этак 2005го.
Запустил под семеркой. В админ режиме работает, причем ни UAC, ни иное не оповещает.

Под юзер режимом не работает.
DLL Injection без dll injection, эта метода была названа так потому, что в качестве указателя на исполняемый код в CreateRemoteThread передавался указатель на LoadLibraryA и параметром был путь к dll'ке. А тут Code Injection какой то. А вообще, да, этому методу уже лет много, помойму Рихтер его описал первым.
UFO just landed and posted this here
Почему-то некоторые считают, что написать статью — это взять исходник и откомментировать каждый чих.
Читал где то магию про native api, там народ более злые вещи делал, но UAC такое недопустит, ежели в нем конечно нет дырки, позволяющей его усыпить или ослепить
ну их возможность исключать никак нельзя, если они его перепиливали. Тем более учитывая тот факт, что когда только появилась виста, Symantec опубликовали отчет-исследование ее безопасности. UAC там был как решето, потом уже там много чего исправили.
>>ее враг только firewall, так как они оповещают о попытках изменения памяти
Кто бы мог подумать…
Во-первых, читайте Рихтера. Во-вторых, еще раз перечитайте Рихтера, думаю, давать более развернутый комментарий нет смысла.
«а например, для обновления своего приложения. „

и где пример?
UFO just landed and posted this here
1) Ниодная проактивная защита такое про пропустит без предупреждения
2) В статье совсем не DLL инъекция, как заметили другие комментаторы, DLL инъекцию можно осуществить либо документированным способом ака хуком, инъекцией кода, подгружающего DLL, патч импортов файла, заменой DLL и т.д.; а здесь, как я понял, просто инъекция исполняемого кода
А нафига все это разрешено в винде по умолчанию? Есть ли мирные применения вызовов типа WriteProcessMemory, VirtualAllocEx и CreateRemoteThred? Мне. кроме отладки (и то для этого вроде есть отдельные функции) ничего не видится.

В любом случае, лезть в чужую память и тем более создавать там нити — это же ьтолько вирусу может быть полезно.
Админ-процессам разрешено. Что вас удивляет? Мирные цели описаны в msdn.
Антивирусы, фаерволлы, различные надстройки для готовых приложений (когда нет исходников).
> Антивирусы, фаерволлы,

Зачем фаерволлу или антивирусу *записывать* что-то в чужую память и тем более создавать там нити? Пусть в своем процессе их создает.

> различные надстройки для готовых приложений (когда нет исходников).

Кряки что ли ?)) В любом случае monkey patching это зло.

>Зачем фаерволлу или антивирусу *записывать* что-то в чужую память и тем более создавать там нити?
> Пусть в своем процессе их создает.

хм, а как по вашему он будет блокировать?! только подменой на себя.
Блокировать что? Соединение с другим хостом— пусть говорит винде, чтобы та например из функиции coonect() или как там создать сокет :) вернула ошибку, и все. Все же делается через вызовы API. Зачем в чужой код то лезть? Это же криво, и я так подозреваю, открывает потенциальные бреши.
т.е. другими словами ты не совсем понимаешь как устроено ядро виндов.

>Зачем в чужой код то лезть
если руки ровные, то это не нарушает работу приложения, а просто перехватывает нужный функционал.

а как другое приложение узнает о ваших злодеяния?! антивирус действует абсолютно тем же методом перехвата чтоб блокировать другие перехваты.

Очевидно, надо как-то со стороны ядра поставить фильтр на вызов того же connect(), чтобы ядро спрашивало, разрешить его или нет. По моему, логично. И ведь, в случае с внедрением, зловредный код может отследить внедрение антивируса в себя и как-то пропатчить его код, так ведь? Ну а если такого функционала нет в виндах, это уже не мои проблемы, а проблемы индусов.

Да в конце концов, криво это, блин, ну как мне еще объяснить?
и тогда система встанет колом, если ядро будет постоянно ждать ответа от приложений юзер мода! ядру нужно будет тогда выдавать список процессов\тредов запрещённых, а это расточительство при сравнении сигнатур внутри ядра, в случае же с отдельным процессом блокируется по ситуации — ядро не напрягается, а приложение спокойно сканирует отправляемые пакеты (внутри каждого процесса), и тем самым может предотвратить посыл конфиденциальной информации, и при этом многозадачность не страдает.

> зловредный код может отследить внедрение антивируса в себя и как-то пропатчить его код, так ведь

только по косвенным признакам и то не всегда, потому что антивирус установлен раньше и перехват уже завязан на него, тем самым он сканирует зловредный код ещё до его запуска.
> и тогда система встанет колом

Да ну, вряд ли connect() осуществляется больше пары десятков раз в секунду, при активном серфинге, если конечно юзер не занимается сканированием портов :) И к тому же, если ядро вытесняемое (в смысле возможно переключать задачи, даже если процесс в ядре находится), то урона многозадачности не будет, так ведь? Блокируется то только поток, запрашивающий соединение. Хотя, конечно еть накладные расходы на IPC но они по-любому есть.

Ну хорошо, мы ж можем написать незловредный код, единственная задача которого — просматривать свое адресное пространство на предмет обнаружения левого кода и его патчения :) А уж после — безнаказанно подгружать с сети любые файлы, как вам идея?))

>> зловредный код может отследить внедрение антивируса в себя и как-то пропатчить его код, так ведь

> только по косвенным признакам и то не всегда

Да ну, тупо получить список доступных областей памяти и проверить на наличие левых (+ возможно код антивируса по одному и тому же адресу всегда находится).

Хотя конечно, я особо принцип работы антивирусов не знаю, но факт — если располагать свой код в процессе-вирусе, у последнего есть возможность теоретически сделать с ним все что угодно.
> то урона многозадачности не будет, так ведь?

это только в случае вызова крайне редкой функции! а что насчет обращения к файлу, к памяти? это всё нужно чистить на уровне ядра по твоему?! лучше чуть затормозить отдельный процесс чем замочить ядро.

>Ну хорошо, мы ж можем написать незловредный код, единственная задача которого — просматривать свое адресное пространство на предмет обнаружения левого кода и его патчения :) А уж после — безнаказанно подгружать с сети любые файлы, как вам идея?))

грош цена твоей идее, ты думаешь что перехватом нельзя спрятаться от такого?! программа вообще может думать что она одна запущена, именно потому что до неё были установлены хуки.

> Да ну, тупо получить список доступных областей памяти и проверить на наличие левых (+
> возможно код антивируса по одному и тому же адресу всегда находится).

вот именно что тупо…

например цепляем хуком свою длл, во время подключения заворачиваю все вызовы нумерации дллок на себя- как ты собираешся определять что дллка есть? если я подделаю выдачу.
Это всё так и чистится через SD-таблицу, перехватывая вызовы ядерных NtAPI функций. Примеры приводить не буду (ибо это — точно счастье кулхацкеров), но самый банальный пример — подгрузка своего драйвера (который суть PEXE файл с определенной точной входа, но исполняется в контексте ядра), прописывания хук-функций по статичным адресам по смещению от адреса krnl и запись этих адресов в SDT поверх старых.
Это гораздо опасней, потому что крэш такого драйвера положит и всю систему. а т.к. антивирь ставится первым делом то не обязательно так глубоко лезть, уже в следствии можно не давать ставить не понятные драйвера(без прав то, хрен поставишь драйвер, разве что...).

понятное дело что нуль кольце можно ой как накуралесить (:
А проблема в том, что нормальный AV сразу вешает свой драйвер и хучит почти все «отладочные» функции на себя. Причем именно их NT-реализацию (а это null-ring), что не позволяет пользоваться заглушками на библиотеки (вроде переписывания какой-нибудь user32.dll). Яркий пример — Комода.
> например цепляем хуком свою длл, во время подключения заворачиваю все вызовы нумерации дллок на себя- как ты собираешся определять что дллка есть? если я подделаю выдачу.

Можно физически сканировать область памяти, т е например через 1024 байт всю вирт. память проверять на доступность для чтения/записи, еслши доступна — значит эта страница выделена процессу. Далее в доступных кучках ищем заголовок exe/dll и определяем что за файл (какая dll) туда отображена. Если exe-заголовка нет — значит это код инжектированный через WriteMemory.

Опять же, можно сканировать кучу, у только что запущенного процесса в ней должно быть почти пусто (разве что системные библиотеки неного для себя там выделят).

Я точно знаю, что сканирование памяти в поисках сигнатуры использовалось какими-то зловредями чтобы найти системные dll и адреса импорта без обращения к GetProcAddr.
надоело мне одно и тоже повторять…
FreeCap или SocksCap (не помню точно) внедряет свою DLL в процесс и ставит хуки на connect, send, recv (для работы через прокси).

GameGuard (популярная защита для MMORPG) внедряет свой модуль во все процессы и перехватывает основные функции WinAPI для осуществления контроля и защиты игры от внешнего воздействия (WriteProcessMemory, SendMessage и PostMessage и др.).

Сам в свое время разрабатывал защиту для сервера Lineage, которая внедрялась в клиент игры, создавала рабочие потоки, перехватывала некоторые внутренние вызовы между библиотеками и др.

Подобные взаимодействия используются для отладки, контроля, расширения функционала и многого другого.
> FreeCap или SocksCap (не помню точно) внедряет свою DLL в процесс и ставит хуки на connect, send, recv (для работы через прокси).

А если программа получает адреса этих функций нестандартным способом (например, напрямик от GetProcAddr, а не импортом системной dll ), способ ведь не прокатит? Правильнее создавать виртуальный сетевой интерфейс, который будет работать через socks (типа как VPN), и редиректить вызовы программы на него (хотя тут наверно надо поддержку со стороны ядра винды).

> GameGuard (популярная защита для MMORPG) внедряет свой модуль во все процессы

Ну это уже зловредство какое-то, а вдруг она внедрит свой модуль в процесс банковского клиента, там что-то глюкнет и у пользователя обнулится баланс? Или ему заблокируют счет за попытку внедрения в клиент, или еще что-то? А если модуль внедрится в процесс проприетарного компонента, работающего с железом, который из-за этого вылетит в синий экран? Это же опасно и нестабильно, внедрять свой код в чужой процесс.

И кстати, ведь этот GameGuard можно обмануть, если подсунуть ему патченное ядро Windows, в котором например, некоторые процессы не будут показаны gameGuard'у?

> Подобные взаимодействия используются для отладки, контроля, расширения функционала и многого другого.

Для отладки есть свое API, нет разве? В любом случае, отладка — это не то чем занимается домашний пользоатель, и не то, что должно быть разрешено по умолчанию. Расширение функционала таким способом — ну явный изврат, согласитесь?
что мешает перехватывает GetProcAddr?! (:

> а вдруг она внедрит свой модуль в процесс банковского клиента
если банковский клиент написан без хаков то ни че с ним не будет.

> А если модуль внедрится в процесс проприетарного компонента, работающего с железом

с железом работает драйвер, который является компонентом ядра, а там совсем другая история.
в синий экран можно уложить систему очень просто особенно ни чаго не написав:

HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWSNT\CURRENTVERSION\WINDOWS\AppInit_DLLs — прописав туда дллку которая использует какие нибудь апи из user32.dll. система сама прицепит эту дллку во все процессы, а так как оно начнёт её вещать во все подряд в некоторых процессах не будет адресного пространства user32.dll и система упадёт в бсод.

ВНИМАНИЕ!!! делать этого не следует т.к. и в сэйф моде оно тоже будет туда падать! и восстановить можно только лишь сняв винт или загрузившись в другую систему и откатить\отредактировать реестр.

ЗЫ. между прочим аутпост пользуется тем же ключом чтоб внедрится в систему.

А если программа получает адреса этих функций нестандартным способом (например, напрямик от GetProcAddr, а не импортом системной dll ), способ ведь не прокатит? Правильнее создавать виртуальный сетевой интерфейс, который будет работать через socks (типа как VPN), и редиректить вызовы программы на него (хотя тут наверно надо поддержку со стороны ядра винды).

Я и не говорил об изменении таблицы импорта. Патчится непосредственно код функции (ставится безусловный переход на функцию-обработчик с сохранением старых команд в отдельной области).
В данном случае, «правильнее» использовать LSP. НО внедрить DLL и перехватить функции можно на лету с довольно ограниченными правами (при чем в рамках конкретного приложения). А добавить, к примеру, собственный провайдер в цепочку на порядок сложнее и в случае какой-либо ошибки последствия будут «катастрофичны».

В любом случае, отладка — это не то чем занимается домашний пользоатель, и не то, что должно быть разрешено по умолчанию. Расширение функционала таким способом — ну явный изврат, согласитесь?

Если нет других способов и сделано грамотно и по всем правилам, то почему сразу «изврат»? Система обязана быть гибкой и позволять подобные манипуляции при наличии соответствующих прав у процесса.
> Если нет других способов и сделано грамотно и по всем правилам, то почему сразу «изврат»?

Ага, это те же люди делают, которые пишут код типа if (booleanVar.toString().length() == 4 /* true */) {… } else if (booleanVar.toString().length() == 5 /* false */) {… } else { throw new Exception(«Fatal Error»); }. Индусские техники, я смотрю, пользуются популярностью.

Любое использование извратов усложняет отладку кода, увеличивает вероятность появления их ошибок, и т.д. Хотя МС тоже молодцы, мне это нравится:

> One major common issue with LSPs was that if they were to be removed or unregistered improperly or if the LSP was buggy, it would result in corruption of the Winsock catalog in the registry, and the entire TCP/IP stack would break and the computer could no longer access the network.

>… in Windows XP Service Pack 2, Windows Server 2003 Service Pack 1 and all later Windows operating systems, in which Winsock has the ability to self-heal after a user uninstalls such an LSP…

(из Википедии).

Вот хоть стой, хоть падай ((
Ага, это те же люди делают, которые пишут код типа if (booleanVar.toString().length() == 4 /* true */) {… } else if (booleanVar.toString().length() == 5 /* false */) {… } else { throw new Exception(«Fatal Error»); }.

Не надо обобщать.
Может я неудачник, но у меня при компиляции аналогичной программы сразу же сработал антивирус. Пришлось поизвращаться (получать адрес WriteProcessMemory через GetProcAddress, а перед этим преобразовывать строку с именем функции), чтобы обойти детекцию.

А использовал я это для перехвата (модификация мне была не особо нужна) и автоматического анализа («в реальном времени») с помощью своей программы трафика браузера на один игровой сайт (боты там разумеется были запрещены, но такого пассивного бота засечь не возможно).
А подделать своего «клиента-бота», что бы он под браузер «косил» не лучше бы было?
Лучше. Но я не умею идеально (т.е. с выполнением javascript в точности со всеми багами и фичами, учетом кук, загрузкой ресурсов в точно такой же последовательности и с точно таким же кэшированием соединений и.т.д.) подделываться под браузер. Конечно, вряд ли у них там сложная защита, но я в таких делах параноик.
Ну IE очень удобно контролировать через COM-объекты если я не путаю :) Без всяких извратов и предупреждений антивируса к слову.
Да, но я этой магией так и не овладел :(. Да и не кошерно как-то IE использовать. Вот если бы у firefox такое было…
Люди пишут же свои расширения для FF, так что, возможно, там целое непаханное поле.
Тому, кто делает подобные вещи, надо отрывать руки и засовывать их в естественные отверстия тела. Одних — потому что по ним УК РФ плачет, а остальных — чтобы больше за клавиатуру не садились, потому что RTFM — не для них и все надо делать через некоторое естественное отверстие организма, вот и инжектятся «для обновления».
Вы немного не поняли сути. Это абсолютно «легальный» метод.
А если руки из известного места растут у Вас — это не повод ругаться на Рихтера & co.
Если API позволяет такие вещи делать — не факт что их делать следует. Руткиты тоже в венде работают, но никто же не говорит, что это легально?

Для внедрения своего кода в процесс можно использовать параметр AppInit_DLLs и это как раз НОРМАЛЬНЫЙ способ.
Вы ничего не понимаете в программировании (с)
Если в AppInit_DLLs (упаси Вас от такого) случайно окажется «кривая» dll, ляжет вся система. И не загрузится. Не надо прикрывать собственное невежество громкими словами. Лучше почитайте умные книги.
А если инжектор окажется кривым — он заинжектит черт знает что во все процессы. Так что не аргумент.
выше я описывал что бывает если дллка кривая оказывается в appinit_dlls (:
А я выше написал, что возможно и инжектор будет кривым. Благо написать инжектор — сложнее, чем либу которая сможет нормально загрузится и будет что-то делать только в нужном процессе.
хм слышал про detours? про хуки? при чем тут код инжекта? в случае хуков ты только пользовательское пространство зомбируешь, а appinit_dlls вешает ддлку во все процессы подрят
А зачем легальному софту хуки через инжект?
А проблема закгрузки во все процессы решается с пол-пинка, или так сложно понять кто же именно либу грузит из самой либы?
Вопрос к автору, покажи где у тебя тут DLL?
Sign up to leave a comment.

Articles