Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [nmap-svn] r31823 - nmap-exp/d33tah/ncat-lua-callbacks/ncat
From: David Fifield <david () bamsoftware com>
Date: Wed, 14 Aug 2013 22:04:57 -0700

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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault