XGETBV trickies

Well, started play for some reassembly & meet this XGETBV instruction (AVX related?), which quite puzzled me.
this instruction is included in CPU detection routines with bunch of CPUIDs. ..and..
when I ripped these routines, XGETBV does fault in my prog! while not doing in there.. (FFox)
now I have few assumpts:
1. instruction activated by specifically compiled mz-pe header?? (tried some flags..) or signed pe-images?
2. instruction activated by some call to system?
3. or in registry is granted some keys upon installation? (less likely)

xgetbv is compiled via the intrinsic _xgetbv defined in immintrin.h
as far as i know only one register is defined XCR0 == 0

but this intrinsic also takes 1 as its parameter
and returns result in EAX:EDX (this can probably be used as an anti debugging feature )
because the results are different inside and outside of debugger (3 no debugger ,7 with debugger afaik)

so there is paired instruction XSETBV, so debugger probably sets values in RING0.. tested under Windbg and for ecx=1 > eax=7 ;
PS: seems, this is per-process flag, as other programs did not got change.
thiis FrieFox maybe too much tries against anti-debug; can say, it is showcase of this. also it has is strangely generated code, which caused to fail test reassembly to run. while I was sure, reassembly was proper. after debug, I discovered, that in assembly exist RAW Pointers(like in IAT) to strings. and dissam can't handle guess this, as they are not relocated and special code adds base to them;
then I manually rewrote these and now reassembly works
in fact these blocks are like "artifical" IAT
there is also similar RAW-offset chunk, which is for msvcrt fail cases, I ignored these,as they will need for failures only..

Just for fun I started grepping system files for XGETBV (0F 01 D0) and XSETBV (0F 01 D1) to see how they were used. I found them in many files, including ntoskrnl.exe, but also in many other non-system files.

In a lot of cases they're used separately with no real indication of what they do, but I found a pairing of the 2 instructions in the 32 bit file C:\Windows/Boot/PCAT/memtest.exe.

Here is how they are used, disassembled in IDA 7 free with symbols loaded, in procs _ArchEnableProcessorFeatures and _ArchRestoreProcessorFeatures.

I just thought this was sort of interesting code. Notice the 'or eax, 7'.

these code shows XGETBV for ecx=0, where it seems for "check the AVX registers restore at context switch".
look for case ecx=1, which seems about debugging(?), or just WINDBG uses some extended states, so it writes this flag;
ps. i did not find 0F01D1 in "Windows Kits" folder except for arm folder.

Not xgetbv but another opcode I hadn't come across before, VPCEXT 7, 0Bh, used to detect the presence of VirtualPC.

This is just an observation really. I was looking at an app that detected VMWare, using the well known check for VMXh through the I/O port. I then noticed in IDA the opcode 'vpcext 7, 0Bh', a quick google search found that this is also a known check for VirtualPC.

What I found interesting was that IDA was able to decode the instruction while neither Olly or WinDbg could. VirtualPC is made by MS but apparently their debugger chooses not to support disassembling that opcode instruction.

I tried to find documentation on the two-byte 0F-3Fh opcode (vpcext) but none was to be found other than the anecdotal mentions of its existence. The secondary opcode map in the AMD64 ArchitectureProgrammer’s Manual on page 488 shows that opcode slot as being undefined.

There is a Wikipedia reference to 0F-3Fh being a backdoor Alternate Instruction Set (AIS) x86 instruction that was used by VIA Technologies. On these VIA C3 processors, the second hidden processor mode is accessed by executing the x86 instruction ALTINST (0F 3F). If AIS mode has been enabled, the processor will perform a JMP EAX and begin executing AIS instructions at the address of the EAX register. Using AIS allows native access to the Centaur Technology-designed RISC core inside the processor.

So props to IDA for being so good as to recognize that instruction. It crossed my mind that searching for these opcode bytes in malware might point to any general VM detection it uses, though they could just as easily be hidden in self modifying code (SMC).