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 15:48:07 -0700

On Thu, Aug 15, 2013 at 12:46:49AM +0200, Jacek Wielemborek wrote:
2013/8/15 David Fifield <david () bamsoftware com>:
On Thu, Aug 15, 2013 at 12:36:27AM +0200, Jacek Wielemborek wrote:
2013/8/15 David Fifield <david () bamsoftware com>:
You should try inverting your abstractions. If ncat_recv returns the
string result of possibly many layers of Lua filters, that indeed makes
it hard to test whether the socket is closed. So don't do that. When you
find that a socket is closed (through a zero-byte read), all you need to
do is report it to the next layer up, and only in that one place. The
Lua code in the next layer is now responsible for doing something
intelligent with the error. You should read about how sockets work in
When a socket read fails, you want to return (nil, err) to the caller.
You are almost certainly going to have to define a new function at the
top level that understands those Lua return values and transforms them
into something useful for the C caller. You probably will not be able to
use a zero-byte string as a close signal at this level.

In other words, you might want to have ncat_recv at the bottom of your
abstraction layers, not at the top.

It's actually both at the top and at the bottom. I still have no idea
how to solve the problem of empty strings - I want to let the bottom
know: "there's nothing there, but don't quit, don't loop over, just
fall back to select". Not sure how to handle it yet.

Just something like

char *magic_recv(size_t *len)
        data, err = call_lua_filter_recv()
        if (data == nil) {
                return NULL
        } else {
                *len = lua_strlen(data)
                return lua_strdup(data)

...and replace ncat_recv calls with something that understands it?

Yes. Feel free to introduce new abstractions.

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

  By Date           By Thread  

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