compiling one script(exe) using the other

[SmOke_N]

mate, can u send me script1.exe then please. The one u have compiled using your auto it version. I am using 3.1.1

You can download the new "Released" version... No sense in working with a belated product.

http://www.autoitscript.com/autoit3/downloads.php

[PsaltyDS]

I am doing more deep coding than you can think off. Obviously I cannot release the details here for security reasons.

Oohh... sooper seekrit schtuff... best finish this conversation under "The Cone of Silence", huh Chief?

mate, can u send me script1.exe then please. The one u have compiled using your auto it version. I am using 3.1.1

So, Agent 86... what did you get when you tried it my way in post #13 (shouldn't matter what version you are using)?

Edit: Tested it and had wrong kind of FileWrite(), so it's been tweaked, but works for me on XP Pro SP2.

Edited August 14, 2006 by PsaltyDS

[bluebearr]

Well, this works. It creates a script2.exe in the same directory as where this script is run.

#include <File.au3>
$domain = InputBox("Question 1 of 3 ", "What is the domain name", "Domain1", "", -1, -1, 0, 0)
$username = InputBox("Question 2 of 3", "What is the local Administrator account named", "", "", -1, -1 , 0, 0)
$passwd = InputBox("Question 3 of 3 ", "Enter the password for the local Administrator account", "", "*", -1, -1, 0, 0)

; Check if AutoIt is installed
$PrevInstalled = 0
$AU3Dir = RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\AutoIt v3\AutoIt", "InstallDir")
If $AU3Dir = "" Then
    ; Install AutoIt
    FileInstall("C:\Temp\autoit-v3.2-setup.exe", @TempDir & "\autoit-v3.2-setup.exe", 1)
    RunWait(@TempDir & "\autoit-v3.2-setup.exe /S")
    $AU3Dir = RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\AutoIt v3\AutoIt", "InstallDir")
Else
    $PrevInstalled = 1
EndIf
$tmpAu3 = _TempFile()
FileWriteLine($tmpAU3, 'MsgBox (0, "", "The information you entered" & @CRLF ' _
    & '& "Domain: ' & $domain & ' Username: ' & $username & ' Password: ' & $passwd & '")')
FileDelete(@ScriptDir & "\script2.exe")
RunWait($AU3Dir & '\Aut2Exe\aut2exe.exe /in "' & $tmpAU3 & '" /out "' & @ScriptDir & '\script2.exe" /nodecompile /pass MyB1gS3cret', @ScriptDir)
Sleep(5000)

; Cleanup
FileDelete($tmpAu3)
If Not $PrevInstalled Then
    If FileExists($AU3Dir & "\Uninstall.exe") Then
        FileCopy($AU3Dir & "\Uninstall.exe", @TempDir & "\uninstall.exe", 1)
        RunWait(@TempDir & "\uninstall.exe /S _?=" & $AU3Dir)
        Sleep(2000)
        FileDelete(@TempDir & "\uninstall.exe")
        FileDelete(@TempDir & "\autoit-v3.2-setup.exe")
    EndIf
EndIf

For your actual script, I wouldn't write out the whole thing with FileWriteLine. I'd keep the static portion of the script as a separate file and just write out the changing portion, then install the static portion, read it to a varible, and write the whole thing after the changing portion in one operation.

Regarding the AutoIt installation, because the license of Autoit specifies:

Reproduction and Distribution. You may reproduce and distribute an unlimited number of copies of the SOFTWARE PRODUCT; provided that each copy shall be a true and complete copy, including all copyright and trademark notices, and shall be accompanied by a copy of this EULA. Copies of the SOFTWARE PRODUCT may be distributed as a standalone product or included with your own product.

I took the tact that you need to install the entire product in order to use the Aut2exe program on a system that doesn't have it.

However, I, along with many others, wouldn't recommend doing it this way. I would write my script to look for a certain file in the directory where it is run (like ScriptName.ini). If the file isn't found, I'd prompt the user for all the credentials, encrypt the data (using the _StringEncrypt function), and then save it to the file. If the file is found, the script would just go ahead and do what you are looking to your script2.exe to do. Then just make sure the techs know that they need to keep that ScriptName.ini file around.

