Web Analytics Made Easy - Statcounter

PowerShell (.ps1) Script Upload


What is OnDemand obfuscation?

  1. It is a badly needed option that we should have provided much earlier than we did, apparently
    • It is a pay-as-you-go plan that allows you to avoid paying the month based prices
      • Instead of the $49.95 per month, you get to choose from these 3 cheaper plans:
        1. 1-Day Access / 1.Script.Submission / 15.resubmissions / Expires in 24.hours
        2. 2-Day Access / 5.Script.Submission / 50.resubmissions / Expires in 48.hours
        3. 3-Day Access / 10.Script.Submission / 100.resubmissions / Expires in 72.hours
    • For more information, or to make a purchase, you may visit this link OnDemand Options.
      • Please note however, as of right now (April 3rd, 2024), OnDemand plans are currently only available for 4 languages...
        1. Rcode/RMD
        2. Shell/Bash
        3. PowerShell
        4. Python
      • We'll add more languages based on...well, demand :)

For a seamless obfuscation of powershell scripts, please note the following:

  1. Ensure all submitted powershell scripts are appropriately named:
    • Uploaded powershell scripts must have the appropriate .ps1 extension:
      • my_fantastic_script.ps1
    • Avoid spaces in the names of your scripts:
      • my fantastic script.ps1
  2. When the "Obfuscate Now" button is clicked, be aware of the following:
    • You will be automatically re-directed to the download page for freshly obfuscated .ps1 scripts
      • The obfuscated powershell script(s) will be in a zip file, under the link titled "PACKAGED".

NOTE: All obfuscated powershell scripts generated on this page are expected to work exactly as ther originals and on any Windows OS.

For subscribers:

In the space provided for User List, specify a comma seperated list of usernames you wish to grant execute access to your obfuscated powershell scripts. Note, the specified username(s) will be the only usernames allowed to run/use/execute your obfuscated powershell script(s). The scripts will not function for any other user!

For subscribers:

In the space provided for Host List, specify a comma seperated list of hostnames(fqdns) you wish to grant permission to execute your obfuscated powershell scripts. Note, the hostname(s) you specify will be the only hosts on which your obfuscated powershell script(s) will be allowed to run. The script(s) will not function on any other host!

In the space provided, specify when you wish for your script to expire.


    • 7d = 7 Days
    • 2w = 2 Weeks
    • 4mo = 4 Months
    • 7000d = 19+ Years
    • July-18-2023_15:00 = Specific date

If no option is selected, the default option will be "off". Which means your script will not expire!

In the space provided for Function names, specify the comma seperated list of functions you wish to protect, if using RStudio/Rconsole.

Choose 'no' (recommended) to disable the ability to debug your encrypted script

This setting forces your protected powershell script to validate itself with our servers before allowing users to run it.

  • NOTE: If an attempt is made to run a satelite enabled obfuscated powershell script on a host without internet connectivity, the script will abort.
    • Enabling this setting means the obfuscated script may collect information about the system on which it is executed.
      • Collection of details is automatically enabled whenever an unususal activity is detected against the execution of the protected code.

For subscribers:

To restrict your scripts so that they can only be imported from other encrypted scripts, configure the following settings:

    Previously available only for Python scripts but now available for Powershell scripts as well

    • Unique Company Name = Set this to your companyname....(.i.e. apple.com, google.com, cnn.com)
    • Import Access Key = Set a password here to be assigned to all scripts being encrypted
      • Note, this is only needed if Admin Imports and Allowed Importers have values. Do not enter anything here if you're not encrypting imported modules
    • Admin Imports = Specify the names of the main/master scripts which will be importing other scripts
    • Allowed Importers = Specify here the names of other scripts which the main/master scripts will be importing

PowerShell Obfuscator - Obfuscate any PowerShell Script

The complexity of your .ps1 Powershell script does not matter. At all.

Any powershell script obfuscated by AtShai.com/EnScrypt.io should be expected to work exactly as the original. If your original plain text powershell script has bugs in it, then yes, the obfuscated version will also have bugs. Therefore, we strongly recommend confirming the plain text powershell script you're uploading actually works.

