El uso de SHC para compilar las secuencias de comandos no protegerlos. No obtienes más seguridad de esta manera. El shc compila descifrados binarios y carga el script en la memoria cuando se inicia. Entonces, justo después de que comenzó el binario, solo puede segfault y recuperar su script del coredump.
aquí hay un pequeño script de ejemplo llamado test.sh:
#! /bin/bash
echo "starting script and doing stuff"
sleep 1
echo "finished doing stuff"
compilarlo con SHC:
shc -f test.sh
iniciarlo como proceso en segundo plano y la violación de segmento de inmediato:
./test.sh.x& (sleep 0.2 && kill -SIGSEGV $!)
sleep 0.2 dará al binario el tiempo suficiente para iniciar y descifrar el script original. La variable $! contiene el pid del último proceso de fondo iniciado, por lo que podemos matarlo fácilmente con la señal de falla de segmentación SIGSEGV (igual que kill -11 $!).
[1] + segmentation fault (core dumped) ./test.sh.x
Ahora podemos buscar el vertedero para el guión original:
cat core | strings
tubería Nosotros los datos en el fichero de volcado a las cadenas, que a su vez nos muestran todos los caracteres imprimibles en el archivo y podemos ahora ver el guión original entre la basura:
...
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
...
Si el guión es bastante grande, tal vez usted tiene que ajustar el tamaño de archivo de núcleo con ulimit. Bastante fácil, ¿verdad?
¡Esperamos que aprenda su lección y comience a usar un sistema de control de versiones! (git es genial) – Daenyth