34 replies to this topic

[Fossil Rock]

You still see exe2aut because you *probably* installed it over your previous installation of AutoIt (the exe2aut file is probably from the previous installation)... Try uninstalling and then reinstalling.. you'll see that its gone... and the fact that exe2aut has indeed been removed is listed in the version history of the file...

Not true... and the only thing removed was the ability to decompile any files after v3.2.5.1.

[Koshy John]

Not true... and the only thing removed was the ability to decompile any files after v3.2.5.1.

My mistake... I came rushing back to edit it... but I'd already been spotted...

[Koshy John]

Here's the direct link to the history of the stub:
http://www.autoitscript.com/autoit3/docs/history.htm

[Fossil Rock]

And here's the exact information contained in the link...

24th August, 2007 - v3.2.6.0

* Changed: IconId in all GUI functions is now the same as GUICtrlSetImage().

WARNING: Previous scripts using GUICtrlSetImage(), GUISetIcon(), TraySetIcon() and TraySetPauseIcon()
may display a wrong Icon. To get the same icon "if nId > 0 Then newId = - nId - 1".

* Changed: AutoIt .a3x and compiled script format. Exe2Aut will only decompile 3.2.5.1 and earlier files. No ExeAut utility is supplied for ongoing versions.
* Changed: General performance improvements (currently around 30-40% over 3.2.4.9)
* Changed: Limited Unicode support added in regular expressions.
* Changed: ControlMove() just resizing as WinMove() if X=Y=Default.
* Changed: PCRE engine updated from 7.0 to 7.1
* Changed: Suppress delay when speed=0 in MouseMove().

In this version (3.2.6.0) it clearly states it will only work for versions 3.2.5.1 and older, not that it has not been included. Apparently the util will not be included in any future versions.

[Jon]

I am just wondering the general thoughts or motives of everyone on this matter. If you want something compiled to bytecode or whatnot, why not just use Visual Basic? Or are we attempting a freeware Visual Basic?

I personally think this is a move in the wrong direction. I have already seen the general opinion of AutoIt on security forums and the like. Making the signature of a file even more difficult to read just seems a little... I do not know... counterproductive maybe?

The signature of a compiled file is perfectly static. By accepting a EULA all the major AV companies and any that request it have access to the format headers and documentation of a compiled script and can decide on the best way to create signatures. They also have access to methods to determine what a script does. This is done with my help - this has not changed.

I realize a lot of people love AutoIt and want to make commercial programs with it or perhaps sincerely just want to hide its source, but hiding what an automation language is doing is a sure way to get someone to label this movement incorrectly.

Sounds like you are saying noone should be able to release software in .exe format. I'd better throw away my C compiler.

So, in the newest version then are our wrapped EXEs no longer able to be decompiled or is it just that Exe2Aut is gone?

The format is different for a number of reasons (performance, security and to support future optimizations). The way that the orginal file format was cracked was by stepping through Exe2Aut.

If the compilation is different, I will be sticking with my 3.2.4.9 version. I have no intentions of offering closed-source software.

Bizaare statement. If you are committed to offering open source software then relying on some mangled white-space and comment stripped Exe2Aut version of the source is a nonsense. You should be suppling the script files or having all the files FileInstalled() so they can be used properly.

NOTE: Wait a second... I just download the latest (regular) version. Exe2Aut *is* there. What am I missing?

The version of Exe2Aut that is supplied only decompiles 3.2.5.1 and earlier scripts.

[Jon]

Exe2aut has finally been removed from AutoIt... As per the latest version: 3.2.6.0
Thank you Jon!!!

psst: have you implemented bytecode like functionality fully... not that i'd make any difference to me at the scripting level... but just curious since you once said you were nearly done with it... and u were just ironing out some problems...

It's a sort of byte code yeah.

[Jon]

And here's the exact information contained in the link...



In this version (3.2.6.0) it clearly states it will only work for versions 3.2.5.1 and older, not that it has not been included. Apparently the util will not be included in any future versions.

The util will be included for old scripts, but it won't be updated to decompiled 3.2.6.0 scripts.

[Jos]

... If you are committed to offering open source software then relying on some mangled white-space and comment stripped Exe2Aut version of the source is a nonsense. You should be suppling the script files or having all the files FileInstalled() so they can be used properly.

I will make a new version of AutoIt3Wrapper available soon that will have an additional directive which will store the original sourcecode in the Program Resources using reshacker to allow people that insist on "including" the source with the EXE an easy option to do so.

Edited by JdeB, 26 August 2007 - 07:47 PM.

[Fossil Rock]

The util will be included for old scripts, but it won't be updated to decompiled 3.2.6.0 scripts.

Thanks for clarifying all this.

[fowmow]

The signature of a compiled file is perfectly static. By accepting a EULA all the major AV companies and any that request it have access to the format headers and documentation of a compiled script and can decide on the best way to create signatures. They also have access to methods to determine what a script does. This is done with my help - this has not changed.

