Bus Kill

[JamesTaiclet]

Hello all,

Recently I was browsing the internet in Internet Explorer and found this interesting piece of fringe technology on my RSS feed!

GitHub - BusKill/buskill-app: BusKill's main CLI/GUI app for arming/disarming/configuring the BusKill laptop kill cord

BusKill's main CLI/GUI app for arming/disarming/configuring the BusKill laptop kill cord - BusKill/buskill-app

github.com

Its an interesting concept. A USB drive that is attached to you and the computer, with a magnetic break-away in the center. When you get up, the USB drive is disconnected, thus rendering the computer inoperable. To bad they want 50-100 dollars for each USB kill cable when similar cables are available on aliexpress for next to nothing. Also having the cable would hurt plausible deniability; your silence cannot be used against you in court but having a bus kill branded cable could be introduced as attempts to hide evidence.

A much cheaper and more plausibly deniable system could be made using a cheap magnetic break away cable, a usb-c female to usb-a female adapter, a low profile usb drive that has a lanyard attachment point, and a good means of attaching it to yourself. This setup comes out to a whopping 25.91 USD, and you might even have some of these items at hand already. Fill with necessary documents that you might actually use on a regular basis and you have a very plausibly deniable system.

I have tried the software on my computer (Ubuntu, the only acceptable linux operating system for a homosexual man of my stature) and it seemed to work acceptably. Despite their rather questionable decision to use Python for this application, nothing seems to be unstable. I am going to mess around with the triggers and CLI mode at some point and see what interesting behaviors could be set up. If it actually performs well I could see myself adding it to my list of things to use when traveling for business.

Yours,
James "Jerkin" Taiclet

 

[Arnox]

Oooooh, this is interesting. Maybe an even better implementation of this would be to also have it trigger simply when the power cord is unplugged or if the computer is turned off without logging back in. To really take advantage of this though, you would need a third-party server you own or rent that the laptop can connect to over wi-fi if BusKill gets trigger which would allow for remote tracking and the erasing of data.

 

[JamesTaiclet]

Oooooh, this is interesting. Maybe an even better implementation of this would be to also have it trigger simply when the power cord is unplugged or if the computer is turned off without logging back in. To really take advantage of this though, you would need a third-party server you own or rent that the laptop can connect to over wi-fi if BusKill gets trigger which would allow for remote tracking and the erasing of data.

Hello,

I am not sure how windows exposes the battery status in winapi but the former idea sounds doable, and uses hardware that would not be suspicious in any manner. No need for plausibly deniable hardware. I am also unsure of how to access winapi calls through python, generally c++ is more up to the task. Might require a full re-write of the code base at that stage, although this is not a particularly sophisticated application by any means.

The ladder idea could be absolutely excellent, they actually have an exposed set of triggers for you to create custom actions. You could even host your own server without exposing the end point for remote wiping via Tor. Tor hidden services can easily be run behind realistically any network, so the server location could be obscured and even be run out of a small home network (possibly not even yours). I could especially see this being used to great advantage in toughbooks that have integrated sim card modems, applications can still reach the internet even when the computer is sleeping (excluding hibernation). Triggering the panic condition could start the web interface to regularly query the computer for location information, access to the camera, listening into the microphone, ect to track, identify & monitor the actor.

Smart actors (state actors in particular) will probably open the device up in an airgap. To prevent data recovery it might be best to pair it with a veracrypt hidden partition system. Thus, the computer could be unlocked to a plausibly deniable device, with the real operating system being obscured entirely. Pair this with a secondary encryption system for files to increase the entropy (state actors have access to powerful FPGA driven hardware for encrypted volume cracking), and you would be golden.

Yours,
James Taiclet

 

[Arnox]

Hello,

I am not sure how windows exposes the battery status in winapi but the former idea sounds doable, and uses hardware that would not be suspicious in any manner. No need for plausibly deniable hardware. I am also unsure of how to access winapi calls through python, generally c++ is more up to the task. Might require a full re-write of the code base at that stage, although this is not a particularly sophisticated application by any means.

The ladder idea could be absolutely excellent, they actually have an exposed set of triggers for you to create custom actions. You could even host your own server without exposing the end point for remote wiping via Tor. Tor hidden services can easily be run behind realistically any network, so the server location could be obscured and even be run out of a small home network (possibly not even yours). I could especially see this being used to great advantage in toughbooks that have integrated sim card modems, applications can still reach the internet even when the computer is sleeping (excluding hibernation). Triggering the panic condition could start the web interface to regularly query the computer for location information, access to the camera, listening into the microphone, ect to track, identify & monitor the actor.

