@lexikos
My plan is to supply a program which the user can call via a 'PostExec' directive. This can quickly hex-edit the created binary before final compression, and will be generalised to accept parameters defining what is to be changed. I see some fast routines employing machine code on the old and new forums, and intend to borrow from these (with attribution of course).
There has been interest shown in altering the 'AutoHotkeyGIU' string as well, so the above solution should be useful for this also.
Upcoming Ahk2Exe Changes (2024)
Re: Upcoming Ahk2Exe Changes (2019)
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
Re: Upcoming Ahk2Exe Changes (2019)
That's what I figured.
I was going to say "be aware that some things might break if the window class does not begin with AutoHotkey", but actually, I think that only affects the Edit command, which has no effect in compiled scripts. And even if it affected compiled scripts, replacing all instances of the string "AutoHotkey" would probably suffice.
Specifically, in non-compiled scripts, Edit tries to activate the first window that has the script's filename in its title (but excluding the script's main window via ExcludeTitle), unless its class begins with "AutoHotkey".
I was going to say "be aware that some things might break if the window class does not begin with AutoHotkey", but actually, I think that only affects the Edit command, which has no effect in compiled scripts. And even if it affected compiled scripts, replacing all instances of the string "AutoHotkey" would probably suffice.
Specifically, in non-compiled scripts, Edit tries to activate the first window that has the script's filename in its title (but excluding the script's main window via ExcludeTitle), unless its class begins with "AutoHotkey".
Last edited by lexikos on 25 Oct 2019, 20:14, edited 1 time in total.
Reason: nitpicking
Reason: nitpicking
Re: Upcoming Ahk2Exe Changes (2019)
@lexikos +1
Also, the removal of >AHK WITH ICON< was implemented in the edge branch which has since been merged.
https://github.com/AutoHotkey/Ahk2Exe/commit/9693a7176f0cbbc41664ba9003cccc9c351fcb30
Also, the removal of >AHK WITH ICON< was implemented in the edge branch which has since been merged.
https://github.com/AutoHotkey/Ahk2Exe/commit/9693a7176f0cbbc41664ba9003cccc9c351fcb30
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
- JoeWinograd
- Posts: 2182
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
Found both in Ahk2Exe.exe v1.1.31.01 with a hex editor...nice!lexikos wrote:>AUTOHOTKEY SCRIPT<
>AHK WITH ICON<
Got it!guest3456 wrote:AHK_H encrypts the source code of the script, so this compiler would need to implement the same encryption as the AHK_H compiler
Sounds great!TAC109 wrote:My plan is to supply a program which the user can call via a 'PostExec' directive.
Thanks...one fewer issue to worry about.joedf wrote:removal of >AHK WITH ICON< was implemented in the edge branch which has since been merged
Regards, Joe
Re: Upcoming Ahk2Exe Changes (2019)
@joedf
I need to make some changes to AutoHotkey/Ahk2Exe on GitHub. Should I do this directly or would you prefer I fork to TAC109, change there and push back to AutoHotkey/Ahk2Exe?
Cheers
I need to make some changes to AutoHotkey/Ahk2Exe on GitHub. Should I do this directly or would you prefer I fork to TAC109, change there and push back to AutoHotkey/Ahk2Exe?
Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
- JoeWinograd
- Posts: 2182
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
Hi TAC,TAC109 wrote:I need to make some changes to AutoHotkey/Ahk2Exe on GitHub.
By any chance, will this address the RCData/>AUTOHOTKEY SCRIPT< issue? I'm eagerly awaiting that. Thanks, Joe
Re: Upcoming Ahk2Exe Changes (2019)
@TAC109
I have added you as collaborator, you should be able to push and pull from it now. Please check your github notifications.
Otherwise let me know or update your fork
I have added you as collaborator, you should be able to push and pull from it now. Please check your github notifications.
Otherwise let me know or update your fork
Windows 10 x64 Professional, Intel i5-8500, NVIDIA GTX 1060 6GB, 2x16GB Kingston FURY Beast - DDR4 3200 MHz | [About Me] | [About the AHK Foundation] | [Courses on AutoHotkey]
[ASPDM - StdLib Distribution] | [Qonsole - Quake-like console emulator] | [LibCon - Autohotkey Console Library]
Re: Upcoming Ahk2Exe Changes (2019)
@JoeWinograd
Yes, that’s involved. Plus I’m writing a 'PostExec' script to do the heavy lifting.
@joedf
Thanks
Yes, that’s involved. Plus I’m writing a 'PostExec' script to do the heavy lifting.
@joedf
Thanks
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
- JoeWinograd
- Posts: 2182
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
Very nice!TAC109 wrote:I’m writing a 'PostExec' script to do the heavy lifting.
Re: Upcoming Ahk2Exe Changes (2019)
@JoeWinograd
Here's the 'PostExec' code to alter compiled scripts. It works with Ahk2Exe Beta 7 and later.
If you have 64-bit AutoHotkey installed, you'll need to compile this script with a 32-bit 'bin' and call that in your 'PostExec' directive, otherwise you can use this script directly if you wish. Detailed instructions are at the top of the script.
Note that the replacement string needs to be filled with spaces to be the same size as the search string.
An example directive:
BinMod.ahk can be downloaded from GitHub here.
Edit: Add to description.
Edit2: Removed script from post and added a GitHub link.
Here's the 'PostExec' code to alter compiled scripts. It works with Ahk2Exe Beta 7 and later.
If you have 64-bit AutoHotkey installed, you'll need to compile this script with a 32-bit 'bin' and call that in your 'PostExec' directive, otherwise you can use this script directly if you wish. Detailed instructions are at the top of the script.
Note that the replacement string needs to be filled with spaces to be the same size as the search string.
An example directive:
Code: Select all
;@Ahk2Exe-PostExec "path to\BinMod.exe" "%A_WorkFileName%" "22.>AUTOHOTKEY SCRIPT<.DATA "
Edit: Add to description.
Edit2: Removed script from post and added a GitHub link.
Last edited by TAC109 on 01 Nov 2019, 21:04, edited 1 time in total.
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
- JoeWinograd
- Posts: 2182
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
Hi TAC,
I compiled BinMod with the 1.1.31.1 32-bit bin. I then compiled this script with Beta_7:
I got this dialog:
After clicking OK, got this one:
Btw, what do you mean by the "Edit: Add to description." comment in your last post? Thanks, Joe
I compiled BinMod with the 1.1.31.1 32-bit bin. I then compiled this script with Beta_7:
Code: Select all
;@Ahk2Exe-SetName HelloWorld
;@Ahk2Exe-SetDescription HelloWorld
;@Ahk2Exe-SetVersion 1.0
;@Ahk2Exe-SetOrigFilename HelloWorld.exe
;@Ahk2Exe-PostExec "c:\temp\BinMod.exe" "c:\temp\HelloWorld.exe" "22.>AUTOHOTKEY SCRIPT<.DATA "
msgbox hello world
After clicking OK, got this one:
Btw, what do you mean by the "Edit: Add to description." comment in your last post? Thanks, Joe
Last edited by JoeWinograd on 30 Oct 2019, 16:12, edited 1 time in total.
Re: Upcoming Ahk2Exe Changes (2019)
(1) "%A_WorkFileName%" contains the name of the file of the processed .exe at that point. (See the 'PostExec' documentation.) It is also defined with the built-in variables earlier on in that document.
(2) I added 'It works with Ahk2Exe beta 7' to my post.
Cheers
(2) I added 'It works with Ahk2Exe beta 7' to my post.
Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
- JoeWinograd
- Posts: 2182
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
Our messages just crossed. I had already tried (1) as the name of the EXE being compiled. Thanks for the clarification on (2).
- JoeWinograd
- Posts: 2182
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
Hi TAC,
Thank you for pointing me to the PostExec doc...my bad! I changed the directive to this:
Worked perfectly! ResourceHacker now shows this:
Exactly what I wanted! Thanks very much for your efforts on this...truly appreciated! Regards, Joe
Thank you for pointing me to the PostExec doc...my bad! I changed the directive to this:
Code: Select all
;@Ahk2Exe-PostExec "c:\temp\BinMod.exe" "%A_WorkFileName%" "22.>AUTOHOTKEY SCRIPT<.DATA "
Exactly what I wanted! Thanks very much for your efforts on this...truly appreciated! Regards, Joe
- JoeWinograd
- Posts: 2182
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
Hi TAC (or anyone else who wants to jump in),
I just took a spin through the compiled EXE after replacing the RCData entry to make sure that there were no indicators of AHK left, but this is in the Manifest:
<assemblyIdentity version="1.1.00.00" name="AutoHotkey" type="win32" />
Based on the Ahk2ExeDirectives doc, I tried this:
;@Ahk2Exe-UpdateManifest 0,HelloWorld,3.13.0.0
The compile was successful, but when I ran the EXE, Malwarebytes quarantined it, detecting this:
MachineLearning/Anomalous.100%
I'm guessing that my UpdateMaifest directive is wrong and is the culprit. Without it, the compiled EXE runs fine. Is there any way to change or replace those version and name values? Thanks again, Joe
I just took a spin through the compiled EXE after replacing the RCData entry to make sure that there were no indicators of AHK left, but this is in the Manifest:
<assemblyIdentity version="1.1.00.00" name="AutoHotkey" type="win32" />
Based on the Ahk2ExeDirectives doc, I tried this:
;@Ahk2Exe-UpdateManifest 0,HelloWorld,3.13.0.0
The compile was successful, but when I ran the EXE, Malwarebytes quarantined it, detecting this:
MachineLearning/Anomalous.100%
I'm guessing that my UpdateMaifest directive is wrong and is the culprit. Without it, the compiled EXE runs fine. Is there any way to change or replace those version and name values? Thanks again, Joe
Re: Upcoming Ahk2Exe Changes (2019)
It’s a false positive, Joe. I used code supplied by Lexikos (see up-thread a few pages), and all this directive does is edit the manifest. I’ve tested the manifest changes made by this directive and am happy that it is performing as expected.
Can you tell malwarebytes to ignore it and check the generated .exe yourself?
Cheers
Can you tell malwarebytes to ignore it and check the generated .exe yourself?
Cheers
My scripts:-
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
XRef - Produces Cross Reference lists for scripts
ReClip - A Text Reformatting and Clip Management utility
ScriptGuard - Protects Compiled Scripts from Decompilation
I also maintain Ahk2Exe
- JoeWinograd
- Posts: 2182
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Upcoming Ahk2Exe Changes (2019)
Ah, I glossed over all the manifest discussion back then. Now I see what Drugwash was talking about.
I put an exclusion in Malwarebytes for the EXE and all is good...the UpdateManifest directive (exactly as I posted above) changes the name and version values correctly (as shown in RH) and the EXE runs fine. Problem is, Malwarebytes is very popular and it would be a disaster to have all my programs get a false positive from it.
What's interesting here is that Drugwash was saying that changing name= in the manifest from AutoHotkey to the program name "may reduce the chances of such compiled executables being wrongly flagged as infected or potentially unwanted, if some so-called antivirus checks the name field and finds AutoHotkey there." That makes a lot of sense to me, but, ironically, the opposite just happened with Malwarebytes...it detected name="HelloWorld" but not name="AutoHotkey"...strange! Regards, Joe
I put an exclusion in Malwarebytes for the EXE and all is good...the UpdateManifest directive (exactly as I posted above) changes the name and version values correctly (as shown in RH) and the EXE runs fine. Problem is, Malwarebytes is very popular and it would be a disaster to have all my programs get a false positive from it.
What's interesting here is that Drugwash was saying that changing name= in the manifest from AutoHotkey to the program name "may reduce the chances of such compiled executables being wrongly flagged as infected or potentially unwanted, if some so-called antivirus checks the name field and finds AutoHotkey there." That makes a lot of sense to me, but, ironically, the opposite just happened with Malwarebytes...it detected name="HelloWorld" but not name="AutoHotkey"...strange! Regards, Joe
Re: Upcoming Ahk2Exe Changes (2019)
It seems likely that malware creators already tried to disguise their AHK malware before as something else (not only by changing these fields, though).
I could imagine that most harmless AHK exes that got scanned by AV software still have the original fields and that many which have changed fields are actually malware... so, heuristically your exe might look more risky than others to them, right from the start.
I could imagine that most harmless AHK exes that got scanned by AV software still have the original fields and that many which have changed fields are actually malware... so, heuristically your exe might look more risky than others to them, right from the start.
Re: Upcoming Ahk2Exe Changes (2019)
Maybe their "A.I." goes beyond simply checking for names from a black list - maybe they also check for a match between filename, VersionInfo fields, Manifest name and who-knows-what else inside the executable based on some fixed patterns plus heuristics. However, variations on "Hello world" may well be on the black list; have you tried other more sensible names in the Manifest?
Personally I did away with those resource hogs more than ten years ago, when I realized where they were going to. The only thing I kept for a while was Trend Micro's Sysclean, which I manually launched whenever I had strong reasons to suspect some file could've been infected or when I had to disinfect somebody else's computer. But nothing resident.
You may submit your exes to VirusTotal for analysis, and also mention that option in a ReadMe file and/or other places related to the distribution of your exes.
Part of my AHK work can be found here.
Re: Upcoming Ahk2Exe Changes (2019)
Can't you just write a null-terminator (write StrLen + 1 characters)? Of course, the replacement still can't be longer than the search string.
(For all I know, there might be some reason you can't use a shorter string.)
I think that resource names with lower-case letters don't work (maybe for specific APIs or situations?). Ahk2Exe converts FileInstall filenames to uppercase.