IDA Pro has 9 debugger modules

Since the number of debugger modules in IDA surpassed the magical number seven plus or minus two, we created a small table describing what is available and what is not:
http://www.hex-rays.com/idapro/debugger/index.htm
Direct links to tutorials are available here:
http://www.hex-rays.com/idapro/idasupport.htm
I know, I know – we need to add 64-bit support for all platforms, port the Bochs debugger module to Linux, and… any other suggestions? I personally would love to have source level debugging, yet it requires some substantial changes to the kernel. We probably will move in this direction, sooner or later…

This entry was posted in IDA Pro. Bookmark the permalink.

15 Responses to IDA Pro has 9 debugger modules

  1. Anonymous says:

    Yeah, I would love 64 bit support for Linux. May be adding x86_64/ia64 support for the GDB debugger module? I think that would be easier.
    And something that would be really cool is debugging through pseudo-code (hex-rays).

  2. dennis says:

    yeah, I’ve had the idea of writing a debugger plugin which utilizes the decompiler as well. any plans about that so far? should be “a few” lines of code only, no?

  3. Ilfak Guilfanov says:

    Displaying the source lines and letting the user to step over them is not that difficult, it is true. But as soon as the user gets used to it, she will immediately want high level expressions to be evaluated. Seeing high-level code but not being able to examine variables and/or expressions would be disconcerting. This means that we have to implement some kind of expression evaluator… Like you have a structure variable, then you can examine its members, follow pointers, display results in various forms, etc

  4. Anonymous says:

    Move to 64-bit is a trend. Source code level debugging is preferred after these basic facilities constructed.
    For basic debugging facilities, I think IDA should improve the stack window and Binary window display/Modify flexibilites, though these can be done with scripts or plugins, a convinient UI is a must for most users, see the popularity of ollydbg is a good example.

  5. sam says:

    Can the bochs debugger debug 16-bit (segmented) code at all?
    There are some old DOS packers that still hold some interest and this would also be helpful for looking into implementation bugs in DOSBox. Any solution for this older stuff would be appreciated.

  6. Kender says:

    Thank you so much for all this debugging goodness!
    You may want to change this text though:
    “Currently IDA Pro can debug only MS Windows 64-bit applications.”
    I’m pretty sure win32 apps can be debugged too :)

  7. Mike says:

    A 68K Debugger would be very nice :)
    Just a suggestion

  8. Ilfak Guilfanov says:

    For 64-bit debugging, it is not that difficult (in theory we just need to recompile the modules and check that everything runs ok) but the sheer number of operating systems and variants becomes a real burden. For example, we already compile 18 versions of IDA before a release, some internal, some public. While it may be argued that adding a couple or more variants will not change much, our desire it to decrease this number. Probably we will release 64-bit modules separately, if we have some free time.
    For the user interface, I agree with you 100%. We already started working on that, here’s a screenshot:
    http://www.hexblog.com/ida_pro/pix/cpuview.gif
    There will be a ‘standard’ cpu view with a nice data dump, stack view, registers, etc. The disassembly listing will be available as a text or a graph.
    The bochs debugger can handle 16-bit without any problems. In fact we added full 16bit support to the debugger, so implementing a dosbox debugger is also possible. Since it is our first release that supports 16-bit, there might be some glitches but overall it should work.
    For the 68K debugger, the suggestion has been noted. Just FYI: this is a typical situation when someone works with a processor and wants us to implement (additional) support for it. The day when the user stops working on that processor, he is not interested anymore, and this is very natural. The only problem here is that the number of users interested in this or that processor is quite small. For example, it is the first time we receive a request for 68K. So, thank you for understanding and sorry that we do not plan to implement such a debugger module. But hey, what about doing it yourself? ;)

  9. Mike says:

    “For example, it is the first time we receive a request for 68K”
    Really? That’s astonishing. 68K or Coldfire platform is still used in many embedded systems. Anyway, thanks for your answer ! It was just a suggestion not a claim ;)

  10. Vincent says:

    Hi Ilfak,
    I recently came across malware sample – password stealer that aside from steeling IE, firefox passwords tried to reach for my ida.key hence my question is it possible to add in the next IDA version some kind of master password?(optional)

  11. dennis says:

    vincent,
    would you mind sharing a sample/md5 of that malware?

  12. newsoft says:

    A remote Cisco IOS debugger would be nice, too.
    Since they have gdbserver on board, and there is some documentation floating around on their implementation (cf. Andy Davis), it seems to be a reasonable request :)

  13. Kender says:

    Another question:
    Is there any support for detecting and/or defeating anti-debugger tricks in IDA?

  14. Ilfak Guilfanov says:

    While IDA does not have any built-in measures to detect and defeat anti-debugger tricks, it does provide the user with the necessary functionality. Anti-debugger tricks continuously evolve and get improved. We do not plan to be involved into this arms race since anything we offer will be targeted. It is much better for our users if they develop their own plugins.
    BTW, you may want to check this addition to IDA:
    http://www.openrce.org/downloads/details/255/IDA_Stealth_Plugin

  15. Mark says:

    day when the user stops working on that processor, he is not interested anymore, and this is very natural. The only problem here is that the number of users interested in this or that processor is quite small