I mistakenly referred to a compiled EXE's "bytecode" or contents as a "signature."

Sounds like you are saying noone should be able to release software in .exe format. I'd better throw away my C compiler.

Not at all. If C was an automation language, I would have problems with someone attempting to make them harder to examine as well.

The format is different for a number of reasons (performance, security and to support future optimizations). The way that the orginal file format was cracked was by stepping through Exe2Aut.

That is great for those who wish to *protect* their source I suppose.

Bizaare statement. If you are committed to offering open source software then relying on some mangled white-space and comment stripped Exe2Aut version of the source is a nonsense. You should be suppling the script files or having all the files FileInstalled() so they can be used properly.

In fairness, I did not say that I would *rely* on "some mangled white-space comment stripped Exe2Aut version." I just meant that for whatever reason if the source cannot be found, then my EXE could then be decompiled. Anyone who wished to do this would surely know what to do with it at that point.

I do not agree with Koshy John's silly statement (no offense John!), that someone who does not keep their source or whatever, does not deserve to have had it in the first place. If I write an application, offer it for download and then my house burns down, does that mean I do not deserve my source?

I can always redownload my application, decompile and go through the laborious process of commenting it again or adding to it, bug-fixing, et cetera.

The version of Exe2Aut that is supplied only decompiles 3.2.5.1 and earlier scripts.

Thanks. And again, in fairness this is why I will not be upgrading. If I happen to use some features only available in >3.2.5.1, then I automatically lose the ability to decompile in the above scenario.

Believe me though, I love AutoIt. In fact, I have already downloaded the newest version (obviously) and plan on seeing what its fundamental differences are and playing with it a bit. Which actually leads me to my next response to JdeB.

So, there is my meager $0.02 worth of opinion. Take care, Jon.

Is it odd to find it cool as hell that I actually conversed with Jon? I seem to get this way around *all* talented programmers.
When I first met Mark Russinovich, Mark Thompson, Bjarne Stroustrup, Miguel de Icaza, countless talented Microsoft programmers, assorted "MVPs" or whatever they call themselves nowadays, and several tens of lesser-known talented programmers, I found myself grinning like a fool. *shrugs*

[Lazycat]

I do not agree with Koshy John's silly statement (no offense John!), that someone who does not keep their source or whatever, does not deserve to have had it in the first place. If I write an application, offer it for download and then my house burns down, does that mean I do not deserve my source?

I can always redownload my application, decompile and go through the laborious process of commenting it again or adding to it, bug-fixing, et cetera.

Maybe this was too loud sentence, but basically it still correct.
You deserve your source, but anyway you should in first place take care that your source will be safe. You write: "I can always redownload my application, decompile and go through" - but who stops you just attach source to archive and then just redownload it and edit without redundant steps like decompilation? If you want even more safety, create sourceforge project - and access your code anytime and anywhere. And don't forget about backups: DVDs, USB sticks, FTPs, online storages - you have enough ways. You definitely go this way for C and other language, why Autoit should be an exception to the prejudice of security and speed?

[Koshy John]

I do not agree with Koshy John's silly statement (no offense John!), that someone who does not keep their source or whatever, does not deserve to have had it in the first place. If I write an application, offer it for download and then my house burns down, does that mean I do not deserve my source?

No offence taken as I see you've hinged on the word "deserve". You'd probably deserve your source in such a scenario, but you'd still deserve to pay the price for not taking care to make redundant copies of code in physically separate locations. Many people, including me, have learned the value of a backup when they didn't have one to revert to when their precious code's lost. In my opinion, the earlier a person learns that in his/her coding career the better.

Currently, I do daily backups of my code on the same machine (to protect against errors that I introduce unknowingly and am unable to remove easily). Physically discrete backups happen may be once in 2 months (I guess I'm yet to learn to increase the frequency the hard way )

It's a sort of byte code yeah.

Congrats Jon (and a HUGE THANK YOU)!!!!!! This is a major milestone for AutoIt... Sadly only the few people who clamoured for it (and the few who opposed it) will know its significance right now...

[socratessa]

I found this topic through search because what i want to know if it is still possible to decompile scripts?

I dont want links to methods that can do so.
I simply want to know when i compile my scripts password protected can somebody else decompile it anyway?

[Zedna]

I found this topic through search because what i want to know if it is still possible to decompile scripts?

I dont want links to methods that can do so.
I simply want to know when i compile my scripts password protected can somebody else decompile it anyway?

In release version 3.2.6.0 (or beta 3.2.5.2+) has changed compiled format.
From that version Script is not stored in EXE as AU3 source but as bytecode.
So if somebody want AU3 sources from EXE he must write his own decompiler for bytecode --> AU3 conversion.
And therefore "Allow decompile & Passphrase" options has no meaning for these new AutoIt versions.

[socratessa]

Thanks thats the answer i wanted to hear