PowerShell (.ps1) Script Upload
For a seamless obfuscation of powershell scripts, please note the following:
- Ensure all submitted powershell scripts are appropriately named:
- Uploaded powershell scripts must have the appropriate .ps1 extension:
- Avoid spaces in the names of your scripts:
- my fantastic script.ps1
- 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.
- If you encounter a system on which your obfuscated powershell script fails to execute, let us know immediately.
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!
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
- 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.
To restrict your scripts so that they can only be imported from other encrypted scripts, configure the following settings:
- 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
Previously available only for Python scripts but now available for Powershell scripts as well
PowerShell Obfuscator - Obfuscate any PowerShell Script
Protect PowerShell Script Source Code
- 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
- 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.
- 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!
- 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.
- 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.
- 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.
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
- 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
- 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?
- 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.
- 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?
- First, we do the obvious. We convert your plain text code into an unreadable text
- 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!
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.
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:
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.
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.
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.
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.