Creating custom cd application with stored domain/admin passwords

[cheeseslice]

Hi,

This is sort of two questions that I am hoping I can get a bit of advice with. I haven't been using autoit for quite a while so I'm just checking how best to go about this.

Certain departments on the domain need specific applications installed on their workstations, no-one is allowed admin rights and because of the way the packages are they need to be installed individually on each machine.

My solution to this problem is that I am going to write autoit scripts for each of these packages, I am then going to create a gui as a front end for the user to click on whichever application they need installed and I am going to run all of this from a virtual cd off one of my servers. All users have access to the virtual cd library so I just need to assign a shortcut to them with this disc of software.

My two questions:

1. I am going to have to put my username and password into these scripts so that the software can install and download files from the servers. Is there a safe way to encrypt the code once it is compiled? I know that a while ago it was just a case of decompiling and the password was plain to see.

2. In your opinion would it be best to write the gui using autoit or should I use somethign like vb.net for that part of it?

Thanks in advance.

[Mat]

2) is easy to answer so I'll do that first: Yes. Make the GUI with AutoIt. GUIs are very easy, and although Koda (our form designer) can't compare to Visual Studio's designer, GUIs are very simple in code.

1) How secure does it need to be? There are several ways to encrypt the data, but all of them will only slow down anyone that wants that password.

My initial thoughts are: Make an account with enough permissions to do what the AutoIt scripts need to do. That way your account won't be messed with, and you are minimising the damage that could happen.

A useful link:

There are more examples of encryption if you search the forums.

[cheeseslice]

2) is easy to answer so I'll do that first: Yes. Make the GUI with AutoIt. GUIs are very easy, and although Koda (our form designer) can't compare to Visual Studio's designer, GUIs are very simple in code.

1) How secure does it need to be? There are several ways to encrypt the data, but all of them will only slow down anyone that wants that password.

My initial thoughts are: Make an account with enough permissions to do what the AutoIt scripts need to do. That way your account won't be messed with, and you are minimising the damage that could happen.

A useful link:

There are more examples of encryption if you search the forums.

you are right, koda is very quick. I have just created the gui and thrown on a few buttons, it doesn't need to be pretty!

To install this software and access the right files the account is going to have the same rights as me, which is a problem. I can't really see anyone trying to decompile the scripts but at the same time I can't really take the risk that someone might.

I'm wondering if there is a way I could protect the file virtual disc from being explored but I don't think I can do that.

[Mat]

I'd still go with making another account... What happens if they get your account and password and change the password or you use the same password for other things... If you could stop the user changing user settings that would also make it a bit more safe.

As mentioned, there is no foolproof solution unfortunately. If you are not anticipating a big security risk then it might be enough to:

1) Use StringEncrypt with the password and some dummy data, I have seen people using stuff like the exe name or some other property of the exe to do this.

2) Obfuscate the code

3) Use UPX to compress the binary (enabled by default with AutoIt).

That would stop most people unless they want that password and know AutoIt pretty well.

[BrewManNH]

I work on a Windows domain connected network, and I have to image computers with Ghost. Because we have 5 locations that these computers are deployed to, we don't join them to the domain until they are deployed. To minimize the set up time we use Sysprep and have them auto-join the network. The problem with sysprep is, if you want to auto-join to a domain, is that the user name and password are in plain text in the sysprep file. What I ended up doing was creating a user account that has the authority to join an unlimited number of machines to the domain, but has no other rights. I have created policies that prevent that user name from being able to log into any machine so even if they get the credentials (which get deleted after sysprep has been run the first time), they can't do anything with it because they can't use it to log into the computer later.