AkaProc:

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

Полностью согласен, но с одним замечанием: Важно и наличие опыта анализа кода без исходников.

Маловероятно, что защита программы "размазана" по коду(если да, то несколько очень веселых месяцев Вам гарантировано), также маловероятно, что вся защита построена на одном:

The IsDebuggerPresent function indicates whether the calling process is running under the context of a debugger.
BOOL IsDebuggerPresent(VOID)

.

Обычно создаются отдельные библиотеки защищающие программу - смотрите первым делом, импорт библиотек и функций(для информации, что искать:СТАТЬИ - устройство защит и их обход, у К.Касперски, много таких). Библиотеки можно подгрузить ещё и с помощью LoadLibrary - тоже смотрим на код, где она есть и что грузит.

Программа общается с сетью, это ещё одно уязвимое программы и защиты, обычно эти функции находятся в NETAPI32. Находя участки с этими функциями Вы можете проконтролировать как программа работает, что где берет, что куда отправляет, а значит:

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

совсем рядом.

Не знаю, игрушка делает "сохраненки" на диск, если да, то соответствующие функции(их наличие) помогут добратся Вам до различных свойств персонажа.

Зенченко Константин Николаевич, Большое спасибо за Ваш отклик и информацию, которую Вы мне дали! Она мне очень пригодится.

Не знаю, игрушка делает "сохраненки" на диск, если да, то соответствующие функции(их наличие) помогут добратся Вам до различных свойств персонажа.

Про сохранения знаю, но у меня сетевая игра.Моя сетевая игра не оставляет сохранений.

Про сохранения знаю, но у меня сетевая игра. Моя сетевая игра не оставляет сохранений.

Как Вы думаете, информация о текущем персонаже в сетевой игре хранится в другом месте, отличном от персональной игры?

Я всегда думал, что в оперативной памяти. Разве нет ? Можете подробнее с этого момента ?

AkaProc:

Я всегда думал, что в оперативной памяти

Правильно. Вот представьте, что:

CALL Get...(чего там),a,b,c
где
Get...(чего там) - любая функция API, которая чего-то, где-то и сколько-то берет и не важно что именно.
a - указатель на открытый девайс
b - указатель на буффер
c - количество байт в доступном буффере

где-то в области данных программы(а может и нет) в оперативной памяти есть такие строчки

Угадайте если это есть в оперативной памяти, то возможно ли посмотреть что именно там есть и кто именно, приблизительно как и Get... обращается к нашему участку: b. Т.е. где-то там есть код: CALL Calc..,b,cc или другими словами: что-то будет работать с участком памяти, который мы контролируем и как-то обрабатывать.
Что смотреть и как, зависит, от того как организовано хранение этих самых персонажных данных.

Звучит интересно... я тут вот, чего подумал... А, может, поискать количество патронов с помощью ArtMoney, затем найти эту же ячейку в отладчике и поставить на нее точку останова на обращение ? Может быть, тут мне удастся выяснить, какая процедура обращается к ней ? Как Вы думаете ?

AkaProc:

А, может, поискать количество патронов с помощью ArtMoney, затем найти эту же ячейку в отладчике и поставить на нее точку останова на обращение ? Может быть, тут мне удастся выяснить, какая процедура обращается к ней ?

Основное Вы поняли. Единственное замечание: нужно контролировать: не одну ячейку, а диапозон ячеек, т.к. именно он представляет собой профиль текущего персонажа. Обратите внимание на изменения происходящие при смене текущего оружия, вполне возможно, что некоторое количество байт копируется в определенный участок памяти из места, где расположено имеющееся в наличии оружие, т.к. одним из параметров стрелкового оружия есть - количество выстрелов в минуту. Хотя возможно, что изменяется только указатель на него.

Большое спасибо за совет!
Я заметил интересную вещь: как только я сменил оружие (!) Внимание (!) у меня обнулились не только 4 байта, отображающие кол-во патронов, но и еще 8 байт, которые идут после них.
Когда я заменил оружие и вычислил ячейки, хранящие кол-во патронов, то они были не далеко от тех, что хранили значение патронов предыдущего оружия. (!)
Насчет копирования не уверен - это проверить очень трудно, а порой почти невозможно...
Вы когда-нибудь работали с OllyDBG ?

