FLAG_LOCK not set when destination is a register

[GoogleCodeExporter]

First, technically it is an error to use the lock prefix when the destination 
is a register. However, distorm does decompose the byte streams that result in 
this and does not set FLAG_LOCK. 

Also, it does appear that some older processors may have allowed the lock 
prefix on these instructions without throwing an exception. Modern processors 
will throw an exception.

In what mode did you try to disassemble (16/32/64)?
32 and 64bit

What is the input buffer (binary stream) you used to reproduce the problem?
f093   lock xchg eax, ebx
f089d8 lock mov eax, ebx
f0ffc0 lock inc eax

What is the expected output (or what instruction)?
1 of 2 things:
1) I would expect FLAG_LOCK to be set.
-OR-
2) fail to disassemble

Which tool did you use to see the expected output?
ndisasm will display these as shown above. (BTW, these also compile with nasm 
and yasm. Haven't tried other compilers.)

What do you see instead?
Since FLAG_LOCK is not set, Decode shows the instruction without the lock 
prefix, even though the byte sequence will contain f0 showing there is a prefix.

What version of diStorm are you using? On what platform (Python/EXE/other)?
distorm 3.3 on Linux, using python interface

Please provide any additional information below.

Original issue reported on code.google.com by mnor...@cerodias.com on 15 Aug 2013 at 2:31

[GoogleCodeExporter]

I looked into the issue and found the problem. I have attached a patch that 
addresses the issue by making the use of a lock prefix when the destination is 
a register return undecodeable. Also realized that a decode failure when a lock 
prefix is present could be due to the instruction not being lockable (e.g. mov 
eax, ebx) and the current code seems to discard all of the prefix if there is a 
decode error. So if the lock prefix was present, discard all bytes up to and 
including the lock prefix, but keep everything after and try to decode again. 
There's probably a better way to do it other than what I've supplied.

for 64bit
48f093 should become DB 43; DB f0; xor eax, ebx
f04893 should become DB f0; xor rax, rbx

Original comment by mnor...@cerodias.com on 17 Aug 2013 at 2:37

Attachments:

• distorm3.lockpfx.diff

[GoogleCodeExporter]

Hi

This is by design, it's an invalid prefix. I wanted to ignore such prefixes on 
purpose so people can still see the instructions, maybe invalid instruction is 
too much.
Anyway, if you use the decompose interface, there's the unusedPrefixesMask you 
can examine for such cases.

Original comment by distorm@gmail.com on 27 Aug 2013 at 6:27