Ben Kettle

Making Semgrep rip: how ripgrep inspired us to shave hours off scans

Wed, 10 Jun 2026 00:00:00 +0000

Photos from Darktable to my blog in one click

Tue, 17 Mar 2026 00:00:00 +0000

I fixed the graphics drivers on my laptop and Darktable—for the unaware, an extremely solid OSS photo editing software—went from essentially unusable to decently fast. After years of anticipation, I finally plugged my big hard drive into my little server and set up a network share (and backups!). I consolidated all my various photo libraries that were previously strewn across four portable HDDs and SSDs in various degrees of duplication into a single library on said big hard drive. And I even bought a new camera that online hype claimed would make it so I didn’t have to edit pictures anymore (then I felt bad about how much it cost, so returned it and bought a different one that was half the price and fit my needs much better).

These all helped me get out of my several-year drought where I occasionally decided to drag my camera around and took some photos, but rarely actually looked at the results. I’ve come to quite like Darktable now that it’s usable on my laptop, especially after spending some time learning about tone mapping and color theory and following a few tutorials. I’ve been carrying my new small camera around way more often and taking photos more frequently, but also more intentionally, as a result. I’ve produced some photos that I’m pretty happy with in the last couple months. I’ve wanted to post these photos on my website, but that so far has meant:

Exporting the photo from Darktable into a folder somewhere
Making a new folder in my website’s content/photos directory
Copying the exported image file into that folder
Copying an index.md from a previous photo post into the folder
Updating the date and caption for the new photo and copying the filename into the featured_image field
Commit and push with git to trigger the auto-build-and-deploy that happens on each push.

This is tedious enough that I so far have rarely posted photos to my website.

Luckily, though, Darktable provides a nice solution. Darktable exposes an API to Lua and allows integrating Lua scripts into the UI and, especially important for my purposes, it allows defining custom export destinations with these Lua scripts. So I set up a simple automation that combines a bash script in my website’s directory with a simple Lua exporter.

The bash script takes a single JPEG filename and produces a Hugo post from it (I use Just for this repo, but this could also just be a bash script). It reads the date and caption from the image EXIF data, but sets pubDate to the current date since I often edit old photos and still want these to show up when I publish them.

# Create a photo post from an image file, reading EXIF data for the date and description.
# Usage: just photo-from-file /path/to/photo.jpg
photo-from-file filepath:
    #!/usr/bin/env bash
    set -euo pipefail

    filepath=$(cd "{{invocation_directory()}}" && realpath "{{filepath}}")
    filename=$(basename "$filepath")

    # Get datetime from EXIF
    exif_datetime=$(exiftool -s3 -d "%Y-%m-%dT%H:%M:%S" -DateTimeOriginal "$filepath" 2>/dev/null || true)
    if [ -z "$exif_datetime" ]; then
        exif_datetime=$(exiftool -s3 -d "%Y-%m-%dT%H:%M:%S" -CreateDate "$filepath" 2>/dev/null || true)
    fi
    if [ -z "$exif_datetime" ]; then
        echo "Error: could not read date from EXIF data" >&2
        exit 1
    fi

    offset=$(exiftool -s3 -OffsetTimeOriginal "$filepath" 2>/dev/null | tr -d '[:space:]' || true)
    if [ -z "$offset" ]; then
        offset="+00:00"
    fi
    date_str="${exif_datetime}${offset}"

    publish_date_str=$(date --iso-8601=seconds)

    # Use EXIF ImageDescription as title/caption
    description=$(exiftool -s3 -ImageDescription "$filepath" 2>/dev/null | sed 's/^[[:space:]]*//;s/[[:space:]]*$//' || true)
    if [ -z "$description" ]; then
        echo "Error: no ImageDescription found in EXIF data" >&2
        exit 1
    fi

    # Derive slug from description: lowercase, replace spaces/special chars with hyphens
    slug=$(echo "$description" | tr '[:upper:]' '[:lower:]' | sed -E 's/[^a-z0-9]+/-/g; s/^-+|-+$//g')

    site_dir="{{justfile_directory()}}"
    post_dir="$site_dir/content/photos/$slug"
    mkdir -p "$post_dir/images"

    # Write index.md
    {
        echo '+++'
        echo "title=\"$description\""
        echo "publishDate=\"$publish_date_str\""
        echo "date=\"$date_str\""
        echo "draft=false"
        echo "caption=\"$description\""
        echo "featured_image='images/$filename'"
        echo '+++'
    } > "$post_dir/index.md"

    cp "$filepath" "$post_dir/images/$filename"

    echo "Created $post_dir/index.md"

And then, in Darktable, all we do is call this script to create the post and run the git commands to commit and push.

darktable = require "darktable"

local SITE_DIR = "/home/ben/dev/personal-website"
local JUSTFILE = SITE_DIR .. "/justfile"

local function export_image(storage, image, format, filename, number, total, high_quality, extra_data)
    -- filename is the absolute temp export path darktable wrote the image to.
    local cmd = string.format(
        "just -f %q photo-from-file %q 2>&1",
        JUSTFILE, filename
    )

    local base = filename:match("([^/]+)$")
    darktable.print("Creating photo post for " .. base .. "...")

    local result = darktable.control.execute(cmd)

    if result ~= 0 then
        darktable.print_error("photo-from-file failed for " .. base .. " (exit code " .. result .. ")")
        darktable.print("ERROR: photo-from-file failed for " .. base .. " — check the darktable log")
    else
        darktable.print("Photo post created for " .. base)
    end
end

local function finalize(storage, image_table, extra_data)
    local first_image, first_filename = next(image_table)
    local first_image_description = first_image.description
    local cmd = string.format(
        "cd %q && git add . && git commit -m 'export darktable image %q' && git push",
        SITE_DIR, first_image_description
    )
    local result = darktable.control.execute(cmd)
    darktable.print("Committed. Open " .. SITE_DIR .. "/content/photos/ to review posts.")
end

darktable.register_storage("website_export","Export to benkettle.xyz", export_image, finalize)

The full workflow looks like this now:

