KJK::Hyperion ha scritto:
Previous scanning worms, such as Code Red, spread via many threads,
each invoking connect() to probe random addresses.
what the hell is this? visiting the iniquity of the applications upon
the protocols? Winsock is probably the only API that lets you connect()
Isn't it true that a TCP packet is typically 20 bytes, and a UDP packet
about 8? This is minus any additional data that has been added to the
packet. If this is true, then depending on the size of the pipe your sending
the data through, and the amount of congestion there might be, a UDP packet
On Thu, 06 Mar 2008 09:13:05 EST, Static Rez said:
Isn't it true that a TCP packet is typically 20 bytes, and a UDP packet
about 8? This is minus any additional data that has been added to the
packet. If this is true, then depending on the size of the pipe your sending
the data through, and
hey dude, how is merely sending a single datagram not going to be faster
than doing an entire handshake?
On Tue, Mar 4, 2008 at 12:53 AM, Sebastian Krahmer [EMAIL PROTECTED] wrote:
This is not true. I doubt there is any measurable advantage
of UDP vs. TCP scans if you do it right.
dude, you don't need the entire handshake for tcp scanning.
On Wed, Mar 5, 2008 at 2:54 PM, Andrew A [EMAIL PROTECTED] wrote:
hey dude, how is merely sending a single datagram not going to be faster
than doing an entire handshake?
On Tue, Mar 4, 2008 at 12:53 AM, Sebastian Krahmer [EMAIL
Hi dude,
On Wed, Mar 05, 2008 at 04:54:16AM -0800, Andrew A wrote:
hey dude, how is merely sending a single datagram not going to be faster
than doing an entire handshake?
First, to know whether a TCP port is open you do not need
a complete handshake. A single TCP packet is enough.
I doubt
Hi,
all due to the unreliable nature of UDP.
But the most important thing is, that if you do it large scale*,
you have to wait for some sort of reply anyways,
either TCP SYN|ACK or some application data. This time of waiting
can be used to SYN/request yet another 10,000 hosts.
Thus, how
That single UDP datagram is definitely faster. Compare the Code Red
worm to Sapphire (SQL Slammer), for instance:
Previous scanning worms, such as Code Red, spread via many threads,
each invoking connect() to probe random addresses. Thus each thread's
scanning rate was limited by network latency,
sub ha scritto:
Previous scanning worms, such as Code Red, spread via many threads,
each invoking connect() to probe random addresses.
what the hell is this? visiting the iniquity of the applications upon
the protocols? Winsock is probably the only API that lets you connect()
asynchronously
No, but if you're querying the services for data you do.
On 3/5/08, Dmitry [EMAIL PROTECTED] wrote:
dude, you don't need the entire handshake for tcp scanning.
___
Full-Disclosure - We believe in it.
Charter:
On Tue, Mar 04, 2008 at 12:02:25AM +, Adrian P wrote:
* Exploring the UNKNOWN: Scanning the Internet via SNMP! *
http://www.gnucitizen.org/blog/exploring-the-unknown-scanning-the-internet-via-snmp/
Hacking is not only about coming up with interesting solutions to
problems, but also
Well, such statement is simply derived from my personal experience of
doing application-layer UDP scanning. Never ran a proper benchmark to
compare speed results to be honest.
On Tue, Mar 4, 2008 at 8:53 AM, Sebastian Krahmer [EMAIL PROTECTED] wrote:
On Tue, Mar 04, 2008 at 12:02:25AM +,
* Exploring the UNKNOWN: Scanning the Internet via SNMP! *
http://www.gnucitizen.org/blog/exploring-the-unknown-scanning-the-internet-via-snmp/
Hacking is not only about coming up with interesting solutions to
problems, but also about exploring the unknown. It was this drive for
knowledge
13 matches
Mail list logo
