[@dark]

А точнее в статье описан способ реализации читов на основе использования функций игрового клиента. А если ещё точнее, то описан метод создания пакетчика на примере спамера :)

Недавно получил заказ на создание авто-спамилки для игры Blood and Soul с сохранением моего права на его распространение. Штука не особо востребованная, поэтому решил рассказать вам на примере реализации спамера о довольно интересном методе создания читов для игр. Ну и в целом статья поможет вам понять ход мыслей программиста при создании нужного чита.
Ссылки на инструменты я дам в конце статьи.

Итак, задача - Научиться программным способом постить в чат свои сообщения. Защита игрового клиента не даёт использовать кликеры, поэтому этот вариант сразу опустим. Можно, конечно, рыть защиту или просто заюзать мой обход для неё - но в контексте статьи эти варианты не интересны. Первым вариантом реализации поставленной задачи в голову приходит, разумеется, "пакетный" способ. Иными словами мы можем разобрать сетевой протокол клиент-серверного взаимодействия BS и отталкиваясь от этого генерить нужный пакет для посылки сообщения в чат. Как его слать? Можно через WPF, можно сделать DLL, которая бы хукала какую-либо wsock API для определения сокета и просто в цикле слала бы в сокет ваш пакет. Но это уже второе дело, сейчас главное найти вариант хотя бы вручную постить сообщения в чат без мышки и клавы :)
Для начала пробуем определить какими пакетами осуществляется пост сообщений в чат. Для этого нам требуется перехватить исходящие пакеты игрового клиента. Как? Вариантов много - начиная со сниффера, заканчивая API-шпионами и дебаггерами. Я выбрал третий вариант, т.к. у него просто больше возможностей чем у остальных. Из дебаггеров я выбрал, разумеется, ollydbg. Аттачимся к игре и ставим бряк на send():



Далее постим в чат, например, "aaaa", после чего срабатывает наш breakpoint:



В стеке мы имеем аргументы, с которыми вызывался send. Из них вытаскиваем адрес пакета и его длину. Вот таким образом разным текстом и в разные чаты шлём несколько сообщений и ловим соответствующие пакеты. Вот несколько пакетов чата:

общий чат:
BB A9 CB D5 A6 0F FB 76 38 00 00 00 00 00 00 00  | .......v8.......
FF FF FF FF 00 00 00 00 04 00 61 00 61 00 61 00  | ..........a.a.a.
61 00 61 00 61 00 61 00 61 00 61 00 61 00 61 00  | a.a.a.a.a.a.a.a.
61 00 61 00 61 00 61 00 61 00 00 00 	 	 | a.a.a.a.a....

BB A9 CB D5 A6 0F FB 76 38 00 00 00 00 00 00 00  | .......v8.......
FF FF FF FF 00 00 00 00 04 00 62 00 62 00 62 00  | ..........b.b.b.
62 00 62 00 62 00 62 00 62 00 62 00 62 00 62 00  | b.b.b.b.b.b.b.b.
62 00 62 00 62 00 62 00 62 00 00 00 	  	 | b.b.b.b.b....

B4 A9 CB C1 A6 0F FB 76 2C 00 00 00 00 00 00 00  | .......v,.......
FF FF FF FF 00 00 00 00 04 00 64 00 77 00 64 00  | ..........d.w.d.
77 00 64 00 77 00 64 00 77 00 64 00 77 00 00 00  | w.d.w.d.w.d.w...

Релогин:
B1 A9 CB CD A6 0F FB 76 20 00 00 00 00 00 00 00  | .......v .......
FF FF FF FF 00 00 00 00 04 00 61 00 61 00 61 00  | ..........a.a.a.
61 00 00 00 01  				 | a....	

BE A9 CB CD A6 0F FB 76 20 00 00 00 00 00 00 00  | .......v .......
FF FF FF FF 00 00 00 00 04 00 61 00 61 00 61 00  | ..........a.a.a.
61 00 00 00 D1  				 | a....

локация:
B4 A9 CB D5 A6 0F FB 76 38 00 00 00 00 00 00 00  | .......v8.......
FF FF FF FF 00 00 00 00 05 00 61 00 61 00 61 00  | ..........a.a.a.
61 00 61 00 61 00 61 00 61 00 61 00 61 00 61 00  | a.a.a.a.a.a.a.a.
61 00 61 00 61 00 61 00 61 00 00 00 	  	 | a.a.a.a.a....