Do my regular photo editing process and end up with a photo that I like (hopefully)
Add a “description” to the photo in Darktable’s UI
Export the photo using my custom exporter And with that, my photo is published! No filesystem manipulation or even command-line usage necessary.

Finding Fibonacci in the NYT Pips

Sun, 11 Jan 2026 00:00:00 +0000

When I was home over the holidays, one of my good high school friends got me hooked on the NYT Pips game. If you’re not familiar, it’s a puzzle game where you arrange a provided set of dominoes onto a board so that their values satisfy some constraints like “these 3 spots add to 5” or “these spots are all equal”.

While we were downhill skiing over the break, said friend and I got to discussing how you might write a solver for Pips. I thought that SMT solvers like Z3 might be a good fit, and indeed we found a couple of blog posts (one, two) solving the game that way. But we were curious about how we might write one ourselves. In particular, we wanted to know how big the solution space really was: could we just brute-force it, or were there too many possible solutions for a computer to handle?

Thinking about the number of solutions

The number of possible solutions breaks down—the way we thought about it—into two main components:

The number of geometric arrangements of dominoes onto the board. To be valid, an assignment must fill the entire board.
For each of those arrangements, the number of ways that the dominoes can be assigned to each space.

The second component seemed easy enough to reason about: a geometric arrangement of dominoes gives $d$ spaces to each be filled by one of the $d$ given dominoes in one of two ways (either not-flipped or flipped, ignoring doubles). There are $d!$ permutations of dominoes into the $d$ spaces, and each domino in each permutation can be either flipped or not flipped, for a total of:

$$ \text{solutions per arrangement} = d! \cdot 2^{d} $$

But figuring out the number of possible geometric arrangements was too hard for us to figure out on the chairlift (even after several runs): the simple cases were easy enough but as the grid got bigger it was hard to see any pattern. So I decided I’d just write some code to figure it out for the most common cases first.

Calculating geometric arrangements

Since we were just interested in approximating the number of solutions, I thought it’d be good to first think about just rectangular boards. Though the boards for Pips are rarely rectangles, the rectangular case should be a good place to start. And on the day that I decided to do this, the hard puzzle was just a $6 \times 5$ rectangle.

To get going, I wrote some quick code to model a board, pieces on a board, and conflicts between pieces. Then I wrote a basic recursive backtracking algorithm to enumerate all possible assignments, and got the following results for $m \times n$ boards:

	1	2	3	4	5	6	7	8
1	0	1	0	1	0	1	0	1
2	1	2	3	5	8	13	21	34
3	0	3	0	11	0	41	0	153
4	1	5	11	36	95	281	781	2245
5	0	8	0	95	0	1183	0	14824
6	1	13	41	281	1183	6728	31529	167089
7	0	21	0	781	0	31529	0	1292697
8	1	34	153	2245	14824	167089	1292697	12988816

I sent this to my friend, and he pointed out that the $2 \times n$ case looks an awful lot like the Fibonacci sequence! Of course, I learned from Grant Sanderson that patterns fool ya, so I had my program compute some more $2 \times n$ arrangements:

$$\begin{array}{r|rrrrrrrrrrrrrrrrr} n & 1 & 2 & 3 & 4 & 5 & 6 & 7 & 8 & 9 & 10 & 11 & 12 & 13 & 14 & 15 & 16 & 17 & \cdots \\ \hline & 1 & 2 & 3 & 5 & 8 & 13 & 21 & 34 & 55 & 89 & 144 & 233 & 377 & 610 & 987 & 1597 & 2584 & \cdots \\ \end{array}$$

I went up to $2 \times 36$ ($24157817$) before my computer started to really slow down, and it kept following Fibonacci.

Why Fibonacci?

At first, it seemed pretty crazy that Fibonacci would show up inside the NYT Pips. But the $2 \times n$ case is pretty simple, and the fact that the number of total arrangements for each $n$ looks like Fibonacci gives us a hint about a good way to think about the relation. Fibonacci is defined as:

$$F(n) = F(n-1) + F(n-2)$$

so let’s think about the $n - 1$ and $n - 2$ cases of a $2 \times n$ Pips board and how they each contribute to the total number of arrangements that fill a $2 \times n$ board.

Claim 1: There is exactly one way to turn a valid $2 \times (n -1)$ arrangement into a valid $2 \times n$ arrangement.

Drawing it out, it looks like for any arrangement that fills a $2 \times (n - 1)$ Pips board, we can simply add one vertical domino at the end to fill a $2 \times n$ Pips board. And indeed this is the only way to fill a $2 \times n$ Pips board given an arrangement that fills a $2 \times (n - 1)$ Pips board.

Claim 2: There is exactly one way to turn a valid $2 \times (n -2)$ arrangement into a valid $2 \times n$ arrangement that is distinct from any valid $2 \times (n - 1)$-derived arrangement.

If we think about a $2 \times (n - 2)$ Pips board, there are two ways to fill it out: we need two dominoes to fill the four empty squares, but those two dominoes can be either vertical or horizontal.

However, we are interested in counting the number of unique geometric arrangements of dominoes to fill a $2 \times n$ board. With the final dominoes in the $n-2$ case vertical, we’ve created a duplicate with the arrangements covered by the $n-1$ case: since removing the right of the two new dominoes would give a valid arrangement for a $2 \times (n -1)$ board and we already consider adding a vertical domino to every valid $n-1$ arrangement, all of those arrangements must already be covered by the $n - 1$ cases. So the only contributors to unique geometric arrangements for the $2 \times (n - 2)$ case are those with two horizontal dominoes filling the extra space.

This is sounding like Fibonacci, but one might finally wonder if we need to also consider any smaller instances of the recurrence. For example, is it possible to create any new arrangements that are derived from an arrangement that fills a $2 \times (n - 3)$ board? I claim that it is not and indeed that it is not possible for any small instance:

Claim 3: All valid $2 \times n$ arrangements must be an extension of either a valid $2 \times (n - 1)$ or a valid $2 \times (n - 2)$ arrangement.

