DEV Community: HimitsuShell

Shell Script-to-Binary Tools: shc vs. HimitsuShell

HimitsuShell — Wed, 24 Jun 2026 07:01:38 +0000

shc is a tool that converts shell scripts into binaries to prevent source code exposure. It is widely used, but has several limitations in practical use:

It provides no obfuscation, making it vulnerable to reverse engineering.
It depends on system shells such as /bin/sh, exposing it to logging- and hooking-based attacks.

In contrast, HimitsuShell was designed to address these issues. It applies various obfuscation techniques and does not rely on system shells, providing better protection against logging- and hooking-based attacks.

Below is a comparison across multiple aspects.

Test Environment

The test is conducted on Ubuntu 24.04 using the following shell script:

HimitsuShell is executed with default settings, while shc is built using its maximum security configuration:

shc -Uf launcher.sh -o shc_binary

Both binaries generated by HimitsuShell and shc execute correctly as shown below.

Debug Symbol Stripping

Both HimitsuShell and shc strip debug symbols.

Protection against Dynamic Library Hooking

Himitsu Shell does not rely on dynamic libraries, whereas shc does. As a result, shc is vulnerable to hooking-based attacks.

Debugger Detection

Both HimitsuShell and shc detect debuggers such as gdb and strace and terminate execution accordingly.

String and Constant Obfuscation

When extracting strings using Ghidra, the difference is apparent.

HimitsuShell obfuscates strings, making analysis more difficult. In contrast, shc binaries expose sensitive strings in plaintext.

Additionally, HimitsuShell supports constant obfuscation, while shc does not.

Advanced Obfuscation (Control Flow Flattening, Dead Code Injection, etc.)

The control flow graph of the main function in Ghidra reveals a clear difference.

HimitsuShell heavily obfuscates the execution flow, making analysis significantly harder.

shc, on the other hand, has a simple and readily analyzable control flow.

Protection against OS-level Logging and Hooking

When monitoring execve using auditd, scripts executed via shc expose the original shell script content in the logs.
This happens because shc relies on the system shell.

In contrast, binaries generated by HimitsuShell do not expose script contents under the same conditions. This is because HimitsuShell does not rely on an external system shell and handles execution internally.

Conclusion

A comparison between shc and Himitsu Shell reveals clear differences in obfuscation and protection against OS-level logging and hooking.

Additional Comparison

ssc is another tool that improves upon shc.

It introduces protection against dynamic library hooking and string obfuscation, but still has limitations in advanced obfuscation and protection against OS-level logging and hooking.

In particular, ssc is independent of the system shell, but it extracts an interpreter (e.g., /bin/sh) into /tmp/ssc/XXXXXX during execution. This leaves a window during which logging and hooking are still possible.

In contrast, Himitsu Shell does not extract an external interpreter and handles execution internally, making it more resilient than ssc under the same conditions.

ssc Security Analysis: Structural Limitations of a Shell Script Compiler

HimitsuShell — Wed, 24 Jun 2026 06:39:37 +0000

ssc is a project designed to improve upon shc, a popular Shell Script Compiler. Like shc, it converts shell scripts into C source code and then builds them into binaries to prevent source code exposure.

liberize / ssc

Convert shell script to binary

Simple Script Compiler

中文版

This is a powerful tool to turn almost any script to binary, inspired by shc.

ssc itself is not a compiler such as cc, it rather generates c++ source code with script code, then uses c++ compiler to compile the source into a binary which behaves exactly like the original script.

Upon execution, the binary will call real script interpreter (systemwide, bundled or embeded), and fork a child process to pipe script code to the interpreter to execute.

Prerequisite

(Note: g++ version should be 5.2 or above)

For Debian-based Linux distros

g++, perl, binutils
libc-dev, libstdc++-dev (only required by -s flag)
libz-dev (only required by -E flag)
libz-dev, libfuse-dev, git, gcc, make, automake, autoconf, pkg-config, libtool, squashfs-tools (only required by -M flag)

For RedHat-based Linux distros

g++, perl, binutils
glibc-static, libstdc++-static (only required by -s flag)
zlib-devel (only required by -E flag)
zlib-devel, fuse-devel, git, gcc…

View on GitHub

Unlike shc, ssc does not directly depend on the system shell. Instead, it embeds a shell interpreter inside the generated binary.

As a result, the attack technique demonstrated in the previous shc analysis using auditd (an operating system-level monitoring tool) cannot be applied to ssc in the same way.

HimitsuShell

Jun 23

shc Security Analysis: Structural Limitations of a Shell Script Compiler

#security #linux #bash #opensource

2 min read

However, ssc also has its own structural limitations.

Binaries generated by ssc temporarily extract an embedded shell interpreter (for example, BusyBox) to a path such as: /tmp/ssc.XXXXXX/busybox

The shell script is then passed to the extracted interpreter for execution.

As a result, if an attacker monitors the moment the embedded interpreter becomes externally accessible, the original shell script can be recovered.

Let’s reproduce the issue and examine the limitation in practice.

Test Environment

On Ubuntu 24.04, use the following shell script.

Use the following command to embed the shell interpreter

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

Reproducing the Issue

# 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 screenshot below, the original shell script can be recovered using bpftrace, a kernel-level monitoring tool.

Mitigation

To avoid this issue, a Shell Script Compiler should process the shell interpreter internally without extracting it outside the binary.

Architectures that temporarily expose the interpreter to the operating system may still be vulnerable to kernel-level monitoring attacks such as the one demonstrated above.

One example of an alternative approach is HimitsuShell.

The following articles provide additional information:

[Boost]

HimitsuShell — Tue, 23 Jun 2026 07:36:23 +0000

HimitsuShell

Jun 23

shc Security Analysis: Structural Limitations of a Shell Script Compiler

#security #linux #bash #opensource

2 min read

shc Security Analysis: Structural Limitations of a Shell Script Compiler

HimitsuShell — Tue, 23 Jun 2026 07:25:11 +0000

shc is one of the most widely used Shell Script Compilers. It converts a shell script into C source code and then builds it into a binary to prevent source code exposure.

However, shc has a fundamental architectural limitation: it relies on the system shell for script execution, making it vulnerable to operating system-level logging and hooking attacks.

neurobin / shc

Shell script compiler

Shell Script Compiler

A generic shell script compiler. Shc takes a script, which is specified on the command line and produces C source code. The generated source code is then compiled and linked to produce a stripped binary executable.

The compiled binary will still be dependent on the shell specified in the first line of the shell code (i.e shebang) (i.e. #!/bin/sh), thus shc does not create completely independent binaries.

shc itself is not a compiler such as cc, it rather encodes and encrypts a shell script and generates C source code with the added expiration capability. It then uses the system compiler to compile a stripped binary which behaves exactly like the original script. Upon execution, the compiled binary will decrypt and execute the code with the shell -c option.

Install

./configure
make
sudo make install

Note If make fails due to automake version, run ./autogen.sh before running the…

View on GitHub

Binaries generated by shc execute shell scripts by passing them to the system shell (for example, /bin/bash).

As a result, if an attacker monitors the moment the script is passed to the system shell, the original shell script can be recovered with relative ease.

Let’s reproduce the issue and examine the limitation in practice.

Test Environment

On Ubuntu 24.04, use the following shell script.

Use the maximum security settings as shown below

shc -Uf launcher.sh -o shc_binary

Reproducing the Issue

# Install auditd
sudo apt install auditd -y

# Register monitoring rule
sudo auditctl -a exit,always -F arch=b64 -S execve

# Run the shc binary
./shc_binary

# Check logs
sudo ausearch -i -sc execve | grep "shc_binary" -A 100

As shown in the screenshot below, the original shell script can be recovered using auditd, an operating system-level monitoring tool.

Mitigation

To avoid this issue, a Shell Script Compiler should not rely on the system shell for script execution.

Architectures that depend on the system shell are inherently exposed to operating system-level logging and hooking attacks such as the one demonstrated above.

Several alternatives exist, including ssc and HimitsuShell. However, ssc also has its own architectural limitations.

The following articles provide additional analysis: