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

Проверочные байты


MasterGH

Рекомендуемые сообщения

Сравнение проверочных байт.

Русская версия CE на нашем сайте умеет генерировать возможную сигнатуру байт.

Красный – отличающиеся байты.

Голубой – сомнительные, которые могут поменяться со следующим патчем.

Жирный – подходящие для проверочных байт.

Некоторые области я не правильно закрасил, но смыл не особо теряется. Лень переделывать.

post-3-1294575029,34_thumb.gif

Некоторые выводы:

1. Этот участок кода не менялся разработчиками, его изменил компилятор, т.к. наблюдается строгая последовательность операторов.

2. Похожи первые байты главных операторов, различаются некоторые операнды, а некоторые операнды остаются под сомнением.

2. Могут меняться: размеры структур, некоторые регистры, операнды для push-ей,

3. Если push занимает один байт, то этот байт сомнительный и его не следует брать в цепочку проверочных байт.

Итак цепочка проверочных байт будет равна:

DisciplesIII.exe+2D13BA:>xxxxxxxx8Bxx3B91xxxxxxxx89xxxxxxYYxx8Bxx6Axx6Axx68xxxxxxxx68xx

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

Протестировано 4 версии игры. Все тесты успешны.

Ссылка на комментарий
Поделиться на другие сайты

  • 4 недели спустя...

Я покажу пример скрипта с проверочными байтами для версии CE 5.6.

/*
ManHant 2
Чит: на здоровье
MasterGH (c) 10.02.10*/

AOBSCAN(_adhealth,d8xxxxxxdfxxf6xxxx0fxxxxxxxxxx8bxxe8xxxxxxxx8bxxe8xxxxxxxxd9xxd8)

[ENABLE]
alloc(newmem,2048)
label(_originalcode)
label(_returnhere)

newmem:
mov [ebp+7c],(float)125
_originalcode:
fld dword ptr [ebp+7c]
push esi
fstp dword ptr [esp+10]
jmp _returnhere

_adhealth-8:
jmp newmem
nop
nop
nop
_returnhere:

[DISABLE]
_adhealth-8:
fld dword ptr [ebp+7c] // инструкция тип А - работает со здоровьем
push esi
fstp dword ptr [esp+10]
dealloc(newmem)

Информация по проверочным байтам.

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

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

CALL 4565455 (байт-код call брать можно, а вот байты адреса брать нельзя)

MOV [4565455] (байт-код mov брать можно, а вот байты адреса брать нельзя)

jmp 4565455

je short 4565455

И другие подобные инструкции со статическими адресами. Если соблюдать эти критерии, то трейнер должен работать с любым NoDVD или даже с локализацией игры. А также с «легкими» патчами для игры. Т.е. узнаваемость кода остаётся высокой.

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

MOV [ebx + 46] (байт-код mov брать можно, а вот байты смещения брать нельзя, они могут отличаться)

LEA [ebx + 46] (байт-код LEA брать можно, а вот байты смещения брать нельзя)

JMP [ecx+45]

СMP [ecx+45]

RET 0C // не проверенное предположение

Во всяком случае, надо полагаться на то что бы оставлять те байты, по которым выполняется уникальный алгоритм во всём адресном пространстве.

Ссылка на комментарий
Поделиться на другие сайты

  • 1 год спустя...

Форум уже существует уже второй год и где-то уже обсуждалось применении aobscan. Интересующиеся могут воспользоваться поиском. Эта функция появилась в CE 5.6. В новых версиях она осталась, а также у неё появились новые параметры в LUA-engine в версии CE 6.1 (пока официального реализа не было)

Об этой функции.

Эта функция сканирует память процесса. Если использовать в Автоассемблере версии больше 6.0, то сканирует ВСЮ память процесса. Если использовать в предыдущих версиях, то сканирует память тип которой указан в настройках. Это не всегда удобно, т.к. в настройках обычно не указано искать память executed и приходится лезть частенько в настройки и менять тип сканируемой памяти, чтобы поиск шёл быстрее когда executed сканировать не требуется. Как я уже писал в LUA-engine в CE 6.1 версии aobscan может иметь настройки сканируемой памяти и сканирование будет значительно быстрее. Но сейчас рассматриваем aobscan в автоассемблере.


[ENABLE]
aobscan(address1, 45xxxx45454545454545)
address1:
// ваш код


[DISABLE]

Здесь мы ищем первый адрес сигнатуры "45xxxx45454545454545". Адресов может найтись несколько, но будет возвращён только первый адрес. Если адрес не будет найден, то CE даст ошибку и скрипт не будет активирован.

