Articles tagged #rust

The thumbnail for this page

Running an executable without exec

In part 1, we’ve looked at three executables:

  • sample, an assembly program that prints “hi there” using the write system call.
  • entry_point, a C program that prints the address of main using printf
  • The /bin/true executable, probably also a C program (because it’s part of GNU coreutils), and which just exits with code 0.

We noticed that when running entry_point through GDB, it always printed the same address. But when we ran it directly, it printed a different address on every run.

The thumbnail for this page

What's in a Linux executable?

Executables have been fascinating to me ever since I discovered, as a kid, that they were just files. If you renamed a .exe to something else, you could open it in notepad! And if you renamed something else to a .exe, you’d get a neat error dialog.

Clearly, something was different about these files. Seen from notepad, they were mostly gibberish, but there had to be order in that chaos. 12-year-old me knew that, although he didn’t quite know how or where to dig to make sense of it all.

The thumbnail for this page

Crafting ICMP-bearing IPv4 packets with the help of bitvec

So. Serializing IPv4 packets. Easy? Well, not exactly.

IPv4 was annoying to parse, because we had 3-bit integers, and 13-bit integers, and who knows what else. Serializing it is going to be exactly the same.

Right now, we don’t have a way to serialize that.

Let’s take the version and ihl fields, both of which are supposed to take 4 bits, together making a byte. We could serialize them like this:

The thumbnail for this page

Crafting ARP packets to find a remote host's MAC address

Alright. ALRIGHT. I know, we’re all excited, but let’s think about what we’re doing again.

So we’ve managed to look at real network traffic and parse it completely. We’ve also taken some ICMP packets, parsed them, and then serialized them right back and we got the exact same result.

So I know what you’re thinking - let’s just move our way down the stack again - stuff that ICMP packet in an IP packet, then in an Ethernet frame, and then serialize the whole thing.

The thumbnail for this page

Parsing and serializing ICMP packets with cookie-factory.

In the last part, we’ve finally parsed some IPv4 packets. We even found a way to filter only IPv4 packets that contain ICMP packets.

There’s one thing we haven’t done though, and that’s verify their checksum. Folks could be sending us invalid IPv4 packets and we’d be parsing them like a fool!

This series is getting quite long, so let’s jump right into it.

The thumbnail for this page

Parsing IPv4 packets, including numbers smaller than bytes

Hello and welcome to Part 11 of this series, wherein we finally use some of the code I prototyped way back when I was planning this series.

Where are we standing?

Let’s review the progress we’ve made in the first 10 parts: first, we’ve started thinking about what it takes for computers to communicate. Then, we’ve followed a rough outline of the various standards and protocols that have emerged since the 1970s.

The thumbnail for this page

Improving error handling - panics vs. proper errors

Before we move on to parsing more of our raw packets, I want to take some time to improve our error handling strategy.

Currently, the ersatz codebase contains a mix of Result<T, E>, and some methods that panic, like unwrap() and expect().

We also have a custom Error enum that lets us return rawsock errors, IO errors, or Win32 errors:

pub enum Error { Rawsock(rawsock::Error), IO(std::io::Error), Win32(u32), }

Rust 2020: Funding

Blog posts that praise Rust are many but funding is generally in short supply.

If even a small percentage of the money Rust saves companies was put back into the ecosystem it would help secure the future of the platform tremendously.

Multiple sources of funding

It is unreasonable going forward to expect the same handful of companies to provide all the funding.

Go back to the homepage.