Как стать автором
Обновить

Комментарии 29

НЛО прилетело и опубликовало эту надпись здесь
Складывается ощущение, что у людей при слове ассемблер начинается паническая атака, закладывает уши и отключается мозг

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

MH_CreateHook(ShellExecuteExWptr,
			reinterpret_cast<void*> (&DetourShellExecuteExW),
			reinterpret_cast<void**> (&fpShellExecuteExW));
MH_EnableHook(ShellExecuteExWptr);

// ......

BOOL WINAPI DetourShellExecuteExW(LPSHELLEXECUTEINFOW pExecInfo) {

    // some code
	
    return fpShellExecuteExW(pExecInfo); // call original proc
}

Тут подразумевается что этот код лежит в целевом процессе.

Плюс к этому библиотеки обычно берут на себя процесс корректной установки хуков, как то — предварительная приостановка потоков/правка EIP/RIP в случае если поток стоит на месте патчимой функции, итп.

Это позволяет работать на высоком уровне абстракции, а не думать о возможности порушить стек или других низкоуровневых вещах.
Согласен. Только как это потом обфусцировать внутри целевого процесса. Ведь вопрос не только в самом хуке, а еще и что бы не совсем понятно было, куда он ведет. С асмом все просто, nop'ов наставил, мусором забил и поди пойми, что это. Не будет же игра дебажить себя и по маске не определить тоже.
Тут прямого ответа нет, но например исходный код библиотеки что я приводил выше открыт, а следовательно — можно изменить установку перехода в начало на код позапутаннее(это несложно так как библиотека имеет дизассемблер длин). Например набить тем-же мусором, а переход сделать в середине заменив его на push/ret/call/etc.

Ассемблер как инструмент это вопрос личных предпочтений, я просто попытался осветить предполагаемый ход мыслей на тему «почему ассемблер». Ту-же dll можно и обфусцировать и развернуть в целевом процессе вручную в обход стандартного механизма ОС чтобы нельзя было этот модуль найти обычным способом. Это сложнее с технической стороны зато после даёт возможность не заморачиватся при разработке основной функциональности бота.
А генерацией опкодов пусть занимается компилятор, а не программист имхо.
Вы не поняли. Код ассемблера меняется при каждой новой инъекции, мусор в нем генерируется программой-инъектором, что-то вроде полиморфа, а код библиотеки — статичен и что бы его изменить придется ее править ручками и компилировать заново. Здесь идет упор не на удобство, а на недетектируемость кода, поверьте это важнее удобства.
В общем, да. Если нужна именно такая обфускация то тут проще сделать так как у вас. Я исходил из позиции что нужен обход существующих эвристиков(сокрытие перехода/наличия длл должно быть достаточно имхо), а вот если программа желает жить даже после попадания в античит лаборатории то тут всё намного сложнее, античит может просто начать реагировать на запущенную программу-хост вне зависимости внедряет она свой код в игру или нет.
Складывается ощущение, что у людей при слове ассемблер начинается паническая атака, закладывает уши и отключается мозг. Не нужно его боятся на столько, он не так страшен. Ведь что может быть проще, чем попросить саму программу выполнить свою же функцию и результат поместить по указателю который вы знаете? Не нужно изобретать велосипед, я использую, то что есть
Предположим мы пишем чит (или бот как вам удобнее). Мы умеем перехватывать управление, но помимо этого у нас присутствует бизнес-логика самого чита и чем больше его функциональность, тем больше бизнес логики. Вот я хочу к примеру добавить в свой чит возможность его включения и отключения на кнопку F8, сколько строк кода это займёт на ассемблере и насколько легко будет такой код писать и сопровождать?

Потом какова цель мутации кода? Я знаю что античит может сканировать память загруженого модуля, но врятли он будет сканировать простые секции. Если бы передо мной стояла задача детекта вашего чита, я бы детектил патч в памяти но никак не код чита. Я уже писал что поиск по памяти это неэффективный костыль, сигнатура скорее всего вещается на статический оффсет, такое обходится и без ассемблера
Вот я хочу к примеру добавить в свой чит возможность его включения и отключения на кнопку F8, сколько строк кода это займёт на ассемблере и насколько легко будет такой код писать и сопровождать?

Если Вы не заметили, то только инъекции написаны на ассемблере, а все остальное на C#. И кстати о бизнес логике хочу сказать, что на C# проще контролировать потоки чем в С++.
Если бы передо мной стояла задача детекта вашего чита, я бы детектил патч в памяти но никак не код чита.

