vmt / udis86

Disassembler Library for x86 and x86-64
http://udis86.sourceforge.net
BSD 2-Clause "Simplified" License
1.01k stars 295 forks source link

Error in asm_buf management. After coping structure ud by 'operator=' asm_buf of the new object points to asm_buf_int of the previous object. #94

Open hasherezade opened 9 years ago

hasherezade commented 9 years ago

After coping structure ud by 'operator=' asm_buf of the new object points to asm_buf_int of the previous object.

Problem ilustration:

original object: ud_obj:

asm_buf: 1df318 asm_buf_int: 1df318 SAME! 0000000000000000 3132 xor [edx], esi

copied object u2:(struct ud u2 = ud_obj)

asm_buf: 1df318 asm_buf_int: 1df598 DIFF! 0000000000000000 3132 xor [edx], esi

Code used for the test: https://gist.github.com/hasherezade/85a81b61f4a56be5a96d

Consequences:

If this issue will not be solved problems will be occuring: the new object will be overwriting buffer of previous object. or - if the previous object no longer exists - it will be writing to unallocated memory.

Proposed solution:

Problem can be solved either by implementing expliclitly operator= for struct ud, or by changing the policy of chosing active buffer.

in7egral commented 8 years ago

Another possible solution - do not use asm_buf. If udis86 used by C++ code, asm string can be got with something like this std::string(var_ud.asm_buf_int, var_ud.asm_buf_size).

But, anyway it's bad design of ud_t. I suppose, ud_insn_asm should be rewritten:

const char*
ud_insn_asm(const struct ud* u)
{
  //return u->asm_buf;
  return u->asm_buf_int; // it's normal conversation for C due to 'const' keyword
}