Nmap Development mailing list archives
Re: Working my way through nmap, one function at a time.
From: James Rogers <jamesmrogers () gmail com>
Date: Sun, 6 May 2012 21:58:16 -0400
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/
Current thread:
- Working my way through nmap, one function at a time. James Rogers (May 06)
- Re: Working my way through nmap, one function at a time. Littlefield, Tyler (May 06)
- Re: Working my way through nmap, one function at a time. James Rogers (May 06)
- Re: Working my way through nmap, one function at a time. Littlefield, Tyler (May 06)