Перейти к содержанию

MasterGH

Ветераны
  • Постов

    2 999
  • Зарегистрирован

  • Победитель дней

    129

Весь контент MasterGH

  1. Информация. 1) CE периодически фиксится без уведомления в новостях на главном сайте, так что имейте ввиду. Возможно ваш баг уже исправлен. 2) В этом обзоре (наверно уже вы его видели, привожу ещё раз на всякий случай) показаны основные фишки CE 6.0 (я например узнал как пользоваться сканированием по процентам). Также вы увидите описание трейсера, установки условных бряков и увидите что-то ещё. 3) Кое-кто (mgr.inz.Player) уже успел сделать таблицу на CE 6.0 для Сталкера. Там же есть LUA + помните что в Сталкере объектные патроны, кому интересно могут посмотреть как были сделаны бесконечные патроны. Хотя я думаю, там просто автоматизирована перезарядка, с каждой перезарядкой можно создавать новые патроны. Т.е. без перезарядки беск. патроны не сделаешь простым способом. А там именно этот простой способ. Я же делал без перезарядки (только скрипт остался на харде в Москве, а сейчас не в Москве, так что посмотреть не могу) Скрины и скрипт xrEngine.rar:
  2. 1) туторы LUA с форума CE - здесь; 2) последние изменения/добавления в LUA можно увидеть здесь; 3) константы здесь; 4) как работают LUA функции в коде - здесь; О LUA в CE 6.0 LUA движок используется в Cheat Engine 6.0, а также и в множестве игр. Вспомните что у большинства компьютерных игр под Windows есть вызов игровой консоли так вот я точно не знаю, но вроде в большинстве случаев для этой консоли используется LUA движки. Например, в игре СТАЛКЕР точно есть LUA. Я всё пишу к тому, что LUA может вам пригодиться для модинга, спавна и т.п. Но сейчас речь не об этом. О достоинствах LUA я писал в нескольких темах на форуме, одна из них. Привожу справочный материал из справки CE 6.0 Тутор 5. Обзор GUI - элементов и работа с GUI - элементами. GUI (или Graphical user interface графический интерфейс пользователя) имеют все оконные приложения Windows. В него входят различные элементы: форма, даилоги, кнопки, панели, лейблы(вывод одной строкой с возможностью возврата каретки и новой строки), едиты (ввод/ввод текста одной строкой), мемо(многострочный ввод/вывод) и т.п. Перед тем как обратиться к этим элементам стоит рассмотреть управления окнами CE. Эти команды удобны в тех случаях, когда вы создаёте LUA трейнер чтобы CE не мешался своим видом. Пришёл ответ. Это возможность пока не поддерживается. Но в будущей версии 6.1 уже поддерживается загрузка картинок с ресурсами форму из IDE LUA. Причем картинки разных форматов, а не только bmp. Можете посмотреть на результат. Картинка весит ~70 кб. Файл скрипта весит в два раза больше. Учитывая то, что кроме картинки больше ничего нет. А знаете почему. Потому что скрипт это xml разметки и картинка преобразуется в нём в текстовый вид байтов. <CheatTable CheatEngineTableVersion="10"> <Forms> <UDF1>5450463007544345466F726D0455444631044C65667403A30106486569676874039F0003546F7003C401055769647468034301084175746F53697A65 //.......................... (вырезано мной) FD9000000</UDF1> </Forms> <CheatEntries/> <UserdefinedSymbols/> </CheatTable><?xml version="1.0"?> Если картинку удалить, то скрипт занимает 301 байт. <CheatTable CheatEngineTableVersion="10"> <Forms> <UDF1>5450463007544345466F726D0455444631044C6566740360010648656967687403F00003546F70038F010557696474680340010743617074696F6E0604554446310000</UDF1> </Forms> <CheatEntries/> <UserdefinedSymbols/> </CheatTable><?xml version="1.0"?> Также хочу напомнить, что очень важен именно такой тип трейнеров зависящих от установленной Cheat Engine, а не автономно работающих отдельно от CE. Почему спросите вы? Я отвечу: 1) Очень важно - в любой момент можно проанализировать и изменить скрипт. 2) Автономные трейнеры от CE не подходят (хотя их тоже можно открыть в CE и редактировать). Они не подходят и логически и из-за увеличения размера в базе данных, которая будет и без того разрастаться. Логически одна часть программы должна быть на компьютере пользователя и должна строить интерфейс трейнера по разметке. Разметки, т.е. скрипты уже пользователь может качать хоть откуда. Если пользователь не будет размещать в своём трейнере картинок, то его разметка будет меньше 1 кб. Сравните самый маленький трейнер обычно больше 2 кб. А в основном делают трейнеры которые больше 20 кб. Если паковать/распаковывать в огромной базе, то это будет ненужной работой процессора, который будет работать с базой данных. Одно дело когда мы хотим скачать трейнер пусть даже размером 1 мб. Мы его скачаем попользуемся и удалим. Другое дело быть человеком который хранит множество трейнеров, чтобы другие ими пользовались. И тут встаёт вопрос. Во всех трейнерах есть множество повторяющейся логической информации: код создание окна, обработчики сообщений, PE формат исполянемых файлов. Всё это мусор когда терйнеров больше одного. Мы должны работать только с той информацией которая удобна и которая не повторяется от трейнера к трейнеру. Решение это именно таблицы Cheat Engine: LUA скрипты + автоассемблер + подгрузка dll-ок. Больше ничего геймхакеру и не нужно, он сосредоточиться только на инъекции кода и сможет быстро и удобно изменять её в любой момент и хранить свой труд в максимально лучшей форме - восприятии и компактности. Какие нам нужны ещё туторы. 0) Работа с вводом/выводом (горячие клавиши, эмуляция клавиш, обработчики нажатий клавиш) 1) Отображения информации из памяти игры в GUI элементах 2) Создание интерфейса как у трейнера с управлением активации и деактивации читов 3) По дизассемблерным инструкциям формирование автоассемблерных скриптов и читов 4) Пользователь вводит адрес параметра, после чего происходит отладка с нахождением инструкций, создаётся чит... 5) Работа в LUA с файлами 6) Создание автоматизированных сценариев в сингловых играх. и т.п. Резюме по LUA CE 6.0 Кстати поддержка отдельно функционирующих трейнеров будет в следующих версиях (написал Дарк Байт) Вообще я считаю не очень стоит заморачиваться на LUA в создании трейнеров. Форму трейнера с GUI элементами по прежнему удобнее создавать в IDE VisulaStudio. Как я писал много раз я придерживаюсь модели: создания программы ланчера TrainerMAx с БД библиотек cheat.dll, которые внедряются в процесс используют базовые функции из SystemCheat.dll. И это самый лушчий способ, который я знаю в создании групп трейнеров. GUI форму можно сменить на DirectX и OpenGL.... НО LUA это хороший эксперимент. И все же он полезен при исследовании игрового кода, т.к. с его помощью можно автоматизировать чтение структур данных, их обработки (сравнении, выводе информации по условию и т.п.).
  3. Для тех кто не знает о возможностях CE 6.0 можно прочитать на форуме CE здесь и здесь.
  4. Объявляется благодарность Дарк Байту за создание CE и обновления до 6.0 Как жаль что тебя нет на этом форуме. Был ты на нашем форуме получил бы к уровню +100
  5. Ага, я не подумал об этом . С помощью LUA можно дизассемблировать инструкции, анализировать их и составлять автоассемблерные скрипты. Их потом можно сразу использовать как чит или перед этим добавить его в таблицу читов, а после закрытия CE удалять, т.к. они создаются динамически. Также можно автоматизировать отладку по LUA если это требуется... а от пользователя потребуется только ввести начальный адрес некоторого параметра. +1
  6. Да и кстати забыл обратить внимание. Теперь CE не поддерживает создания трейнеров как самостоятельных программ как это было ранее. Но это дело двух сторон. С одной стороны - не имеет поддрежки трейнеров, с другой стороны на LUA скриптах вы можете создать "форму трейнера" и необходимые контролы Т.е. теперь вы скриптами пишите и форму трейнера и сами читы. Затем эти скрипты аккуратно сохраняете по папкам и запускаете когда надо. Вообще хорошая идея. Однако было бы лучше если бы в CE была база данных как локальная (хотябы локальная) так и удалённая. Чтобы к этой БД можно было делать запросы и получить необходимые скрипты и описания к ним.
  7. 1) DEALLOC - удаление выделенной памяти 2)GlobalAlloc (уже такая директива была). Нужна для разового выделения памяти. Пример [ENABLE] GlobalAlloc(mem1,500) mem1: // будет выделена память [DISABLE] // описания изменение В этом примере при включении/выключении чита, mem1 выделиться только первый раз. Если кто-то общается с Дарк Байтом, то можете предложить ему аналогичную директиву для CreateThread которая аналогично бы работала один раз. А также ввести аналогичную директиву распрастраняющуюся на группы читов. Например, это было бы полезно если нужно выполнить какой-то поток при первой активации любого чита из группы читов. Про активирующие скрипты - http://forum.gamehac...db0490fa0249111 3) У CE обновлён Script engine на движке LUA
  8. Вышла CE 6.0. Описание: Обсуждаем новые возможности в этой теме.
  9. Возможно игра берёт "куски текстов-параметров", парсит текст и изменяет параметры как требуется, затем читает параметры которые следует вывести на экран. Ставишь бряк на запись на байт текста, когда прервётся посмотри каким образом текст менялся. Если встретишь массив символов найди на него указатели чрезе отладку и там вверх по коду пройдёшься в отладке и если сюрпризов не будет то увидишь что-то типа привидения типов из текста в числовой параметр и обратно и там уже разберёшься как подменить нужный тебе параметр. "Код игры всегда "знает" как к какому параметру обратиться если это обращение было видно в игровом интерфейсе. 100% выход - копаться в отладке"
  10. Благодарность с моей стороны: live_4_ever, Grom-Skynet, Akama, JIeXaGAD. - Вы входите теперь в группу Разработчиков; - Вам доступен скрытый форум Наши реализы; - Вы можете загружать файлы на хостинг форума (ваши файлы, трейнеры, картинки, тексты и т.п. можно аттачить к форуму чтобы они не пропали со временем); Спасибо вам всем за участие в жизни форума!
  11. Xipho, помнишь ты мне дал твою функцию определения настоящего имени модуля dll в удалённом процессе. Тут что используем?! CreateFile, CreateFileMapping, MapViewOfFile, затем через череду путей добираемся до pImportDesc (это PIMAGE_EXPORT_DIRECTORY) Затем так получаем реальное имя (char*)(DWORD(mFile)+ (DWORD)(pImportDesc->Name)), где mFile был получен из MapViewOfFile(hMapFile....) hMapFile - из CreateFileMapping(hFile,...) hFile - из CreateFile(Path,...) Path - полный путь с названием файла модуля // Дефайны #define MakePtr(Type, Base, Offset) ((Type)(DWORD(Base) + (DWORD)(Offset))) #define NTSIGNATURE(a) ((LPVOID)((BYTE *)a + ((PIMAGE_DOS_HEADER)a)->e_lfanew)) // char *Output - возврат реального имени модуля // char *Path - передача пути модуля по указателю в GetModuleRealName void GetModuleRealName(char *Output,char *Path) { HANDLE hFile = CreateFile(Path,GENERIC_READ,FILE_SHARE_READ | FILE_SHARE_WRITE,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0); if (hFile!=INVALID_HANDLE_VALUE) { HANDLE hMapFile = CreateFileMapping(hFile,NULL,PAGE_READONLY | SEC_IMAGE,0,0,NULL); if (hMapFile) { PBYTE mFile = (PBYTE)MapViewOfFile(hMapFile,FILE_MAP_READ,0,0,0); PIMAGE_DOS_HEADER pDOSHead; pDOSHead = (PIMAGE_DOS_HEADER)mFile; if (pDOSHead->e_magic != IMAGE_DOS_SIGNATURE) { MessageBox(NULL,"Error Dos Header signature MZ","Error",MB_OK); } PIMAGE_NT_HEADERS pPEHeader; pPEHeader=(PIMAGE_NT_HEADERS) NTSIGNATURE(pDOSHead); if (pPEHeader->Signature != IMAGE_NT_SIGNATURE) { MessageBox(NULL,"Error PE Header signature PE","Error",MB_OK); } IMAGE_OPTIONAL_HEADER32 OptionalHeader; OptionalHeader = (IMAGE_OPTIONAL_HEADER32) pPEHeader->OptionalHeader; PIMAGE_EXPORT_DIRECTORY pImportDesc=NULL; pImportDesc = MakePtr(PIMAGE_EXPORT_DIRECTORY,mFile,pPEHeader->OptionalHeader.DataDirectory[0].VirtualAddress); char *p = MakePtr(char*,mFile,pImportDesc->Name); strcpy_s(Output,strlen(p)+1,p); UnmapViewOfFile(mFile); } CloseHandle(hMapFile); } else { int er = GetLastError(); char p[30]; wsprintf(p,"Last Error: %d",er); MessageBox(NULL,p,"ERROR",MB_OK); } CloseHandle(hFile); } 1) Так вот у меня вопросы как называется твой метод если имеет какое название? 2) Какое отношение он имеет к именованным каналам и другим видам межпроцессорного взаимодействия? 3) Теоритически можно ли было твою функцию переписать как поиск сигнатуры? 4) Теоритически можно ли было твою функцию переписать используя метод разделяемой памяти? Т.е. делаем например так. Ищем все модули процесса (как ты делал) У каждого модуля ищем реальное имя и возвращаем его, а делаем это так. Своим главным потоком процесса1 позаимствуем секцию(ии) чужого процесса2 по методу разделяемой памяти, остановив перед этим процесс2. И работаем с этими секциями как со своими внутри процесса1 - читаем данные этих секций как свои для процесса1 на предмет поиска настоящего имени dll. Выводим на консоль, отменяем семафоры (их два и их ещё надо было создать до этого), закрываем ненужные дескрипторы, размораживаем процесс2...
  12. Хороший пример хакинга через внедренную dll, а также с примером хука на directXDraw функции начала сцены, функции конца сцены, функции reset... Посмотрите на интересный вариант описания реализации класса Hacks из Hacks.h:
  13. Ок. Про ассемблерный код. Упростить вроде не упростишь. Лучше вообще переписать так: Главный скрипт: registersymbol(pStruct) Player: mov [pHero],esi push eax mov eax,[esi+FC] // загрузил структуру золота и очков mov [pStruct],eax pop eax fld dword ptr [esi+0000018c] jmp EPlayer Включаешь этот скрипт, а в таблице Cheat Engine пишешь: 1) указатели относительно зарегистрированной метки pStruct; 2) функцию добавления и добавляемое значение; 3) горячие клавиши. Можно городить эти каскады флагов как ты сделал, но они отнимают ресурсы у процессора (не нужно чтобы этот кусок кода срабатывал с частотой меньше чем 10 мс, да и "главный скрипт" должен срабатывать когда меняются указатели pHero и pStruct) cmp dword ptr [iXP],1 jne p2 add [eax+8c],#1000 mov [iXP],0 p2: cmp dword ptr [iPP],1 jne p3 add [eax+2c],#10 mov [iPP],0 p3: cmp dword ptr [iSP],1 jne BPlayer add [eax+3c],#10 mov [iSP],0 BPlayer: pop eax
  14. Я этот исходник посмотрел ещё давно когда ты его выложил. Если постараться дать объективную оценку ему, то он написан по методам "современной школы, которая "потихоньку превращается в старую". Это школа имеет тенденцию выделять/изменять новую память для инъекций тел чит-кодов с помощью процесса трейнера. Это тенденция очень популярна и по сей день в скриптах CheatEngine и в большинстве любых других трейнерах которые делают сегодня. Но существует ещё одна "школа" которую можно назвать мало используемой старой (менее популярной из-за сложностей внедрение и написания своих dll-ок) или школой нового поколения которая где-то развивается парочкой людей и её не использует большинство. "Новая школа" предполагает создание особого модуля xxx.dll который по разному можно внедрить в процесс игры при помощи трейнера, после чего трейнер непосредственно с памятью процесса игры не работает, т.к. с ним работает та самая xxx.dll предназначение которой изменять поведение игры... В CheatEngine есть методы загрузки такой dll-ки и даже есть такой метод в скриптах CE. Но по сей день на форуме Cheat Engine популярны скрипты CE без работы с dll.
  15. А можно по конкретней, что это за новинка? Это просто многоуровневые указатели на нулевые адреса привязанные к версии эмулятора или это одно-многоуровневые указатели на нулевые адреса которые находятся автоматически независимо от эмулятора и только в зависимости от рома?
  16. Снова для тех кто решит писать на C/C++ Пишем шаблон для повторяющихся участков cmp dword ptr [x1],1 jne _next add [x2],x3 mov [x1],0 _next://переменные dword: x1, x2, x3, _next Представим это дело функцией: { if (x1==0) { x2+=x3; x1=1; } }inline void AddSource(DWORD x1, x2, x3) Представим это дело как если бы писали dll-ку: void InitCheatData() { // написать инициализцаию для структуры cheatData; // написать прыг на Injection1() в место внедрения // написать баты нопов } void Injection1() { __asm { pushad pushfd } CheatAddValueHero(); /* Посмотри сколько читов я могу сделать на С/С++ дальше а ты будешь их долго писать на ассемблере Cheat1(); Cheat2(); Cheat3(); Cheat4(); Cheat5(); Cheat6(); Cheat7(); Cheat8(); Cheat9(); Cheat10(); Cheat11(); Если выбирать между удобством С/С++ и эффективностью ассемблера, то лучше выбрать первое если сложные: читы, механизмы активации и деактивации, если читов довольно много и т.п. */ __asm { popfd popad } } inline void CheatAddValueHero() { for(int i=0; i<3; i++) { if (cheatData[i].x1==0) { cheatData[i].x2+=cheatData[i].x3; cheatData[i].x1=1; } } }struct CheatData {DWORD x1, x2, x3}[] cheatData; При загруке dll-ки вызывать функцию удалённым потоком InitCheatData();
  17. Akama, всё что я описывал это были общие рекомендации. Между прочем твоё решение было в этих рекомендациях, если ты не увидел. По-другому твой скрипт можно так написать: [ENABLE] alloc(newmem,2048) label(returnhere) label(originalcode) StrongholdLegends.exe+3E82D9: jmp newmem nop nop nop nop returnhere: newmem: fst dword ptr [ecx+4c] fcomp dword ptr [00910168] cmp dword ptr [ecx+178],1 jne returnhere push [ecx+48] pop [ecx+4c] jmp returnhere [DISABLE] StrongholdLegends.exe+3E82D9: fst dword ptr [ecx+4c] fcomp dword ptr [00910168]
  18. Напоминаю, что реализ CE 6.0 на официальном сайте подразумевается 31 декабря или позже (январе или даже в феврале). Так что ждём Те кто ждать не хотят могут сами скомпилировать проект из исходников SVN. Так же хочется упомянуть, что основная проблема русификации и тем более модернизации CE состоит в ручном изменении исходников CE. Т.е. довольно нудно и трудоёмко вручную переносить старые модернизации в новые версии CE. Если бы это дело как-то автоматизировать (например Макросами IDE Delphi), то было гораздо проще. Другая проблема лично моя - пока модернизацией CE я заниматься не хочу, т.к. полно своих дел.
  19. Что-то я не понял. Этот глюк спонтанно возникает с твоими изменениями в памяти или без них? Если второе, то искать причину будет весьма трудно. Если первое, то легче, но насколько легче не известно. По крайне мере в первом случае можно чётко установить обратную связь - изменил значение адреса, то получил глюк. Что-то бит я не увидел, увидел только "2,5 (CC102h) и 3,5(E0EC102h) байта" То что "ноль приводит к таким последствиям" это да - случайность и открытие. Но можно было предположить, что ты можешь перечислить наборы всех моделей пока не получить такое свойство. И тут тебе бы не пришлось много перебирать если бы ты начала с нуля. За труды в исследовании +1.
  20. Я это предположил с точностью до 80-99% процентов по первому посту в твоей теме. Я просто написал свои мысли для тех кому они могут пригодиться. Да и потом кто знает, может скрипты CE тебе будут скучны в будущем из-за того что ты будешь cool-программистом и тебе возможно это пригодиться.
  21. НА будущее для тех кто решит сделать подобное на С++. Текст ниже удобнее читать снизу-вверх.
  22. Все эти пути сводятся к одному - использование сканера памяти, отладчика Windows-приложений, отладчка рома и язык программирования (для продвинутых позволит автоматизировать разные процессы). На языке программирования будет выглядеть лучше и проще. На MHS C-скрипте будет выглядеть тоже не плохо. Например, тебе нужно описать отдельные функции: 1) Функция2 (использующая nulladdr) возвращающая структуру Hero; 2) Функция3 (использующая Hero) совершает например заморозку здоровья героя; 3) Функция4 (использующая Hero) совершает например заморозку стойкости машины. Аналогично, можно сделать PS2-ассемблерными вставками вместо заморозки, что будет эффективнее. В MHS можно написать С-подобный скрипт и связать с горячей клавишей. Так что MHS решает эту задачу. Да и вообще эффективнее не использовать заморозку, а редктировать PS2-ассемблерный код. Первую причину установить легко - делай по шагам, то что привело к эффекту "глюка" и определишь какой шаг привёл к нему.
  23. Этой информации не достаточно. Тебе нужно сравнить как минимум 4 листинга регистров юнитов. Два твоих двух разных юнитов и два разных юнитов- врагов. Это сравнение первое которое можно сделать перед тем как ты сравнивал структуры юнитов твоих и врагов. Оно не всегда помогает и в этом случае уже можно сравнивать инструкции на бряках здоровья твоего и чужого юнитов. Если опять не определил фильтров, то ищёшь указатель уровня вверх по дизассемблерному коду и аналогично проходишь все этапы с ним: сравнение структур указателей твоего игрока и других юнитов, сравнение регистров, сравнение инструкций... не получилось, тогда опять ищем указатель на уровень выше и делаем заново с ним. Утомительно, не спорю, но возможно иначе никак. Хотя есть ещё изворотливый способ, например, сравнивать дампы стека во время бряков на здоровье юнитов и также другой памяти игры....
×
×
  • Создать...

Важная информация

Находясь на нашем сайте, Вы автоматически соглашаетесь соблюдать наши Условия использования.