Re: nmap-dev Digest, Vol 53, Issue 1

[adt deniz <adtinbox () gmail com>]

Fuck your mother :@ delete my mail in your maillist

2009/8/3, nmap-dev-request () insecure org <nmap-dev-request () insecure org>:
> Send nmap-dev mailing list submissions to
>       nmap-dev () insecure org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>       http://cgi.insecure.org/mailman/listinfo/nmap-dev
> or, via email, send a message with subject or body 'help' to
>       nmap-dev-request () insecure org
>
> You can reach the person managing the list at
>       nmap-dev-owner () insecure org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of nmap-dev digest..."
>
>
> Today's Topics:
>
>    1. Nmap 5 (14531) - compilation warnings (Sebastian Lopienski)
>    2. Re: Nmap 5 (14531) - compilation warnings (Henri Salo)
>    3. Nmap Windows Makefile (ithilgore)
>    4. Ncrack --resume option (ithilgore)
>    5. Re: Ncrack --resume option (Henri Salo)
>    6. Building against external libdnet (was: Build Nmap-5.00
>       without sctp    support) (Daniel Roethlisberger)
>    7. Nmap 5 (14531) - compilation warnings (Sebastian Lopienski)
>    8. Nmap-dev-only release: Nmap 3.10ALPHA1 (Sammy Cheng)
>    9. Status Report #15 of 17 (Luis M.)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 30 Jul 2009 14:36:07 +0200
> From: Sebastian Lopienski <Sebastian.Lopienski () cern ch>
> Subject: Nmap 5 (14531) - compilation warnings
> To: "nmap-dev () insecure org" <nmap-dev () insecure org>
> Message-ID:
>       <FA1EC4A372DF7D458494A923703997381591F612 () cernxchg72 cern ch>
> Keywords: CERN SpamKiller Note: -50
> Content-Type: text/plain; charset="us-ascii"
>
> Dear Nmap developers,
>
> (I have taken over Nmap maintenance at CERN from Lionel Cons, who you have
> seen on this list before).
>
> First, thank you for your efforts on developing Nmap 5! I'm not sure if you
> are interested in this kind of feedback, but here are compilation warnings I
> got for Nmap 5 (revision 14531) on my Linux box. It is Scientific Linux CERN
> 5 (based on Red Hat Enterprise 5) machine, kernel 2.6.18-128.1.10.el5,
> architecture x86_64.
>
> config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
> setting
> config.status: WARNING:  Makefile.in seems to ignore the --datarootdir
> setting
> config.status: WARNING:  include/Makefile.in seems to ignore the
> --datarootdir setting
> config.status: WARNING:  include/dnet/Makefile.in seems to ignore the
> --datarootdir setting
> config.status: WARNING:  src/Makefile.in seems to ignore the --datarootdir
> setting
> config.status: WARNING:  Makefile.in seems to ignore the --datarootdir
> setting
> config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
> setting
> Makefile:312: makefile.dep: No such file or directory
> rand.c: In function 'rand_open':
> rand.c:84: warning: ignoring return value of 'read', declared with attribute
> warn_unused_result
> intf.c: In function 'intf_get_dst':
> intf.c:650: warning: pointer targets in passing argument 3 of 'getsockname'
> differ in signedness
> ip.c: In function 'ip_open':
> ip.c:43: warning: pointer targets in passing argument 5 of 'getsockopt'
> differ in signedness
> Makefile:80: makefile.dep: No such file or directory
> Makefile:160: makefile.dep: No such file or directory
> ncat_proxy.c: In function 'ncat_http_server':
> ncat_proxy.c:161: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> ncat_broker.c: In function 'read_and_broadcast':
> ncat_broker.c:323: warning: passing argument 2 of 'fix_line_endings' from
> incompatible pointer type
> ncat_broker.c:371: warning: passing argument 4 of 'chat_filter' from
> incompatible pointer type
> ncat_ssl.c: In function 'ssl_cert_fp_str_sha1':
> ncat_ssl.c:425: warning: passing argument 4 of 'X509_digest' from
> incompatible pointer type
> scan_engine.cc: In function 'void begin_sniffer(UltraScanInfo*,
> std::vector<Target*, std::allocator<Target*> >&)':
> scan_engine.cc:5040: warning: format '%u' expects type 'unsigned int', but
> argument 3 has type 'long unsigned int'
>
> Cheers,
> Sebastian Lopienski
> CERN
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 30 Jul 2009 15:42:14 +0300
> From: Henri Salo <henri () nerv fi>
> Subject: Re: Nmap 5 (14531) - compilation warnings
> To: nmap-dev () insecure org
> Message-ID: <20090730154214.3e8d14f9 () foo fgeek fi>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 30 Jul 2009 14:36:07 +0200
> Sebastian Lopienski <Sebastian.Lopienski () cern ch> wrote:
>
> <snip>
> > First, thank you for your efforts on developing Nmap 5! I'm not sure
> > if you are interested in this kind of feedback, but here are
> > compilation warnings I got for Nmap 5 (revision 14531) on my Linux
> > box. It is Scientific Linux CERN 5 (based on Red Hat Enterprise 5)
> > machine, kernel 2.6.18-128.1.10.el5, architecture x86_64.
> <snip>
>
> I'll bet the community is interested of any kind of feedback. Heck, I'm
> interested! :)
>
> ---
> Henri Salo
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 31 Jul 2009 15:44:32 +0300
> From: ithilgore <ithilgore.ryu.l () gmail com>
> Subject: Nmap Windows Makefile
> To: nmap-dev <nmap-dev () insecure org>
> Message-ID: <4A72E730.9040302 () gmail com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello,
> I recently built the NSIS installer for Ncrack and wrote the corresponding
> Makefile which is based on that of Nmap's. However, in Nmap's Makefile there
> are
> two somewhat non-conventional points:
>
> 1) The path for NSIS is assumed as C:\apps\NSIS
> However, the default path for NSIS normally is C:\Progam Files\NSIS
>
> 2) The path for cygwin's c drive is assumed as /c, while the default
> is /cygdrive/c which requires the developer to make a symlink.
>
> Is there a reason for these 2 changes?
>
> Since Ncrack needs to be largely compatible with Nmap, even when that just
> involves compilation, I would propose that we either change Nmap's Makefile
> to
> handle the default paths or if that is not considered as generic (for
> reasons
> that I am not currently aware of) I can change Ncrack's Makefile to use the
> same
> paths as Nmap's.
>
> Regards,
> ithilgore
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 31 Jul 2009 15:59:46 +0300
> From: ithilgore <ithilgore.ryu.l () gmail com>
> Subject: Ncrack --resume option
> To: nmap-dev <nmap-dev () insecure org>
> Message-ID: <4A72EAC2.9070604 () gmail com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello nmap-dev.
>
> One of the options that Ncrack will eventually support is --resume, which
> will
> enable the user to temporarily stop a cracking session (usually by Ctrl+C)
> and
> later continue from where it left by calling Ncrack with --resume. However
> there
> are some points to consider here:
>
> Nmap supports the same option by saving some state information in the output
> files just before closing after catching the terminating signal (whatever
> that
> may be). The state information used is:
> a) Nmap's invocation arguments
> b) How many hosts have been *completed* up until that time
>
> What this essentially means, is that if a host was partially scanned at the
> time
> Nmap was closed, then that host will have to be rescanned from the
> beginning.
>
> Now, supporting the same thing in Ncrack is fairly easy, since parsing that
> information from the log files isn't much work. However, Ncrack is of
> different
> nature and a better approach would be to able to continue from almost the
> exact
> moment that Ncrack was stopped. This means that if a host had half the
> username/password list completed at the time Ncrack is closed, then Ncrack
> will
> continue from cracking the rest of the half username/password list when
> restarted with the --resume option.
> This provides maximum flexibility in our scans, however the implementation
> now
> gets a lot more complex. To be able to attain that level of state retrieval,
> Ncrack will have to dump nearly all current information into a separate
> special
> file (which can be binary or text) and then reparse it when it is resumed.
> Since, most of that information is inside Ncrack's different Classes and
> that
> involves a lot of dynamic memory (in addition to STL lists and vectors) it
> would
> require an Object Serialization scheme.
> There are a couple of resources on the net about how this is implemented,
> and it
> is usually done by writing the memory length inside a fixed-size value that
> is
> parsed before a dynamic object is retrieved. By that way, the parser knows
> how
> many bytes to allocate to the next variable-length object.
>
> Anyway, I would like your opinions on this matter. I think the 2nd more
> flexible
> approach is worth the trouble, yet it is fairly challenging. What do you
> think?
>
> Cheers,
> ithilgore
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 31 Jul 2009 17:57:49 +0300
> From: Henri Salo <henri () nerv fi>
> Subject: Re: Ncrack --resume option
> To: nmap-dev () insecure org
> Message-ID: <20090731175749.28b3d90c () foo fgeek fi>
> Content-Type: text/plain; charset=US-ASCII
>
> On Fri, 31 Jul 2009 15:59:46 +0300
> ithilgore <ithilgore.ryu.l () gmail com> wrote:
>
> <snip>
> > Anyway, I would like your opinions on this matter. I think the 2nd
> > more flexible approach is worth the trouble, yet it is fairly
> > challenging. What do you think?
> >
> > Cheers,
> > ithilgore
>
> Definately worth of the trouble. If this takes lots of time we could
> make the easier solution first and continue developing this aside.
>
> ---
> Henri Salo
>
>
> ------------------------------
>
> Message: 6
> Date: Sun, 2 Aug 2009 17:11:03 +0200
> From: Daniel Roethlisberger <daniel () roe ch>
> Subject: Building against external libdnet (was: Build Nmap-5.00
>       without sctp    support)
> To: nmap-dev () insecure org
> Cc: bigionews () snb it, pawlowski.mp () gmail com
> Message-ID: <20090802151102.GC25899 () hobbes ustdmz roe ch>
> Content-Type: text/plain; charset=us-ascii
>
> Giovanni Bechis <bigionews () snb it> 2009-07-27:
> > David Fifield wrote:
> > > Hello. There should be no need to port Nmap to OpenBSD. If it takes
> > > special work to make it compile or run then it's a bug, so please submit
> > > a patch so that we can integrate it with the mainline code.
> > We added a sctp.h file to the source to let nmap build (otherwise nmap
> > cannot find a few structs)
>
> You are trying to build against an external libdnet from OpenBSD
> ports, right?  To do so, you'd need to update the libdnet port to
> latest libdnet trunk [1] or use Nmap's internal libdnet.  Dug
> Song so far hasn't released a libdnet release including my SCTP
> extensions.
>
> [1] http://code.google.com/p/libdnet/
>
> However, since the Nmap internal libdnet has a lot of patches
> which have not been merged to upstream libdnet, using external
> libdnet is not such a terribly good idea anyway.  Users of the
> OpenBSD port will miss out on many small bugfixes and
> Nmap-specific improvements to libdnet.  You could of course add
> patches containing all the libdnet additions in Nmap's
> libdnet-stripped to the libdnet port.  Beware that many of these
> are untested outside of Nmap.
>
> Actually, I'd suggest we remove or disable the ./configure option
> to build Nmap against an external libdnet as long as the list of
> unmerged patches is as long as it is currently.  It's not just
> the SCTP stuff which is missing in external libdnet versions.  Or
> at least add a warning to the description of the option in
> ./configure --help.  Opinions?
>
> --
> Daniel Roethlisberger
> http://daniel.roe.ch/
>
>
> ------------------------------
>
> Message: 7
> Date: Sun, 2 Aug 2009 18:00:29 -0700
> From: Sebastian Lopienski <Sebastian.Lopienski () cern ch>
> Subject: Nmap 5 (14531) - compilation warnings
> To: nmap-dev () insecure org
> Message-ID: <20090803010029.GB11979 () syn lnxnet net>
> Content-Type: text/plain; charset=us-ascii
>
> Dear Nmap developers,
>
> (I have taken over Nmap maintenance at CERN from Lionel Cons, who you have
> seen on this list before).
>
> First, thank you for your efforts on developing Nmap 5! I'm not sure if you
> are interested in this kind of feedback, but here are compilation warnings I
> got for Nmap 5 (revision 14531) on my Linux box. It is Scientific Linux CERN
> 5 (based on Red Hat Enterprise 5) machine, kernel 2.6.18-128.1.10.el5,
> architecture x86_64.
>
> config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
> setting
> config.status: WARNING:  Makefile.in seems to ignore the --datarootdir
> setting
> config.status: WARNING:  include/Makefile.in seems to ignore the
> --datarootdir setting
> config.status: WARNING:  include/dnet/Makefile.in seems to ignore the
> --datarootdir setting
> config.status: WARNING:  src/Makefile.in seems to ignore the --datarootdir
> setting
> config.status: WARNING:  Makefile.in seems to ignore the --datarootdir
> setting
> config.status: WARNING:  'Makefile.in' seems to ignore the --datarootdir
> setting
> Makefile:312: makefile.dep: No such file or directory
> rand.c: In function 'rand_open':
> rand.c:84: warning: ignoring return value of 'read', declared with attribute
> warn_unused_result
> intf.c: In function 'intf_get_dst':
> intf.c:650: warning: pointer targets in passing argument 3 of 'getsockname'
> differ in signedness
> ip.c: In function 'ip_open':
> ip.c:43: warning: pointer targets in passing argument 5 of 'getsockopt'
> differ in signedness
> Makefile:80: makefile.dep: No such file or directory
> Makefile:160: makefile.dep: No such file or directory
> ncat_proxy.c: In function 'ncat_http_server':
> ncat_proxy.c:161: warning: dereferencing type-punned pointer will break
> strict-aliasing rules
> ncat_broker.c: In function 'read_and_broadcast':
> ncat_broker.c:323: warning: passing argument 2 of 'fix_line_endings' from
> incompatible pointer type
> ncat_broker.c:371: warning: passing argument 4 of 'chat_filter' from
> incompatible pointer type
> ncat_ssl.c: In function 'ssl_cert_fp_str_sha1':
> ncat_ssl.c:425: warning: passing argument 4 of 'X509_digest' from
> incompatible pointer type
> scan_engine.cc: In function 'void begin_sniffer(UltraScanInfo*,
> std::vector<Target*, std::allocator<Target*> >&)':
> scan_engine.cc:5040: warning: format '%u' expects type 'unsigned int', but
> argument 3 has type 'long unsigned int'
>
> Cheers,
> Sebastian Lopienski
> CERN
>
>
> ------------------------------
>
> Message: 8
> Date: Sun, 2 Aug 2009 18:35:58 -0700
> From: Sammy Cheng <sammycheng.cmm () gmail com>
> Subject: Nmap-dev-only release: Nmap 3.10ALPHA1
> To: nmap-dev () insecure org
> Message-ID: <20090803013558.GB14449 () syn lnxnet net>
> Content-Type: text/plain; charset=us-ascii
>
>
> Hey,
>
> I'm using Nmap5.00 to perform some scanning in IPv6. And I see this on
> screen:
> IPv6 support is currently only available for connect() scan (-sT), ping scan
> (-sP), and list scan (-sL).  OS detection, random targets and decoys are
> also not supported with IPv6.
> I've tried to look for some documentation on Nmap5.00, but failed.
>
> However, I've read a documentation about Nmap2.54BETA *Extension of a
> network scanning tool with IPv6 features (Nmap),* in which the author
> Sebastien Peterson tested all kinds of scans including SYN scan, FIN scan
> and so on.
> But I ran into some problems when installing Nmap2.54BETA: it always said
> the
> parameter of wait() is not right when executing "make". So I don't know
> whether it works as the author said or not.
>
> I'm very confused now. Is there any version of Nmap that can support more
> kinds of scan in IPv6?
>
> Thanks in advance for your kind help.
>
> Yours,
> Sammy Cheng
>
>
>
>
> ------------------------------
>
> Message: 9
> Date: Mon, 03 Aug 2009 20:51:54 +0200
> From: "Luis M." <luis.mgarc () gmail com>
> Subject: Status Report #15 of 17
> To: nmap-dev <nmap-dev () insecure org>
> Message-ID: <4A7731CA.7030009 () gmail com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi!
>
> Here are some of the accomplishments of last week and priorities
> for this week:
>
>
> Accomplishments:
>
>
> * Many improvements in IPv6 support.
> * Added support for detailed statistics: packet counts, tx and rx rates,
>   round trip delay times, per-target stats, etc.
> * Big enhancements in packet display format. Now 3 different levels of
>   detail are supported. ICMP was specially improved since Nmap original
>   code did not display ICMP-type specific information. Code of the
> function in
>   charge of packet display (ippackethdrinfo()) has been reorganized and
>   commented to make it easier to maintain. Also, some bugs were fixed.
> * Many improvements in packet creation default choices in ID numbers,
>   Sequence numbers, Ack numbers, etc.
> * Finished raw-ethernet support. From now on, users can send probes
> either at
>   raw IP level or at raw Ethernet frame level. This should be specially
> useful
>   under Windows since MS does not provide raw sockets anymore.
> * Fixed a bug in processSpecs(): it failed to rewind the spec internal
>   counters so under some circumstances, the first target spec was being
>   ignored.
> * Added functions to store ICMP identification and sequence numbers
>   so it's possible to use the same id per target and consistent
> monotonically
>   increasing sequence numbers.
> * Little reorganization of verbosity levels.
> * Fixed memset() related bug that could result in a buffer overflow.
> * Fixed bug produced when incrementing verbosity when debugging level
>   is specified.
> * Fixed bug that caused the last reply not being received due to a
> problem in
>   post-transmission waiting period.
> * Cleanup of Argparser() source.
> * Decided to postpone Nping Echo Mode implementation until all important
>   TO-DO items are implemented and IPv6 support is added.
> * Had a meeting with Fyodor
> * Scheduled next meeting.
>
> Priorities:
>
> * Finish porting Nping to Windows.
> * Finish IPv6 support.
> * Finish support for ICMP netmask messages.
> * Start testing on Mac OS.
>
> Regards,
>
>
> Luis.
>
>
> ------------------------------
>
> _______________________________________________
> nmap-dev mailing list
> nmap-dev () insecure org
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
>
>
> End of nmap-dev Digest, Vol 53, Issue 1
> ***************************************

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