Взлом движков M2:TW и RTW - REX/M2EX - Сообщество Империал

Взлом движков M2:TW и RTW - REX/M2EX

Базовая тема

Тема создана: 12 апреля 2026, 08:24 · Автор: bitterhowl

85 Страниц
« Первая
10
11
12
13
14
Последняя »

bitterhowl

Дата: 12 апреля 2026, 08:24

Движок REX/M2EX

Фанатское сообщество совершило революцию, теперь легендарные игры Rome Total War и Medieval II Total War работают на обновленном движке 64-бита без ограничений ресурсов ПК. Производительность выросла в несколько раз, было исправлено множество багов и убраны все ограничения для моддинга.

Ссылка на github: Для просмотра ссылки Зарегистрируйтесь
Discord разработчиков: Для просмотра ссылки Зарегистрируйтесь

Для просмотра ссылки Зарегистрируйтесь
Для просмотра ссылки Зарегистрируйтесь

Master_TW_DAR

Дата: 14 апреля 2026, 10:18

Цитата

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

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

Из собственного опыта прогулки по исходникам EOP, складывается общее понимание того, как устроен механизм "турбонаддува" геймплея Меди 2:

1. Путем исследования памяти системного процесса medieval2.exe/kingdoms.exe с помощью динамического отладчика обнаруживаются нужные регистры и значения регистров в машинном коде.
2. Библиотека EOP на уровне исходного кода осуществляет установку/подмену нужных значений в нужные регистры игрового процесса, когда данный процесс активируется из-под лаунчера EOP.
3. Функциональность Lua-скриптов EOP опирается на знание объявлений/определений библиотечных функций проекта EOP и потребляет эти функции, позволяя мододелу передавать нужные аргументы.

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

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

Проект EOP использует последний из вышеописанных подходов, но реализует данный подход путем смешивания традиционной техники и реверс-инженерии. Пожалуй, это единственный путь достижения приемлемого результата. Так как же быть, если мы захотим прикрутить Lua-скрипты EOP к "пропатченным" экзешникам ???

Скорее всего, самым простым способом будет следующий - заменить "бэкенд" игрового процесса.
Например, EOP использует родные экзешники CA для обхода лимитов, а теперь понадобится сделать переключатель на "пропатченные экзешники" коммьюнити.

Для этого потребуется как минимум:

1. Исследовать, совместимы ли потребляемые EOP регистры в памяти процесса с теми же самыми регистрами в памяти "пропатченного" процесса. Возможно, совместимость есть, но заниматься динамическим анализом процесса всё равно придётся - взять и прикрутить EOP к модифицированному экзешнику вряд ли получится без последствий.
2. На уровне исходного кода EOP написать новые реализации функций, принимающих участие в подмене значений регистров - если это действительно нужно, или же можно каким-то способом специализировать существующие реализации, например с помощью добавления новых параметров и так далее.
3. Подготовить нужные внешние интерфейсы для того чтобы мододелы могли переключать нужные реализации функции для использования фич EOP на пропатченном или неизменном экзешнике игры.

Концептуальный принцип очень похож на следующий: вы запускаете какую-нибудь старенькую игру, используя тот или иной графический рендерер (DirectX или OpenGL, например) - здесь же EOP будет потреблять ту или иную реализацию одного и того же игрового движка.

Резюмирую: если вам нужно перенести функционал EOP на взломанный экзешник Меди, потребуется реализовать поддержку данного экзешника на уровне исходного кода EOP.

Master_TW_DAR

Дата: 14 апреля 2026, 17:37

Камрады, дополнение к моему предыдущему посту.

Возможно ли распространить функционал новой проги по снятию лимитов на движок 1.5.0 (не стим). Вопрос из разряда теоретической части.

Да, можно, для этого потребуются знание матчасти и ещё вагон со всем остальным, чем должен обладать любой копатель Меди.

В данном случае попробую дать всем заинтересованным консультацию, в каком направлении я двигался бы для того чтобы решить данную задачу.
Сразу оговорка - могу ошибаться, у меня нет всей глубины знаний в данном вопросе, я пишу исходя из совокупного программистского опыта.

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

1. Нужно получить информацию о том, какие участки машинного кода классического/стимовского экзешника Меди подвергаются использованию в вызовах JIT-функций, вызываемых библиотечным кодом M2TWEOP. JIT - just-in-time - это простыми словами техника встраивания фрагментов машинного кода в некоторый код программы тем или иным способом (необязательно тоже машинный, это может быть промежуточное представление, но в нашем случае EOP использует услуги JIT-инструментарий для того чтобы встраивать нужный мододелу машинный код в машинный код, находящийся в памяти запущенного процесса). В идеале надо знать виртуальные адреса той или иной команды машинного кода в памяти запущенного процесса. EOP, предположительно, меняет аргументы в операндах машинных команд, но сами команды и их расположение должны оставаться по идее прежними. Важно выяснить, какие участки кода экзешника эксплуатируются функционалом EOP.