Taking the example of $2 \times (n - 3)$ from above, filling the empty space to the right of the $2 \times (n-3)$ arrangement requires that each space is filled by a portion of either a horizontal domino or a vertical domino. Since all dominoes have dimension $1 \times 2$, it is necessary to complete either a valid $2 \times (n -1)$ or $2 \times (n -2)$ arrangement in order to complete a valid $2 \times n$ arrangement, and therefore any valid arrangement derived from a $2 \times (n -3)$ arrangement would also be included in the arrangements considered above. This applies in the same way to any smaller instance of the recurrence, so it is sufficient to count all possible arrangements to consider only the $n-1$ and $n-2$ cases.

Combining these three claims, since there is exactly one way to turn a valid $2 \times (n-1)$ arrangement into a valid $2 \times n$ arrangement and exactly one way to turn a valid $2 \times (n-2)$ arrangement into a valid $2 \times n$ arrangement, and because all valid $2 \times n$ arrangements must also be a rightward extension of either a $2 \times (n-1)$ or a $2 \times (n-2)$ arrangement, we can say that the number of possible arrangements of dominoes to fill a $2 \times n$ Pips board is equal to the sum of the number of possible arrangements to fill a $2 \times (n-1)$ board and to fill a $2 \times (n-2)$ board. If we call $F(n)$ the number of possible arrangements to fill a $2 \times n$ board, then, and set base cases of $F(1) = 1$ and $F(2) = 2$ for the $2\times 1$ and $2 \times 2$ cases, this gives:

$$ F(n) = F(n - 1) + F(n - 2)$$

Just like Fibonacci.

Nothing new

Of course, my friend and I did not discover a new field of math by playing Pips. Some Googling suggested that this problem is called Domino Tiling, and the general $m \times n$ case was solved by Temperley & Fisher and by Kasteleyn in 1961 in the context of statistical mechanics and physics, respectively, as:

$$ \prod^{\lceil\frac{m}{2}\rceil}_{j=1}\prod^{\lceil\frac{n}{2}\rceil}_{k=1} \left( 4\cos^2 \frac{\pi j}{m + 1} + 4 \cos^2 \frac{\pi k}{n + 1}\right)$$

But it was a lot more fun to play around with it myself and be surprised by the Fibonacci than to read it on Wikipedia :)

So, can we brute-force it?

Fibonacci aside, the original question we set out to answer was whether the solution space of a regular Pips game was small enough for a computer to brute-force. We discovered above that the number of geometric arrangements for a standard-sized “hard” board, such as the $6 \times 5$ one from Jan. 11, contributes only a factor of a few thousand geometric arrangements ($1183 \approx 2^{10}$ in the $6 \times 5$ case). The number of dominoes $d$ and the way that they can be assigned within a geometric arrangement contributes a much larger factor: $d! \cdot 2^d$ or, for $d = 15$, $4.28 \times 10^{19} \approx 2^{55}$.

$2^{55}$ is already outside the range of brute-forcing effectively—at even a wildly unrealistic checking rate of 1 solution per CPU cycle, a 5GHz CPU ($\approx 2^{32}$ cycles/sec) it would take about $2^{23}$ seconds, or 97 days, to check every possible solution for a single geometric arrangement. Adding in the factor of $2^{10}$ for the number of geometric arrangements bumps us up to $2^{32}$ seconds, or 272 years. I think we need something smarter.

Autogenerating a Book Series From Three Years of iMessages

Thu, 08 Feb 2024 00:00:00 +0000

I am frequently annoyed at the things that I can’t remember. And when I’m trying to remember the details of something, I often turn to my text messages—thanks to big improvements recently, it is now quite fast to search my whole iMessage history on my phone, provided that I can remember some verbatim part of the message I’m looking for. And often, once I’m in the past, I want to look around: text messages from ages ago provide surprisingly interesting insights into the past.

But iMessage isn’t set up well for this casual browsing: when you try to scroll away from a search result, the loading is very slow. And the interface provides no way to jump to a specific date. I’d really like to be able to “flip through” my messages and stop at a random place for a view into that moment in time. Apple doesn’t provide a way to do that, so, I thought, why not enable it myself? I though it’d be great to enable this “flipping through messages” in the most literal way possible: by creating a physical book of my biggest conversation.

Is it possible?

In order to do anything at all with the messages, I needed to get them out of my phone and onto my computer. I’d looked many times for a way to do this with Signal, so wasn’t sure what I’d find, but was pleased that it seemed relatively straightforward to pull messages off an iPhone (even easier if your messages are already on a Mac). According to the very helpful iPhone wiki, all I had to do was grab sms.db from a backup of my phone, and I’d have a SQLite database that I could do whatever I liked with.

Querying my texts with SQL

This simplicity seemed a bit too good to be true—for some reason I expected some proprietary format that would be a pain to reverse-engineer. So I had to see it for myself. I took a standard backup on my Mac in finder (that was a trip—the “plugged-in iPhone” UI has barely changed since I used iTunes to sync music to my iPod touch in seventh grade). While the backup format is really not complicated, it was intimidating browsing the backup folder at first because an ls in the root directory yields a bunch of directories named after a single hex byte:

/.../00008120-001854410CEB401E >>> ls
00  0e	1c  2a	38  46	54  62	70  7e	8c  9a	a8  b6	c4  d2	e0  ee	fc
01  0f	1d  2b	39  47	55  63	71  7f	8d  9b	a9  b7	c5  d3	e1  ef	fd
02  10	1e  2c	3a  48	56  64	72  80	8e  9c	aa  b8	c6  d4	e2  f0	fe
03  11	1f  2d	3b  49	57  65	73  81	8f  9d	ab  b9	c7  d5	e3  f1	ff
04  12	20  2e	3c  4a	58  66	74  82	90  9e	ac  ba	c8  d6	e4  f2	Info.plist
05  13	21  2f	3d  4b	59  67	75  83	91  9f	ad  bb	c9  d7	e5  f3	Manifest.db
06  14	22  30	3e  4c	5a  68	76  84	92  a0	ae  bc	ca  d8	e6  f4	Manifest.db-shm
07  15	23  31	3f  4d	5b  69	77  85	93  a1	af  bd	cb  d9	e7  f5	Manifest.db-wal
08  16	24  32	40  4e	5c  6a	78  86	94  a2	b0  be	cc  da	e8  f6	Manifest.plist
09  17	25  33	41  4f	5d  6b	79  87	95  a3	b1  bf	cd  db	e9  f7	Status.plist
0a  18	26  34	42  50	5e  6c	7a  88	96  a4	b2  c0	ce  dc	ea  f8
0b  19	27  35	43  51	5f  6d	7b  89	97  a5	b3  c1	cf  dd	eb  f9
0c  1a	28  36	44  52	60  6e	7c  8a	98  a6	b4  c2	d0  de	ec  fa
0d  1b	29  37	45  53	61  6f	7d  8b	99  a7	b5  c3	d1  df	ed  fb

