Skip to content

Commit 24098aa

Browse files
committed
Create 2026-08-10-shc-vs-himitsushell-en.md
1 parent 331ccb0 commit 24098aa

1 file changed

Lines changed: 102 additions & 0 deletions

File tree

Lines changed: 102 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,102 @@
1+
---
2+
layout: post
3+
title: "Comparing Shell Script Protection Tools: shc vs HimitsuShell (Binary Compilation, Encryption, and Obfuscation)"
4+
date: 2026-08-10 17:30:00 +0900
5+
lang: en
6+
categories: [en]
7+
---
8+
[shc](https://github.com/neurobin/shc/tree/master) (a shell script compiler) is a tool that converts shell scripts into binaries to prevent source code exposure. However, it has the following limitations in real-world use:
9+
- It provides no obfuscation, which leaves it vulnerable to reverse engineering.
10+
- It depends on the system shell (e.g., /bin/sh), which leaves it vulnerable to logging/hooking attacks.
11+
12+
[HimitsuShell](https://github.com/HimitsuShell/HimitsuShell) was built to address these gaps. It applies a variety of LLVM-based obfuscation techniques and doesn't depend on the system shell either.
13+
14+
Now let's walk through the comparison item by item.
15+
16+
## Test Environment
17+
The following shell script is used on Ubuntu 24.04.
18+
19+
![Test shell script](/assets/images/shc-vs-himitsushell/1.png)
20+
21+
HimitsuShell is run with its default options, while shc is run at [maximum security level](https://github.com/neurobin/shc/blob/master/man.md) as shown below.
22+
23+
```shell
24+
shc -Uf launcher.sh -o shc_binary
25+
```
26+
27+
As shown below, the binaries produced by both HimitsuShell and shc run correctly.
28+
29+
![Binary execution test results](/assets/images/shc-vs-himitsushell/2.png)
30+
31+
## Debug Symbol Stripping
32+
33+
![Debug symbols removed](/assets/images/shc-vs-himitsushell/3.png)
34+
35+
Both HimitsuShell and shc strip debug symbols.
36+
37+
## Protection against Dynamic Library Hooking
38+
39+
![Dynamic library lookup results](/assets/images/shc-vs-himitsushell/4.png)
40+
41+
HimitsuShell doesn't rely on dynamic libraries, but shc does.
42+
As a result, shc is vulnerable to hooking attacks.
43+
44+
## Debugger Detection
45+
46+
![Debugger detection verification results 1](/assets/images/shc-vs-himitsushell/5.png)
47+
48+
![Debugger detection verification results 2](/assets/images/shc-vs-himitsushell/6.png)
49+
50+
Both HimitsuShell and shc detect and block debuggers (e.g., gdb, strace).
51+
52+
## String and Constant Obfuscation
53+
54+
![String obfuscation verification results 1](/assets/images/shc-vs-himitsushell/7.png)
55+
56+
![String obfuscation verification results 1](/assets/images/shc-vs-himitsushell/8.png)
57+
58+
Looking at the string list in Ghidra makes the difference obvious.
59+
HimitsuShell's strings are obfuscated, while binaries built with shc expose sensitive strings as plain text.
60+
HimitsuShell also provides constant obfuscation, while shc does not.
61+
62+
## Advanced Obfuscation (Control Flow Flattening, Dead Code Injection, etc.)
63+
64+
![Control flow graph results 1](/assets/images/shc-vs-himitsushell/9.png)
65+
66+
![Control flow graph results 2](/assets/images/shc-vs-himitsushell/10.png)
67+
68+
Looking at the control flow graph of the main function in Ghidra, the difference is clear.
69+
HimitsuShell is obfuscated to the point where tracing the control flow is essentially impossible.
70+
shc, on the other hand, has a simple control flow that's easy to analyze.
71+
72+
## Protection against OS-level Logging and Hooking
73+
74+
![auditd verification results 1](/assets/images/shc-vs-himitsushell/11.png)
75+
76+
If you monitor the system calls (e.g., execve) of a binary built with shc using auditd, the shell script shows up in the logs in plain text.
77+
Because it relies on the system shell, it's vulnerable to OS-level logging/hooking attacks.
78+
79+
![auditd verification results 2](/assets/images/shc-vs-himitsushell/12.png)
80+
81+
In contrast, a binary built with HimitsuShell shows no shell script logging under the same conditions.
82+
That's because it doesn't rely on the system shell — it uses a shell embedded in the binary itself.
83+
84+
## Conclusion
85+
As shown above, there's a clear difference in security strength between shc and HimitsuShell.
86+
87+
||shc|HimitsuShell|
88+
|---|---|---|
89+
|Debug Symbol Stripping|✓|✓|
90+
|Protection against Dynamic Library Hooking| |✓|
91+
|Debugger detection|✓|✓|
92+
|String and Constant Obfuscation| |✓|
93+
|Advanced Obfuscation (Control Flow Flattening, Dead Code Injection, etc.)| |✓|
94+
|Protection against OS-level Logging and Hooking| |✓|
95+
96+
## Additional Comparison
97+
There's also [ssc](https://github.com/liberize/ssc), which improves on shc.
98+
It addresses some of the issues (dynamic library hooking defense, string obfuscation), but still has limitations around advanced obfuscation and OS-level logging/hooking defense.
99+
100+
**Notably, while ssc doesn't depend on the system shell, at runtime it extracts the interpreter (e.g., /bin/sh) to the path /tmp/ssc/XXXXXX and passes the shell script to it. This means logging or hooking that path leaves the shell script vulnerable to extraction.**
101+
102+
HimitsuShell, on the other hand, never extracts the interpreter outside the binary, so it's safe from this issue.

0 commit comments

Comments
 (0)