Hello. I decided to try to start a series of articles on the modernization of our beloved
IDA Pro .
In each of the tutorials I will try to solve a rather complicated and poorly studied topic: writing various modules:
- loaders;
- plugins;
- debager plugins;
- processor modules;
- scripts.
And, if
processor modules ,
plug-ins and
scripts are a topic that is more or less revealed, then the rest is almost total darkness (
at the end of the article I will give a list of references and projects where there is at least something ).
So, the first article from the cycle will be devoted to writing a
plug-in debugger , or rather a preliminary theory. In the standard delivery of the
IDA SDK , there are already sources of the main debuggers (
Windows ,
Linux ,
Mac ). But what about, for example,
Amiga ,
M68000 ?
This article is more likely to be devoted to boring and not very theory. It is strongly recommended to get acquainted with it, because Many moments in the future may be incomprehensible precisely because of the impossibility of presenting a general concept.To begin with, we will define what plug-ins debuggers happen.
')
Types of debugger plugins
The debugging plugins for
IDA are of two main types:
- local - executed on the same machine on which the debugging process takes place;
- remote ( RPC ) - executes remotely. You have to pull it with a local plugin.
There are still some others, but they will not be discussed in these articles (or will they?). I will describe here only a
local debugger, since
the remote one requires twice the code (client and server), and I have not studied it well enough.
Components of the debager plugin
- Actually, IDA . Sends commands, accepts and responds to messages from the debugger , displays the current debug status;
- The emulator of the processor or code we need. Suppose he knows how to execute instructions, report breakpoints, pause and continue the emulation process, start and end the process;
- Well, the debugger itself is a plugin. It should interact with the emulator , send messages to IDA , read the current state of registers, memory.
So, about all the components in order.
IDA - visual interface
Actually,
IDA itself is an adapter between the user interface and the
debager , sending
commands to it , and waiting for any reaction (
messages ). Commands may be:
- Completion of processing the current event;
- Start / pause / end of a process or thread;
- Step ( Step Into , Step Over , Step Until Return );
- Installation / removal of bryak;
- Read / write memory or registers;
Debugger plugin
The task of the plug-in is to respond to the commands from
IDA (
see above ), and send it the events of the following types triggered in the
emulator :
- Start / pause / join / disconnect from / end the process;
- Start / end stream;
- Breakpoint;
- Step ( Step Into , Step Over , Step Until Return );
- An exception.
You need to send messages so that
IDA knows what is happening now and displays the current state of debugging. When a breakpoint or step event occurs, for example, a debugger window should appear, in order to wait for further actions from the user.
Emulator - all head
What is the purpose of the
emulator ? Of course, follow the instructions. He also knows how to keep context. Sometimes, it holds information about breakpoints (and sometimes it’s not - then you have to implement them at the
debager level). It also happens that the
emulator itself does not have the function of suspending / continuing execution, and we have to implement it somehow. One thing pleases - usually emulator source codes for many platforms already exist, and, often, they need only a little bit of modernization for our task.
So, the
emulator reports to the
debager about the occurrence of events in itself:
- There was a start / end of a process or thread;
- Breakpoint triggered;
- A step has been executed;
- An exception has worked.
Developments
Let's look at the Step event :
- I press the F7 ( Step Into ) key in IDA ;
- In debugger gets the command to complete the last coming before this event . Usually, the debager in this case will have to tell the emulator to continue execution;
- Next, the debugger receives the command to perform the step in the stream , responds to this by executing one instruction of the emulator ;
- The emulator reports back to the debager that the STEP event has arrived, placing it in the event queue ( see the event queue below );
- Debager gets the dispatched event from the event queue, and reports it to IDA ;
- IDA responds to an upcoming event. In this case, realizes that the step has been completed, and shows the current EIP address, which we got up to after the step;
- After we have seen enough of the IDA window with the state of registers and other things, and we want to do something further (for example, another step by pressing F7 ), the cycle again goes to the first item.
Event Queue :
Such a thing that constantly revolves in a separate
debuger thread, in anticipation of the onset of new events of the
emulator . When receiving a new event, you must pause the emulation (because the step implies a process frieze), and then pass the event to
IDA . When the
IDA reports that the event has been processed, a command to complete the processing of the current event will come to the
debager .
As you can see, the topic is very muddy, and not very simple. But, it seems so at first glance. In the next article, we will begin the actual writing of a debugger plugin , and at the same time we will see what and how.- References and projects:
- The IDA Book is the best-selling book on IDA Pro . There is almost everything ( well, except for debugs ).
MUST HAVE ! - deci3dbg is one of two public debugging modules.
PS3 debugger; - idados is the second debugger module, albeit an eerie curve ( but the author can be forgiven, since the topic has been little studied now ).
MS-DOS debugger; - idados_dosbox - my fork of the previous project. At least it is going to normal, and not so much bog;
- IDASDK \ plugins \ debugger is what everyone starts with. Difficult, incomprehensible.