Decompiling

[HotKeyIt]

Those files should not be there, I have removed them, this is the correct file, thanks for pointing out.

[Mobius]

If each character of the password is stored as an individual and an identical character (within the password) is used as an individual within the source then post optimization that same character will only exist once in the binary and be used as an individual reference point for multiple code procedures, the same actually if the password is a string that is used multiple times within the source post optimization.

If this is indeed the case then I have wasted everyone's time and patching is indeed very difficult without breakage somewhere else.

Response to your edit:
Zip is an algorithm is it not , this is ofc moot if the above is true.

[HotKeyIt]

The idea was that not only the password should be changed when recompiling source but also how it is assigned to variables, so instead of simply assigning a character you could call a function or apply some algorithm that makes the password for you.

EDIT:
Yes, zip is algorithm but it does not apply to the password

[Mobius]

Thankyou very much for your time HotKeyIt I think I should take a much closer look before posting further!

Ed: I was kinda hoping this wouldn't be as cut and dry as it first appeared, unlike hybridization of the original AutoHotkey payload algorithm

[guest3456]

The idea was that not only the password should be changed when recompiling source but also how it is assigned to variables, so instead of simply assigning a character you could call a function or apply some algorithm that makes the password for you.

But does it even matter? I mean the ahk2exe compiler requires you to input the password as a normal string that is used to unencrypt the scripttext so that the executable can even run

[HotKeyIt]

Yes but the password is saved in executable only, I think it is more difficult to find out the password if you apply more security, even just moving the assignments to different place or randomizing it, e.g.:

Code: Select all

	g_default_pwd1 = L'u';
	g_default_pwd5 = L'o';
	g_default_pwd4 = L'H';
	g_default_pwd2 = L't';
	g_default_pwd8 = L'e';
	g_default_pwd9 = L'y';
	g_default_pwd3 = L'o';
	g_default_pwd0 = L'A';
	g_default_pwd6 = L't';
	g_default_pwd7 = L'k';

[guest3456]

for reference for those reading

normal AHK 1.1 scripts compiled with the ahk2exe (non AHK_H), can be easily viewed by simply looking at the RCData resource in the executable, with a tool such as Resource Hacker

alternatively, you can use the decompiler to extract the script's code, gotten from this thread

HotKeyIt's AHK_H build aims to offer an alternative with some protection from this by encrypting the resource. both the Resource Hacker and the decompiler fails on AHK_H encrypted exes

finally, users of the older AHK 1.0 (AHK_Basic) can get some protection by using HotKeyCamo by Mobius

[Mobius]

Unfortunately what I've seen of Ahk_h the methodology behind the password better serves obstruction of post compile manipulation rather than obstructing the acquisition of the password as one only needs to trace the references to the character's in a debugger.

My advice would be to build a wrapper around the dll version of this product (which is mighty fine IMO) and impose your own algorithm (whatever you choose) for source acquisition as the primary or a secondary layer of obstruction.

This is of course only relevant to those that do not wish to delve into vs2010 in which anything is possible thanks to the generously open source nature of this product.

[HotKeyIt]

Unfortunately what I've seen of Ahk_h the methodology behind the password better serves obstruction of post compile manipulation rather than obstructing the acquisition of the password as one only needs to trace the references to the character's in a debugger.

Therefore I have implemented some anti-debugging features that should make it a harder, we all know there is no way to protect it 100%.

The way AHK_H protects script does make it difficult to write a tool that will decrypt any script.
It is up to the user do add more security to the source code and apply some algorithm or function that generates the password, so it makes it very hard to get the code for a non hacker.

Have you tried to get the password in debugger? Did you succeed? Did you manage to get the script?

[guest3456]

My advice would be to build a wrapper around the dll version of this product (which is mighty fine IMO) and impose your own algorithm (whatever you choose) for source acquisition as the primary or a secondary layer of obstruction.

I did this for another one of my projects. I used a simple AHK_Basic wrapper script, compiled/protected with HotkeyCamo. This wrapper would connect to my website, and upon license verification, it would download an encrypted version of the actual script code. The code would be decrypted by the wrapper and then run dynamically through AHK_H.dll

I was hoping to avoid this type of hack with this new AHK_H

[drawback]

Hello!

Sorry for asking dumb questions but I'm new to all of this

Can somebody give a brief overview (step by step) of what I need to do exactly to get a AHK_H version that is able to encrypt the source code of a project by using a different password than the default?

HotKeyIt posted instructions:
1. Download
2. Extract ahkdll-v1-release-master.zip
3. Copy ahkdll-v1-release-master\Win32w\AutoHotkey.exe to ahkdll-v1-release-master\Compiler\Ahk2Exe.exe
4. Double click Ahk2Exe.exe
5. Select correct Base File (.bin)
6. Use compression or/and encryption checkboxes.
7. Press > Compile Executable <

Ok, I did all this (with https://github.com/HotKeyIt/ahkdll-v2-r ... master.zip instead of the v1 release)
I used a simple .ahk script to see if it works:

Code: Select all

a := "Test stringg"
StringTrimRight, a, a, 1
MsgBox, % a

But whatever .bin file I select:
v2.0.0.0 Ahk2Exe.exe (..\Compiler)
v2.0.0.0 Ahk2Exe.exe (..\Win32w)
etc.

I immediately get this error after clicking on "Compile Executable":

Code: Select all

Error: The script contains syntax errors.

StringTrimRight, a, a, 1
(4) : ==> Call to nonexistent function.

     Specifically: StringTrimRight

What am I doing wrong?

[HotKeyIt]

You are using AutoHotkey v2 and try to compile script that is written for AutoHotkey v1!

[drawback]

Emmmm, ok, I got it, old syntax is gone... Rewriting the example to e.g. SubStr() works fine

[Guest078]

Hi,

I've recompiled AutoHotkey with a different password and it works fine when I use it as Ahk2Exe.exe from the compiler folder

I'm used to compile my scripts with a build script (a .bat file) from within Sublime Text. Is there any chance that command line parameters will be supported, HotKeyIt?
Like:
ahk2exe.exe /in "<file name.ahk>" /out "<different file name.exe>" /pwd "<the password that was used for recompiling AutoHotkey>"?

Ofc no GUI would be shown and error messages would be directed to standard out (konsole), not with a message box...

This would make building so much more convenient...

Regards,
Stephen

[HotKeyIt]

Compile Ahk2Exe.ahk and it should work, otherwise you have to pass ahk2exe.ahk as parameter for ahk2exe.exe!

[Guest078]

Compile Ahk2Exe.ahk and it should work

Can't get it to work...

- I've copied my new AutoHotkey.exe (with changed password) to ".\Compiler"
- Renamed it to "Ahk2Exe.exe"
- Started it
- As the source file I use the "Ahk2Exe.ahk"
- As destination: "Ahk2Exe_new.exe"
- I use the new password for "Encrypt." and compile it
- Delete "Ahk2Exe.exe" and rename "Ahk2Exe_new.exe" back to "Ahk2Exe.exe"

When I now invoke Ahk2Exe.exe from the command line I get this error:

Error: The AutoHotkey build used for auto-inclusion of library functions is not recognized.

D:\Tools\AutoHotkey_H\Compiler\..\AutoHotkey.exe

I tried it with the files that are included in "https://github.com/HotKeyIt/ahkdll/tree/alpha"
and with "https://github.com/HotKeyIt/Ahk2Exe/tree/alpha" (deleting the compiler folder before)

I guess I did something wrong?

[HotKeyIt]

I have pushed a fix, download the files again and try now.

[Guest078]

Thanks!

With the fix I don't get the error message any more

Unfortunately, something still isn't working as expected (or I don't understand correctly how to call Ahk2Exe)...

Let's assume I changed the password from AutoHotkey to ButoHotkey
(by changing g_default_pwd0 = 'A'; to g_default_pwd0 = 'B'; and recompiling the project)

I compiled the fixed Ahk2Exe.ahk and when I invoke it's .exe file and compile a testscript
from the GUI (I'm using the "ButoHotkey" password here) the testscript's .exe
- Works fine
- Is fully encrypted (I looked at all RCDATA entries with Resource Hacker)

When I try to do the same from the command line by:

Code: Select all

Ahk2Exe.exe /in "D:\Tools\AutoHotkey_H\Compiler\_testscript.ahk" /out "D:\Tools\AutoHotkey_H\Compiler\_testscript.exe" /bin Ahk2Exe.exe /pass ButoHotkey

- The resulting .exe still works fine
- But it's script is fully visible in one of the RCDATA entries

<- Too dumb to call Ahk2Exe correctly?

[HotKeyIt]

That was a bug, fixed now

[Guest078]

That was a bug, fixed now

Confirmed, works fine now! Thanks for creating AHK_H + the support!