35 replies to this topic

[Valik]

Jon's right, he didn't write the limitation. Also, while it's true that it can be disabled by modifying a couple lines, actually removing the code completely (Which is what needs done) is actually a bit of work.

AutoIt is big enough now that in general it's easiest for the person who wrote something to maintain it.

[Richard Robertson]

Valid reasons. I've seen the code for AutoIt when it was last released and it looks complicated enough then.

Side note: I just noticed Valik is like Valid.

[zfisherdrums]

Has there been any movement/resolution to this matter?

[Yusuke]

Hi,

Sorry if I make revive old threads here : I was kindly pointed to this thread by Piccaso (thank you, by the way) when I asked for the historical reasons behind the limitations of Execute : as I thought, it indeed was security reasons.

Well, before being accused of writing a virus, the reason why I would have liked it to properly are in the thread I linked above : shortly put, I needed to have a main script run several scripts in subdirectories (software deployment scripts) and have these scripts interact with a GUI created in the main script. I was hoping to be able to share all the variables accoss the "children" scripts and make them interact with the main GUI in a really easy way. In such a way, we could benefit from a sort of dynamic #include (#include doesn't accept variables), for lack of better term...
Actually, I'm just revamping a system I wrote in VBScript/WSH at that time (VBScript has ExecuteGlobal, a non-crippled Execute) and porting to AutoIt to benefit of this vastly superior language, but I really miss this feature that I found extremely handy in VBScript.

Security is a nice and important thing of course, but actually, I really have difficulty to consider how limiting this function actually helps the security in the end since there are many workarounds to achieve similar results, like embed the AutoIt interpreter using FileInstall and make your script write to a separate file, or even a batch file.
A virus also probably wouldn't need to bother using Execute for the evil code, if it can have it execute itself the normal way.
Using this logic, FileDelete can also be considered a very dangerous function and Run or _RunDos as well, yet they are not limited...

By the looks of it, nobody seems pleased with the current state of this function, not even part of the AutoIt developers themselves.
I can understand that if the function isn't theirs, they are not willing to modify it to be rude to this function's author or simply because of code maintenance reasons, but I wonder if it wouldn't be possible for the author of this function to participate to this thread and have some discussion why this function won't be modified ?
I'm sure many people would like to have a functional Execute function, and I can't believe all of them have evil intends...

Thanks a lot in advance,

Edited by Yusuke, 21 August 2007 - 11:38 PM.

[ssubirias3]

Security is a nice and important thing of course, but actually, I really have difficulty to consider how limiting this function actually helps the security in the end since there are many workarounds to achieve similar results, like embed the AutoIt interpreter using FileInstall and make your script write to a separate file, or even a batch file.
A virus also probably wouldn't need to bother using Execute for the evil code, if it can have it execute itself the normal way.
Using this logic, FileDelete can also be considered a very dangerous function and Run or _RunDos as well, yet they are not limited...

By the looks of it, nobody seems pleased with the current state of this function, not even part of the AutoIt developers themselves.
I can understand that if the function isn't theirs, they are not willing to modify it to be rude to this function's author or simply because of code maintenance reasons, but I wonder if it wouldn't be possible for the author of this function to participate to this thread and have some discussion why this function won't be modified ?

A quick glance over the autoit changelog didn't list this change for Execute() or who the author might be; unless its W0uter? And I'm not sure what the outcome would be if the author said no to removing the limitations despite Jon giving the green light.

Let's just remove the limitations please. I don't like the command but if it's in it shouldn't be limited.

But good points Yusuke, if there's a will there's a way. Like my pappy use to say, "Locks are for honest folk, 'em rascals will still break in if they wanna bad enough."

[Valik]

A quick glance over the autoit changelog didn't list this change for Execute() or who the author might be; unless its W0uter? And I'm not sure what the outcome would be if the author said no to removing the limitations despite Jon giving the green light.