Entering one of these directories yields a bunch of files starting with the hex byte after which the directory was named:

/.../00008120-001854410CEB401E >>> cd 3d
/.../00008120-001854410CEB401E/3d >>> ls
3d0292d3fe90e1e22c247403c0e9105ea0f9ff44      3d8830b71e98aae80b6eaf8bdd5500d79ce74946
3d02fe309afa7de839822d6f1b8433aa90090d17      3d88cdc16ff2b5231e5ea4b52271ee195a6f4b96
3d072c4fca5db4a5678fa10b137435f757e98492      3d8a425d70f4049417e855d273c44d8199de30c9
3d0739c90579fa907246d5c21bd8d8ebaa2d9d6b      3d8a43a1921f504bb4393250f75b24bfc2c5cedb
3d0798b3cc4d2f5ad347ffb8bc5a0f9d8c82cfb9      3d8a7c0460aadabf1b7fc9adea9e6a2a6e7bc73b
3d07a0adc5c5c22dc525ccd3a93fb05a50ef1ac5      3d8b6ad12c7617b3d783790a457b0aa19b193b68
3d0880f091c51ddc145e17c78d8e6f9a3e7e20c8      3d8b82abe05a9d697102d8b665c9d499e07492ea
3d093e92cf03abf3650411e09a647630a1e0c478      3d8ba897240ad32580bf8dfd00db8f181658cdfd
3d095e908ff898be3b3ffd64a75db959a58ac70a      3d8bc227d67ec4944df8e75291102367034d7214
3d09d5dcd5a9bdad67a80cd83201a9e1fb75aada      3d8c722f1d92f7cd6f90c936c14f60f51aad128b
3d0abb83123be82abf43ce20118e72fea06023c5      3d8ca6eeabeb1c01fae05bb20f08dedf734cfd04
3d0b246304c42d2ab1eb1892d629fcdfde689cb7      3d8d0c6b1bf7946c6bef91d60cccb32207b7bc01
3d0bb5f49e6f0e31348ef8feb9a38d4ce71f5ec7      3d8fd2fbcaf3079a683a8e486ecde8875f0a591d
3d0c1283936c45fec533a507b78558b5aa3159fa      3d8ff93bd94b3ea14edc77d1e677cf4ee4306e4e
3d0cb8e28462780bb9af1440e297ecd8224c70ff      3d90ea8bfbf62feda080cd0ccbd12fa5c8673993
3d0ce10de5f69606c52882215b99ebab259dc194      3d932638fe8ed669725b7a143c6a8b02b8959923
3d0d7e5fb2ce288813306e4d4636395e047a3d28      3d93c92679aa9d398331e27fdeed64b5094e68d1
...

Looking at these with a nice file explorer that looks at magic bytes to determine filetypes (I use Thunar) helps make some sense of it, since it can show that these cryptic names really are just regular old images and other files. But really even that is unnecessary since the iPhone Wiki told us that the filename for the sms.db file that we’re looking for is 3d0d7e5fb2ce288813306e4d4636395e047a3d28. Copying this to my home directory:

$ cp 3d0d7e5fb2ce288813306e4d4636395e047a3d28 ~/imessage.db

And opening it up with the sqlite3 CLI we can actually see some tables!

~ >>> sqlite3 imessages.db
SQLite version 3.44.2 2023-11-24 11:41:44
Enter ".help" for usage hints.
sqlite> .tables
_SqliteDatabaseProperties              message
attachment                             message_attachment_join
chat                                   message_processing_task
chat_handle_join                       recoverable_message_part
chat_message_join                      sync_deleted_attachments
chat_recoverable_message_join          sync_deleted_chats
deleted_messages                       sync_deleted_messages
handle                                 unsynced_removed_recoverable_messages
kvtable
sqlite>

The schema requires a couple of joins to extract an actual conversation, but without too much trouble we can start to pull out messages (in this case from CVS spamming me):

sqlite> select
        message.ROWID, message.date, message.text, message.is_from_me from message
        inner join chat_message_join on message_id=message.ROWID
        inner join chat on chat.ROWID=chat_message_join.chat_id
        where chat.chat_identifier='28732'
        order by date asc;
278125|694030292385607040||0
278327|694647875648848000||0

...

314056|726702453329793024||0
314412|727316171079934976|CVS ExtraCare: 20% off one full-price item, just because. Tap the link to send to card: c.cvs.com/B0kjBMbNM|0

We got one, but a lot of blank ones too—many of the messages are missing! It turns out that for some messages, message data is stored in an encoded NSMutableAttributedString binary blob in the message.attributedData column instead of in message.text. With a bit of wrangling to get the binary data out of the SQLite CLI, we can look at one of these missing messages and see that the data is indeed there:

