announce: my very first disassembler now available (GPL)
in [ASM]
|
From: NathanCBaker on 13 Aug 2008 16:58 On Aug 13, 3:43 pm, "Wolfgang Kern" <nowh...(a)never.at> wrote: > Nathan wrote: > > > I think that Wolfgang's 'disass.com' might contain both 16- and 32-bit > > code. Can we make crudasm (and maybe ndisasm) "switch gears" in the > > middle of a disassembly? > > Why not ? > a disassembler could be able to detect code flow and mode changes within > the code under test also in a static analysis and insert 'use16/use32'. > And that's just one point why I designed my 'DisAss core' this way. What was the other reason? Every "hillfolk" farmer wants 'DisAss' to be better than 'DatAss'. :) But, would it be a "waste of time" (except as a learning experience) to perfect that feature? Combined 16/32-bit code is rare (not counting the DOS-stub in PE files). Probably better to spend time teaching the disassembler how to interpret PE and Elf headers so the user doesn't waste time guessing the "magic parameters". Nathan.
From: Chuck Crayne on 13 Aug 2008 18:23 On Wed, 13 Aug 2008 11:08:21 -0700 (PDT) NathanCBaker(a)gmail.com wrote: > Can we make crudasm (and maybe ndisasm) "switch gears" in the > middle of a disassembly? ndisasm can effectively do this now, although one would have to invoke it more than once, and combine the results, but it would be fairly easy to enhance ndisasm to do it all in a single pass. In fact, some time ago, I looked at what it would take for it to pick up the required parameters from the ELF header. However, actually implementing it is pretty low on my priority list, because most people in the ELF world already use objdump in preference to ndisasm. -- Chuck http://www.pacificsites.com/~ccrayne/charles.html
From: Rod Pemberton on 13 Aug 2008 20:48 "Willow" <wrschlanger(a)gmail.com> wrote in message news:c18865be-c40e-4e7b-8df9-fcd28f29cfa4(a)8g2000hse.googlegroups.com... > I just finished my very own disassembler, written from scratch. It > takes a 750-line input script file that specifies the x86 and x86-64 > instruction set, and produces a disassembler. Unlike other > disassemblers, mine is enjoyable to work on because it is coherent, > you have a script file that makes sense (to me at least :-) rather > than a bunch of incoherent and often buggy opcode tables copied from > an Intel manual. > > You should check it out and let me know what you think! > It's called crudasm, the crude disassembler. Right now it only works > in 16 and 32 bit mode, and only supports raw binary files (e.g. no PE > etc. files). > > You can find it here: http://code.google.com/p/vm64dec/downloads/list > Here are just a few differences between NASM's Ndisasm and Crudasm1: Ndisasm (0.98.39): 00000000 1499 adc al,0x99 00000002 1433 adc al,0x33 00000004 2433 and al,0x33 00000006 660FC8 bswap eax 00000009 6699 cdq 0000000B 3C33 cmp al,0x33 0000000D 0FA606EEBB cmpxchg486 [0xbbee],al Crudasm1: 00000000 adc dh,0x99 00000002 adc dh,0x33 00000004 and dh,0x33 00000006 o32 bswap 00000009 o32 cdq 0000000b cmp dh,0x33 0000000d db 0x0f 0000000e cmps byte [si],byte [es:di] 0000000f push ss 00000010 out si,dh abort: cs segment limit exceeded (or internal error) I noticed from disassembling a larger file (all the instructions in NASM's insns.dat) that Crudasm is loosing the register on certain instructions (e.g., the ones with dh...). Also, although cmpxch486 doesn't disassembly correctly, it still points out the "unique" disassembly of "cmpsb". I can work through more as time permits, if you'd like. Rod Pemberton
From: Frank Kotler on 13 Aug 2008 21:01 Chuck Crayne wrote: > On Wed, 13 Aug 2008 11:08:21 -0700 (PDT) > NathanCBaker(a)gmail.com wrote: > >> Can we make crudasm (and maybe ndisasm) "switch gears" in the >> middle of a disassembly? > > ndisasm can effectively do this now, although one would have to invoke > it more than once, and combine the results, but it would be fairly easy > to enhance ndisasm to do it all in a single pass. In fact, some time > ago, I looked at what it would take for it to pick up the required > parameters from the ELF header. However, actually implementing it is > pretty low on my priority list, because most people in the ELF world > already use objdump in preference to ndisasm. Japheth made mention, the other day, of Agner Fog's "objconv". I got as far as downloading it, and took a quick look (before I fell into my "lazy hole"). Looked *very* impressive. http://www.agner.org/optimize/#objconv I'll get back to that... pretty soon... Best, Frank
From: Willow on 13 Aug 2008 21:51
On Aug 13, 4:48 pm, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: [snip] > Crudasm1: > > 00000000 adc dh,0x99 > 00000002 adc dh,0x33 > 00000004 and dh,0x33 > 00000006 o32 bswap > 00000009 o32 cdq > 0000000b cmp dh,0x33 > 0000000d db 0x0f > 0000000e cmps byte [si],byte [es:di] > 0000000f push ss > 00000010 out si,dh > abort: cs segment limit exceeded (or internal error) Thanks for pointing out this bug, I just fixed it. Now it prints out this: 00000000 adc al,0x99 00000002 adc al,0x33 00000004 and al,0x33 00000006 bswap eax 00000009 cdq 0000000b cmp al,0x33 0000000d db 0x0f 0000000e cmps byte [si],byte [es:di] 0000000f push es 00000010 out dx,al 00000011 db 0xbb I want to add cmpxchg486, but I need to know two things about it: what is the size of the r/m argument, and is it a locakable instruction? The db 0x0f and skipping to then next instruction is the standard way we handle invalid opcodes - the latest version of ndisasm also "recognizes" cmps after the db 0x0f because it does not have cmpxchg486 either. You can add these two lines to the script file: _cmpxchg486 def lcka osz def def 0f a6 +w def reg def def rm:<size>,r:w Use lcka if it's lockable or def if it's not lockable. <size> must be replaced with the size of the r/m. I'd do it for you, but it's an undocumented instruction and this is the output I get from ndisasm 2.02: 00000000 1499 adc al,0x99 00000002 1433 adc al,0x33 00000004 2433 and al,0x33 00000006 660FC8 bswap eax 00000009 6699 cdq 0000000B 3C33 cmp al,0x33 0000000D 0F db 0x0F 0000000E A6 cmpsb 0000000F 06 push es 00000010 EE out dx,al 00000011 BB db 0xBB You can see that they removed the opcode from ndisasm in its latest version. I hesitate to add an opcode that is invalid on modern CPUs. > > I noticed from disassembling a larger file (all the instructions in NASM's > insns.dat) that Crudasm is loosing the register on certain instructions > (e.g., the ones with dh...). Also, although cmpxch486 doesn't disassembly > correctly, it still points out the "unique" disassembly of "cmpsb". I can > work through more as time permits, if you'd like. Wow, you really tested it! That's great! Can you do more testing on the latest version and let me know how it goes? I lack the skill in Perl to make use of INSNS.DAT, it has all these octal codes and I don't know how to use it. Don't even think about trying 64-bit instructions, floating point instructions, MMX/SSE etc. instructions, or exotic undocumented opcodes that are no longer valid on the latest CPUs (like cmpxchg486 :-) I have to add these new instructions to the script file... at least I got the VT instructions in there! Got to add some intelligence to the disassembler... The latest version is available here: http://code.google.com/p/vm64dec/downloads/list Willow |