MasterGH

Это можно поправить изменив исходники Cheat Engine. При чем это не просто пару строчек кода написать. А без знаний языка программирования почти не реально. Так, что крупный облом вышел с "привязкой" для автономных трейнеров на CE

Берёшь отладчик, берёшь справку, берёшь компилятор + DirectX SDK. И "получаешь более глубокие знания"

Я не могу дать точный ответ, потому что меня запутало представлять какие бряки и когда ставить. Я просто прокомментирую. Давайте вообще поймём, что в статье делается.Статья очень большая, а написать-то Автору первоисточника надо было чуть проще и статью читать с конца к началу. Наша задача найти указатель на устройство редеринга g_pd3dDevice.Т.е. g_pd3dDevice это адрес по которому располагается адрес устройства. LPDIRECT3D9 g_pD3D = NULL; // Используется для создания D3D устройства LPDIRECT3DDEVICE9 g_pd3dDevice = NULL; // Наше устройство рендеринга HRESULT InitD3D( HWND hWnd ) { // Создаём D3D объект, который необходим для созданияD3D устройства. if( NULL == ( g_pD3D =Direct3DCreate9( D3D_SDK_VERSION ) ) ) return E_FAIL; D3DPRESENT_PARAMETERS d3dpp; ZeroMemory( &d3dpp, sizeof(d3dpp) ); d3dpp.Windowed = TRUE; d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD; d3dpp.BackBufferFormat = D3DFMT_UNKNOWN; if( FAILED( g_pD3D->CreateDevice(D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd, D3DCREATE_SOFTWARE_VERTEXPROCESSING, &d3dpp, &g_pd3dDevice ) ) ) { return E_FAIL; } // Если устройство создано - возвращаем S_OK return S_OK; } Посмотрите последний абзац статьи, там где есть скриншот стека с выделенным последним адресом - т.е. g_pd3dDevice. Наша задача как в статье выйти на вызвов g_pD3D->CreateDevice(….,&g_pd3dDevice). Чтобы выйти на этот участок, мы должны найти указательна g_pD3D, прозвонить call [ [eax] + 3c], где eax= g_pD3D. Вот там где мы окажемся по call и будет вызов g_pD3D->CreateDevice(….,&g_pd3dDevice) и там мы снимем показания стека на бряке. Чтобы найти g_pD3D мы должны найти Direct3DCreate9 или иную смотря какая у васверсия дайректИкс dll-и.Теперь смотрим внимательно статью ещё раз и думаем как снять показания, когда и какие бряки ставить. Но я предлагаю совершенно другой вариант. В том же ollyDbg поставить условный бряк на функцию процедуры окна на сообщение WM_PAINT и искать машинный код вот такого условия сравнения с нулём if( NULL ==g_pd3dDevice ) return; Где после этого сравнения будут вызовы типа call [[g_pd3dDevice]+ смещение] или g_pd3dDevice->функция(..): //----------------------------------------------------------------------------- // Имя: Render() // Описание: Рисование сцены //----------------------------------------------------------------------------- VOIDRender() { if( NULL == g_pd3dDevice ) return; // Очистка backbuffer'а в голубой цвет g_pd3dDevice->Clear( 0, NULL,D3DCLEAR_TARGET, D3DCOLOR_XRGB(0,0,255), 1.0f, 0 ); // начало сцены if( SUCCEEDED(g_pd3dDevice->BeginScene() ) ) { //Рендеринг объектов сцены должен находиться здесь // Конец сцены g_pd3dDevice->EndScene(); } // Выводим содержимое backbuffer'a на экран g_pd3dDevice->Present( NULL, NULL, NULL,NULL ); } //----------------------------------------------------------------------------- // Имя: MsgProc() // Описание: Обработка сообщений //----------------------------------------------------------------------------- LRESULT WINAPI MsgProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam ) { switch( msg ) { case WM_DESTROY: Cleanup(); PostQuitMessage( 0 ); return 0; case WM_PAINT: Render(); ValidateRect( hWnd, NULL ); return 0; } return DefWindowProc( hWnd, msg, wParam, lParam ); } Для проверки g_pd3dDevice посмотрите смещения call [[g_pd3dDevice]+ смещение] где смещение равно вызову функции Clear(), вызову BeginScene(),вызову EndScene(),Present(). Если подобную манипуляцию сделать однажды, то потом установить адрес устройства редеринга будет проще чем через способ , который автор первоисточника написал в статье. Но он-то написал это на примере работы в отладчике в режиме отладки, а если его способ автоматизировать то его способ будет даже наверно попроще моего, т.к. мой способ автоматизировать будет сложнее.

