Remote debugging begins by launching an appropriate debugging server component on the computer on which a process is to be debugged. IDA ships with the following server components:

In order to perform remote debugging on any platform, the only component you are required to execute on that platform is the appropriate server component. It is not necessary to install a full version of IDA on the remote platform. In other words, if you intend to use a Windows version of IDA as your debugging client, and you wish to remotely debug Linux applications, the only file, other than the binary that is being debugged, that you need to copy to and execute on the Linux system is linux_server.^[239]

Regardless of the platform you intend to run the server on, the server components accept three command-line options, as listed here:

There is no option to restrict the IP address on which the server listens. If you wish to restrict incoming connections, you may do so using host-based firewall rules as applicable to your debugging platform. Once a server has been launched, IDA may be executed from any supported operating system and used to provide a client interface to the debug server; however, a server can handle only one active debugging session at any given time. If you wish to maintain several simultaneous debugging sessions, you must launch several instances of the debugging server on several different TCP ports.

From the client perspective, remote debugging is initiated by specifying a server hostname and ports via the Debugger ▸ Process Options command, as shown in Figure 26-1. This action must be performed prior to starting or attaching to the process you intend to debug.

Figure 26-1. The debugger process options dialog

The first four fields in this dialog apply to both local and remote debugging sessions, while the Hostname, Port, and Password fields apply only to remote debugging sessions. The fields of this dialog are summarized here.

At first glance, the Application and Input File fields in Figure 26-1 may seem to be identical. When the file opened in your IDA database is the same as the executable file that you wish to run on the remote computer, these two fields will hold the same value. However, in some cases, you may wish to debug a library file (such as a DLL) that you are analyzing in an IDA database. It is not possible to debug a library file directly because library files are not standalone executables. In such cases, you will set the Input File field to the path of the library file. The Application field must be set to the name of an application that makes use of the library file that you wish to debug.

The procedures for connecting to a remote gdb server are nearly identical to the procedures for attaching to a remote IDA debugging server with two minor exceptions. First, no password is required to connect to a gdb_server, and second, IDA allows specification of gdb-specific behaviors via the Set specific options button within the debugger setup dialog. Figure 26-2 shows the GDB Configuration dialog.

Figure 26-2. GDB Configuration dialog

Of note is the fact that IDA has no way of knowing the architecture of the computer on which the gdb_server is running and that you are obligated to specify a processor type (which defaults to Intel x86) and potentially the endian-ness of that processor. IDA is currently capable of providing a debugging interface for x86, ARM, PowerPC, and MIPS processors.

A number of different scenarios exist if you intend to attach to a running process on your remote debugging server. First, if you have no database open in IDA, you may select Debugger ▸ Attach and choose from IDA’s list of available debuggers. If you choose one of IDA’s remote debuggers, you are presented with the configuration dialog shown in Figure 26-3.

Figure 26-3. Remote debugger configuration

Once you provide the appropriate connection parameters and click OK, IDA obtains and displays a process list from the remote debugging server, allowing you to select and attach to a specific process.

In the second scenario, you might already have a binary open in IDA and wish to attach to a remote process. In this case you may need to select a debugger (if none has been previously specified for the open file type) or switch your debugger type (if a remote debugger is not currently selected). Once a debugger has been selected, you must provide hostname and password information for the remote debugger server, as shown in Figure 26-1, at which point you may attach to a remote process using Debugger ▸ Attach to Process.

In Chapter 25 we discussed the IDA debugger’s handling of exceptions and how to modify the debugger’s exception-handling behavior. During remote debugging sessions, the debugger’s default exception-handling behavior is dictated by the exceptions.cfg file, which resides on the client machine (the machine on which you are actually running IDA). This allows you to modify exceptions.cfg and reload the changes via the Debugger Setup dialog (see Figure 25-4) without the need to access the remote server.

During a remote debugging session, it remains possible to utilize scripts and plug-ins to automate debugging tasks. Any scripts or plug-ins that you choose to execute will run within IDA on the client machine. IDA will in turn handle any actions that are required to interact with the remote process, such as setting breakpoints, querying state, modifying memory, or resuming execution. From the script’s perspective, all behaviors will appear just as if the debugging session was taking place locally. The only thing to remember is to make sure that your scripts and plug-ins are tailored to the architecture on which the target process is running and not the architecture on which the IDA client is running (unless they happen to be the same). In other words, if you are running the Windows version of IDA as a client for remote debugging on Linux, do not expect your Windows debugger-hiding script to do you any good.