Re: [nmap-svn] r31823 - nmap-exp/d33tah/ncat-lua-callbacks/ncat

[David Fifield <david () bamsoftware com>]

On Thu, Aug 15, 2013 at 12:51:29AM +0200, Jacek Wielemborek wrote:
> 2013/8/15 David Fifield <david () bamsoftware com>:
> > On Thu, Aug 15, 2013 at 12:46:49AM +0200, Jacek Wielemborek wrote:
> > > ...and replace ncat_recv calls with something that understands it?
> >
> > Yes. Feel free to introduce new abstractions.
>
> Right now it doesn't feel like adding abstractions, but replacing
> interfaces - an alternative to ncat_recv that takes int *size, returns
> a buffer which is allowed to be NULL to signal "not error, just an
> empty string, come back to select()". It will affect a lot of code
> too.

This kind of thing is not unprecendented. Look at r16410, which replaced
SSL_read/recv with ncat_recv; and r16993, which introduced fdinfo_recv.

Since a Lua filter can legitimately return 0 bytes in response to a
receive, I don't think you'll be able to use a function with the same
signature as ncat_recv at the top level. You need to design a new
interface that allows you to return 0 bytes without it meaning
end-of-stream. This could be done through additional pointer arguments,
for example. In other words, you probably will have to replace
ncat_recv, everywhere it is called, with something else. (Or change the
signature of ncat_recv, and introduce a new function to do what the old
ncat_recv did.)

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