We are very confident our Powershell obfuscator can thoroughly obfuscate any powershell script given to it and we welcome you to test and confirm for yourself. If your obfuscated powershell script is unable to execute for some odd reason, there's no need panic or feel dejected (we actually understand). Just notify us immediately so we can address it.

Yes. Your obfuscated powershell code will work wherever its plain text version has been confirmed to work on. The powershell version and the windows version does not matter.

If you do encounter a system on which the obfuscated powershell script is not working (and its plain text version does), let us know immediately. We'll update our online powershell obfuscator to accommodate that system.
No. The obfuscated version of your powershell (.ps1) script will behave exactly as the original. No addons or special modules will be needed to execute it.

All functionalities available in the plain text version of the powershell script will also be available in the obfuscated version.

Protect PowerShell Script Source Code

All .ps1 Powershell scripts uploaded through this free portal will have some strict security settings enabled by default.

Default Security Features

  1. Duplication Prevention
    • This feature ensures the name you gave to your obfuscated powershell script at the time of obfuscation is the name it will be forever known by. If changed, the obfuscated powershell script will abort execution
  2. Expiration Date Control
    • This setting ensures all submitted powershell scripts expire within 24 to 48 hours. The allowed time is verified remotely, with our servers. This means we will be notified of all unauthorized attempts to prolong the usage of the obfuscated powershell code.
  3. Self-Defend/Self-Destruction
    • This feature handles the process of terminating the execution of a protected script whenever it is under attack. We understand once an obfuscated powershell script is sent out into the world, anyone can try all sorts of hacks on it. As such, we built in some self-defense capabilities in all obfuscated powershell scripts. If during execution of a protected powershell script, we sense that it has been maliciously altered, we will cause the script to abort, and self destruct!

  1. Although the powershell protection features listed here are indeed advanced and do protect your powershell code as described, from our perspective, they should still be considered basic.
    • In order to ensure that the trial version of an obfuscated powershell code works for everyone, we stripped out most of stringent protection in it. They can be added back, if needed.
    • There are many, many more features that can be added or enabled which will further enhance the security of your code, but some may not be necessary. Each client is different.
      • Just reach out to us to start a conversation on what your requirements are and we'll advise you on the options available and the way forward.
Yes. All paid customers are allowed to specify expiration dates (among other settings) and also configure how their protected powershell script should behave in the event of an attempted hack attack.
We are different in a number of ways. We'll name a few common ones.

  1. First, we are the one and only PowerShell Obfuscator available. With our obfuscation, developers can retain control of their source code, regardless of where it is.

  2. The AtShai Powershell Obfuscator converts plain text powershell code, in its entirety, into an obscured format that bears no resemblance to the original plain text version. Yes, we do much more than just scramble variable names.
    • In addition to our thorough powershell code obfuscation, we also provide mechanism through which users can track where in the world their intellectual property (i.e. scripts) is being utilized.
      • Yes, our obfuscation tool will obfuscate any powershell script and will also allow you, the developer, to remotely disable or enable an obfuscated script, if the appropriate setting is enabled during the obfuscation process.

  3. We require no addons. Yes, you can very easily obfuscate any powershell script and immediately begin using it without needing to install modules or download addons.

Powershell Code Security - Hardcoding passwords in plain text scripts | Why? Why not?

News Report: (September, 2022) Uber hack made possible through MFA and hardcoded credentials in Powershell script

There was a relatively recent hack that occurred at Uber back in September of 2022. This was of course embarassing for the company, as it would be for any other company. The problem they had was a common one. The admin password was hardcoded in a powershell script. The hacker discovered this plain text script and subsequently obtained privileged credentials through it, and with that, was able to intrude into restricted areas. Clearly, this should be considered a derelict of ones duty on the part of the administrator. Correct?

Well, before we judge the system administrator in this case, let us examine the possible reasons he might have had to justify putting credentials in a plain text script.

