Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

HotkeyCamo [0.65.14b] AutoHotkey Basic Compile Wrapper


  • Please log in to reply
186 replies to this topic
rand0m
  • Members
  • 17 posts
  • Last active: Dec 31 2012 08:59 AM
  • Joined: 26 Feb 2010
I love HKC! Thank you for this. Please continue to develop it further.

Mobius
  • Members
  • 97 posts
  • Last active: Jul 31 2015 01:53 PM
  • Joined: 08 Jun 2008

I love HKC! Thank you for this. Please continue to develop it further.


Thanks dude I will.

If you or anybody else has an idea what you would like the further to mean don't hesitate to suggest it, regardless of what it might be.

Bonus point grin for using its abbreviated name too. :D

Delusion
  • Members
  • 272 posts
  • Last active: Jul 13 2014 09:04 PM
  • Joined: 16 Jul 2008
very nice! it works on my windows vista ultimate sp2 x64 partition too now
thank you so much for your great work :)
QuickSubs | Popcorn Movie Catalog
All my scripts are just in AutoHotkey v1.0.48.05

Mobius
  • Members
  • 97 posts
  • Last active: Jul 31 2015 01:53 PM
  • Joined: 08 Jun 2008

very nice! it works on my windows vista ultimate sp2 x64 partition too now
thank you so much for your great work :)


Many thanks for reporting this excellent news Delusion, it is rather unexpected. 8)

Respect

Vlad

Drugwash
  • Members
  • 1078 posts
  • Last active: May 24 2016 04:20 PM
  • Joined: 07 Sep 2008
Hey, Mobius! Just tried out your tool - mainly out of curiosity but also because I could use a compiler that allows a quick selection of the bin used and/or version info changes. Protection is of no importance for me, at least for now.

It may come as a shock for you, but it might work in Win9x; test was performed in Win98SE and the GUI shows up, buttons work, starts building but... bugs stopped it in its tracks. :?

Admittedly, I did not copy the app to the Compiler folder as required - honestly, this kinda sounds like a limitation, regardless of its function; instead, I ran it directly through Total Commander's 7z decompression (working folder was %temp%\tc0\HotKeyCamo). For that reason, the app stopped at finding the UPX executable (log error: Cant find UPX exe - should be Can't), as there is no (visible) way of setting the path to it - I would've thought having an Edit control for the AHK main folder path would've put everything in order, Ahk2Exe and upx included - what do you think?

Now, trying to overcome this, I toggled the UPX checkmark and tried to build again, but same error popped in the log. I then closed the app, changed location (still NOT in the Compiler folder) and ran it again, this time having UPX compression unchecked from the beginning; same error popped up in the log, leading to the conclusion that UPX usage might not be well coordinated.

Related to UPX, the default Ahk2Exe offers a few degrees of compression; can you provide that in HKC too, or is it unnecessary?

Anyhow, AHK has not been installed at its default location; I usually use the non-installer version of apps, where possible, so in this case I used the zip version, unpacked in C:\Utils\Autohotkey 1.0.47.05 (updated to 1.0.48.05, of course, but folder name remained unchanged). I did try running HKC from the Compiler folder but it still failed at finding UPX. :(

Minor issues with file types as shown in the Open file dialogs: the Input, Output, MainIcon, etc buttons will pop up a dialog where file types appear with exactly the respective name, instead of .ahk, .exe, .ico, etc. and as usually the All file types *.*

It's also a bit unclear how the resources and version info can be changed; I'd see it logical to be able to change AHK's .bin resources and VI in the respective tabs once a .bin file has been chosen, still there's no field filled in there. :?

That's about all for now since I'm in a bit of a hurry; will read any replies next time I log in (in 1-2 weeks, maybe) so apologies in advance for a broken dialog.

Mobius
  • Members
  • 97 posts
  • Last active: Jul 31 2015 01:53 PM
  • Joined: 08 Jun 2008

It may come as a shock for you, but it might work in Win9x; test was performed in Win98SE and the GUI shows up, buttons work, starts building but... bugs stopped it in its tracks. :?

Yo Drugwash,

To be fair I did not expect to be getting error reports from a system that old, not these days. (win2k maybe not 9x :lol: )

Maybe grab a screen cap or two if you ever try that again, "bugs stopped it in its tracks" is a bit vague and I would love to see what 98 spits out. (if anything):?

Admittedly, I did not copy the app to the Compiler folder as required - honestly, this kinda sounds like a limitation, regardless of its function; instead, I ran it directly through Total Commander's 7z decompression (working folder was %temp%\tc0\HotKeyCamo). For that reason, the app stopped at finding the UPX executable (log error: Cant find UPX exe - should be Can't), as there is no (visible) way of setting the path to it - I would've thought having an Edit control for the AHK main folder path would've put everything in order, Ahk2Exe and upx included - what do you think?

