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
Mobius
  • Members
  • 97 posts
  • Last active: Jul 31 2015 01:53 PM
  • Joined: 08 Jun 2008
Thanks jNizM
Posted Image

Sergo_bro
  • Members
  • 6 posts
  • Last active: Nov 17 2014 05:11 PM
  • Joined: 09 Mar 2014

AHK_L turns on this compiler does not work?



Kudos
  • Members
  • 39 posts
  • Last active: Sep 27 2015 09:06 AM
  • Joined: 21 Aug 2006

I have the same error when trying to compile with AHK_L

http://ahkscript.org/download/

 

Error line 287
The following variable name contains an illegal character: "ushort""
The program will exit.
 
Please Mobius - can you fix this? I love HotkeyCamo!
 
Thanks :)


MyDream
  • Members
  • 6 posts
  • Last active: Nov 28 2014 04:52 PM
  • Joined: 02 Mar 2009

I wonder will HotkeyCamo have an update to support AutoHotkey L now.



Mobius
  • Members
  • 97 posts
  • Last active: Jul 31 2015 01:53 PM
  • Joined: 08 Jun 2008
Well after months of searching old backups I finally found my password for this place.

Lets lay this Ahk_L confusion issue to rest once and for all.

The original AutoHotkey by Chris (Which HotkeyCamo supports) used an archive like algorithm for storing
the script data. HotkeyCamo is entirely dependant on that algorithm in order for it to delay tools like
decompilers which are also dependent on the same algorithm.

Now you guys have Ahk_L from which the current maintainer of the Ahk source decided to remove the archive
algorithm in favour of embedding your script in plain text into the resource table of the interpreter.

When using HotkeyCamo with Ahk_L there are no algorithmic op-codes for it to work with in the builder
(Ahk2Exe) or the interpreter, in fact there is every possibility that HkC can damage an Ahk_L standalone
if by some chance it finds a matching op-code (which for Ahk_L will not be correct).

To prevent this potential damage you can disable the HkC's internal archive randomiser by ticking the
disable Camo checkbox located at the bottom of the "Main" tab, or adding HKC_NO_CAMO = 1 to your build
config, Even then I have not tested the last release with Ahk_L so whether this will fix the USHORT
problems that have been reported is a mystery.

However since there is no protection applied by HkC (which is its only trick to play) you are better off
using other builder wrappers available if you are an Ahk_L user. Unless of course you actually like HkC
as a tool which I doubt.

While I have started work on bringing HkC up to the level of AutoCamo (AutoIt version) the only so called
protection offered by it where Ahk_L is concerned can also be obtained by using any other type of software
armouring tool such as packers - crypters and bloaters (oh my lul), plus there is no public decompiler
available for Ahk_L (outside of dumping the process realigning the dump file and using a resource editor)
so I ask myself what is the point of trying to defend (no matter how meagre) that which does not want to
be defended.

Just about the only thing I started where Ahk_L is concerned is patching the native function names in the
interpreter and the source file before build (which works because Ahk does not use tokens for comparison)
but that is a great deal of effort for something that can be reverted in about ten minutes by a skilled
interrogator (or someone with half a brain, the source, and a string dump of the interpreter).

Basically what I am saying is don't whine at me that HkC does not work with Ahk_L (if protection is what you seek)
whine at the maintainer for imposing open source ideology upon the product you have chosen to craft your work,
or put another way take responsibility for the product you choose to use, instead of the plethora of equally
simple to use languages that can create truly compiled binaries at the expense of effort and time from the user.

An update of HkC is coming because as a tool it is riddled with bugs (I only code when I'm off my tits, sorry it is
the only way I can justify it to myself in this day and age), but it is still only going to support the
original Ahk (whether anyone uses it or not) for obvious reasons described above.

@MyDream Hello again dude, if I come up with anything regarding Ahk_L you will be one of the first to know,
as I did for AutoCamo ;) .

@ Da Rest, these are the way things are, not how I wish them to be, my bad I guess.

Vlad
Posted Image

homingProxyMine
  • Members
  • 4 posts
  • Last active: Jul 11 2015 11:24 AM
  • Joined: 27 Jun 2015

Is this still being updated? If not, can anyone provide a download link to the latest version and what version of AHK was compatible with?



guest3456
  • Members
  • 1704 posts
  • Last active: Nov 19 2015 11:58 AM
  • Joined: 10 Mar 2011

An update of HkC is coming because as a tool it is riddled with bugs (I only code when I'm off my tits, sorry it is
the only way I can justify it to myself in this day and age), but it is still only going to support the
original Ahk (whether anyone uses it or not) for obvious reasons described above.


I still use HkC with AHK Basic (AHK 1.0) so I would appreciate any updates
 

While I have started work on bringing HkC up to the level of AutoCamo (AutoIt version) the only so called
protection offered by it where Ahk_L is concerned can also be obtained by using any other type of software
armouring tool such as packers - crypters and bloaters (oh my lul), plus there is no public decompiler
available for Ahk_L (outside of dumping the process realigning the dump file and using a resource editor)
so I ask myself what is the point of trying to defend (no matter how meagre) that which does not want to
be defended.


fair enough.

one AHK_L (AHK 1.1) decompiler is here:
http://autohotkey.co...payload-method/
 

Basically what I am saying is don't whine at me that HkC does not work with Ahk_L (if protection is what you seek)
whine at the maintainer for imposing open source ideology upon the product you have chosen to craft your work,
or put another way take responsibility for the product you choose to use, instead of the plethora of equally
simple to use languages that can create truly compiled binaries at the expense of effort and time from the user.


HotKeyIt has a fork of AHK_L, his is named AHK_H, and he has recently offered some type of source protection/encryption. But to use it, you need to change the password within the c++ source and then compile your own AHK executable to use:
http://ahkscript.org....php?f=5&t=6013
 

Is this still being updated? If not, can anyone provide a download link to the latest version and what version of AHK was compatible with?


the latest version that HkC works with is AHK 1.0.48.05
http://ahkscript.org/download/1.0/