The first obvious reason would be for convenience. Yes, there are options available that can be utilized to protect credentials in a script

  1. Generally, these options will require that your script initiate a network connection to retrieve the encrypted credentials
    • While this might seem straight forward to some, there are some drawbacks.
      • This method introduces an extra layer of complication into a process that was originally simple.
        • What happens if that extra layer goes offline?
          • Your script won't work.
          • You would be at the mercy of the connection between your host and that external layer

  2. Other methods include downloading and installing packages that aren't native to the language your script is written in (powershell in this case)
    • Again, while this may not seem like a big deal to the uninitiated, it does have its problems.
      • If you were to upgrade your operating system, there is the real possibility that the new OS version will be incompatible with your custom packages.
        • And if you try to download **new or updated versions** of the packages, you may find out the original links no longer exists.
          • And the rabbit holes that can result from this are painfully numerous.

So I ask again, what are the likeliest reasons the administrator at Uber hardcoded passwords in their script?

  1. Because it was simply the easiest thing to do.
    • So is he lazy? No. I wouldn't make such an accusation. Neither should you.
    • It is likely that, when he (the administrator) considered the totality of the day to day work he was responsible for, taking that extra 30 minutes to an hour (probably longer) to find and implement a reliable solution was just too much.

  2. Can we blame him?
    • You can. But that would be unfair....considering what happened to him can happen to most of us in similar scenarios. Let's be frank.
      • If you think it could never happen to you, that's probably because you dont write enough number of scripts for it to be an issue.

So how does atshai.com solve this problem?

  1. First, we do the obvious. We convert your plain text code into an unreadable text

  2. We provide various types of restrictions to apply to your script.

    • Aggressive protection - Cause the protected powershell script to self destruct when it detects suspicious behavior

    • Time ranges - Specify what time period your script is allowed or expected to run in.

    • Host list - Specify a list of hosts on which your powershell script is allowed to run

    • User list - Specify the usernames/accounts that are authorized to execute the powershell script

    • Tamper Resistance - The first thing hackers will attempt to do when in possession of an obfuscated script, is try to alter it

      • When that happens, you can be sure the protected powershell code will self-abort.
      • There was a time they said it is not possible for a script to validate itself against unauthorized modifications

        • We clearly defeated that hurdle. We incarnated an inspiration and materialized it in the world of reality.
    • Remote code monitoring - Enable remote monitoring during obfuscation of the powershell script

      • This essentially means your obfuscated powershell script will be mandated to:
        • Remotely validate itself with either us (enscrypt.io/atshai.com) OR
        • An internal webserver in your environment

      • If your protected powershell script is unable to validate itself at all, for any reason, it will abort and notifications will be sent out.
        • Additionally, all associated dashboards will light up RED and will stay RED!

  3. When all or some of the aforementioned restrictions are applied to a powershell script, you can rest assured your .ps1 code is safer than the alternative options.
  4. We provide barriers and fortifications between the sensitive data in your powershell code and the outside world.

Some may ask, what happens if our powershell obfuscation can be easily broken?

    First, it is not easily broken. But let us assume just for the sake of argument, that it is easily broken. Then what?

    • Well, an attacker would first need to read through the obfuscated powershell script to understand what it does.

      • A process that will NOT be completed within a few minutes or hours, or days or weeks.

    • OK, Another scenario. Let's assume the attacker does manage to get a general idea of what our obfuscation does. What then?

      • If he is arrogant and thinks he knows all, he will make the mistake of actually running the script on his own machine. and when he does this, a signal will be sent to us and it will be registered on a dashboard and alerts sent out to whoever needs to know about the incident.

        • Note however, this particular protection is activated ONLY if the powershell script was obfuscated with remote monitoring enabled.

      • Well, what happens if the hacker runs the code on a standalone system that isn't connected to the web?

        • If the powershell script was obfuscated with remote monitoring enabled...the script will NOT function.

        • It can even self destruct, if you really wish to make things as difficult as possible for a hacker.