Детектили патч в памяти 3-rd party библиотеки? Каким образом? Написали бы к игре еще и дизасемблер с отладчиком? Повторюсь. Я предпочитаю конструктивную критику. Расскажите пожалуйста.
P.S. Складывается впечатление, что вы и половины принципа работы бота не поняли либо не читали вообще статьи…
Если Вы не заметили, то только инъекции написаны на ассемблере, а все остальное на C#. И кстати о бизнес логике хочу сказать, что на C# проще контролировать потоки чем в С++.
Не понял о чем вы, но это ваше субьективное мнение не стану спорить.

Детектили патч в памяти 3-rd party библиотеки? Каким образом? Написали бы к игре еще и дизасемблер с отладчиком? Повторюсь. Я предпочитаю конструктивную критику. Расскажите пожалуйста.
Да ради бога :) С точки зрения защиты игры есть ряд библиотек поведение которых может повлиять на игровую логику, это системные библиотеки Kernel32, KernelBase, User32, Ntdll и т.п., графические библиотеки относящиеся к OpenGL, DirectX и возможно какие-то собственные библиотеки, распостраняющиеся с игрой. Имена этих библиотек нам за ранее извесны, будем их называть критическими (поведение остального кода в процессе нас не интересует). Так вот как детектится изменение в критических библиотеках. Анализируется импорт модулей игры и собирается список импортируемых функций из критических библиотек, снимается контрольная сумма с первых байт импортируемых функций, снимается контрольная сумма с таблицы экспорта критических библиотек. После чего защита должна переодически проверять эти контрольные суммы. Но это очень упращенный вариант реализации, тут есть подводные камни.
Вы забыли про версионность, одних DirectX у вас будет за сотню. И представим, что вы нашли jmp инструкцию, что дальше?
А какое отношение версия библиотеки имеет к нашей контрольной сумме? Мы же знаем имя или ординал импортируемой функции, поэтому берём и парсим структуры экспорта в критической библиотеке, находим там rva нужной функции и плюсуем его к базе модуля. Обычно меняется внутренняя реализация библиотеки, интерфейс же статичен. Контрольная сумма снимается согласно данным из текущего загруженного модуля в простом случае, либо из его файла на диске (с учётом релоков и т.п. конечно) в продвинутом случае.

Если мы защита и например мы натыкаемся на нарушенную контрольную сумму (к примеру jmp на функцие EndScene), то мы можем сказать что это детект чита, либо мы можем промолчать и восстановить оригинальное содержимое функции, тем самым выпнув стороннюю логику.

UPD: Все контрольные суммы снимаются из процесса игры, они не предопределены
Мы наверное ведем беседу о разных вещах… Есть D3D Device один единый на всю систему, у него есть VMT указателей на функции, так вот мы берем и патчим функцию EndScene по найденому на нее указателю, а какой она должна быть — не знаем не мы ни процесс, который ее использует, т.к. она была и остается 32-ой по счету, а проверять ее содержимое — не благородное дело. Я не подменяю ее адрес в VMT я изменяю ее содержание.
Почему вы решили что защита знать не должна каким может быть метод EndScene? И если вы получили указатель на него почему защита не может сделать также? Я уже объяснил выше как определить наличие патча кода, будь то виртуальный метод или экспорт, разница лишь в способе получения адреса.

Другой вопрос это определение модификаций в виртуальной таблице методов, там нельзя однозначно определить является перегрузка законной или нет.
Вы издеваетесь? 100+ версий DirectX под разные платформы, будете составлять базу, сверять по ней и перепатчивать ее? Еще не забыть всякие оверлеи для игр, которые тоже лезут в эти таблицы, а еще антивирусы и прочие программы… Ваша игра будет не тем заниматься. В общем я повторюсь:
На все остальные вопросы ответ будет следующим: «За последние 4 года на battle.net сервере, я ни разу не получил бан или предупреждение»
100+ версий DirectX под разные платформы, будете составлять базу, сверять по ней и перепатчивать ее?
Зачем составлять базу, вы думаете контрольные суммы собираются заранее?) Контрольная сумма снимается во время старта процесса из памяти либо из исполняемого файла на диске который был загружен игрой. Тут нет разницы какая версия библиотеки используется, зная её виртуальный интерфейс бинарная реализация нас не интересует.

На все остальные вопросы ответ будет следующим: «За последние 4 года на battle.net сервере, я ни разу не получил бан или предупреждение».
Первоначально вы спросили как бы я это обнаружил, я вам ответил, речь не идёт про какие-то реализации защит.

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

Ваш алгоритм контрольной суммы можно изменить или у Вас еще алгоритм на алгоритм будет?;) Загружаемый файл или память могут быть уже модифицированы. Не много ли проблем?
Ну вы уже задели филосовский вопрос. Я нигде не обещал что защита будет полной, всё это в некоторый степени эвристика. К таму же пока операционные системы не предоставляют средств защиты кода приложений, хороших подходов к юзермодным защитам быть не может.
Не надо патчить ф-цию.
Надо скопировать VMT класса D3DDevice и в копии заменить указатель EndScene на наш.
А единственному объекту pD3DDevice, выделенному в read/write памяти, по смещению 0 поменять указатель на нашу копию VMT.