2. Нужно подвергнуть взломанный экзешник тому же самому динамическому анализа с помощью отладчика, как и в случае с M2TWEOP. Вероятно, следует проверить, эквиваленты ли выявленные в предыдущем шаги участки машинного кода - по структуре последовательности команд (вдруг хакнутый экзешник где-то вставляет инструкции переходов или что-то еще) и виртуальным адресам. Я не знаю, как лучше к этому подойти. Подобный анализ обычно выполняют с помощью продвинутых инструментов динамического анализа исполняемого кода - скорее всего можно как-то получить с помощью этих инструментов дампы содержимого памяти или ассемблерные листинги. Эти артефакты наверняка окажется полезными при сравнении кода девственного и хакнутого экзешников.

3. Только когда появится понимание, эквиваленты ли эксплуатируемые участки кода, можно приступать к реализации поддержки функций EOP для хакнутого экзешника. Здесь стоит обратиться к моему прошлому посту на данную тему.

Я не знаю всех технических деталей. Здесь нужно спрашивать конкретно по существу тех, кто имеет реальный опыт работы над пунктом № 1. Скорее всего, опять же я предполагаю, эксплуатируемый фичами EOP машинный код везде остается один и тот же, т.к. геймплей идентичен везде. Разница будет в виртуальных адресах машинных команд для разных экзешников. Нужно узнать эти технические детали и интегрировать полученное знание в исходный код библиотечных функций EOP любым удобным способом. Вроде это всё, что касается теории.

Сто процентов нужно спрашивать разработчиков EOP. Ключ к решению задачи - точное знание деталей. Я бы помог, но у меня нет столько экспертизы в практическом плоскости, могу лишь играть роль "провидца" )))

DinarMayor

Дата: 14 апреля 2026, 18:04

Seydlitz

DinarMayor, скажи, а EOP сверху на это прикрутить получится?

На данный момент нет, но вообще да. Возможно в будущем - посмотрим как там все будет.

АрАл

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

Это не прога, это новая версия игры(.ехе файл). Ее можно ставить и на Стим лицензию и на Стим пиратку. По идее и на дисковую сборку, если немного помудрить(я не пробовал пока). НО она не запуститься без запущенного Стима при условии что у вас есть купленная игра в вашей библиотеке в Стиме. Это сделано намеренно, автор написал почему. Технически, сделать без Стима, никаких сложностей нет, т.к. изначально оно работало и без него.

Master_TW_DAR

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

Это нам очень даже подходит, ибо у нас исходники.))) Я на второй странице писал про это. Может закинуть эту "предысторию" под спойлер что ли? Кто-нибудь?) У меня нет модерки тут.

Автор планирует внедрить подобный язык. Я забыл какой, но тоже что-то подобное. Но на самом деле, имхо, Луа было бы лучше, т.к. часть модмейкеров уже знаком с Луа. Но вообще было бы лучше сразу подружить новые ехе с ЕОП. Юней, автор ЕОП, писал что это возможно. Возможно сделать что-то универсальное, чтоб после каждой компиляции новой ехе игры не искать все адреса в ЕОП. Ещё в 2024 так-то думали/мечтали :0142:

-Добавлено-

DinarMayor

Я на второй странице писал про это. Может закинуть эту "предысторию" под спойлер что ли? Кто-нибудь?) У меня нет модерки тут.

Вот: Для просмотра ссылки Зарегистрируйтесь

Seydlitz

Дата: 14 апреля 2026, 18:37

DinarMayor 14 апреля 2026, 18:04

Ее можно ставить и на Стим лицензию и на Стим пиратку.

Я уже попробовал на стим-пиратку - безуспешно. Даже если переименовать M2EX.exe в medieval2.exe и запустить через файл, который дает обход пиратки, всё равно выскакивает окошко, что стим не запущен.
Если есть ссылка или торрент на стим-пиратку, с которой это работает - буду признателен!
:046:

DinarMayor

Дата: 14 апреля 2026, 18:45

Seydlitz

Я уже попробовал на стим-пиратку - безуспешно.

Ну я именно на нем и запускаю. А Стим запущен? А медь2 в Стиме куплена?) Я ведь ни раз уже писал об этом)

Как запустить M2EX.exe:
- установить M2EX.exe на сборку Стим лицензии или Стим пиратки
- запустить Стим
- у вас должна быть медь2 в вашем Стиме
- все, кайфуем

IL9MIM

Дата: 14 апреля 2026, 18:48

DinarMayor 14 апреля 2026, 18:45

Seydlitz

Я уже попробовал на стим-пиратку - безуспешно.

Ну я именно на нем и запускаю. А Стим запущен? А медь2 в Стиме куплена?) Я ведь ни раз уже писал об этом)

Как запустить M2EX.exe:
- установить M2EX.exe на сборку Стим лицензии или Стим пиратки
- запустить Стим
- у вас должна быть медь2 в вашем Стиме

Одно непонятно - если Медь куплена в Стиме, зачем тогда пиратка?

DinarMayor

Дата: 14 апреля 2026, 18:54

IL9MIM

Одно непонятно - если Медь куплена в Стиме, зачем тогда пиратка?

Если так хочется например)
Я поставил отдельно новую пиратку, чтоб на нем делать все, что связано с M2EX.exe. А на Стим лицензии у меня другие моды, работающие в основном на ЕОП. Я лишь написал, что можно и на пиратку установить.

Kelt881