64 bit not understood sub rsp,8 !

Index > Windows > 64 bit not understood sub rsp,8 !

Goto page Previous 1, 2, 3, 4, 5, 6 Next

Author

Thread

Roman

Joined: 21 Apr 2012
Posts: 1088

Roman

Code:

format PE64 GUI 5.0 on 'nul'
entry Start

macro Msg chT { invoke MessageBox,0,chT,0,0  }

include 'include\win64a.inc'


section '.code' code readable writeable executable
        proc vv
             Msg 'f'
             ret
        endp

Start:
     sub     rsp,8
     push rax ;this crash. comment and get message !
     call vv
     pop rax ;comment


     invoke  ExitProcess, 0


section '.idata' import data readable writeable

  library kernel32,'KERNEL32.DLL',\
          user32,'USER32.DLL'

  import user32,\
         MessageBox,'MessageBoxA'

  import kernel32,\
         ExitProcess,'ExitProcess'

22 Dec 2020, 08:26

Ali.Z

Joined: 08 Jan 2018
Posts: 509

Ali.Z

i think some members here answered this multiple times, please refer to the 64-bit calling conventions. (msdn and wikipedia)

additionally a 32 bytes of shadow space may be required, besides that and since during the load time of your application the stack may not be aligned depending on Windows version; thus you cant always subtract 8 from RSP.

instead subtract some 16 bytes value from RSP then bitwise AND SPL with F0h.

Code:

sub RSP,100h ; just for the sake of example
and SPL,0F0h ; to ensure the alignment

_________________
Asm For Wise Humans

22 Dec 2020, 08:34

Roman

Joined: 21 Apr 2012
Posts: 1088

Roman

Ali.Z

Quote:

thus you cant always subtract 8 from RSP.

And how do pushs ?

22 Dec 2020, 08:39

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18444
Location: In your JS exploiting you and your system

revolution

Okay.

So here is the situation.

Start is unaligned, because you use the entry directive directly.

After sub and then push the stack is unaligned.

After the call the stack is aligned. This is a violation of the call standard. All procedure entries must be unaligned entry after the call, and the code must then align, usually with push rbp. Because you use proc this is done for you by the macro. Therefore the stack is not in the correct state. And KABOOM!

To fix this, do not push a single value to the stack. Always push in pairs, or better yet, don't ever push, just use local variables.

Last edited by revolution on 22 Dec 2020, 08:40; edited 1 time in total

22 Dec 2020, 08:40

Roman

Joined: 21 Apr 2012
Posts: 1088

Roman

Quote:

After sub and then push the stack is unaligned.

After the call the stack is aligned. This is a violation of the call standard. All procedure entries must be unaligned entry after the call, and the code must then align, usually with b]push rbp[/b]. Because you use proc this is done for you by the macro. There fore the stack is not in the correct state. And KABOOM!

I understood this many pages ago Smile

And try say this problem.

In 32 bit program no this problem !
When i do push double(dq value) i not get crash !

Last edited by Roman on 22 Dec 2020, 08:44; edited 1 time in total

22 Dec 2020, 08:40

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18444
Location: In your JS exploiting you and your system

revolution

So why are you asking the question if you already knew?

22 Dec 2020, 08:42

Roman

Joined: 21 Apr 2012
Posts: 1088

Roman

I wanted to confirm my guess. Test program on others CPUs.
And know this is not my wrong code.

And remember this again, after couple years.

Last edited by Roman on 22 Dec 2020, 08:49; edited 1 time in total

22 Dec 2020, 08:45

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18444
Location: In your JS exploiting you and your system

revolution

The 32-bit call standard is completely different. You can't compare them.

22 Dec 2020, 08:47

Roman

Joined: 21 Apr 2012
Posts: 1088

Roman

Quote:

The 32-bit call standard is completely different.

That is why i very surprised when my program 64 bit crash.
I thinked the same must work in 64 bits.

22 Dec 2020, 08:51

Roman

Joined: 21 Apr 2012
Posts: 1088

Roman

But if fasmw have some function to get know align rsp or not.
And not do always in invoke sub rsp,20h and add rsp,20h

Do smart sub rsp and add rsp.
Its solve problem.

My example work if write in proc vv:

Code:

proc vv
sub  rsp,20h-8
xor rcx,rcx
mov rdx,text
xor r8,r8
xor r9,r9
Call [MessageBox]
add rsp,20h-8
ret
text db 'some text',0
endp

in code:
push rax
call vv
pop rax

22 Dec 2020, 08:55

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18444
Location: In your JS exploiting you and your system

revolution

Just follow the rules and then you will have no problem.

Always have your stack aligned before doing call, then it always works, always.

If you have random "fixed" entries then you get trouble.

Code:

; rsp is aligned
push rax ;unaligned
call vv ; okay, because vv has a fixup in there
pop rax ; aligned
call vv ; KABOOM!

Anyhow, 0x20-8 is very bad because now part of your shadow space is the saved RBP. And again KABOOM! At the very least 0x20+8 would work "better", but it is still bad because it doesn't follow the rules.

22 Dec 2020, 09:05

Roman

Joined: 21 Apr 2012
Posts: 1088

Roman

Quote:

Anyhow, 0x20-8 is very bad because now part

I agree and that's why I started talking about a smart mechanism in fasmw 64 bits.
Fasmw must follow rsp and know rsp aligned or not.
And put right x value in sub rsp,x

22 Dec 2020, 09:29

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18444
Location: In your JS exploiting you and your system

revolution

No.

fasm does what you tell it to do.

Just follow the rules. If you have all those random stack adjustments with push then you get problems. Don't do it. Stop doing it. Never do it. Then all will work fine, no need for any special unruly code to "fix" the problems you created.

22 Dec 2020, 09:33

Roman

Joined: 21 Apr 2012
Posts: 1088

Roman

Quote:

Stop doing it. Never do it.

Do it but remember this Smile

And how i sayed best solution not do push rax and pop rax.
Do mov [tmpRegs],rax

Or
macro NewPush reg { mov [tmpReg#reg],reg }

Last edited by Roman on 22 Dec 2020, 09:45; edited 3 times in total

22 Dec 2020, 09:34

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18444
Location: In your JS exploiting you and your system

revolution

Yes. Use local variables. Then you get a nice name attached, and no more problems.

22 Dec 2020, 09:38

Roman

Joined: 21 Apr 2012
Posts: 1088

Roman

Now you see too.
push and pop in 64 bits get problems.

22 Dec 2020, 09:42

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18444
Location: In your JS exploiting you and your system

revolution

You only get problems if you don't understand what is happening.

I said: Don't use random push/pop.

22 Dec 2020, 09:46

Roman

Joined: 21 Apr 2012
Posts: 1088

Roman

Quote:

You only get problems if you don't understand what is happening.

I said: Don't use random push/pop.

I understood, don't be angry.

I try this in fasmw 1.73 :
;illegal local tmpReg:dword very fanny
;but compile ok if local tmpReg:DWORD

Code:

proc v2
     local tmpReg:DWORD
     mov dword [tmpReg],eax
     Msg 'f'
     mov eax,[tmpReg]
     ret
endp

22 Dec 2020, 09:59

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 18444
Location: In your JS exploiting you and your system

revolution

That is normal. What do you find "fanny"?

22 Dec 2020, 10:05

Ali.Z

Joined: 08 Jan 2018
Posts: 509

Ali.Z

Roman wrote:

local tmpReg:dword
local tmpReg:DWORD

because its defined in procXX.inc as upper case.

_________________
Asm For Wise Humans

22 Dec 2020, 10:14

Goto page Previous 1, 2, 3, 4, 5, 6 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