AkaProc:

Вы когда-нибудь работали с OllyDBG ?

Странный вопрос к одному из ассемблерщиков портала.

Я заметил интересную вещь: как только я сменил оружие (!) Внимание (!) у меня обнулились не только 4 байта, отображающие кол-во патронов, но и еще 8 байт, которые идут после них.
Когда я заменил оружие и вычислил ячейки, хранящие кол-во патронов, то они были не далеко от тех, что хранили значение патронов предыдущего оружия. (!)

Посмотрите к примеру вопрос № 179396 или этот код с ракетами и взрывами
[code h=200]locals @@
model tiny,c
.code
.186
;структура объекта
AirPlane struc
next dw ?;указатель на следующий объект
;изображение
image dw ?;указаттель на рисунок объекта
sz_X dw ?;размер рисунка по горизонтали
sz_Y dw ?;размер рисунка по вертикали
;высисляется один раз при рисовании
buffer dw ?;адрес видеобуфера для Show и Hide
;положение объекта
;координаты:
X dw ?;горизонталь
Y dw ?;вертикаль
d_X dw ?;приращение гoризонтальное
d_Y dw ?;приращение вертикальное
;методы:
methodS dw ?;п/п-мма рисования объекта
methodH dw ?;п/п-мма стирания объекта
methodM dw ?;п/п-мма перемещения объекта
AirPlane ends
;коди управляющих клавиш
keyE equ 01h
keyS equ 39h
keyU equ 48h
keyD equ 50h
keyL equ 4Bh
keyR equ 4Dh
;размер экрана
MaxY equ 200
MaxX equ 320
TimeOut equ 9000
NumberMissile equ 10
org 100h
begin: mov ax , 13h
int 10h
;читаем старый и ставим свой обработчики
mov ax , 3509h
int 21h
mov old09o , bx
mov old09s , es
mov ax , 2509h
mov dx , offset new09
int 21h
;видеобуфер
mov ax , 0A000h
mov es , ax
cld
;
;настраиваемся на объекты
mov bx , offset obj_A
;основной цикл программы
Main_Loop: CALL MainLoop , methodS
call Delay
CALL MainLoop , methodH
call CheckKey
CALL MainLoop , methodM
call CheckObj
cmp byte ptr DataKey [ keyE ] , 1
jnz Main_Loop
;выход в DOS
mov ax , 2509h
mov dx , old09o
mov bx , old09s
mov ds , bx
int 21h
int 20h
;основной цикл опроса объектов
MainLoop proc callMethod:word
push bx
;загружаем смещение на текущий метод
@@AA: mov si , callMethod
;считываем адрес текущего изображения
mov ax , [ bx ].image
or ax , ax
jz @@BB
;вызываем текущий метод
call [ bx + si ]
;переходим к следующему объекту
@@BB: mov bx , [ bx ].next
or bx , bx
;пока ВХ - не ноль - повторяем
jnz @@AA
pop bx
ret
MainLoop endp
;тут сами объекты
obj_A AirPlane <offset obj_B, offset img_A , sz_img_A_x , sz_img_A_y , ? , 260 , 150 , 0 , 0 , offset Show , offset Hide , offset Move>
obj_B AirPlane <offset obj_C , offset img_B , sz_img_B_x , sz_img_B_y , ? , 010 , 010 , 0 , 1 , offset Show , offset Hide , offset Move>
obj_C AirPlane <offset obj_D , offset img_B , sz_img_B_x , sz_img_B_y , ? , 050 , 040 , 0 , 1 , offset Show , offset Hide , offset Move>
obj_D AirPlane <offset obj_E , offset img_B , sz_img_B_x , sz_img_B_y , ? , 090 , 070 , 0 , 1 , offset Show , offset Hide , offset Move>
obj_E AirPlane <offset obj_F , offset img_B , sz_img_B_x , sz_img_B_y , ? , 130 , 040 , 0 , 1 , offset Show , offset Hide , offset Move>
obj_F AirPlane <offset obj_G , offset img_B , sz_img_B_x , sz_img_B_y , ? , 170 , 010 , 0 , 1 , offset Show , offset Hide , offset Move>
;резервируем память для новых объектов
obj_G label word
rept NumberMissile
obj_Adr = $ + SIZE AirPlane
AirPlane < obj_Adr , 0 , 0 , 0 , 0 , 0 , 0 , 0 ,0 , 0 , 0 , 0 >
endm
;последний обьект
StopWord AirPlane < 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 ,0 , 0 , 0 , 0 >
;тут типа спрайты
img_A db 0,0,0,0,0,0,0,0,0,9,0,0,0,0,0,0,0,0,0
sz_img_A_x equ $ - img_A
db 0,0,0,0,0,0,0,0,9,9,9,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,9,9,9,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,9,7,9,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,9,9,7,9,9,0,0,0,0,0,0,0
db 0,0,0,0,0,0,9,9,7,7,7,9,9,0,0,0,0,0,0
db 0,0,0,0,0,9,9,9,7,9,7,9,9,9,0,0,0,0,0
db 0,0,0,0,9,9,9,9,9,9,9,9,9,9,9,0,0,0,0
db 0,0,0,9,9,9,9,9,9,9,9,9,9,9,9,9,0,0,0
db 0,0,9,9,9,9,9,9,9,8,9,9,9,9,9,9,9,0,0
db 0,9,9,9,9,9,9,9,9,8,9,9,9,9,9,9,9,9,0
db 9,9,9,9,9,9,4,4,9,8,9,4,4,9,9,9,9,9,9
db 0,0,0,0,0,0,4,4,0,8,0,4,4,0,0,0,0,0,0
sz_img_A_y equ ($ - img_A) / sz_img_A_x
;бомбандирощик
img_B db 0,0,0,0,0,0,0,0,0,0,0,0,8,0,0,0,0,0,0,0,0,0,0,0,0
sz_img_B_x equ $ - img_B
db 0,0,0,0,0,0,0,0,7,7,7,7,8,7,7,7,7,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0,7,7,7,8,7,7,7,0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0,0,0,7,8,7,0,0,0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0,0,0,7,7,7,0,0,0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,0,0,0,0,0
db 0,0,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,0,0
db 7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7
db 7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7,7
db 0,0,0,0,0,0,7,0,0,0,0,7,7,7,0,0,0,0,7,0,0,0,0,0,0
db 0,0,0,0,6,6,6,6,6,0,0,7,7,7,0,0,6,6,6,6,6,0,0,0,0
db 0,0,0,0,0,0,0,0,0,0,0,7,9,7,0,0,0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0,0,0,7,9,7,0,0,0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0,0,0,7,7,7,0,0,0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0,0,0,0,7,0,0,0,0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0,0,6,6,6,6,6,0,0,0,0,0,0,0,0,0,0
sz_img_B_y equ ($ - img_B) / sz_img_B_x
;ракета
img_C db 00,15,00
sz_img_C_x equ $ - img_C
db 15,15,15
db 00,15,00
db 00,15,00
db 15,12,15
db 00,12,00
sz_img_C_y equ ($ - img_C) / sz_img_C_x
;взрыв
;первый кадр
img_D db 0,0,0,0,0,0,0,0,0
sz_img_D_x equ $ - img_D
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,1,0,0,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
sz_img_D_y equ ($ - img_D) / sz_img_D_x
sz_img_D_z equ $ - img_D
;второй кадр
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,0,1,1,1,0,0,0
db 0,0,0,1,2,1,0,0,0
db 0,0,0,1,1,1,0,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
;третий кадр
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,1,1,1,1,1,0,0
db 0,0,1,2,2,2,1,0,0
db 0,0,1,2,3,2,1,0,0
db 0,0,1,2,2,2,1,0,0
db 0,0,1,1,1,1,1,0,0
db 0,0,0,0,0,0,0,0,0
db 0,0,0,0,0,0,0,0,0
;четвертый кадр
db 0,0,0,0,0,0,0,0,0
db 0,1,1,1,1,1,1,1,0
db 0,1,2,2,2,2,2,1,0
db 0,1,2,3,3,3,2,1,0
db 0,1,2,3,4,3,2,1,0
db 0,1,2,3,3,3,2,1,0
db 0,1,2,2,2,2,2,1,0
db 0,1,1,1,1,1,1,1,0
db 0,0,0,0,0,0,0,0,0
;пятый кадр
db 1,1,1,1,1,1,1,1,1
db 1,2,2,2,2,2,2,2,1
db 1,2,3,3,3,3,3,2,1
db 1,2,3,4,4,4,3,2,1
db 1,2,3,4,5,4,3,2,1
db 1,2,3,4,4,4,3,2,1
db 1,2,3,3,3,3,3,2,1
db 1,2,2,2,2,2,2,2,1
db 1,1,1,1,1,1,1,1,1
;шестой кадр
db 2,2,2,2,2,2,2,2,2
db 2,3,3,3,3,3,3,3,2
db 2,3,4,4,4,4,4,3,2
db 2,3,4,5,5,5,4,3,2
db 2,3,4,5,6,5,4,3,2
db 2,3,4,5,5,5,4,3,2
db 2,3,4,4,4,4,4,3,2
db 2,3,3,3,3,3,3,3,2
db 2,2,2,2,2,2,2,2,2
;седьмой кадр
db 3,3,3,3,3,3,3,3,3
db 3,4,4,4,4,4,4,4,3
db 3,4,5,5,5,5,5,4,3
db 3,4,5,6,6,6,5,4,3
db 3,4,5,6,7,6,5,4,3
db 3,4,5,6,6,6,5,4,3
db 3,4,5,5,5,5,5,4,3
db 3,4,4,4,4,4,4,4,3
db 3,3,3,3,3,3,3,3,3
;восьмой кадр
db 4,4,4,4,4,4,4,4,4
db 4,5,5,5,5,5,5,5,4
db 4,5,6,6,6,6,6,5,4
db 4,5,6,7,7,7,6,5,4
db 4,5,6,7,8,7,6,5,4
db 4,5,6,7,7,7,6,5,4
db 4,5,6,6,6,6,6,5,4
db 4,5,5,5,5,5,5,5,4
db 4,4,4,4,4,4,4,4,4
img_D_a equ ( $ - img_D) / sz_img_D_z
;последний кадр
db 5,5,5,5,5,5,5,5,5
db 5,6,6,6,6,6,6,6,5
db 5,6,7,7,7,7,7,6,5
db 5,6,7,8,8,8,7,6,5
db 5,6,7,8,9,8,7,6,5
db 5,6,7,8,8,8,7,6,5
db 5,6,7,7,7,7,7,6,5
db 5,6,6,6,6,6,6,6,5
db 5,5,5,5,5,5,5,5,5
;данные для обработчика клавиатуры
old09o dw ?
old09s dw ?
DataKey db 256 dup(0)
;обработчик контролера клавиатуры
new09: pusha
in al , 60h
xor bx , bx
mov bl , al
mov byte ptr cs:DataKey[ bx ] , 1
xor bl , 80h
mov byte ptr cs:DataKey[ bx ] , 0
in al , 61h
push ax
or al , 80h
out 61h , al
pop ax
out 61h , al
mov al , 20h
out 20h , al
popa
iret
;подпрограмма рисования объекта
Show proc
mov ax , MaxX
xor dx , dx
mul [ bx ].Y
add ax , [ bx ].X
mov [ bx ].buffer , ax
call Draw , [ bx ].image , [ bx ].sz_X , [ bx ]. sz_Y , [ bx ].buffer
ret
Show endp
;подпрограмма стирания объекта
Hide proc
call Draw , 0 , [ bx ].sz_X , [ bx ]. sz_Y , [ bx ].buffer
ret
Hide endp
;рисование прямоугольного спрайта
Draw proc img:word , img_X:word , img_Y:word , buff:word
mov si , img
mov di , buff
;внешний цикл по строкам
@@AA: push di
mov cx , img_X
;внутренний цикл в строке
@@BB: xor al , al
or si , si
jz @@CC
;ноль - стрираем пиксель
lodsb
or al , al
jnz @@CC
;ноль - повторяем пиксель на экране
mov al , es : [ di ]
@@CC: stosb
loop @@BB
;переходим на новую строку
pop di
add di , MaxX
dec img_Y
jnz @@AA
ret
Draw endp
;подпрограмма измененния координат начала спрайта
Move proc
call Control , y , [ bx ].d_y , [ bx ].sz_Y , MaxY
call Control , x , [ bx ].d_x , [ bx ].sz_X , MaxX
ret
Move endp
;контролируем выход за пределы экрана
Control proc value_A:word , value_B:word , value_C:word , value_D:word
mov si , value_A
mov ax , [ bx + si ]
add ax , value_B
mov cx , value_D
sub cx , value_C
cmp ax , cx
jae @@AA
mov [ bx + si ] , ax
ret
;отдельный контроль для бомбера
@@AA: cmp [ bx ].image , offset Img_B
jnz @@BB
xor dx,dx
div cx
mov [ bx + si ] , dx
ret
;отдельный контроль для ракеты
@@BB: cmp [ bx ].image , offset Img_C
jnz @@CC
mov [ bx ].image , 0
@@CC: ret
Control endp
;проверка нажатых клавиш направления
CheckKey proc
call KeyControl , d_y , KeyU , KeyD
call KeyControl , d_x , KeyL , KeyR
;проверка клавиши пробел
cmp byte ptr DataKey [ KeyS ] , 1
jnz @@AA
call Set_Obj_C , [ bx ].X , [ bx ].Y
@@AA: ret
CheckKey endp
;контроль одного направления
KeyControl proc value_A:word , value_B:word , value_C:word
xor ax,ax
;получаем разницу двух разных направлений
mov si , value_C
mov al , DataKey [ si ]
mov si , value_B
sub al , DataKey [ si ]
;разширяем до слова и сохраняем
cbw
mov si , value_A
mov [ bx + si ],ax
ret
KeyControl endp
;задержка отображения на экране
Delay proc
mov cx,TimeOut
@@AA: push cx
mov cx,TimeOut
@@BB: loop @@BB
pop cx
loop @@AA
ret
Delay endp
;установка и открытие нового объекта
Set_Obj_C proc value_A:word , value_B:word
mov si , bx
;цикл проверкивсех объектов
@@AA: mov si , [si].next
or si , si
jz @@BB
;если объект открыт, пропускаем
cmp word ptr [ si ].image , 0
jnz @@AA
;записываем все важные значения ракеты
mov [ si ].image , offset img_C;
mov [ si ].sz_X , sz_Img_C_X;
mov [ si ].sz_Y , sz_Img_C_Y;
mov [ si ].methodS , offset Show;
mov [ si ].methodH , offset Hide;
mov [ si ].methodM , offset Move;
mov ax , value_A
add ax , 5
mov [ si ].X , ax;
mov ax , value_B
add ax , 3
mov [ si ].Y , ax;
mov [ si ].d_x , 0;
mov [ si ].d_y , -2;
@@BB: ret
Set_Obj_C endp
;проверяем бомбер и ракеты
CheckObj proc
push bx
;пока всё не проверим
@@AA: mov bx , [ bx ].next
or bx , bx
jz @@CC
;не бомбер - пропускаем
cmp [ bx ].image , offset Img_B
jnz @@AA
;бомбер - работаем
push bx
pop si
;пока не проверим все оставшиеся записи
@@BB: mov si , [ si ].next
or si , si
jz @@AA
;не ракета - пропускаем
cmp [ si ].image , offset Img_C
jnz @@BB
;начинаем проверку касания бомбера ракетой:
;горизонталь
mov ax , [ si ].X
sub ax , [ bx ].X
cmp ax , [ bx ].sz_X
ja @@BB
;вертикаль
mov di , ax
mov ax , [ si ].Y
sub ax , [ bx ].Y
cmp ax , [ bx ].sz_Y
ja @@BB
;считаем смещение на спрайте бомбера
mov cx , MaxX
xor dx , dx
mul cx
add di , ax
;проверяем бай если ноль то касания еще нет
cmp byte ptr Img_B [ di ] , 0
jz @@BB
;есть касание - превращаем ракету в взрыв
; mov [ bx ].d_y , 0;останавливаем бомбер
;заменяем изображение ракеты на взрыв и его характиристики
mov [ si ].image , offset Img_D
mov [ si ].sz_X , sz_img_D_x
mov [ si ].sz_Y , sz_img_D_y
;ставим значения для обработчика взрыва
mov [ si ].d_X , bx
mov [ si ].d_Y , img_D_a
;новые координаты ракеты
sub [ si ].X , 5
sub [ si ].Y , 5
;заменяем метод обработки взрыва
mov [ si ].methodM , offset Boom
jmp short @@AA
@@CC: pop bx
ret
CheckObj endp
;рисуем взрыв
Boom proc
;проверка фазы рисунка
mov di , [ bx ].d_X
or di , di
jz @@BB
;первая фаза рисуем на фоне самолета
add [ bx ].image , sz_img_D_z
dec [ bx ].d_Y
jnz @@AA
;достигли второй фазы
mov [ di ].image , 0
mov [ bx ].d_X , 0
mov [ bx ].d_Y , img_D_a
@@AA: ret
;вторая фаза
@@BB: sub [ bx ].image , sz_Img_D_z
dec [ bx ].d_Y
jnz @@AA
mov [ bx ].image , 0
ret
Boom endp
end begin[/code]
В исходниках есть комментарии, при анализе чужих программ их не будет
К примеру там есть такие строки:

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

