FASM x64

Здравствуйте.

Сто лет не писал на fasm и забыл как входить в процедуру. Помогите пожалуйста.
Я помню что если сразу входить в процедуру в начале программы то ненужно выравнивать стек "sub rsp,8"

Спасибо, разобрался с Божей помощью

Код (Text):

1.  
2. format PE64 GUI 5.0
3. entry start
4.  
5. include 'win64a.inc'
6.  
7. section '.code' code readable executable
8.  
9.   proc start
10.  
11.   ret
12.  
13.   endp
14.  
15.   invoke  ExitProcess,rax
16.  
17. section '.idata' import data readable writeable
18.  
19.   library kernel,'KERNEL32.DLL'
20.  
21.   import kernel,\
22.   ExitProcess,'ExitProcess'
23.  
24.  

 

Вообще, ничего не понял, что Вам надо, но наверное это:

Код (ASM):

1. include 'win64W.inc'
2.  
3. format PE64 GUI 5.0
4. entry start
5.  
6. section '.text' code readable executable
7.  
8.   start:
9.         sub     rsp,8           ; Выравнивание стека на dqword
10.         call     start2
11.         invoke  ExitProcess, 0
12.  
13. proc start2
14.         ret
15. endp
16.  
17. ;section '.data' data readable writeable
18.  
19. section '.idata' import data readable writeable
20.  
21.   library kernel32,'KERNEL32.DLL',\
22.           user32,'USER32.DLL'
23.  
24.   include 'api\kernel32.inc'
25.   include 'api\user32.inc'        

 

У меня такой вопрос: почему программа ексемпл запускается в безопастном режиме в COMODO FIREWALL, я понимаю что программа редкая но всё же

хостинг фото

 

А что Вы ожидаете? Она просто выводит MessageBox только по тому, что entry указывает на proc start

 

Мне интересно почему фаерволл запускает ее в безопастном режиме, ну ладно...
Вот еще вопрос почему антивирусы, каторый я и в глаза не видел, определяют ее как заразу

фотохостинг бесплатно

 

Решил проблему с COMODO - удалил его

 

Мб, потому что в импорте нет "опасных" функций?

Ложные срабатывания, это норма. Лечиться подписью сертификатом

 

Это не выравнивание, это просто "rsp-8".

Выравнивание вот:

Код (ASM):

1.  
2.     and rsp, -8
3.  

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

 

Категорически не согласен! Если сделать and rsp, -8 то программа упадёт на x64. Т.к применяя and вы убиваете указатель на стек в rsp.

ТС приложил исходник в первом сообщение, смотрим его и путём не сложных умственных заключений приходим к выводу, что его интересует только ОС Windows, архитектура x64 =)

 

Вообще, 8 надо отнять из RSP только потому что макросы Fasm (вроде как invoke) не резервируют достаточное количество байт перед вызовом функции. Win64 ABI требует, чтобы стековый кадр был выравнен на 16 байт. Таким образом если не сделать sub rsp,8, то стек не будет иметь 16 байтовую кратность с учётом адреса возврата вызываемой функции.

 

wat?

А сделав sub - не убиваете, да? И кто вам мешает rsp сначала сохранить, а когда надо - восстановить?

Invoke fasm для win64 отлично резервирует место, ибо это входит в Win64 calling convention.

Тогда надо делать and rsp, -16; причем в самом начале вашей функции, ибо никто не гарантирует, что стек у вас будет при вызове выровнен. Иначе придется скурпулезно считать каждый push и pop, особенно с учетом любых переходов - чтобы не дай бог не сбиться с границы - что все равно рано или поздно произойдет.

Я когда-то писал функцию универсального вызова внешних процедур для С, и выглядела она как то так:

Код (C):

1.  
2. asm("call:",
3.    "pushq %rbp",
4.    "movq  %rsp, %rbp",
5.  
6.    "andl  $-16, %esp", // alignment
7.  
8.    "andq  $1, %rdx", // arguments count
9.    "leaq  -16(%rsp,%rdx,8), %rsp",
10.  
11.    "pushq (%r10)", ..., "pushq (%r10)", // all arguments
12.  
13.    .......
14.    "subq $32, %rsp", // extra space
15.    "call *%rax",
16.    "leave",
17.    "ret",
18.  

Прошу заметить, что перед вызовом винда требует еще и 32 байтика в резерв.

 

Пардон, мой косяк. Действительно and rsp, -8, делает выравнивание стека без потери адреса. Вы были таки правы, я поспешил с выводами, когда увидел опкод and, а дальнейшие мои мысли были построены на ложном умозаключение...

Эм, шутки шутками, но... Опытным путём было выяснено, что перед вызовом функции стек должен быть выравнен на 8 байтовую границу, а после на 16-байтовую. Не надо выравнивать стек перед каждым вызовом функции, достаточно на точке входа сделать sub rsp, 8. Выравнивание на 8 байтовую границу останется, а после вызова call xxxx, будет размещён в стеке адрес возврата и выравнивание стека будет кратно 16, что нам и надо.

Открываем PROC64.INC и видим:

Код (ASM):

1. macro invoke proc,[arg]
2. { common fastcall [proc],arg }
3.  
4. macro fastcall proc,[arg]
5. { common local stackspace,argscount,counter
6.  
7. ; Вот тут самое интересное
8.     if argscount < 4
9.      stackspace = 4*8
10.     else if argscount and 1
11.      stackspace = (argscount+1)*8
12.     else
13.      stackspace = argscount*8
14.     end if    

На сколько я понимаю, если аргументов функции меньше чем 4, то резервируем на стеке 32 байта, если хотя бы 4 и аргументов чётное количество, то резервируем КоличествоАргументов * 8, при не чётном количестве аргументов, считаем, как (КоличествоАргументов + 1) * 8.

Т.е. всё замечательно, аргументы в стеке лежат с выравниванием кратным 16, пока инструкция call не положит в стек адрес возврата... Итого в самом простом случае, получается, что макрос fastcall (invoke) резервирует 32 байта + 8 байт на адрес возврата = 40 байт и чтобы их выровнять, нам надо добавить 8 (отнять от rsp 8).

Я уже не знаю как проще объяснить =(

 

МС загадит 32 байта, как пить дать. Так что лучше, все же, сделать sub rsp, 40.

 

Да, правда ваша - я невнимательно вас прочитал. Уже удалил.

Ну я на эти грабли уже наступал. Ничего не имею против, чтобы и вы потоптались )

 

Пишу оконную процедуру но авирь ругается? Что теперь на fasm невозможно вообще ни чего написать?