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

["Littlefield, Tyler" <tyler () tysdomain com>]

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...
On 5/6/2012 6:39 PM, James Rogers wrote:
> Added gdb stack traces to the strace results I posted here the other day.
>
> http://mystry-geek.blogspot.com/2012/05/analyzing-nmap-using-strace.html
>
> Going to do this several more times with different command line
> arguments to work out exactly what the program is telling the OS to do
> when different options change the behavior of the program, and then
> checking the stack against gdb at those points in the program.
>
> Also planning on doing gdb stack traces of where the config files are
> being loaded in, because this is not clear in looking at the code.
>
> --
>
> With a better understanding of what is happening and where it is being
> called I began going through the program one function at a time,
> understanding what each does in turn.  I am going to accumulate all my
> thoughts about the program here:
>
> http://mystry-geek.blogspot.com/2012/05/analysis-of-nmap-program-flow.html
>
> Going to work on this for the entire summer (as I figure out a new
> part of the program).  Try to get a complete view of the entire
> program before I am done.
>
> --
>
> A question I have about ultra_scan() in scan_engine.cc  is that it
> appears that it does one scan at a time, and then waits for the
> response. Is that right?
>
> Or does it send out all the requests and then waits for all the responses?
>
> Does that behavior depend on the type of scan?
>
> Is scripting done through ultra_scan() as well?

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/