Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UDP -sV speedup ideas #2541

Closed
dmiller-nmap opened this issue Oct 10, 2022 · 0 comments
Closed

UDP -sV speedup ideas #2541

dmiller-nmap opened this issue Oct 10, 2022 · 0 comments

Comments

@dmiller-nmap
Copy link

dmiller-nmap commented Oct 10, 2022

UDP scanning is one of the slowest processes for Nmap, due largely to the fact that most invalid UDP datagrams are ignored by the target service. nmap-payloads remedies this somewhat by defining data payloads that have a high chance of eliciting a response from a target service on a particular port. We also have probes defined in nmap-service-probes that are designed to get a unique response from various software implementations. If we used these probes as data payloads, we could increase the chance of getting a response from various UDP services. Other benefits might result as well.

Brief description of work items necessary to accomplish this:

  • Extend functions from payload.cc to retrieve payloads from the AllProbes class defined in service_scan.h
  • Ensure "duplicate payload" warnings are not produced at normal or verbosity level 1 when they come from this retrieval.

A good solution will also:

  • avoid duplicating payload data in memory, perhaps by linking the struct payload to the ServiceProbe it is related to.

Ideally, we would like to:

  • Save any responses to probes from the port scan phase in order to match them in the service scan phase.
  • Save any responses to payloads from the port scan phase in order to print them in the service fingerprint if the service scan does not find a match.
  • Provide a means such as a nmap-service-probes directive to avoid sending a probe in this manner, for the case where a particular probe is found to be unsuitable for this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant