FASM syntax for FSTENV with 14-byte operand size

Index > Main > FASM syntax for FSTENV with 14-byte operand size

Goto page 1, 2 Next

Author

Thread

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 26 Nov 2008, 15:54

I'm looking for a mnemonic which allows 14-byte FSTENV operand in FASM under use32 (the default is 28-byte operand). I don't want to hardcode it.

The manual doesn't mention this possibility. And FSTENVW doesn't work. I use 1.67.29.

26 Nov 2008, 15:54

revolution
When all else fails, read the source

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

revolution 26 Nov 2008, 16:00

I thought the mem14 structure was only for 16bit code. Is it not so that if you are in 32bit mode the structure is always mem28?

[edit]
I just checked the manuals (again) and it seems that the operand size override will affect the storage format.

Indeed there is no fundamental mem14 or mem28 size in fasm to give the destination size.
[/edit]

Last edited by revolution on 26 Nov 2008, 16:10; edited 1 time in total

26 Nov 2008, 16:00

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 26 Nov 2008, 16:09

Check it once again:

Quote:

The manner in which this information is stored in memory depends on the operating
mode of the processor (protected mode or real-address mode) and on the operandsize
attribute in effect (32-bit or 16-bit).

Or use a debugger.

26 Nov 2008, 16:09

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 26 Nov 2008, 16:12

revolution wrote:

I thought the mem14 structure was only for 16bit code. Is it not so that if you are in 32bit mode the structure is always mem28?

[edit]
I just checked the manuals (again) and it seems that the address size override will affect the storage format.
[/edit]

Check it once again. It is operand size attribute, not address attribute.

26 Nov 2008, 16:12

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 26 Nov 2008, 16:13

Too quick fingers, revolution? Wink

26 Nov 2008, 16:13

revolution
When all else fails, read the source

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

revolution 26 Nov 2008, 16:14

Yeah, my fuskup there, I edited my edit. Sorry for the confusion.

26 Nov 2008, 16:14

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 27 Nov 2008, 09:23

BTW, the same apply for FLDENV m14/28, FnSAVE m94/108, and FRSTOR m94/108.

(FXSAVE and FXRSTOR have fixed m512 operand in all modes)

27 Nov 2008, 09:23

revolution
When all else fails, read the source

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

revolution 27 Nov 2008, 09:29

I guess a macro or equ will be needed. Since Intel have not defined any special opcodes for these situations it doesn't seem appropriate to define our own. And this situation is quite rare so it also doesn't really rate as urgent.

27 Nov 2008, 09:29

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 27 Nov 2008, 10:29

FASM (and other assemblers) already defines its own mnemonics to indicate implicate operand size (doesn't "opcode" refer to a "machine operation code" rather than to "mnemonic"?):

loopw/loopd, loopew/looped/loopzw/loopzd, loopnew/loopned/loopnzw/loopnzd, int3, pushw/pushd, popw/popd, pushfw/popfw, pushaw, aam (with operand), aad (with operand).

27 Nov 2008, 10:29

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 27 Nov 2008, 10:31

And yes, it is not urgent, I was just wondering how would FASM encode them Smile

27 Nov 2008, 10:31

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 27 Nov 2008, 11:01

Yes, I think the FSTENVW would be the way to go.
I need to investigate why I didn't implement it in the past - I recall there was some strange reason, but I don't remember right now.

27 Nov 2008, 11:01

revolution
When all else fails, read the source

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

revolution 27 Nov 2008, 11:11

MazeGen wrote:

loopw/loopd, loopew/looped/loopzw/loopzd, loopnew/loopned/loopnzw/loopnzd, int3, pushw/pushd, popw/popd, pushfw/popfw, pushaw, aam (with operand), aad (with operand).

That is a good point. I hadn't previously considered that.

27 Nov 2008, 11:11

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 27 Nov 2008, 16:29

Tomasz Grysztar wrote:

Yes, I think the FSTENVW would be the way to go.
I need to investigate why I didn't implement it in the past - I recall there was some strange reason, but I don't remember right now.

Just be careful with encodings. FSTENVW must be encoded as 9B66D9/6 instead of 669BD9/6.

27 Nov 2008, 16:29

revolution
When all else fails, read the source

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

revolution 27 Nov 2008, 16:33

MazeGen wrote:

Just be careful with encodings. FSTENVW must be encoded as 9B66D9/6 instead of 669BD9/6.

Unless you are already in 16bit mode.

27 Nov 2008, 16:33

baldr

Joined: 19 Mar 2008
Posts: 1651

baldr 27 Nov 2008, 19:11

MazeGen,

Should future OSes seriously consider emulation of invalid in 64-bit mode opcodes? I'm talking about aaa/…/das family. Converting nibble to hex char using six byte code was so convenient (it even set CF for 0…9)…

27 Nov 2008, 19:11

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 28 Nov 2008, 08:31

These instructions are not really neccessary and that's probably why they were removed. And the emulation would be pretty slow.

On x64 Windows, only LAHF and SAHF are emulated because they are not supported on early steppings of EM64T architecture:

http://www.derkeiler.com/Mailing-Lists/Securiteam/2008-11/msg00024.html wrote:

On x64 Windows,
however, the #UD fault handler will actually emulate the LAHF instruction
if it faults, because some x64 processors may not support SAHF and LAHF in
64-bit mode.

28 Nov 2008, 08:31

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 27 Jan 2009, 14:24

Tomasz Grysztar wrote:

Yes, I think the FSTENVW would be the way to go.
I need to investigate why I didn't implement it in the past - I recall there was some strange reason, but I don't remember right now.

Any progress, Tomasz? I plan to investige also other assemblers so it would be good to know how you're gonna implement FnSTENV and the others.

27 Jan 2009, 14:24

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 08 Feb 2009, 20:18

It's added in 1.67.30.

08 Feb 2009, 20:18

MazeGen

Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia

MazeGen 09 Feb 2009, 09:19

WHATSNEW.TXT wrote:

[+] Added FSTENVW/FSTENVD/FSAVEW/FSAVED mnemonics.

Good work, however, FASM still complains about the following:

Code:

FNSTENVW [eax]
FNSTENVD [eax]

FRSTORW [eax]
FRSTORD [eax]

09 Feb 2009, 09:19

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 09 Feb 2009, 09:41

It seems I forgot about them. Smile

For a quick fix before the next release you can add these items to "instructions_7" table:

Code:

 db 'frstord',4
 dw fnsave_instruction_32bit-assembler
 db 'frstorw',4
 dw fnsave_instruction_16bit-assembler

And these to "instructions_8":

Code:

 db 'fnstenvd',6
 dw fldenv_instruction_32bit-assembler
 db 'fnstenvw',6
 dw fldenv_instruction_16bit-assembler

09 Feb 2009, 09:41

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