В таком случае полностью исключается изменение структур, которые можно сравнить с эталонными в DLL на диске, и нет необходимости менять защиту памяти.
Вы оба правы, но:

1. в данном примере рассматриваются конкретные решения для конкретной задачи под конкретную игру. Собственно зная как она устроена, можно говорить о необходимой достаточности решения. Т.к. автор топика не получил бана за 4 года — это говорит лишь о том, что защита не делает все те проверки, о которых говорит JKornev.

2. JKornev прав в том, что близзы все таки делают такие проверки, а 3axap4eHko просто повезло, что он не попался :) И вот почему:

3. близзы формируют некий хеш из содержимого wow.exe и еще ряда dll-ок игры, которые они с собой таскают. они отправляют этот хеш во второй фазе авторизации, уже на реалм (тот самый никому неизвестный unk_crc в CMSG_AUTH_SESSION). дальнейшие действия понятны. 3axap4eHko повезло только потому, что делают они это только один раз в процессе авторизации, а он инжектился после. Собственно поэтому до сих пор работают снифферы первого поколения (inject типа). Warden их тоже не палит, что так же сказалось на «везении» :)

4. но совершенно точно и достоверно известно, что варден палит проксификаторы (не путать с прокси). они могут быть реализованы и через подмену dll как в той статье, и через хук winsock, и через инжект тоже. тут я и сам теряюсь в догадках, как уж так…
близзы формируют некий хеш из содержимого wow.exe и еще ряда dll-ок игры, которые они с собой таскают. они отправляют этот хеш во второй фазе авторизации, уже на реалм (тот самый никому неизвестный unk_crc в CMSG_AUTH_SESSION). дальнейшие действия понятны. 3axap4eHko повезло только потому, что делают они это только один раз в процессе авторизации, а он инжектился после.

Вы абсолютно не правы в своих рассуждениях. Я уже устал объяснять и повторятся, что я не делаю инжекта dll вообще, видимо Вы не достаточно хорошо ознакомились с предоставленным материалом. Я просто нашел слепую зону в защите памяти процесса и использую ее. Даже если unk_crc формировать каждую минуту, мой код не влияет на это значение.
послушайте, прошу вас, не нужно МНЕ говорить о правильности моих рассуждений. без ложной скромности хотел бы упомянуть, что уже 10 лет я занимаюсь вовемулестроением и поверьте, опыта предостаточно что бы рассуждать правильно. можете указать, что в моих рассуждениях АБСОЛЮТНО неправильно? материал ваш мне хорошо знаком и не по наслышке, т.к. сам всем этим (не вашим материалом, а методами) успешно пользуюсь все эти годы. можете даже наверное загуглить о моих, так сказать «ачивах».

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

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

в четвертых, прошу не воспринимайте все так близко к сердцу, вы прям сразу в позу встали, как будьто я тут пытаюсь вас унизить и/или умалить ваши познания. я лишь дал инфу для справки, просто имейте ввиду что такое есть и будьте внимательны, проверьте. в данном случае лучше перебдеть, чем недобдеть.
Я не нашел Ваше «во-первых»)) Вы либо ознакомьтесь с материалом, либо примите как должное, что сам процесс я не изменяю, это происходит внутри памяти directx хэш сумма которого весьма сомнительное значение, что я уже объяснял тов-щу JKornev, отсюда очевидна слепая зона. Вы неправильно реагируете на критику и проецируете это на меня, я ведь ничего такого не написал, а вы мне прям петицию составили.
P.S. Скоро будет готова финальная статья с исходниками, так что милости просим указать в каких местах и чего не так
Вы меня слышите вообще? Или не слышите, что печально, или не хотите слышать, что как бы намекает.
Вам надергать ваших же слов из вашего «материала», где вы сами говорите о внедрении в процесс?

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

Хотите вы этого или нет, вы МОДИФИЦИРУЕТЕ основной процесс, хотя бы просто когда выделяете память. Я уж не говорю о внедрении своего кода.
Эти модификации варден МОЖЕТ палить. Вам, вон на самую первую статью дали рекомендацию, почтеннейший человек в вовэмулестроении (Леха привет!), а судя по «плюсикам» и «ответам» на эту рекомендацию, вы не слушаете.

Еще раз повторяю, вам везет, что процедуры проверки целостности производятся один раз, до входа в реалм.
Далее, я тут не поленился и проверил: вам снова повезло, та проверка, о которой я говорил, проверяет определенные куски памяти экзешника и ряда длл. Не весь процесс.

