Jump to content
Comatose

Hide my code in the .exe

Recommended Posts

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 ...
 

Share this post


Link to post
Share on other sites
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 by Jos

SciTE4AutoIt3 Full installer Download page   - Beta files       Read before posting     How to post scriptsource   Forum etiquette  Forum Rules 
 
Live for the present,
Dream of the future,
Learn from the past.
  :)

Share this post


Link to post
Share on other sites

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. 

Share this post


Link to post
Share on other sites

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 by Comatose

Share this post


Link to post
Share on other sites

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.


This wonderful site allows debugging and testing regular expressions (many flavors available). An absolute must have in your bookmarks.
Another excellent RegExp tutorial. Don't forget downloading your copy of up-to-date pcretest.exe and pcregrep.exe here
RegExp tutorial: enough to get started
PCRE v8.33 regexp documentation latest available release and currently implemented in AutoIt beta.

SQLitespeed is another feature-rich premier SQLite manager (includes import/export). Well worth a try.
SQLite Expert (freeware Personal Edition or payware Pro version) is a very useful SQLite database manager.
An excellent eBook covering almost every aspect of SQLite3: a must-read for anyone doing serious work.
SQL tutorial (covers "generic" SQL, but most of it applies to SQLite as well)
A work-in-progress SQLite3 tutorial. Don't miss other LxyzTHW pages!
SQLite official website with full documentation (may be newer than the SQLite library that comes standard with AutoIt)

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

@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 by Comatose

Share this post


Link to post
Share on other sites

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 by jchd

This wonderful site allows debugging and testing regular expressions (many flavors available). An absolute must have in your bookmarks.
Another excellent RegExp tutorial. Don't forget downloading your copy of up-to-date pcretest.exe and pcregrep.exe here
RegExp tutorial: enough to get started
PCRE v8.33 regexp documentation latest available release and currently implemented in AutoIt beta.

SQLitespeed is another feature-rich premier SQLite manager (includes import/export). Well worth a try.
SQLite Expert (freeware Personal Edition or payware Pro version) is a very useful SQLite database manager.
An excellent eBook covering almost every aspect of SQLite3: a must-read for anyone doing serious work.
SQL tutorial (covers "generic" SQL, but most of it applies to SQLite as well)
A work-in-progress SQLite3 tutorial. Don't miss other LxyzTHW pages!
SQLite official website with full documentation (may be newer than the SQLite library that comes standard with AutoIt)

Share this post


Link to post
Share on other sites

..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.

Share this post


Link to post
Share on other sites

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 by RTFC
typos

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...