Menu
▾
▴
bastard-libdisasm — libdisasm feature requests and issues
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Kristis M. <kri...@as...> - 2006-03-29 22:17:09
|
libdisasm2 incorrectly inteprets junk bytes as a jump. For example: # quickdis append_linux_2_6_semaphore_trampoline.bin QUICKDIS Disassembly of .text: Intel syntax 0: 8d 42 6c lea eax, [edx+108] 3: e8 c1 d4 0f 00 call 0x000FD4C9 8: e9 1d jmp 0x0000000A While objdump thinks that this is really a: # objdump -D -b binary -m i386 append_linux_2_6_semaphore_trampoline.bin append_linux_2_6_semaphore_trampoline.bin: file format binary objdump: append_linux_2_6_semaphore_trampoline.bin: no symbols Disassembly of section .data: 00000000 <.data>: 0: 8d 42 6c lea 0x6c(%edx),%eax 3: e8 c1 d4 0f 00 call 0xfd4c9 8: e9 .byte 0xe9 9: 1d .byte 0x1d I haven't looked in detail in the internals of libdisasm2 to debug this. What is the state of libdisasm2 ? Will it continue being maintained ? |
|
From: Kristis M. <kri...@as...> - 2006-03-09 19:41:26
|
Hello, I've come across a case where libdisasm2 does not set the size of an invalid instruction properly. I'm using libdisasm2 from CVS as of 2005-08-31, using a patch I once submitted for not dropping invalid instructions (http://sourceforge.net/mailarchive/forum.php?thread_id=8094996&forum_id=36930) Here's what objdump reports: # objdump -D -b binary -m i386 image_invalid_opcode_c0.bin image_invalid_opcode_c0.bin: file format binary objdump: image_invalid_opcode_c0.bin: no symbols Disassembly of section .data: 00000000 <.data>: 0: 8c 10 movl %ss,(%eax) 2: 8c 10 movl %ss,(%eax) 4: 8c 10 movl %ss,(%eax) 6: c0 .byte 0xc0 0xc0 is an invalid instruction, but should still be reported by libdisasm2 as plain data. Here's what I get with libdisasm2: QUICKDIS Disassembly of .text: Intel syntax 0: 8c 10 mov [eax], ss 2: 8c 10 mov [eax], ss 4: 8c 10 mov [eax], ss invalid opcode FFFFFFC0 Adding an instruction of size zero Again, the motivation here is to apply special processing on a function image. If some instruction, or data in code, is interpreted as an invalid opcode and silently dropped, then the function size changes, and any special processing logic applied on it is thrown off. Plus, if this is data in code, some data is lost. I also tried this with the latest disasm2 from sourceforge and I get with x86dis: 00000000 8C 10 mov [eax], ss 00000002 8C 10 mov [eax], ss 00000004 8C 10 mov [eax], ss X86DIS ERROR 'Instruction at RVA extends beyond buffer:' 0x00000006 I was able to fix this problem with the patch that follows. This change has not broken any of my ~30 tests, but I don't know if it breaks anything else. Please apply. Thanks, Kristis =================================================================== --- x86_disasm.c 1 Sep 2005 04:11:55 -0000 1.1 +++ x86_disasm.c 9 Mar 2006 19:43:00 -0000 1.2 @@ -46,12 +46,8 @@ } /* check if we overran the end of the buffer */ - /* FIXME: this may no longer have an effect : move to main - * disasm routine */ - if ( size > len ) { - x86_report_error( report_insn_bounds, (char*)buf_rva + offset ); - return(0); - } + if ( size > len ) + size = len; /* fill rva, offset, and bytes fields of insn */ insn->addr = buf_rva + offset; |
|
From: <kri...@as...> - 2005-09-01 22:43:16
|
> 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]. gcc 3.3.5 compiles pipe_read from linux 2.4.27 with an invalid opcode somewhere in between: pipe_read: ... 1a4: 0f 84 be fe ff ff je 0x68 1aa: 0f 0b ud2a 1ac: 78 00 js 0x1ae 1ae: 20 84 22 c0 e9 b1 fe and %al,0xfeb1e9c0(%edx) 1b5: ff (bad) 1b6: ff 90 8d 74 26 00 call *0x26748d(%eax) 1bc: b9 01 00 00 00 mov $0x1,%ecx Could be somewhat related to their BUG() macro and mixing inline assembly with C source. Improperly generated, sure, but still it happens. Oh well... |
|
From: <kri...@as...> - 2005-09-01 06:57:00
|
Michael, > 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 That corrected the problem. > The code in CVS is pretty close to the last release, I haven't worked > on it in awhile... I imported the latest CVS work. I have ~25 tests manipulating binary images and those pass, so the latest libdisasm2 seems to work. Thanks for maintaining x86_get_rel_offset by the way; I really needed that and it worked like a charm. I'm attaching 1-byte invalid opcode patch in case someone else needs this. Thanks again. Kristis |
|
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> |
|
From: <kri...@as...> - 2005-09-01 01:35:34
|
Hey Mike > 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. I've been going through disasm_addr and noticed that. Will need an extra argument in the function signature I suppose to hold that byte. (I'm still talking 2005-02-27) > 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? I wasn't sure -- it IS always just one byte, isn't it ? There will be subsequent 1 byte invalid opcodes when processing continues, right ? I'm about to test an import of your latest libdisasm from CVS. Seems easier to modify than the 2005-02-27 version I'm running. I just hope it works. Will let you know. THANKS |
|
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> |
|
From: <kri...@as...> - 2005-08-31 22:20:35
|
Hi Michael, It appears that when an invalid opcode is encountered by libdisasm, the insn does not keep any information related to the opcode. It would be nice if the exact bytes that were available as invalid opcodes were still in the data structure, and that insn->size was still set to the size of the invalid code area. For example, if one was going over a list of disassembled instructions and copying them somewhere else, missing the invalid opcodes (due to a 0 size, and no by information) would cause offset problems for other branches inside a function image! This is against libdisasm2 extracted from cvs on 2005-02-27. Is this issue addressed in a newer release ? What is the status of the new release Thanks, Kristis |
|
From: Kristis M. <kri...@as...> - 2005-03-03 04:05:07
|
Hello, I believe that this sequence: 0f 84 a9 fe ff ff je 0x72 0f 0b ud2a 78 00 js 0x1cd 68 36 22 c0 e9 push $0xe9c02236 is turned into: 0f 84 a9 fe ff ff je 0x72 0b 78 00 or 0x0(%eax),%edi 68 36 22 c0 e9 push $0xe9c02236 due to libdisasm2 flagging the "0f" in ud2a's "0f 0b" as invalid and then using the remaining "0b" to incorrectly interpret the "js" into an "or" In particular, quikdis reports: 1c3: jz 0xC013FBF6 invalid opcode 0F 1ca: or edi, [eax] Anyway I can get a patch for this ?? Thanks, Kristis |
|
From: Kristis M. <kri...@as...> - 2005-02-27 21:03:50
|
> * bastard code is no longer being maintained. Could you please update your webpage to reflect that ? > * libdisasm .21 [pre or something] is the latest, HOWEVER the > CVS version has some bug fixes. There are various libdisasm directories in CVS. Is ~/libdisasm the latest ? ~libdisasm/libdisasm ? or ~/src/arch/i386/libdisasm ? > * there is also a new version [rewrite of the decoding algo, > and support for the SSE2/3 crap] in a different dir in > CVS, but it has not been finished -- r/l concerns and all > that. Which one is that ? I need a stable one, whichever that is. > what's up with the mpatrol log? wouldn't valgrind be a better > way of finding where the bug is? Wasn't aware of valgrind. Thanks for the heads up. > anyways, in the middle of something ... will get to your original > email later. Groovy. Thanks. |
|
From: Kristis M. <kri...@as...> - 2005-02-27 20:29:55
|
This adds a uniform way of retrieving a relative offset of an instruction. Is there already a function for this ? If not, please apply. Kristis |
|
From: Michael M. <ma...@ho...> - 2005-02-27 20:26:08
|
take it easy with the CCs there fella ;) haven't had time to reply to your earlier email, but here's the story: * bastard code is no longer being maintained. * libdisasm .21 [pre or something] is the latest, HOWEVER the CVS version has some bug fixes. * there is also a new version [rewrite of the decoding algo, and support for the SSE2/3 crap] in a different dir in CVS, but it has not been finished -- r/l concerns and all that. what's up with the mpatrol log? wouldn't valgrind be a better way of finding where the bug is? anyways, in the middle of something ... will get to your original email later. _m >From: Kristis Makris <kri...@as...> >To: bas...@li..., bas...@li... >Subject: overflow buffer bug >Date: Sun, 27 Feb 2005 12:21:06 -0700 >MIME-Version: 1.0 >Received: from sc8-sf-mx1.sourceforge.net ([66.35.250.206]) by MC8-F4.hotmail.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Feb 2005 11:21:12 -0800 >Received: from mta6.srv.hcvlny.cv.net ([167.206.5.72])by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.41)id 1D5Tyb-0003Ll-5l; Sun, 27 Feb 2005 11:21:13 -0800 >Received: from [192.168.0.30] (ool-44c7579f.dyn.optonline.net [68.199.87.159]) by mta6.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IC...@mt...>; Sun, 27 Feb 2005 14:21:07 -0500 (EST) >X-Message-Info: JGTYoYF78jFslrnrPyNKlf9gfY/RWzU2gbOuR0gSHgM= >X-Mailer: Evolution 2.0.3 >X-Spam-Score: 0.0 (/) >X-Spam-Report: Spam Filtering performed by sourceforge.net.See http://spamassassin.org/tag/ for more details.Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 >Return-Path: kri...@as... >X-OriginalArrivalTime: 27 Feb 2005 19:21:13.0025 (UTC) FILETIME=[800A2B10:01C51D01] > >Hello, > >It appears that there is a buffer overflow problem in libdisasm. This >was discovered using mpatrol and a random .bin file (attached). mpatrol >reports (at the end of this email) that a memory allocation was given a >pointer to a buffer that is corrupted before any data were written to >it. > >This was produced using bastard_src-0.17. > >Is there a fix ? Is this project active or should I stop bothering ? > >Thanks, >Kristis > > >$ dd if=/dev/random of=test.bin bs=1 count=100 100+0 records in >100+0 records out >100 bytes transferred in 0.000747 seconds (133890 bytes/sec) > > >$ mpatrol -g -i -C --dynamic --leak-table --alloc-byte=0x66 >--oflow-byte=0x79 --oflow-size=64 ./testdis test.bin >File name: test.bin >0 1C 14 ;invariant bytes (signature) >0 1C 14 sbb %(null), $0x14 >2 31 A4 57 5B D7 18 E7 ;invariant bytes >(signature) >2 31 A4 57 5B D7 18 E7 xor -18E728A5(%edi, % >edx,02), %(null) >9 2B 72 5A ;invariant bytes (signature) >9 2B 72 5A sub %(null), 5A(%edx) >C 94 ;invariant bytes (signature) >C 94 xchg %(null), %(null) >D 3F ;invariant bytes (signature) >D 3F aas >E 66 EA F4 F4 F4 F4 ;invariant bytes >(signature) >E 66 EA 9D 7D DF A5 jmp *0xA5DF7D9D >14 28 71 1E ;invariant bytes (signature) >14 28 71 1E sub 1E(%ecx), %(null) >17 DB 87 95 83 6B F5 ;invariant bytes >(signature) >17 DB 87 95 83 6B F5 fild -0A947C6B(%edi) >1D 63 E8 ;invariant bytes (signature) >1D 63 E8 arpl %(null), %(null) >1F D9 ;invariant bytes (signature) >1F invalid opcode D9 >20 D9 93 58 0E 24 B7 ;invariant bytes >(signature) >20 D9 93 58 0E 24 B7 fst -48DBF1A8(%ebx) >26 44 ;invariant bytes (signature) >26 44 inc %(null) >27 DF ;invariant bytes (signature) >27 invalid opcode DF >28 08 71 FF ;invariant bytes (signature) >28 08 71 FF or -01(%ecx), %(null) >2B 89 4B 90 ;invariant bytes (signature) >2B 89 4B 90 mov -70(%ebx), %(null) >2E 7A 18 ;invariant bytes (signature) >2E 7A 18 jpe +0x18 >30 15 F4 F4 F4 F4 ;invariant bytes (signature) >30 15 4C 14 9A 96 adc %(null), $-0x969A144C >35 A7 ;invariant bytes (signature) >35 A7 cmpsd %(null), %(null) >36 7C E4 ;invariant bytes (signature) >36 7C E4 jl +0xE4 >38 71 88 ;invariant bytes (signature) >38 71 88 jno +0x88 >3A FB ;invariant bytes (signature) >3A FB sti >3B 6B B0 83 A0 7D 20 90 ;invariant bytes >(signature) >3B 6B B0 83 A0 7D 20 90 imul %(null), >207DA083(%eax), $-0xFFFFFF90 >42 50 ;invariant bytes (signature) >42 50 push %(null) >43 E9 F4 F4 F4 F4 ;invariant bytes (signature) >43 E9 D6 77 A4 9B jmp +0x9BA477D6 >48 F9 ;invariant bytes (signature) >48 F9 stc >49 5B ;invariant bytes (signature) >49 5B pop %(null) >4A AA ;invariant bytes (signature) >4A AA stosb %(null), %(null) >4B 32 FF ;invariant bytes (signature) >4B 32 FF xor %(null), %(null) >4D C9 ;invariant bytes (signature) >4D C9 leave >4E 51 ;invariant bytes (signature) >4E 51 push %(null) >4F 49 ;invariant bytes (signature) >4F 49 dec %(null) >50 10 7A 0E ;invariant bytes (signature) >50 10 7A 0E adc 0E(%edx), %(null) >53 66 3F ;invariant bytes (signature) >53 66 3F aas >55 2C 64 ;invariant bytes (signature) >55 2C 64 sub %(null), $0x64 >57 E4 36 ;invariant bytes (signature) >57 E4 36 in %(null), $0x36 >59 04 68 ;invariant bytes (signature) >59 04 68 add %(null), $0x68 >5B 25 F4 F4 F4 F4 ;invariant bytes (signature) >5B 25 05 4B B1 A2 and %(null), $-0xA2B14B05 >60 A9 F4 F4 F4 F4 ;invariant bytes (signature) >60 A9 48 A4 5F 00 test %(null), >$0x5FA448 >(2148)12:11:46[mkgnu@syd:~/incoming/bastard_src-0.17/src/arch/i386/libdisasm]$ more mpatrol.21399.log >@(#) mpatrol 1.4.8 (02/01/08) >Copyright (C) 1997-2002 Graeme S. Roy > >This is free software, and you are welcome to redistribute it under >certain >conditions; see the GNU Library General Public License for details. > >For the latest mpatrol release and documentation, >visit http://www.cbmamiga.demon.co.uk/mpatrol. > >operating system: UNIX >system variant: Linux >processor architecture: Intel 80x86 >processor word size: 32-bit >object file format: ELF32 >dynamic linker type: SVR4 > >Log file generated on Sun Feb 27 12:11:46 2005 > >read 77 symbols from ./testdis > >LOG: check () [-|-|-] > 0x400457FE ??? > 0x4000C4F6 ??? > 0x40095A52 ??? > 0x4007FDCE ??? > 0x08048661 _start+33 > >system page size: 4096 bytes >default alignment: 4 bytes >overflow size: 64 bytes >overflow byte: 0x79 >allocation byte: 0x66 >free byte: 0x55 >allocation stop: 0 >reallocation stop: 0 >free stop: 0 >unfreed abort: 0 >small boundary: 32 bytes >medium boundary: 256 bytes >large boundary: 2048 bytes >lower check range: 0 >upper check range: 0 >check frequency: 1 >failure frequency: 0 >failure seed: 1109531506 >prologue function: <unset> >epilogue function: <unset> >handler function: <unset> >log file: mpatrol.21399.log >profiling file: mpatrol.21399.out >tracing file: mpatrol.21399.trace >program filename: ./testdis >symbols read: 77 >autosave count: 0 >freed queue size: 0 >allocation count: 29 >allocation peak: 18 (6371 bytes) >allocation limit: 0 bytes >allocated blocks: 15 (755 bytes) >marked blocks: 0 (0 bytes) >freed blocks: 0 (0 bytes) >free blocks: 9 (9613 bytes) >internal blocks: 8 (131072 bytes) >total heap usage: 143360 bytes >total compared: 0 bytes >total located: 0 bytes >total copied: 1547 bytes >total set: 6860 bytes >total warnings: 0 >total errors: 0 > >ERROR: [ALLOVF]: allocation 0x08061080 has a corrupted overflow buffer >at 0x080610A4 > 0x0806109C 79797979 79797979 00000000 79797979 >yyyyyyyy....yyyy > 0x080610AC 79797979 79797979 79797979 79797979 >yyyyyyyyyyyyyyyy > 0x080610BC 79797979 79797979 79797979 79797979 >yyyyyyyyyyyyyyyy > 0x080610CC 79797979 79797979 79797979 79797979 >yyyyyyyyyyyyyyyy > > 0x08061080 (28 bytes) {calloc:15:0} [-|-|-] > 0x08049C1C x86_old_disasm_addr+496 > 0x080488A0 main+400 > 0x4007FDC6 ??? > 0x08048661 _start+33 > > ><< test.bin >> |
|
From: Kristis M. <kri...@as...> - 2005-02-27 20:16:48
|
The directory libdisasm/x86dis should be removed. The Makefile can't produce x86dis if it's contents are there. It's contents are already duplicates of libdisasm/ Kristis |
|
From: Kristis M. <kri...@as...> - 2005-02-27 19:21:08
|
Hello, It appears that there is a buffer overflow problem in libdisasm. This was discovered using mpatrol and a random .bin file (attached). mpatr= ol reports (at the end of this email) that a memory allocation was given= a pointer to a buffer that is corrupted before any data were written to it. This was produced using bastard_src-0.17. Is there a fix ? Is this project active or should I stop bothering ? Thanks, Kristis $ dd if=3D/dev/random of=3Dtest.bin bs=3D1 count=3D100 100+0 records = in 100+0 records out 100 bytes transferred in 0.000747 seconds (133890 bytes/sec) $ mpatrol -g -i -C --dynamic --leak-table --alloc-byte=3D0x66 --oflow-byte=3D0x79 --oflow-size=3D64 ./testdis test.bin File name: test.bin 0 1C 14 ;invariant bytes (signature) 0 1C 14 sbb %(null), $0x14 2 31 A4 57 5B D7 18 E7 ;invariant bytes (signature) 2 31 A4 57 5B D7 18 E7 xor -18E728A5(%edi, % edx,02), %(null) 9 2B 72 5A ;invariant bytes (signature) 9 2B 72 5A sub %(null), 5A(%edx) C 94 ;invariant bytes (signature) C 94 xchg %(null), %(nu= ll) D 3F ;invariant bytes (signature) D 3F aas E 66 EA F4 F4 F4 F4 ;invariant bytes (signature) E 66 EA 9D 7D DF A5 jmp *0xA5DF7D9D 14 28 71 1E ;invariant bytes (signature) 14 28 71 1E sub 1E(%ecx), %(null) 17 DB 87 95 83 6B F5 ;invariant bytes (signature) 17 DB 87 95 83 6B F5 fild -0A947C6B(%ed= i) 1D 63 E8 ;invariant bytes (signature) 1D 63 E8 arpl %(null), %(nu= ll) 1F D9 ;invariant bytes (signature) 1F invalid opcode D9 20 D9 93 58 0E 24 B7 ;invariant bytes (signature) 20 D9 93 58 0E 24 B7 fst -48DBF1A8(%ebx) 26 44 ;invariant bytes (signature) 26 44 inc %(null) 27 DF ;invariant bytes (signature) 27 invalid opcode DF 28 08 71 FF ;invariant bytes (signature) 28 08 71 FF or -01(%ecx), %(null) 2B 89 4B 90 ;invariant bytes (signature) 2B 89 4B 90 mov -70(%ebx), %(null) 2E 7A 18 ;invariant bytes (signature) 2E 7A 18 jpe +0x18 30 15 F4 F4 F4 F4 ;invariant bytes (signature) 30 15 4C 14 9A 96 adc %(null), $-0x969A144C 35 A7 ;invariant bytes (signature) 35 A7 cmpsd %(null), %(nu= ll) 36 7C E4 ;invariant bytes (signature) 36 7C E4 jl +0xE4 38 71 88 ;invariant bytes (signature) 38 71 88 jno +0x88 3A FB ;invariant bytes (signature) 3A FB sti 3B 6B B0 83 A0 7D 20 90 ;invariant bytes (signature) 3B 6B B0 83 A0 7D 20 90 imul %(null), 207DA083(%eax), $-0xFFFFFF90 42 50 ;invariant bytes (signature) 42 50 push %(null) 43 E9 F4 F4 F4 F4 ;invariant bytes (signature) 43 E9 D6 77 A4 9B jmp +0x9BA477D6 48 F9 ;invariant bytes (signature) 48 F9 stc 49 5B ;invariant bytes (signature) 49 5B pop %(null) 4A AA ;invariant bytes (signature) 4A AA stosb %(null), %(nu= ll) 4B 32 FF ;invariant bytes (signature) 4B 32 FF xor %(null), %(null) 4D C9 ;invariant bytes (signature) 4D C9 leave 4E 51 ;invariant bytes (signature) 4E 51 push %(null) 4F 49 ;invariant bytes (signature) 4F 49 dec %(null) 50 10 7A 0E ;invariant bytes (signature) 50 10 7A 0E adc 0E(%edx), %(null) 53 66 3F ;invariant bytes (signature) 53 66 3F aas 55 2C 64 ;invariant bytes (signature) 55 2C 64 sub %(null), $0x64 57 E4 36 ;invariant bytes (signature) 57 E4 36 in %(null), $0x36 59 04 68 ;invariant bytes (signature) 59 04 68 add %(null), $0x68 5B 25 F4 F4 F4 F4 ;invariant bytes (signature) 5B 25 05 4B B1 A2 and %(null), $-0xA2B14B05 60 A9 F4 F4 F4 F4 ;invariant bytes (signature) 60 A9 48 A4 5F 00 test %(null), $0x5FA448 (2148)12:11:46[mkgnu@syd:~/incoming/bastard_src-0.17/src/arch/i386/li= bdisasm]$ more mpatrol.21399.log @(#) mpatrol 1.4.8 (02/01/08) Copyright (C) 1997-2002 Graeme S. Roy This is free software, and you are welcome to redistribute it under certain conditions; see the GNU Library General Public License for details. For the latest mpatrol release and documentation, visit http://www.cbmamiga.demon.co.uk/mpatrol. operating system: UNIX system variant: Linux processor architecture: Intel 80x86 processor word size: 32-bit object file format: ELF32 dynamic linker type: SVR4 Log file generated on Sun Feb 27 12:11:46 2005 read 77 symbols from ./testdis LOG: check () [-|-|-] 0x400457FE ??? 0x4000C4F6 ??? 0x40095A52 ??? 0x4007FDCE ??? 0x08048661 _start+33 system page size: 4096 bytes default alignment: 4 bytes overflow size: 64 bytes overflow byte: 0x79 allocation byte: 0x66 free byte: 0x55 allocation stop: 0 reallocation stop: 0 free stop: 0 unfreed abort: 0 small boundary: 32 bytes medium boundary: 256 bytes large boundary: 2048 bytes lower check range: 0 upper check range: 0 check frequency: 1 failure frequency: 0 failure seed: 1109531506 prologue function: <unset> epilogue function: <unset> handler function: <unset> log file: mpatrol.21399.log profiling file: mpatrol.21399.out tracing file: mpatrol.21399.trace program filename: ./testdis symbols read: 77 autosave count: 0 freed queue size: 0 allocation count: 29 allocation peak: 18 (6371 bytes) allocation limit: 0 bytes allocated blocks: 15 (755 bytes) marked blocks: 0 (0 bytes) freed blocks: 0 (0 bytes) free blocks: 9 (9613 bytes) internal blocks: 8 (131072 bytes) total heap usage: 143360 bytes total compared: 0 bytes total located: 0 bytes total copied: 1547 bytes total set: 6860 bytes total warnings: 0 total errors: 0 ERROR: [ALLOVF]: allocation 0x08061080 has a corrupted overflow buffe= r at 0x080610A4 0x0806109C 79797979 79797979 00000000 79797979 yyyyyyyy....yyyy 0x080610AC 79797979 79797979 79797979 79797979 yyyyyyyyyyyyyyyy 0x080610BC 79797979 79797979 79797979 79797979 yyyyyyyyyyyyyyyy 0x080610CC 79797979 79797979 79797979 79797979 yyyyyyyyyyyyyyyy 0x08061080 (28 bytes) {calloc:15:0} [-|-|-] 0x08049C1C x86_old_disasm_addr+496 0x080488A0 main+400 0x4007FDC6 ??? 0x08048661 _start+33 |
|
From: <ben...@id...> - 2004-05-25 09:52:37
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Michael M. <ma...@ho...> - 2004-01-25 19:35:39
|
Quick update... The following are things that need to be done on libdisasm to prepare it for a release: 1. Testing of correct SSE and SSE2 instruction disassembly 2. Testing of x86dis to see if it does as advertised 3. Writing of perl, python, tcl, etc wrappers for libdisasm 4. Rewriting i386.c to no longer use bastard-specific calls for things such as register id->name mapping, address expression generation, and so forth. Instruction disassembly should be entirely self-contained and generate an x86_insn_t, not a code struct -- the old bastard ARCH extension way of doing things is being phased out. Any volunteers? ;P _m _________________________________________________________________ There are now three new levels of MSN Hotmail Extra Storage! Learn more. http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1 |
|
From: Michael M. <ma...@ho...> - 2004-01-20 00:33:57
|
OK, there is a new version in the SF d/l section for you to play with. Features: * 'make install' does something * removed from bastard source tree * RAW and XML formatting is [mostly] done - thanks xvr! * very rudimentary man pages have been provided * x86dis command line utility has been written -- a bytestream disassembler OK, there a few gotchas to look out for: + RAW and XML 'missing things' + x86dis acting a bit funky with -r and '-1' for len + P4 opcodes may or may not be working As usual, report any bugs... _m _________________________________________________________________ Rethink your business approach for the new year with the helpful tips here. http://special.msn.com/bcentral/prep04.armx |
|
From: Rakan El-K. <ra...@we...> - 2003-12-15 17:14:09
|
Sure I can do this. Np. But, it would be helpful that next time around yo= u sent me all of the files I need ... As it is, there are a bunch of things missing, and I fixed a problem in libdis.c (format_raw_insn). And also, x86dis won't compile because you initialize a structure with stdin/stdout/stderr, which are not constants. Did you try to compile before sending the files to me? :) Dude this is really not going to be easy if we're going to be sending files like this to each other.. Thx, R. > Well, the format_xml_insn() and format_raw_insn() in libdis.c need to be > written -- preferably in the same manner as the intel/att/native ones, wh= ere > an operand or a mnemonic can be formatted and printed on their own. >=20 > Also, x86dis.c needs to be written -- the file right now has a main(), ar= g > processing, and basically sets everything up for disassembly. Needs to ha= ve > the lidisasm 'umf' added to it. >=20 > The files are attached. libdis.h needs to be updated so that enum > x86_asm_format has the XML and raw syntax as used in libdis.c. >=20 > _m >=20 >=20 >> w00t. >>=20 >> What can I do to help? >>=20 >> R. >>=20 >=20 > _________________________________________________________________ > Cell phone =91switch=92 rules are taking effect =97 find out more here. > http://special.msn.com/msnbc/consumeradvocate.armx >=20 --=20 Until lions have their historians, tales of the hunt shall always glorify the hunter. -- African Proverb |
|
From: Rakan El-K. <ra...@we...> - 2003-12-10 07:53:05
|
Cool -- I'll get to this early next week -- paper due on Thursday + time to catch up on social life. R. > Well, the format_xml_insn() and format_raw_insn() in libdis.c need to be > written -- preferably in the same manner as the intel/att/native ones, wh= ere > an operand or a mnemonic can be formatted and printed on their own. >=20 > Also, x86dis.c needs to be written -- the file right now has a main(), ar= g > processing, and basically sets everything up for disassembly. Needs to ha= ve > the lidisasm 'umf' added to it. >=20 > The files are attached. libdis.h needs to be updated so that enum > x86_asm_format has the XML and raw syntax as used in libdis.c. >=20 > _m >=20 >=20 >> w00t. >>=20 >> What can I do to help? >>=20 >> R. >>=20 >=20 > _________________________________________________________________ > Cell phone =91switch=92 rules are taking effect =97 find out more here. > http://special.msn.com/msnbc/consumeradvocate.armx >=20 --=20 In considering any new subject, there is frequently a tendency, first, to overrate what we find to be already interesting or remarkable; and, secondly, by a sort of natural reaction, to undervalue the true state of th= e case, when we do discover that our notions have surpassed those that were really tenable. -- Lady Lovelace |
|
From: Michael M. <ma...@ho...> - 2003-12-10 00:08:01
|
Well, the format_xml_insn() and format_raw_insn() in libdis.c need to be written -- preferably in the same manner as the intel/att/native ones, where an operand or a mnemonic can be formatted and printed on their own. Also, x86dis.c needs to be written -- the file right now has a main(), arg processing, and basically sets everything up for disassembly. Needs to have the lidisasm 'umf' added to it. The files are attached. libdis.h needs to be updated so that enum x86_asm_format has the XML and raw syntax as used in libdis.c. _m >w00t. > >What can I do to help? > >R. > _________________________________________________________________ Cell phone switch rules are taking effect find out more here. http://special.msn.com/msnbc/consumeradvocate.armx |
|
From: Rakan El-K. <ra...@we...> - 2003-12-08 20:22:39
|
w00t. What can I do to help? R. >=20 > OK, This should be the first message of the ML. >=20 > Last week I mucked about with CVS and broke libdisasm off into its own > module; > it can now be checked out by doing >=20 > cvs -dus...@cv...:/cvsroot/bastard co libdisasm >=20 > The bastard has been put into its own module; maintenance of 0.17 will mo= st > likely die off, and development will commence with 2.0 in the bastard2 > module next year. >=20 > Currently I am working on SSE2 disassembly in libdisasm; it is mostly don= e, > with the tedious task of fillinf the SSE2 opcode tables remaining. Once t= hat > is finished, I will have to add XML and 'raw' formats to the "at&t, intel= , > native" asm formatting that libdisasm does. >=20 > An addition to libdisasm is the x86dis command-line utility. This is > half-written; when complete, it will allow arbitrary addresses in a file = to > be disassembled. Typical unix convention will apply; you will be able to = do > a > cat /bin/ls | x86dis -s intel -e 0x8040100 | grep call > and it will work as expected. >=20 > At some point I plan on writing Perl and Python wrappers for libdisasm, i= f > no-one beats me to it. Other languages such as Tcl, Java, Ruby, Ocaml, et= c I > am not particularly interested in. >=20 >=20 > The SSE2 support and the x86dis utility will result in libdisasm 0.21.0; > Perl and Python modules will probably appear in 0.22.0. >=20 > _m >=20 > _________________________________________________________________ > Shop online for kids=92 toys by age group, price range, and toy category at > MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Bastard-libdisasm mailing list > Bas...@li... > https://lists.sourceforge.net/lists/listinfo/bastard-libdisasm >=20 --=20 "bouncy bouncy" -- Monty Python |
|
From: Michael M. <ma...@ho...> - 2003-12-08 14:11:14
|
OK, This should be the first message of the ML. Last week I mucked about with CVS and broke libdisasm off into its own module; it can now be checked out by doing cvs -dus...@cv...:/cvsroot/bastard co libdisasm The bastard has been put into its own module; maintenance of 0.17 will most likely die off, and development will commence with 2.0 in the bastard2 module next year. Currently I am working on SSE2 disassembly in libdisasm; it is mostly done, with the tedious task of fillinf the SSE2 opcode tables remaining. Once that is finished, I will have to add XML and 'raw' formats to the "at&t, intel, native" asm formatting that libdisasm does. An addition to libdisasm is the x86dis command-line utility. This is half-written; when complete, it will allow arbitrary addresses in a file to be disassembled. Typical unix convention will apply; you will be able to do a cat /bin/ls | x86dis -s intel -e 0x8040100 | grep call and it will work as expected. At some point I plan on writing Perl and Python wrappers for libdisasm, if no-one beats me to it. Other languages such as Tcl, Java, Ruby, Ocaml, etc I am not particularly interested in. The SSE2 support and the x86dis utility will result in libdisasm 0.21.0; Perl and Python modules will probably appear in 0.22.0. _m _________________________________________________________________ Shop online for kids toys by age group, price range, and toy category at MSN Shopping. No waiting for a clerk to help you! http://shopping.msn.com |