~ >>> sqlite3 imessages.db "select hex(attributedBody) from message where ROWID=278125;"   \
| cut -d\' -f2   \
| xxd -r -p      \
| xxd -g1
00000000: 04 0b 73 74 72 65 61 6d 74 79 70 65 64 81 e8 03  ..streamtyped...
00000010: 84 01 40 84 84 84 19 4e 53 4d 75 74 61 62 6c 65  ..@....NSMutable
00000020: 41 74 74 72 69 62 75 74 65 64 53 74 72 69 6e 67  AttributedString
00000030: 00 84 84 12 4e 53 41 74 74 72 69 62 75 74 65 64  ....NSAttributed
00000040: 53 74 72 69 6e 67 00 84 84 08 4e 53 4f 62 6a 65  String....NSObje
00000050: 63 74 00 85 92 84 84 84 0f 4e 53 4d 75 74 61 62  ct.......NSMutab
00000060: 6c 65 53 74 72 69 6e 67 01 84 84 08 4e 53 53 74  leString....NSSt
00000070: 72 69 6e 67 01 95 84 01 2b 81 f3 00 43 56 53 20  ring....+...CVS
00000080: 45 78 74 72 61 43 61 72 65 3a 20 24 32 20 6f 66  ExtraCare: $2 of
00000090: 66 20 79 6f 75 72 20 70 75 72 63 68 61 73 65 2c  f your purchase,
000000a0: 20 6a 75 73 74 20 66 6f 72 20 79 6f 75 21 20 49   just for you! I
000000b0: 6e 20 73 74 6f 72 65 20 6f 72 20 6f 6e 6c 69 6e  n store or onlin
000000c0: 65 2e 20 54 61 70 20 74 68 65 20 6c 69 6e 6b 20  e. Tap the link
000000d0: 74 6f 20 73 65 6e 64 20 64 65 61 6c 20 74 6f 20  to send deal to
000000e0: 63 61 72 64 3a 20 63 2e 63 76 73 2e 63 6f 6d 2f  card: c.cvs.com/

Luckily, we don’t need to implement the parsing for this binary format ourselves. There’s a great imessage-database crate that does exactly this: ingests an iMessage database and outputs the data in nice Rust data structures. Out of the box, it comes with a binary (imessage-exporter) to generate text or HTML versions of your conversations—so really quite similar to my goal.

With just a couple of tweaks to the SQL statement the library uses to fetch messages, I’m able to narrow down the query to just a single conversation. But for this project I want to make a nicely formatted physical book that I can hold in my hand and flip through—the HTML and text formats that the project ships with won’t quite work for this.

Generating LaTeX

I am a huge fan of LaTeX due to the beautiful documents it can be convinced to produce, and since leaving school have been itching to generate some more pretty PDFs. And since LaTeX’s text-based source code makes it perfect for templating and autogeneration, it seems like a great choice. I’ll my book by spitting out LaTeX code for every text message in the conversation.

Thanks to the imessage-database library it’s pretty easy to iterate through all the messages in the conversation, so I start by generating LaTeX code for each message. My first approach at this LaTeX generation is quite simple: align left if the message is from me and right otherwise, insert some text indicating an attachment where images are sent, and skip things like reactions and replies that I don’t want to bother rendering. This initial approach works well, and after splitting the text up into chapters based on date and bit of visual tweaking, I’m satisfied.

But there’s one major problem: LaTeX doesn’t support unicode. Of course, this means that as soon as I extend the rendering window enough to include an emoji, the LaTeX compiler explodes. Simply stripping out emojis from the source text works, but is hardly a tolerable solution—after all, emojis are integral to modern communication.

After a bit of research, it looks like XeLaTeX is the key: it adds support for unicode fonts to LaTeX. Switching to XeLaTeX proves quite straightforward, and by defining a \emojifont to an emoji font and wrapping every emoji in {\emojifont X} in my generated LaTeX source, the output renders successfully with emojis inline. But I don’t want to pay for every page of my book to be printed in color when I print it. Luckily, Google’s Noto Emoji font has a great set of simple black-and-white emojis that are perfect for this purpose. I’m quite happy with the way these emojis look in print:

After a couple extra niceties like a header that tracks the current date (with a LaTeX command that sets \markright with every message), I’m ready to put it all together.

When I finally compile all three years of messages that I want to be able to flip through, I’m surprised to find that the compiler dumps out well over a thousand pages of messages when I put them into a standard 6" x 9" page size. Since it’s exactly three years of messages anyway, though, there’s an easy solution: I split the opus into three volumes to get the size of each one down to something printable.

Ordering

When I decided to try to do this, I really wanted to end up with a physical book in my hand. So I had to figure out how to get these books printed. And to my surprise, printing a paperback book is quite cheap. After reviewing a bunch of options, Barnes and Noble Press seems like the best option. It’s decently more expensive than some of the other options like Lulu and Amazon KDP, but most options are targeted at people that are trying to sell their books. B&N Press is too, but their story for personal books seems better than the others as you don’t need to “publish” your book to get it printed. And the price is still quite reasonable: I was able to print all three volumes, around 1300 pages total, for $30 including shipping.

Before I can order books from my LaTeX-generated PDFs, the website tells me that the last step is to create covers. Upon uploading the body pages to B&N Press, the sites generates the dimensions required for the cover. Given these, I threw together a cover for each of the three volumes in Inkscape, which the website accepted without complaint.

The B&N press website is not perfect: it generally is very slow, and while trying to place my order the checkout page was broken and wouldn’t show up for over 24 hours. But after that was fixed, ordering worked.

And sure enough, after a couple weeks’ wait, I had three actual books in hand. I flip through them regularly, and it is so much easier to revisit old conversations this way than trying to do so on my phone.

Create your own

The source code is in rough shape, and I haven’t packaged it as a cargo binary, but there’s not much of it. If you want to take a look or try for yourself, it’s available at https://github.com/bkettle/message-book.

Building a Safer FIDO2 Key with Privilege Separation and WebAssembly

Tue, 11 Jul 2023 15:33:43 -0500

FIDO2 is growing as a solution to the password hell we all know too well by replacing passwords stored in brains with secret keys stored on dedicated hardware security keys. This new protocol brings a huge increase in security and in usability, but the security key poses an attractive new target for attackers. For my Master’s thesis, I implemented a safer FIDO2 security key that I call Plat. Plat is a new implementation of a FIDO2 security key that retrofits privilege separation onto an existing codebase in order to prevent possible bugs from compromising the security of the key. Plat uses a new WebAssembly-based toolchain to create isolation domains on our embedded ARM platform while minimizing the need to write new code. In addition to isolating software-only libraries, Plat’s toolchain enables privilege separation of drivers by controlling access to individual hardware peripherals.

