MasterGH

На форуме написано по каким правилам составляется цепочка байт, там написано как пользоваться aobscan. Им можно пользоваться в Автоассемблере, а можно на Lua. Скрипт Можно переделать на этот: А можно и на этот на Lua (но я не проверял):

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

О, не плохо. Если ты сам написал описание "_call()", то даже я не знал про то, что так можно динамически определять аргументы функции... Это можно реализовать и на автоассемблере, и на Lua, и на том и другом вместе. Я подумаю как сделать удобнее... Возможно стоит просто вызывать AddMsg() из скриптов CE по горячим клавишам... посмотрим. ------------- Кстати по той же теме, может кому будет полезно, мой набросок одной инъекции. Её предназначение сохранять базу данных из одного формата в другой в файл. Код не был доработан, но можно понять что делать чтобы сохранить что-то и как-то в файл.

int (сокращённое от "Integer") - это тип данных для определения переменой числа. У числа типа int может быть положительный и отрицательный знак. Размер 4 байта. Более подробно в поисковике по запросу "типы данных Integer"

Для тех кто хочет использовать этот компонент, а также другие на этом примере с setProperty не из дизайнера создания форм. В данном примере создаётся ListView с 3 столбцами и 3 строками. f=createForm() lv=createListView(f) setProperty(lv, 'ViewStyle', 'vsReport') --non lua exported property but you can access it with this setProperty(lv, 'RowSelect', 'True') setProperty(lv, 'ReadOnly', 'True') lvc=listview_getColumns(lv) column1=listcolumns_add(lvc) column2=listcolumns_add(lvc) column3=listcolumns_add(lvc) listcolumn_setCaption(column1, 'a') listcolumn_setCaption(column2, 'b') listcolumn_setCaption(column3, 'c') lvi=listview_getItems(lv); row1=listitems_add(lvi) listitem_setCaption(row1, 'Row 1'); --rw 1 column a row1_subitems=listitem_getSubItems(row1) --returns a Strings object strings_add(row1_subitems, 'r1_cb') --row 1 column b strings_add(row1_subitems, 'r1_cc') --row 1 column c row2=listitems_add(lvi) listitem_setCaption(row2, 'Row 2'); row2_subitems=listitem_getSubItems(row2) strings_add(row2_subitems, 'r2_cb') strings_add(row2_subitems, 'r2_cc') row3=listitems_add(lvi) listitem_setCaption(row3, 'Row 3'); row3_subitems=listitem_getSubItems(row3) strings_add(row3_subitems, 'r3_cb') strings_add(row3_subitems, 'r3_cc') Источник форум CE.

Да, реально. Предвижу несколько способов. Покажу на мой взглядлучший из них, но не проверенный и не полный, поэтому могут быть ошибки. function FunctionSpawnCar(hotkey) autoAssemble("CREATETHREAD(SpawnCar)") end function SetHotKey(func, hotkey) local objectHotKey = createHotkey(func, hotkey) generichotkey_setKeys(objectHotKey, hotkey) generichotkey_onHotkey(objectHotKey, func) end function Deinitialization() autoAssemble([[ unregistersymbol(SpawnCar) dealloc(SpawnCar) ]]) end function Initialization() local address = ... // получить адрес вызываемой функции local AAscript = [[ alloc(SpawnCar,2048) registersymbol(SpawnCar) label(stringCar) SpawnCar: push ... push ... push stringCar call ]]..address..[[ ret stringCar: db ... 00 // hex-строка машины оканчивающаясь нулевым символом ]] autoAssemble(AAscript) --создание формы трейнера -- ... --привязка функции Deinitialization() к закрытию формы -- ... --Назначение хоткеев setHotKey(FunctionSpawnCar, VK_F2) -- спавн некоторой машины end function onOpenProcess(processid) Initialization() end local aalist = getAutoAttachList() stringlist_add(aalist, "gta4.exe") Как видно здесь Lua код вперемешку с Автоассемблером. Есть инициализация, деинициализация, првязка горячей клавиши, создание потока на АА. Могут быть проблемы с поточной синхронизацией или другие, надо проверять на практике... 1. Можно ли на Lua делать удобнее не знаю. Для каждого человека своё видение удобства.2. По горячим клавишам можно выполнять Lua функцию, которая могла бы на АА скриптах что-то делать... создавать новые "секции кода" и уничтожать старые. 3. Переменные можно менять и без Lua. Зарегистрируй их в АА через registersymbol. Создай другой АА который бы менял значения по зарегистрированным меткам. 4. Когда Lua поддержки в CE не было у меня была та же проблема. Lua я не знал, но учился на примерах.

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

2. Случай. Увлёкшись написанием длинного скрипта можно забыть о корректности типов данных. В этом примере не учтено, что cmp без указания типа данных сравнивает данные как dword. Это касается 32-х разрядных приложений.

Izmalkoff, давай я не буду гадать, а просто буду учить как проверять свои скрипты. 1) Перед активацией скрипта (игра должна быть в оконном режиме), надо зайти по адресу 038B0013 в дизассемблер. 2) Нужно выделить инструкцию левым кликом мышки с которой будет переход на инструкцию по адресу 038B0013 3) Нажать на F5 чтобы поставить бряк на выполнение (чтобы снять нажать ещё раз) 4) Зайти в игру и что-то сделать, чтобы игра прервалась в отладчике 5) Затем выполняешь отладку по шагам c заходом в call и смотришь за регистрами (кнопки F7 шаг с заходом в call, F8 - шаг без захода в call), Таким образом ты определишь что в регистрах сранивается, что не сравнивается, почему выполняются или не выполняются прыжки.

