ssc is a project that improves on shc (shell script compiler).
Like shc, it wraps a shell script in C source code and compiles it into a binary to keep the code from being exposed.

Unlike shc, ssc doesn’t rely on the system shell — it uses a separate shell interpreter (e.g., BusyBox) instead.
So the technique used to attack shc (auditd) can’t be applied to ssc in the same way.

That said, ssc has a structural limitation of its own.
A binary built with ssc briefly drops the embedded shell interpreter (e.g., BusyBox) to disk at /tmp/ssc.XXXXXX/busybox, then hands the shell script off to it to run.
So if you just watch for the moment the embedded shell interpreter gets exposed externally, you can capture the shell script.

ssc vulnerability diagram

Let’s test this directly and confirm the vulnerability.

Test Environment

The following shell script was tested on Ubuntu 24.04.

Test shell script

We’ll build the binary with the shell interpreter (BusyBox) embedded, as shown below.

./ssc test ssc_binary -s -r -e busybox -c

Test Method

# Install bpftrace
sudo apt install bpftrace

# Start monitoring in terminal 1
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_write /comm == "ssc_binary"/ { printf("PID: %d | FD: %d | Data: %s\n", pid, args->fd, str(args->buf)); }'

# Run ssc_binary in terminal 2
./ssc_binary

As shown in the red box in the image below, bpftrace (a kernel tracing tool) makes it easy to capture the shell script.

Terminal 2 monitoring result

Terminal 1 monitoring result

Solution

What’s needed is a protection tool that keeps the shell interpreter entirely internal instead of exposing it externally.
A representative example is HimitsuShell.

The next post will introduce HimitsuShell.