Now, trying to overcome this, I toggled the UPX checkmark and tried to build again, but same error popped in the log. I then closed the app, changed location (still NOT in the Compiler folder) and ran it again, this time having UPX compression unchecked from the beginning; same error popped up in the log, leading to the conclusion that UPX usage might not be well coordinated.

Related to UPX, the default Ahk2Exe offers a few degrees of compression; can you provide that in HKC too, or is it unnecessary?

Anyhow, AHK has not been installed at its default location; I usually use the non-installer version of apps, where possible, so in this case I used the zip version, unpacked in C:\Utils\Autohotkey 1.0.47.05 (updated to 1.0.48.05, of course, but folder name remained unchanged). I did try running HKC from the Compiler folder but it still failed at finding UPX. :(

As stated in the help document / First post
Upx must be in HotkeyCamo's own directory and no alternate path can be specified.

Perhaps I did not state the reasons why when I should have..
Ahk2Exe is distributed packed by upx by default, and needs to be unpacked for operations to proceed. (Even with the commandline option to disable protection I am adding now, upx will still be required.)

HkC's directory is the actual directory that the modified Ahk2Exe exists at build time, the option to pack with upx is handled by Ahk2Exe internally and not by HkC directly, so the path to upx and the options it uses are hardcoded into Ahk2Exe. I am adding a workaround so that in the fuzzing process you can specify the alternate string that Ahk2Exe uses when it calls upx. This will allow you to use your own options or even other types of software armoring tools previously unable to be used by AutoHotkey. (which will either have to exist in HkC's directory or be found through the path environment variable)

Maybe I should support an alternate path to upx to be specified and copy it to HkC's directory at build time as a temp file, or attempt to copy it automatically from the possible default locations when it does not exist.

I had originally intended to embed upx within HkC itself and export it to disk as and when but decided that idea would freak to many people out, particularly the ever itchy anti-virus crowd.

You are right the upx element does need more work.

The methods described in the install section of the help doc are recommended but not essential.

I had hoped that by describing both methods the user would realize that regardless of how they have ahk set up on their system, the original build files can be either in HkC's directory or in a directory named compiler above it. If this is not the case then they must specify the paths to them.

Minor issues with file types as shown in the Open file dialogs: the Input, Output, MainIcon, etc buttons will pop up a dialog where file types appear with exactly the respective name, instead of .ahk, .exe, .ico, etc. and as usually the All file types *.*

Agreed, I will change them to represent the related extensions.

It's also a bit unclear how the resources and version info can be changed; I'd see it logical to be able to change AHK's .bin resources and VI in the respective tabs once a .bin file has been chosen, still there's no field filled in there. :?

When the field is not filled in HkC uses the already mentioned 2 possible default locations for your bin, you only need to fill in the field if your bin is not in one of those locations.

Enforcing that the user must specify a bin file before allowing them to use the resource and version info tabs is a bad idea and would negate the 2 possible default locations (fine for the largest percent of users), or would obstruct the flow of config creation since you are only defining actions to be performed by HkC during build preparation, the order of when and how you actually fill in the fields is irrelevant.

Automatically updating the bin and a2e fields with the default path to these files is one answer, but is flawed for a large percent of users when they come to save the config by adding an unnecessary full path to an entry that HkC normally can handle automatically for them.

Thank you for your feedback and ideas Drugwash.

Vlad

AHKnow*
  • Guests
  • Last active:
  • Joined: --
I am adding a workaround so that in the fuzzing process you can specify the alternate string that Ahk2Exe uses when it calls upx. This will allow you to use your own options or even other types of software armoring tools previously unable to be used by AutoHotkey. (which will either have to exist in HkC's directory or be found through the path environment variable).

I think your concept is really great. It is useful for AHK to have some form of obfuscator.

Having HkC able to use other forms of software protection with AHK would be a major accomplishment.

I think you should be patient with people asking about source code, because it is a legitimate concern and people will be afraid to use something that may have malicious code, especially for a company. You don't necessarily have to open your source code, but simply explain (as you did) how they can check on their own or have another well known AHK user vouch for your program. As was stated, trust is always an issue with any software and from nearly any independent programmer.

Anyway, good idea and good program.

AHKnow*
  • Guests
  • Last active:
  • Joined: --

I am adding a workaround so that in the fuzzing process you can specify the alternate string that Ahk2Exe uses when it calls upx. This will allow you to use your own options or even other types of software armoring tools previously unable to be used by AutoHotkey. (which will either have to exist in HkC's directory or be found through the path environment variable).


The above was a quote from Mobius. Opppsss...

Mobius
  • Members
  • 97 posts
  • Last active: Jul 31 2015 01:53 PM
  • Joined: 08 Jun 2008

I think your concept is really great. It is useful for AHK to have some form of obfuscator.

Thanks but I think you misunderstand, HkC is in no way a code obfuscator, If Ahk needed obfuscation I believe that one of the veterans would have written one long ago.

Having HkC able to use other forms of software protection with AHK would be a major accomplishment.

There will be many limitations such as:
# Tool must be command line capable.
# Command line cannot exceed the maximum length of the original C string. (drawback of patching but could be easily worked around with a script that calls the tool)
# Tools Loader should not validate its own integrity with checksums.

I think you should be patient with people asking about source code, because it is a legitimate concern and people will be afraid to use something that may have malicious code, especially for a company. You don't necessarily have to open your source code, but simply explain (as you did) how they can check on their own or have another well known AHK user vouch for your program. As was stated, trust is always an issue with any software and from nearly any independent programmer.

Anyway, good idea and good program.


I understand peoples concerns in this matter, however to check if a binary is malicious or not has never and will never be valid grounds to request anybody's source.

On a brighter note, finally managed to incorporate support for the recent ansi and unicode builds of AutoHotkey_L by Lexikos :)

Vlad

Drugwash
  • Members
  • 1078 posts
  • Last active: May 24 2016 04:20 PM
  • Joined: 07 Sep 2008
Thank you for your reply, Vlad. Obviously I must test your app more thoroughly before posting final observations, but good thing is it can work on my OS. I do work on Win98SE daily by choice and prefer it over any other Windows version.

As stated in the help document / First post
Upx must be in HotkeyCamo's own directory and no alternate path can be specified.

If I'm not mistaken, upx is being delivered with AHK and is usually found in the Compiler folder, so having the AHK installation folder specified in some field should be enough for your app to be able to pick up the upx location, I would guess.

As for the bin files, I'm not sure we're on the same page. What I'm thinking of:
- the bin is the original one; as a script author, I might wanna change version number, file name, copyright, etc to my own desire. If there's no custom bin file selected in first tab, the default fields should be available for editing in version info tab.
- there's a custom bin selected; the fields should be visible and editable as well

Backing up a bit: right now, I have a few scripts for public use. Each and every one of them has its own version number, creation date/copyright, original file name, etc. For this task, I usually create copies of the original AHK bin, edited to hold the respective modified version info data, along with specific icons, where applicable. If your script allowed me to edit the VI data, icon and other resources on the fly, there would be no need for those copies. Right now though, I have no idea how to do that.

If you still need screenshots or other info, I'll provide them as soon as possible. Thank you for reviewing my report.

Mobius
  • Members
  • 97 posts
  • Last active: Jul 31 2015 01:53 PM
  • Joined: 08 Jun 2008

Thank you for your reply, Vlad. Obviously I must test your app more thoroughly before posting final observations, but good thing is it can work on my OS. I do work on Win98SE daily by choice and prefer it over any other Windows version.

*Slams on anchors - head hits dashboard* ;)
Your saying that it does actually work 98SE? Or it works haphazardly?

I have been putting off installing 98 under a vm for testing, perhaps I should not have.

If I'm not mistaken, upx is being delivered with AHK and is usually found in the Compiler folder, so having the AHK installation folder specified in some field should be enough for your app to be able to pick up the upx location, I would guess.

