WPE Pro-Контроль пакетов для взлома онлайн игр
Вся информация взята из свободных источников и предоставлена исключительно в ознакомительных целях и не является призывом к действию.
Приложение wpe pro позволит провести необходимую модификацию данных. При использовании программы wpe pro опытный специалист выбирает активный процесс, находящийся в памяти диспетчера задач, и изменяет данные. Однако перед этим он перехватывает и меняет до того, как они достигают своего пункта назначения.
Данное приложение многофункционально и универсально, однако пригодится только тем пользователям, которые знают, как правильно с ним обращаться. В любом другом случае даже подробная инструкция, которая идет вместе с приложением, не сможет вам существенно помочь.
Принцип работы или как оно работает?
Для обмена данными между сервером и компьютером пользователя(нами) используют такие пакеты:
— Send – исходящий пакет что отправляется на сервер от нас.
— Recv – входящий пакет что приходит от сервера к нашему компу.
Все дело состоит в подмене этих пакетов, а точней первого типа пакетов.
Второй тип пакетов мы не редактируем, а беремся за первый объясню почему: Recv-пакеты не дадут нам желаемого результата, потому что они не идут обратно на сервер, а только в одном направлении. А для того чтоб изменить какую-то инфу на сервере нужно ее менять на нашем компе до отправки.
Если Вы поставите фильтр между сервером и компом на Recv-пакеты(входящие), то:
— информация в проге/игре измениться только визуально;
— сервер кинет ошибку;
— ничего не изменится.
- Запись входящих и исходящих пакетов
Для того чтоб отправлять пакеты и создавать фильтры, нужно записать пакеты, без них работа невозможна.
ВНИМАНИЕ! Перед работой с программой выключите антивирус или добавьте папку с программой в исключения (антивирь ругается не только на exe-файл, а и на dll).
— запустите программу/игру с которой происходить запись пакетов;
— запустите WPE(для удобства киньте ярлык на рабочий стол);
— выберете программу с какой будете записывать пакеты, нажав на Target
— выбираем программу и нажимаем Open.
— нажимаем на треугольник для записи;
— заходим в игру/программу делаем действия, пакеты которых хотим записать(например, машем рукой). Возможно программа что-то делает без вашего вмешательства тогда только записуем;
— когда действие закончилось быстренько переходим в окно WPE и нажимаем
на красный квадрат.
2. Создание фильтров
Пакет записали, но для создания фильтра необходимо 2 примерно одинаковых пакетов. Поехали:
— копируем строчку кода которая выполняет действие «машем рукой» — выделяем → ПКМ(61 63 74 3D 66 6B 69 6E 67 63 68 61 74 26 6C 61);
— ставим галочку на фильтре;
— нажимаем кнопку создать/редактировать фильтр;
— появится окошко создания фильтра;
— в поле SEARCH вставляем код первого пакета(действие «машем рукой») с помощью сочетания клавиш Ctrl + V(или ПКМ → Вставить);
— в поле Filter name можно задать имя фильтра;
— в поле Search in: убираем галочки с Recv и Recv From;
— нажимаем кнопку Apply;
— также копируем похожий пакет с второй группы(вторая сессия записи) с действием «хитаем головой»(48 54 54 50 2F 31 2E 31 20 32 30 30 20 4F 4B 0D) и вставляем в поле MODIFY окна Filter edit;
— опять Apply и все. Фильтр готов к работе;
— остается только включить,нажав ON
Теперь когда мы будем нажимать на кнопку «машем рукой» персонаж будет выполнять действие «хитаем головой».
3. Отправка записанных пакетов на сервер
С помощью WPE можно как составлять список отправляемых пакетов так и отправлять их по одному. Сначала разберем отправку 1 пакета:
— нажимаем ПКМ на пакете → Отправка. И вот что мы видим:
Большое текстовое поле дает возможность редактировать пакет перед отправкой(не забывайте что 16-я система исчисления состоит из цифр и букв от A до F). С левой стороны текстового поля находится hex(16-я система исчисления), а справа ASCII кодировки.
Регулировать объем пакета можно в поле Packet size.
В поле Sent видим количество отосланных пакетов ( в этом случае 1) и количество ошибок при отсылке.
В поле Send можно задавать задержку между отправками(Timer), с ним будьте осторожней, если поставить очень мало сразу попадете в бан. Выбор Continuously и Time(s) думаю Вам понятен. При нажатии точки New Soketнужно задать порт и ip сервера на который пойдет пакет. После нажатия треугольника ваш пакет «полетит». Остановить догадаетесь.
Рассмотрим вкладку Send. Она имеет такие же кнопки как вкладка Filters. Кроме них здесь есть кнопки создание нового пакета(), отправки пакета/пакетов(), остановка отправки(). Изменять пакеты можно нажав на правка или двойной щелчок на нем. После нажатия пакеты Вы увидите окошко с подобными настройками как при отправлении 1 пакета.
И напоследок рассмотрим вкладки главного меню:
— File включает пункты новый, открыть что делают ту же функцию(возможно автор недосмотрел). Cloze закрывает записанную группу пакетов. Save as – сохраняет группы пакетов в формате pac(формат WPE) после чего их можно опять открыть в программе и продолжить работу; и формате txt(WPE не поддерживает).
— Edit – функции буфера обмена.
— View – настройка интерфейса панелей программы.
— Window – удобно размещает записанные пакеты по рабочей области программы.
Еще в программе есть Find(поиск).
При выборе Hex поиск будет произведен в левой части пакета, то есть в 16-й системе исчисления, при ASCII кодировке в правой части пакета.
Разбираемся с поддержкой x64 в 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
Однако продемонстрированного здесь функционала было вполне достаточно для решения поставленной передо мной задачей, а остальное уже остаётся на усмотрение читателей.
Послесловие
Исследование и модификация бинарных файлов не всегда даёт моментальный результат, как это наблюдалось в предыдущих моих статьях (если интересно, читайте об этом тут и тут), так что иногда приходится вернуться в самое начало и изменить свой подход к решению проблемы. Но в этом нет абсолютно ничего ненормального — как известно, любой опыт полезен, а реверс-инжиниринг — не исключение.
Спасибо за внимание, и снова надеюсь, что статья оказалась кому-нибудь полезной.