Патчинг L2.exe

[Zubastic]

Собственно решил перенести свои правки из хексинга в свою 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, то все меняется нормально. Интересно в чем проблема...

[n3k0nation]

FlushInstructionCache?

[Zubastic]

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, то проблема пропала

[nn03]

Неа, остальные байтики рядом меняет, а один нет 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, то проблема пропала

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

[Zubastic]

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

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

[Aquanox]

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

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

[doesitmatter]

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/en/...anual.html)

[Zubastic]

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

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

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

[n3k0nation]

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



(https://www.intel.com/content/www/us/en/...anual.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.

[doesitmatter]

Code segment != virt adr

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

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

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

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

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

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 – вряд ли…