Ох... не будет автор модернизировать CE. Это уже обсуждалось.

Уважаемые пользователи, давайте не будем обсуждать CE vs Artmoney. Давайте обсуждать GodGame и конкретные вещи, и конкретные предложения. Автор программы напишет, что сделать реально, а что не реально. Вот и все

>>Ну это уже Cheat Engine получится, я специально делал так, что-бы окна не перекрывались. Если окна будут "не перекрываться", то невозможно будет без переключения между окнами работать с "дизассемблером, сканером памяти, окном скриптов". Речь идёт об удобстве. Напримере в MHS есть два варианта. Хочешь можешь слипить окна в одно, а хочешь можешь их разъединить. Делается все через drag and drop. Конечно, можно оставить как есть, я только предлагаю удобный вариант который я юзаю уже года 4 на Cheat Engine, MHS( было дело).

Да, перевод другой. Чтобы была настройка как на рисунке

Есть не очень удобная штука 1) Когда передаём фокус на адрес кликом (1) в окне дизассемблера, то в дизассемблере отображается первый адрес на который кликали(2). Было бы хорошо чтобы этот адрес(2) был не вверху окна дизассемблера, а по середине. 2) Если я передал фокус фокус на адрес(1), то пока я не передал фокус на дизассемблер, то я не могу скролить колесом мышки. Было бы хорошо, если можно было бы скроилть колесом мышки дизассемблерный код когда курсор перешёл в область панели дизассеблера. 3) Было бы удобно редактировать дизассемблерную инструкцию двойным кликом по колонке дизассемблерного кода, чтобы это не было установкой бряка на выполнение. 4) Ещё один момент. Если у меня сработало 10-20 инструкций, то я должен 10-20 раз кликать по адресам или перемещаться по ним, чтобы видеть дизассемблерный код в дизассемблере. Было бы удобно видеть список не просто "адрес - кол-во хитов", а такой 1) 00410400 mov eax, [ebx] 3 2) 00410440 mov eax, [ecx] 30 И лучше это делать в отдельной форме, которая показывается как только поставили бряк на адрес. 5) Когда я работаю в окне редактора скриптов, я не могу видеть другие окна. Ни дизассемблер, ни сканер памяти. Т.е. мне надо постоянно перемещать между окнами, когда мой монитор позволяет разместить отдельные окна и видить и работать с ними. Это довольно не удобно. 6) Когда я пишу скрипт формы мне приходится переключать редактор скрипта на форму и обратно. Хотелось бы видеть форму и видеть редактор скрипта одновременно. 7) Явно какая-то проблема с выравниванием контролов (характерно для всех версий GodGame на Windows7):

В этой теме ведётся обсуждение технических возможностей программы GodGame. 1) Описание функционала новых и старых версии 2) Обсуждение работы программы, что работает и что не работает 3) Предложите что-то исправить или что-то сделать Здесь пишем ближе по существующему функционалу. Автор программы GodGame не задёт вопросы в этой теме: 1) не задаёт вопрос типа "ищу того и того человека" для того и того 2) не задаёт вопроса типа "а что если я сделаю то и то, а как вам это понравится или не понравится" Эти вопросы он может задать в этой теме, существование которой пока не подтверждено Xipho.

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

Решил сегодня сгенирить трейнер в текущей версии GodGame v 1.5 Очень обрадовало автогенерация кода функцией "Скопировать код формы". Размер трейнера около 150 кб с демо-картинкой, которая весит 76кб. Без картинки получается 74Кб. Я так понимаю в этот размер входит поддержка функций ниже. Не уже ли ассемблер и и дизассемблер могут вместиться в 74кб-ный трейнер? Функции // Assemble ( Mnemonic: string; Address: Integer; var Bytes: string ) - Преобразует ассемблерную инструкцию в байт код // Disassemble ( Address: Pointer ) - Дизасембелирует инструкцию и возвращает ее строковое представление // GetInstructionSize ( Address: Pointer ) - Возвращает размер инструкции Эти функции работают с SIMD инструкциями, т.е. с инструкциями типа movsd и т.п.? Работают ли эти функции с 64-разрядными приложениями? Вроде я читал что не работают. Тогда будет ли это дело планироваться? Будут ли события в инспекторе объектов для формы? Если это дело сейчас не поддерживается и возможно планируется, то когда это можно будет поюзать? Пока я вынужден юзать Cheat Engine из-за поддержки 64-разрядных систем. И ещё чё-то я не понял где функции обработчиков событий для трёх кнопок в демо-скине. И в каких случаях нужен демо-скин, когда вроде как мы форму должны делать ещё до создания демо скина. Ты бы что ли тутор сделал бы на своём сайте по созданию простого трейнера с демо-скином. А то я не знаю. Демо скрипт есть, демо скин есть, а как они связаны не понятно. Я ещё еле угадал как кнопки разместить на форме демоскина.

Короче первый совет. Читать статьи и форум. Второй совет. Создать запрос на трейнер для игры в соответствующем разделе форума. И ждать. Третий совет. Подробно всё расписываем, что делаешь по шагам в этой теме. Если выбрала третий путь, то читаем ниже Да, уже хоть что-то , но это все-равно плохо описано. Как будто это какая-то подачка всем или мелкая подсказка. Решение проблемы нужно тебе больше всего и поэтому нужно все шаги расписывать и даже лучше со скриншотами чтобы интереснее было рассматривать проблему другим. Можешь, конечно, не расписывать, но тогда скорее всего никто и не поможет. Если своей работы ноль, то тогда обычно и никто не помогает. Зачем нужно долго и нудно описывать свои действия? Это нужно потому, что мало кому хочется все делать за кого-то и заниматься чьей-то проблемой. Можно расписывать следующим образом.

Либо полностью описывай процесс "от и до" о том что получалось и или не получалось. Ну, или жди у "моря погоды".

Короче обычно делают все через прыжки и прыжки рассчитывают.Если лень прыги рассчитывать (или есть другие причины (о них выше)) делаем через call.Да, и call в 32-разрыдных системах имеет размер 5 байт. Также и jmp. А вот short прыги (да-да, такие тоже есть) имеют размер два байта, если не ошибаюсь.

