Re: Working my way through nmap, one function at a time.

[James Rogers <jamesmrogers () gmail com>]

My write up is probably a little confusing, I'll try to explain here
and add this explanation to the blog.  I read magazines from back to
front too.  And I took all my toys apart when I was a kid. :)

The other analysis I am doing is following the code through in program
execution order.  So I am looking at the code forwards and backwards.
My first code walk though didn't show me any config files being
loaded.  So I was just saying that I can find out using the same
technique in just a few additional minutes.

I always like to analyze programs this way because often it points to
inefficiencies that could be done in better ways.  I feel comfortable
with looking at how a program runs by how it interacts with the
system.  Plus I was really interesting in the actual how things happen
where the rubber meets the road.  I was wondering if we used

For instance, the packet trace option when running nmap shows me a
packet that is being received:

RCVD (0.4640s) TCP 127.0.0.1:8080 > 127.0.0.1:39122 RA ttl=64 id=0
iplen=40  seq=0 win=0

Looking at strace the line that matches up to the output is this:

recvmsg(4, {msg_name(18)={sa_family=AF_PACKET, proto=0x800, if1,
pkttype=PACKET_HOST, addr(6)={772, 000000000000},
msg_iov(1)=[{"\0\0\0\0\0\0\0\0\0\0\0\0\10\0E\0\0(\0\0@\0@\6<\316\177\0\0\1\177\0"...,
256}], msg_controllen=32, {cmsg_len=32, cmsg_level=SOL_PACKET,
cmsg_type=, ...}, msg_flags=0}, MSG_TRUNC) = 54

And putting a breakpoint in recvmsg() in gdb shows me this:

#0 recvmsg () at ../sysdeps/unix/sysv/linux/i386/socket.S:46
#1 0x0811b729 in pcap_read_packet (handle=0x84eb200, max_packets=1,
callback=0x8106a60 <pcap_oneshot>,
user=0xbfffe430 "x\344\377\277<\344\377\277") at ./pcap-linux.c:1502
#2 pcap_read_linux (handle=0x84eb200, max_packets=1,
callback=0x8106a60 <pcap_oneshot>, user=0xbfffe430
"x\344\377\277<\344\377\277") at ./pcap-linux.c:1407
#3 0x08106f17 in pcap_dispatch (p=0x84eb200, cnt=1, callback=0x8106a60
<pcap_oneshot>, user=0xbfffe430 "x\344\377\277<\344\377\277") at
./pcap.c:497
#4 0x08106f65 in pcap_next (p=0x84eb200, h=0xbfffe478) at ./pcap.c:180
#5 0x0807d107 in readip_pcap (pd=0x84eb200, len=0xbfffe548,
to_usec=999717, rcvdtime=0xbfffe534, linknfo=0xbfffe8dc,
validate=true) at tcpip.cc:1660
#6 0x080b8928 in get_pcap_result (USI=0x84ea4a8, stime=0xbfffea04) at
scan_engine.cc:4283
#7 0x080be05f in waitForResponses (Targets=..., ports=0x826b9e0,
scantype=SYN_SCAN, to=0x0) at scan_engine.cc:5336
#8 ultra_scan (Targets=..., ports=0x826b9e0, scantype=SYN_SCAN,
to=0x0) at scan_engine.cc:5645
#9 0x08076874 in nmap_main (argc=7, argv=0xbffff6e4) at nmap.cc:1889
#10 0x0806e9c5 in main (argc=7, argv=0xbffff6e4) at main.cc:198

Which tells me that the pcap library is being used, that it is called
from waitForResponses on line 5336 in the ultra_scan function on line
5645.  Even better, because ultra_scan is called a dozen times in
nmap_main, I know that ulra_scan() is being called here because

1888       if (o.synscan)
1889         ultra_scan(Targets, &ports, SYN_SCAN);

Then I look at the code and follow this trail upward and it is very
clear why it works this way.

Now that I am all set up it is only going to take a few minutes to
figure out where and give context as to why the program is loading
each config file and opening all these ports on startup.

On Sun, May 6, 2012 at 9:07 PM, Littlefield, Tyler <tyler () tysdomain com> wrote:
> I am really confused. rather than muddle your way through strace and debug
> everything with gdb, why not just ask where the configuration files are
> loaded, or follow it in the code? Using strace and reading through all that
> just to figure out the config files (and it still won't show you where in
> the program they're loaded) seems like you're bashing your head into a wall
> for no apparent reason.
>
> Maybe I'm wrong here and I should just go back under my rock, but...
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/