|
From: Michael M. <ma...@ho...> - 2005-09-01 01:21:58
|
That behavior is by design, and not so simple to change; internally, size is the return value of the disassembly routines, with INVALID_INSN (-1) returned instead of size if the instruction is invalid. An invalid instruction has no size, really, and using the point where decoding fails is not necessarily accurate. A compromise would be to set the size of an invalid instruction to 1 byte, and copy that byte into the x86_insn_t -- would that be sufficient? _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>bas...@li...</i><br>Subject: <i>[Bastard-libdisasm] Data kept for invalid instructions</i><br>Date: <i>Wed, 31 Aug 2005 15:19:57 -0700 (MST)</i><br>MIME-Version: <i>1.0</i><br>X-Originating-IP: <i>67.40.69.52</i><br>Received: <i>from mc1-f24.hotmail.com ([64.4.50.31]) by imc3-s40.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 15:21:18 -0700</i><br>Received: <i>from lists-outbound.sourceforge.net ([66.35.250.225]) by mc1-f24.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 Aug 2005 15:21:18 -0700</i><br>Received: <i>from projects.sourceforge.net (sc8-sf-list2-b.sourceforge.net [10.3.1.8])by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTPid A5D4732FCB; Wed, 31 Aug 2005 15:21:17 -0700 (PDT)</i><br>Received: <i>from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net)by sc8-sf-list2.sourceforge.net with esmtp (Exim 4.30)id 1EAawc-0004DB-NPfor bas...@li...; Wed, 31 Aug 2005 15:20:34 -0700</i><br>Received: <i>from post5.inre.asu.edu ([129.219.110.120])by mail.sourceforge.net with esmtp (Exim 4.44)id 1EAawb-0007oj-Ezfor bas...@li...; Wed, 31 Aug 2005 15:20:34 -0700</i><br>Received: <i>from conversion.post5.inre.asu.edu by asu.edu (PMDF V6.1-1X6 #30769) id <0IM...@as...> for bas...@li...; Wed, 31 Aug 2005 15:20:06 -0700 (MST)</i><br>Received: <i>from webmail2.asu.edu (webmail2.asu.edu [129.219.117.231]) by asu.edu (PMDF V6.1-1X6 #30769) with ESMTP id <0IM...@as...>; Wed, 31 Aug 2005 15:20:06 -0700 (MST)</i><br>Received: <i>(from emma@localhost) by webmail2.asu.edu (8.12.9/8.12.9/Submit) id j7VMJv8s018423; Wed, 31 Aug 2005 15:19:57 -0700</i><br>>Hi Michael,<br>><br>>It appears that when an invalid opcode is encountered by libdisasm, the insn<br>>does not keep any information related to the opcode. It would be nice if the<br>>exact bytes that were available as invalid opcodes were still in the data<br>>structure, and that insn->size was still set to the size of the invalid code area.<br>><br>>For example, if one was going over a list of disassembled instructions and<br>>copying them somewhere else, missing the invalid opcodes (due to a 0 size, and<br>>no by information) would cause offset problems for other branches inside a<br>>function image!<br>><br>>This is against libdisasm2 extracted from cvs on 2005-02-27. Is this issue<br>>addressed in a newer release ? What is the status of the new release<br>><br>>Thanks,<br>>Kristis<br>><br>><br>>-------------------------------------------------------<br>>SF.Net email is Sponsored by the Better Software Conference & EXPO<br>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices<br>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA<br>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf<br>>_______________________________________________<br>>Bastard-libdisasm mailing list<br>>Bas...@li...<br>>https://lists.sourceforge.net/lists/listinfo/bastard-libdisasm<br></font></BLOCKQUOTE> |