upx is now copied (if it does not exist in HkC's dir) from the compiler directory or if it is not found there from the directory location specified for Ahk2Exe.

With a bit of luck this should address some of HkC's upx woes.

As for the bin files, I'm not sure we're on the same page. What I'm thinking of:
- the bin is the original one; as a script author, I might wanna change version number, file name, copyright, etc to my own desire. If there's no custom bin file selected in first tab, the default fields should be available for editing in version info tab.
- there's a custom bin selected; the fields should be visible and editable as well

Backing up a bit: right now, I have a few scripts for public use. Each and every one of them has its own version number, creation date/copyright, original file name, etc. For this task, I usually create copies of the original AHK bin, edited to hold the respective modified version info data, along with specific icons, where applicable. If your script allowed me to edit the VI data, icon and other resources on the fly, there would be no need for those copies. Right now though, I have no idea how to do that.

Same page? LoL I was not even in the right domain.

You are asking why HkC does not enumerate the resource table and version info structure data of the bin file and display the existing values and data automatically in the relevant tabs?

Excellent idea if so, I had hoped to add such functionality to HkC in the future as the resource editing elements become more developed.

Until that time the individual resource and version info job elements will have to be built from scratch by the author through the config file and the gui.

; Original AutoHotkeySC.bin RES and VI to HkC config template.
; Comment out or delete what you do not need.
[HKC_RES]
; MENU
TRAY=4`211`1033`
; DIALOG
INPUT=5`205`1033`
; ACCELERATORS
MENUHOTKEYS=9`212`1033`
; ICONGROUP
MAIN_32=14`159`1033`
FILE_32=14`160`1033`
TRAY_SG_16=14`206`1033`
TRAY_HR_16=14`207`1033`
TRAY_SR_16=14`208`1033`
TRAY_HG_16=14`228`1033`
TRAY_SG_16=14`229`1033`
; VERSIONINFO
VNFO_ORG=16`1`1033`
; MANIFEST
XML_ORG=24`1`1033`
[HKC_VER]
FileDescription=
FileVersion=1, 0, 48, 05
InternalName=
LegalCopyright=
OriginalFilename=
ProductName=
ProductVersion=1, 0, 48, 05
[]

All the above values can be added/edited from your code editor or from HkC's gui, perhaps I misunderstand what you mean by on the fly.

If you still need screenshots or other info, I'll provide them as soon as possible. Thank you for reviewing my report.

That would be sweet Drugwash, any and all information (particularly error related) is greatly appreciated.

Many thanks for your time dude, a couple of things you have pointed out will be addressed in the next release 0.9.5 in a day or so.

Respect

Vlad

hmmmm
  • Guests
  • Last active:
  • Joined: --
thanks for your work, looks great smells nice but I cannot run it. I tried it on an .ahk File without success.


What did i make wrong?
HotkeyCamo Settings: Posted ImageLog: Posted Image SystemFiles: Posted Image


Suggestion: Could you provide a SETUP(.EXE), which installs all needed files automatically in the right directory/a predefined directory...

Thanks in Advance.

Mobius
  • Members
  • 97 posts
  • Last active: Jul 31 2015 01:53 PM
  • Joined: 08 Jun 2008

thanks for your work, looks great smells nice but I cannot run it. I tried it on an .ahk File without success.

What did i make wrong?

Suggestion: Could you provide a SETUP(.EXE), which installs all needed files automatically in the right directory/a predefined directory...

Thanks in Advance.


Hmmmm,
Judging by your screen caps (thankyou for those btw) HotkeyCamo does not recognize one or more of the build files that you are using.

Its unlikely to be Ahk2Exe since HkC has unpacked this file for fuzzing. (Unless you have modified this file and then repacked it?)

So this moves us on to AutoHotkeySC.bin, here are a couple of reasons why HkC might fail to auto detect the bin file version through crc:

[*:2ca178rd] You have modified this file before using it with HkC (even a single byte)
[*:2ca178rd] The file has been modified by some other means....
[*:2ca178rd]You are using the unsupported smaller interpreter that is available here
[*:2ca178rd] The bin file is from a build of AutoHotkey_L. (not supported in 0.9.4b)
[*:2ca178rd] The bin is from a version of Ahk that I have overlooked.
[*:2ca178rd] The crc values I put into HkC for the version you are using are incorrect.
Possible workarounds...

You could execute HkC with the ~ns commandline option or tick the 'disable build recognition by crc' option in the gui, and specify the correct Ahk version value you are using through the hkc_ver config option or through the gui.

You could post the bin (and a2e if you wish) and I will take a look at it.


Regarding the setup exe, I personally don't like installers, they are best left for programs with fiddly installation methods or heavy shell integration.

HotkeyCamo requires only the contents of the compiler directory to function, If I distributed these files with HkC people would be suspicious or might think that they have been recompiled in some way, besides they are part of the Ahk distribution.

Vlad

hmmmm
  • Guests
  • Last active:
  • Joined: --
Hi!

I first tried to "disable build recognition by crc" but it had no effect.

I had AHK Version 1.0.48.03 (Help File Info) installed.

I guess I found the problem:

I have installed Skite-Editor (which shouldn't have an effect?!) and AHK Compile II which is another gui-based compiler. I guess that AHK Compile II modified the bin-File.

So i simply installed AHK Version 1.0.48.05. Now your Tool works. Thanks for your Support! and WOW it really prevents from Decompiling :)
Thanks for the App!


Regarding the Setup, I can only speak from my Point of view, and i prefer a quick installation without having to much to configure. So my suggestion is that you could provide additionally the Setup, for Guys like me :)...but

Aravind
  • Members
  • 67 posts
  • Last active: Oct 26 2014 10:21 AM
  • Joined: 30 Oct 2009
Posted Image

I got this error msg when i tried to compile your examples using HotKeyCamo.
I'm Using Autohotkey Version 1.0.48.03 Running On Windows 7 64Bit(i suspect thats the problem). I've never modified AutoHotkeySC.bin in any way.


Anyway, great work dude! even if it didn't worked for me, i think this app is great & really you're a genius! I've used many EXE Packers to encrypt my EXEs created using AutoHotkey to prevent decompiling by 'Real Decompilers'. This tool is great! But unfortunately it doesn't work for me!

Help Me Please!
Posted Image

Don't Take Life Too Seriously,Because In The End, You Won't Escape It Alive Anyway ;)