"push $FFFFFFFE" out of range?

Index > Main > "push $FFFFFFFE" out of range?

Author

Thread

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 15 Aug 2009, 00:08

Code:

use64
push       $FFFFFFFE

Am I just misunderstanding something again, or should this.. you know.. compile?

15 Aug 2009, 00:08

revolution
When all else fails, read the source

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

revolution 15 Aug 2009, 00:24

You can't push 0x00000000fffffffe, it is out of range.

I think you were given the range of 64bit constants previously.

0xffffffff80000000 to 0x000000007fffffff inclusive.

15 Aug 2009, 00:24

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 15 Aug 2009, 00:47

....it works in 32bit mode though... =/

So what am I supposed to do to push arguments in 64bit mode?

Code:

lea    rsp,[rsp-8]
mov      qword[rsp],ARG

???

Code:

mov rax,ARG
push rax

????

Come on! Sad

There has got to be some kind of mistake.. didn't you say before that data movement functions like push and mov are supposed to support 64bit values? And that isn't even a 64bit one, it is 32bit! Confused

Also, I am sure it is not "0xffffffff80000000 to 0x000000007fffffff"; the below compiles fine..

Code:

use64
push    1

But it is way below $7FFFFFFF.

So what's going on with this?

15 Aug 2009, 00:47

LocoDelAssembly
Your code has a bug

Joined: 06 May 2005
Posts: 4624
Location: Argentina

LocoDelAssembly 15 Aug 2009, 01:08

Quote:

But it is way below $7FFFFFFF.

Perhaps this will be more understandable: {[0xffffffff80000000..0xffffffffffffffff]} UNION {[0x0..0x000000007fffffff]}

The first set intersects with {[-2147483648..-1]}

15 Aug 2009, 01:08

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 15 Aug 2009, 01:13

Thanks.. so how do I use the old version? It kind of sucks not even being able to push 32bit values, yet alone 64bit ones! Confused

15 Aug 2009, 01:13

revolution
When all else fails, read the source

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

revolution 15 Aug 2009, 03:46

If you would take the time to read the AMD and/or the Intel manuals you would see that all stack instructions in long mode do not support 32bit operations.

Azu wrote:

... didn't you say before that data movement functions like push and mov are supposed to support 64bit values?

No, nobody said that or even implied that. mov supports 64bit constants, no mention has been made of push until now.

15 Aug 2009, 03:46

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 15 Aug 2009, 04:39

revolution wrote:

If you would take the time to read the AMD and/or the Intel manuals you would see that all stack instructions in long mode do not support 32bit operations.

It sucks not even being able to push 32bit values. In fact, I was actually hoping it would support 64bit ones! 31bit push == yuck. It REALLY sucks since most of the syscalls in windows need args passed by stack. Sad

Aren't there any ways to put stuff on the stack besides those awful dependency chains I mentioned above? Because I think they will kill performance..

Edit: damn I really should proofread my posts for typos before submitting :/

Last edited by Azu on 15 Aug 2009, 06:35; edited 1 time in total

15 Aug 2009, 04:39

revolution
When all else fails, read the source

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

revolution 15 Aug 2009, 05:31

Azu wrote:

Aren't there any ways to put stuff on the stack besides those awful dependency chains I mentioned above?

The only method that is useful is

Code:

mov reg,const64
push reg
;or
mov [e{b|s}p+offset],reg

Azu wrote:

Because I think they will kill performance..

Performance! This is the least of your worries, get your code working first. Plus, if you ever get to the stage to be able to really measure the difference in a real program (and not some synthetic test) then you may be surprised to learn just how little difference it makes.

15 Aug 2009, 05:31

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 16 Aug 2009, 15:39

Why switch to 64-bit mode if performance is gonna be worse? Rolling Eyes

16 Aug 2009, 15:39

bitRAKE

Joined: 21 Jul 2003
Posts: 3892
Location: vpcmipstrm

bitRAKE 16 Aug 2009, 18:14

Under Win64 the ABI doesn't use PUSHing of parameters. Even prior to Win64 Intel recommended not PUSHing arguments on the stack for performance reasons. So, if performance is the goal then PUSHing should not be done - 64-bit or 32-bit. PUSHing under Win32 is/was done because it was easy.

Code:

pushw 0
pushw 0
pushw -1
pushw -2

...okay, now that just seems silly. Very Happy

(but doesn't effect flags)

Code:

push -2
not dword [rsp+4] ; and

Code:

push 0
or dword [rsp],-2 ; sub/add

...six bytes seems too many.
(Are you sure the upper dword needs to be clear?)

16 Aug 2009, 18:14

Azu

Joined: 16 Dec 2008
Posts: 1159

Azu 16 Aug 2009, 19:03

Well on win64 the native calls need stuff passed by stack, like so;

Code:

macro  ntSleep hundredNS{
if hundredNS eq -1
       xor     rdx,rdx
     dec     rdx
 shr     rdx,1
       push    rdx
;else if ($FFFFFFFF80000000>-hundredNS) and (-hundredNS>$000000007FFFFFFF)
;    mov     rdx,-hundredNS
;     push    rdx
;This won't compile! 
else
     push    -hundredNS
end if
mov     eax,ordinalDelayExecution
mov        rdx,rsp
zero r10
syscall
pop   rdx
}
macro  ntSleepMS MS{
if MS eq -1
   ntSleep -1
else
  ntSleep MS*10000
end if
}

The upper dword matters because is 64bit value.

I've only tested with DelayExecution so far (easiest one to test), but I'm pretty sure they all use the same standard..

16 Aug 2009, 19:03

< 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