You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there's a very small chance any given outputted payload will be able to be sourced. This is due to a few things. First, the 'eval wrapping' that Bashfuscator applies automatically to almost every layer. Bashfuscator does this because the results of each layer needs to be passed back, in order for the outputted payload to deobfuscate and run it's obfuscated input. There are 2 eval wrappers currently, and they are randomly chosen:
eval "$(OBFUSCATED_CODE)"
printf %s "$(OBFUSCATED_CODE)" | bash
When the first option is used, generated payloads can be sourced successfully. For example, if you generated a payload obfuscated with one layer and it used the first eval wrapper described above, the payload will be able to be sourced. So an easy solution is just to create an CLI option that forces the use of the first eval wrapper.
The only problem with that is some Mutators don't require eval wrapping, as they do similar functionality themselves. An example is the Token/Special-Char-Only obfuscator. To make sure its payloads are comprised entirely of special characters, it evals itself towards the end of its generated payload.
To prevent variable pollution on the parent shell environment (variables, aliases or functions getting set in Mutators and remaining set in the parent shell), I currently wrap each Mutator's payload that evals itself in a subshell. Like this: ( OBFUSCATED_CODE ). The problem with this is by definition of a subshell, the variables, funcions, and aliases defined inside a subshell does not effect the parent shell environment. Hence can't be sourced.
A solution to this problem is to not wrap the payload generated from self-evaling Mutators in a subshell, and add code to the payload that will unset any variables, aliases and functions set in that payload. This functionality will be much easier to add once work on once #9 is finished.
The text was updated successfully, but these errors were encountered:
Currently, there's a very small chance any given outputted payload will be able to be sourced. This is due to a few things. First, the 'eval wrapping' that Bashfuscator applies automatically to almost every layer. Bashfuscator does this because the results of each layer needs to be passed back, in order for the outputted payload to deobfuscate and run it's obfuscated input. There are 2 eval wrappers currently, and they are randomly chosen:
eval "$(OBFUSCATED_CODE)"
printf %s "$(OBFUSCATED_CODE)" | bash
When the first option is used, generated payloads can be sourced successfully. For example, if you generated a payload obfuscated with one layer and it used the first eval wrapper described above, the payload will be able to be sourced. So an easy solution is just to create an CLI option that forces the use of the first eval wrapper.
The only problem with that is some Mutators don't require eval wrapping, as they do similar functionality themselves. An example is the Token/Special-Char-Only obfuscator. To make sure its payloads are comprised entirely of special characters, it evals itself towards the end of its generated payload.
To prevent variable pollution on the parent shell environment (variables, aliases or functions getting set in Mutators and remaining set in the parent shell), I currently wrap each Mutator's payload that evals itself in a subshell. Like this:
( OBFUSCATED_CODE )
. The problem with this is by definition of a subshell, the variables, funcions, and aliases defined inside a subshell does not effect the parent shell environment. Hence can't be sourced.A solution to this problem is to not wrap the payload generated from self-evaling Mutators in a subshell, and add code to the payload that will unset any variables, aliases and functions set in that payload. This functionality will be much easier to add once work on once #9 is finished.
The text was updated successfully, but these errors were encountered: