Doing the naughty thing with AI

Alright, so I'm doing some distro and broader OS development. Mostly building, packaging and modification of existing distros. So nothing extraordinarily cool.

The cool bits are in how I'm testing and deploying said images.

I'm a former network engineer that's been developing and building on Linux for quite some time. If there is anything I know I understand more than the average software developer or Linux user is the concept: "everything is a socket." The OSI 7 layer model is complete bullshit, the only true model is the 2-layer model and that's the one stated above: every goddamn thing is a socket. The physical layer, the link layer, IP, TCP/UDP, your files, even your damn clipboard is a socket, because it's a medium you can write and read from. The model states you have a socket layer and a data layer and that's it. You can promote to a 3-layer model by imposing a protocol within the data layer, but you really just end up proving the 2-layer is the only real one, because your protocol now becomes a socket layer to write data to.

With that said, why is that useful? What am I doing that's naughty?

Well, I have a problem. I don't want to just build custom distros, I want to prove they work, and if I can do so agentively that would be kind of sick. The problem is image deployment. There are great tools around automatic deployment of custom images to baremetal and VMs, but I find almost all of them have ridiculous shortcomings.

cloud-init is a fat piece of bloatware (love you cloud-init, you are a god of cluster provisioning, but you are unbelievably huge on most images)
guest-agents do exist, but not all are preinstalled, and some require specific networking or specific sockets to work
for the guest-agents that do exist, most aren't shell-less execve() rpc daemons, which means environment-specific or shell-session-specific states can affect or even sometimes block IaC execution. Its not uncommon for terraform and ansible to butt heads with sshd, because sshd is a remote shell, not a remote RPC daemon, which means it carries all sorts of session state nastiness with it.
Ol' reliable serial ttys0 is also by definition, not shell-less, and also not reliable, because of serial drops.

And that list is just a subset of all the ways I know you can automatically deploy images for testing.

That's where I am at right now, but I do have a solution planned.

# The Gameplan.

When building and playtesting images, I've played around with a lot of different remote administrative tools. sshd, adbd on android, qrexec on qubes os, qemu guest agent in linux vms, etc. Most of these tools are a simple concept: RPC and a shell on a socket, but they're all vastly different in opinions to the same problem and a lot are not interchangeable nor universal

- So what if I made a one-size fits all?
- Solve serial's unreliability with PPP and TCP?
- Create a RPC daemon that works over whatever damn socket you want?
- Adopt adbd's exec and get shell-less execution?
- Even include shells, forwarding and tunnelling, because if I'm going to run PPP and TCP and why the hell not?

So claude and myself drafted this: https://github.com/sw2m/pdbd/blob/main/README.md

Intent would be to inject the pdbd binary into the image I'm testing/modifying/whatever and control it programmatically or agentively with pdb over any socket that's available

# The Spicy/Naughty Bit:

I'm posting about this early and pre-implementation, because I want to discuss the glaringly obvious problem: this is a C2 Control Channel goldmine.

It gives you everything the standard C2 attacker would ever want. A single binary, with stabilized net and control, an included RPC system, and guerilla networking architecture above and below the protocol.

The only difference between my proposed tool and a cut and dry C2 is simply the intent. That's as shallow as it gets. I may use this for image development and testing, but I can see quite-glaringly how others may use it for devious purposes.

I'm not exactly pressed away from it, because I