With this post I attach a small com-file. It is a pure dump of the executable code in the Master Boot Record of a harddisk on a Windows 98 (Swedish language version) computer.

When I disassemble this file in IDA I notice several annoying and confusing things, that I would really appreciate if some of you assembly/IDA-wizards could clarify for me.

First of all, all offsets mentioned below are the offsets shown in IDA. The corresponding file offsets are 100h less (IDA takes into consideration the runtime PSP when adding 100h to the offsets I guess?).


Strange thing number 1:

At offset 01A6 there is a jmp to offset 04A6. At this target address (04A6) IDA only disassembles one single instruction, namely "cli". Then it has just stops the disassembly and marks the bytes after this as "unexplored". Why would it do this? As far as I know, the "cli" instruction only modifies the interrupt mask, and does not in any way divert the control flow?


Strange thing number 2:

The practically same thing happens at offset 0175, which contains a call to offset 01D7. At this target address (01D7) IDA also only disassembles one single instruction, namely "push si". Then it just stops the disassembly and marks the bytes after this as "unexplored". And "push si" certainly does not divert the control flow, right? What's up with that?


Strange thing number 3:

At offset 013C, there is a call to offset 01D6. At this target address (01D6) IDA disassembles one instruction, and then it decides that this instruction is the entire body of this called procedure, like this:

proc near
01D6: inc cx
endp

Note also, that the next offset is the target offset mentioned in situation 2 above, containing the instruction "push si", which is in turn followed by the "unexplored" data.


Strange thing common for all these situations:
Whenever I try to force IDA to treat any unexplored bytes as code (e.g. the bytes after the single instructions in situation 1 and 2), by putting the cursor on the first line of unexplored data and then pressing the C button, I always just get the message 'Command "MakeCode" failed'.
What the %@£€#%?!? That is exactly how that IDA-command always repsonds when I try to use it, it has never been able to work a single time for me. Just because IDA has decided in advance that these bytes are not code it seems to refuse to even consider the possibility, even though the traced control flow runs right into these offsets!


Summary:
So, my questions are:
Why does IDA just halt the disassembly on arbitrary places like this (and end procedures on equally arbitrary places, like in situation 3 above)? And what am I doing wrong with the C ("Make code" command? There's not much "interactive" about the disassembler if it always overrides any and all of my requests to change its initial opinion about anything, now is it. Has anybody ever gotten that command to work?

I'm using IDA 4.21, but it has acted exactly the same for me with earlier versions too.


Any explanation regarding any of these issues would be greatly appreciated, since this is starting to drive me completely crazy.

Thanks!

I think that IDA is unable to recognize this type of instructions.
For example, I have tried to force IDA to recognize the instruction (at :4A6) 'movzx eax, byte ptr [bp+10]' using the 'assemble instruction' option but the result is only a message: 'invalid mnemonic'.

If you want to know something more about your file, this link might help you: http://www.geocities.com/thestarman3/asm/mbr/MSWIN41.htm

my 2 €...
ZaiRoN

ps. wdasm & hview display the instructions in the right way

that makes the score:
wdasm: 1
ida: 94018



in all honesty though, that is very interesting that wdasm can do it but ida can't. dELTA, perhaps you should consider contacting ilfak and ask him what the problem is

Thanks for the link!

In that analysis of the code, it turns out that (at least some of) these exact positions where IDA abruptly ended the disassembly contains instructions that "MS-DEBUG" cannot disassemble correctly either.

But how on earth can there exist so many instructions that neither IDA nor MS-DEBUG can decode? Why can't they simply decode all legal instructions? I mean, after all there is only a finite number of them, and they are even arranged in a quite logically sound space?! Anyone have any idea whatsoever why they might do that?

And as bad as it might sound to just skip the ability to decode certain perfectly valid instructions, it seems even worse to silently abort the disassembly of all code-flow paths that come upon one of these, not to mention refusing to give any explanatory error message when a "MakeCode" command is issued and fails. While being such an incredibly cool and powerful disassembler, I still get really disappointed in IDA sometimes.

Sure disavowed, I will try to ask the IDA guys, and I'll return here later with the official explanation.

(it would still be cool to hear if anyone here has any ideas about what I wrote about in my last post above)

it's not totally silent. if you look in the Problems Window (View->Open Subviews->Problems), you'll see it says:
seg000:01D8 NODISASM db 66h ; f
seg000:04A7 NODISASM db 66h ; f

so it does say where it ran into problems, and what the problems were (NODISASM short for "no disassemble johnny-5"?

problem solved!!!

set your Processor Type in IDA to "Intel 80x86 processors: metapc"

now it disassembles your above 2 issues correctly!

Cool, thanks disavowed!

I didn't see that IDA all of a sudden defaulted to the 8086 instruction set just because it was a com file. Normally (with PE files) it always defaults to metapc.

Then I would like to apologize to IDA for my former complaints, and instead add a new one : Stop defaulting to processors that might not potentially be able to handle the instructions in a piece of code that is loaded, at least without giving an expressive warning that this might be the case when an undecodable instruction is found. I mean, what can defaulting to the 8086 instruction set possibly be good for (especially compared to the problems it might cause)?