AutoHotkey Community

Topic split from "Low-level Script Engine Access -- incl. Dynamic Expressions" by Lexikos

this is amazing... thanks. while this opens many new opportunites, i am worried about the internals of AHK being discussed in public. IMHO, you could have chosen the "appropriate section" of our forum. please consider. thanks again for your wonderful contribution. :)

sent pm

What is the "appropriate section"? This is still an AutoHotkey script.

Plus, this goes back to the debate of having a developers section. Perhaps only seen if you log on. Then AutoHotkey design issues could be discussed there.

2Moderator
I am sure you don't know what are you talking about. This is yet another script, and module, and as such it belongs here.

_________________

...why is everyone so centered on being "stdlib compliant"...what should be done...is call the script LowLevel.ahk...as it is, but add a blank function LowLevel_Init()...then in each script that wants to "use it"...& doesn't want to use #Include...just include a call to LowLevel_Init()...the call will do nothing, but load the stblib file LowLevel.ahk...then all the functions in the script don't need a prefix...I'm really not sure why the functions don't have more useful names, but they don't all need a prefix to be "stdlib compliant"...

This script has nothing to do with development of AutoHotkey. It is based on features of AutoHotkey that already exist. As majkinetor says, it is "yet another script."
Because it is convenient. I already explained why I named the script as I did, and what name to use to make it std-lib compliant. I also said I would hear out name suggestions, but I have decided to leave the functions named as they are.
Since that is a simple solution, I have added it to the script. It also ensures that __init() is always called...

In some cases it would be more appropriate to simply copy the needed functions into the user script.
Could you give an example of how a name could be more useful?

Given that the functions aren't really united under a single purpose, I am against adding a prefix.
"Moderator!" was worried that the script may make it easier for "the bad guys" to exploit scripts. It does allow the script to "exploit" itself, but not some other script. We have talked in private, and I believe there is no longer an issue.

What do you mean by "exploiting scripts"
As script is text, anybody can change it anytime. Moderator actually ment what he said:


This is not the first time I see such behavior here and it has nothing to do with sanity. Acctually, it is contraproductive as talking about internals of AHK publicaly may just lead to good results (ppl becoming more familiar with internals may lead to more ppl influencing development of AHK)

_________________

omg how useful! thx for that module!

Naming tip: "a.ahk"
Functions: a_expr(code)

you are not the first to point that out. he has explained what he did, as well as made a wrapper function to allow normal stdlib use.

_________________

(Common Answers) - New Tutorials Forum - Humongous FAQ

That was more or less my point, but "Moderator!" needed clarification on one point: the script can not be used to access ("exploit") external - i.e. compiled and password-protected - scripts.
Indeed, but not all of what he said was in public...

actually there are tools out there which allow to decompile even password protected ahk scripts regardless of the password or if the n/a option set

the only way to stop decomplitaion AFAIK 'd be to use a modified upx packer which doesnt store the correct checksum in the final exe

even with this - not so harmless - gpl violating upx packer (its origin licence points out that doing so will revoke any rights granted with gpl) it would still be possible to 'crack' a crypted and morphed ahk complied script, though more time needs to be spend with

well ...

derRaphael

DerRaphael: It is a difficult task: you want your program to execute without a password, but you want to hide the algorithm. You could do several things: insert random, dummy instructions between the original ones, which leave the memory and registers in the state they were originally; compute jump addresses and memory references with obfuscated code; insert code to change memory at store and change it back at each load, but with different instructions, etc. Some games, commercial SW (mostly DRM systems) use variations of these, with varying success. Unfortunately, I don’t know of any free tools to automate the process. You could give it a try...

this is what i found in some other forum:

using morphine and a upx mod on the exe would keep away most of those who try to decompile your script. it wont prevent the final decompressed code to be read out at execution time with a mem dump

but it would prevent most script kiddies using the decompiler ignoring the password since this one wont be able to decompress the file after using morphine's obfuscation

but still .... using a modded upx version wont be the solution to a wide public since this violates their licence.

probably using a different packer like mew could be a solution

as long as the program starts without asking for password at startup, it will be decompilable.

getting back to ahk, using a code obfucator and different packer should do the trick, i think - though havent tried out yet

derRaphael

incredible.

_________________
Joyce Jamce

dynamic function calls seems like works great. AWESOME.

(ps: is even worth responding to 'guest' with username "Moderator!" ???)

_________________
Joyce Jamce