Dynamic compiler
Dynamic compiler
My work is planning on shutting down my 10+ year project because security scans of ahk files show all functions the langauge is capable of instead of only what the program is using. Is there a way to have the compiler scan your code and include only the libraries it needs? This would resolve nearly all of the security complaints that have been addressed over the years.
Re: Dynamic compiler
An AutoHotkey "executable" is not truly compiled. The script is instructions to the C++ interpreter, which is the compiled program. The script is bound to the interpreter, to create the "executable". If you are referring to the AutoHotkey.exe, that is the C++ interpreter that is executing the instructions from the .ahk script. The AutoHotkey.exe was compiled using Visual Studio, though with some tinkering it should be possible to use other C++ compilers.
The other possibility that I can think of is someone using the AutoHotkey.dll, where they are identifying the functions from the .dll file. But in that case, the AutoHotkey.dll is benign. The only danger can come from the programming language calling the .dll, not from the .dll itself. People would usually be using the AutoHotkey.dll from another programming language, so the "threat" would be from that other code and language.
To do what you are suggesting, it would appear you would have to modify and then recompile the AutoHotkey source code to have only functions that are used by the script. You could compile the new version of AutoHotkey (with limited functions) as a .dll or .exe. Such things are usually done manually. In that method, you would be compiling your own special copy of AutoHotkey. This is what was done with the AutoHotkey_H fork. However, keep in mind that you would be bound by the terms of the GPL, thus would have to make such a fork public.
I don't know of any simple method that would result in the "dynamic compiler" that you want, unless what you really mean is a transpiler. This would be translating the AutoHotkey language to the equivalent of a compiled language (source to source translation), where you can then use its compiler. Making a transpiler would not be easy. Arguably, if a person was going that route, they might also want to consider creating a new compiled programming language loosely based on AutoHotkey. But, there are already programming languages that have automation libraries. Python (PyAutoGUI) and Object Pascal (Simba) come quickly to mind. In the case of Python, its an interpreted language like AutoHotkey, but having the additional advantage of being cross-platform. Object Pascal would be the true contender, as it's a compiled language like C++. There is already a project to make a cross platform version of AutoHotkey, called Keysharp. I would agree that AutoHotkey stands above other automation scripting languages on the Windows OS, but it won't be easy to create your own AutoHotkey-like compiled programming language, versus use what is already in existence.
I suppose, in theory, it might be possible to do something "funky" with the GNU GCC Compiler (and its a lot smaller and more portable than Visual Studio). If the existing AutoHotkey source code could be compiled with the GNU GCC compiler, maybe something could be made to read a script and then determine what functions in the source code are needed, then create a customized executable made from the AutoHotkey source. But that doesn't seem like anything easy either. Instead of going that route, a person could learn C++, and then get good at programming in that language. Obviously mastering C++ isn't easy for most, but in terms of how long it would take to create an alternative solution, it might be the same in terms of time.
The other possibility that I can think of is someone using the AutoHotkey.dll, where they are identifying the functions from the .dll file. But in that case, the AutoHotkey.dll is benign. The only danger can come from the programming language calling the .dll, not from the .dll itself. People would usually be using the AutoHotkey.dll from another programming language, so the "threat" would be from that other code and language.
To do what you are suggesting, it would appear you would have to modify and then recompile the AutoHotkey source code to have only functions that are used by the script. You could compile the new version of AutoHotkey (with limited functions) as a .dll or .exe. Such things are usually done manually. In that method, you would be compiling your own special copy of AutoHotkey. This is what was done with the AutoHotkey_H fork. However, keep in mind that you would be bound by the terms of the GPL, thus would have to make such a fork public.
I don't know of any simple method that would result in the "dynamic compiler" that you want, unless what you really mean is a transpiler. This would be translating the AutoHotkey language to the equivalent of a compiled language (source to source translation), where you can then use its compiler. Making a transpiler would not be easy. Arguably, if a person was going that route, they might also want to consider creating a new compiled programming language loosely based on AutoHotkey. But, there are already programming languages that have automation libraries. Python (PyAutoGUI) and Object Pascal (Simba) come quickly to mind. In the case of Python, its an interpreted language like AutoHotkey, but having the additional advantage of being cross-platform. Object Pascal would be the true contender, as it's a compiled language like C++. There is already a project to make a cross platform version of AutoHotkey, called Keysharp. I would agree that AutoHotkey stands above other automation scripting languages on the Windows OS, but it won't be easy to create your own AutoHotkey-like compiled programming language, versus use what is already in existence.
I suppose, in theory, it might be possible to do something "funky" with the GNU GCC Compiler (and its a lot smaller and more portable than Visual Studio). If the existing AutoHotkey source code could be compiled with the GNU GCC compiler, maybe something could be made to read a script and then determine what functions in the source code are needed, then create a customized executable made from the AutoHotkey source. But that doesn't seem like anything easy either. Instead of going that route, a person could learn C++, and then get good at programming in that language. Obviously mastering C++ isn't easy for most, but in terms of how long it would take to create an alternative solution, it might be the same in terms of time.
Re: Dynamic compiler
I have no formal programming training. Everything I know about ahk and programming has been from the help file and forums over the 10 years I've been working with it. I tremble at the thought of how long it would take me to get good enough at c++ to rebuild this program as it is today. :p I guess my company will just have to get on the ball with finding a better solution. It's taken them 10 years so far. Shouldn't be too much longer.
Re: Dynamic compiler
Perhaps you want to elaborate on this part more. A normal Anti-Virus scan doesn't show all the functions in an executable (as far as I know). What scans recognize are hashes which identify dangerous files, sections of machine code that are considered dangerous, detect behavior that is dangerous, sandbox the executable and then do behavior analysis as it executes, etc......security scans of ahk files show all functions the langauge is capable of instead of only what the program is using...
However, a .dll file or a .ahk file would be different. A .dll file is a library of functions to be called by an executable, therefore various programs can see what functions they are offering. An .ahk file is a text file, where you can read what the functions are or have a special built program do such. But, it would be unusual for an Anti-Virus vendor or IT department to build a special program to read through .ahk files or specifically target .ahk files. It's more likely that advanced AHK users would do such.
What I'm getting at is your comment about such "security scans" sounds weird. 1) That they can scan executables and determine all the functions within them. 2) That they would specifically target .ahk files or AutoHotkey executables. 3) That they are not going after the executables of other programming languages. 4) That they would allow you to use some type of trimmed down AutoHotkey executable.
Maybe if you give more details, people could give advice of greater value. Perhaps this can be resolved in some other way.
Something that is being lost in translation is the details of what you are referring to? Is it just a .ahk file? Who and why are they putting pressure on you to trim down the .ahk file or to use something else? For instance, if it's just a low ranking member of the company IT personnel, you might be able to go to his boss or to management to get approval for your program. If it has been in use for 10 years and useful to the company, seems odd that they would suddenly want to stop using it.punchin wrote: ↑01 Oct 2020, 20:59I have no formal programming training. Everything I know about ahk and programming has been from the help file and forums over the 10 years I've been working with it. I tremble at the thought of how long it would take me to get good enough at c++ to rebuild this program as it is today. :p I guess my company will just have to get on the ball with finding a better solution. It's taken them 10 years so far. Shouldn't be too much longer.
Re: Dynamic compiler
i think what he's getting at is what is visible when you scan a compiled script on VirusTotal...
basically the answer is no, thats the beauty of the scripting language. If that is strictly needed you would want to start programming in C++ directly and then you can control what api's are available to your exe.
As a stop gap because rewriting everything doesn't sound great either, you might try using AutoHotkey_H and compiling your own version (well documented) then you could possible remove some specific functionality that you for sure won't be using...
Edit: is someone at your company actually looking at your files? or are they just saying they don't want anything that gets flagged by antivirus software?
Code: Select all
COMDLG32.dll
GetSaveFileNameW
GetOpenFileNameW
CommDlgExtendedError
VERSION.dll
VerQueryValueW
GetFileVersionInfoW
GetFileVersionInfoSizeW
WINMM.dll
mixerGetLineControlsW
mixerGetControlDetailsW
mixerOpen
waveOutSetVolume
mixerSetControlDetails
mciSendStringW
mixerClose
mixerGetDevCapsW
waveOutGetVolume
mixerGetLineInfoW
WININET.dll
InternetReadFileExA
InternetOpenW
InternetCloseHandle
InternetOpenUrlW
...
As a stop gap because rewriting everything doesn't sound great either, you might try using AutoHotkey_H and compiling your own version (well documented) then you could possible remove some specific functionality that you for sure won't be using...
Edit: is someone at your company actually looking at your files? or are they just saying they don't want anything that gets flagged by antivirus software?
EitherMouse - Multiple mice, individual settings . . . . www.EitherMouse.com . . . . forum . . . .
Re: Dynamic compiler
Basically they don't want ahk files on the network due to the possibility of what they could do. I'm not sure if anybody has actually looked at my code to decipher it yet. I have gotten a temporary pass to get my files approved, but every update requires a ticket open with the security team. You guys don't know of an easy to use ahk > c++ converter, do you? If I could just convert the code and recompile that way, I would be more inclined to learn enough c++ to do it. As it stands, I don't have the time around work and family to sit down with the c++ book I've had for years and learn it.
Re: Dynamic compiler
This is somewhat understandable, but almost any .exe or .dll could be made to do something malicious. Just getting to the command line, running a .cmd file or .ps1 (PowerShell) could cause havoc, not to mention their friend VBScript.
In the case of how AutoHotkey is run and contrary to the advice that is sometimes given, I think it is arguably better to run AutoHotkey programs as .exe and not .ahk on a company or school network. I will repeat that. I rather see a compiled AutoHotkey .exe on the network than people running .ahk files all over the place. The reason for this is that you can hash check (md5, sha1, or sha256) the compiled AutoHotkey .exe and have it digitally signed. An exception is made only for that specific Autohotkey file. Let's call it usefulhelp.exe. That file would be whitelisted and information about it known, including it being identifiable as a company file when you look at it's properties. You can also go further, by having the department that is using that file (usefulhelp.exe) clarify what it does (so it's documented by the IT dept) and restrict it to only certain computers that need it.
When files are run as .ahk files. It creates the possibility of "anybody" creating a .ahk file to be executed by their copy of AutoHotkey.exe, if they know about and understand AutoHotkey. That includes the AutoHotkey.exe files ending up on random computers for unknown reason (as far as IT is concerned). To be clear, this isn't a problem specific to AutoHotkey, of course such loose things can be done with other scripting languages such as JavaScript, Python, AutoIt, PowerShell, etc...
The only person who should have an exception for AutoHotkey.exe on their company computer is a "developer" (using the term loosely and not in the professional context), who is making some script for the company or department. That would be only be for the time it takes for them to create what they need. The exception would only be granted on a limited basis, as needed by that "developer". And this goes for any programming language. I wouldn't want to see Visual Studio, PyCharm (Python IDE), Delphi Community Edition, etc... popping up on just any random work computer. Of course a lot of mischief can still be done just with the command line, PowerShell, JavaScript, or VBScript.
This make sense. If they are hash checking and whitelisting files, an updated file needs to be known and approved. AHK v1 is not updated that often, that it shouldn't be a problem. Lately, AHK v2 has a more rapid development pace, but its Alpha and experimental, so arguably shouldn't be used for anything important at work. To be more clear, I'm making a distinction between the AutoHotkey.exe you download from this website or GitHub or any programs that you might use for development like AHK Studio, versus your finished program. Let's call it usefulhelp.exe.I have gotten a temporary pass to get my files approved, but every update requires a ticket open with the security team.
Your IT Dept has to make this distinction too. AutoHotkey.exe can't be allowed to be running loose on their network. Where they can make an exception for usefulhelp.exe (a compiled AutoHotkey executable), because it's doing something specific and is needed by a specific department.
It should be clarified if they are giving you approval for just your computer, so that you can do development versus you have created a finished program that will be used on multiple computers in the company. The finished program should arguably be compiled, it's hash cataloged, and if possible digitally signed too.
So part of the issue of what we are talking about is the process. You need to have some agreed upon development process that the IT dept and management understands, in addition to them understanding why you need and are developing a program.
I think there is a misunderstanding about AutoHotkey or programming, by either yourself or your IT Dept. AutoHotkey is no more a threat than any other programming language. That would include Python, VBScript, PowerShell, C#, etc... You creating a C++ program to run on multiple computers on your company network is no less a threat than having a compiled AutoHotkey executable doing the same. A C++ program can contain code or backdoor code to do malicious things, that may not be obvious to any Anti-Virus scan or until after it's executed. Where with a compiled AutoHotkey executable, you can at least identify, explain, and have viewable comments about the contents of the script and what actions it will do.You guys don't know of an easy to use ahk > c++ converter, do you? If I could just convert the code and recompile that way, I would be more inclined to learn enough c++ to do it. As it stands, I don't have the time around work and family to sit down with the c++ book I've had for years and learn it.
It seems like you want an AHK to C++ transpiler, and that doesn't exist. You would have to manually edit the AutoHotkey source code, take out functions you don't want, then compile it using Visual Studio (or some other C++ compiler and that will be even harder). This will take a decent knowledge of C++. You don't necessarily have to go the C++ route and can use another compiled programming language, but you would need to be an advanced user of that other language in order to translate what you have written with an AutoHotkey script into that language.
Who is online
Users browsing this forum: No registered users and 33 guests