<--

Personal Projects

Synacor Challenge

After participating in Advent of Code for a few years now, I have grown a fan of Eric Wastl's puzzles. This is a multi-part challenge that involves implementing a virtual machine to interpret and run the supplied binary file. You are also given a document outlining the architecture specification of the machine that can run the binary file. Once completed and the self-tests are passed, you're taken on text-based adventure as the program runs, that is very similar to AoC stories. The goal is to find 8 codes while completing various puzzles in the program. Before the original site was taken down (pretty sure Eric doesn't work at Synacor anymore), you could validate the codes found on the site, but since it is no longer up, The codes can be manually verified. Thanks to Aneurysm9/vm_challenge for providing a binary file and matching checksums for the codes. I wrote a small script to validate them from a text file. I chose to implement my solution in C with a simple stack data structure, as that seems most fitting for the task at hand. My implementation and related tools can be found here for those interested. The rest of what's here is likely to be spoilers...

Code 1

This one is found in plain text in the arch-spec file.
== hints ==
- Start with operations 0, 19, and 21.
- Here's a code for the challenge website: <CODE>
    

Code 2

After implementing a basic interpreter that supports the first subset of opcodes (out, noop, and halt), this one is found in the output.
Welcome to the Synacor OSCON 2012 Challenge!
Please record your progress by putting codes like
this one into the challenge website: <CODE>
    
Just for fun, this one can also be spotted early on in the hexdump of the binary file:
00000210  13 00 20 00 13 00 49 00  13 00 6d 00 13 00 6f 00  |.. ...I...m...o.|
00000220  13 00 46 00 13 00 7a 00  13 00 74 00 13 00 57 00  |..F...z...t...W.|
00000230  13 00 51 00 13 00 43 00  13 00 76 00 13 00 78 00  |..Q...C...v...x.|
00000240  13 00 6a 00 13 00 0a 00  13 00 0a 00 13 00 45 00  |..j.............|
    

Code 3

To retrieve this code, the interpreter must be fully implemented and must pass the initial self-tests. If those conditions are met, the third code is printed.
Executing self-test...

self-test complete, all tests pass
The self-test completion code is: <CODE>
    

Code 4

Now, the adventure aspect of the challenge begins. Pay attention to the things of interest, and take/use them as needed, like the tablet here.
What do you do?
take tablet

Taken.

What do you do?
use tablet

You find yourself writing <CODE> on the tablet.  Perhaps it's some 
kind of code?
    

Code 5

This puzzle appears to be a maze after several entries of south, north, west, etc. I decided to map my steps with pen and paper. After not too long, I arrive at the next code, but not without getting lost and eaten by grues numerous times.
What do you do?
east

Chiseled on the wall of one of the passageways, you see:

    <CODE>
    

Code 6

The next puzzle is a maths problem. There will be some coins each with a numeric value that you can inspect to see. The coins must be arranged in a specific order to satisfy the equation on the wall.
There is a strange monument in the center of the hall with circular slots and unusual symbols.  It reads:

_ + _ * _^2 + _^3 - _ = 399
    
This is easy enough to be by hand, but why not make another script to do it. Looks like 9 + 2*5^2 + 7^3 - 3 = 399 will do it, so arrange the coins in order blue, red, shiny, concave, corroded. After completing this, a previously locked door opens and our next code is revealed.
What do you do?
use teleporter

You activate the teleporter!  As you spiral through time and space, you think you see a pattern in the stars...

    <CODE>
    

Code 7

This is by far the most clever puzzle in this challenge. There's a strange book that contains some information about using the teleporter. Some provision to log instructions and register values is crucial for this puzzle. It appears we must set the 8th register to a certain value. We can set the register to a non-zero value to progress in the program, but it will not provide the correct code, thus we need to find the correct value. The underlying algorithm is a variation of the Ackermann function. The modified function can be found in the program used to find the register value. Python proved to be a bit too slow to compute this. Once set to the correct value (25734 in my case), the seventh code is shown.
You wake up on a sandy beach with a slight headache.  The last thing you remember is activating that teleporter... but now you can't find it anywhere in your pack.  Someone seems to have drawn a message in the sand here:

    <CODE>

It begins to rain. The message washes away. You take a deep breath and feel firmly grounded in reality as the effects of the teleportation wear off.
    

Code 8

This looks to be some sort of arrangement of tiles, each with a number of arithmetic operation. By moving from one tile to another, you are constructing an expression that must evaluate to the number on the door: 30. This is a BFS application to construct the shortest path to the door. I made another script to achieve this. After inputting the appropriate cardinal directions, we see the final code in a mirror. Of course, it is entered in reverse.
You gaze into the mirror, and you see yourself gazing back.
But wait!
It looks like someone wrote on your face while you were unconscious on the beach!
Through the mirror, you see <CODE> scrawled in charcoal on your forehead.

Congratulations; you have reached the end of the challenge!
    

Hardware security key for authentication on Linux

Typing in a rather long password each time I log into my computer or need to complete a privileged task can be bothersome. A couple years ago I came across solokeys, which are fully open source hardware and firmware security keys. I chose to build the Solo 1 (or five because that's the MOQ from most PCB manufacturers). Note, at the time of writing this, the solo1-cli tool is currently broken with the latest FIDO2 library, meaning it must be installed explicitly at 0.9.3.
$ pip install solo1
$ pip install fido2==0.9.3
    
After building, I didn't use it much, as many services don't support security keys quite yet, or required a paid subscription (I'm looking at you, Bitwarden). Come a few months ago, I found Yubico's PAM for U2F. This is a PAM module to provide authentication from a U2F device. To use this, first ensure the CONFIG_HIDRAW and CONFIG_USB_HIDDEV options are set in your kernel. Next, obtain the module via package manager or compiling from source and generate the authorisation mapping with your key inserted. The created directory must be named Yubico, even if not using a Yubico key. It can be overridden in util.h if you so choose.
$ mkdir ~/.config/Yubico
$ pamu2fcfg > ~/.config/Yubico/u2f_keys
Enter PIN for /dev/hidraw2:
    
Assuming all has been successful, you can configure PAM services to use the device. The following configures doas to utilise the U2F module in the /etc/pam.d/doas file. The same line can be added in other files where needed (eg. display manager, system-local-login, etc.)
auth sufficient pam_u2f.so cue pinverification=0
auth include system-auth
...
    
Above, sufficient indicates that authentication from the device alone is enough to fully authenticate. Use required instead if you want both password and device authentication to be required. cue simply displays a prompt to press the button on the device when needed to authenticate. pinverification=0 disables the need to entre the passphrase associated with your security key. Note, this means your system can be accessed only with your key, and no password entry of any type. Set the parameter to 1 if you'd like otherwise. Another thing of interest was locking/unlocking my system automatically when the key is removed/inserted, respectively. This can be achieved via a custom udev rule that executes a script when a device matching our key's VID/PID is plugged in. This script will use pamtester to test for authentication success.
#!/bin/bash
if [ "$1" == "lock" ]; then
    # lock system
else
    if [ echo "" | pamtester login  authenticate ]; then
        # kill lock program
    fi
fi
exit 0
    
Now, a custom udev rule that lives in /etc/udev/rules.d/70-solokey.rules and looks for a matching VID/PID and executes this script when found with the appropriate argument.
ACTION::"remove", ENV{DEVTYPE}::"usb_device", ENV{PRODUCT}::"0483/a2Ca", RUN+:"/usr/local/sbin/keyauth.sh lock"
ACTION::"add", ENV{DEVTYPE}::"usb_device", ENV{ID_BUS}::"usb", ENV{PRODUCT}::"0483/a2Ca", RUN+:"/usr/local/sbin/keyauth.sh unlock"