- Сообщения
- 3,608
- Репутация
- 941
Dellroc я уже почти не кодю на автоите но суть достаточно проста:
1) Если у вас есть клиент игры, по сути у вас есть её исходник
2) Если в былые времена трафик не шифровался или шифровался статичными ключами (вшитыми в клиент), то сейчас в 99% случаев при попытке отреверсить пакеты получаемые от сервера, вы наткнетесь на динамичный шифр. То есть каждую новую сессию (а то и каждый новый пакет :D), получаемые вами данные при одном и том же содержании будут выглядеть в совершенно по другому.
3) Если учесть условие (2), то вы будете получать ключи в момент инициализации сессии (если ключи статичны в пределах сессии), или же вы будете в каждом получаемом пакете иметь так же связку ключей (если ключи динамичны в пределах сессии).
4) Вы НЕ СМОЖЕТЕ отреверсить ключи работая только с памятью, только с пакетами или только с ассемблерными листингами, вам надо работать со всем одновременно.
5) Схема достаточно проста, вам нужен отладчик, например OllyDBG так же стоит укомплектоваться снифферами и взломщиками памяти, из взломщиков памяти лучше чем CheatEngine человечество еще не придумало, он помимо тупого поиска значения в памяти (что по сути является далеко не главным его преимуществом, иначе подошел бы и примитивный Cheat Omatic), так же может выводить вам исходный ассемблерный код программы, и при условии что вы в состоянии понимать что там написано, вы получаете абсолютный контроль над клиентом, так же с его помощью вы можете модифицировать код программы с которой работаете, в пределах сессии конечно же. Про снифферы нет смысла разглагольствовать, их сотни, в различных вариантах, тот же WPE Pro.
6) Нужна точка привязки. Тут всё зависит от конкретной игры и того как тамошние кодеры написали процесс инициализации. Либо клиент получает ключи от сервера в момент запуска (наиболее маловероятный вариант, т.к. при таком раскладе, собственное детище фирмы могло бы спокойно за ддосить создателя), либо вы получаете ключи при успешной авторизации (наиболее вероятно при условии статичных ключей в пределах сессии). Например: В клиент вшит какой-нибудь примитивный алгоритм шифрования, который используется лишь в момент инициализации, дабы отправить авторизационные данные серверу, в хоть сколько нибудь не читаемом на глаз виде, подойдет даже ксоринг. Клиент отправляет логин и пароль пользователя в плохозащищенном формате и в ответ в случае успеха получает ключи и разрешение на работу, если же логин и пароль были неправильными, сервер даже не почешется вернуть клиенту какую-то сколько-нибудь стоящую инфу, он даже не почешется инициализировать сколько-нибудь сложные алгоритмы геренации ключей или еще что, он вернет что-то столь же примитивно зашифрованное как и авторизационный пакет, говорящее о том что "шел бы ты подальше". И прошу заметить что это ключевой момент. Вы получили ответ от сервера, каким бы он небыл - это результат. Вы имеете что-то например похожее на: "5c0xF ff5839CC ... fafa32 N". И это самое важное событие в вашей жизни. Это и есть тот пакет который вы обязаны отреверсить если хотите пройти дальше. Тут видимо пора начать следующий пункт.
7) Кнопка Login. Да, именно она инициализирует связь с сервером в 99% случаев. И пользуясь отладчиком типа OllyDBG, вы сможете по крайней мере пошагово отследить действия, которые проводит клиент с логином и паролем прежде чем отправить их на сервер. Да, для вас это вероятнее всего будет бессмысленная не имеющая особой логики цикличная операция. НО вы должны понимать принципы работы шифрования. в том же RSA происходит побайтовое кодирование сообщения с преобразованием его в набор не несущих смысла цифр, В ЦИКЛЕ. Да тот же ксоринг может так сделать. И если вы наткнетесь на цикличный кусок кода, который принимает например 1 символ, а выплевывает набор цифр или же набор хексов или еще что, вы попали в яблочко грубо говоря. Имея ассмеблерный код этой функции вы сможете восстановить её исходник, который позволит вам хотя бы формировать пакеты авторизации. Далее следующий шаг.
8) Реверс пакета несущего в себе инфу о положительной авторизации от сервера. В 99% случаев функцией что принимает результат будет совершенно иная функция нежели та что его отправляла, ввиду того что полученный на успешную автоизацию пакет будет нести в себе сложную информацию закодированный динамичными ключами. Тут вы опять же имея приложенный к процессу отладчик, сможете отследить процесс получения информации со всеми его ключами, вы сможете увидеть где в полученном сообщении располагаются ключи и как в дальнейшем они применяются к сообщению в целом с целью получения raw_message. Которое и является тем самым сообщением, говорящем клиенту о том что теперь он может работать.
9) В большинстве случаев raw_message и окажется носителем ключей.
CAUTION
В подавляющем большинстве случаев, все ключи имеют срок жизни. Например я, программируя свои сервера принятия решений, выставляю срок жизни не более нескольких секунд. После этого времени, даже если полученная инфа является валидной, сервер отклоняет клиент ввиду того что срок жизни ключей прошел. Уже в попытках отреверсить пакеты, вы можете наткнуться на бан т.к. время затраченное вами на реверс пакета, может привышать срок его жизни. Это беда, да, но деваться некуда, вы должны расчитывать примерно на 15-20 банов аккаунтов с момента когда вы решили начать реверсить пакет и до момента его успешного реверса.
Самое важное для вас, получить доуступ к декодирующей функции. Их может быть несколько в клиенте и вам понадобиться восстановить исходный код каждой из них.
P.S. Под восстановлением исходного кода я имею ввиду не то что думают большинство пользователей автоита "перетащил ехешничек в окошко и получил исходник", а полноценный реверс, когда вы читая ассемблерный листинг восстанавливаете логику его поведения с нуля, фактически пишите функцию заново.
Добавлено:
P.S.S. Да, я думал о написании подобного гайда, но для Diablo II. Хотя еще даже не приступал, времени нету
Добавлено:
P.S.S.S. Чем больше я пытаюсь монетизировать свои знания, тем больше я понимаю что подобные посты деструктивны для меня самого
1) Если у вас есть клиент игры, по сути у вас есть её исходник
2) Если в былые времена трафик не шифровался или шифровался статичными ключами (вшитыми в клиент), то сейчас в 99% случаев при попытке отреверсить пакеты получаемые от сервера, вы наткнетесь на динамичный шифр. То есть каждую новую сессию (а то и каждый новый пакет :D), получаемые вами данные при одном и том же содержании будут выглядеть в совершенно по другому.
3) Если учесть условие (2), то вы будете получать ключи в момент инициализации сессии (если ключи статичны в пределах сессии), или же вы будете в каждом получаемом пакете иметь так же связку ключей (если ключи динамичны в пределах сессии).
4) Вы НЕ СМОЖЕТЕ отреверсить ключи работая только с памятью, только с пакетами или только с ассемблерными листингами, вам надо работать со всем одновременно.
5) Схема достаточно проста, вам нужен отладчик, например OllyDBG так же стоит укомплектоваться снифферами и взломщиками памяти, из взломщиков памяти лучше чем CheatEngine человечество еще не придумало, он помимо тупого поиска значения в памяти (что по сути является далеко не главным его преимуществом, иначе подошел бы и примитивный Cheat Omatic), так же может выводить вам исходный ассемблерный код программы, и при условии что вы в состоянии понимать что там написано, вы получаете абсолютный контроль над клиентом, так же с его помощью вы можете модифицировать код программы с которой работаете, в пределах сессии конечно же. Про снифферы нет смысла разглагольствовать, их сотни, в различных вариантах, тот же WPE Pro.
6) Нужна точка привязки. Тут всё зависит от конкретной игры и того как тамошние кодеры написали процесс инициализации. Либо клиент получает ключи от сервера в момент запуска (наиболее маловероятный вариант, т.к. при таком раскладе, собственное детище фирмы могло бы спокойно за ддосить создателя), либо вы получаете ключи при успешной авторизации (наиболее вероятно при условии статичных ключей в пределах сессии). Например: В клиент вшит какой-нибудь примитивный алгоритм шифрования, который используется лишь в момент инициализации, дабы отправить авторизационные данные серверу, в хоть сколько нибудь не читаемом на глаз виде, подойдет даже ксоринг. Клиент отправляет логин и пароль пользователя в плохозащищенном формате и в ответ в случае успеха получает ключи и разрешение на работу, если же логин и пароль были неправильными, сервер даже не почешется вернуть клиенту какую-то сколько-нибудь стоящую инфу, он даже не почешется инициализировать сколько-нибудь сложные алгоритмы геренации ключей или еще что, он вернет что-то столь же примитивно зашифрованное как и авторизационный пакет, говорящее о том что "шел бы ты подальше". И прошу заметить что это ключевой момент. Вы получили ответ от сервера, каким бы он небыл - это результат. Вы имеете что-то например похожее на: "5c0xF ff5839CC ... fafa32 N". И это самое важное событие в вашей жизни. Это и есть тот пакет который вы обязаны отреверсить если хотите пройти дальше. Тут видимо пора начать следующий пункт.
7) Кнопка Login. Да, именно она инициализирует связь с сервером в 99% случаев. И пользуясь отладчиком типа OllyDBG, вы сможете по крайней мере пошагово отследить действия, которые проводит клиент с логином и паролем прежде чем отправить их на сервер. Да, для вас это вероятнее всего будет бессмысленная не имеющая особой логики цикличная операция. НО вы должны понимать принципы работы шифрования. в том же RSA происходит побайтовое кодирование сообщения с преобразованием его в набор не несущих смысла цифр, В ЦИКЛЕ. Да тот же ксоринг может так сделать. И если вы наткнетесь на цикличный кусок кода, который принимает например 1 символ, а выплевывает набор цифр или же набор хексов или еще что, вы попали в яблочко грубо говоря. Имея ассмеблерный код этой функции вы сможете восстановить её исходник, который позволит вам хотя бы формировать пакеты авторизации. Далее следующий шаг.
8) Реверс пакета несущего в себе инфу о положительной авторизации от сервера. В 99% случаев функцией что принимает результат будет совершенно иная функция нежели та что его отправляла, ввиду того что полученный на успешную автоизацию пакет будет нести в себе сложную информацию закодированный динамичными ключами. Тут вы опять же имея приложенный к процессу отладчик, сможете отследить процесс получения информации со всеми его ключами, вы сможете увидеть где в полученном сообщении располагаются ключи и как в дальнейшем они применяются к сообщению в целом с целью получения raw_message. Которое и является тем самым сообщением, говорящем клиенту о том что теперь он может работать.
9) В большинстве случаев raw_message и окажется носителем ключей.
CAUTION
В подавляющем большинстве случаев, все ключи имеют срок жизни. Например я, программируя свои сервера принятия решений, выставляю срок жизни не более нескольких секунд. После этого времени, даже если полученная инфа является валидной, сервер отклоняет клиент ввиду того что срок жизни ключей прошел. Уже в попытках отреверсить пакеты, вы можете наткнуться на бан т.к. время затраченное вами на реверс пакета, может привышать срок его жизни. Это беда, да, но деваться некуда, вы должны расчитывать примерно на 15-20 банов аккаунтов с момента когда вы решили начать реверсить пакет и до момента его успешного реверса.
Самое важное для вас, получить доуступ к декодирующей функции. Их может быть несколько в клиенте и вам понадобиться восстановить исходный код каждой из них.
P.S. Под восстановлением исходного кода я имею ввиду не то что думают большинство пользователей автоита "перетащил ехешничек в окошко и получил исходник", а полноценный реверс, когда вы читая ассемблерный листинг восстанавливаете логику его поведения с нуля, фактически пишите функцию заново.
Добавлено:
Сообщение автоматически объединено:
P.S.S. Да, я думал о написании подобного гайда, но для Diablo II. Хотя еще даже не приступал, времени нету
Добавлено:
Сообщение автоматически объединено:
P.S.S.S. Чем больше я пытаюсь монетизировать свои знания, тем больше я понимаю что подобные посты деструктивны для меня самого
