Time for another day of Advent of Code 2020.

For Day 5, we’re going to have to do…

So there’s an airline that uses binary space partitioning when referring to seats - there’s 128 rows and 8 columns. The first 7 characters are either F (Front, for the lower half) and B (back, for the upper half), and the last 3 are L (Left, for the lower half) or R (Right, for the upper half).

A while back, I asked on Twitter what people found confusing in Rust, and one of the top topics was “how the module system maps to files”.

I remember struggling with that a lot when I first started Rust, so I’ll try to explain it in a way that makes sense to me.

Important note

All that follows is written for Rust 2021 edition. I have no interest in learning (or teaching) the ins and outs of the previous version, especially because it was a lot more confusing to me.

Last week-end, I participated to Ludum Dare for the fourth time in a row!

Downloads: Linux (64) | OS/X | Windows

Story

So here is our entry: Legithief. The backstory is simple, yet cunning: you are an ordinary thief practicing ordinary acts of thievery in the houses of ordinary people to make a living. But one day.. you are quietly robbing yet another home, when you are suddenly smashed in the head with a bat.

In the last article, we found where code was hiding in our samples/hello executable, by disassembling the whole file and then looking for syscalls.

Later on, we learned how to inspect which memory ranges are mapped for a given PID (process identifier). We saw that memory areas weren’t all equal: they can be readable, writable, and/or executable.

A little while ago, I wrote an article on things that can go wrong when downloading, it listed a series of reasons, from network problems to invalid content to imperfect hardware that may occur when initially installing a game.

This article discusses what methods we can use to upgrade a game to a later version, when an older version has been successfully installed.

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.

In the previous article, We’ve built a nagaqueen-based tool that can parse one ooc file, detect class declarations and print its doc strings. Today, we’re making a bit of infrastructure for our app to support more sizable projects.

Source path and lib folders

Parsing a single file was a nice milestone, but it’s not nearly enough. We want to generate documentation for a whole project at a time: and since we’ll want to cross-link the various bits of documentation we generate, we’ll also need to parse the various dependencies (such as the ooc sdk, and any used library) so that we can resolve argument types and link them properly.

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 rawsock stdio

Our ping API is simple, but it’s also very limited:

pub fn ping(dest: ipv4::Addr) -> Result<(), String> // called as: ping(ipv4::Addr([8, 8, 8, 8])).unwrap();

It doesn’t allow specifying the TTL (time to live) of packets, it doesn’t allow specifying the timeout, it doesn’t let one specify the data to send along, and it doesn’t give us any kind of information on the reply.