Да уж... становится все интересней. :)

Ну, да... Я все так примерно и представлял и судя по показаниям редактора памяти все выглядит примерно так, как показано в той теме. Судя по моим исследованиям читов, которые у меня есть - они не изменяют характеристики оружия, они вызывают процедуру, которая отвечает за выстрел и делают это по нажатию на ЛКМ. Причем, делают они это даже тогда, когда я сижу в меню, т.е. получается так, что я сижу в меню и стреляю. Я нашел адрес кол-ва патронов, но исследование соседних байт ничего не выявило. Меня интересует даже больше не это, а та процедура, которая обращается к ячейке с кол-вом патронов. Не знаете, как ее можно вычислить ? Мне кажется, так: поставить точку останова на обращение к этой ячейке и следить за значением в регистре IP. Но тут есть одна проблема: игра "зависает", если срабатывает точка останова и получается, что ее можно "отвиснуть" только нажав F9, предварительно, через диспетчер задач, переключившись на отладчик. Может быть, если я подключу второй монитор - это поможет ? Т.е. на одном монике игра, на другом отладчик.А как Вы думаете ?

AkaProc:

Мне кажется, так: поставить точку останова на обращение к этой ячейке и следить за значением в регистре IP. Но тут есть одна проблема: игра "зависает", если срабатывает точка останова и получается, что ее можно "отвиснуть" только нажав F9, предварительно, через диспетчер задач, переключившись на отладчик. Может быть, если я подключу второй монитор - это поможет ? Т.е. на одном монике игра, на другом отладчик. А как Вы думаете ?

