Similarly, if we intend to debug remotely an app using IDA we must also use HTTP instead of sockets. The netcat server running on cloud9 also displays the success status as in Figure 6.įigure 6: Netcat server replied to the requestįrom the above experiments, it is clear that we must use HTTP in order to establish a connection to the remote container running on a virtual host. The connection succeeds and we get the HELLO WORLD response. We choose curl over netcat as we are performing an HTTP transaction and not a socket connection.įigure 5: Using curl to connect to the netcat server
Ida pro debugging windows#
This is done as shown in Figure 4įigure 4: Netcat server replying with HTTP messageįor the client part in the Windows XP box, we use curl instead of netcat as shown in Figure 5. We create a netcat server listening on port 8081 which replies with a HTTP " HELLO WORLD" message. This is possible because of the Host header as mentioned earlier, Let's test this concept. However, if we connect using HTTP we can use domain names. We have seen that socket connection is be made using IP addresses. Unsurprisingly, this fails too for the same reason. We can try to connect to this server from our Windows XP VM as shown in Figure 3.įigure 3: Trying to connect to our netcat server Let us create a netcat server listening on port 8081 as shown in Figure 2.įigure 2: Netcat server listening on port 8081 We can get a clearer picture using netcat. A socket connects by IP addresses and not by domain names thus it is not possible to connect to our container using sockets. This is expected as the container on which the debuggee is running is on a virtual host where multiple containers have same IP addresses with different domain names. Now, if we try to attach to the process in IDA using remote gdb debugger as the debugger type configured as shown in Figure 1, IDA fails.įigure 1: Remote debugger configuration (ignore the paths)
![ida pro debugging ida pro debugging](https://pbs.twimg.com/media/DK21zlKVYAESzCl.jpg)
We have specified port 8081 as it is one of the few ports cloud9 allows incoming connections. The port on which qemu listens for incoming gdb connections is specified by the -g flag and is 8081 in this case. We are using the user mode emulation capability of qemu to run non-native elf binaries. The arm binary can be debugged using qemu as follows: Cloud9 is a sort of VPS that provide Docker Ubuntu containers called as workspaces where we can run whatever we want. Rather than powering up my ubuntu VM, I decided to debug it remotely on cloud9. Debugging the binary would require a Linux box at the minimum with qemu-arm installed. The binary was loaded in IDA within a Windows XP VM. The rest of the blog post describes this process in detail.Ī few days ago, I was trying some CTF challenge involving an arm binary.
![ida pro debugging ida pro debugging](https://i.stack.imgur.com/RuUsb.png)
It seems that if we can wrap the transport layer socket traffic in plain old HTTP messages our problem would be solved. The Application Layer Protocol HTTP solves the virtual host problem by including the Host header in HTTP messages. Instead, it would be much better if sockets supported connections based on domain names as described in this paper Name-based Virtual Hosting in TCP.
![ida pro debugging ida pro debugging](https://www.c-sharpcorner.com/UploadFile/ajyadav123/binary-cracking-and-byte-patching-with-ida-pro/Images/CrackDebuging.jpg)
Port forwarding capability is not available everywhere so we can ignore it for now. However, this is not entirely true as there are techniques such as port forwarding (aka virtual server) that can be used to reroute the incoming traffic to various private IPs based on a pre-decided table. Thus remote debugging using sockets is not possible. For an incoming socket connection, a server hosting multiple domains on the same IP address cannot decide which domain to actually forward the request based on socket address alone. The socket address, in turn, comprises of the IP address and a port number. So far so good, but what if the debugging server resided on a virtual host hosting multiple domain names? We cannot use sockets anymore.Ī socket connection between two endpoints is characterized by a pair of socket addresses, one for each node. These debugging servers transport the debugger commands, messages and relevant data over a TCP/IP network through BSD sockets. IDA can remotely debug another binary in two ways - through a gdbserver or by the provided debugger servers (located in dbgsrv directory). This feature is very useful in situations such as when we want to debug an executable for an arm device as installing IDA on it is not possible. IDA Pro provides remote debugging capability that allows us to debug a target binary residing on a different machine over the network.