OSDev.org

Hi,

I am wring some code that mix 16bit and 32bit code in asm and C. To fight some bugs I am having, I need to diassemble the code. Unfortunately I found that objdump is horrible: it very often produces bad disassembly that is very different from the source, so I cannot understand where the problem is.

I use objdump with option "-S -d". So could anybody tell if if there is a way to have objdump worked better?

Or: Is there a more reliable disassembler than objdump for what I want to do?

Thanks,
J

I use ndisasm, the nasm disassembler. Just strip the location and hex dump columns from the disassembly and you'll have a reassemblable output ready to go through nasm. It replaces data with opcodes, though - but in the end it looks the same in the output file.

Jeremiah Griffin wrote:I use ndisasm, the nasm disassembler. Just strip the location and hex dump columns from the disassembly and you'll have a reassemblable output ready to go through nasm. It replaces data with opcodes, though - but in the end it looks the same in the output file.

I tried ndisasm before, but the output looks quite confused, because it doesnt come with C source code like objdump (the -S option of objdump is good!). And ndisasm only produces pure assembly, without any symbols that can help to quickly understand the code??

Any idea?

Thanks,
J

I suggest you get used to reading assembly. objdump is an extremely good disassembler - what you're actually asking for is a decompiler, of which there are few, and fewer good ones. I use "objdump -d" and interpret the assembly, as I know many others do.

JamesM wrote:I suggest you get used to reading assembly. objdump is an extremely good disassembler - what you're actually asking for is a decompiler, of which there are few, and fewer good ones. I use "objdump -d" and interpret the assembly, as I know many others do.

In my experience, objdump produces very bad assembly output, which is completely wrong almost all the time on my code. So I cannot say that objdump is a good one, at least for 16bit code.

Meanwhile, ndisasm produces very nice and correct assembly code, The only problem is that it cannot corporate source code like objdump does.

Currently I use objdump to have a look first, then if something is wrong (mostly), I get the related opcode, and search for them on the output of ndisasm to see what it actually does. But this is very inconvenient, so I want to know if there is a "2-in-1" tool to do everything correctly and nicely.

Thanks,
J

In what respect is the output wrong? Could you post a snippet of where it goes wrong?

Cheers,

James

FYI,

http://sourceforge.net/projects/bastard/

<kernel-level >
http://oss.sgi.com/projects/kdb/

http://www.linice.com/

--
PS: http://en.wikibooks.org/wiki/Reverse_Engineering/Tools

PPS: http://idc.sf.net and it's disassembler, not diassembler.

IDA
If it doesn't know file format(PE,ELF) then you need to tell yourself where code/data start. Same goes for mixed (16/32/64bit) code.
IDA 4.9 is free for non commercial use, lacks some features - don't know which.

I use IDA as well.
I use it for both the disassembly mode and decompiling feature.

JamesM wrote:In what respect is the output wrong? Could you post a snippet of where it goes wrong?

Sorry that I have no code here, but you can try to compile some 16bit code with ".code16gcc" directive. Somehow objdump fails to understand when the code use override prefixes for address and data.

Thanks,
J

junkoi wrote: Sorry that I have no code here, but you can try to compile some 16bit code with ".code16gcc" directive. Somehow objdump fails to understand when the code use override prefixes for address and data.

I think in case you are trying to disasembly 8086 code with objdump this `-m i8086' switch should be used.

In my experience, objdump produces very bad assembly output, which is completely wrong almost all the time on my code. So I cannot say that objdump is a good one, at least for 16bit code.

IIRC, that's because you're using it wrong. You're supposed to pass a command line option to switch it to 16-bit mode.

devel wrote:

junkoi wrote: Sorry that I have no code here, but you can try to compile some 16bit code with ".code16gcc" directive. Somehow objdump fails to understand when the code use override prefixes for address and data.

I think in case you are trying to disasembly 8086 code with objdump this `-m i8086' switch should be used.

devel, thanks so much for your suggestion! -m i8086 works perfectly for me!!!!!!

Best,
J