MasterGH

1. Найти/проверить инструкцию типа А. Предпологаемая инструкция (по вашим данным): game.exe+231B0D - fld dword ptr [eax+08] Поставить определение адресов на этой инструкции. Если на ней проскакивают адреса врагов значит это тип не А. Поставить бряк на адресе здоровья врага, получить инструкции (в частности при стрельбе во врага...) Сравнить инструкции при бряке на адресе здоровья своего героя с инструкциями при бряке на адресе врага и найти инстуркцию типа А. Если не нашли типа А, то идём вверх по указателю на один уровень и точно также ищем тип А ставив бряк на указатели своего героя и врага. Если не нашли, то опять идём вверх уже на конечный третий уровень пока не найдём тип А. На последнем уровне точно должна быть типа А. 2. После нахождения инструкции типа А, нужно её изменить инъекцией чтобы сохранить указатель на некоторый уровень. [[[{3ий уровень}адрес+смещение]{2ой уровень}+смещение]{1ый уровень}+смещение] // {комментарии} Допустим "вынесли" (т.е. сохранили для фильтра) указатель с третьего уровня. 3. В инструкции работающей непосредственно со здоровьем, т.е с 1-ым уровнем нужно сделать инъекцию кода, так чтобы 3-тий уровень был в качестве фильтра. Фильтр например напишем так "Если [[{3ий уровень}адрес+смещение]{2ой уровень}+смещение] = 1ый уровень, то записать здоровье своему игроку." Это самый простой способ, но с новыми патчами может оказаться не рабочим. Примечение. Для увелечения работоспособности: - поиск адреса внедрения через проверочные байты; - (CE на сегодняшний момент этого делать не умеет через так называемое автодизассемблирование) идентификация смещений в уровнях цепи указателей перед автоассемблированием, идентификация перед автоассемблированием регистров левой и правой частей инструкции по адресу внедрения, т.е. операндов источника и адресата. И конечный реультат - автоассемблирование с сгенериованным скриптом по указанным правилам: писать здоровье своему игроку и OneHitKill.

Сделать полную сохранялку конкретной или любой игры дело не простое. Как минимум требует многочасовой работы и экспериментов. Но есть несколько возможных альтернативных вариантов. 1. Использовать эмулятор Windows. 2. Поискать программу в интернете. 3. Поговорить с разработчиками Артмани, которые за это дело требуют деньги. 4. Написать Дарк Байту (автору CheatEngine). Написать ЭльСпиро (разработчику MHS). Ещё есть разработчики WGC,DS - но они врядли этим будут заниматься. 5. Попробовать каким-то изворотливым способом через Artmoney, экспериментируюя отключая звук, замораживая или удаляя какие-то потоки процесса через системыне утилиты.

Возможные причины не работающего бессметрия: 1. Не найден адрес здоровья или найдены не все (что скорее всего). Проверить это можно, ставив бряк на запись на адреса здоровья своего героя и на адреса здоровья других игроков. 2. Адрес (или адреса) здоровья может находиться в структуре1. С неё снимается копия в структуру2 и код который работает с этой структурой может повлиять на смерть героя. Больше вариантов у меня нет, если не тратить время чтобы придумывать их. Как написал Xipho необходимо смотреть в отладке. Хорошо бы найти несколько структур и постарать найти адреса-зацепки которые изменяются во время смерти некотрого игрока, но не своего... Если setdammage работает в редакторе, то надо проследить в какую функцию идёт эта комманда. Попытаться найти её в самой игре. Я думаю, проще искать причину гибели от пуль. Это делать надо в Olly и брякнуться в момент оповещения о сметри героя. Именно брякнуться. Запомнить это место - Бряк1. Посмотреть стек вызовов и на каждом вызове поставить бряки. Перезапустить игру и играть если прерываемся и очевидной смерти нет, то снимаем бряки кроме 1. Если остался бряк1, то надо чё-то думать. И наконец когда смерть вновь произошла и сработал один из бряков, то плясать уже на этом уровне кода и смотреть что там происходит.... В общем не знаю как объяснить и предположить иное.

Хорошая статья по игре Bloodrayne 2 Demo. Но можно сделать ещё лучше - свою статью на основе этой с некоторыми скринами ключевых моментов на CheatEngine на той же самой игре Bloodrayne 2 Demo. Конечно это тебе решать

Я знаю об этом... вроде всё нормально.

По идее машина состоит из объектов, капота, дверей, бампера.... которые имеют видимо свой урон. Если урон больше определённой величины, то происходит анимация (бьётся стекло, отваливание). При каждой анимации урон может сбрасываться в ноль... в общем надо копаться и скать. Лучше сканером памяти в определённых диапазонах адресов.

