Die Verwendung von shc zum Kompilieren Ihrer Skripte schützt diese nicht. Sie erhalten auf diese Weise nicht mehr Sicherheit. Die mit shc kompilierte Binärdatei entschlüsselt und lädt das Skript beim Start in den Speicher. Sie könnten dann direkt nach dem Start der Binärdatei einen Segfault ausführen und Ihr Skript aus dem Coredump abrufen.
Hier ist ein kleines Beispielskript namens test.sh:
#! /bin/bash
echo "starting script and doing stuff"
sleep 1
echo "finished doing stuff"
Kompilieren Sie es mit shc:
shc -f test.sh
Starten Sie ihn als Hintergrundprozess und lassen Sie ihn sofort segfaulen:
./test.sh.x& ( sleep 0.2 && kill -SIGSEGV $! )
sleep 0.2 gibt dem Binary genug Zeit, um zu starten und das Originalskript zu entschlüsseln. Die Variable $! enthält die PID des zuletzt gestarteten Hintergrundprozesses, so dass wir ihn leicht mit dem Segmentierungsfehlersignal SIGSEGV (wie kill -11 $!) beenden können.
[1] + segmentation fault (core dumped) ./test.sh.x
Jetzt können wir den Speicherauszug nach dem Originalskript durchsuchen:
cat core | strings
Wir leiten die Daten in der Dump-Datei an Strings weiter, die uns dann alle druckbaren Zeichen in der Datei anzeigen, und wir können jetzt das ursprüngliche Skript zwischen dem Müll sehen:
...
4.0.37(2)-release
BASH_VERSINFO
BASH_VERSINFO
release
i686-pc-linux-gnu
BASH_EXECUTION_STRING
BASH_EXECUTION_STRING
#! /bin/bash
echo "starting script and doing stuff"
sleep 1
echo "finished doing stuff"
1000
EUID
EUID
1000
...
Wenn das Skript ziemlich groß ist, müssen Sie vielleicht die Größe der Kerndatei mit ulimit anpassen. Ziemlich einfach, oder?