You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
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
The text was updated successfully, but these errors were encountered:
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 innmap-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:
payload.cc
to retrieve payloads from theAllProbes
class defined inservice_scan.h
A good solution will also:
struct payload
to theServiceProbe
it is related to.Ideally, we would like to:
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 thisThe text was updated successfully, but these errors were encountered: