Help with Windbg

Hi all, I'm having a spot of bother with Windbg. I've been messing with a game and found whenever I try to assemble any instruction containing 'xmm0' I would recieve an 'Bad opcode error' warning.

I've even tried copying an existing instruction ie, movaps [ecx],xmm0 and still get the same warning.

If there are any Windbg users on this board can you please tell me the correct way to write 'xmm0' or any of the 8 xmm registers, to work with Windbg.

Thanks.

Can you paste a bit more of the syntax around what you're doing?

As a thought, if you already know the machine representation of the assembly mnemonic and where you're trying to put it, you can just straight 'e' (edit) the memory instead. For example, using Notepad as the hapless victim and starting off with:

0:000> ub .
USER32!GetWindowLongPtrW+0x1f:
00000000`7796d087 eb00 jmp USER32!GetWindowLongPtrW+0x2d (00000000`7796d089)
00000000`7796d089 4883c420 add rsp,20h
00000000`7796d08d 5b pop rbx
00000000`7796d08e c3 ret
00000000`7796d08f 90 nop

Let's instead pop rbx twice and use up that nop byte...

0:000> eq 00000000`7796d08e 5b
0:000> eq 00000000`7796d08f c3

And now:

0:000> u USER32!GetWindowLongPtrW+0x1f
USER32!GetWindowLongPtrW+0x1f:
00000000`7796d087 eb00 jmp USER32!GetWindowLongPtrW+0x2d (00000000`7796d089)
00000000`7796d089 4883c420 add rsp,20h
00000000`7796d08d 5b pop rbx
00000000`7796d08e 5b pop rbx
00000000`7796d08f c3 ret

You only need 'a' (assemble) if you don't already have the machine mnemonic representation.

The problem is the debugger doesn't accept the inputted assembly if 'xmm#' is part of the instruction.
I have no problem assembling, say for example;

a 7796d089 add rsp,20h
a 7796d08d pop rbx
a 7796d08e ret

but if I were to attempt to add an instruction that included xmm0, i'd recieve the bad opcode error.
It's as though the debugger doesn't understand the xmm0 part, even when directly replacing an existing xmm0 involved instruction with itself.

Has this something to do with 'symbols'?

This is assembling via the dissassembly window, I don't know the hex of the mnemonics so I prefer assembly instructions.

Same here.

My guess is that 'a' doesn't handle SSE SIMD instructions at all, nor the registers on which they operate. "Bad Opcode" just means it doesn't understand the instruction, as opposed to the register - it uses "bad register" to denote the latter. Hence, your problem stems from both the xmm* registers and the movaps instruction (SSE). I had a bit of a play with this:

0:000:x86> a
77be0bc9 movss xmm1,xmm2
movss xmm1,xmm2
^ Bad opcode error in 'movss xmm1,xmm2'

Instruction is correct but 'a' presumably doesn't do SSE.


77be0bc9 mob @eax,@ebx
mob @eax,@ebx
^ Bad opcode error in 'mob @eax,@ebx'

Intentionally misspelled and nonsensical instruction produces the same result.


77be0bc9 movups @xmm2,@xmm1
movups @xmm2,@xmm1
^ Bad opcode error in 'movups @xmm2,@xmm1'

Another SSE instruction, registers prefixed with @ to denote registers and prevent the possibility of interpretation as symbols.


77be0bc9 mov @eax,xmm2
mov @eax,xmm2
^ Couldn't resolve 'mov @eax,xmm2'

Now it understands the (non-SSE) instruction but not "xmm2". Without the @ prefix, it thinks it might be a symbol which it can't resolve.


77be0bc9 mov @eax,@xmm2
mov @eax,@xmm2
^ Bad register error in 'mov @eax,@xmm2'

It's been told that xmm2 is supposedly a register, by use of the @ prefix, but it obviously doesn't know of the xmm* registers and it barfs with "bad register error".


Verdict: limitation of the 'a' engine. They haven't updated it to do SSE.


That needn't hold you back if you're only trying to modify a handful of instructions though. You can still work out the corresponding machine code yourself (Intel docs + vast amount of online info), and just use the 'e' (edit) command to punch that into memory directly.

Great question though. Have some rep

Thanks alot bro, I've moved back to Ollydbg for now.
Rep returned by fellow aussie.