53 votes

Comment compiler un shell linux script pour qu'il soit un exécutable autonome *binaire* (c'est-à-dire pas seulement par exemple chmod 755) ?

Je suis à la recherche d'un ensemble d'outils libres et gratuits qui compilera divers langages de script "classiques", par exemple Korn Shell, ksh, csh, bash etc. sous forme d'un exécutable -- et si le script appelle d'autres programmes ou exécutables, pour qu'ils soient inclus dans l'exécutable unique.

Raisons :

  1. Pour obscurcir le code à livrer à un client afin de ne pas révéler notre propriété intellectuelle - pour le livrer à un client du client mes propres machines/systèmes pour lesquels je n'ai aucun contrôle sur les autorisations que je peux définir en matière d'accès, de sorte que le fichier du programme doit être binaire, ce qui fait que le fonctionnement ne peut pas être facilement vu en l'affichant dans un éditeur de texte, ou hexdump téléspectateur.

  2. Réaliser un programme unique, simplement déployé pour le client, sans ou avec un minimum de dépendances externes.

Je préférerais quelque chose de simple sans avoir besoin de gestionnaire de paquets depuis :

  1. Je ne peux pas compter sur les connaissances du client pour exécuter les instructions d'emballage (non) et les instructions d'emballage (non).

  2. Je ne peux pas me fier aux politiques régissant leurs machines en ce qui concerne l'installation de paquets (et même de tiers).

L'approche préférée la plus simple est de pouvoir compiler en code machine correct un seul exécutable qui fonctionnera sans aucune dépendance.

48voto

therobyouknow Points 2026

La solution qui répondrait entièrement à mes besoins serait SHC - un outil gratuit, ou CCsh un outil commercial. Tous deux compilent les scripts shell en C, qui peuvent ensuite être compilés à l'aide d'un compilateur C.

Liens sur le SHC :

Liens sur le CCsh :

1 votes

Je n'avais jamais entendu parler de ça avant, mais ça semble faire ce que le PO demande. Notez qu'il peut ou ne peut pas être compatible avec certaines fonctionnalités de bash ou ksh, mais cela n'a probablement pas d'importance pour les besoins de l'OP. Il a également une fonction pour donner au binaire compilé une date d'expiration.

1 votes

C'est la réponse définitive. J'utilise SHC pour compiler mes scripts shell, il existe depuis 2002, si je ne me trompe pas. SHC a été créé par Francisco Javier Rosales García. Bien que, c'est un peu dit, mais il fonctionne toujours.

0 votes

J'ai récemment essayé cet outil, SHC, et bien qu'il ait compilé sur mon système Fedora 14 daté, les exécutables résultants ne fonctionnaient pas correctement, ils s'exécutaient comme s'ils étaient en arrière-plan et je devais taper fg pour les mettre au premier plan. C'était le cas pour les scripts les plus basiques, donc je ne suis pas sûr de ce qui se passe.

7voto

SirDarius Points 13074

Vous pourriez utiliser ceci : http://megastep.org/makeself/

Ceci génère un shell script qui extrait automatiquement une archive tar.gz dans le répertoire temporaire, et peut ensuite exécuter une commande arbitraire lors de l'extraction.

En utilisant cet outil, vous pouvez fournir un seul script au client.

Ce script va ensuite extraire votre debsh scripts et binaires obfusqués dans /tmp, et les exécuter de manière transparente.

0 votes

La réponse acceptée est d'utiliser le SHC comme ci-dessous : stackoverflow.com/questions/6423007/

0 votes

@therobyouknow, la réponse acceptée concernant le SHC ne prend pas en charge le regroupement dans d'autres exécutables, ce qui, selon votre question, est une exigence.

0 votes

"SHC ne supporte pas le regroupement dans d'autres exécutables". Je vous crois sur parole, bien sûr, mais il n'est pas nécessaire de l'intégrer dans d'autres exécutables - si le résultat de SHC est du pur code C, alors ce code C peut être compilé, lié et construit à l'aide d'outils standard qui peuvent être utilisés par les utilisateurs. hacer soutenir le regroupement ( ?)

5voto

Vous pouvez obscurcir les scripts shell avec quelque chose comme ofbsh . Vous ne pourrez pas facilement regrouper d'autres programmes dans un seul exécutable pour unix, cependant. Normalement, l'approche pour l'installation serait de créer un paquetage pour le gestionnaire de paquets de votre plateforme (par ex. rpm, deb, pkg ) ou de fournir une archive à démêler dans le répertoire approprié.

Si vous avez besoin d'un fichier exécutable qui décompresse le contenu, vous pouvez utiliser une archive shell. Jetez un coup d'œil à la documentation de shar(1) et voir si cela vous permet d'obtenir ce que vous voulez

Si vous avez vraiment besoin d'une capacité de script pour coller plusieurs programmes C ensemble, jetez un coup d'œil au langage Tcl. Il possède une API conçue pour envelopper de manière triviale les programmes C qui s'attendent à voir argv[] paramètres de style. Vous pouvez même intégrer les morceaux de code C dans un interpréteur Tcl personnalisé et le coller avec divers scripts Tcl.

Si vous avez vraiment besoin de le rendre opaque, vous pouvez crypter les scripts tcl et envelopper le tout dans quelque chose qui décrypte les scripts tcl dans un tampon et exécute ensuite l'interpréteur Tcl sur ceux-ci. Tcl peut accepter des scripts à partir d'un fichier ou d'un fichier char* pour que les scripts non chiffrés n'aient jamais à atteindre le système de fichiers.

0 votes

Je préférerais quelque chose de simple sans avoir besoin d'un gestionnaire de paquets car 1) je ne peux pas compter sur les connaissances du client pour réaliser de telles instructions et 2) je ne peux pas compter sur les politiques régissant leurs machines concernant l'installation de paquets (et même de tiers). L'approche préférée la plus simple est de pouvoir compiler en code machine correct un seul exécutable qui fonctionnera sans aucune dépendance.

0 votes

+1 Pour ofbsh, cela pourrait être utile dans certains cas. Bien que cela puisse nuire à la perception du client si le code semble illisible, le client peut peut-être s'inquiéter des problèmes de qualité, à moins qu'on lui explique que le code est délibérément obscurci pour qu'il ne puisse pas le comprendre - ce qui n'aide pas nécessairement à construire une relation basée sur la confiance si nous essayons de cacher des choses à un client tiers payant.

0 votes

Il vaut mieux donner un exécutable dès le départ, ce qui élimine tout souci de dissimulation, c'est probablement ce que le client attend de toute façon et cela ne donne aucune indication sur la façon dont le logiciel est mis en œuvre. Personne n'aura l'impression que des choses lui sont cachées si un simple exécutable est proposé.

4voto

Jahid Points 12756

shc

J'ai modifié l'original source et mis à jour vers une nouvelle version avec quelques ajouts de fonctionnalités et corrections de bugs. C'est aquí .

Exemple d'utilisation :

shc -f script.sh -o binary_name

script.sh sera compilé dans un binaire nommé nom_binaire

Notez que le shell requis doit être installé sur votre système pour exécuter cet exécutable.

2voto

vdm Points 21

arx est un excellent bundler, et vous pourrez peut-être intégrer un obfuscateur dans son flux de travail.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X