Memory operand problems

[mineiro]

I can compile this, but I get wrong results.

Code Select Expand


xor ecx,[edx+30303030h]

Can anybody more experience explain please.
regards.

[dedndave]

lol - that's an odd bump to an old thread
but, i am sure you are getting the correct results, for the code as shown
thing is - we can't tell you much without seeing the rest of the routine
it appears as though they are trying to convert 4 decimal bytes to ASCII with one instruction
although it is a little messed up - lol

you might see...

Code Select Expand

lea ecx,[edx+30303030h]
but, with XOR, they are going to get some strange results because edx+30303030h is likely to address some unpredictable data

[mineiro]

snippet source is:

Code Select Expand


atol_m proc lpSrc:DWORD
xor ecx,ecx
xor eax,eax
xor ecx,[edx+30303030h]
xor ecx,ecx
xor eax,eax
ret
atol_m endp

In olly I get this:

Code Select Expand


Address   Hex dump          Command                                  Comments
00401298   $  33C9          XOR ECX,ECX
0040129A   .  33C0          XOR EAX,EAX
0040129C      33            DB 33                                    ; CHAR '3'
0040129D  /.  8A30          MOV DH,BYTE PTR DS:[EAX]
0040129F  |.  3030          XOR BYTE PTR DS:[EAX],DH
004012A1  |.  3033          XOR BYTE PTR DS:[EBX],DH
004012A3  |.  C9            LEAVE
004012A4  |.  33C0          XOR EAX,EAX
004012A6  \.  C3            RETN

regards

[dedndave]

hmmmmm
it looks like olly is not aligned with the code - lol
it is not interpreting the 338A30303030 as a valid opcode, which i think it is
it is as though it is trying to disassemble it as 16-bit code - but i think the opcode would be valid there, too
something is very strange - there are no segment overrides

but, there is something wrong with the proc, too
i don't see where the lpSrc pointer value is loaded into a register
and - xor ecx,[edx+30303030h] is still going to get you garbage
at any rate, whatever is in ECX gets zeroed in the next line
where did you get this snippet ? - lol

[mineiro]

thank you for the answer Sr dedndave, this is only a test while I'm trying to write this procedure.
the code is align 16, so maybe this is the answer, I will try this one and later post here.
My idea is deal with this number on the fly (like a mask), without aloc it in .data session. You're right, the lpSrc is done nothing in this example. But if I do
xor ecx,[edx+3h] I get right results.
Thank you Sr.
regards.

[mineiro]

I changed the code(created with an wizard win32 in radasm)  and I'm getting access violation, so I presume it works, but in olly this give strange disasm.

Code Select Expand


xor eax,eax
here:
mov edx,offset here
xor ecx,[edx+3]
...

So, sorry for posting in wrong topic.
regards.

[MichaelW]

Code Select Expand


xor eax,eax
here:
mov edx,offset here
xor ecx,[edx+3]


The code runs OK for me.

[mineiro]

This code works here too Sr MichaelW, I have an illusion because ollydgb don't disasm this well.
Can anybody check the disasm of "xor ecx,[edx+30303030h]"
regards and thank you.

edited after
can anybody post the disasm of this proc:
disasm_test proc
xor ecx,ecx      
xor eax,eax
here:
xor edx,offset here
xor ecx,[edx+3333c090h]
xor ecx,[edx+909090h]
xor ecx,ecx
xor eax,eax
disasm_test endp

[brethren]

try deleting the udd file then run it through olly again

[dedndave]

this is generated by the assembler using the /Fl switch

Code Select Expand

00000013 disasm_test proc
00000013  33 C9 xor ecx,ecx     
00000015  33 C0 xor eax,eax
00000017 here:
00000017  81 F2 00000017 R xor edx,offset here
0000001D  33 8A 3333C090 xor ecx,[edx+3333c090h]
00000023  33 8A 00909090 xor ecx,[edx+909090h]
00000029  33 C9 xor ecx,ecx
0000002B  33 C0 xor eax,eax
0000002D disasm_test endp
here it is using a simple disassembler

Code Select Expand

:00401013 33C9                    xor ecx, ecx
:00401015 33C0                    xor eax, eax
:00401017 81F217104000            xor edx, 00401017
:0040101D 338A90C03333            xor ecx, dword[edx+3333C090]
:00401023 338A90909000            xor ecx, dword[edx+00909090]
:00401029 33C9                    xor ecx, ecx
:0040102B 33C0                    xor eax, eax

[donkey]

Here is a disassembly of the code you posted (without the stack frame stuff)

Code Select Expand

0040195A >/$ 31C9           XOR ECX,ECX
0040195C  |. 31C0           XOR EAX,EAX
0040195E  |. 81F2 5E194000  XOR EDX,40195E
00401964  |. 338A 90C03333  XOR ECX,DWORD PTR DS:[EDX+3333C090]
0040196A  |. 338A 90909000  XOR ECX,DWORD PTR DS:[EDX+909090]
00401970  |. 31C9           XOR ECX,ECX
00401972  |. 31C0           XOR EAX,EAX

Though the code makes little sense and will only lead to an access violation since the addresses you are using are not dereferenced.

Edgar

[mineiro]

Thank you for the answers.
In the first moment, I thinked that can be the odd/even address location of opcode in memory, but now I see that this is not true.
In second moment, i thinked that can be compiler ineficience (this is why I posted this one in that part of topic).
In the answer of sr donkey the first line produce opcode "31c9 31c0"h and in dedndave "33c9 33c0"h. In mine "33c9"h too, so I select this piece of code in ollydbg and click in "remove analysis from selection" to give right disasm, after deleting the .udd file.
Why the same code produce diferent opcodes is what I'm trying to understand now.
regards.

[redskull]

I seem to remember a thread about how MASM had a bug when compiling XOR, but since both operands are the same, it made no difference.

-r

[mineiro]

Yes sr redsdull, this makes no diference at all, because is like "mov ???,00". In my tests I do some referencing to a register, but now I erased it after so much tests. I simply cannot reproduce it again, but if I remember well, is something like:
xor ecx,ecx      
xor al,[edx+ecx+3]
xor cl,[ecx+ebx]
I'm using XOR here, because with xor you can [mov+cmp] in the same time, or "sub,add,zero,"... doing this while processors don't create a NAND opcode and mnemonic.
regards.

[dedndave]

 :bg
interesting to see the term "NAND" in here - lol
you must be in electronics
there is also no "NOR", or "XNOR"   :P
they would be handy sometimes

there are several instructions that have multiple valid coding
the assembler usually picks the shorter one, if any, because the performance is otherwise the same for most of these