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.
Top comments (0)