Monday, December 19, 2005


This is a follow up to the previous post. Let's tackle each problem one by one. Note that each problem can have several solutions depending on your preferences/requirements. Of course, I am assuming this system is our dear old Linux box.

  1. You wrote the communication protocol subsystem for a local client-server system (e.g. X-server & the TrueType font server) running on the system and want to verify everything being exchanged between the two over a Unix domain socket or a FIFO or a pipe. What do you do?

    Solution: In this case since you are the developer of the system a very obvious way to tackle this problem is to echo everything being exchanged over the Unix domain socket/FIFO over stdout. You have the source code so you are the master. If the messages are binary you can print them out in hex or store them in separate files - one for the client, other for the server and then examine them later with a hex editor. Obviously, these are required for this to work:

    - You own the source code and know the innards enough to insert debugging statements
    - You are willing to write extra code to debug the client-server
  1. You have recently noticed a suspicious program which seems to be reading/writing to sockets and communicating with another program non-stop over a pipe. And you need a way to find out everything being exchanged over the sockets and the pipe. What do you do?

    Solution: Ok, this one is tricky. If the program is genuinely malicious, then it will not use some way through which it'll take an IP address of some server from the user and try connecting to it like regular FTP/Mail clients do - instead it'll most probably use a hard-coded address (IP/host). This means using a man-in-the-middle kind of server for looking at everything being exchanged is not as straightforward a task. The first step will be to find out the IP address of the machine to which the program is trying to connect. This can be done using simple tools like "lsof/netstat" to find out the sockets opened by the program and checking the IP address there. Now the second task will be to fool the program into connecting to a server with "that IP address". Of course you'll have to write this server or use some freely available tools for the purpose of posing as a man-in-the-middle server. Apply your networking knowledge there (another task for you ;-). Ok, you got hold of the sockets by the ears, what about the pipes?
    Use system call tracers such as "strace" to find out what is being written to pipe file descriptors. To see which file descriptor is which - scourge through /proc/pid/fd directory and check out the ones which say it's a pipe. Attach a system call tracer to the program using it's pid.

    strace -p pid -x -s 1024

    will do for a start ;-). By the way, this trick should work for sockets as well. Told ya, there are more solutions than one to these depending on what you prefer. And I kind of don't prefer any of these. They are too messy. More on this later.

Well, for now these two will do for a start. Me back to work... Meanwhile you muse about the rest of the three. The ideal solution hasn't been discussed mind you. Well, of course you know. Don't ya?


At Wednesday, January 25, 2006 6:52:00 PM, Blogger Teens to Toons said...

not good enough.. you ain't working hard enuff

At Thursday, January 26, 2006 4:53:00 AM, Blogger Sudhanshu said...

Dude, of course you are the best...! Hard to please you ;)


Post a Comment

<< Home