Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
1. Launch a remote IDA debugger server on the remote host. The remote server is started from the command line and accepts command line parameters. You can specify a password if you want to protect your debugger server from strangers. For example, to launch the server under MS Windows, you could enter:
2. Specify the remote debugger parameters in the Debugger, Process options. The file paths must be valid on the remote host. Do not forget to specify the same password as you have specified when launching the server. For example, to debug notepad.exe on the remote computer remote.host.com:
3. The rest of debugging is the same as with local debugging.
The debugger server can handle one debugger session at once. If you need to debug several applications simultaneously, launch several servers at different network ports.
The following debugger servers are shipped with IDA
An appropriate server must be started on the remote computer before starting a debug session.
See also
The Remote iOS Debugger allows for debugging iOS applications directly from IDA.
IDA's iOS debugger acts as a client to Apple's debugserver. So, you must ensure that the debugserver is already installed on your device for the debugger to work.
See: https://www.hex-rays.com/products/ida/support/tutorials/ios_debugger_tutorial.pdf
for a detailed tutorial on getting started with iOS.
See also
The Dalvik debugger is a plugin to debug Android applications written for the Dalvik Virtual Machine. It includes the source level debugging too.
Dalvik debugger specific options:
Source-level debugging
List of special things about our Dalvik debugger:
Locals window
Watches window
See also Debugger submenu.
Make sure the following line is present in the .cfg file for your target:
Edit the port number if necessary. Specify that port in the process options and use the Debugger, Attach command.
Tips: Use the GDB command line to send commands directly to OpenOCD interpreter. Back to Remote GDB Debugger
VMWare Workstation 6.5 is recommended for debugging, though earlier versions may work too. Only 32-bit debugging is supported.
In order to enable debugging with GDB protocol, add the following lines to the .vmx file of the virtual machine:
To debug the VM startup, use:
Please note that the execution will start in the BIOS.
To accept connections from remote computers, the following line must be specified:
VMWare Workstation will listen on port 8832.
Tips:
Since the GDB server does not report the memory layout, it must be specified manually. For example, to debug BIOS startup code, create a 16-bit segment from F0000 to 10000 with base F000.
Use the GDB command line to get extra info about the registers. For example, use "r cr0" to see current value of the cr0 register or "r cs" to see the base, limit and other attributes of the CS selector in protected mode.
Back to Remote GDB Debugger
Max packet size
Timeout
Run a program before starting debugging Check to enable external program options. Processor This option is only visible when starting debugger without a database. Use it to specify on which CPU the target is running. For some processors you can also specify the endianness. Software breakpoints at EIP+1
Use CS:IP in real mode
See also
gdbserver is a GDB stub implemented as a separate program. It runs a program to be debugged or attaches to a process and then waits for commands. The remote GDB debugger module has been tested with gdbserver available with Cygwin and Linux.
To debug a specific program from the start, run the following command:
and then choose Debugger,Attach,<process running on target> in IDA.
To debug a running process:
then choose Debugger,Attach,<enter PID to attach> in IDA and enter the PID of the process to attach to.
Another method of debugging a running process is:
then choose Debugger,Attach,<process running on target> in IDA.
To start a program from inside IDA, first launch the debugger server:
Then use Debugger,Start process or Debugger,Run in IDA.
The --multi option is only available in GDB 6.8 or higher.
Back to Remote GDB Debugger
Remote GDB Debugger module allows for debugging code using the GDB remote serial protocol. For this, the debuggee must contain a so-called "GDB stub" that controls the execution and handles the remote protocol commands. There are many implementations of such stubs available with different capabilities. The module has been tested with the following GDB stubs: gdbserver: Windows (Cygwin), Linux (ARM, MIPS, PowerPC) VMWare: x86 (16/32 bit) QEMU: x86 (16/32 bit), ARM, MIPS, PowerPC OpenOCD: ARM It is quite possible that the module will work with other stubs. Note that only x86, ARM, MIPS and PowerPC processors are supported at the moment.
Some GDB stubs support so-called "monitor" commands. For example, VMWare stub can return extra info about system registers. Use the command line at the bottom of the main IDA window to send such commands. The output will be displayed in the message window. Hint: most stubs have a "help" command (if they support any commands at all).
The module also makes the following function available from IDC: string send_dbg_command(string command);
When using instant debugging, you will need to tell IDA on which CPU the target is running. This is done in the Remote GDB Debugger options dialog, available via "Debugger specific options" button in the Process options dialog shown when you choose Remote GDB Debugger from the Run or Attach menu.
Many GDB stubs do not report the address that triggered a hardware breakpoint. In this case, IDA will report a memory breakpoint hit as a generic TRAP signal. Examine the previous instruction to see if it referenced a memory location with breakpoint. When continuing from such a breakpoint, choose not to pass the signal to the program.
IDA can be used together with a J-Link debug probe from SEGGER Microcontroller GmbH:
https://segger.com/jlink-debug-probes.html
See also
Run QEMU with -s switch to enable its GDB stub. The default port number is 1234. If desired, the -p command line switch can be used to change it. The -S command line switch causes the execution to be suspended at startup. For example:
For better debugging, make sure to set the following options in GDB Debugger options:
In other aspects debugging with QEMU is the same as debugging for other targets.
Back to Remote GDB Debugger
The PIN debugger is a remote debugger plugin used to record execution traces. It allows to record traces on Linux and Windows (x86 and x86_64) from any of the supported IDA platforms (Windows, Linux and MacOSX). Support for MacOSX targets is not yet available. Please see the section for more details on this subject.
To use the PIN debugger plugin the following steps must be carried out:
Download the appropriate version of PIN from
- PIN Binary Path: Full path to the pin binary.
PIN Tool Path: Directory where the idadbg.so or .dll PIN tool resides.
Tracing options:
Instruction tracing: trace individual instructions
Basic block tracing: trace basic blocks
Function tracing: trace functions
Recording of register values: record register values or not. If this option is disabled, only EIP/RIP will be recorded.
PIN Tool options:
Autolaunch pin for "localhost": When this option is set and the host name specified in Debugger, Process Options is "localhost", the PIN tool will be executed by IDA. Otherwise IDA expects the PIN tool to be already running and listening. Please refer to for more details.
Debug mode: This flag allows one to see what's happening in the PIN tool side. It prints out some debugging information.
Extra-arguments: Additional command line arguments to be used when constructing the command line to launch PIN locally. The extra arguments can be added before the PIN tool specification (before '-t /path/to/pin/tool) or after the PIN tool (after '-t /path/to/pin/tool' but before '-- application'). Please consult the section "Command Line Switches" of the Intel PIN manual for more details. Optionally you can launch PIN yourself and connect to it from IDA. See for more details.
The "Run a program before debugging" option in allows to automatically run a program (such as a debugging server) when starting a debugging session. If you enable it, the following options become available:
Command line
%i: input file name from the dialog %p: port number from the dialog %e: file name of a temporary ELF file created from the database contents Initial SP
Choose a configuration
Memory map
One use of these options is to using the QEMU emulator.
See also
.
The Bochs debugger plugin uses the Bochs internal command line debugger. For more about the internal debugger:
To use the Bochs debugger plugin, the following steps must be carried out:
Download and install Bochs v2.6.x from: For Mac OS or Linux, please refer to the following guide:
Because the debugger plugin uses the Bochs command line debugger, it has the following limitations:
There are ways to overcome some of the limitations mentioned above by downloading Bochs source code and modifying it. For example, the number of allowed breakpoints can be increased.
The Bochs debugger configuration dialog box has the following entries:
Default configuration parameters are taken from ida\cfg\dbg_bochs.cfg.
The Bochs debugger module adds a new menu item: Debugger, Bochs Command. It can be used to send arbitrary commands to Bochs. The command output is displayed in the message window (there is also an IDC counterpart of this function, please refer to "startup.idc" file). This command is very useful but may interfere with IDA, especially if the user modifies breakpoints or resume execution outside IDA.
See also:
Operation mode The user can choose between , and operation modes.
The replayer debugger is a pseudo-debugger used to replay recorded traces.
The replayer debugger supports replaying traces recorded with any of the currently supported debuggers, ranging from local Linux or win32 debuggers to remote GDB targets. Currently supported targets include x86, x86_64, ARM, MIPS and PPC.
To use the replayer debugger you will need first to record a trace by enabling instruction tracing, function tracing or basic block tracing with another debugger. Then, after loading a recorded trace in the Tracing window, select the replay debugger from the debugger's dropdown list and start the debugger normally as you would do with any other debugger.
One of the advantages of the replay debugger module over re-executing the debuggee is that in the replayer debugger it is possible to step not only forward, but also backwards, making it easier to analyze what happened during the execution of the recorded trace.
There are two types of traces that can be replayed: instruction level traces or partial traces. Instruction level traces are recorded by enabling instruction tracing and partial traces are recorded using either function tracing or basic block tracing. When a trace is recorded with instruction tracing enabled all register values are saved. With basic block or function level tracing only the instruction pointer is saved. Additionally, in basic block tracing the register values are also saved when the last instruction of a basic block is reached or a call in the middle of a basic block is about to be executed.
The replayer debugger module adds a new menu item: Debugger, Step Back command. It can be used to step back to the previous instruction when replaying a recorded trace.
Recording traces on MacOSX target is not supported yet. Versions equal or prior to 2.12-55942 does not have support for the API PIN_SpawnInternalThread, which is needed by IDA to communicate with the PIN tool.
However, it's possible to record traces from a Linux or Windows target using the MacOSX version of IDA.
General:
- How are breakpoints treated by IDA Bochs Plugin: Bochs debugger does not use breakpoints by inserting 0xCC at the given address. Instead, since it is an emulator, it constantly compares the current instruction pointer against the breakpoint list. Data breakpoints are supported by Bochs and are known as "watchpoints". If the user creates hardware breakpoints, IDA will automatically create Bochs watchpoints.
- How to select the Bochs operation mode programmatically: using IDC: it is possible to use process_config_line() function to pass a key=value. For example, process_config_line("DEFAULT_MODE=1") will select the disk image operation mode. (Please refer to cfg\dbg_bochs.cfg for list of configurable options).
- When debugging, IDA undefines instructions: if the "Debugger options / Reconstruct stack" is checked and the stack pointer is in the same segment as the currently executing code, then IDA might undefine instructions. To solve this program, uncheck the reconstruct stack option.
- How to convert from physical to linear addresses and vice versa: Bochs internal debugger provides two useful commands for this: "info tab" and "page".
Disk image operation mode:
- Data/Software breakpoints are not always triggered: During a debugging session, when a breakpoint is created while the protected mode/paging is enabled, the page table information is used to translate addresses and correctly create the breakpoint. When debugging session is started again, IDA cannot access translation tables to re-create the same breakpoint, thus the breakpoint will be created without any translation information (it will be treated as physical addresses) This is why those breakpoints are not triggered. As a workaround, we suggest disabling those breakpoints and re-enable them when paging is enabled. This problem can also arise when the "use virtual breakpoints" option is enabled.
IDB/PE operation mode:
- Cannot map VA: Sometimes, IDA may display a message stating that a given VA could not be mapped. This mainly happens because both IDB/PE operation modes use virtual addresses from 0x0 to 0x9000 and from 0xE0000000 to 0xFFFFFFFF internally. To solve the problem, please rebase the program to another area:
PE operation mode:
- Dynamic DLL loading: sometimes, when running a program, the plugin may attempt to load a DLL that is not declared in the stub or load section of the startup script. In this case, please write down the name of the DLL, then add it to the startup script, and restart the debug session. It is possible to create a local copy, next to your database, of startup scripts so that these scripts will be used with this database only.
- Disk image loading slow: The disk image produced in the PE operation mode can be as big as 20MB. The reason for this slow loading is most probably because the plugin tries to load all referenced DLLs instead of stubbing them. To fix this, when the process starts, please take note of the loaded DLLs list (using IDA / Modules List) then add the desired module names in the startup.* / "stub" section. See also: Bochs debugger
The disk image operation mode is used to run Bochs with any Bochs disk image.
A simple way to get started is to launch IDA and disassemble the bochsrc file associated with your disk image. IDA will recognize bochsrc files, parse the contents, determine the associated disk image and create a new database containing the first sector of the disk image (usually the boot sector).
The database does not have to correspond to the disk image: it could in fact start as an empty database, then user could convert the needed segments to loader segments for later analysis. The following script can be used for that purpose:
If the disk image switches to protected mode with memory paging enabled, IDA will use the page table mapping to display segments. For 16-bit applications, IDA automatically creates a default DOS memory map (Interrupt vector table, Bios Data Area, User Memory and BIOS ROM). Also, the Bochs Debugger plugin will try to guess the debugger segment bitness, nonetheless the user can edit the bitness manually.
Moreover, the Bochs internal debugger provides the ability to add hardware like breakpoints, known as watchpoints, but the addresses must be physical addresses. In order to use the disk image operation mode in a more convenient way, the plugin will convert the virtual addresses to physical addresses (if page table information is present) before adding the hardware breakpoint. This mechanism will not always work, please check the FAQ for more information. For hardware breakpoint on execute, the plugin will use the selected address as-is and create a physical breakpoint.
The following parameters can be specified for the disk image operation mode:
This is a small example on how to debug a given disk image:
1. Prepare the needed bochs virtual machine files (bochsrc, disk image, floppy image if needed, etc...)
2. Load the bochsrc file into IDA. IDA will automatically create a database.
(Step 2, is optional. It is possible to use a database of your choice, but remember to point its "Debugger->Process Options->Input file" to the bochsrc file)
3. Make sure the "Disk image" operation mode is selected (If Step 2 was used, then Disk image operation mode will be selected automatically)
4. Enable "Debugger Options->Suspend on debugging start", and start debugging!
In the disk image operation mode, the Bochs debugger plugin does not handle or report exceptions, if they must be caught and handled, please put breakpoints in the IDT or IVT entries.
See also:
Before using the PIN tracer the PIN tool module (distributed only in source code form) must be built as the Intel PIN license disallows redistributing PIN tools in binary form.
Please refer to
https://www.hex-rays.com/products/ida/support/tutorials/pin/pin_tutorial.pdf
to learn how to build our PIN tool.
For local debugging the PIN tool can be automatically launched by IDA. For remote debugging it must be launched manually, as in the following example:
Where PORT is the port that the PIN tool will listen for incoming connections from IDA. APPLICATION is the target application to be traced and the optional parameter ARGUMENTS are the arguments to be passed to the target application. Please note that on Win64 it may be required to specify the path to specific x64 binary instead to the pin.bat batch file.
To attach to an already running process instead of starting a new one a command like the following one must be executed:
Where PID is the pid of the running process to attach and PORT the port that the PIN tool will listen for incoming connections.
The hostname and port where the PIN tool is listening for incoming connections should be specified in IDA. See the Debugger, Process options dialog.
After successfully launching the PIN tool the IDA debugger can be launched by pressing F9 or selecting Debugger, Start Process.
PIN accepts the following optional environment variables and command line arguments:
The Android debugger has the following particularities and limitations:
- Android on ARM is supported (not on x86)
- Both ARM and Thumb mode code is supported
- Multithreaded applications can be debugged. However, since the operating system does not report thread deaths, they are reported only when the debugger notices that the thread is missing (for example, because there is an error when we try to suspend it)
- Apparently Android reports applications that are currently executing a system call as executing "LDMFD SP!, {R4,R7}" before the syscall. Once the syscall completes, the next instruction is reached.
- Hardware breakpoints are not supported. See also
The IDB operation mode, as its name implies, takes the current database as the input and runs it under the Bochs debugger. This mode can be used to debug any x86 32 or 64-bit code. Please note that the code executes with privilege ring 3.
The following parameters can be specified in the IDB operation mode:
It may also prove useful to enable the "Debugger Setup/Suspend on debugging start" so that IDA automatically suspends the process before executing the first instruction.
While debugging, exceptions may occur and are caught by IDA. Please note that these exceptions are raw machine exceptions. For example, instead of an access violation exception, a page fault exception is generated.
See also:
Using the "Run external program" option it is easy to debug small ARM, MIPS or PowePC code snippets directly from inside IDA.
1) Download and install QEMU. Win32 builds can be downloaded from http://homepage3.nifty.com/takeda-toshiya/qemu/.
2) Edit cfg\gdb_arch.cfg file and change the "set QEMUPATH" line to point to the install directory of QEMU.
3) In Remote GDB Debugger options (Debugger|Debugger options, Set specific options), enable "Run a program before debugging".
4) Click "Choose a configuration" and choose a predefined configuration. Choose "for snippets", if mentioned.
5) If necessary, edit the command line or memory map.
6) Click OK, OK to confirm and close the options dialog.
7) In Debugger|Process options make sure that Hostname is set to "localhost" and port is non-zero.
8) Select the code range to emulate or at least the first instruction. Alternatively, you can rename the starting address "ENTRY" and end address as "EXIT".
9) Choose Debugger|Run or press F9.
IDA will write the database into an ELF file (if %e was specified), start QEMU with the specified command line and connect to its GDB stub. It will set the SP and PC values so that the code can be stepped through.
NOTE
While it can be very useful, QEMU emulation has certain limitations:
1) the memory map is usually fixed at compile time. So if your program addresses intersect some of the system regions as specified by the memory map, IDA will refuse to start debugging. In that case, you can either rebase the program so that it fits into RAM regions or check other QEMU board configurations for a compatible memory layout.
2) the emulation starts at the system (kernel) level when there is no OS loaded. That means that system calls and imported functions will not work.
3) the hardware access will only work to the extent emulated by QEMU. If the code you are emulating does not match the chosen board configuration of QEMU, the code accessing the hardware most likely will not work properly, if at all.
See also
The PE operation mode can be used to load PE files and debug them in a MS Windows like environment.
The current limitations include:
PE executables feature list:
- SEH support: we try to mimic MS Windows as much as possible. For example, the ICEBP instruction is a privileged instruction, but Windows reports back a single step exception. Similarly, MS Windows does not distinguish between 0xCC and 0xCD 0x03, so when an exception occurs, it reports that the exception address is always one byte before the trap. So if it was an INT 0x3 (CD03), the exception address will point to the 0x03 (in the middle of the instruction).
- TLS callbacks: TLS callbacks are normally parsed by IDA and presented as entry points. They will be called by the debugger before jumping to the main entry point of the application. Turning on the "Debugger Setup/Suspend on debugging start" may be a good idea since it will make all this logic clearly visible.
- Emulation of NT structures: Some malware do not use GetProcAddress() or GetModuleHandle(). Instead, they try to parse the system structures and deduce these values. For this we also provide and build the basic structure of TIB, PEB, PEB_LDR_DATA, LDR_MODULE(s) and RTL_USER_PROCESS_PARAMETERS. Other structures can be built in the bochs_startup() function of the startup.idc file.
PE/PE+ executables feature list:
- Extensible API emulation: The user may provide an implementation of a any API function using scripts. The plugin supports IDC language by default, but if there are any other registered and active external languages, then external language will be used. Currently, the plugin ships with preconfigured IDC and Python scripts (please refer to startup.idc/startup.py).
It is also possible to take a copy of all the API and startup scripts and place them next to the database in question. This will tell the Bochs debugger plugin that these scripts are to be used with the current database directory. Such mechanism makes it possible to customize API/startup scripts for different databases.
In the following example, kernel32!GlobalAlloc is implemented via IDC like this:
A simple MessageBoxA replacement can be:
To access the stack arguments passed to a given IDC function, please use the BochsGetParam() IDC function.
For a full reference on using IDC to implement API calls, please refer to ida\plugins\bochs\api_kernel32.idc file.
- Remap a DLL path (from the startup.idc script):
- Specify additional DLL search path (and optionally change the mapping):
- Redefine the environment variables: the environment variables can be redefined in startup.idc
- Use native code: it is possible to write a custom Win32/64 DLL and map it into the process space.
Existing APIs can then be redirected to custom written functions. For example:
Here we redirect some functions to bochsys.dll that modify the memory space of the application. Please note that bochsys.dll is a special module, IDA is aware of it. Custom functions are declared like this:
Then in startup.idc file, the following line must be added:
Custom DLLs are normal DLLs that can import functions from any other DLL. However, it is advisable that the custom DLL is kept small in size and simple, by not linking it to the runtime libraries.
- Helper IDC functions: a set of helper IDC functions are available when the debugger is active. For more information, please refer to "startup.idc".
- Less demanding PE loader: Most PE files can be loaded and run, including system drivers, DLL and some PE files that cannot be run by the operating system.
- Dependency resolution: In the PE operation mode, the plugin will recursively load all DLLs referenced by the program. All DLLs that are not explicitly marked with "stub" in startup.idc will be loaded as is. It is important to "stub" all system DLLs for faster loading. The PE loader creates empty stubs for undefined functions in stubbed DLLs. For example, the following line defines a stub that will always return 0 for CreateFileA:
Since CreateFileA is mentioned in the IDS files and IDA knows how many bytes it purges from the stack, there is no need to specify the "purge" value. For other functions that are not known to IDA, a full definition line would look like:
- Startup and Exit scripts: It is possible to assign IDC functions that run when the debugging session starts or is about to terminate (before the application continues from the PROCESS_EXITED event). In addition to running code at startup, the startup script serves a role in telling the PE loader which DLLs are to be mapped for the current debugging session. For example:
These lines list the DLLs that will be used during the debugging session. IDA creates empty stubs for all functions from these DLLs. Non-trivial implementations of selected functions can be specified in api_xxxx.idc files, where xxxx is the module name.
API and startup scripts are searched first in the current directory and then in the ida/plugins/bochs directory.
- Memory allocation limit: The PE loader has a simple memory manager. It is used for the initial memory allocation at the loading stage and for dynamic memory allocation during the debugging session. No memory limits are applied at the loading stage: the loader will load all modules regardless of their size. However, when the debugging session starts, a limit applies on how much memory can be dynamically allocated. This limit is specified in the debugger specific options as "Max allocatable memory". Memory allocation will fail once this limit is reached.
Some notes on bochsys.dll:
- BxIDACall: This exported function is used as a trap to suspend the code execution in Bochs and perform some actions in IDA. For example, when the target calls kernel32.VirtualAlloc, it is redirected to bochsys.BxVirtualAlloc, which calls BxIDACall, which triggers IDA:
A breakpoint can be set on this function to monitor all API calls that are handled by IDA.
- BxUndefinedApiCall: This exported function is executed when the application calls an unimplemented function. Setting a breakpoint on it will allow discovering unimplemented functions and eventually implementing them as IDC or DLL functions. It can also be used to determine when unpacking/decryption finishes (provided that all functions used by the unpacker have been defined).
See also: