Recently, I used Nemesis to spoof ARP packets on a dsl network with seven nodes. In the process of doing it, I learned a lot about network topology and tcp. Most of it was learned the hard way -- trial and error -- as I could find very little technical details about using Nemesis for
that specific purpose on Google.

Here's how I did it:

1.) My platform was BackTrack 4 (what a beautiful system!) on a 2 GHz P4 ThinkPad, and Ubuntu 10.10 on a 1.7 GHz P4 on a Compaq laptop.

2.) Software used was Nemesis v. 1.4 (Build 26) and my trusty binary editor, Hexedit.
In this case, I actually used Ubuntu 10.04 to disseminate the packets, and
BackTrack 4 for analysis but it could have been down either way.

3.) Installing Nemesis on Ubuntu 10.10 is pretty straightforward. Google nemesis-1.4.orig.tar.gz and install on Ubuntu using the usual Linux compilation method. Note that libnet-1.0.2a must also be installed before nemesis will make. I used gcc-4.1 also. An installation guide may be found at Installing Nemesis on Ubuntu 10.04 - Note that the makefile should be edited to point to your compiler.

4.) An appropriate packet must be crafted as a binary file. I snatched an ARP packet, send
by the gateway, with Wireshark and then used it as a model for this. Typically, these
packets are 28 bytes long and contain the packet type (ARP reply = 0x00 0x02), the gateway MAC address and the MAC address and I.P. of the target machine. Note that I used the word "target" here as no one was defrauded in this experiment. Of course, an unethical person could also install a sniffer and acquire sensitive data using this technique ... in which case the "target" becomes the "victim".

5.) A shell script was then written which invoked Nemesis in a continuous loop. The shell script is reproduced as follows:

while [1 == 1]
nemesis arp -S gateway_MAC -D target_MAC -h sending_Machine_MAC -m target_MAC -P binary_filename

# This will issue continuous ARP requests but is not sufficient to populate the target's ARP
# cache. For this to happen, an ARP reply must be sent immediately thereafter:

nemesis arp -S gateway_MAC -D target_MAC -h sending_Machine_MAC -m target_MAC -r -P binary_filename

Note the -r in the preceding command. This force the packet type to 00 02 which is the reply.

I also added a moderate delay following the packet distributions as some machines seem to hang up if these packets are sent too fast:

sleep .3

While the packets were being issued, and ussing Wiretrack on the BackTrack 4 machine, I was able to view and compare them with the original ones issued by the gateway. If any tweaking needs to be done, it can be done here. Wireshark, another amazing tool, will give full details of each packet, including the length and all data. It also shows the encapsulation by the ethernet layer which is a wonderful way to understand the OSI.

Issuing arp -a on the target will disclosed that the cache has indeed been polluted and the gateway is now perceived to be the Ubuntu machine! The command is the same under Windows and Linux.

At this point, by reassigning the iptables and installing a sniffer, the target's traffic can be routed through the sending machine.

(Now, here's what I don't understand. On some networks, only the target's cache was populated. But on other networks, every machine's cache was populated? Can someone explain this to me?)

That's it. I hope this helps some of you who are security conscious to better understand how packet crafting under Nemesis work. But be careful and use this knowledge only for ethical purposes. Jail is not a pleasant place to live.