По первому вопросу. 1) Если использовать call, то для возврата желательно использовать ret. 2) Если используем jmp, то для возврата должен быть другой jmp. Второй пункт явно быстрее первого по выполнению инструкций. Но в то же время первый пункт даёт очень сильное преимущество, когда два и более call-ов "прозванивают" какой-то адрес, тогда по ret будет возврат в место под тем call, который был выполнен. Короче говоря call это своего рода функции. int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow){ SomeFunction(); // возращает eax из call //.... SomeFunction();// возращает eax из call //.... SomeFunction();// возращает eax из call //.... SomeFunction();// возращает eax из call //.... SomeFunction();// возращает eax из call //.... } int SomeGunction(){ //.... }

Я так понял тема уже перенесена откуда-то кем-то. Да будет здесь ей место. Посты почистил и объединил. Рейтинг keng-а не изменился.

Ты вроде просил ссылку по API. Вот хороший мануал (перевод SDK). Быстро сможешь прочитать как построить приложение на API. Это прочный фундамент полезно знать каждому перед тем как что-то писать на WinAPI на каком-то языке программирования. И эта информация гораздо лучше воспринимается если знаешь язык С++ (работу с функцими, передачу аргументов, компиляция проекта). Синтаксис не такой насыщенный как у ассемблера и более компактный. А компактность это залог того, что ты увидишь всю программу лучше чем по мелочам на ассемблере. Ну я не говорю, что лучше увидит программист, я говорю о пользователей который немного знает о программирование на /Дельфи(Object Pascal/Pascal)/C#/C/C++

Все твои статьи по асму очень хороши. Поставил по плюс один на каждый пост. Боюсь, что только люди, которые знают WinAPI хорошо понимают о чём идёт речь. Те кто первый раз имеет дело с WinAPI боюсь должны приложить много упорства. Чтобы материал возможно лучше воспринимался мои пожелания строить статьи следующим образом. 1. Показать результат. Показать готовый exe-шник и скриншот. Покаазать весь исходник без комментариев, который пользователь должен скомпилить и сам убедиться что его код работает. И лучше это скомпилировать сейчас и почувствовать сейчас в начале статьи, а не в конце статьи. Т.е. пользователь вынужден запоминать правила построения приложения, но ещё не увидел конечный результат, а только смутно представил. 2. А вот теперь по кускам разбираем участки кода, т.е. то что ты обычно пишешь. 3. Ещё очень было бы полезно поучить читателя работать с документацией WinAPI по состовлению приложения "Простой диалог" на C++ и сравнить это дело с fasm-ов или другим ассемблером: Можно найти этот исходный код по запросу "MSDN Создание приложения Win32 (C++)"

Grom-Skynet, твой пятый пост довольно хорош Чем чаще будешь использовать подобные "витиеватые приемы" по установке определённых типов бряков на определённые адреса, тем больше ты овладеешь интуицией в создании очень сложных читов. Поздравляю Как и Xipho я тоже сходу подумал про поток на АА-скриптах createthread("метка в выделенной памяти") и совсем забыл, что адрес из структуры может постоянно или с другой периодичностью читаться для установки прыжка при инициализации "person controller". Действительно надо ставить бряк на чтение и экспериментировать, что ты в принципе успешно сделал. "person controller" это название условного класса кода по управлению 3D-моделью героя. Модель героя и этот класс инициализируются вместе с новой сценой. Данные прыжка, позиции 3D-модели, позиции камеры и другие устанавливаются из данных в ресурсах в структуру героя. Когда пользователь пытается прыгать, то читается адрес со значением высоты прыжка из этой структуры. Как-то так...

Значит ты исправил только визуальное отображение. Попробуй исследовать что влияет на это "визуальное отображение зацепки крюка" после "чтения координат твоего героя". Т.е. поставь бряк на прохождение "отображения крюка". Игра должна остановиться. Просканируй стек в котором могут быть координаты твоего героя или один из указателей связанный со структурой твоего героя. Если найдёшь подозрительный участок стека поднимайся по ретам вверх выходя из callo-в. Короче говоря тебе нужно найти развилку кода. Если "что-то", то "показывать возможность зацепить крюком", иначе "не показывать" Объяснил как смог. Сам заниматься этим не могу, очень много работы.

ZOCKIR, если что-то вылетает в казалось бы нормальной инъекции, то советую проверять работоспособность твоей инъекции кода в OllyDbg, а не подбирать по какому-то странному принципу инструкции которые бы подходили И если можно избавиться от использования pushad/popad то лучше это и делать (зачем нам сохранять и восстанавливать данные из регистров которые мы не трогаем). Если что напоминаю, что эта команда не "кладёт" в стек EIP и не кладёт регистр флагов EFLAGS.

>> Есть вероятность того что свободные регистры в этой инструкции они будут постоянно свободный для внедрение своего чита? ZOCKIR, по этому участку кода на скриншоте ничего не могу сказать. Может быть да, а может быть и нет. А ebx тут зачем класть в стек и восстанавливать, если им не пользуешься?! ))

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

Спасибо за статью Несколько вещей, которые я никогда не делаю и не советую так делать 1) Не искать указатель сканером указателей, а искать (его в отладчике + возможно использовать сканер памяти для поиска адреса) 2) Не проверять указатель перезагрукой ПК. 99% эта необходимость отпадает если применять способ в пункте1, когда мы достаточно уверены в работе указателей. 3) Не писать в АА-скриптах mov [[[..]...]..]..],(float)100 . Вместо этого нужно писать ассемблерный код. Дело в том что mov [[[..]...]..]..],(float)100 Будет как: mov [адрес],(float)100 Но, в играх полезно постоянно читать весь путь, а не конечный рассчитанный адрес. Если игра перезагрузиться, то конечный адрес можете поменяться. Желаю успехов автору статьи

По поводу адреса азота. Скорее всего, те кто искал не нашли именно нужный адрес. Я бы искал неизвестное значение которое уменьшалось бы при уменьшении азота, если бы не нашёл искал бы значение которое увеличивалось при уменьшении азота. Типы 1,2,4,4 float, double. Если бы не нашёл что хотел, то копал бы ввырх по ретам из этой MSVCR90.dll, т.к. это тоже зацепка.