Форум администраторов игровых серверов

- Программирование / Programming (https://forum.zone-game.info/forumdisplay.php?f=98)

- - Патчинг L2.exe (https://forum.zone-game.info/showthread.php?t=42363)

Патчинг L2.exe

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

Код:

WriteProcessMemory(GetCurrentProcess(), dest, &src, countBytes, nullptr);

И так

Код:

        DWORD dwProtect = PAGE_READWRITE;

        VirtualProtect(dest, countBytes, dwProtect, &dwProtect);

        *((BYTE *)(dest)) = src;

        VirtualProtect(dest, countBytes, dwProtect, &dwProtect);

В итоге из 28 адресов, которые я патчу, 13 возвращают ошибку. Причем какой-либо закономерности я обнаружить не смог. WriteProcessMemory возвращает 1, но данные не меняет nichoci

Есть какие-либо идеи?

Добавлено через 11 минут
И еще кое что: если я изменяю память через Ollydbg, то все меняется нормально. Интересно в чем проблема...

Re: Патчинг L2.exe

FlushInstructionCache?

Re: Патчинг L2.exe

Цитата:

Сообщение от n3k0nation (Сообщение 426735)

FlushInstructionCache?

Неа, остальные байтики рядом меняет, а один нет nichoci
Т.е. меняю 10 байтов на 0x01, в итоге вижу такую картину:
0х01 0х01 0х01 0х01 0х01 0хFF 0х01 0х01 0х01 0х01 :)

Кстати как переаттачил дллку от l2.exe к nwindow.dll, то проблема пропала :)

Re: Патчинг L2.exe

Цитата:

Сообщение от Zubastic (Сообщение 426736)

мистика и нечего больее

Re: Патчинг L2.exe

Цитата:

Сообщение от nn03 (Сообщение 426737)

мистика и нечего больее

Это к адептам темной магии, мы так не работаем :)

Re: Патчинг L2.exe

Как вариант что-то использует эту область памяти... Есть ли возможность прицепить "железный" on-write breakpoint на этот участок памяти и попробовать поймать кто его изменяет после патчинга?

https://github.com/mmorearty/hardware-breakpoints

Re: Патчинг L2.exe

Цитата:

Сообщение от n3k0nation (Сообщение 426735)

FlushInstructionCache?

Бесполезно на X86 (по крайней мере, пока модифицируемый код имеет тот же виртуальный адрес, что и при исполнении):

Цитата:

11.6 SELF-MODIFYING CODE

A write to a memory location in a code segment that is currently cached in the processor causes the associated cache line (or lines) to be invalidated.

(https://www.intel.com/content/www/us...-1-manual.html)

Re: Патчинг L2.exe

Цитата:

Сообщение от Aquanox (Сообщение 426779)

Ничто ее не использовало. Почему так получается не знаю. Сейчас аттачусь к nwindow.dll и проблем не знаю :)

Re: Патчинг L2.exe

Цитата:

Сообщение от doesitmatter (Сообщение 426783)

Бесполезно на X86 (по крайней мере, пока модифицируемый код имеет тот же виртуальный адрес, что и при исполнении):

(https://www.intel.com/content/www/us...-1-manual.html)

Цитата:

11.6 SELF-MODIFYING CODE

A write to a memory location in a code segment that is currently cached in the processor causes the associated cache line (or lines) to be invalidated.

Code segment != virt adr
Патчинг кода из дллки или RemoteThread это иной сегмент кода, нежели ранинг уже пропатченого куска кода на клиенте. И вообще, в рамках одного модуля (PE) - сегменты могут различаться.
С учетом размера кешей современных процов - туда влезает далеко не один сегмент. Ну и ~~многопоточность~~многоядерность не забываем.

Цитата:

Particularly on x86 my guess that simple JMP just wont do it, since on modern processors there are branch predictors and optimizers that would "see" the code that your jump would target. Another scenario is when multiple CPU's are in play, and instruction cache has to be flushed from
both chips.

branch predictors -- в данном случае prefetch queue
Особенно актуально для RemoteThread.

Re: Патчинг L2.exe

Цитата:

Сообщение от n3k0nation (Сообщение 426803)

Code segment != virt adr

Конечно, это вообще разные понятия, но что это доказывает?

Цитата:

Сообщение от n3k0nation (Сообщение 426803)

Патчинг кода из дллки или RemoteThread это иной сегмент кода, нежели ранинг уже пропатченого куска кода на клиенте.

Не понял смысла этого предложения. "Патчинг это иной сегмент"?

Цитата:

Сообщение от n3k0nation (Сообщение 426803)

Ну и ~~многопоточность~~многоядерность не забываем.

Не забываем: кэши мультипроцессорной системе инвалидейтятся, конкретно у интел это вариация MESI: https://en.wikipedia.org/wiki/MESI_protocol

Цитата:

Сообщение от n3k0nation (Сообщение 426803)

branch predictors -- в данном случае prefetch queue
Особенно актуально для RemoteThread.

Intel Volume 3a, section 11.6, “Self Modifying Code”:

Цитата:

In addition, the P6 family and Pentium processors check whether a write to a code segment may modify an instruction that has been prefetched for execution. If the write affects a prefetched instruction, the prefetch queue is invalidated. This latter check is based on the linear address of the instruction.

Возможный вариант рассинхронизации, оттуда же:

Цитата:

Systems software, such as
a debugger, that might possibly modify an instruction using a different linear address
than that used to fetch the instruction, will execute a serializing operation, such as a
CPUID instruction, before the modified instruction is executed, which will automatically
resynchronize the instruction cache and prefetch queue.

Другой сценарий, в котором я могу представить проблемы: когда один процессор (ядро) модифицирует код, который уже исполняется другим процессором.

Небольшое исследование по теме с цитатами из 3a: http://blog.onlinedisassembler.com/blog/?p=133

Я, конечно, допускаю, что дело может быть в синхронизации, но зная X86 – вряд ли…