This post talks about the work completed in my Master’s thesis. For more details, you may want to look at the thesis itself.

Context

While passwords are in widespread usage due to their convenience and implementation simplicity, they have a long history of security issues, from weak passwords and common password reuse to phishing vulnerability and server database leaks. FIDO2’s WebAuthn standard, which was formed by a group of tech companies like Google and Apple and is quickly gaining momentum as an authentication standard, aims to solve many of these issues by replacing passwords with an automated public-key signature exchange. In doing so, FIDO2 removes the need for users to manually remember and enter passwords, and thus eliminates many of passwords’ inherent security risks, by reducing the security of web-based authentication to the security of a user’s private key. There have been previous attempts to replace passwords, but FIDO2 seems to be the one that’s gaining steam: Apple has added authenticators to their devices and Google recently enabled WebAuthn as a password replacement for Google accounts.

Though companies like Apple are embedding authenticators into their devices, authentication via WebAuthn and its U2F predecessor today is often done via physical security keys like the YubiKey. In addition to a familiar lock-and-key mental model, these physical security keys can provide strong security: since these devices focus on a single task, their codebase can be much smaller than the millions of lines that comprise a modern PC’s operating system, drivers, and applications, and therefore can have far fewer bugs and vulnerabilities. However, security keys and similar devices like hardware cryptocurrency wallets have still had many bugs. Careful review can remove many of these bugs, as can replacing the C used in their source code with a memory-safe language like Rust. But ultimately it is very difficult to find and fix every bug in a system, leaving the door open to vulnerabilities. Since authenticators have such high-value contents, they are a likely attack target, and an exploit of a bug in an authenticator can compromise the account security that users rely on these authenticators to provide.

For my recently-completed Master’s thesis, I designed and implemented a security key that I call Plat. Plat implements the same functionality as existing security key, but uses privilege separation to limit the damage that many types of bugs can cause. Plat adds this privilege separation to the open-source SoloKey codebase, using the same basic hardware components (seen below on the breadboard I used to prototype) and minimizing new code to be written.

Threat Model & Security Goals

The security of the FIDO2 protocol relies fundamentally on the security of each user’s secret keys. If an attacker learns a user’s secret key, they can forge the cryptographic signatures at the protocol’s core and pretend to be the user. In order for the FIDO2 protocol to be usable, the risk of secret key compromise must be low.

Unfortunately, given the huge scale of modern PC software, computer compromises are relatively common. If secret keys were simply stored in a regular program on the user’s machine, a simple piece of malware would allow an attacker permananent access to all of a user’s accounts.

Implementing the authenticator as a standalone device like a YubiKey offers some protection against a compromised host PC: while an attacker who compromises a user’s PC would be able to trivially read secret keys from an authenticator implemented as an application, a hardware authenticator that is attached via a USB port can still enforce its own restrictions even when the host PC is compromised. These security keys are typically designed to allow the connected host PC to send signature requests to the key and, perhaps after a required button press by a human, receive a signature in response. If the security key works as intended, the security key should never reveal the secret key to the host computer.

But an attacker who compromises a host PC still gets significant power to interact with a connected authenticator by sending arbitrary messages over USB to the authenticator. If the authenticator includes bugs that are exploitable via USB, an attacker could circumvent the protections that hardware security keys aim to provide and get unrestricted access to a user’s accounts.

Even if a user’s PC is compromised and the authenticator code includes bugs, Plat aims to ensure that these bugs cannot cause total long-lasting account compromise. Specifically, we aim to ensure that the secret key is not revealed and that each signature performed has the explicit approval of the user.

Plat’s Approach: Privilege Separation

Plat uses privilege separation to limit the damage caused by many classes of bugs and achieve these goals. Used in security-critical software like browsers, privilege separation is a powerful technique that involves splitting a system into several components and placing restrictions on each component that give it permission to perform only actions that are strictly necessary for its function. For effective privilege separation, each component must be placed in a sandbox that limits its interaction with other components and with the host environment that coordinates all of the components. Except as explicitly allowed by the host environment’s configuration, these sandboxed components should not be able to affect the execution of anything outside of their sandbox: a component should not be able to access memory not owned by that component, and a component should not be able to jump to code that is not part of that same component. We call these sandboxed components modules.

The choice of the boundaries of these modules defines the security of a privilege-separated system. With all code in a single module, privilege separation gives no benefits—code within a module is not protected from other code within that same module. But with too-small modules, it may be necessary for a module to expose a wide API, increasing its vulnerability exposure and increasing overall complexity. To be effective, modules must be chosen to encapsulate a given functionality with a narrow API, to meaningfully separate components based on the privileges they require, and to separate bug-prone code from the code we aim to protect.

We expected most bugs to reside in the most complex pieces of the codebase. First, the USB stack seemed like a likely source of bugs: drivers historically have been responsible for many bugs, including a majority of bugs in the Linux kernel, and USB has been a source of bugs on embedded devices in the past. Parsers are also notoriously bug-prone, and we anticipated that the FIDO2 processing logic, which includes a CBOR parsing library, may be another source of bugs. As seen above, Plat places each of these bug-prone components into their own module, restricting their access to hardware resources and to sensitive cryptography state. This way, even if the USB stack or the CBOR parser has a bug that allows an attacker to gain control of that module, the attacker still will not be able to read out the secret key since the privilege separation system does not provide this modules with any way to do so.

Isolating Modules with WebAssembly

We decided to implement the isolation that we needed using WebAssembly. While WebAssembly, as the name implies, was designed to run in the browser, its isolation guaratees are useful far beyond the web. In order to support the execution of code shipped from an untrusted web server, Wasm is built around the concept of sandboxed modules. The language ensures that WebAssembly code cannot affect the host environment except through a clearly defined API. And unlike other sandboxing and isolation solutions, WebAssembly does not rely on an operating system to provide a process abstraction or on fancy processors to provide page table hardware—neither of which were an option for Plat.

WebAssembly provides the isolation and OS-independence that we need for privilege separation out of the box. Somewhat less straightforward was building a system to build and run multiple WebAssembly modules to run together on the ARM microprocessor that Plat is based on.