Сигнатура "45xxxx45454545454545" взята для примера. Второй и третий её байт помечен "xx" это означает, что значение этих байт не важны для поиска. Таким образом если вы определили по многим экспериментам, что определенные байты не меняются, а другие меняются, то вы можете указать "сигнатуру байт" в aobscan чтобы найти адрес при каждом новом запуске игры.

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

По экспериментам с этими патчами я очень давно сделал такую картинку сравнений патчей.

84915865.gif

Как видно первые байты инструкций не всегда, но могут быть байтами сигнатуры. Я давно сделал в модификации CE 5.6 RUS 1.0, которую вы можете скачать на сайте, генерирование шаблона с сигнатурой типа этого:


aobscan(_faddress,d9xxxxxxxxxxxxd9xxd8xxdfxxf6xxxx75xxddxxebxxf6xxxx7axxd8)
alloc(_newmem,2048)
label(_returnhere)
label(_originalcode)

_newmem:
mov dword ptr [esi+00000ca4],3F800000
_originalcode:
fld dword ptr [esi+00000ca4]
jmp _returnhere

_faddress: // 00ADFCFD = GameDLL_x86.dll+50FCFD
jmp _newmem
nop
_returnhere:

[DISABLE]
aobscan(_faddress,90xxd9xxd8xxdfxxf6xxxx75xxddxxebxxf6xxxx7axxd8)

_faddress-5:
fld dword ptr [esi+00000ca4]

dealloc(_newmem)
[ENABLE] 

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

Но в большинстве игр под [DISABLE] ставить aobscan не требуется и как это сделать я пока не знал. И вот месяц назад я нашёл выход из этой ситуации на форуме CE. Ответ написал Дакр Байт - разработчик CE.


aobscan(_faddress,d9xxxxxxxxxxxxd9xxd8xxdfxxf6xxxx75xxddxxebxxf6xxxx7axxd8)
alloc(_newmem,2048)
label(_returnhere)
label(_originalcode)
label(_address)

_newmem:
mov dword ptr [esi+00000ca4],3F800000
_originalcode:
fld dword ptr [esi+00000ca4]
jmp _returnhere

_address:
_faddress: // 00ADFCFD = GameDLL_x86.dll+50FCFD
jmp _newmem
nop
_returnhere:

[DISABLE]
_address:
fld dword ptr [esi+00000ca4]

dealloc(_newmem)
[ENABLE] 

Как можно видеть нужно просто поставить две метки рядом друг с другом : _address и _faddress.

Как я уже отметил aobscan в CE 5.6 буть то русская или не русская версия ищет в памяти указанную в настройках. Если вы генерируете автономный трейнер, то, видимо, в трейнере зашиваются последние настройки типа памяти. В новых же версиях CE 6.0 и выше aobscan в автоассемблере "чешет" всю память процесса, тоже самое, видимо, касается и генерируемых трейнеров. Однако, если вы будите использовать aobscan в LUA-engine в CE 6.1 и выше версиях, то вы сможете настроить работу aobscan. Ну а самый главный вывод - aobscan повышает работоспособность вашего трейнера, но не на 100%... Вы можете найти сигнатуру кода, которая не будет изменяться на патчах, а также можете найти сигнатуру какой-то структуры с указателями, относящуюся например к вашему герою. Но возможны и случаи когда сигнатура вам не поможет. Например, новый патч поменял регистры в инструкциях или же поменял смещения.

Было:

mov eax, [ebx+10]

Стало:

mov edx, [ecx+10]

Или же было:

mov eax, [ebx+10]

Стало:

mov eax, [ecx+12]

Оба случая можно обработать автоматически с помощью LUA дизассемблера и ассемблера в новой пока не отреализиной версии CE 6.1 Альфа 8. Т.е. мы получим что-то типа автоинъекции по правилам, например, инъекции по правилу постоянного значения равному 1000. Эту штуку я делал на Дельфи для основных инструкций ассемблера и она работала. Было супер. Дальше её развивать не стал, т.к. пока много других забот. Ну, вроде, пока рассмотрел всё, что помню.

Всем желаю успехов!

Ссылка на комментарий
Поделиться на другие сайты

  • 4 месяца спустя...

В отладчиках обычно раскраска определённых байтов не предусмотрена.

Это не отладчик это текстовый редактор. Цвет текста я делал вручную.

Ссылка на комментарий
Поделиться на другие сайты

×
×
  • Создать...

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

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