Да и потом, хук на EndScenе, который является гвоздем вашего «материала» и который вы тут всем выдаете за какое то ноухау (на ownedcore об этом пишут уже несколько лет), с которым вы развели гимор по внедрению на целую главу, вы могли бы заменить на простой таймер. Код все равно внедряете, там и повесьте его.
И еще, в актуальной версии клиента сейчас опасно из EndScene вызывать… а хотя нет, подождем фильную статью, там и закритикуем. Я уверен будет что :)

Вы либо ознакомьтесь с материалом, либо примите как должное
Вы поймите, ваши читатели не все «окей-мэны», как вам хотелось бы. Есть те, кто владеет предметом лучше вас и поправляет вас, дает вам рекомендации, предлагает помощь и предостерегает от возможных ошибок. На вашем месте стоило бы прислушаться.

сам процесс я не изменяю, это происходит внутри памяти directx
А что, память directx уже не память процесса? Что такое вообще directx? Ну, очевидно, это какие то dll. Ну откройте вы любой отладчик, любой процесс вьювер, да посмотрите что там в памяти процесса. Можете даже ознакомится с материалом, тут или тут, во избежание предвзятого отношения ко мне.
Это во-первых :)
А во-вторых, вы ИЗМЕНЯЕТЕ процесс, выделяя память и внедряя свой код. Что, тоже оспорите?

Вы неправильно реагируете на критику
Критику???! Вся ваша критика состоит из безапеляционного и ничем не подтвержденного (до сих пор, кстати) утверждения «вы абсолютно не правы» и минусом в карму. А так же плюсом в свою на это заявление. Уж не знаю кто это делает, вы сами или ваши поклонники, мне в общем то все равно. Я на этом ресурсе ничего не пишу и ценности мне оно никакой не представляет, просто пройти мимо святого и родного не смог. Ваши минусы мне выглядят преждевременными (стоило копнуть чуть глубже и стало ясно, вы не разобрались в предмете), а плюсы себе смешными. Что удивительно, почти каждый ваш пост заплюсован, не важно, по делу или нет. Посмотрел в других ваших тредах, ситуация та же. Явно «группа поддержки», что очень удобно для накрутки репутации, не так ли? Уверен, что будущие минусы этого сообщения ваших поклонников только подтвердят вышесказанное :) Но как я уже сказал, мне все равно.

и проецируете это на меня, я ведь ничего такого не написал, а вы мне прям петицию составили.
Побойтесь Бога, не перевирайте. Вы сейчас выглядите как некоторые нынешние политические деятели, называющие черное белым. На критику «неправильно» реагируете именно вы, т.к. именно вы представляете тут свой «материал», а мы его тут критикуем, говорим что где не так. И вы, выражаясь другими словами, предлагаете заткнуться и слушать что «умный дядя» говорит. Не хорошо. Не красиво. Не культурно. Не профессионально.

Я не нашел Ваше «во-первых»))
Первый признак того, что у оппонента кончились доводы. Придирание к мелочам детектед. А петицию на вас я еще напишу, не сомневайтесь :)
не знаю, не сохранилось форматирование текста, хотя теги все расставлены, писал в блокноте, исходник сохранился.
рекомендация:
habrahabr.ru/post/251137/#comment_8295393
карта памяти:
habrahabr.ru/company/smart_soft/blog/185226
habrahabr.ru/post/202242
всем ботоводам и особенно автору статьи — информация для размышления:
www.thebuddyforum.com/honorbuddy-forum/ban-section-ban-reports/discussions-no-ban-reports-here-/215021-honorbuddy-bans-statement.html

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

я просто не занимаюсь ботами, больше по серверной части специализируюсь.
«Не читал но осуждаю» — это так называется. Треть своих знаний о ботах в WoW я получил исследуя honorbuddy, да только вот мой бот благополучно продолжает рейдить LFR, арены и ловить рыбку. Я вроде уже говорил, что не выкладываю свою защиту на всеобщее обозоение, а лишь покажу некоторые принципы, но вы почему-то упорно продолжаете наседать. Поверьте, у меня все отлично — ниодного бана. И снова цитируя себя:
Вся информация здесь изложена только в познавательных целях. Особенно для компаний разрабатывающих MMORPG, что бы помочь им бороться с ботоводами.


Я только рад, если игра в WoW на офе станет не возможной с помощью ботов. А вот разработчикам приватных серверов есть над чем чесать затылок, т.к. на этих серверах работают даже самые простые читы, хотя слышал, что вам как-то удалось приручить варден.
варден приручен, да. но толку от него не сильно много, он представлял скорее академический интерес. поэтому пришлось в своем сервере делать защиту иного рода — проверять валидность присылаемых данных. это трудоемко, но хоть как то решает проблему.

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

Публикации

Истории