flat assembler
Message board for the users of flat assembler.

Index > Windows > "call" doing wrong

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
Big problem in fasm (64bit) to use 'call' operator. Fasm missaderssing it all the time. I have to control by myself every single instance. Sometimes labels need to be declared before "call". Otherwise after. Inside or outside 'proc' procedures it has a matter. It is really annoying.

At the same time there is no problem with jamp operators or ret, they work correctly. What is wrong with 'call'?

Did someone else see that kind of problem? Is there any fix for that? Maybe it is mixing logic from 32 bit short and long calls? Can I macro it for right condition or the only way to fix it is push rip and jmp combination?
Post 04 Aug 2020, 12:01
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17639
Location: In your JS exploiting you and your system
revolution
No one else has reported any problem with call.

Show some representative code. We don't know what you have done.
Post 04 Aug 2020, 12:03
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
This part of code works only if declared before DlgProc
Code:
alignPrepared:
        push    rax
        push    rbx
        push    rcx
        mov             rcx,4
        @@:
        dec             rcx
        cmp             rcx,0
        je              @F
        mov             rbx,Prepared
        add             rbx,rcx
        mov             al,[rbx]
        cmp             al,20h
        jne             @B
        mov             byte[rbx],0
        jmp             @B
        @@:
        pop             rcx
        pop             rbx
        pop             rax
        ret
    

It doesn't work if declared inside DlgProc, but if I use some macros on it, I have to declare it inside DlgProc, even in the end of proc, otherwise it corrupt.

You say no one else reported this problem, but I seen it already in google with advice to declare procedure-label before call.[/code]
Post 04 Aug 2020, 12:31
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17639
Location: In your JS exploiting you and your system
revolution
There are no call instructions inside your code sample. Question

This works for me:
Code:
use64
call forward_label
forward_label:    
Code:
2 passes, 5 bytes.    
Post 04 Aug 2020, 12:46
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
It was procedure called by call operator from DlgProc. What do you want to see, how I call? It is nothing wrong to put 'call label' somewhere. Problem with address it use for jump. Passed not mean working.
Post 04 Aug 2020, 12:56
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17639
Location: In your JS exploiting you and your system
revolution
I can't replicate your problem, so yes, we need to see what is happening.

Post some minimised code showing the problem.
Post 04 Aug 2020, 12:58
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
call alignPrepared
Post 04 Aug 2020, 12:59
View user's profile Send private message Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
jmp alignPrepared works fine in almost the same condition.
Post 04 Aug 2020, 13:00
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17639
Location: In your JS exploiting you and your system
revolution
Do you mean like this:
Code:
use64
call alignPrepared
alignPrepared:
        push    rax
        push    rbx
        push    rcx
        mov             rcx,4
        @@:
        dec             rcx
        cmp             rcx,0
        je              @F
;        mov             rbx,Prepared
        add             rbx,rcx
        mov             al,[rbx]
        cmp             al,20h
        jne             @B
        mov             byte[rbx],0
        jmp             @B
        @@:
        pop             rcx
        pop             rbx
        pop             rax
        ret
call alignPrepared    
Code:
2 passes, 47 bytes.    
Post 04 Aug 2020, 13:02
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
Code:
will_work:
   invoke  MessageBox,HWND_DESKTOP,"It is ok",0,MB_OK
   ret
;-----------------------------------------------
proc dlgProc ....
  cmp   [wMsg],WM_COMMAND
  je            wmcommand
  ret
wmcommand:
  ....BN_CLICKED...
  button_1:
     call will_work
     ret
  button_2:
     call will_not
     ret
  button_3:
     call will_work_too
     ret
;subprocedures------------------------------------
will_not:
  invoke  MessageBox,HWND_DESKTOP,"It is ok",0,MB_OK
  ret
will_work_too:
  somemacro 
  invoke  MessageBox,HWND_DESKTOP,"It is ok",0,MB_OK
  ret
endp    
Post 04 Aug 2020, 13:12
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17639
Location: In your JS exploiting you and your system
revolution
You have no endp so all the rets after the proc are more complex than just the simple ret.
Post 04 Aug 2020, 13:15
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
Actually last example will always work as it already use macro "invoke" (exept first button), but I hope you understand what I mean.

scroll it to see endp


Last edited by Overclick on 04 Aug 2020, 13:21; edited 1 time in total
Post 04 Aug 2020, 13:17
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17639
Location: In your JS exploiting you and your system
revolution
The rets inside the proc/endp are not normal rets. You need to move that code outside the proc/end
Code:
proc ...
 call something
 ret ;complex ret
endp
something:
 invoke ...
 ret ;normal ret    
Post 04 Aug 2020, 13:20
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
I have no problems with rets. there is wrong call address.
Any way I don't use subprocedures inside proc any more.
Post 04 Aug 2020, 13:25
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17639
Location: In your JS exploiting you and your system
revolution
Overclick wrote:
I have no problems with rets. there is wrong call address.
Try my suggestion above to move the code after the endp.
Post 04 Aug 2020, 13:26
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
Why it is not documented anyhow? Whatever, 'call' still unpredictable in calls to outside DlgProc.
Code:
will_not:
   mymacro
   ret
will_work:
   mymacro
   jmp back_to_Dlg

proc DlgProc
...
   call will_not
   jmp will_work
   back_to_Dlg:
...
ret
endp    

There is no issues to return, mymacro doesn't even start to work.


Last edited by Overclick on 04 Aug 2020, 13:40; edited 1 time in total
Post 04 Aug 2020, 13:35
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17639
Location: In your JS exploiting you and your system
revolution
Then I think there is something else you have done that you have overlooked. No one else has trouble.
Post 04 Aug 2020, 13:38
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3025
Location: vpcmipstrm
bitRAKE
I've had this problem in the past - it was like revolution said. It was so annoying that I switched to using RETN every time I want a real RET instruction. You can see it in all my code on the board. If people don't know they probably think it looks crazy, but when assemblers starting making decisions what a return instruction is based on the context I moved to be more explicit. So, it's possible to have leaf functions in PROC, but they should end with RETN. This works similarly to MASM.

The macro interaction sounds like something else.

_________________
¯\(°_o)/¯ unlicense.org


Last edited by bitRAKE on 04 Aug 2020, 13:44; edited 1 time in total
Post 04 Aug 2020, 13:41
View user's profile Send private message Visit poster's website Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
Short and long calls missing I suppose.
Post 04 Aug 2020, 13:42
View user's profile Send private message Reply with quote
Overclick



Joined: 11 Jul 2020
Posts: 199
Overclick
about call:
Code:
macro call destination {
   push  rip
   push  rax
   mov   rax,<sum of opcodes size>
   add   [rsp+8],rax
   pop   rax
   jmp   destination
}    

Just for testing 'call'. If it will work fine, then it 100% problem in fasm


Last edited by Overclick on 04 Aug 2020, 13:55; edited 2 times in total
Post 04 Aug 2020, 13:51
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.