Да нужно смотреть на IP, т.к. именно этот код обращается к контролируемой ячейке.
Игра не зависает, произошло событие, процессор передал управление на отладчик, а игрушка останавливается. Нажимая F9 Вы даете команду отлачику передать управление игре.
Второй монитор возможно поможет, но я в таком режиме ещё не работал.

Игра не зависает, произошло событие, процессор передал управление на отладчик, а игрушка останавливается. Нажимая F9 Вы даете команду отлачику передать управление игре.
Второй монитор возможно поможет, но я в таком режиме ещё не работал.

Да, я это и имел ввиду, поэтому и заключил слова "зависает" и "отвисает" в кавычки.Второй монитор не понадобился, т.к. эта подпрограмма обращается к этой ячейке не один раз, а много. Поэтому есть возможность сначала приостановить при обращении к ячейке, затем дать команду на свертывание и опять передать управление на игру. Когда она опять обратится к нужной ячейке, то она прервется уже будучи свернутой. Так, что второй монитор и не понадобился. :)
Я так понимаю, я попал в процедуру обработки события нажатия на клавишу мыши... причем, попал я в какую-то подпрограмму... соответственно, мне надо выйти из всех этих подпрограмм и очутиться в основном модуле FEARMP, где расположена основная процедура, которая и производит вызов процедуры выстрела... Сейчас я установил контрольную точку на место в процедуре, которая отвечает за выстрел...
У Вас есть какие-нибудь мысли на эту тему ?

