Menu
▾
▴
RE: [Bastard-libdisasm] Data kept for invalid instructions
|
From: Michael M. <ma...@ho...> - 2005-09-01 03:40:58
|
Heya Kristis, Yeah, the disasm routines that call disasm_address always advance one byte when they encounter an invalid instruction. Invalid opcodes could be from 1-3 bytes though, if you include invalid opcodes cause by a ModR/M opcode extension following a two-byte opcode. 3DNow instructions could prove tricky as well, since the last opcode byte is at the end of the insn. I think fixing up the x86_insn_t in the disasm_addr function to return a 1-byte invalid instruction is the best way to go. Retaining the number of invalid bytes encountered does not really help anyone, since the real instruction could start anywhere in that range. A 1-byte invalid insn could at least be useful when dealing with off-by-one anti-disasm code [though even then, only if it is improperly written]. _m The code in CVS is pretty close to the last release, I haven't worked on it in awhile... _m <BLOCKQUOTE style='PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #A0C6E5 2px solid; MARGIN-RIGHT: 0px'><font style='FONT-SIZE:11px;FONT-FAMILY:tahoma,sans-serif'><hr color=#A0C6E5 size=1> From: <i>kri...@as...</i><br>To: <i>Michael Mondragon <ma...@ho...></i><br>CC: <i>kri...@as..., bas...@li...</i><br>Subject: <i>RE: [Bastard-libdisasm] Data kept for invalid instructions</i><br>Date: <i>Wed, 31 Aug 2005 18:33:40 -0700 (MST)</i><br>MIME-Version: <i>1.0</i><br>X-Originating-IP: <i>149.169.177.21</i><br>Received: <i>from post5.inre.asu.edu ([129.219.110.120]) by mc2-f40.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 18:35:42 -0700</i><br>Received: <i>from conversion.post5.inre.asu.edu by asu.edu (PMDF V6.1-1X6 #30769) id <0IM...@as...> for ma...@ho...; Wed, 31 Aug 2005 18:33:46 -0700 (MST)</i><br>Received: <i>from webmail1.asu.edu (webmail1.asu.edu [129.219.117.230]) by asu.edu (PMDF V6.1-1X6 #30769) with ESMTP id <0IM...@as...>; Wed, 31 Aug 2005 18:33:46 -0700 (MST)</i><br>Received: <i>(from emma@localhost) by webmail1.asu.edu (8.12.9/8.12.9/Submit) id j811XeBf031897; Wed, 31 Aug 2005 18:33:40 -0700</i><br>>Hey Mike<br>><br>> > That behavior is by design, and not so simple to change; internally,<br>> > size is<br>> > the return value of the disassembly routines, with INVALID_INSN (-1)<br>> > returned instead of size if the instruction is invalid.<br>><br>>I've been going through disasm_addr and noticed that. Will need an extra<br>>argument in the function signature I suppose to hold that byte. (I'm still<br>>talking 2005-02-27)<br>><br>> > A compromise would be to set the size of an invalid instruction to<br>> > 1 byte, and copy that byte into the x86_insn_t -- would that be<br>> > sufficient?<br>><br>>I wasn't sure -- it IS always just one byte, isn't it ? There will be subsequent<br>>1 byte invalid opcodes when processing continues, right ?<br>><br>>I'm about to test an import of your latest libdisasm from CVS. Seems easier to<br>>modify than the 2005-02-27 version I'm running. I just hope it works. Will let<br>>you know.<br>><br>>THANKS<br></font></BLOCKQUOTE> |