Меняя тип чата, длину текста и перелогиниваясь мы можем по пакету понять, какой байт за что отвечает. Исходя из этого набора пакетов я делаю следующие выводы на примере последнего пакета:
B4 A9 CB D5 A6 0F FB 76 38 00 00 00 00 00 00 00 FF FF FF FF 00 00 00 00 05 00 61 00 61 00 61 00 61 00 .......
B4 A9 CB D5 - неизвестная составляющая, которая в рамках сессии периодически меняется.
A6 0F FB 76 - не меняется. Видимо, ID персонажа или аккаунта - для нас не важно, главное, что константа.
38 00 00 00 - если посмотреть на второй скриншот, то видно, что это длина пакета минус 4. Это нам говорит о том, что первые 4 байта идут как бы отдельно от тела пакета и несут иной функциональный смысл.
00 00 00 00 FF FF FF FF 00 00 00 00 - константы. Не известно что, но нам впрочем и не важно.
05 - это тип чата! Видно, что в пакете для общего чата и локации этот байт отличается
00 61 00 61 00 61 00 61 ... - это сам текст в юникоде.
Вот тут мы сталкиваемся с главной проблемой, которая весьма усложняет поставленную задачу. Мы не знаем как генерируются первые 4 байта и для чего они нужны. Вероятно, они призваны защитить игру как раз от инжекта чужих пакетов. Что делать дальше? У нас два варианта - либо копать игру дебаггером в поисках места, где генерируется эти 4 байта, либо искать другой вариант решения задачи. Проблема первого варианта в том, что в алгоритме генерации этих 4 байт могут быть забиты такие величины, из-за которых наши пакеты внесут ассинхронизацию генерации этих байт между сервером и клиентом. Сложно, да? :) Ну допустим этот код генериться через каждые 3 отосланных пакета. Клиент и сервер абсолютно точно знают, когда его генерировать снова. Если мы вдруг шлём свой пакет в обход клиента, то клиент о посылке знать не будет, а сервер будет - отсюда последствия в виде ассинхронизации и дисконнекта. Вроде понятно объяснил.. Чтобы избежать подобных вероятных проблем, можно не генерировать свой код, а воспользоваться непосредственно клиентской функцией, которая его генерирует! Как найти эту самую функцию? Точно также, через дебаггер. Я не зря выше писал о причине использования дебаггера вместо сниффера и апи-шпиона.
Итак, снова брякаемся на send() и смотрим стек (тот скриншот №2). Первый же адрес в нём - это адрес возврата в функцию, которая вызвала send(). Точнее олька нам подсказывает, что это функция-член (или метод) ThreadSend класса XClient. Далее отпускаем и ищем этот метод в vEngine.dll, брякаем:



Шлём сообщение в чат и что мы видим? Бряк не срабатывает. Чисто логически это означает, что данный метод зациклен (если исключить варианты защиты от бряков). Да и по его названию можно понять, что это поток, который берёт из некой кучи пакеты и отправляет их в сокет. Побегав по этому методу бряками моя версия подтверждается.
Может показаться, что мы в тупике, потому что мы не знаем какая функция или метод кладёт сгенеренные пакеты в кучу. На самом деле логично предположить, что адрес этой кучи должен быть константным. Снова пару раз брякаемся на send() и видим, что отсылаемый пакет меняется, но всегда лежит по одному и тому же адресу!
В нашем случае это 0x05280264 (смотрите скриншот №2). Дальше всё элементарно! Ставим бряк на запись в память по этому адресу и пишем в чат:



Вуаля! Мы попадаем в метод AddMsg, в котором пакет записывается в эту самую очередь (буду называть её "кучей"). Этот метод в свою очередь вызывается методом Send класса XClient. Брякаемся на нём и постим любимые "aaaaa" в чат:



И вот мы внутри Send, смотрим его аргументы и понимаем, что дело в шляпе. Функция Send принимает два аргумента: отсылаемый пакет и его размер, после чего просто добавляет его в очередь. Если внимательнее посмотрите на пакет, то заметите, что в нём отсутствуют те первые 4 байта, значение которых мы хотели определить. По всей видимости они добавляются к пакету в методе ThreadSend. Но это для нас уже не важно, потому что мы можем слать пакеты через этот самый Send, а неопознанные байты будут добавлены методом ThreadSend.

Теперь перейдём к реализации. Я решил описать этот момент, т.к. там есть пара подводных камней. Первый из которых - это согласование вызовов. Метод Send должен вызываться как __thiscall, ибо это функция-член класса XClient. Подробнее об этом читайте в MSDN. Мы это легко можем определить по коду. Вот как вызывается Send:

CPU Disasm
Address   Hex dump          Command                                                         Comments
0082B398  ***179;. 8B55 D0        MOV EDX,DWORD PTR SS:[LOCAL.12]
0082B39B  ***179;. 52             PUSH EDX                                                        ; ***218;Arg2 => [LOCAL.12]
0082B39C  ***179;. 8B45 D4        MOV EAX,DWORD PTR SS:[LOCAL.11]                                 ; ***179;
0082B39F  ***179;. 50             PUSH EAX                                                        ; ***179;Arg1 => [LOCAL.11]
0082B3A0  ***179;. 8B4D CC        MOV ECX,DWORD PTR SS:[LOCAL.13]                                 ; ***179;
0082B3A3  ***179;. 83C1 60        ADD ECX,60                                                      ; ***179;
0082B3A6  ***179;. E8 F5DCBDFF    CALL client.004090A0                                            ; ***179;
0082B3AB  ***179;. 8BC8           MOV ECX,EAX                                                     ; ***179;
0082B3AD  ***179;. FF15 DCA49900  CALL DWORD PTR DS:[<&vEngine.?Send@XClient@vEngine@@QAEHPAXK@Z> ; ***192;vEngine.?Send@XClient@vEngine@@QAEHPAXK@Z

Оба аргумента передаются через стек, а вот через регистр ECX передаётся указатель на свой класс. Так какое согласование следует использовать нам? Я пошёл путём использования __fastcall. Данное соглашение о вызовах говорит компилятору о том, что первые два аргумента должны передаваться через регистр ECX (да, да!) и EDX. А остальные через стек. Получается, что прототип функции Send мы можем представить вот так:

int (__fastcall *vEngine__XClient__Send)(void *This, void *_EDX, void *Src, int Size);

В EDX можно передавать мусор, а вот указатель на класс, к сожалению, должен быть заполнен. Как его найти? Можно тупо через Cheat Engine найти его расположение через указатели, можно хукнуть какой-нибудь из методов этого класса и просто сохранять значение ECX для дальнейшего использования. Тут уже сами, т.к. задача тривиальна.

В итоге код, который шлёт пакет, занимает всего несколько строчек:

HMODULE hModule = GetModuleHandle("vEngine.dll");
(FARPROC &)vEngine__XClient__Send = (FARPROC)GetProcAddress(hModule, "?Send@XClient@vEngine@@QAEHPAXK@Z");
vEngine__XClient__Send((void *)thisAddr, (void *)0, (void *)packet, size);

Всё гениальное - просто. Точно также в других в играх вы можете обходить, например, шифрование траффика. Обратите внимание, что этим способом вы можете слать любой игровой пакет! Просто в контексте моей задачи я затронул только чат.
Мало того, используя описанный подход, вы можете использовать любую игровую функцию. Допустим, хотите из своего кода атаковать моба с неограниченной скоростью? Не вопрос - точно так же брякаетесь на методе Send и далее по описанному выше сценарию ищите ту функцию, которая отвечает за атаку и вызываете её с нужной вам скоростью. Огромный плюс этого способа написания читов заключается в том, что игровые обновления очень редко на него влияют. Используемая выше функция Send вообще врядли когда-либо будет изменена, таким образом этот пакетчик (и спамилка) будут работать вечно.

Ни у результат:



Используемые инструменты в статье:
OllyDbg
TotalInjector

Ну и кому интересна тематика, рекомендую предыдущую читерскую статью по обходу игровых защит - https://www.rf-cheats.ru/forum/showthread.php?t=201477

[@vadim_vankov]

То есть я так понимаю теперь можно заменять вещи ?

[@Тигрь]

Сообщение от vadim_vankov

То есть я так понимаю теперь можно заменять вещи ?

Теперь НУЖНО заменять вещи!

Добавлено через 23 минуты

Сообщение от dark

Иными словами мы можем разобрать сетевой протокол клиент-серверного взаимодействия BS и отталкиваясь от этого генерить нужный пакет для посылки сообщения в чат. Как его слать? Можно через WPF, можно сделать DLL, которая бы хукала какую-либо wsock API для определения сокета и просто в цикле слала бы в сокет ваш пакет. Но это уже второе дело, сейчас главное найти вариант хотя бы вручную постить сообщения в чат без мышки и клавы :)

Я кстати ваще не парился когда спамер на BS у меня заказывали, обычный winsocks Send похукал и все. Ты кстати по чем спамер на БС продаешь? Под хайдом чиркани.

[@dark]

Сообщение от Тигрь

Теперь НУЖНО заменять вещи!

Добавлено через 23 минуты


Я кстати ваще не парился когда спамер на BS у меня заказывали, обычный winsocks Send похукал и все. Ты кстати по чем спамер на БС продаешь? Под хайдом чиркани.

то есть ты эти первые 4 байта разобрал как генерить?
А спаммер делал на заказ за 10к. Больше никому не продавал.

[@rat]

Сообщение от dark

А точнее в статье описан способ реализации читов на основе использования функций игрового клиента. А если ещё точнее, то описан метод создания пакетчика на примере спамера :)

Сообщений этому человеку за его труды!!!!

[@Тигрь]

Сообщение от dark

то есть ты эти первые 4 байта разобрал как генерить?
А спаммер делал на заказ за 10к. Больше никому не продавал.

Да там в этих байтах размер пакета закодирован. У меня они не менялись от сессии к сессии если одинаковый пакет слать. Хз мож щас чо то изменилось. У меня чел покупал спамер за 1к в месяц. А потом он забил на торговлю в BS и я забил на спамер. Там к стати его потом банить стали по железу за спам, я еще обход бана по железу делал.

[@dark]

Сообщение от vadim_vankov

То есть я так понимаю теперь можно заменять вещи ?

Конечно

Сообщение от Тигрь

Да там в этих байтах размер пакета закодирован.

Ха, точняк

[@TuuTeP]

Многа букаф

[@dark]

Сообщение от TuuTeP

Многа букаф

правильно, нехрен нормальным пацанам читать умные тексты.

[@barblga]

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