AkaProc:
Мыслей никаких, т.к. не знаю устройства этой игры.

Но о том как устроем DOOM(помните такой) можно почитать в книге Как самому создать трехмерную игру : Хонич А.

AkaProc:
а почему вы решили что нужные данные находятся в статической памяти?
если игра писалась на С++, то скорее всего она имеет объектную структуру
и память для объекта с патронами и т.д. будет выделяться в куче
т.е. каждый раз адрес виртуальной памяти будет немного другой

Да, каждый раз адрес ячейки со значением патронов немного разный, но не сильно: адреса всегда начинаются с 09...
А я разве говорил, что нужные данные находятся в статической памяти... ? Странно... по крайней мере, я никогда не имел это ввиду...

Alex_S:

а почему вы решили что нужные данные находятся в статической памяти?

Никто и не говорил, что это статическая память с фиксированным адресом.

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

Если программа написана на любом ЯВУ, то вполне возможно, что эти данные хранятся даже в стеке, но в любом случае:

в оперативной памяти

Каждый раз при вызове какой либо функции, ей будет передаватся указатель на определенным образом организованный участок памяти, в котором каждый параметр имеет строго определенное смещение относительно этого указателя. А сама функция работает с фиксированным смещением относительно указателя.

AkaProc:

Как Вы думаете, информация о текущем персонаже в сетевой игре хранится в другом месте, отличном от персональной игры?

