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. Ключ к решению задачи - точное знание деталей. Я бы помог, но у меня нет столько экспертизы в практическом плоскости, могу лишь играть роль "провидца" )))
Hey! I like your way of thinking, it's very clear and logical.
However, transferring EOP onto M2EX wouldn't be easy. The retail and M2EX exes barely have anything in common in terms of the machine code layout. M2EX is a 64-bit EXE built on AVX2, retail is 32-bit on SSE2. And a significant part of the code isn't the same either (I have modified it).
t1aro
alZarif
Dr.Schmeisser
KhanBagatur
gurvinek2005
Crusader556
Haktar
Mady
Valyrian_Legionnaire
DinarMayor
Corrector
kosak4
Farin Frostgeir
