Hide my code in the .exe

[Comatose]

Basically looking for a way to hide my script being in the .exe after compiling. I've wrote a security program and it really
don't make much sense to have my script just sitting there ready to be cracked.  Please be descriptive if you have any ideals ...
 

[Jos]

2 hours ago, Comatose said:

Please be descriptive if you have any ideals .

Please use the search first as this has been discussed ample times!  

Bottomline: Compiled AutoIt3 programs are not secure and should never be use for sensitive information. 

Jos 

 

Edited February 21, 2020 by Jos

[Comatose]

Would have been nice to know that 15 years ago. 

I have looked around. Thus the post ...
Nothing I have found seem to be to very descriptive.  Could you at lest provide a link .. Also why isn't a programming language secure.
No wonder so many add bugs and viruses with AutoIt. It would seem anyone could change exiting programs by simply meddling
with someones script in a released program. I always thought it was programmers with no morals. Didn't know the backdoor was wide open.
That is such a shame .. Have always loved AutoIt. 

[Comatose]

I've went ahead and did as you said and looked deeper into this. Once again nothing was very descriptive. I could really use some help here.
Possibly just aim me in the right direction. Is there a "pro" version of AutoIt with security. I would be one of the 1st in line to buy it. 
I work with AutoIt most everyday and have been for a very long time. It would be an honor to support it.

Edited February 21, 2020 by Comatose

[jchd]

Welcome to the wonderful world of computers!

Once a program exists that is built to run on a fully known hardware under a fully known OS, there is nothing on Earth that can block someone having access to both the program and the hardware specifications from setting up an environment (e.g. a debugger, a simulator, an emulator, whatever) allowing a complete reverse-engineering of said program, ruining any attempt to "hide" itself from preying eyes. Of course, any hardware or software complexity introduced to make the process harder will inevitably increase the time or cost of the reverse-engineering.

What that means is that we're in a bullet vs. shield situation: the harder the shield, the more expensive the bullet.

The moral in every security issue is: determine the price that the attacker would gain by stealing your "secret" and put obstacles in place to make the cost of buglary significantly higher. That applies as well to every program, whatever language and platform. AutoIt is cheap in this regard since it doesn't embed a strong enough barrier to make access to the source particularly hard, but other development toolchains don't escape the rule even if some are by construction more expensive to reverse-engineer.

[RTFC]

If the aim is to restrict an AutoIt programme to a specific, secure(!), sanctioned environment, you may find CodeCrypter of use (link in my signature below).

[Comatose]

@jchd ... Thank you for the response. I'm 55 and I've been programming all my life. I started on the Amiga and have a few degrees.
AutoIt is a bear most the time but it reminds me of my beloved Amiga language AmosPro (minus the graphic abilities). So I fully understand
what you are saying. However I've never tried to crack an AutoIt program and when testing was a bit shocked to see the script just sitting there.
It would seem to have zero security or "shield". My question was is there anything I can do about this other than what I've already found ...
Starting to look like I'll just need to re-code this in another language. I was hoping to find somewhat of a solution here.

@RTFC ... Thank you for the link. It's would seem all the links to that Obfuscate tool are dead. I take it this is what CodeCrypter is doing.
So at least it's a step in the right direction. As far as something I can do. Was hoping for a better solution but sure will look into that.
Again thank you for your time and direction.

  

Edited February 22, 2020 by Comatose

[jchd]

Look at what @RTFC pointed to: that isn't just code obfuscation but a serious layer for code security. That will certainly block sister kid and more advanced street hackers from getting the code but nothing will stopped a determined and resourceful opponent.

Any code interpreter (strictly speaking) has to parse and execute source code. AutoIt being an interpreter, it's plain that the source code has to be embedded in some form inside the .exe file.

Edited February 22, 2020 by jchd

[argumentum]

..could not help myself @Comatose, had to write back my 2 cents.
The most you can do, is code in language that compiles to machine code.
But as far as I know, multi-million dollar software development got cracked, keyGen, loader, etc. and there is not much one can do about that.

See if you can "web-it" (SaaS), and that, could help a lot since you'd have an API or "call-home" of sorts and having your code would not be so harmful if it came to that.

Or a radical approach: open source it. And have ppl pay for support.

In any case I have no idea of how or what your app. does, this is just my 2 cents. Or even less.

[RTFC]

Just to clarify:

What makes CodeCrypter different from other encryptors is not the algorithm (Ward's machine-coded AES at the moment, but watch the thread...), but that the decryption key is not stored anywhere, but instead extracted at runtime from the user environment, using a function, macro, UDF, dll call, or whatever else you can think of (password query, hardware ID, server response, @year&@mon (=automatic expiry), or a combination of several encryption keys).

So the code will always be decrypted, but produces utter garbage unless whatever your function/macro/etc returns from its current environment exactly matches whatever was used at the time of encryption (you can specify this explicitly; it doesn't have to be the machine you happen to be encrypting on).

The basic scenario is an office computer running a CodeCrypted script with admin privileges to receive system-info (for the decryption key) that an ordinary user cannot access on that machine. If an employee then copies that code and takes it home for personal use or for selling on to third parties, it won't work anywhere else (even with admin privileges elsewhere), because the retrieved environment specs will always be different. So the strength of the encryption algo is unimportant. The only weakness is physical access to the sanctioned machine/work environment; if a thief steals the workstation itself and takes it apart to retrieve the motherboard serial number (if that's what was used), or a hacker blackmails the sysadmin with what happened with the goat at the Xmas office party last year, all is lost. The point is (as @jchd pointed out) to raise the bar so the h/cracking effort is no longer worth the reward.

Edited February 24, 2020 by RTFC
typos

[Skysnake]

Why not simply make it open source? 🙃