Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: Ncat and windows line endings
From: Fyodor <fyodor () insecure org>
Date: Fri, 8 May 2009 20:42:25 -0700

On Thu, May 07, 2009 at 10:48:46PM +0100, jah wrote:

I'd modified the Nmap code to produce the 13 (0x0D) in the error
message.  Turns out that Ncat from a windows shell (also a cygwin shell
which piggybacks the windows shell) sends \r\n as its line endings and
the \r is appended to the command at the other end.  This prevents any
command I've tried from working.  Conversely, a mingw shell sends \n as
its line endings and this issue doesn't arise.

I felt sure that something like this has been raised before, but haven't
found anything pertinent.  Is this a known issue and, more to the point,
can we afford to modify ncat to do something about it given that \r\n
might have been sent as part of a HTTP GET, for example?

Hi Jah.  Excellent point.  I wish we there was a way we could
automatically detect and do "the right thing".  But as you noted,
passing \r\n straight through may be desirable in some cases
(e.g. writing HTTP requests) while changing \r\n to \n is desirable in
others (talking to a UNIX shell).  We should probably at least provide
options for both approaches.  We currently offer:

 -C, --crlf (Use CRLF as EOL)
    This option tells Ncat to try to use CRLF for line-endings if only
    an LF is found. This doesn't convert all LFs to CRLFs, only if
    it's at the end of the read buffer. This is useful for talking to
    some stringent servers directly from a terminal in one of the many
    common plain-text protocols which specify CRLF as the required EOL
    sequence.
    --http://nmap.org/ncat/man.html

First of all, maybe -C should format all bare \n in the buffer to
\r\n.  Is there a good reason (other than ease of implementation) for
only handling bare \n which happens to appear at the end of the
buffer?  Of course it needs to make sure that the \n chars in the
buffer are bare (not preceeded by a \r already).  We don't want to end
up with \r\r\n.

Second, we should probably have an option which does the opposite and
converts \r\n in input to plain \n.  Maybe it could be -N/--newline or
-L/--lf or something.  It should check the whole buffer for \r\n too,
IMHO.

Does anyone have a different idea or should we just implement these
two changes?  Anyone want to write a patch?

Cheers,
-F

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


  By Date           By Thread  

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