Wpe pro не видит процесс

Wpe pro не видит процесс

Please complete the security check to access youhack.ru

Why do I have to complete a CAPTCHA?

Completing the CAPTCHA proves you are a human and gives you temporary access to the web property.

What can I do to prevent this in the future?

If you are on a personal connection, like at home, you can run an anti-virus scan on your device to make sure it is not infected with malware.

If you are at an office or shared network, you can ask the network administrator to run a scan across the network looking for misconfigured or infected devices.

Another way to prevent getting this page in the future is to use Privacy Pass. You may need to download version 2.0 now from the Chrome Web Store.

Cloudflare Ray ID: 57a1a885feebc79d • Your IP : 5.45.65.94 • Performance & security by Cloudflare

Популярные файлы Новые файлы
WPE PRO самый мошный чит для wow любой версии + мануал
ЧИТ WowMaelstrom 2.4.3 RC3 спидхак с обходом антиспид хака
QuestHelper для WOTLK 3.0.9 ru
Atlasloot Enhanced для WOTLK 3.0.9
QuestHelper Для русского WoW (2.4.3)
Master Plan
WoW TNT чит 2015(Wow 3.3.5a)(работает на WowCircle)
Личный Кабинет Privat by Symphony
Deadly Boss Mods для 3.3.5a
GatherMate2 для 3.3.5a

WPE PRO самый мошный чит для wow любой версии + мануал

1. скачайте и распакуйте файлы
2. запустите WPE PRO.exe, но ничего с ним не делайте
3. запустите PermEdit.exe и среди списка процессов найдите WPE PRO.exe. Тыкните по нему и нажмите Grant Permissions. В появившемся окошке нажмите OK
4. запускаем клиент ВоВа (можете зайти на сервер, а можете зайти позже — разницы не имеет)
5. возвращаемся к уже запущенному WPE PRO. Сверху слева нажимаем Target program. В появившемся списке выбираем WoW.exe и нажимаем Open.

Выполнив эти шаги вы полностью настроили WPE Pro для работы.

Редактирование фильтров:
в 99% случаев вы будете пользоваться фильтрами, поэтому теперь рассмотрим, как их редактировать.

5) вы обязательно выполнили шаги 0, 1, 2, 3, 4 описанные выше
6) находим строчку Filter 1 и тыкаем по ней два раза

7) попадаем в новое окно

8) в поля SEARCH и MODIFY вам надо вписать HEX ID спеллов/предметов/талантов — вобщем того, что вы хотите изменить. В счастливые времена, когда еще не было Burning Crusade с помощью этой програмым можно было выучить все таланты, одеться в самый крутой шмот и даже научить приста использовать таунт и шилд блок. Но сейчас все "легкие" варианты уже не работают и поэтому описывать как получить HEX ID — уже не имеет смысла.
9) на нашем форуме в разделе World of Warcraft ищите темы с пометкой [WPE]. В этих темах будет просто указано в какую колонку какие цифры вписать и что в итоге получится =)
10) после того, как вы вписали нужные цифры (которые нашли в темах с пометкой [WPE] ), жмем кнопку Apply
11) в строке Filter 1 ставим галочку
12) нажимаем кнопку ON (кнопка ON очень маленькая и спряталась чуть выше, чем строка Filter 1)
13) если вы все сделали правильно, то WPE PRO примет такой вид:

Думаю, что большинство из местных обитателей знакомы с понятием сниффера. Несмотря на то, что конечная цель у них одна и та же (перехват пакетов, соответствующих определённым критериям), достигают они её совершенно разным образом. Какой-то софт слушает указанный сетевой интерфейс (например, Wireshark, где это реализовано при помощи библиотеки Pcap), а какой-то — перехватывает вызовы ответственных за взаимодействие с сетью WinAPI-функций. И у того, и у другого метода есть свои плюсы и минусы, однако если по задаче необходим перехват пакетов от конкретного заранее известного приложения, то второй вариант, как правило, банально удобнее. В этом случае нет нужды узнавать IP-адреса и порты, которые использует данная программа (особенно учитывая тот факт, что их может быть довольно много), и можно просто сказать «я хочу перехватывать все пакеты вот этого приложения». Удобно, не правда ли?

