Lockshell Devlog 2 - Fork this

2024-02-29
 Lockshell Devlog Fork

This article is about the “fork” between lockshell & painshell. And how they are becoming “separate” projects with different goals.

Rationale

So why the split?

There are a myriad of reasons for the split. It came down to 2 things: a design / architectural decision and wanting to close out a project and be able to gain some non-trivial data to improve the process in the future.

Starting with the architectural decision, I originally set out to build lockshell as a way to block any intruders from doing damage whilst giving them the illusion of success. That initial goal was met but after checking out how cowrie works. There was a realization that it would be infinitely more valuable to see keypresses and signals for threat intel. It seemed only prudent to do a re-write that factored in both of those inputs without hurting each other. (Signals could be caught but at the cost of user input and visa versa)

Likewise I didn’t want to create anything that could be used as a keylogger. Turns out in order to capture those things for threat intelligence, it would have to function like a keylogger and log the keys written. Additionally the version behind lockshell was for it to be available for *unix systems like Ubuntu, Debian, Arch and OpenBSD without too much modification. But even when trying to modify the makefile, on both OpenBSD and Arch there seemed to be a disconnect with how they functioned.

Additionally it came to the reliance on stuff like gcc, make and signal(). (There is nothing wrong with these but tools like clang,sigaction, and any other build tool might be better suited). There were reasons for doing it then but tech debt should be cleaned up before jumping onto bigger and better. As an example, I leveraged gcc to come up with a quick and incredibly hacky way to get 20 characters of data of ambiguous memory without being reliant of time.h or libsodium.h for creating some ID for logging unique files. I used the following bit of C code:

// hacky way to get random alphanumeric characters from ambiguous memory
snprintf(_id, 20, "%x", "%x");

While this works in creating the random bits to better ID the file a craftier adversarial might be able to manipulate memory in such a way that these files can be overwritten, affecting the integrity of this project. Not to mention, if there was a decision to obfuscate the binary (use movfuscator for example), it may not be able because of the reliance on gcc.

If it wasn’t already clear, it seemed like the project had some past tech debt and the scope kept increasing to the point where it felt like this would be another infinite project or start from the beginning and scrap all of the work for the potential of a brighter future. To ensure that there was an end goal in mind and to not create any of these scenarios, it became clear that a fork needed to happen.

Forcing a “fork”

So after realizing that I wanted to branch out with 2 different goals but have similar beginnings, I would need to fork the current lockshell repository. My initial assumption was that the split from a base would be as easy as clicking fork. And then done, create a fork then start with changing up lockshell and then begin to work on painshell.

The figure above shows how Github forks repositories. Different users can fork the same project. However the same user can’t fork their own project even if it has another name. Additionally, I tried was to transfer ownership from my user to a organization, then fork that organization’s repository to my own, effectively creating the illusion that it was a different person but no success was found there. Unfortunately for me, it appears Github doesn’t allow me to be able to fork my own repository. Unfortunately for Github if there is a way to hack up a solution, I will find it.

I found success when I thought of it as less of a fork and more of a template. Github has a concept of template repositories. Generally they are used for organizations to follow a certain pattern or standard. But personal accounts can use them to follow patterns as well, sometimes they can be used to create a readme.md pattern for repositories: check out this README template. Using this template feature, I was able to set lockshell to be a template repository. I then decided to create the painshell repository and have it be generated from the lockshell template repository. This allows there to be some reference to the original lockshell repository from the painshell repository, while being able to start at the point where I wanted to “fork” it from. After being “forked”, I reverted lockshell from a template repository back to a regular repository and like that I was able to force Github to fork my repo.

While it doesn’t say forked from AOrps/lockshell, I think the generated from AOrps/lockshell looks a bit cooler and highlights the unique journey of the painshell origin and the gymnastics required to make into a reality.

Why happens now?

So given that there are now 2 different repositories, what are the future milestones for each?

lockshell is going to be converted to a more simple repository where experiments on the basic program can begin via a global phase 1 deployment. Additionally, it serves as a testbed where I can test out the usability and functionality of this homegrown honeypot. Any lessons from lockshell will be used to improve and beef up painshell. (Although it might be in different languages, but we will cross that bridge when we get to it)

Lockshell:

  1. Clean up code-base. (Currently there are multiple log functions that all work slightly differently)
  2. Convert the code-base to rust. (With a more simple functionality created, it should make the transition to rust a fun learning project). If not Rust, then perhaps it might be useful to play with some macro dark magic to leverage OpenBSD’s pledge() and unveil() functionalities.
  3. Focus on creating an aesthetically pleasing repository (Filled with ‘superficial’ badges to make it look official, superficial can be a contentious point but it does spice it up)
  4. Deploy global lockshell deployments for a phase 1 (Use those findings to improve functionality, capabilities and processes of painshell and understand current short-comings with the existing technology.

Really, lockshell can be considered a test bed for a much more ambitious cyber deception project that I hope will be painshell.

Painshell:

With respect to this series of blogs, expect more of a focus to be on lockshell for the time to come until a global deployment of lockshell and its findings have been digested.

Resources