doubt in converting powershell code to Autoit

[Syed23]

Hi All,

       Due to some restriction in our environment we should not pass the user id and password of the database directly in code to connect to the DB. so we have dll which will help to retrive the user id and password. initially we had a powershell code which will get the login id and password from the dll, now i want to to do the same using autoit.. i know autoit is capable of.. but i am failing to do that.. can someone help me how to do it?

Here is my Powershell coe:

[Reflection.Assembly]::LoadFile("C:\temp\TEST.dll")
$dll = New-Object -TypeName TESTS.SecurityAssist

[string] $userid = ""
[string] $pwd = ""
[string]$domain = ""

$dll.retrieveSA("DATABASE", [ref]$domain,[ref]$userid, [ref]$pwd)

Here is the autoit code which i tried:

$Open = DllOpen("C:\temp\TEST.dll")
$DLL = ObjCreate("TESTS.SecurityAssist")
$userid = ""
$pwd = ""
$Dll.retrieveDB("DATABASE",$userid,$pwd)
MsgBox(0,"",$userid)
MsgBox(0,"",$pwd)

Edited:

I am very poor at DLL using so please appologise if my code irritated any of you

Edited December 18, 2013 by Syed23

[JohnOne]

I've got no idea about powershell or know the dll documentation but thought I'd have a blind pop.

$userid = DllStructCreate("char[256]")
$pwd = DllStructCreate("char[256]")
$domain = DllStructCreate("char[256]")

DllCall("C:\temp\TEST.dll", "none", "retrieveSA", "str*", DllStructGetPtr($domain), "str*", DllStructGetPtr($userid), "str*", DllStructGetPtr($pwd))
If @error Then
    Exit MsgBox(0,"Error", "ErrorNo: " & @error)
EndIf

ConsoleWrite(DllStructGetData($domain, 1) & @LF & DllStructGetData($userid, 1) & @LF & DllStructGetData($pwd, 1) & @LF)

[Syed23]

Hi John,

             Thank you so much for your reply..i tried with the code but i am getting an error 3

[JohnOne]

Do you have the dll code or documentation?

If not try changing "retrieveSA" to "DATABASE"

[Richard Robertson]

The dll is clearly a .Net dll based on the Reflection.Assembly part. AutoIt does not support .Net in any fashion.

[michaelslamet]

I'm interested with the idea storing username and password in DLL file and then retrieve it using AutoIT,

that way (I hope) will more secure.

Any idea how I can do it with AutoIT? I have no idea about how to create a DLL file with or without AutoIT

Thank you

[Richard Robertson]

So you're just saying that the dll has the username and password in its code instead of in the AutoIt script?

That's not any safer than just putting it in the script as any program can call the dll too.

[Syed23]

Hi Richard,

               Thanks for your reply. sorry i was on vacation so i couldn't reply.. you are right! the DLL was created in .Net.

[Richard Robertson]

Hi Richard,

               Thanks for your reply. sorry i was on vacation so i couldn't reply.. you are right! the DLL was created in .Net.

Not a problem. Unfortunately, .Net is just one of those things that AutoIt doesn't play well with yet.

[trancexx]

If managed member/whatever within assembly is COM visible then you can access it with AutoIt through ObjCreate() returned object.

For that to happen ComVisibleAttribute must be set to true, e.g. for the .NET class and inteface.

[michaelslamet]

So you're just saying that the dll has the username and password in its code instead of in the AutoIt script?

That's not any safer than just putting it in the script as any program can call the dll too.

 

I'm imagine this:

The dll is created by another language/compiler, compiled, and should no decompiler able to decompile it.

I know probably there is no such a language/compiler, my point is it's much harder to decompile than AutoIT

or if someone able to decompile it, it will only get the source code in binary/asm.

This dll is relly to another file for protection. If this another file is not exist, we assume it's run from a incorrect environment so it should terminated.

I'm taking about scripts that will run on a particular environment, like in a company, not scripts that developed for public used.

Is that solution make sense and applicable?

[Richard Robertson]

Even an assembly coded dll will be easy to decompile if it just contains a couple strings.

Security through obscurity isn't security. Just because you hide something, doesn't mean people can't still steal it. If someone can take your script outside of your environment, they can take the dll too.