Re: GSOC 2012

[SAI LAKSHMI Bhavana <oslbhavana () gmail com>]

> You are getting the right idea. Let me ask you some questions to help
> clarify your thinking. Suppose you have some pseudocode like this:
>        struct proxy proxy1 = { PROXY_SOCKS4A, "proxy1", 9100 };
>        struct proxy proxy2 = { PROXY_HTTP, "proxy2", 8080 };
>        struct proxy proxy3 = { PROXY_SOCKS5, "proxy3", 3128 };
>        nsock_add_proxy(nsp, &proxy1);
>        nsock_add_proxy(nsp, &proxy2);
>        nsock_add_proxy(nsp, &proxy3);
>        nsock_connect_tcp(nsp, handle_connect, "target", 80);
> You need to think about it in terms of events and callbacks. So for
> example, I think that the final function call above will call
> nsock_connect_tcp_primitive(nsp, handle_socks4a_proxy_connect, "proxy1", 9100).
> The handle_socks4a_proxy_connect callback function will send the SOCKS
> proxy request for proxy2:8080, and register its own callback to read the
> response. The read callback will then (assuming the proxy request
> succeeds) send the next HTTP request, and so on.
> What
> internal callback functions do you think will be necessary? It may help
> to walk through the example I gave you, knowing that you have to make it
> work as several function calls that you don't control directly, not just
> a simple blocking while loop.

Hello Sir,

For the above given example
handle_socks4a_proxy_connect callback on success of the connect event
      creates a ms_event of type NSE_WRITE and sends socks proxy
request for proxy2:8080
      *nse = new ms_event(*nsp, NSE_WRITE, *ms_iod, timeout_secs,
handle_socks4a_proxy_write, *userdata);
handle_socks4a_proxy_write callback on success of write event creates
a NSE_READ event
      *nse = new ms_event(*nsp, NSE_READ, *ms_iod, timeout_secs,
handle_socks4a_proxy_read, *userdata);
handle_socks4a_proxy_read callback on success of read event creates a
NSE_WRITE event for the next proxy in chain so on.


> What new event types do you think will be necessary (if any)?

I think of having a new event type NSE_TYPE_PROXY_CONNECT;

> How will you remember your position in the proxy list between function
> calls? I suspect we will need to add a new member to nsock_iod. Is there
> any other new state you think will be needed?

we can create a gh_list of the proxy structs as gh_list proxy_chain.
This list can be made a member of mspool struct
Another member *next_proxy to know the next proxy to be handled in the
proxy chain.

A new state NSE_STATUS_PROCESS is necessary to represent that the
proxy chain is being handled.

> (P.S. Your step (2) above should send a SOCKS request to proxy1, not an
> HTTP request.)
   yes :)
> > the request to be sent for a particular proxy HTTP or SOCKS can be
> > known from two methods that can  be included  namely
> > req_http_proxy(url), req_socks_proxy(url)
>
> I don't understand what these functions do. What do they return, a
> string containing the request text? In what other functions will these
> functions be called?

yes, these functions just return a string containing the request text
this will help up having just one callback such as handle_proxy_write
rather than having handle_socks4a_proxy_write and
handle_http_proxy_write.

Sir please let me know how to write a good proposal :)

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