Scripting – Sean Creasy

Experimental batch script

So, I was in need of using something like a pointer in a batch script, and I wondered if it were possible. So I invented this little script to demonstrate a cmd variable usage that resembles using pointers, or what is fun to say, variable variables. I’m not sure if it works using the command.com interpreter, but it does work with cmd.exe. Let me know what you think. I named the script varvarbinks.cmd

@echo off

:: setting up the pointer's value
set pntClient=%1
:: set the value of what pntClient points to
set %pntClient%=true

:: output what %%pntClient%% would equal since %%pntClient%%
:: does not work to a temp file
for /f %%a in ('echo %pntClient%') do set %%a>%temp%varvar.tmp
:: splits the variable and value up
for /f "tokens=1,* delims==" %%a in (%temp%varvar.tmp) do (
set valofvar=%%b
)
:: clean up the temp file
erase /F /Q %temp%varvar.tmp

echo The value of %pntClient% is %valofvar%

I wish I could get away with not using a temp file, but I haven’t figured out a way to do that yet. When you run, just run varvarbinks.cmd name-of-variable and it will show you that the name-of-variable is true.

AVG finds “Archive Bomb”

So, all of a sudden, AVG Network Edition (version 9.0.851 Virus DB 271.1.1/305) started to call a certain VBS file an “Archive Bomb”.

For any of you who do not know what an Archive Bomb is, it is basically an archive file (zip or rar, for example) that when decompressed, it takes up a LOT more space than the original file. This could be done by zipping a large file that is filled with all binary zeroes or ones. Another type of archive bomb is zipping a zip file, and then keep zipping the resulting file until when you try to decompress it, it will keep going until the last one. Both of these methods are designed to significantly hinder a computer when trying to decompress it. So, now after that background information, here is the script that AVG saw as an archive bomb:

ForReading = 1
ForAppending = 8

Set objFso = CreateObject("Scripting.FileSystemObject")
Set txtadd = objFso.OpenTextFile("k:\script\email\email.txt", ForReading)
Set filetxt = objFso.OpenTextFile("k:\script\notify\keybank.txt", ForAppending)
Do Until txtadd.AtEndOfStream = True
str = txtadd.Readline
filetxt.WriteLine str
Loop

txtadd.close
filetxt.close

That is it… no compression techniques used at all. We have been playing with the file, changing some of the basic structure of the script, re-typing the script into another file, etc… anyone have any theories as to why this would be detected as an Archive Bomb?

The big problem about this was when AVG found this file and thought it was a virus, it completely stopped processing everything on one of our main server machines that AVG was running on.

So, I believe this is one more reason not to use such anti-virus tools. The best one I’ve seen that doesn’t give such obvious false positives is Windows Security Essentials, it also doesn’t seem to stop any processes when files are found. But, of course, nothing beats the best anti-virus there is, the human brain.

WSH, RUNAS, Automation, etc…

Okay… So, I’ve been working on getting an automation script to work that runs a dos command as another user (namely Administrator) without requiring user interaction. So the RUNAS command is a good choice for a start.

One way to accomplish this is to download the program SANUR (runas backwords) and place it into your %PATH% and then use the command:

runas /user:CompOrDomainAdministrator Command to run | sanur password

That sanur command sends the password provided (could also place the password in a file so it is not immediately noticed) but this requires that you place SANUR into the %PATH% on all computers that will run the script, so lets try another way that also can help hide the password.

Here comes WSH scripting to the rescue. We can look at the Run, AppActivate, and SendKeys methods of the WScript.Shell object and use them to run the command, activate it, and then send the password to it.

First is the Run method. I would much rather use the newer Exec method, but for some reason, it does not seem to work with dos commands like runas and the like. Using Exec when possible would allow the AppActivate to be a little bit simpler by storing the WshShellExec object as a variable and look at the ProcessID property instead of the window title. But since it does not work quite the way we want, we use Run. The easiest way to do the run is (in JScript, I’ll add the VBS code in our final product):

var WshShell = WScript.CreateObject("WScript.Shell");
WshShell.Run("%comspec% /C runas /user:CompOrDomainadministrator CommandToRun");

That will create the WScript.Shell object and then use the Run method to run the runas command we spoke of earlier.

Now we have a window open running the specified command… now what? What if someone clicks away from it? That’s where the AppActivate method comes in.

WshShell.AppActivate("title of window" or ProcessID)

Okay, so we can use the title of the window we want to activate, or it’s PID. How do we get that? And if there’s more than one window with the same title, then what?

What I came up with was using the dos command TITLE to change the title of the running window and name it “Window” followed by a random number between 1 and 100000, so the chances of having two windows with the same name are very much minimized. But that chance does exist, which is why the WshShellExec.ProcessID method would be much better because a process ID can only point to one process. But this way gives us a better way than looking for “runas blahblahblah”. So here’s what we have so far:

var WshShell = WScript.CreateObject("WScript.Shell");
var strTitle = "Window " + (Math.round(Math.random()*100000) + 1);
WshShell.Run("%comspec% /C title " + strTitle + " &amp; runas /user:CompOrDomainadministrator CommandToRun");
WScript.Sleep(1000);
WshShell.AppActivate(strTitle);

Note the WScript.Sleep(1000); That ensures that there’s enough time for the title and runas commands to start running. So now this works to open the command and activate the command’s window. Now it’s asking for the password (assuming you have one). Now lets plug it in with a call to the SendKeys method. SendKeys sends the string of keys to the currently activated window like the following:

WshShell.SendKeys("ThisIsAPassword~");

Notice the tilde (~) at the end. That is SendKeys‘ quick character to send an enter keypress or carriage return character. So now, we should have our completed code now. The following is the WSF file that contains the VBS and JScript versions of the same code:

Set objShell = CreateObject(“WScript.Shell”)
Randomize
strTitle = “Window ” & Int(Rnd * 100000 + 1)
objShell.Run(“%comspec% /c title ” & strTitle & ” & runas /user:CompOrDomainadministrator CommandToRun”)
WScript.Sleep 1000
objShell.AppActivate strTitle
objShell.SendKeys “ThisIsAPassword~”

var WshShell = WScript.CreateObject(“WScript.Shell”);
var strTitle = “Window ” + (Math.round(Math.random()*100000) + 1);
WshShell.Run(“%comspec% /C title ” + strTitle + ” & runas /user:CompOrDomainadministrator CommandToRun”);
WScript.Sleep(1000);
WshShell.AppActivate(strTitle);
WshShell.SendKeys(“ThisIsAPassword~”);

So there you have it. It will also work for windows programs as well.

But how about security? You definitely could just look at the script source and get the password, so there are two ways off hand to help secure the password. One way is to make sure the permissions on the file does not allow anybody other than those who would be using the script to read it. Or you can encrypt the script using Microsoft Script Encoder. But know that having it encrypted with that does not make it 100% secure. There is a VBS script out there that allows you to just drop any VBE or JSE file onto it, and it spits it all out in plaintext. So my recommendation is to use both security methods I mentioned.

Well, that’s all! I hope you all have fun with this information!