#include <cyanid.hpp>
#include <iostream>

using namespace std;

int main(int argc, char* argv[])
{
    if(argc < 6) {
        cerr << "Usage: arp_poisioner [interface] "
             << "[sha] [spa] [tha] [tpa]" << endl;

    const string iface      = argv[1];
    const string source_mac = argv[2];
    const string source_ip  = argv[3];
    const string target_mac = argv[4];
    const string target_ip  = argv[5];

    cyanid::device device(iface)   

    cyanid::packet packet(device);

    packet.build<cyanid::builder::arp>()(
            cyanid::builder::arp::REPLY,
            source_mac,
            source_ip,
            target_mac,
            target_ip);

    packet.build<cyanid::builder::ethernet>()(
            target_mac,
            cyanid::builder::arp::ETHER_TYPE);

    size_t bytes_written = packet.dispatch();
    cout << "Wrote " << bytes_written
         << " bytes to the network" << endl;

    return 0;
}

The code is pretty self explanatory. We first create a device by specifying the network interface we want to use. We then create a packet to be transmitted over this device, and then we build the necessary packet headers (in reversed order) before the packet is actually dispatched. The next thing we need is a way of capturing packets. A simple packet capturer (very similar to the one found in examples/arp_listener) is shown here:

#include <cyanid.hpp>
#include <iostream>

using namespace std;

class Listener : public cyanid::listener {
public:
    Listener(cyanid::device& device) : listener(device)
    {
        apply_filter("arp");
    }

    void handle_packet(const cyanid::raw_packet& packet)
    {
        size_t packet_size = packet.packet_header()->len;
        cyanid::builder::ethernet eth(
            packet.payload(), packet_size);

        size_t arp_size =
            packet_size - cyanid::builder::ethernet::header_size;
        cyanid::builder::arp arp(eth.payload(), arp_size);

        std::string type = arp.oper() ==
            cyanid::builder::arp::REQUEST ? "REQUEST" : "REPLY";

        cout << "Captured ARP packet: " << endl
            << "============================================"
            << endl << "ARP type: " << type << endl
            << "Source hardware address: " << arp.sha() << endl
            << "Target hardware address: " << arp.tha() << endl
            << "Source protocol address: " << arp.spa() << endl
            << "Target protocol address: " << arp.tpa() << endl
            << endl;
    }
};

int main(int argc, char* argv[])
{
    if(argc < 2) {
        cerr << "Usage: arp_listener [IFACE]" << endl;
        return 1;
    }

    const std::string iface = argv[1];

    cyanid::device device(iface);
    Listener listener(device);
    listener.run();

    return 0;
}

There are a couple of things happening here. First and most importantly, the Listener class. Any listener must override the handle_packet method which is called whenever a packet is captured. A raw packet contains a packet header and the actual data, and is passed as an argument to handle_packet for processing. The next thing we do is to reconstruct the ARP packet we captured from the raw packet. Note that this happens in the opposite order of which the packet was built in the first place. There is one more thing that is important to notice; the call to apply_filter in the constructor. This function (which is inherited from cyanid::listener) enables you to filter the traffic we are capturing in the exact same way as with tcpdump. In this example we tell the listener that we are only interested in capturing ARP packets. Now that we know how to capture and injects packets, we’re ready to get our hands dirty. But first, let’s make a list of what we need our program to do in order to get a working firewall up an running:

• The ARP cache is updated on a regular basis, so we need to ARP poison our hosts on a regular basis too. Possible strategies:
  • ARP poison our hosts on a fixed time interval. This may be ineffective. For example, if the ARP cache on our hosts for some reason is updated every 20 seconds and we decide to ARP poison our  hosts on a 10 second interval, the host might end up being cut off from our firewall half the time if our timing is bad. This will happen if we ARP poison the target right before the target receives the legit ARP reply.  Likewise, if we’re firewalling many hosts each with an ARP cache being updated approximately every 10 minutes, we might end up flooding the network with unnecessary traffic if we are ARP poisoning our hosts on, let’s say, a 10 or 20 second interval.
  • Listen for ARP requests going to and from our hosts and then ARP poison accordingly. This way we will only send ARP poison when we have to – that is, right after the hosts sends an ARP request. This will also minimize the amount of time our hosts is cut off from the firewall since we’re ARP poisoning our hosts right after the host has sent an ARP request. But there is a chance that this could all backfire if we’re not careful; we must make sure that our reply comes after the legit ARP reply so we need to add some sort of delay to make sure that we send our spoofed ARP reply after the legit ARP reply.
• When a packet is captured we need to determine the packets destination, and forward it if the packet is allowed through our filter. This might sound like a bit of a hassle, but the only thing we need to do is to duplicate this packet and inject it onto the network. However, we need to replace the spoofed MAC address with the correct one so that the packet is sent to the intended host.
• We need a filtering mechanism. People spend years of their life perfecting different filtering mechanisms. I’m not one of those people, so I’m gonna go with something real simple, like … no filtering!

Alright, so now we need to come up with a design for our implementation. First off, we need a listener that will capture ARP traffic and keep our target hosts high on our benevolent poison. This must run in a separate thread. Then we need a routing mechanism. This routing mechanism should also be a listener, and should capture all IP-based traffic and forward it to the intended hosts. The routing should be done in a separate thread too. Last but not least, we need a filter. Let us make it simple and create a filter class and pass an instance of it to our routing mechanism.  This way the router can determine whether or not to forward a given packet. After screwing around with this for some (way too much) time, I came up with what seems to be a working (ish) implementation.

Step 1: Generate a list of the file names in Vim.

All the files I wanted were in the same folder, so I simply wrote

:r !dir /B *

If you have different folders, you would want file paths and not only file names. If you have other files in the same folder, you would want to specify a filter (like *.cpp).

Step 2: Record a macro.

Macros are wonderful if you want to repeat a few steps several times. First, position the cursor at the beginning of the line with the first file name. To record a macro, press q followed by the name of the register you want to record to macro to. Since I do not want to reuse this macro after I am done generating the file, I use the q register for my macro. You know, because I am too lazy to move my finger. Put together, this means you need to press qq in normal mode (i.e. after pressing Escape). The bottom left corner now says ‘recording’ to indicate it is, well, recording your macro.

'spiller inn' means 'recording'

Step 3: Read the contents of the current file name.

You now want to press

dd:$r <C-r>"<BS>

The details are explained below. You should see something like this (before pressing backspace):

Notice the first line is gone.

The <Key> construct is Vim notation to specify different keys and key combinations. <C-r> means ‘Hold down control and press r‘, <BS> means backspace and <CR> means the enter/return key (Carriage Return). Let’s break this down:

dd – delete the current line.
: – start an Ex command.
$ – append at the end of the file.
r – read the following into this buffer. This must be followed by a space.
<C-r>" – paste contents of the given buffer. The " buffer contains the previously deleted line.
<BS> – I need to press backspace to remove the ^M (which means carriage return) from Windows line endings. YMMV.

And then finally execute the command with the enter key.

And it goes a little something like something like this.

Step 4: Prepare the next macro run.

Take note of the line number above the cursor, i.e. the line with the last file name. In this example, the number is 13. Now, press gg to return to the first line, then q to stop recording the macro. You may do a test run of the macro by pressing @q if you want to.

Step 5: Finishing the text.

Do you remember the number from the previous step? Good. Now press n@q, but substitute n with the number from step 4. In our example, I would press 13@q. This would run the q macro 13 times.

Note: If you did a test run, decrement the number by one (since you have run the macro once), and press @@ instead of @q. @@ will re-run the previous macro and is faster to type than @q.

No files left, only beautiful code.

Voila! The files are all handily read into your buffer, ready to be pasted into Wordle.

For completeness, here’s the generated result based on the example code base:

Words on a screen.

But I am special, so I do want to.

First, let us recap what ::operator new and ::operator delete really are. (The double colons simply mean that they are in the global namespace, and not in the std namespace. But you probably already knew that.) “Oh, that’s easy,” you might say.” When you say ‘new Foo()‘, you call ::operator new, and when you ‘delete foo’, you call ::operator delete, right?”  Wrong. Well, it is true that those operators are called, but they are just two pieces in the big picture. We need to separate between ‘the new expression‘ (sometimes called the new operator), and ‘operator new’.

And so each bit allocated by operator new is flipped to its correct state

Operator new is fairly simple, but comes in many forms. It is responsible for allocating memory, much like malloc(). It has two main forms: operator new and operator new[]. Each of these has three global overloads: The normal version, a nothrow-version and placement new. The latter two are simple: The nothrow variant should return a null pointer if allocation fails, rather than call any new_handlers or throw std::bad_alloc. Placement operator new just returns its pointer argument – it is basically a no-op used to trick the new-expression into calling the constructor for us. Apart from these six global variants, each class can overload its own operator new, thus allowing for an arbitrary number of different ‘operator new’s. The typical reason for overloading operator new is to allow for more efficient memory storage on a per-class basis.

The new-expression is special. There are only two of them: new and new[]. Their mission is to allocate dynamic memory for whatever they are creating and call all the correct constructors. This includes constructors for each object in the case of new[]. The new-expression will also have to call the constructors for base classes or contained classes. They can not be overloaded or replaced.

As usual, Newton’s third law of C++ applies to new and delete – for every new there is an equal and opposite delete. Most of the above is equal (but opposite) for operator delete and the delete-expression.

Normally, if you are not satisfied with ::operator new, then you overload it for your particular class or classes. But for me, the situation is different. I am developing embedded software, and the platform we work on needs to carefully place objects in memory. For C code, this means that we use a function called umalloc() rather than regular malloc(). For C++, we need to ensure that the new-expression gets its memory through umalloc(), which means replacing ::operator new.

Yes, replacing. Not overloading. The global ‘operator new’s and ‘operator delete’s are implicitly declared, and we can replace them simply by providing a new definition. But the behavior of ::operator new is not as straightforward as you might think. You can’t just write:

void* operator new(size_t n) {
    void* new_memory = malloc(n);
    if (new_memory == nullptr) {
        return new_memory;
    }

    throw std::bad_alloc();
}

As the accepted answer to this question on StackOverflow explains, there is more to it than that, and most of it boils down to new_handlers. I will spare you the boring details (you can read the answer for more information), and simply jump straight to the code I ended up with:

#include <new>
#include <stdexcept>

// Scalar regular new
void* operator new(std::size_t n) throw(std::bad_alloc)
{
    using namespace std;

    for (;;) {
        void* allocated_memory = ::operator new(n, nothrow);
        if (allocated_memory != 0) return allocated_memory;

        // Store the global new handler
        new_handler global_handler = set_new_handler(0);
        set_new_handler(global_handler);

        if (global_handler) {
            global_handler();
        } else {
            throw bad_alloc();
        }
    }
}

// Scalar nothrow new
void* operator new(std::size_t n, std::nothrow_t const&) throw()
{
    if (n == 0) n = 1;

    return malloc(n);
}

// Array regular new
void* operator new[](std::size_t n) throw(std::bad_alloc)
{
    return ::operator new(n);
}

// Array nothrow new
void* operator new[](std::size_t n, std::nothrow_t const&) throw()
{
    return ::operator new(n, std::nothrow);
}

// Scalar regular delete (doesn't throw either)
void operator delete(void* p) throw()
{
    free(p);
}

// Scalar nothrow delete
void operator delete(void* p, std::nothrow_t const&) throw()
{
    ::operator delete(p);
}

// Array regular delete
void operator delete[](void* p) throw()
{
    ::operator delete(p);
}

// Array nothrow delete
void operator delete[](void* p, std::nothrow_t const&) throw()
{
    ::operator delete(p);
}

The reason we have nothrow-versions of operator delete, even when regular delete never throws, is because of the law of equal and opposite news and deletes - when memory has been allocated with nothrow new, it will be deallocated with nothrow delete.

With the exception of any bugs it may contain (I have not found any, so there are probably many left), this should be the typical way to replace ::operator new and ::operator delete. But you almost never want to do that anyway.

Unless you are special.

The steps we have taken so far include:

• Using a more mobile-friendly theme when visiting the site from a mobile browser. (If you ever have any problems with the mobile browser detection, we would love to hear from you!)
• Removing header image from the mobile theme.
• Limiting the number of posts shown.
• Splitting long posts into multiple pages when viewed on a mobile device.

We hope you enjoy reading codebloat on a mobile device!