Если Вы об этом, то подразумевалось, что:

Не знаю, игрушка делает "сохраненки" на диск, если да, то соответствующие функции(их наличие) помогут добратся Вам до различных свойств персонажа.

Соответсвующие функции (WriteFile, ReadFile) будут работать с определенной областью памяти(смотрим сохраняемые в стек значения), в которой хранится информация о персонаже, возможно даже в закодированом виде. После того как информация считана с диска, она должна быть обработана(возможно и раскодирована, т.е. будет вызыватся какой либо декодер - получим код декодера найдем и алгоритм кодировки), т.е. вызыватся какой либо код(если его проанализировать, то станет известно, что на что влияет). Сетевая игра - аналогично, т.к. свойства и методы объекта-персонажа в сетевой игрушке совпадают с персональной игрой и обрабатываются одним и тем же кодом. Важно не то, где хранятся данные о персонаже, важно какой код с ними работает и как. А когда известно как этот код работает, то всегда можно "сказать" ему как нужно правильно работать.

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

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

Дело в том, что если мы знаем, где хранятся данные, то будет проще выйти на декодер. :)

Соответсвующие функции (WriteFile, ReadFile) будут работать с определенной областью памяти(смотрим сохраняемые в стек значения), в которой хранится информация о персонаже, возможно даже в закодированом виде. После того как информация считана с диска, она должна быть обработана(возможно и раскодирована, т.е. будет вызыватся какой либо декодер - получим код декодера найдем и алгоритм кодировки), т.е. вызыватся какой либо код(если его проанализировать, то станет известно, что на что влияет). Сетевая игра - аналогично, т.к. свойства и методы объекта-персонажа в сетевой игрушке совпадают с персональной игрой и обрабатываются одним и тем же кодом. Важно не то, где хранятся данные о персонаже, важно какой код с ними работает и как. А когда известно как этот код работает, то всегда можно "сказать" ему как нужно правильно работать.