Лучше меня и Xipho Шефами не величать, а использовать никнеймы. Мы будем рады если называть нас по никнеймам По поводу способа ничего против не имею так как я с ним не работал и тонкостей не узнавал.

Не одно и тоже. Способ который я привёл рассчитывает указатель каждый раз заново, а твой - только при активации чита. Применять тот или иной способ зависит от кода игры. Посмотри в дизассемблере что у тебя получается при активации чита. Так же советую это делать почаще для версии CE 6.1, т.к. она может неправильно ассемблировать. По поводу вылета на "faddp dword [ecx]". У меня вообще эта инструкция не ассемблировалась. Похоже она работает только с регистрами FPU.

aliast, замени там где надо db на dd или поставь тип данных байта в сравнении. По умолчанию в 32-разрядных приложениях сравниваются значения типа dword-а. Поэтому такой эффект.

Ой. Инструкцию "movss xmm0,[ecx]" надо убрать. По идеи xmm0 дальше использоваться не будет. А если будет, то надо по другому написать.

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

В какой-то игре случай с добавлением числа с точкой может быть разным и придётся писать инструкции иначе. Мой пример для всех игр не подходит и его нужно менять. Попробую написать подробнее. push eax //eax = 175.4727812 fld dword [esp] fadd dword [value] fstp dword [esp] pop eax // eax = eax + 3.4383 push eax //eax уже предположительно равен 175.4727812 и его помещаем в стек в [esp] fld dword [esp] // загружаем в ST0 значение 175.4727812 из стека fadd dword [value] // добавляем к ST0 значение [value], меняется ST0 fstp dword [esp] // перезаписываем значение в стеке c выплёвываем из ST0 уже сумму pop eax // eax = eax + 3.4383 // почти аналогично "выплёвываем" из стека сумму в eax По поводу твоего примера, лучше не писать цепочку в скрипте типа mov ebx,[[[[[p4dftre.dll+01849C8C]+24]+28]+128]+4] и убрать лишние инструкции. Цепочку лучше так не писать, потому что она рассчитывает один раз и ассемблируется как mov ebx,[адрес]. А адрес в течении игры может быть другим! Может быть вылет из игры. Если есть полная цепочка указателей, то лучше не делать сравнений... И того получаем: newmem: pushf mov ecx,[p4dftre.dll+01849C8C] mov ecx,[ecx + 24] mov ecx,[ecx + 28] mov ecx,[ecx + 128] mov ecx,[ecx + 4] lea ecx,[ecx + 208] // ecx = [[[[[p4dftre.dll+01849C8C]+24]+28]+128]+4]+208 fld dword [value] faddp dword [ecx] movss xmm0,[ecx] popf mov ecx,esi jmp returnhere value: dd (float)1.0 Может быть я где-то ошибся поэтому надо проверить в отладке. И ещё если знать работу с XMM-рами, то возможно можно ещё короче написать, т.к. в xmm0 в "младшей" части уже есть значение, к которому надо прибвить value.

Попробуй сделать следующее. Запусти его трейнер чтобы тот уже работал с игрой. Подключись к процессу трейнера procxp.exe. Найди процесс трейнера (или один из нескольких процессов), выдели его и спосмотри в его свойствах строки. Попробуй через ctrl+f ввести строки из предполагаемого скрипта. Например введи "ENABLE"... возможно у тебя получиться увидеть скрипты на CE, если они будут в памяти процесса.

А ну теперь ясна первостепенная задача. А ты не смотрел таблицы на официальном сайте Cheat Engine, может быть ты там найдёшь подсказку?!

А что в этом трейнере особенного, раз ты взялся за его распаковку?

Очень маловероятно что может произойти "крэш" процесса современной игры. Причина скорее в антиотладочной защите. В Cheat Engine есть режим VEH-дебегера в таких случаях. Но против некоторых версий Старфорса не поможет. Если я не ошибся, то где-то так: [ENABLE] //code from here to '[DISABLE]' will be used to enable the cheat alloc(newmem,2048) //2kb should be enough label(returnhere) label(originalcode) label(exit) label(value) newmem: //.... push eax //eax = 175.4727812 fld dword [esp] fadd dword [value] fstp dword [esp] pop eax // eax = eax + 3.4383 originalcode: //... exit: jmp returnhere value: dd (float)3.4383 "Test.exe"+556DE: jmp newmem returnhere: [DISABLE] "Test.exe"+556DE: mov eax,004546C0 //Alt: db B8 C0 46 45 00 dealloc(newmem)

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

Akama, не спешил бы ты с выводами так скоро и при любой возможности. Вот практическое применение. Как видно на рисунке указатели были исследованы, а вот как сделать "бесконечное обучение заклинаниям" будет описано ниже благодаря способу о котором идёт речь. Этот способ установил рамки до какого адреса вверх стоит подниматься из call-ов.

Здесь вызывается не 0xDEADBEEF ("то что мы хотели"), а "0xDEADBEEF + dwLoadOffset". А почему вычитается "0x400000" ?

Если игра в полноэкранном режиме, то эти кнопки не будут доступны. Так что ни одна дополнительная кнопка не позволит свернуть игру в окно.

Это зависит от конкретного случая. Надо подразумевать простую схему. Когда используешь этот способ, то у тебя есть два адреса как минимум одного маршрута выполнения машинного кода. Первая точка это бряк на вводе от пользователя, вторая - бряк на адресе параметра, для которого нужно сделать чит. Соответсвенно, если есть проблемы с созданием чита, то нужно исследовать этот маршрут...

В меню "Файл" есть опция генерации трейнера... Какие у тебя могли возникнуть трудности? очень странно