Lockshell Devlog 0 - Hello World

2023-10-21
 Lockshell Devlog #0

So what is Lockshell?

Lockshell is simply a program that “locks someone” in what they might believe to be a shell (something analogous to a bash, zsh, fish, etc). Given that “pretend-shell-with-signal-locking-functionality-for-potential-bad-actors” was a tad too verbose, I decided simplicity might be best. For lore-sake, I was originally going to call it kraken, where it acted more like a shell and more active countermeasures (think the pwnagotchi or flipper zero but instead of support, it’s taunting you or trying to frustrate you or intentionally giving misinformation) but I think the existing complexity is enough to keep me busy for a little bit.

Another quick thing, this is not a terminal emulator. It really is just a program that doesn’t let you escape (with extra steps), so if you are looking for your next temrinal emulator for your hot new ricing project, this is not it.

Locking?

Linux (and OpenBSD [and assuming by extension the BSD variants]) has something called signals, originally derived from Unix. They are a software form of exceptional control flow, which allows processes and the kernel to interrupt other processes. Effectively, a signal is a small message that tells a process that some event has occurred in the system. The following table consists of a couple of standard linux signals (which can be found on the manpages):

To start there will be a focus on how to handle SIGINT, SIGQUIT, and SIGTSTP, these can be invoked using CTRL+C,CTRL+D,CTRL+Z, respectively. By explicitly handling these signals (and then simply doing nothing), it should act as a pseudo-lock where breaking out of the shell is not a trivial matter.

*Btw, something similar happens in the (somewhat) popular sl utility. It displays animations aimed to correct users who accidentally enter sl instead of ls. SL stands for Steam Locomotive. (man pages description)

Why?

I am creating lockshell for a myriad of different reasons:

Roadmap (without any Promises)

Given that this is simply a side-project and not the next VC-backed billion-dollar unicorn company out of the valley jammed with all the latest and greatest buzz-words, I don’t have a responsibility to anyone or any organization to do the following but some things that I hope to achieve:

*After Defcon 31, I checked out the packet hacking village and learned about cowrie. It was pretty dope seeing and learning how to configure an actual cyber-deception tool, but it also let me see the playback functionality. I was curious how one could create that, so I took a look at how script and scriptreplay worked. Code looks a bit like this, check the RedHat link for a better tutorial on how it worked:

# to create a typescript of a terminal session
$ script --timing=time.tm script.out
Script started, output log file is 'script.out', timing file is 'time.tm'.
$ echo "Hello World"
Hell World
$ ls
<list files in directory>


# to replay the typescript of a terminal session
$ scriptreplay --timing=file.tm script.out
<Watch the shell commands invoked and their execution>

*https://www.redhat.com/en/blog/record-terminal-script-scriptreplay

Blazingly Fast?

This project originally started in Crablang (for about 4 minutes), but I lacked the necessary knowledge on both Unix Signals and Crablang. (Also, I wanted to get better at C, I had a blast when I learned it at University). Now with some more experience, and more documentation on how to handle more than just SIGINT, it doesn’t seem as daunting. I took a quick look at the ecosystem now and was able to find these 2 gems: https://rust-cli.github.io/book/in-depth/signals.html and https://crates.io/crates/signal-hook. So I might have to do the obligatory rewrite in Crablang… one day.

Resources

To write this