Большое спасибо, приму к сведению!А то чего-то сразу не понял. :)

AkaProc:

Дело в том, что если мы знаем, где хранятся данные, то будет проще выйти на декодер.

Ещё проще, исходные коды у автора попросить.


Основной метод анализа кода: ищется уязвимое место в программе(диск, реестр, сеть, ввод и вывод сообщений и т.д.), определяются функции которые с ним работают, т.е. код. Ну а дальше: шаг №N - код => данные => анализ, шаг №N+1 - данные => код => анализ, на каждом шаге получается нужная информация.

Почитайте статью Исследование программ, автор Крис Касперски. Это фрагмент его книги "Техника отладки программ без исходных кодов"(isbn 5-94157-229-8) - советую купить.
Описано множество механизмов защиты и методы их обхода. Книга с диском, на котором под каждый метод есть, написаная автором учебная программа crackme.

Спасибо за информацию! :)

Основной метод анализа кода: ищется уязвимое место в программе(диск, реестр, сеть, ввод и вывод сообщений и т.д.), определяются функции которые с ним работают, т.е. код. Ну а дальше: шаг №N - код => данные => анализ, шаг №N+1 - данные => код => анализ, на каждом шаге получается нужная информация.

Да, именно так я и делаю.Хех, вместо того, чтобы попасть в характеристики оружия, я попал в характеристики персонажа, а точнее в код, который с ними работает.Интересно так: научился делать стрельбу без перезарядки, менять его позу, т.е. он держит автомат или он его опустил, или он держит автомат только в одной руке.Классно!В принципе, я тут не вижу каких-либо очень мощных механизмов защиты, а точнее их тут нет вовсе. Тем не менее, статью и книгу обязательно прочитаю.Хотя... сейчас сам вожусь и мне эта забава очень нравится.Тут, собственно, надо прикладывать логику и все. :)
Ну, а то, что исходные коды у автора можно попросить я не сомневаюсь, только, даст ли он их ? :)