Пожалуй, самым популярным на сегодняшний день сниффером, работающим по принципу перехвата вызовов определённых WinAPI-функций, является WPE Pro. Возможно, многие из вас слышали о нём на различных форумах, посвящённых онлайн-играм, ведь именно для получения преимуществ в различных играх этот сниффер в большинстве случаев и используется. Свою задачу он выполняет прекрасно, однако у него есть один неприятный недостаток — он не умеет работать с 64-битными приложениями. Так уж вышло, что по одной из возникших задач мне как раз понадобилось перехватывать пакеты от 64-битного приложения, и я посмотрел в сторону Wireshark. К сожалению, использовать его в данной ситуации было не очень удобно — исследуемое приложение отправляло данные на разные IP-адреса, каждый раз открывая новый порт. Погуглив немного, я обнаружил, что готовых аналогов WPE Pro с поддержкой x64 нет (если они всё же есть, буду признателен за ссылки в комментариях — обратите внимание, что речь идёт о Windows). Автор WPE Pro не оставил никаких контактных данных на официальном сайте и в самом сниффере, так что я принял решение разобраться в этом вопросе самостоятельно.

Как протекал процесс и что из этого вышло, читайте под катом.

Итак, что необходимо сделать в первую очередь? Верно, скачать сам WPE Pro. Сделать это можно на официальном сайте сниффера, где предлагаются для загрузки сразу две версии — 0.9a и 1.3. Мы будем рассматривать версию 0.9a, потому что именно она работает на последних версиях Windows.

Скачали? Теперь давайте проверим, не накрыт ли он каким-нибудь паковщиком или протектором:

Похоже, на этот раз снимать нам ничего не придётся. Тогда берём в руки OllyDbg и загружаем «WpePro.net.exe». Давайте для примера запустим 64-битную версию Dependency Walker’а и узнаем, почему WPE Pro не может отобразить его в списке доступных для перехвата процессов.

Получить список текущих процессов в WinAPI можно двумя основными путями:

  • При помощи связки функций CreateToolhelp32Snapshot, Process32First и Process32Next (пример можно найти, например, тут)
  • При помощи функции EnumProcesses (пример можно найти, например, тут)

При желании можете почитать о разнице между данными способами, например, тут.

Смотрим на intermodular calls модуля «WpePro.net.exe» и видим, что ни CreateToolhelp32Snapshot, ни EnumProcesses тут нет. Возможно, приложение получает их адрес в run-time при помощи WinAPI-функции GetProcAddress, так что давайте посмотрим на referenced text strings. На этот раз всё с точностью наоборот — нашлась как строка «CreateToolhelp32Snapshot», так и «EnumProcesses». Ставим бряки на места, где происходит обращение к данным строкам, нажимаем на кнопку «Target program» в WPE Pro и смотрим на место, на котором мы остановились:

Если понажимать F9, то мы увидим, что этот же бряк срабатывает ещё несколько раз, прежде чем наконец появится окно со списком текущих процессов. Давайте посмотрим, почему в нём не оказалось Dependency Walker’а. Закрываем окно, снова нажимаем на кнопку «Target program» и выполняем пошаговую отладку, начиная с того же самого бряка. Вскоре после вызовов GetProcAddress мы попадаем в цикл, в котором последовательно вызываются следующие функции — OpenProcess, EnumProcessModules, скрывающаяся за инструкцией CALL DWORD PTR DS:[EDI+10], GetModuleFileNameEx (инструкция CALL DWORD PTR DS:[ECX+14]) и CloseHandle:

Давайте поставим бряк по адресу 0x0042A910, где происходит занесение на стек последнего аргумента функции OpenProcess — PID, и попробуем дождаться момента, когда регистр EAX примет значение, равное идентификатору процесса Dependency Walker’а. На моей машине в этот момент он был равен 6600, т.е. 0x19C8.

