Mac OSX 10.7 Lion problems

So when Lion came out last week, I went ahead and bought and downloaded it… I then spent 3 or 4 days trying to figure out why I couldn’t install it. I was also experiencing some problems with my installation of Snow Leopard and even trying to boot my known good Snow Leopard installer disk. The problems I was experiencing was that when booting up, it would completely freeze once everything came up and would sit like that for 5 minutes or so before I could start using it. Lion would not install stating only “An error has occurred, please run this program again later”

Only after I had been doing some searching for the errors that showed up in the installation log, I found a suggestion to try clearing the PRAM and NVRAM. I did that by turning on my Macbook Pro while holding down Option, Command, P, and R. And guess what, everything worked fine then.

So, my suggestion to any mac owners that are experiencing weird problems, reset your PRAM and NVRAM before you spend days searching for the answer like myself.

I hacked together this hand crank radio (I used an Innovage Outdoor AM/FM/WB radio ) to my old MintyBoost (available from Adafruit Industries )

Sorry for the shaky-cam, I just wanted to put out something quick and dirty.

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 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


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.

If anyone has any questions about anything and would like me to go in depth with, just shoot me an e-mail at or go to

If you get me started, I’ll really take off and hopefully keep you all entertained, or informed, or whatever.

  • Sean

Fun little DOS command

I discovered the following commands during some of my internet travels:

The LINKD command interested me for being able to mount drives to a particular directory like is normally used in POSIX systems. The way it is used is like the following:

LINKD C:\ edrive E:\

It’s pretty sweet, keeps you from needing to go all over your drive letters for things, just subdirectories. One unfortunate thing is that it does not appear to work for mapped network drives. In order to get around this issue, I thought to myself, “what would happen if I used the SUBST command to mount the UNC path and then use LINKD to mount that?” I tried it, and it didn’t work. :( I’m not sure if there’s any way to mount a network drive to a directory at this time, but the LINKD will give me a nice RAID-ish structure to my drives so i can hide the drive letters and just use the directories.

Have fun!

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:CompOrDomain\Administrator 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:CompOrDomain\\administrator 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 + " & runas /user:CompOrDomain\\administrator 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:


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:CompOrDomain\administrator CommandToRun”) WScript.Sleep 1000 objShell.AppActivate strTitle objShell.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!