AkaProc:

Тут, собственно, надо прикладывать логику и все.

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

Ну, а то, что исходные коды у автора можно попросить я не сомневаюсь, только, даст ли он их ? :)

-Здравствуй, Автор, я тут твой код ломаю,

я тут не вижу каких-либо очень мощных механизмов защиты, а точнее их тут нет вовсе.

, за защиту своего кода ты заплатил лишние "бабки", дай свои исходники, а то мне напрягатся лень.

научился делать . . .

Вы добрались к проофилю персонажа(каждый байтик, если не битик, что-то значит), именно там должно всё быть: имеющееся оружие, режим этого оружия, количество патронов именно для этого оружия, если не всамом профиле, то там должны быть указатели на них(профили оружия). Нужно только понять, как автор все это организовал(связи(указатели), значения и т.д.).
Успехов Вам в иследованиях, но помните, что есть ещё и законы.
Удачи!

за защиту своего кода ты заплатил лишние "бабки", дай свои исходники, а то мне напрягатся лень.

Я имел ввиду, что на тех участках кода, где я копаюсь, нет никакой защиты: все довольно просто.Защита есть в том коде, который, например, отправляет данные по сети, т.е. он делает закрытый ключ шифрования. Может, еще где-то есть защита... У меня складывается впечатление, что кол-во патронов в обойме хранится в характеристиках персонажа, а само кол-во патронов хранится в другой ячейке, которую можно найти, просто сложив кол-во патронов в обойме и запаске. :)
Кстати, а я занимаюсь незаконной деятельностью ?
Спасибо. :)

AkaProc:

Кстати, а я занимаюсь незаконной деятельностью ?

Вопрос сложный, все зависит от лицензионного соглашения, Ваших целей, Ваших действий и их последствий.
Статья 272 УК РФ. Неправомерный доступ к компьютерной информации

Да... интересно... Я так понимаю... вроде... ничего такого я не делаю...

AkaProc:
Правда?
Игра-клиент -> снифер -> анализ пакета -> подмена пакета -> Игра-сервер
Клиент-банк -> снифер -> анализ пакета -> подмена пакета -> Сервер-Банк
Найдите отличия.

В обоих случаях - Неправомерный доступ к информации.

Ваших целей, Ваших действий и их последствий

Чем крупнее последствия, тем сильнее Вас будут искать.

Чем крупнее последствия, тем сильнее Вас будут искать.

Ясненько... :)
Насчет неправомерного доступа к информации... не совсем согласен. :)

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