by SOTE » 22 Jan 2020, 06:45
freespacing wrote: ↑21 Jan 2020, 23:57
your developed script does not have to remain Open Source
As of Jan 2020, does anyone know if there a good pathway to obfuscate and/or encrypt source code in compiled scripts?
Last time I looked, about a year ago, I spent three days chasing black cats down blind alleys.
Asking about something that can work with large scripts, with many thousands of lines, lots of include files, tons of functions.
I don't quite understand how you have never found an answer to that question, when a search for encrypt or obfuscate will turn up lots of posts on the subject. Probably the latest help topic where the subject was explored is here (and lists some protection options)-
https://www.autohotkey.com/boards/viewtopic.php?f=76&t=69724
(AHK Script Encryption)
Long story made shorter, interpreted programming languages like AutoHotkey and those using bytecode (AutoIt, Java, JavaScript, Python, PHP, PowerShell, C#, Lua, etc...) are going to have a much more harder time with protection than totally compiled languages (like C/C++, Pascal, Go, Swift, etc...). The interpreter must be able to "see" your script in order to execute it. However, even if you used a compiled language, there are still ways and many tools out there to edit/patch/crack/reverse engineer it from machine code, to Assembly language, and then pseudo C code. The expectation to create a hackerproof program is unrealistic.
Be that as it may, it hasn't stopped programmers and companies from releasing their programs and doing business, so sometimes people are being more worried about the imaginary loss of profits than they should. This is because probably 95% of users have no idea about reverse engineering and cracking, don't want to waste their time on such, or are law-abiding types. Of the probable 5% that remains, most likely have only a passing interest or limited knowledge and are easily deterred with basic protections (some of those protections are talked about in the link provided). And of the remaining willing to spend lots of time, are very knowledgeable, or are criminals, no matter what software protection that is used, it's not going to stop them from eventually cracking it (to include spending weeks or months trying).
Thus your best alternate route (outside of encryption and obfuscation) is legal protection, which is what Joe Glines webinar is about. Suggest viewing it, if you haven't already, very informative videos.
[quote=freespacing post_id=310721 time=1579669045 user_id=72716]
[quote]your developed script does not have to remain Open Source[/quote]
As of Jan 2020, does anyone know if there a good pathway to obfuscate and/or encrypt source code in compiled scripts?
Last time I looked, about a year ago, I spent three days chasing black cats down blind alleys.
Asking about something that can work with large scripts, with many thousands of lines, lots of include files, tons of functions.
[/quote]
I don't quite understand how you have never found an answer to that question, when a search for encrypt or obfuscate will turn up lots of posts on the subject. Probably the latest help topic where the subject was explored is here (and lists some protection options)-
[url]https://www.autohotkey.com/boards/viewtopic.php?f=76&t=69724[/url]
(AHK Script Encryption)
Long story made shorter, interpreted programming languages like AutoHotkey and those using bytecode (AutoIt, Java, JavaScript, Python, PHP, PowerShell, C#, Lua, etc...) are going to have a much more harder time with protection than totally compiled languages (like C/C++, Pascal, Go, Swift, etc...). The interpreter must be able to "see" your script in order to execute it. However, even if you used a compiled language, there are still ways and many tools out there to edit/patch/crack/reverse engineer it from machine code, to Assembly language, and then pseudo C code. The expectation to create a hackerproof program is unrealistic.
Be that as it may, it hasn't stopped programmers and companies from releasing their programs and doing business, so sometimes people are being more worried about the imaginary loss of profits than they should. This is because probably 95% of users have no idea about reverse engineering and cracking, don't want to waste their time on such, or are law-abiding types. Of the probable 5% that remains, most likely have only a passing interest or limited knowledge and are easily deterred with basic protections (some of those protections are talked about in the link provided). And of the remaining willing to spend lots of time, are very knowledgeable, or are criminals, no matter what software protection that is used, it's not going to stop them from eventually cracking it (to include spending weeks or months trying).
Thus your best alternate route (outside of encryption and obfuscation) is legal protection, which is what Joe Glines webinar is about. Suggest viewing it, if you haven't already, very informative videos.