Dino

с D3D тестом у тебя все ОК . Думаю, проблема именно в хуке.

для дальнейшего анализа слишком мало кода

крашить в том месте может только в случае IsBadReadPtr(d3dDevicee,4) == true, от сюда вывод, что CreateDevice у тебя отрабатывает коряво. И вообще где все проверки? а то у тебя код как-то линейно выполняется, будь что будет .. суть этого цикла вообще не понял for (int i = 0; i < 4; i++) { vtableFrag[i] = vtablePtr[i + 6]; }

Мне кажется либо память не выделяется для записи, либо ты пытаешься читать невалидный адрес(с таким кол-вом итераций это вполне вероятно)

То что ты перечислил должно защищать только от Windows Dbg Это называется паттерн. Можно. Гугли "сканер сигнатур".

Хуки которые снимал - не помнишь, название игры - не скажешь, элементарно скинуть текст ошибки - не можешь. Слишком мало информации для оказания помощи. Без бряков искать цепочку указатели это мудацтво. В крайнем случае можешь воспользоваться встроенным PointerScan, но он неточный, жрет много ресурсов и долгий. Поснимал несколько раз дампы памяти? А какова вероятность что часть поинтеров не попало в твой дамп? Или ты считаешь что поинтеры лежать всегда друг за другом?:D Да даже если и лежали бы, то ты этого все равно не смог узнать. Можно еще сдампить весь процесс при помощи того же PeTools, затем загнать этот дамп в IDA Pro(тк у нее есть фишка - показывает цепочку вызовов функций), но для этого тебе все равно нужно знать адрес конечной инструкции, которая пишет в твой адрес. Это очень трудоемкий процесс, тк нужно все регистры и стек в голове держать.

control_getCaption строку же возвращает

Veh Debugger не может не работать, но с ним могут возникнуть пару нюансов. Для работы он должен загрузить свой модуль в адресное пространство игры, а затем уже проинициализироваться, этого не случится если : a) В игре установлены хуки(как ты уже подметил) на такие функции как LoadLibrary, LoadLibraryEx, LdrLoadDll, в этом случае нужно вернуть оригинальные байты пролога, в общем то ничего сложного.. если конечно в игре не стоит контроль за целостностью памяти б) Защита игры мониторит загруженные в нее модули и в случае обнаружения постороннего - бан/вылет и все в этом духе.

у тебя Veh Debugger палится игрой?

Заморозку нецелесообразно использовать в данном случае, тк получается что один поток (игровой) пишет 1, а другой 0 (CEшный) и они друг друга перебивают. Заморозка в СЕ это ничто иное как зацикленная запись указанного значения в указанную ячейку памяти в адресном пространстве указанного процесса) . Наиболее подходящее и простое решение это заNOPать инструкцию, которая пишет по этому адресу.

Передаешь адрес переменной, затем в потоке приводишь к нужному типу и разыменовываешь. Код бред, читай MSDN

void my_thread(void* pParams) { } void main() { struct arglist { int a; } ; arglist err; err.a = 100; _beginthread( my_thread,0,&err); }