Runtimes and compilers like wasm3 and aWsm support ARM processors like the one we use for Plat, but require including an interpreter in the case of aWsm or working with generated binaries in the case of aWsm. Instead, we use a toolchain similar to the one used in Firefox to sandbox untrusted libraries using wasm2c and to add the features we need.

As seen above, Plat’s toolchain compiles C code into several WebAssembly modules before translating them back into more C code with added safety checks to preserve Wasm’s isolation guarantees. Unlike WebAssembly, C itself does not include any safety checks or make any isolation guarantees. To preserve isolation between modules, we trust wasm2c to insert the necessary checks into the generated C code. A nice benefit of this C-based toolchain is that it makes linking to and between our modules very simple. For each function that a module imports or exports, wasm2c generates function declarations that the host environment can then import as normal C functions—no manual ABI translation required. It also makes our compilation and linking process simple: once we have the C code that wasm2c generates, the final binary generation is exactly the same as if we were compiling any monolithic C application.

This toolchain allows us to create sandboxed modules from existing C code that each have their own memory space and a statically defined set of jump targets, ensuring that each module’s code escape its sandbox. Further, modules are able to import and export functions to interact with each other and with functions defined in the host environment. But the toolchain does not itself provide the safe access to peripheral MMIO that we require for the USB driver or the safe access to cryptography that the FIDO2 module needs.

Making It All Work

The set of constructs provided by WebAssembly means that it does not rely on hardware support and thus makes it a compelling mechanism to implement privilege separation in Plat. But, like any isolation strategy, it comes with some challenges. Implementing Plat involved designing several new constructs to enable passing of large arguments across module boundaries, to allow sandboxing the USB driver that requires access to peripheral memory, and to enable the FIDO2 module to perform signatures while ensuring that it cannot learn, modify, or abuse the authenticator’s secret key.

Protecting Secret State

Plat’s design aims to sandbox as much of the FIDO2 parsing and logic code as possible in order to guarantee that bugs in that code cannot read, modify, or use the secret key except as allowed. This is complicated by the fact that the FIDO2 code necessarily needs to perform signatures and other cryptography using this secret key. To address this, Plat’s design separates the core FIDO2 parsing and logic from the code that accesses the secret key and uses Plat’s State Manager to ensure that the isolated FIDO2 code cannot learn the secret key.

Plat separates the cryptography code into two pieces. Cryptography code that does not require access to the secret data, such as simple SHA256 hashes, is part of the sandboxed code. Cryptography functions that do use the secret key, however, such as signature and HMAC code, run in the trusted host environment and are available to the FIDO2 module only as an import. We call these functions with access to the secret key “trusted crypto” functions, and their API is designed to allow the module to learn signatures and MACs that use the secret key, but to prevent the module from learning the secret key itself. To get a signature over the data required to perform a FIDO2 authentication, for example, the FIDO2 makes a call to t_crypto_ecc256_sign() and recieves the signature in response. The secret key is automatically supplied by the host environment without the module ever seeing it.

Placing the cryptography operations behind an API in this way also allows us to place limits on when signatures can be calculated. Before computing a signature, the trusted cryptography code will ensure that the user has pressed the authenticator’s button to approve this signature and will increment the signature counter.

By storing the secret key in a separate memory region, we can ensure that sandboxed code cannot access it while running. However, security keys are designed to be unplugged and moved between computers frequently. To enable this, the secret key is stored along with all other authenticator state in persistent flash storage. Instead of allowing the FIDO2 module to access this flash storage directly and potentially read or modify the secret key, Plat’s state manager interposes on requests to read the state from flash and masks out the secret key. As illustrated below, the state manager allows only the trusted cryptography code to read the secret key from flash. The state manager also provides the FIDO2 module with only read-only access to the signature counter, ensuring that it cannot be corrupted by a bug in the module.

Sandboxing the majority of the FIDO2 code while leaving the trusted cryptography functions in the trusted host, along with using the state manager to provide safe access to persistent memory, enables Plat to perform all the cryptography functionality required to perform its job while still ensuring that a bug in the FIDO2 parsing and logic code cannot allow an attacker to learn the secret key.

Providing Safe Imports

WebAssembly’s function call interface allows only integer arguments and return types to imported and exported functions that cross the module boundary. However, Plat needs to send more complex binary datatypes across the boundary. For example, the USB stack sends and receives 64-byte packets, and the FIDO2 module requests and receives signatures over arbitrary-length data blobs. To allow for non-integer arguments and return types, Plat uses pointers.

In order to preserve isolation, WebAssembly modules do not have direct access to system memory. Instead, each WebAssembly module has a dedicated “linear memory” region. It is not possible for a module to access memory outside of this dedicated region. Because of this, pointers in the global memory space—that is, memory addresses—are not the same as pointers within module memory—we call these offsets. Plat’s design includes machinery to translate between host memory addresses and module memory offsets and vice versa.

But we must be careful not to break isolation when we do this translation. In particular, it is not safe to blindly translate module-provided offsets into host memory addresses and pass the addresses to host functions. For instance, the FIDO2 module imports the function usbhid_send to send packets to the host PC. Thanks to our pointer-based approach, the function available inside the module C code looks exactly like it would without any privilege separation at all:

void usbhid_send(uint8_t * msg);

wasm2c’s machinery generates a function declaration Z_envZ_usbhid_send that must be implemented by the host environment to provide the FIDO2 module with this import. To provide this import, the host definition calls a translation function translateGuestAddr, which also runs in the host environment, to convert the guest offset provided by the module into a physical memory address. With the physical memory address of the data the module intends to pass as an argument, the host definition then calls the underlying function call with the true physical memory address of the argument. (In this case, usbhid_send is routed eventually to the USB module, but that does not matter for this example.)

void Z_envZ_usbhid_send(struct Z_env_instance_t* env, u32 msgOffset) {
    uint8_t * msgAddr = translateGuestOffset(env, msgOffset, PKT_BUF_SIZE)
    return usbhid_send(msgAddr);
}