Если пробежаться по коду, то мы увидим, что в случае Dependency Walker’а инструкция TEST EAX,EAX, находящаяся по адресу 0x0042A942 и следующая за вызовом WinAPI-функции EnumProcessModules, заставляет следующий за ней оператор условного перехода прыгнуть по адресу 0x0042A9E7, где находится вызов CloseHandle, что, разумеется, не является нормальным ходом работы приложения, ведь мы ещё даже не дошли до вызова функции GetModuleFileNameEx:

Обратите внимание на код ошибки — 0x12B (ERROR_PARTIAL_COPY). Давайте посмотрим, почему такое может происходить. Открываем документацию к функции EnumProcessModules и видим следующее:

If this function is called from a 32-bit application running on WOW64, it can only enumerate the modules of a 32-bit process. If the process is a 64-bit process, this function fails and the last error code is ERROR_PARTIAL_COPY (299)

Да, это как раз наш случай.

Несмотря на то, что в документации к функции GetModuleFileNameEx не сказано ничего похожего, ведёт она себя аналогичным образом, что описано, например, тут. Одним из вариантов решения этой проблемы является использование функции QueryFullProcessImageName, которая будет отрабатывать нормально даже в случае вызова из 32-битного приложения, запущенного в WOW64, в случае применения её к 64-битному процессу.

Теперь мы можем занопить вызов функции EnumProcessModules

и написать code cave для замены GetModuleFileNameEx функцией QueryFullProcessImageName:

Теперь WPE Pro отображает множество новых процессов, в том числе и наш Dependency Walker:

Однако при попытке приаттачиться к данному процессу WPE Pro выдаёт неприятное для нас сообщение:

Тут мы уже, к сожалению, ничего не можем поделать. DLL-инъекция осуществляется путём внедрения своей DLL в адресное пространство target-процесса, а на MSDN сказано следующее:

On 64-bit Windows, a 64-bit process cannot load a 32-bit dynamic-link library (DLL). Additionally, a 32-bit process cannot load a 64-bit DLL

Несложно догадаться, что WPE Pro поставляется только с 32-битной библиотекой.

Что же делать? Писать свой перехватчик WinSock? А почему бы и нет?

Но как мы это будем осуществлять? Первое, что приходит на ум — это воспользоваться Detours, однако на официальном сайте сразу же сообщается, что поддержка 64-битных приложений есть только в Professional Edition:

Detours Express is limited to 32-bit processes on x86 processors

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

You will be able to write injection libraries and host processes compiled for AnyCPU, which will allow you to inject your code into 32- and 64-Bit processes from 64- and 32-Bit processes by using the very same assembly in all cases

С небольшими изменениями примера, продемонстрированного в официальном туториале, получаем код, перехватывающий вызовы функций recv и send из WinSock и выводящий перехваченные сообщения побайтово в шестнадцатеричном виде:

Код программы, совершающей DLL-инъекцию

Код самой DLL, которая будет инжектиться в целевой процесс

Конечно, тут ещё есть, над чем поработать:

  • Во-первых, отсутствует перехват WSARecv, WSASend и некоторых других функций, которые могут использоваться в целевых приложениях
  • Во-вторых, отсутствие GUI и «строкового» представления перехваченных сообщений
  • etc

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

Послесловие

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

Спасибо за внимание, и снова надеюсь, что статья оказалась кому-нибудь полезной.

Разместил: Aras Категория: Читы
Размер: 0 KB Дата: 18.01.2009
Версия файла: Источник: wow-files.ru
Ссылка на основную публикацию
Logitech deluxe 250 keyboard драйвер
Ниже показаны совместимые с ОС Windows 7 драйвера для Logitech Deluxe 250 USB Keyboard. Каждый драйвер клавиатуры Logitech Deluxe 250...
Adblock detector