Smart actors (state actors in particular) will probably open the device up in an airgap. To prevent data recovery it might be best to pair it with a veracrypt hidden partition system. Thus, the computer could be unlocked to a plausibly deniable device, with the real operating system being obscured entirely. Pair this with a secondary encryption system for files to increase the entropy (state actors have access to powerful FPGA driven hardware for encrypted volume cracking), and you would be golden.

Yours,
James Taiclet

Indeed. Love those ideas. Only problem is it may be a lot of work to implement them. Or maybe not at all.

 

[JamesTaiclet]

Indeed. Love those ideas. Only problem is it may be a lot of work to implement them. Or maybe not at all.

Hello,

I am not sure about windows, but in linux the status of the power cable is tracked in a file accessible on the computer itself. This is found in the file "/sys/class/power_supply/AC/online". It seems pretty easy to poll. Here is some boilerplate code I cooked up while bored that seems to work with the AC power removal idea.

#include <iostream>
#include <fstream>

int main (void) {
        std::fstream acstatus;
        acstatus.open("/sys/class/power_supply/AC/online", std::fstream::in);
        char val, flag = 1;
        while (1) {
                acstatus >> val;
                if (val == '0' && flag) {
                        std::system("xdg-screensaver lock");
                        flag = 0;
                } else if (val == '1' && !flag) {
                        flag = 1;
                }
                acstatus.clear();
                acstatus.seekg(0, std::fstream::beg);
        }
}

Its nothing seriously fancy but it seems to work fairly well. Had to add an extra check in to ensure that the program doesn't spam the lockscreen command repeatedly, which will force the user to lock out (discovered this while testing, not fun).

Yours,
James Taiclet

 

[Arnox]

Hello,

I am not sure about windows, but in linux the status of the power cable is tracked in a file accessible on the computer itself. This is found in the file "/sys/class/power_supply/AC/online". It seems pretty easy to poll. Here is some boilerplate code I cooked up while bored that seems to work with the AC power removal idea.

#include <iostream>
#include <fstream>

int main (void) {
        std::fstream acstatus;
        acstatus.open("/sys/class/power_supply/AC/online", std::fstream::in);
        char val, flag = 1;
        while (1) {
                acstatus >> val;
                if (val == '0' && flag) {
                        std::system("xdg-screensaver lock");
                        flag = 0;
                } else if (val == '1' && !flag) {
                        flag = 1;
                }
                acstatus.clear();
                acstatus.seekg(0, std::fstream::beg);
        }
}

Its nothing seriously fancy but it seems to work fairly well. Had to add an extra check in to ensure that the program doesn't spam the lockscreen command repeatedly, which will force the user to lock out (discovered this while testing, not fun).

Yours,
James Taiclet

That is awesome. Thank you for contributing that.

 

[JamesTaiclet]

That is awesome. Thank you for contributing that.

Hello,

Thank you, but hold your praise. Going to be working on a version that could work in windows here soon, we will see how my winapi skills have aged. Since veracrypt hidden OS type volumes really only function on windows, this will be the primary target.

 

[Arnox]

Hello,

Thank you, but hold your praise. Going to be working on a version that could work in windows here soon, we will see how my winapi skills have aged. Since veracrypt hidden OS type volumes really only function on windows, this will be the primary target.

You know what, I'd say unless you wish to develop for 8.1 and below, I wouldn't bother. I myself am no longer offering any technical support to Windows 10 or 11.

 

[JamesTaiclet]

You know what, I'd say unless you wish to develop for 8.1 and below, I wouldn't bother. I myself am no longer offering any technical support to Windows 10 or 11.

Hello,

I can understand the adversity to windows. Windows 8.1, 10, and 11 all have very similar winapi changes with minimal, if any, differences. Whatever application would come as a result of this would likely work on all of them. I only focus on windows because something like this would be great in addition to Veracrypt's plausibly deniable operating system model. This would allow a user to have two separate operating systems working in tandem that look identical. When the ac + stick would be pulled, the person would be logged out. Should they be demanded to log back in, they can then log into their fake operating system. Unfortunately veracrypt has not worked on a version of this for linux, likely due to their chronic under-funding.

I think the best route for all of this in a more mature program would be to structure the codebase so that it used a common interface library such as qt, and then the functions to check for the presence of the AC power and USB drive's be in separate libraries. At compile time, the user would specify which they OS they are building for, which would set the macros to compile only things relevant to that operating system. This would allow the same codebase to be maintained for both programs.

Yours,
James Taiclet