Thank you for the PR @roguepullrequest , i am not opposed to including this functionality as a failsafe for when permissions on target don't allow the use of wget, however in order to get the script on target remotely git, wget, and/or cURL have to be available in the first place. Unless there is an underlying vulnerability on the box you are targeting such as an RCE that can be leveraged to download and execute RootHelper.

Perhaps in a scenario where you have a limited shell on target which forces you to echo RootHelper over it would stand to reason to first echo my SBD script over and execute that since it is designed to provide the user with access to static binaries and busybox which has both cURL and wget out of the box as it were.

What would also be a possibility is to encode a static wget binary, Base64 the results, include it in the main script and have a function write it out on target should it be determined we don't have access to or permissions to run wget. We would automate the decoding process and make the wget we brought along executable in order to use that to bypass any limitations imposed on the proper operation of RootHelper.

Implementing such a solution would be a matter of adding a conditional to check availability, and invoking a function to perform the operations i just mentioned. in my opinion that would be a more robust solution than simply hoping cURL will work if wget won't.

I would very much like to hear your thoughts on this, before i merge or request changes to the PR to the extent that we have a more robust failsafe mechanism.

This does make sense. If you want to have another fallback option it can be TCP sockets. Let me see what I can cobble together to handle all the scenarios.

This does make sense. If you want to have another fallback option it can be TCP sockets. Let me see what I can cobble together to handle all the scenarios.

Any updates on any potential improvements you had in mind?