mov [edx],10h - Invalid instruction operands

[Astro]

Hi,

Code Select Expand

mov edx,ServiceStatus
mov [edx],10h ; dwServiceType - SERVICE_WIN32_OWN_PROCESS

:'(

Maybe I screwed something up, but I don't know what.

ServiceStatus contains a pointer to heap memory allocated with HeapAlloc into the process heap.

EDIT: Hmm.

Code Select Expand

mov [edx],dword ptr 10h ; dwServiceType - SERVICE_WIN32_OWN_PROCESS

works.

Best regards,
Astro.

[dedndave]

i would write it as....

        mov dword ptr [edx],10h

your way is probably ok, too   :P

most of the values are defined as equates in windows.inc or winextra.inc, so...

        mov dword ptr [edx],SERVICE_WIN32_OWN_PROCESS

[Astro]

Hmm...

Seems:

Code Select Expand

mov dword [edx],10h

mov dword ptr [edx],10h

mov [edx], dword 10h

mov [edx], dword ptr 10h

are all the same and valid.

Best regards,
Astro.

[Ghandi]

Code Select Expand


MOV EAX, [EAX]
MOV [EAX],EAX


These sort of statements will assemble fine because the register is giving MASM the size, but if it becomes ambiguous in any way, then the assembler will throw an error.

Code Select Expand


MOV AX,[EAX]
MOVZX EAX,[EAX]
MOV [EAX],10h


Although you can get away with omitting a lot of *details* when coding with MASM, i prefer to write my code with full references, etc. That way when i debug it later in OllyDbg, there are no surprises, because it is (almost) identical to how i wrote it and there is no ambiguity about instructions, such as this one.

HR,
Ghandi

[GregL]

Like dedndave said,

Code Select Expand

mov DWORD PTR [edx], 10h

is what you need.

[hutch--]

If there is an ambiguity you must specify the actuial SIZE of the immediate you want to move to a memory location. The problem is with the instruction you tried to use,

mov [edx],10h

is that the assembler has no way of knowing whether 10h is a BYTE, WORD or DWORD so it cannot proceed.

[Astro]

I realized that after I wrote the post. It was a "D'OH!" moment.  :cheekygreen:

I initially thought it would assume because [edx] was 32-bit, that the immediate was also 32-bit with it not being defined. Obviously I found out that wasn't the case.

Best regards,
Astro.

[dedndave]

edx does represent a 32-bit address - all addresses in 32-bit code are 32-bits (ignoring seg registers)
but the context of the data at that address is another subject

[Ghandi]

I guess my post about (size) ambiguity was ambiguous itself, thanks for explaining it a little better Hutch. :)

I posted because i've run into this problem when i was first starting and it was annoying until i found the reason. Then it was more annoying to find that it was actually my fault and it was my coding... :P

HR,
Ghandi

[Astro]

 :bg

Thanks everyone!

Best regards,
Astro.