Может быть. Если не лень, можешь отправить "репорт" Дарк Байту.

1. В скрипте CE ты не учёл fld dword ptr [ecx+00000354]. Эта инструкция смещает стек сопроцессора и требует выгрузки, чтобы не было краха игры 2. Если без фильтра не вылетает, а с ним вылетает, то можно попробовать сохранять регистр флагов pushf ... .... popf Идентично тому же pushad или popad. 3. Также могу ещё обратить внимание на то чтобы не применять фильтры повсеместно. В данном случае можно было что-то вроде этого (здесь цитата, чтобы можно было выделить жирным шрифт моментов на которые стоит обратить внимание) Как видно здесь мы не пишем фильтр и этим самым вероятно увеличиваем шанс чтобы герой был жив даже при сверхсильном уроне. Хотя предполагаю что производительность чуть будет страдать. Чтобы более точно определить нужно посчитать лишние такты.

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

Если прокомментировать, то я могу сказать, что нужно исследовать код больше ничего по этому поводу сказать не могу да и вряд ли кто сможет без самой игры. Если куски кода повторяются, то нужно попытаться найти код вверх по иерархии вложеных вызовов или (даже возможно вниз) где проверочные байты индивидуальны и как-то от них отталкиваться по смещениям или "делать изворотливый" скрипт. Были у меня подобные случаи, я просто находил связанные адреса например со здоровьем и находил куски кода, которые были уникальны. Возможно, будущем я придумаю ещё что-нибудь по решению этой проблемы хотя бы в теории...

Вот один из возможных примеров на скрипте CE с сравнением указателя [[core.dll+00155744h]+350h]+43Ch (если немного подумать, то можно написать и с записью значения по этому указателю): /*MasterGH(c) 04.01.08. UnrealTournament2003+ (InfHealth)*/ [ENABLE] label(returnhere) label(originalcode) label(y1) registersymbol(y1) core.dll+0290://codecave push ebx mov ebx,[core.dll+00155744] mov ebx,[ebx+350] add ebx,43C //ebx=[[core.dll+00155744h]+350h]+43Ch cmp eax,ebx pop ebx y1: db eb 03//jmp short originalcode (EB03 fix EB0390909090) mov byte ptr [eax],#250 originalcode: mov ecx,[eax] mov edx,[esp+04] jmp returnhere core.dll+4285c: jmp core.dll+0290 nop returnhere: [DISABLE] //Not to edit

Это не код, а адрес начала любой программы под Windows. 0x00400000 - обычно программы "начинаются" с этого адреса и не меньше (иногда с 0x00410000 или др.) А заканчиваются где-то 0x7FFFFFFF (может ошибся, не помню). Когда ты ищешь указатель в памяти инструкции mov eax,[ebx+0x2026020] , то нужно брать адрес регистра лежащий в промежутке от 0x00400000-0x7FFFFFFF в 32-разрядных играх. У тебя ebx < 0x00400000 и 90-95% указателя на него нет. Зато есть 0x2026020, но указатель на него нет смысла искать, т.к. 0x2026020 здесь жёстко задано. Что в игре именно за проблемы, остаётся только гадать. Короче всё это решается под отладкой. Если через несколько месяцев решишь заняться серьёзным гейм-хакингом, то совету читать Рихтера (Windows для профессионалов). Там ты узнаешь и об архитектуре памяти приложений (т.е игр) и о многом-многом другом.

Ты наверно про регистр ebx из инструкции: mov eax,[ebx+0x2026020] Если ebx = 1Е334, то очень маловероятно, что следует искать указатель на это значение, т.к. оно меньше 0x00400000. Можешь попробовать привести нам всем не меньше 20-ти инструкций вверх и вниз от mov eax,[ebx+0x2026020] и укажи все регистры на этом участке (это просто сделать в Cheat Engine RUS, поставив также бряк на адресе здоровья...).

Я выделил ключевые места жирным. Отсюда следует что фильтр на [0x0510C11B] это фильтр на всех игроков. Если его не ставить, то здоровье будет без эффекта. Значит нужно найти ещё фильтр на твоего игрока. Т.е. нужно ставить либо два фильтра, либо искать другой фильтр на твоего игрока. Если это показалось запутанным, то есть ещё один верный выход - найти всю цепочку указателей до здоровья твоего игрока. Затем ставить на каждый указатель в цепочки брейкпоинт на доступ и искать инструкцию типа А и в неё внедрять чит-код. Работать лучше с CheatEngine. Я могу предположить то что я написал сложно понять, поэтому советую потренироваться скачав игру "Grand Theft Auto Vice City" сделать чит по статье, которая есть на нашем форуме при помощи TSearch, а также самостоятельно с CheatEngine.

В свою очередь напомню (чтобы другим не лазить и не искать):

Я конечно спорить не буду, я читал об кольцах защиты, но как-то люди были не профи (где-то они услышали, где-то прочитали, кто-то им сказал) Почему-то мне кажется что можно осуществить доступ через дырки в драйверах: переполнение стека и выполнения данных как кода... правда проще другой метод. Свой драйвер написать, который проверяет отладку процесса трейнера и если отладка есть, то схлопываем систему. Загрузка драйвера в систему без её перезагрузки возможна, это я точно знаю: MHS и cheat engine могут это делать

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

Если я не "вру", отладчики ипользуют некоторые прерывания совместно с регистрами отладки. Когда происходит отладка, то можно узнать по этим прерываниям и по изменениям регистров. Выполнять это нужно как-то в нулевом кольце с вылетом в бсод. Возможно, это отобьёт желание копаться даже Софт-Айсом. Но увы исходников у меня нет. Примеров, которые бы я изучал тоже нет, но есть очень много статей в инете. Какие бы ты защиты не ставил, если трейнер запускается однажды и выполняет необходимый функционал, то ни одна "защита" направленная против рипа, выдергивания ресурсов, кода и т.п. не поможет против очень опытного человека.

С Macromedia Flash Professional 8 хороший вариант, я про него не подумал. ПО Flash - Variable engine 2.0 все было бы хорошо, но изменённые этой программой значения иногда превращается в текст. Было "10" очков. Изменили "10" "Flash - Variable engine 2.0 " на "200". В игре в процессе игры добавляется 5 и видим не 205, а "205+5"

...А искать сканерами памяти, точнее теми которые сейчас существуют бесполезно потому, что с каждым изменением данные (вероятно любой тип данных находящийся в текстовом формате с описанием типа): а) вероятно меняют своё местоположение в памяти б) упаковываются и распаковываются при каждом изменении Изменить данные извне можно специальной функцией зная имя параметра. Только я уже подзабыл что это за функция. Берём любую среду разработки (Delphi,VC++, даже думаю C#...) импортируем ActiveX компонент флеш-плеера, в него загрузим флешку и его функцией изменим некоторый параметр по названию. Когда-то давно я это делал ради эксперимента.

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

Попробуй дизассемблером IDA (она в частности для 64-разрядных приложений) или ищи отладчики под 64-разрядные приложения. Так же возможно сапёр написан на .NET (хотя мало вероятно) и тогда и отладчик ищи под .NET. О том на какой платформе написано приложение можешь проверить утилитами (не помню какими). ProcessXP подсветит процесс желтым если это .NET. А Paid вроде покажет 64/32 разрядное приложение или какой-нибудь протектор/пакер... Думаю, можно и без отладчика обойтись, если "смотреть в дампе памяти флажки" (если это не .NET, с ней может быть и иначе)

На форуме есть раздел для статей и можно сразу добавить в него. Но по желанию пользователей и администрации, статью можно опубликовать на сайте, если автор статьи дал на это право. Так что пиши ссылку на статью в личное сообщение мне и Xipho - кто-то из нас быстрее выложит. У меня сейчас есть минут 30 свободного времени.

Иначе говоря "сделать невидимость". Невидимость я уже делал в играх следующим вариантом и по методологии. Каждый объект-противник-игрок имеет своё поле чувствительности (визуальное/"слуховое"/чувствительность на какие-то действия главного героя). Если в это поле по координатам попадает объект нашего игрока, то анализируются его(нашего игрока) действия с критичными. Если эти действия критичны, то выставляется уровень "тревоги" в объекте-противника. Если противник главного героя встречается с другим противником главного героя, то у обоих уравнивается порог тревоги... Все пороги тревоги приводятся к максимальному... и отправляются в некоторый адрес памяти, как визуализация тревоги. А из этого предполагаемого процесса следует. Что 1) нужно найти адрес индикатора тревоги 2) поставить на него бряк на запись 3) найти инструкцию через которую все объекты-противники пишут в адрес тревоги значение тревоги 4) выйти вверх по коду до прыжка и изменить его так чтобы объект-врага "не нервничал". Именно так. Если же мы заморозим адрес индикатора тревоги, то толку от этого не будет, всё равно объекты-противники будут нервничать. Конечно, я не знаю как точно обстоят дела, но в некоторых играх именно так: например в Manhunt 2

Akama, попробуй сам проверить, я к сожалению не помню: вроде прыжок может быть на расстоянии (0xFFFF-1) / 2 вверх и вниз. Или (0xFF-1)/2. Или без "-1"