Jump to content

Decompilation question


Recommended Posts

Hello,

I've been testing and spending many hours enjoying AutoIt. I'm currently thinking about how it might benefit some open and closed source apps that I'd like to make available.

While I do see there is an [ ] Allow Decompilation checkbox, from my understanding so far there is a scripting engine running under the hood, and I'm gathering that the structure of the script is still somewhere packed in the executable, rather than being literally compiled into pure code?

With Java, for example, you can either leave in or remove the debugging information, but the language itself is extremely susceptible to decompilation. If the debugging info is left in you have usually an identical copy of the original source. Without the debugging information, the variable names and so forth are lost, but the general program is still intact.

Perhaps I missed a section of documentation somewhere, but I didn't get a clear sense of the actual level of protection that the AutoIt source enjoys. If someone had a desire to decompile an AutoIt compiled program (with the Allow Decompilation de-selected), how easy would it be, and what barriers are there?

It would help to get a better sense of how and to what degree the source is protected, particularly for use in corporate environments and commercial applications. Open Source ones, speaking in the direction of the GPL, of course, don't have those particular requirements.

Your input appreciated. And kudos for AutoIt itself.

Link to comment
Share on other sites

it's not safe.

<{POST_SNAPBACK}>

That's too bad. That would seem to indicate it's more of use for Open Source and custom in-house software. Open Source=good thing, however it would have been nice to be able to use it for non-Open Source projects as well.

Are there any particular philosophical leanings of the AutoIt developers (with regard to AutoIt) toward Open Source versus Proprietary? I'm gathering the method of growth from AutoIt's batch roots has by default kept it in the Open Source framework.

With the official demise of VB6, interesting opportunities abound.

Link to comment
Share on other sites

On a related tangent, I tripped over Morphine 2.7 by Dirk Paehl. (Disclaimer: I do not know him. I do not know whether his programs are safe. Caution)

Are there any benefits to this technique, or is it just one more level of obfuscation which can be unravelled? Does it add any level of difficulty to the process?

I would imagine that unless you take protective measures, that once the script is loaded up for execution in RAM that it is vulnerable; But that brings to mind protective measures taken by PGP corporation regarding key caching (RAM/Swap, etc.)

Link to comment
Share on other sites

Morphine looks interesting, thanks for the link.

"I thoroughly disapprove of duels. If a man should challenge me, I would take him kindly and forgivingly by the hand and lead him to a quiet place and kill him." - Mark TwainPatient: "It hurts when I do $var_"Doctor: "Don't do $var_" - Lar.
Link to comment
Share on other sites

As mentioned before: Compilation only adds an EXE-wrapper to the AU3-file. If you choose to provide a passphrase (or disallow compilation), then the AU3-file is encrypted before the wrapper is added. But the full source of the script is still in there, including comments, variable names, ...

It's only a matter of time when it's possible to decrypt it. Also one point adds a lot to the problem, as you already mentioned: The scripts needs to decrypt itself when it's run, so everything needed to decrypt the script is also added to the EXE-wrapper.

What you could do to get around this problem is: Write a C/C++ converter that converts AutoIt scripts into C/C++ programs which you can compile into machine code afterwards. It should be possible to do this, but then you could simply write your script in C/C++ which might be easier than to create a converter...

Link to comment
Share on other sites

It's only a matter of time when it's possible to decrypt it. Also one point adds a lot to the problem, as you already mentioned: The scripts needs to decrypt itself when it's run, so everything needed to decrypt the script is also added to the EXE-wrapper.

<{POST_SNAPBACK}>

In its current form, it's almost more of an AutoItX thing I'm thinking of, isn't it. In other words, the master executable (in whatever language) executing AutoItX instructions, as there is less/nothing to decrypt except what functions are called with what parameters.

But AutoItX is a subset of AutoIt. Makes me tangent about thinking of a master executable that dynamically spawns AutoIt compiled programs, wherein the entire package is itself code & encrypted. Thinking aloud, wouldn't that then mean that the vulnerability exists primarily in RAM once the fork/call occurs to the compiled au3 which decrypts in RAM the script (which was, in turn, decrypted with the AutoIt decompiler/decrypter + the compiled/encrypted au3, when the master executable invoked it?)

I'm not trying to be convoluted for its own sake. :)

Perhaps... an Istool created Inno compiled install of a C++ program which has encrypted in its belly one or more AutoIt3.exe compiled au3 scripts....

It would be fun if the features of AutoIt and Inno Setup could be combined. But AutoItX could definitely be called from ISTool/Inno Setup as it stands now. Or compiled AutoIt3 au3 scripts could be invoked in the Pascal scripting process. Together I think Istool/Inno and AutoIt/AutoItX would make a powerful tag team combo.

Edited by warmfuzzy
Link to comment
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
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...