Don't trust IDAPRO's disassembling listings all the time
krad <cradnilgmailcom> Sunday, March 30 2008 04:54.04 CDT


IDAPRO ala, is the industrial standard disassembler, But to my suprise, there are defect in basic disassembling functionality, two bugs are present:

seg000:00000000 85 D8                     test    ebx, eax

seg000:00000002 00                                db    0
seg000:00000003 00                                db    0

is the actual disasm of NASM's output of:

use32
test eax, ebx
add     [eax], al




Comments
bw Posted: Sunday, March 30 2008 08:06.31 CDT
and what's the first bug? different order of EBX and EAX in TEST? But it depends on the compiler very often. Try to compile it also with MASM or FASM

and about the second ehem "bug", can't you just convert it to code with 'C'?

krad Posted: Sunday, March 30 2008 08:54.30 CDT
the first bug is the order, it's ok for human, it would confuse  some automatic tools just as in my case.

the second bug is that the disassembler engine can't deal with this 00 00 encoding yet. "C" magic has no effect.

igorsk Posted: Sunday, March 30 2008 09:21.32 CDT
See processor options.

Disassemble zero opcode instructions

       This option allows ida to disassemble the following instructions:

       00 00      add [bx+si], al      ; 16 bit
       00 00      add [eax], al        ; 32 bit

       Usually this option is disabled

QvasiModo Posted: Sunday, March 30 2008 15:22.35 CDT
the first "bug" is not a bug. both instructions (test eax, ebx) and (test ebx, eax) are exactly the same and assemble to the same sequence of bytes. that's because the result of the AND bitwise operation does not change with the order of the parameters.

the second "bug" is not a bug either. IDA actually did you a favor and recognized a rather contrived series of instructions as data, since when you have a sequence of null bytes it's more likely data than code. the (add [eax], al) instruction assembles as a sequence of zeroes.

krad Posted: Sunday, March 30 2008 20:25.11 CDT
thanks to igorsk for pointing out that the second is not a bug.

QvasiModo, I've stated above that the first bug is ok for man, but it would confuse the automatic tools, I'am trying to reassemble the assembbly and would to get the same binary sequences as it is. Because I would rehash the binary sequence for validation, SO the story begins. However, this is not a major defect.

bw Posted: Monday, March 31 2008 08:26.57 CDT
QvasiMode it's not the same in binary:

test r32, r32 = 0x85, 0xC0 | (cDst << 3) | cSrc

tOpO Posted: Monday, March 31 2008 08:52.27 CDT
bw,

   Qvasimodo is right. The TEST instruction performs a bit-wise logical AND between the two operands, updates the flags registers and not saving the result.
Please refer to Intel documentation.

Sellmi Posted: Tuesday, April 1 2008 02:40.09 CDT
>However, this is not a major defect.

major defect ? This is nothing at all.
there are many ways to encode a menemonic!

please read olly's post for XOR EAX,EAX
(April 17, 2007 - Command search.)
http://www.ollydbg.de/version2.html

morel Posted: Tuesday, April 1 2008 14:34.33 CDT
@tOpO

85,d8 = test eax, ebx
85,c3 = test ebx, eax

this is what bw meant

krad Posted: Wednesday, April 2 2008 07:29.50 CDT
>major defect ? This is nothing at all.

It totally depends on one's opinion. If you think that the same disassembing result can be acceptable only if they have the same meanings, you can get lots of them:

xchg edx, ecx => xchg ecx, edx

even:

test eax, ebx
mov eax, 3
jz dest

can be coded (or disassembled) as:

and eax, eax
mov eax, 3
jz dest

but should a disassembler do this? it's depends on your opinion. In my case, I'd like the disassembler to do what exactly documented by the Intel Specification.

Sellmi, I've stated that you might not read above that: This is ok for humanbeings but will do some difference for automatic tools for special purpose, isn't obvious?

krad Posted: Wednesday, April 2 2008 07:33.53 CDT
and eax, eax => should be and eax, ebx