; Template program using process environment block

format PE64 GUI 5.0
entry start

include 'win64w.inc'

section '.text' code readable executable

proc start
        ;sub     rsp,8           ; Make stack dqword aligned (proc macro already done for us)
     gs mov     rbx,[TEB.ProcessEnvironmentBlock]
        lea     rsi,[rbx+PEB.OSMajorVersion]
        lea     rdi,[_Version]
        lodsd
        add     byte[rdi],al
        lodsd
        add     byte[rdi+2*sizeof.TCHAR],al
        invoke  MessageBox,NULL,rdi,_winVerTitle,MB_OK
        ;add     rsp,8         ; restore stack (proc macro already done for us)
        ret
endp

section '.data' data readable writeable

  _Version TCHAR '0.0',0
  _winVerTitle TCHAR 'Windows version',0

section '.idata' import data readable writeable

  library user32,'USER32.DLL'

  include 'os specific/windows/api/x86/user32.inc'      

00000000: 8B 05 2A 00 00 00        mov eax,[30h]                  
00000006: 65 67 A1 30 00 00 00     mov eax,[gs:30h]               
0000000D: 65 67 A1 FF FF FF FF     mov eax,[gs:000000000FFFFFFFFh]
00000014: 65 8B 04 25 FF FF FF FF  mov eax,[gs:0FFFFFFFFFFFFFFFFh]
0000001C: 65 A1 CC CC CC CC CC CC  mov eax,[gs:0CCCCCCCCCCCCCCCCh]
          CC CC    

I like this variant - placing segment register as prefix

`mov rax, [gs:0x30]` generates address relative to RIP, as the result it generates broken code.

reloc: data fixups
    assert $ = reloc
end data    

Tomasz, can thou explain how to apply such optimizations to practice?
The role of segment registers in x64 world is minimal - it is only point to TEB structure that whole fit 1000h. others segment regs are zeroed.
But maybe initial zeroed segregisters ds ss cs es are more interested in trickeries.
Thanks in advance.

65 48 8B 04 25 30 00 00 00    IDA disassembly: mov rax, gs:30h    

65 67 48 A1 30 00 00 00       IDA disassembly: mov rax, large gs:30h    

Seems like the new version of FASM generates working code now for `mov eax, [gs:0x30]`.

A small question, just out of curiosity. I see that getting TIB in the kernelbase.dll is done this way:

Code:

65 48 8B 04 25 30 00 00 00    IDA disassembly: mov rax, gs:30h    

FASM generates this:

Code:

65 67 48 A1 30 00 00 00       IDA disassembly: mov rax, large gs:30h    

Is it basically the same thing, just one byte shorter?

use64    

mov     eax,[ds:$30]    

mov     eax,[$30]; 67 A1 30 00 00 00    

gs mov     eax,[ds:$30]    

        rdgsbase rbx
        neg     rbx
        mov     [gs:rbx+hwnd],rax       ; access variable in program image    

Why does the code have "neg rbx"?

As Tomasz pointed out, FS/GS have 64 bit bases (MSR for FS base, MSR for GS base, MSR for kernel GS base), the others (CS, DS, ES, SS) have 32 bit bases in GDT.
But be careful with the instruction rdgsbase - old processors do not support it (use CPUID to determine whether cpu supports it - input eax=7, input ecx=0, execute cpuid, check output ebx bit 0.)
When the cpuid output ebx bit 0. is set to 1, then you must check CR4 as its bit 16. enables/disables rdfsbase/rdgsbase/wr..., unluckily you can't easily obtain CR4 in usermode as mov gpr64,cr4 generates #GP(0) here and requires CPL=0 (kernelmode)

As Tomasz pointed out, FS/GS have 64 bit bases (MSR for FS base, MSR for GS base, MSR for kernel GS base), the others (CS, DS, ES, SS) have 32 bit bases in GDT.

But be careful with the instruction rdgsbase - old processors do not support it (...)