But good points Yusuke, if there's a will there's a way. Like my pappy use to say, "Locks are for honest folk, 'em rascals will still break in if they wanna bad enough."

Since when is w0uter a developer of AutoIt?

Anyway, would the author of this "feature" please remove the limitations. We've been going on for over a year about having the limitations removed or the function removed. I really don't want to rip this out myself (as I'll pull the whole damn function).

[vatobeto]

IMHO, "run" can be used for some of what execute might do, when used in conjunction with other autoit features. Recently I used it for something like this:

CODE

#include <File.au3>
$title = "Connect to timinvermont.com"
$sFilePath = "C:\Temp\spawn2.au3"
$compile = "c:\program files\autoit3\autoit3.exe"
$command = $compile & " " & $sFilePath
If Not FileExists($sFilePath) Then
$outFile = _FileCreate ( $sFilePath )
FileOpen($sFilePath,1)
FileWrite($sFilePath, '#include<IE.au3>' & @CRLF & _
'$start="http:\\google.com"' & @CRLF & _
'$oIE = _IECreate($start)' & @CRLF & 'Exit')
FileClose($outFile)
run($command)
Else
FileDelete($sFilePath)
EndIf

v.

[Manadar]

Since when is w0uter a developer of AutoIt?

Anyway, would the author of this "feature" please remove the limitations. We've been going on for over a year about having the limitations removed or the function removed. I really don't want to rip this out myself (as I'll pull the whole damn function).

I would rather have the entire function removed as well. Also to prevent people from writing entire scripts with every line starting with Execute("..

AutoIt already has the capability to execute. Like this:

FileWrite("temp.tt",'MsgBox(0x30,"Title","Hi!")')
Run(@AutoItExe & " /AutoIt3ExecuteScript """ & @ScriptDir & "\temp.tt""")
MsgBox(0x30,"Title", "Why, hello to you too.")
FileDelete("temp.tt")

Compile this and run it. AutoIt need not already be installed (except for the compiling.. ).

[Valik]

I would rather have the entire function removed as well. Also to prevent people from writing entire scripts with every line starting with Execute("..

AutoIt already has the capability to execute. Like this:

FileWrite("temp.tt",'MsgBox(0x30,"Title","Hi!")')
Run(@AutoItExe & " /AutoIt3ExecuteScript """ & @ScriptDir & "\temp.tt""")
MsgBox(0x30,"Title", "Why, hello to you too.")
FileDelete("temp.tt")

Compile this and run it. AutoIt need not already be installed (except for the compiling.. ).

Actually, this would be my argument why the function should be left in and made non-crippled. Execute does serve a purpose, albeit very limited. I wish it'd never been added, it has, so it needs to be fixed to work correctly.

[Sunaj]

Having dealt extensively with loading small modular code pieces it seems to me that a full-featured Execute() would the only way (as far as I can tell) to load smaller script into a main-script (at runtime) only to execute them later on _without_ loading them from the HD which is not the best solution when instant execution is needed. Thus I would definitely also go pro a non-crippled Execute().

Actually, this would be my argument why the function should be left in and made non-crippled. Execute does serve a purpose, albeit very limited. I wish it'd never been added, it has, so it needs to be fixed to work correctly.

Edited by Sunaj, 06 November 2007 - 08:06 PM.

[lod3n]

There seems to be a consensus that Execute should be fixed. No point in repeatedly agreeing with each other.

Which developer can actually do something about Execute, apart from remove it? Will that developer please stand up?

[eltorro]

Wouldn't removing Execute() kill Obsfucator?

[Valik]

Thread locked, I'm tired of people coming in days later saying things which are pointless to say.

[Jos]

Wouldn't removing Execute() kill Obsfucator?

Yes it would make all Obfuscated code fail.

Jos

Edited by Jos, 09 November 2007 - 03:28 PM.

[Jon]

I just guessed at what was needed and ripped out what looks to be the code that stops certain functions. If it breaks more than that then I'll roll it back.