guest3456 wrote:
hey thanks for the reply Mobius, good luck with the autoit3camo. looking forward to your expertise regarding these new ahk_L changes.
some more quotes from lexikos from that same thread linked:
Lexikos wrote:
ruespe wrote:
Lexikos wrote:
This also means that Ahk2Exe no longer supports password protection, and supports compression and encryption only through mpress.exe, if it is present.
Does this mean, that we can't protect our programs any more? And everybody can decompile them with Exe2Ahk or something else?
No. It means Ahk2Exe no longer gives you the
illusion of protecting your script. It means
you can protect your programs. Unlike older versions, there's nothing to stop you from running whatever executable packer or other protection measures you want after compiling the script. Before you could only compress AutoHotkeySC.bin and rely on Ahk2Exe to compress the script and included files. If you don't want to do the research and implement your own solution, you can just
use mpress like I suggested.
Nobody can decompile them with Exe2Ahk. Any tool capable of extracting resources from an executable can extract the script, unless it's been compressed by mpress or some other packer, or some other measure has been taken to prevent it.
and
As of v1.1.01, password protection and the /NoDecompile switch are not supported.
If mpress.exe is present in the "Compiler" subfolder where AutoHotkey was installed, it is used to compress the script executable. This also compresses the script source code (minus any comments), which can otherwise be extracted from the exe file using a PE resource editor.
Thanks for the luck dude, both projects need all they can get.
guest3456 wrote:
so, from my very basic understanding of this all,
1. whatever obfuscation that used to be done with ahk2exe with password protection is now removed.
2. the script text is merely attached as a resource into the exe, and a resource hacker program could easily extract it.
3. the alternative for protection is to use the mpress program which "packs" the exe. i guess this packing is the solution to prevent decompilation.
1. No encoding or compression or byte for byte obfuscation, nothing nada zip.
2. Exactly so.
3. The hell it is, do not I repeat do not put your faith in a single point of defense ever, mpress and upx and many other classes of software armoring tools (except the most advanced bloaters) have a single point of weakness where RCE is concerned, and this is a generic memory dump from the original entry point.
(This single weakness only applies to interpreted languages like AutoIt3 and AutoHotkey where the main application in its original unpacked state is not always the most important focus point to achieve the desired result (decompilation))
Sure from mpress' standpoint the binary itself is partially broken but the portable executable structure (if dumped properly) remains mostly intact, most importantly of which is the resource table.
Shit even if a generic unpack fails to rebuild the resource table to an acceptable level to allow a 3rd party tool to open the binary normally I would just scroll down to the
static resource index normally used for this revision of AutoHotkey within a hex editor (or regex for common instructions) and dump the source from there.
Software armoring tool inspection and circumvention is a too well documented topic (because of malware and because they are phucking cool at what they do) for them to be taken seriously as defense against the dark arts on their own. (which is why I always advocate using SAT's alongside any homegrown obfuscation methods (and optionally HotkeyCamo) for anything that even resembles piece of mind against n00bs)
Plus SAT's come with thier own problems concerning the ever itchy triggered Anti-virus utils.
You guys think Ahk has had/is having a raw deal concerning AV's? You should see what they are doing (along with malicious software of course but thats not the point) to even the least abstract software armoring tools reputation.
guest3456 wrote:
Mobius wrote:
As I recall however the 64 bit editions of Ahk2Exe simply add the source in raw text format in the resource table and if the updated compiler follows this same direction I doubt there is little HotkeyCamo can do for it.
would HotkeyCamo work for this new version of AHK_L at all? or is now HKC only good for previous versions of AHK? is the new solution for AHK exe protection to simply use mpress? i guess this thread is better to ask: how secure exactly is mpress? a quick google turned up one link...
I cannot write a tool to adapt the static nature of another tool if that tool does not want to be protected or does nothing initially to protect itself.
Yes most definitely it seems HotkeyCamo's fate is tied to Chris's original masterpiece and any (main core dependant) hybrids crafted after it from this point backward.
Don't get me wrong I love software armoring tools in general, and mpress is a beautiful packer (equal to the mighty upx in some cases) which is able to get even the most fat ass binary down to an acceptable size (for those of us that still care for such things) but that is about it.
Changing the EXEArc component <- Good Idea (In current AV climate)
Relocating the crippling overlay (tail data) to be read instead from the resource table. <- Cue fanfare.
Respect
Vlad
Login
Register
FAQ
Search
)
but that was quite some time ago and I doubt if that revision is still in use.