In medias res: a demo program for performing ARP attacks using FreeBSD's BPF device
Switch branches/tags
Nothing to show
Clone or download
Submanifold Incipit
Putting the old code on GitHub because I am starting to remove it from
my website.
Latest commit 69eefdf Nov 4, 2018
Permalink
Failed to load latest commit information.
GPL Incipit Nov 4, 2018
Makefile Incipit Nov 4, 2018
OLD_CODE Incipit Nov 4, 2018
OLD_INCLUDES Incipit Nov 4, 2018
README Incipit Nov 4, 2018
README.html Incipit Nov 4, 2018
go.sh Incipit Nov 4, 2018
imr Incipit Nov 4, 2018
imr.cpp Incipit Nov 4, 2018
imr.cpp.bak Incipit Nov 4, 2018
log.log Incipit Nov 4, 2018
mod_arp.cpp Incipit Nov 4, 2018
mod_arp.h Incipit Nov 4, 2018
mod_bpf.cpp Incipit Nov 4, 2018
mod_bpf.h Incipit Nov 4, 2018
mod_eth.cpp Incipit Nov 4, 2018
mod_eth.h Incipit Nov 4, 2018

README

NAME
    IMR -- an ARP table attack program

SYNOPSIS
    imr *ether_addr* *ip_addr* *ether_addr* *ip_addr* *ether_addr* *ip_addr*
    *interface* [*logfile*]

DESCRIPTION
    IMR is short for 'In Medias Res'. It is a program that allows you to
    perform an ARP table attack on two hosts, named *client* and *server*.
    Thus, all traffic from the server to the client will be sent to you, as
    well as all traffic from the client to the server. IMR simply routes all
    incoming data to the appropriate host and logs it to your disk for
    further inspections.

    IMR gives you the ability to check whether your network is secured
    against ARP attacks. Furthermore, it allows you to analyze networking
    protocols in great detail without changing data.

  HOW IT WORKS
    This is what IMR does:

    Send (forged) ARP replies
                Two ARP replies of the form 'a.b.c.d is at AB:CD:EF:GH' are
                sent to both the client and the server, hence ensuring that
                both hosts consider this PC the current communication
                partner.

    Read data   Now all incoming data is read. A loop checks whether they
                originate from the client or from the server. During this
                check, the destination address of the current Ethernet frame
                is set to the proper MAC address, so that the packets don't
                get stuck.

    Log data    Everything is logged in raw format, i.e. each packet plus
                all of its payload is written to the disk. The log file does
                not look good, but it will allow a complete reconstruction
                of each packet.

    Reset the ARP tables
                After the routing has been cancelled, two ARP replies are
                sent that restore the ARP table, so that the proper MAC
                addresses are set.

  WHY IT WORKS
    To work properly, ARP needs an ARP table, in which pairs of MAC
    addresses and IP addresses are saved. This is why your kernel 'knows'
    the destination address of the Ethernet frame. Unfortunately, ARP
    doesn't check whether packets have been requested or not. So you are
    able to poison the ARP table by sending your own ARP replies that say
    something like 'You will find this IP address at my MAC address'. There
    is no possibility for ARP to validate your MAC address / IP address
    pair, so it will be added to the table.

CAVEATS
    Please be aware of the fact that IMR is a diagnostic application. The
    code will give you some information about the *Berkeley Packet Filter*,
    BPF, but IMR is really *not* meant as an attack tool of any sort. Even
    if you are the administrator of your LAN, you are by no means allowed to
    capture the data of your users without telling them...

OTHER INFO
    You might find newer versions of IMR at http://canmore.sdf-eu.org

COPYRIGHT
    IMR is licenced under the GNU General Public Licence. Read the file GPL
    in IMR's directory for more information.

AUTHOR
    IMR has been written by Bastian Rieck <canmore [AT] sdf-eu.org>