infinity loop

Код (Text):

1.  
2. include '%fasm%/win64ax.inc'
3. section '.code' executable
4. start:
5.         sub rsp,8
6.  
7.         mov ecx,10
8. @@:
9.         invoke FindWindow,NULL,'Giglad - Unlicensed'
10.         mov [r],eax
11.         cmp eax,NULL
12.         jnz @f
13.         dec ecx
14.         cmp ecx,NULL
15.         jz exit
16.         invoke Sleep,300
17.         jmp @r
18. @@:
19.         invoke SendMessage,[r],WM_CLOSE,NULL,NULL
20. exit:
21.         invoke ExitProcess,NULL
22.  
23. section '.data' readable writeable
24.  
25.         a rb MAX_PATH
26.         b rb MAX_PATH
27.  
28.         r dd NULL
29.  
30.         x dd NULL
31.         y dd NULL
32.         z dd NULL

Не могу понять что не так? Когда окно есть, работает вроде, когда окна нет, уходит в вечный полёт.
Причём раньше этот кусок кода работал вроде бы в другой програме.

Хотелось бы ещё и запустить после выхода из цикла...

Код (Text):

1.  
2.         invoke SHGetSpecialFolderPath,NULL,a,CSIDL_PROGRAM_FILES,NULL
3.         invoke PathAppend,a,'Giglad'
4.         invoke PathAddBackslash,a
5.         invoke lstrcat,a,'Giglad.exe'
6.  
7.         invoke GetBinaryType,a,z
8.         cmp eax,NULL
9.         jz exit
10.  
11. ;;;; тут         invoke FindWindow,NULL,'Giglad - Unlicensed'
12.  
13.         invoke ShellExecute,NULL,NULL,a,NULL,NULL,SW_NORMAL

 

Для передачи параметров в x86_64 используются регистры в порядке rcx, rdx, r8, r9. После FindWindow в ecx не будет счетчика цикла. Используйте, скажем, r10.

Тем более, если из FindWindow в rcx вернется значение параметра, тогда ваш цикл вечно будет отнимать от 0 и переходить по jnz на -1.

 

FindWindow -> rcx : random.

 

Ого! Сколько я не знал и узнал сразу) thnx!

 

Semiono,

Возврат значения из апи может быть в rdx:rax, но никак не в rcx.

 

Я и не говорил про возврат значения, а про состояния регистра, содержащего параметр после вызова. Он сохраняться не должен, но может остаться равным значению параметра, которое через него передавали.

Т.е. ответьте на вопрос: что содержит rcx после call FindWindow?
У вас есть три варианта:

• содержимое регистра не изменилось т.е. он все еще содержит этот же параметра для FindWindow;
• содержимое регистра изменилось, но численно равно значению параметра переданного в FindWindow;
• содержимое регистра изменилось и содержит значение отличное от значения параметра FindWindow;

Первые два случая равнозначны по значению. Вторые два по алгоритму внутри FindWindow. Но нас интересует именно первое - равнозначность по значению для последующего алгоритма. Т.е. при rcx = 0 будет dec ecx = -1 и cmp ecx, 0 + jz exit (ne).

 

MaKsIm,

> Т.е. ответьте на вопрос: что содержит rcx после call FindWindow?

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

 

Это не важно, что внутри FindWindow. Тем более, что в каждом билде Windows они могут различаться из-за даже версии компилятора.

 

MaKsIm,

Чисто интересно как у тс работало. Это я наверно 32 смотрел. У меня на 10 получается возвращается константа 0x49, либо что то зависящее от фазы луны из freeheap().

Обрати внимание что и там серия call имеется

add: а не константа, не внимательно глянул:

Код (Text):

1. .text:0000000140411257                 mov     rcx, [rbp+0E8h]

Что там(значение возвращаемое сервисами) хз, может даже это kernel disclosure. На до бы проверить..

 

Вот поэтому то и интересно выяснить что за магия в этих call.

Но вот значение rcx после call FindWindows не очень интересно т.к. ошибка явно не из-за функции, что его затирает, а из-за команды, что подготавливает вызов этой функции (еще до call FindWindow).

 

MaKsIm,

Смотри lfence в этом случае нет.