When it comes to protecting powershell scripts, one thing is for certain, hackers will never be able to modify an atshai.com protected code, and expect it to behave normally with their foreign changes.

    • In contrast, if a hacker gets a hold of an unprotected plain text powershell script (as was the case at Uber), all he has to do is read through it, make some changes to it, remove or add custom lines of code. And thats it.
      • He will be able get the script to operate how he wants.

      • BUT, if that same hacker gets a hold of an atshai.com obfuscated code, modifying it will only render the script unusable, corrupted...And can self destruct when confronted with unexpected conditions.

      • NOTE, self destruction of a protected powershell script activates only IF 'aggresive protection' was enabled during the obfuscation process

So how is the atshai obfuscation better than existing methods of code protection?

  • We take your plain text powershell scripts and obfuscate them AS THEY ARE

    • We do NOT require you to do anything to your scripts. Only submit them and that's it. You can go with your life.

  • We do not require 3rd party packages (packages that arent native to powershell or windows)

  • We give you the option to choose between remote monitoring or local monitoring, or no monitoring.

  • We provide dashboards to help you keep tabs on the health of your scripts

    • Health meaning; the visualization of all records of attempts to execute, modify or tamper with your code - know when your code is executed in conditions outside of the ones you defined.

The most common discouraging comment often lunged at those of us who dare to endeavor to protect code is..."whatever you do can be undone by a determined hacker".

    Our response to that is this:

    • Case scenario:

      • Suppose a hacker gets a hold of an atshai.com protected powershell script and manages to crack it.

      • We find out about this, and decide to accost the hacker with a question: Hey Mr./Mrs. GeniusHacker, can you tell us precisely what you did to crack it?

        • The response given to this humble question is often eye-opening.

          • The hacker can only respond to it in 2 or 3 ways:

            • 1) Sure, this is what I did. **proceeds to list the steps he/she followed**

            • 2) Nope, not going to tell you !

            • 3) **Reveals only partial information, not the full steps performed**

          • A hacker who leans towards #2 and #3, is unwittingly making a statement and admission, which essentially boils down to...I AM WORRIED IF I SHOWED YOU HOW I HACKED YOUR OBFUSCATION, YOU WILL BLOCK THE LOOPHOLE

            • And my friends, that statement would be correct!

            • But then, one has to wonder...why is Mr./Mrs. GeniusHacker worried? Any obfuscation can be undone by a determined professional? Right??

          • See, the reality is, we are not going to run out of ideas on how to protect code nor are we going to get tired of it. But, we know those who are convinced of the impossibility of code protection will eventually deplete their arsenal of tricks.

            • We are certain, if there are ways to crack our obfuscation, they will become useless the day we find out about them. Counter measures will always be rapidly developed to null all loopholes.

Finally, we believe when the cynics and critics go as far as to publicly deprecate (put down) the impact of obfuscation as a useful technique in protecting code, it is important you understand they have their own agenda. A bonafide way of protecting code spells disaster for them.

  • They need code to be in plain text, under the guise of open source...because they glean a lot of their ideas for commercial products from those open source plain text scripts

  • You can often get a whiff of their intent by examining the arguments they put up in opposition to code protection. Their argument is that any obfuscation can be undone by a determined, seasoned professional, therefore, dont even bother with it.

    • By that shockingly superficial logic, it is absolutely unnecessary to roll up the windows in your car when you park it on the street.

    • You should leave the doors to your house unlocked. After all, doors can be easily broken into, right? Windows can be easily shattered, right?

  • Conveniently, they ignore the fact that obfuscation of code, by definition, buys you a lot of time...more time than the alternative plain text option.

Above all else, there was a time developers relied only on system privileges, settings and file permissions to help manage or restrict access to their scripts. That is no longer the case today, in the year 2023. AtShai.com has invented a code protection mechanism capable of barricading plain text code from public view so that any random person who gets a hold of it will be unable to reverse engineer it to make it behave in a way it wasn't intended to.


Register/Login to begin Uploading & Obfuscating Powershell (.ps1) scripts