Frequently Asked Questions

Yes, and the Encryption tool itself is encrypted. Which means, no one gets to see how it works.

You'll be licensed to use it on your own private hosts for a specific period of time. And after that period of time expires, the Encryption tool will no longer work. However, the scripts that were encrypted with the Encryption tool during the period when the Encryption tool license was valid, will continue to work for as long as they were configured to be.

To renew your license for the Encryption tool so you can continue to protect additional scripts, visit the home page or click any of the green boxed options to the right of this page for a (30-Day) License.

All of our Encryption tools (Shell, Perl, Ruby, Python, Nodejs, Php and Rcode) allow you to:

  1. Encrypt and Obfuscate as many scripts as you want from the command line
    • - All you really have to do is run one simple command, with arguments passed to it
  2. Avoid having to copy and paste sensitive scripts to an external website
    • - Sensitive scripts can be:
        - Any script with usernames and passwords stored in it - Any script containing proprietary information you don't want to make public
  3. Set expiration dates on all scripts encrypted
    • - Expiration dates prevent the usage of your scripts after a predetermined time
        - You can set your protected scripts to auto self destruct upon expiration
  4. Encrypt the same file or script each time it is updated
  5. Be able to use your encrypted scripts on most UNIX OSes
    • - This portability ensures you never have to require your users to compile a script for any specific OS
        - Works on Linux, AIX, MacOS & Android
  6. Get email notifications whenever attempts are made to modify or make copies of your script
  7. Encrypt and obfuscate not just shell scripts but ruby, perl, python, command line nodejs and php scripts as well
  8. Encrypt multiple scripts and files with a simple one liner and a list file
    • - Avoid time consuming or complicated procedural steps! - Encrypt multiple scripts at once, using our newly developed menu driven interface
  9. Free Support: Reach out to us at [ ] if you require technical assistance
  10. Restrict the usage of your scripts to specific users
    • - Ensure even root can't run a script owned by you! - Give only a specific list of users access to use your scripts - Get alert notifications whenever an unauthorized user attempts to use your scripts
      -We will generate the notifications on all attempted nefarious activities
  11. Limit the usage of your scripts to specific hosts / servers
    • - Ensure even if your script gets in the hands of the wrong people, they wont be able to run it if they're not on the right host.
To distribute an encrypted script to different hosts without having to re-install it, please review the simple steps listed below:

  1. Encrypt the script you wish to protect on your master host - (the master host is where you do all your encryptions!)
  2. Unzip the newly encrypted script from step 1
  3. cd to, then run the Encrypted script
    • The first run of the encrypted script will cause it to auto-morph into a standalone version.
  4. Now you can distribute the script to different hosts
    • ubuntu@ip-$ scp jbowman@
      ubuntu@ip-$ ssh jbowman@
      ubuntu@ip-$ ./
        Usage: {start|stop|graceful-stop|restart|reload|force-reload|start-htcacheclean|stop-htcacheclean}
  1. Credit Card (Visa/Mastercard/Maestro-Laser/Amex)
  2. Paypal (Discover cards are accepted by Paypal)
  3. EUR/USD Cheque/Check
  4. Wire/Bank Transfer
    I have a script that I want to give to a friend. I don't want them to have access to the code, just the functionality. If I buy the 30 day license does that mean the script I send him will stop working after 30 days?

    No. The 30 day license allows you to encrypt as many scripts as you want for a period of 30 days. During those 30 days, you can set the expiration date of your scripts to be as long or short as you need them to be.

    After the 30 days have expired, the scripts you encrypted during the time when the license was valid, will continue to work for as long as you configured them to be. Only thing is, you will not be able to encrypt any additional scripts after the 30 day license has expired.

    For example; you can encrypt a script today and set the expiration date of the script to be 400 days from now. However, 31 days from now, if you try to encrypt another script or the same script again, you wont be able to. The script you encrypted previously that was set to expire 400 days from now, will continue to work until those 400 days have passed.
Upon payment verification, we will immediately generate the latest version of the Encryption tool for you and will send you the download link. Unless requested otherwise, the download link will be sent to the email address of the account that payment was made with.
No. You do not need to encrypt the scripts on the server or host they will run on. There's no need to encrypt your scripts for each OS.

You can encrypt a script on any Mac, Ubuntu or Red Hat system and then be able to run the encrypted script on other Unix systems. So far, scripts that were encrypted by us have been tested and verified to work on Ubuntu, Red Hat, Cent OS, AIX and Embedded (watered-down) Unix systems...i.e. busybox or Android.

If you need to run an encrypted script on any specific version of Unix, no matter how unique it is, we will work with you to get it working for that version.
1. wget(or curl -O)
2. unzip the-zip-file-of-your-encrypted-script
3. cd
4. ./ (replace this with your script name)
    - the first run of your encrypted script will set it up for you
5. ./
    - after the previous first run of your script, you can now begin using it as normal
Contact Us if you encounter any issues while attempting to run your encrypted script.

What is a menu driven / interactive script? An example of such a script would be any script that waits for a response:

    What is your name?
    Do you wish to proceed (y/n)?

Notice how the above prompts are waiting on the user for a response?

Here's how your interactive script should look if it is to be encrypted:

      Example A
          echo "Hello there"
          echo -e "What is your first name?" > /dev/tty
          read x < /dev/tty
          echo $x
          echo "What is your last name?" > /dev/tty
          read y < /dev/tty
          echo "Your name is $x $y"

      Example B
          echo -n "How many random numbers do you want to generate? " > /dev/tty
          read max < /dev/tty
          for (( start = 1; start <= $max; start++ ))
          echo -e $RANDOM
Basically, you have to direct all questions being asked in your script to > /dev/tty.

Then, when you go to read the response provided by the user, you read from the same tty as before, with the < /dev/tty.
Contact us at [ ] if you need additional help.
There are 4 reasons an encrypted script wouldn't work:

  1. If the script is an interactive script and wasn't named properly or edited correctly.
    • - To resolve this, please refer to Help A.(above) and follow the instructions laid out in it.

  2. If the encrypted script is run in an unusual way
    • i.e:
    • sh ./(encrypted-script)
    • instead of

    • ./(encrypted-script)
      • There's no need to put a "sh" or "bash" or anything else before the script when running it.

  3. If the first line of your script does not contain the absolute path to the necessary intepreter.
    • i.e:
    • #!/bin/sh
    • #!/bin/bash
    • #...perl, ruby, python...etc??

  4. A deliberate attempt was made to tamper with the encrypted script in order to figure out how it works.
    • We are quite aware that our encryption methodology is unique and there is absolutely nothing like it anywhere else on the internet. For this reason, there will be those who intentionally try to break it apart in order to replicate it or for some other nefarious reason.
    • To successfully combat this, we have included sensitivity checks in all scripts encrypted by us. What that means is, whenever our encryption mechanism detects that a user is attempting to do things with an encrypted script that he shouldn't be doing, we will automatically cause the encrypted script to self destruct.
    • We take the security of every script encrypted with us very seriously and we do not tolerate any hack attempts to figure out how it works.

    If your script self-destructs, the only way to get it working again is to re-unzip the zip package and re-install it.
Contact us at [ ] if you need additional help. In your email, make sure to provide a copy and paste of all the steps (and their results) that you performed.

If your script was designed to work on embedded or android systems, all you have to do is specify "embedded" or "android" when encrypting it from the command line.

Review the following examples for references to the different ways scripts can be encrypted for use on specific systems.

Example (scripts to be used on regular Unix systems):
    root@virtual# ./ lcs autogenerate 2d customer /home/jbowman/

Example (scripts to be used only on Android Unix systems):
    root@virtual# ./ lcs android-rb 2d customer /home/jbowman/

Example (scripts to be used only on other systems):
    root@virtual# ./ lcs embedded 2d customer /home/jbowman/
Then copy/scp the bolded encrypted zip file to the system or device you intend to use it on.
Individual Option: This option allows you to encrypt one script at a time. You can encrypt as many scripts as you want, however, they'll need to be encrypted one by one, after each other.

Enterprise Option: This option allows for the encryption of large quantities of scripts. For instance, if you wish to encrypt multiple scripts at a time without having to manually encrypt them all from the command line, this is the option for you. Additionally, with the enterprise option, you can choose to put all your protected scripts into one zip or tar file, thereby making it quite convenient to deliver or distribute to clients.

  • When a client gets the zip or tar file, all that he/she will need to do is simply run the automated script (which is included in all packaged zip/tar files), specify the path to install the scripts (as a parameter) and that's it. The automation script will take over from that point and will proceed to set everything in place, all in under 30 seconds.
Detailed instructions on how to encrypt a script is included in the encryption package.

If you need to view the encryption process before making a payment, please refer to the following:

## ./ lcs autogenerate 375d customer /home/jserver/MIGRATE/

SUCCESS: Code has been successfully generated!
    adding: KingLazySHIELD/README.lcs (deflated 63%) adding: KingLazySHIELD/building.sec (deflated 24%) adding: KingLazySHIELD/ (stored 0%) adding: KingLazySHIELD/ (deflated 87%) adding: KingLazySHIELD/ (deflated 20%) adding: KingLazySHIELD/license.lcs (stored 0%) adding: KingLazySHIELD/ (stored 0%) adding: KingLazySHIELD/ (deflated 16%) adding: KingLazySHIELD/stabling.sec (deflated 24%)

SUCCESS: Updated [ /var/tmp/ ]. Expiration time = [ 1510240090 ( Thu Nov 9 07:08:10 PST 2017 ) ]. Customer Name = [ ]. Customer ID = [ 38700212630710300808102016 ].

To begin using your encrypted script, simply unzip the generated zip file [ ], change directory to the directory, then run the script: './<your-script>'.

The first run of your encrypted script after unzipping it will set it up on the system you're running it on.

During encryption, here are the parameters to change for your specific requirements:

375d = This is where you specify how long the script to be encrypted should be valid for. To specify minutes, hours, weeks or months, replace the 'd'

  • 30m = 30 minutes
  • 3h = 3 hours
  • 3d = 3 days
  • 3w = 3 weeks
  • 3mo = 3 months = Replace this email address with yours

/home/jserver/MIGRATE/ = Specify the absolute path of the script you wish to encrypt
Yes it is safe to install an encrypted script and no, it will not affect anything on your system. Our installation procedures DO NOT involve tampering with any configurations, libraries or modules that may already exist on your system.

Our installation mechanism is simple and what it basically does is, through the use of an automated script, it puts the configuration files of your encrypted script in the appropriate place, which would be /var/tmp/<>.

To 'Uninstall' the encrypted script and its configurations from your host, see below -

    • Example 1:
      • To remove an encrypted script called '' from your host, you would run:
          rm -rf /var/tmp/
          rm <path-to-the-symlink-that-points-to-the-script-directory>

    • Example 2:
      • If you have multiple encrypted scripts under '/var/tmp/', you could run:
          rm -rf /var/tmp/*
Yes you can. Under the Enterprise option, we have an automated, menu driven tool that allows users to complete the encryption and obfuscation of several scripts within seconds.

Click the link below to view a screenshot of this tool:

Yes, this tool comes with all of our Enterprise encryption packages (shell, perl, python, php, ruby, rcode, nodejs).
Yes. After encryption, you can expect your script to behave exactly as it was before it was encrypted. Only difference will be, after encryption, no one will be able to view the actual code.

In other words, if your script was accepting arguments before you encrypted it, you can expect it to continue to accept arguments after encryption. Also, all exit codes remain the same. Meaning, whichever exit codes your script was originally programmed to exit in, will remain in tact. No surprises.
No. Once encrypted, it cannot be decrypted. We recommend creating backups of your original un-encrypted script.

During encryption, utilize the "-d" option to specify where the script should install itself whenever it is run for the first time on a host.

Feel free to contact us at [ ] if you need additional clarifications.
Currently, our encryption algorithm can be used to protect shell, perl, ruby, python, rcode, command line nodejs and php scripts. Those were the most commonly requested languages for encryption.

If the script you wish to encrypt and obfuscate is written in a different unlisted language, no worries. Feel free to contact us at [ ] and provide the following information:

    • The name of the interpreted language your script is written in
    • A sample code written in this interpreted language
    • How you normally go about running the script from the command line
    • The Unix OS(es) you intend to run the protected/encrypted scripts on
Please note, as of right now, our encryption method is designed and built only for Unix systems.
  1. Date Management - Assign expiration dates to your scripts
  2. License Management - Regulate the redistribution of all your scripts
  3. User Management - Restrict usage of your scripts to specific Users
  4. Host Management - Restrict usage of your scripts to specific Hosts
  5. Duplication Prevention - Prevent multiple copies of your scripts on a system
  6. Instance Management - Restrict simultaneous or multiple running instances of your scripts
  7. Tamper Resistance - Auto self-destructs whenever a user tries to figure out how it works
    • a) Ensures an encrypted script does not function if it detects that a necessary tool on the system has been altered
          Some users may build a modified version of a binary and then try to use that version to investigate our encryption/obfuscation algorithm.
            - The tamper resistance feature will detect this and will stop the script from working!
      b) Ensures that a protected script never works if the user is doing anything other than running it.
        - There are many interesting ways users can attempt to break a protected script.
        • We monitor for this and we block them at every turn.
      c) Ensures it is impossible for any user to modify a protected script
  8. Access Management - Remotely turn off ability to continue using your script if user is found to be in violation of licensing terms.
    1. Some users have nefarious intentions when they purchase online software. After purchasing a software, these users typically request a refund immediately after. And after the refund is given, they continue to use the software.
      • puts an end to this. Our customers have the option to make their script require internet connectivity.
          • If a customer opts to make her script require internet connection, then users of the script will NOT be able to run the script if they're not connected to the internet.
              - This provides script owners control of their commercial scripts in case a user misbehaves.
  9. Report Generator - Get color coded excel spreadsheets detailing where your script(s) are being used.
    • a). Know when your script is being illegally used
      • If your script was meant to be used at the office in San Francisco but you find out it is now being used in France as well, you might want to know how that happened.

Yes. We offer a 90-Day Money Back Guarantee. Refunds will be granted under two scenarios:

    • If request was submitted within 60 days of purchase OR
    • If you are actually able to successfully unlock any of our encrypted scripts in under 90 days.
      • Under this scenario, to qualify for the refund, we'll need to see proof.
Contact us at [ ] if you have any questions.
There are no chances of that ever happening! If you are actually able to break into the encrypted script we generate for you, feel free to request a refund. We'll gladly give it to you.
Yes, it is extremely easy to do. The Menu Driven Shell Script Encryption Automation that comes with our Enterprise encryption packages, is designed to shield customers from the very technical aspect of the encryption and obfuscation process.

Through the menu driven interface, you can choose to encrypt multiple scripts specified in either a list file or a directory of scripts. The encrypted scripts will be packaged into one zip file or tar file, which you can then give to your customers.

When your customer receives the zip or tar file, all that they'll need to do is unzip or untar the package, and run one simple script to set up the encrypted scripts enclosed in it.
Of course you can. Click on the first box on right column, and copy and paste your code to the space provided to generate an encrypted copy.

Again, if you can actually break into the encrypted script we produce for you, then just don't buy the tool, and if you've already bought it, feel free to request a refund.

Also, please note, when you copy and paste or upload your script to our website, you only need to click the "Submit" button once. It'll take under 5 seconds for the encrypted copy of your plain script to be generated.
Yes. Along with other security measures, we allow users to specify how long a script is to be valid for. After the user specified date, the script will no longer function!
As many as you want. Please note, every script you encrypt using our free web-based service will expire within a few hours of creation.
To encrypt unlimited scripts and to be able to specify expiration dates on each of those scripts, you'll need to purchase a licensed version of our Encryption tool.
  1. Protect sensitive information and intellectual property
  2. Eliminate the ability of others to keep tabs on you, if you work in a lab-like environment where everyone has root access
      - Our encryption tool ensures even those with root privileges cant view your scripts
  3. Hide passwords that you don't want to make easy for anyone to have access to
  4. Sell your scripts to a third party without giving away any proprietary information
  5. Get alert notifications - Create clandestine records of all attempts of theft by users of your scripts
      - Our encryption tool ensures even those with root privileges cant view your scripts
      • Every single script that is obfuscated and encrypted by is protected under the premise that those who run the scripts are simply to run it. When a user of an encrypted script starts trying to break it apart in an effort to see how it works, a record of each attempt will be logged.
        • - This record can then be used (by the script owner) as evidence in a court of law if necessary.
Yes. We can encrypt Shell Scripts, Perl Scripts, Ruby Scripts, Python Scripts, Command line NodeJs and PHP Scripts and RScripts (rcode). You can paste any of these scripts on our home page so you get a feel for how our encryption/obfuscation works.
All scripts that are encrypted through either the 'Upload' or 'Copy and Paste' options provided on the home page are valid for a few hours.

To extend the expiration date of your scripts beyond a few hours, you'll need to purchase a licensed standalone version of the encryption tool of your choice.

Flexible License Terms:

With our one time, monthly, quaterly, bi-yearly and yearly payment options, you can get the exact Encryption software you need for as long as you need it without making a big up-front investment. Payments are not recurring. You only make a payment when you need the tool.
You can:

Purchase and download your own personalized (and encrypted) version of our Encryption tool
  • This option will enable you to avoid submitting any extremely sensitive scripts to our website
    • It allows you to encrypt as many scripts as you need, right from your own private host.

Contact us at [ ] for more information or other options.
Here are your realistic options:

  1. Rely on permissions/ownership as your only means of protection
  2. Use a compilation / obfuscation method everyone on the internet knows about, which makes your scripts likely to be more hackable!
  3. Or use our unique encryption algorithm that ensures no one can easily unveil your protected code
Yes. However, currently, we can only encrypt standalone nodejs scripts - meaning, all the values your nodejs script needs to run must be hard-coded in the script already. The nodejs script should not be accepting any input from users. If your script must accept arguments, make it read from a config file instead, a config file that the person running the script would have to update.

We are currently working on a process that will allow for the direct passing of arguments and parameters to an encrypted nodejs script. As of this writing (March 21st, 2017), that project is still in progress.
There are quite a number of different ways a determined hacker can take to attempt to hack a protected script. One of such ways is altering the binary files of the programming language your script is written in. is aware of these types of tactics and steps have been taken to combat them effectively.

Whenever an protected script is run on any Unix system, it does a variety of checks simulteneously. These checks confirm the validity of all necessary tools needed to run the protected script. If the algorithm senses any of the critical tools it needs have been tampered with or simply aren't in the state it expects them to be in, it will refuse to run the protected script and will abort immediately.

If you're not trying to hack the script, or figure out how our algorithm works, feel free to shoot us an email. In your email, please provide a copy and paste of the exact error messages you encountered and the name of Unix OS your script was run on.
Yes. Your encrypted scripts can run under Android systems. During encryption of the scripts, simply specify "android-rb" instead of "autogenerate" at the command line. To run an encrypted script on an android machine, you can utilize the apps known as "Terminal Emulator" and/or "Root Browser".