If this translation is naive and does not consider the length of module memory, an attacker who gains control of the FIDO2 sandbox could use this to read out the secret key! By manipulating the msgOffset argument to extend beyond the end of module memory so that the resulting msgAddr points to the beginning of the secret key, the attacker can cause the secret key to be sent over USB to the compromised host PC.

To avoid this type of sandbox escape, the translateGuestOffset function is carefully written to ensure that the offset provided by the module actually falls within the bounds of the module’s memory. For operations that will read multiple bytes, the translation function also takes the maximum number of bytes to be accessed (PKT_BUF_SIZE above) and verifies that the entire region that could be accessed is within module memory. By using this translateGuestOffset every time a module offset needs to be converted to a physical memory address, we ensure that all translations are checked and that a module cannot trick an imported function into violating the sandbox on its behalf. This technique is used for every import with blob-type arguments in Plat.

Sandboxing Device Drivers

Since drivers are common sources of bugs, we sought to sandbox the USB driver. But drivers typically require bare-metal access to the hardware: their job is to provide an abstraction over the memory-mapped IO provided by the peripheral.

However, the only memory accessible to a module directly is the module’s dedicated linear memory region. When module code dereferences a pointer, the pointer’s address is interpreted as an offset into this memory region and the dereference fails if the offset falls outside of the allocated memory region. This memory isolation is an integral part of WebAssembly’s sandboxing plan, but precludes MMIO access by drivers via WebAssembly load and store instructions: an attempted access to a specific MMIO address would be converted into nonsense and prohibited by WebAssembly’s guarantees.

Instead, Plat provides each module with access to what we call the peripheral proxy. This peripheral proxy comprises a set of imported functions that allow a module to access an explicitly defined set of physical memory addresses. For example, if the driver needs to read or write a 32-bit word to an MMIO register, it can use the following functions:

uint32_t Z_envZ_memReadWord(Z_env_instance_t* env, uint32_t addr) {
  if (checkAddr(env, addr))
    return (uint32_t) *(uint32_t *) addr;
  trap();
  return 0;
}

uint32_t Z_envZ_memWriteWord(Z_env_instance_t* env, uint32_t addr, uint32_t value) {
  if (checkAddr(env, addr)) {
    *((uint32_t *) addr = value;
    return 0;
  }
  trap();
  return 0;
}

Parallel functions exist for 8-bit and 16-bit widths. Importantly, these functions first check that the module is allowed to access the given addr and then, if permitted, perform the requested read or write. This permission check is of crucial importance: if we omitted the permission check and simply allowed the module to read and write an arbitrary physical memory address, the sandboxed driver could escape its sandbox by reading secret state or overwriting memory to hijack control flow of the host environment. Plat’s peripheral proxy inspects the module-provided address before accessing it to ensure that the address corresponds to the peripherals that the driver is responsible for. To minimize the opportunity for errors and to ease development, Plat includes infrastructure to generate the checkAddr function that performs this check from a YAML file that specifies the individual peripheral memory regions and the modules that are allowed to read each:

device-classes:
  - name: RCC
    allowed-regions:
    - start: 0x4002_1000
      end: 0x4002_13FF
  - name: PWR
    allowed-regions:
    - start: 0x4000_7000
      end: 0x4000_73FF
  - name: USB
    allowed-regions:
    - start: 0x4000_6800
      end: 0x4000_6BFF
    - start: 0x4000_6C00
      end: 0x4000_6FFF

modules:
  - name: USBHID
    allowed-classes:
    - USB
    - RCC
    - PWR
  - name: FIDO2
    allowed-classes: []

From this specification, Plat’s infrastructure generates the checkAddr function definition, which simply translates the regions that each module is allowed to access into a series of conditionals that return true if an access is permitted.

bool checkAddr(struct Z_env_instance_t * env, uint32_t addr) {
  switch (env->module_class) {
    case MODULE_CLASS_USBHID: 
    return (
      // USB
      (addr >= 0x40006800 && addr < 0x40006bff) ||
      (addr >= 0x40006c00 && addr < 0x40006fff) ||
      // RCC
      (addr >= 0x40021000 && addr < 0x400213ff) ||
      // PWR
      (addr >= 0x40007000 && addr < 0x400073ff) 
    );
    break;
    case MODULE_CLASS_FIDO2: 
    return (
      false
    );
    break;
    default:
    return false;
    break;
  }
}

Plat does not permit any peripheral access for the FIDO2 module, which performs only parsing and logic, but does permit access to the USB, PWR, and RCC peripheral memory for the USB module, which includes the entire USB stack. PWR and RCC, which control power and clock gating to all of the chip’s peripherals, is necessary to allow the USB driver to configure the USB peripheral on startup. A future iteration could allow the specification of bit-level access control over these shared configuration regions to ensure that the USB module can access only the fields of the RCC and PWR registers that correspond to the USB peripheral.

Plat’s peripheral proxy allows us to adapt existing device drivers to work in a sandboxed environment. To adapt the standard USB driver used in the original Solokey code to work in our sandbox, the only change necessary is to replace peripheral memory accesses with calls to the imported peripheral proxy functions.

This setup allows Plat to sandbox its complex USB device driver, ensuring that bugs in the driver and USB stack cannot compromise the security of the entire security key.

Conclusion

Plat’s privilege separation approach allows it to preserve the confidentiality and integrity of the secret key and prevent signature abuse even in the presence of exploitable bugs in the bug-prone code contained in the FIDO2 and USB modules. While Plat does not protect the system from all bugs, it does provide strong security guarantees for many likely classes of bugs, and it does so with reasonable performance overhead: the slowest step of an authentication increases from 277ms to 600ms. For an authentication operation that a user performs a few times a day at most, this increase is insignificant (not to mention that many users today spend several minutes trying to guess the password they used for each service).

Privilege separation has the capability to convert devastating bugs into trivial ones by means of “damage control”, but is difficult to implement effectively. Plat explores privilege separation in the new context of embedded devices, addressing the unique challenges that come with bare-metal execution and demonstrating that for many applications the overhead that comes with sandboxing is reasonable. We hope to see more systems adopt privilege separation as an additional layer of defense and hope for improved tools to make it easy to do so in the future.