I was examining a protection and found this odd code usage:



Which equals to bswap dx. The latest Intel's Reference Manual, says that When BSWAP references a 16 bit register, the result is undefined.
This can indeed cause compatibility problems when used seriously..

Here (Intel T9300) it makes the 16-bit register zero (in 32-bit mode). Anyone see anything different?

(I'm not advocating using it, just curious what it actually does on existing implementations!)

Is (e)dx even used for anything after that?

all i remember is the word ptr getting zeroed and trap flag zeroed and this sequence being used in some junk shit routines
with
some crap here
.
.
.
pushfd
or dword ptr ss:[esp],100
popfd
.
.
bswap dx (66 0f ca opcode)
..

blah blah

Is it possibly a disassembly glitch? I've seen nonsensical code that when disassembled using a different tool resolved itself to perfectly normal code.

SiGiNT

there bad opcodes are used as AnitDisassembling tricks.
>>how can a "Protectionist" write this!?

ok, thay can by written using DB statement..

well 66 is prefix for a legitimate 32 bit opcode

bswap edx opcode is 0f ca
and many disassembler tend to disassemble them in different ways

ollybdg will dissassemble it as 16 bit bswap

00401000 t>/$ /EB 00 JMP SHORT 00401002
00401002 |> \66:0FCA BSWAP DX
00401005 |. EB 0B JMP SHORT 00401012


windbg will say edx and include the prefix too

test+0x1000:
00401000 eb00 jmp test+0x1002 (00401002)
00401002 660fca bswap edx
00401005 eb0b jmp test+0x1012 (00401012)
00401007 2b484f sub ecx,dword ptr [eax+4Fh]


idafree will say edx and wont include prefix in one line

.text:00401000 jmp short $+2
.text:00401002 db 66h
.text:00401002 bswap edx
.text:00401005 jmp short loc_401012


it can be written by _emit compiler intrinsc or by _asm { db 0x66 }