Still not totally secure (since anyone who bothers to decompile the exe can look up the encryption key), but it will deter the majority of the simply curious.

[Confuzzled]

Manav: AutoIt is not secure. Any code you develop using it will not stand the scrutiny of a security aware peer review. Anything using it to store passwords will lower the security of your organisation significantly. Your desire for secrecy is suspect. I stand by my original post, in light of the additional posts you have made.

[ivan]

Thanks for your reply. I tried what you said but autoit3 doesnt have the StdIn and console functions . Also even if they were there I dont think it would be any useful to me.

What I want is this :

I want the values from script1.exe to be passed to script2.exe and it(script2.exe) should retain the value or compile another autoit decompilable script say for example script3.exe with those values. Please note that the script3.exe should then run independently and not be dependent on any other script

OR

Script1.exe after running compiles another decompilable Script2.exe . The values once passed from Script1.exe are used to make Script2.exe. how is that??

Manav:

Apologies to PsaltyDS. I have not slept much these days, so I can't do a simple ctrl+c ctrl+v. This post is directed at Manav. Not that it should matter in a forum..., but apologies offered.

Fuckups like those make me think I should take up political journalism.

I decided to check the last topics I was reviewing, including this one, and realized that you are using the release version. You might want to take a look at the latest beta version, it is, I would say nearly a different language than the release. In the beta you can use i/o, as well as great enhancements such as com object functionality, to name a couple of improvements besides the gigantic set of udfs that have been incorporated, including encryption mechanisms for those things that require security.

Question 1 is, how can someone walk through this forum and not realize that almost nobody uses the release 3.1.1 version anymore.

And question 2, is more pertinent to your problem. Have you evaluated the security risks of your application, and your security mechanisms?

If you are the administrator on your server then there probably is not much of a need to build your application, as these mechanisms are an essential part of Windows servers. Not only can you control client file permissions, but also application permissions, and so on... This is not limited to login data such as usr, passwd. You can also define profiles for groups and the list goes on, so, for some reason, I am skeptical about the robustness of your security. Don't forget that exes can be halted via other mechanisms, ctrl+alt+del, deleting the exe from the cmd, even unregistering it if it is registered, so your security does not sound as what you pretend it to be.

Use regedit to change persm for applications, this subject is quite popular in MSDN, I only just looked at it a couple of days ago. What you could use autoit for is for automating those programs, instead of spending hours doing something that already exists. That way, you end up with a tool that is twice as good, first for robustness and second because you'd have built a custom security policy for your server.

you can also develop software with non admin privs.

Check this link.

IVAN

Edited August 16, 2006 by ivan

[keeskas]

maybe i'm wrong but i think you are looking for a way to automate the "runas" process. if not ignore this message, if so take a look at these utils mentioned on this page: http://www.commandline.co.uk/sanur/

one i used is psexec from sysinternals

if under win xp you can make an shortcut and put a checkmark in the "run under different credentials " (advanced), the program will prompt you when started.

Greetings,

Kees

[ivan]

as keeskas noted, there are plenty of utils to accomplish your task. But then again, one has to consider the security risks you are exposed to, so if your stuff is that important, it will do no harm adding that little extra work with an automated data protecting application.

As I noted above, fortunately for system administrators, .exe files can be and are often stopped at runtime, or prevented from running altogether. So if you are the administrator, make sure that your file security applications, including those you develop have higher permission levels than untrusted groups.

If you aren't the administrator, you are probably trying to compromise security somewhere, and having myself been exposed to a number of security breaches, I jolly well hope you refrain from using Autoit for malware deployment. Just consider how much time and effort the developers and other members of this community have put into making Autoit what it is today and what it can become, and the bad press a small minority can cause with such applications.

IVAN

Edited August 17, 2006 by ivan

[keeskas]

i agree with ivan, but even microsoft itself is now promoting the "runas" thing,

It is good practice for administrators to use an account with restrictive permissions to perform routine, nonadministrative tasks, and to use an account with broader permissions only when performing specific administrative tasks. To accomplish this without logging off and back on, log on with a regular user account, and then use the runas command to run the tools that require the broader permissions.

one trick i used is open an "cmd" with runas and use this in an "su" kind of way (even dragging an icon to the cmd-window will work).

Greetings,

Kees