VBScript und Exchange

Für die Nutzung von Outlook aus VBScript finde Sie auf Outlook VBScript weitergehende Informationen.

Ein Häufiger Fehler beim Programmieren ist unachtsamkeit bei der Verwendung von Variablen. Siehe Auch VBScript Falle "ByVAL/ByRef"

Windows Script 5.7 für Windows XP
http://www.microsoft.com/downloads/details.aspx?FamilyID=47809025-D896-482E-A0D6-524E7E844D81&displaylang=en
Windows Script 5.7 für Windows 2000
http://www.microsoft.com/downloads/details.aspx?familyid=C03D3E49-B40E-4CA1-A0C7-CC135EC4D2BE&displaylang=en

Achtung: 64bit und 32bit
Viele COM-Klassen sind 32bit Programme und können nicht vom 64bit CScript instanziiert werden. In solchen Fällen sollten Sie die auf einem 64bit-Server ebenfalls vorhandene 32bit-Version von CScript nutzen. Diese liegt meist auf "c:\windows\syswow64\cscript.exe"

VBScript wurde von vielen Administratoren noch gar nicht richtig entdeckt, da wird es schon wieder das Ende beschworen. Fakt ist aber, dass VBScript auf allen Windows Betriebssystemen ab NT4 verfügbar ist und zusammen mit vorhandenen COM-Objekten auch sehr leistungsfähige Skripte (nicht Programme) erlaubt. Jeder Administrator, der noch mit BATCH-Dateien herum wirbelt, erkennt schnell dass viele Funktionen nur über den Aufruf externer Programme (SORT, FIND, WMIC, IPCONFIG etc.) oder gar nicht möglich sind.  Der Weg zu einem "richtigen" kompilierten Programm aber doch zu weit ist. Daher ist eine leistungsfähige Skriptsprache für eine effektive Administration erforderlich.

Programmieren mit VBScript

VBScript wurde etwa zur Zeit von Windows NT4 und WMI eingeführt um Windows auch per Script administrierbar zu machen. Damals konnten Administratoren eigentlich nur mit Batches und Programmen aus dem Windows NT Ressource Kit ein paar Dinge automatisieren. Auch wenn VBScript seit ca. 2003 nicht mehr aktiv weiter entwickelt wird, (Der Windows Scripting Host 5.6 ist die letzte Version) und es keine EntwicklungsUmgebung von Microsoft gibt, so ist VBScript weiterhin das Werkzeug für Administratoren. VBScript selbst kann sehr wenig, aber durch die Einbindung von COM-Objekten ist fast alles möglich.

Aber Programmieren mit VBScript ist wirklich "Programmieren". Wenn Sie nicht einige Grundregeln des Programmierens können, dann wird aus einem VBScript sehr schnell unlesbarer Spaghetti-Code. Daher möchte ich ihnen nahe legen, nicht nur Skriptschnipsel aus dem Internet oder Tools wie ADSI-Scriptomatic, WMI-Scriptomatic oder Tweakomatic aneinander zu kleben, sondern zumindest Grundbegriffe der objektorientierten Programmierung sich anzueignen. Hier ein paar Regeln:

  • Planen, Teilen und Objektorientierung
    Überlegen Sie sich vorher, welche Funktion das Script ausführen soll. Sicherlich lässt sich jedes Script in logische Funktionen und Einheiten auftrennen, die voneinander unabhängig sind. Sie können in VBScript als auch vielen anderen Programmiersprachen problemlos mit Prozeduren und Funktionen arbeiten aber noch viel besser können Sie ihre eigenen Objekte erstellen und nutzen. Die objektorientierte Programmierung ist ein wichtiger Schritt in gute, stabile und hochwertige Programme.
  • Konstanten statt Hardcoded
    Wenn Sie schon ihr Script auf ihre Umgebung anpassen (z.B. Servernamen, Benutzernamen, Kennworte), dann sollten Sie diese nicht in den Tiefen des Code verstecken, sondern als Konstanten am Anfang des Code ablegen. Das erleichtert später die Anpassung. Sie sollten aber generell prüfen, ob z.B. Username/Kennwort-Kombination nicht besser erfragt werden. Kennworte im Code sind immer eine schlechte Idee und auch verschlüsselte Skripte sind nicht wirklich eine Absicherung.
  • Sauberer Code
    VBScript erlaubt zwar keine Pointer aber dafür sind alle Variablen "Varianten". Eine enge Typprüfung findet daher eher nicht statt. So kann "123" und "456" sowohl ein String als auch numerisch sein. Aus einen "123" + "456" wird als Integer dann "579". Wird der Inhalt als String betrachtet, dann kommt ein "123456" heraus. Es hat sich daher eingebürgert, den Typ der Variable mit im Namen aufzunehmen und bei Funktionen mit Typecasting zu arbeiten (Also cint(), cstr() etc.). Dazu gehört natürlich auch das "Option Explicit" am Anfang des Code, damit Tippfehler bei Variablen auffallen.
    Auch die Übergabe von Variablen an unterfunktionen kann "byVal" oder "byRef" erfolgen, was merkliche unterschiede in der Funktion zur Folge haben kann.
  • Dokumentieren und formatieren
    Jede Zeile Kommentar ist keine verschwendete Zeit, sondern erleichtert ihnen selbst später auch das Verstehen. Es mag zwar sportlich ein, mit möglichst wenig "Lines of Code" eine Problemstellung zu lösen, aber lesbar wird der Code damit nicht. Gehen Sie nicht davon aus, dass jemand anderes das gleiche Wissen um bestimmte Funktionen (z.B.: die Bedeutung von Feldern im Active Directory oder Registrierungsschlüssen) hat. Dokumentieren Sie auch am Anfang genau, was das Script tut, welche Eingabeparameter und Umgebung es erwartet und was herauskommen soll.
  • Testen, Debugging und "On Error"
    Irren ist menschlich und daher sollten Sie davon ausgehen, dass ihr Script NICHT wie geplant funktioniert. Im einfachsten Fall tut es einfach nichts oder bricht mit einer Fehlermeldung ab. Im schlimmsten Fall zerstört es Daten. Setzen Sie daher Anweisungen wie "On error resume next" nur ein, wenn Sie genau wissen, warum und Sie danach die Error-Bedingung abfragen.
    Es ist sicher eine gute Idee, eine Debugfunktion zu integrieren und alle Aktionen, die das Skript durchführt, zu protokollieren. Wenn es auf einen Laufzeitfehler läuft, dann sind das wichtige Daten zur Fehlersuche.
  • Organisieren und Versionen
    Eine Textdatei ist schnell geändert. Seinen Sie diszipliniert und Si sollten immer dann wenn Sie glauben eine Version fertig gestellt zu haben,  aber zumindest wenn das Script in der Art in der Produktion verwendet wurde, eine Kopie des Scripts mit einer Versionsnummer anlegen. Es mag mühselig klingen aber wenn Sie ein Script verändern und einen Irrweg eingeschlagen haben, ist es sehr schwer wieder auf den alten Stand zurück zu kommen, (z.B.: Backup oder Schattenkopien). Es muss ja nicht gleich eine Versionsverwaltung sein.
  • Codegeneratoren und Vorlagen
    Programme wie Scriptomatic und Quellen aus dem Internet sollten Sie nicht blind einsetzen, sondern um vielleicht Tipparbeit zu reduzieren. Sie sollten aber immer wissen, was Sie da tun.

Ich will Sie aber nicht davon abhalten, ihre ersten Schritte in VBScript oder einer anderen Programmiersprache (z.B. .NET) zu unternehmen. Nur sollten Sie rechtzeitig eben auch das Handwerkszeug dazu erlernen, damit Sie nicht sprichwörtlich absaufen.

VBScript und Sicherheit

Natürlich haftet VBScript der Ruf an, dass es "unsicher" wäre. Das ist vor allem ein Ergebnis vieler Viren der Vergangenheit. Gerade bösartige Personen hatten die Mächtigkeit von VBScript erkannt um damit viel Schindluder zu treiben. Das ist nach meiner Ansicht aber nicht als Problem von VBScript als solches anzulasten. Genauso gut könnte ein Schadprogramme als BAT, CMD, Perl, PHP-Datei verteilt und aktiv werden. Natürlich ist diesen Viren entgegen gekommen, dass VBScript per "default" installiert ist, aber eine SHELL auf Unix ist ebenso verfügbar wie die DOS-Box unter Windows. Solange ein Anwender einfach "ausführbaren" Code auch ohne Zögern startet, ist das Problem vorhanden. Aber es betrifft alle Sprachen.

Als Administrator können Sie dem etwas Einhalt gebieten, indem die natürlich gleich den kompletten Windows Scripting Host entfernen. Aber damit nehmen Sie sich auch selbst jede Möglichkeit mit Skripten erforderliche Lösungen zu schaffen.

Sie könnten alternativ die Verbindung von "VBS" zum Scripting Host lösen und z.B.: auf Notepad verbinden. Und damit zumindest den "Doppelklick" verhindern. Ein Aufruf mit WSCRIPT.EXE oder CSCRIPT.EXE ist dann immer noch möglich.

Der sichere Weg ist aber einfach über eine Gruppenrichtlinie vorzuschreiben, dass nur noch digital signierte Skripte ausgeführt werden dürfen. Mit einer eigenen Zertifizierungsstelle ist des nicht sonderlich schwer, dies zu regeln. Folgende KB-Artikel beschreiben zwar die Signierung von VBA aber das ist nicht weit weg von VBS.

Für mich ist also nicht VBScript ein Sicherheitsproblem, sondern der Mensch und Administrator davor. Als Administrator einer mittleren und größeren Umgebung benötige ich aber die Möglichkeiten einer leistungsfähigen SkriptUmgebung. Und dafür ist VBScript wie geschaffen.

VBScript editieren

Der Spruch des "Visual Notepad" wird häufig für VBScript genannt. Notepad ist in der Tat ein oft benutzter Editor, um schnell ein mal ein paar Skripte zu erstellen. Aber ziemlich schnell kommen Sie an die Grenze, wo ein Editor mit SprachUnterstützung ein flüssigeres Arbeiten erlaubt.

Hier eine Auswahl an Programmen, mit denen Sie VBS-Dateien mit etwas mehr Komfort erstellen können. Meine beiden Favoriten sind

Wenn Sie professionell mit Unterstützung entwickeln, dann lohnt sich die Investition in kommerzielle Produkte wie:

Weitere Editoren sind:

Mein persönlicher Favorit ist der SystemScripter von Dr. Tobias Weltner (www.scriptinternals.com), da er die meisten Objekte auf meinem PC erkennt und mir bei der Eingabe schon vorschlägt. Die meisten kostenfreien Werkzeuge beschränken sich auf die farbliche Hervorhebung von Schlüsselworten etc. aber wissen doch nicht, dass es sich um VBScript handelt. Von diesen ist mir SC1 am sympathischsten, da der Editor eine einzige 350 kByte Datei ist und ohne Installation gestartet werden kann.

VBScript debuggen

Wer programmiert weiß, dass Fehler nicht zu vermeiden sind. Oft ist die Suche nach dem Fehler gar nicht so einfach und es geht tief in das Debugging hinein. Einfache Fehler im Skript erkennt der Windows Scripting Host schon beim Aufruf. Das Skript startet erst gar nicht. Einige Fehler werden erst zur Laufzeit erkannt wie z.B. der Zugriff auf ein Property eines Objekt, dass nicht vorhanden ist. Hier bricht das Script in der Regel an. Aber Microsoft hilft hierbei mit mehreren Programmen:

  • WScript.Echo und MSGBOX
    Sie mögen schmunzeln, aber meist ist genau dieser Weg der schnellste und einfachste. Gezielt platzierte Ausgaben von interessanten Variablen geben einen schnellen Anhaltspunkt auf den Fehler
  • Microsoft Script Debugger
    Aber seit Windows 2000 ist der Script Debugger einfach über die optionalen Komponenten des Betriebssystems installierbar. Wird dann z.B.: "CSCRIPT //X scriptname.vbs" aufgerufen, dann wird das Script im interaktiven Debugger gestartet, in dem Sie nun schrittweise den Code durchlaufen können.
    Introducing Microsoft Script Debugger
    http://msdn.Microsoft.com/library/en-us/sdbug/html/sdbug_1.asp
  • 308364 How to debug Windows Script Host, VBScript, and JScript files
  • 284973 How To Switch Between the Visual InterDev Debugger and the Microsoft Script Debugger as Default JIT Debugger
  • 281427 PRB: Microsoft Script Debugger Does Not Break at Error
  • Visual Studio Debugger
    Wer das Glück hat und auch mit Visual Studio arbeitet, kann auch diesen Debugger verwenden.

Einmal ist es mir passiert, dass trotz Installation des Microsoft Skript Debuggers dieser nicht gestartet wurde. Selbst ein Aufruf mit "cscript.exe //D //X scriptname.vbs" erbrachte keine Lösung. Letztlich lag es an einem Eintrag in der Registrierung, welcher nicht auf den Scriptdebugger gesetzt war:

REGEDIT4

[HKEY_CLASSES_ROOT\CLSID\{834128A2-51F4-11D0-8F20-00805F2CD064}]
@="ScriptDebugSvc Class"
"AppID"="{A87F84D0-7A74-11D0-B216-080000185165}"

[HKEY_CLASSES_ROOT\CLSID\{834128A2-51F4-11D0-8F20-00805F2CD064}\LocalServer32]
@="c:\\Program Files\\Microsoft Script Debugger\\msscrdbg.exe"

[HKEY_CLASSES_ROOT\CLSID\{834128A2-51F4-11D0-8F20-00805F2CD064}\ProgID]
@="ScriptDebugSvc.ScriptDebugSvc.1"

[HKEY_CLASSES_ROOT\CLSID\{834128A2-51F4-11D0-8F20-00805F2CD064}\VersionIndependentProgID]
@="ScriptDebugSvc.ScriptDebugSvc"

Warum auch immer hat das Setup des Skript Debuggers diesen Eintrag nicht vorgenommen. Die Fehler müssen Sie aber immer noch selbst suchen. Hierzu kann ihnen auch folgendes helfen:

VBScript Errorbehandlung

Wer Code schreibt, macht Fehler und einige Entwickler schätzen den Aufwand für Code zum Abfangen von Fehlern auf 30-40% des gesamten Codes. Auch bei VBScript gilt, dass ein Laufzeitfehler das Script ohne weitere Aktion beendet, es sei denn Sie arbeiten mit "ON ERROR RESUME NEXT". Sobald diese Zeile eingesetzt wird, sollten Sie aber im Script selbst prüfen, ob vielleicht ein Error aufgetreten ist, da sonst auch ein Schaden auftreten kann. Mit "ON ERROR GOTO 0" können Sie das Ignorieren von Fehlern wieder abschalten. Einen eigenen "Errorhandler" wie in Visual Basic mit "ON ERROR GOTO Funktionsname" ist leider nicht möglich.

Allerdings müssen sie auch noch beachten, dass "ON ERROR RESUME NEXT" bei der Nutzung von unterfunktionen und Prozeduren einen Scope hat. Das folgende Beispiel soll das beleuchten.

Wenn Sie dieses Script starten, dann erhalten Sie folgende Ausgabe:

Die Ausgabe von "Test2 nach Error" unterbleibt, da die Funktion "Test2" keine eigenes explizites "ON ERROR RESUME NEXT" hat. Der in Zeile 21 provozierte Fehler führt daher direkt zu einem Ende dieser Funktion und einem Rücksprung zu Zeile 8.

onerrorscope.vbs
Das VBScript zum selbst experimentieren.

Praktisch bedeutet dies, dass Sie am besten eine Fehlerbehandlungsroutine schreiben, die im Rahmen der Debugausgabe sehr oft aufgerufen wird und sie in jeder Funktion und Prozedur ein "ON ERROR RESUME NEXT" einfügen.

VBScript und HTA

VBScript ist primär eine Skriptsprache für die Kommandozeile. Die normalen Ausgaben beschränken Sich auf das Schreiben von Textzeilen auf die Konsole (wscript.echo) oder in das Eventlog und die Ausgabe über  Mitteilungsfenster (msgbox "Meldung"). Erst über die Einbindung z.B. des Internet Explorers als COM-Objekt kann VBScript auch formatierte Ausgaben erstellen. VBScript kann dann über das Document Object Model (DOM) des Browsers im Betrieb eine Webseite erstellen und so als formatierte Ausgabe nutzen.

Nahe verwandt sind dabei auch die HTA-Dateien. Genau genommen sind das auch "nur" VBScript-Dateien,  die aber in einer HTML-Datei eingebettet sind. Der Internet Explorer startet die HTA-Datei und zeigt die HTML-Inhalte an. So können Sie Eingabemasken etc. z.B. mit Frontpage erstellen und hinter die Buttons entsprechende Skriptfunktionen zu hinterlegen. Damit wird der Internet Explorer dann zum Ersatz für die Windows Forms einer Anwendung. Microsoft selbst nutzt diese HTA-Dateien auch für verschiedene Assistenten (z.B.: Scriptomatic)

VBScript und ASP

Sie dazu die eigene Seite ASP

VBScript und TCP/IP und SMTP

So leistungsfähig VBScript auch sein kann, es ist nichts ohne entsprechende COM-Module, die instanziert und genutzt werden können. Zwei wesentliche Funktionen fehlen bei VBScript:

  • TCP Sockets
    VBScript kann ohne Hilfsprogramme keine TCP/IP-Verbindungen auf Socket Basis öffnen und nutzen, d.h. mal schnell einen "TELNET" schreiben, um eine Mail zu senden ist nicht möglich
  • SMTP-Stack
    VBScript kann auch nicht ohne Hilfsprogramme eine Mail versenden. Es kann diese nur, wenn es auf dem Exchange Server läuft und entsprechende CDO (MAPI/ExtendedMAPI) oder den virtuellen SMTP-Server (Pickup Verzeichnis) nutzen kann oder Outlook (Outlook VBScript) installiert ist.

Allerdings gibt es eine Menge von Drittherstellern, die eben diese fehlenden WINSOCK und SMTP-Objekte als kommerzielle Produkte oder auch als Freeware bereit stellen.

VBScript und "Lokalität"

Als alter Pascal Programmierer war es problemlos möglich, an eine Funktion oder Prozedur entsprechende Parameter zu übergeben. Diese konnten in der Prozedur ohne Risiko geändert werden, da sie "lokal" waren. Bei VBScript wird erst mal alles "byRef" übergeben. Das ist zwar schneller, aber bedeutet auch, dass sie eine übergebene Variable in einer Funktion nicht einfach verändern sollten, weil sich damit auch der Inhalt der Variable im darüber liegenden Programm ändert.

Das gleiche gilt, wenn man Klassen (Objektorientierte Entwicklung) nutzt. folgendes Beispiel instanziert eine Klasse, füllt diese mit einem Wert und über die Zeile "set o2=o1" kopiert man die Klasse.

option explicit

dim o1, o2

set o1 = new Testclass
o1.test="1"
wscript.echo "o1:" & o1.gettest

set o2 = o1
wscript.echo "o2:" & o2.gettest
o2.test="2"

wscript.echo "o1:" & o1.gettest
wscript.echo "o2:" & o2.gettest


class Testclass

    dim strtest

    public property let test(wert)
        strtest = wert
    end property
   
    function gettest
        gettest = strtest
    end function
end class

In Realität ist es aber keine Kopie, sondern nur eine Referenz. Wenn man nun die Instanz "o1" verändert, dann ändert sich damit auch o2. Zerstört man nun o1, dann ist auch o2 nicht mehr gültig. Um eine echte Kopie zu erzeugen, muss man eine neue Instanz mit "set o2 = new testclass" erzeugen und die Eigenschaften manuell übernehmen.

Beachten Sie auch die Probleme von VBScript Falle "ByVAL"

VBScript und Errors

Manchmal glauben Sie, ihr Skript ist 100% fehlerfrei und es tut dennoch nicht, was es soll. Dann kann es sein, dass Sie auf "besondere" Felder gestoßen sind. Angenommen Sie möchten den Inhalt des Felds "Company" eines Benutzers prüfen, dann könnten Sie folgende Zeile programmieren. 

if (currentobj.Fields("company") <> "MSXFAQ") then
	wscript.echo "Company ist nicht korrekt"
endif

Wenn das Feld "company" dann den falschen Wert enthält, dann wird auch sauber "Company ist nicht korrekt" angezeigt. Ist aber das Feld "company" gar nicht belegt (also NULL), dann ist es mit schon passiert, dass der THEN-Teil trotzdem nicht aufgerufen wurde, obwohl "NULL <> "MSXFAQ" ist. Seit dem prüfe ich lieber auf Gleichheit und nutze den Else-Zweig, also:

if (currentobj.Fields("company") = "MSXFAQ") then
	wscript.echo "Company ist korrekt"
else
	wscript.echo "Company ist nicht korrekt"
endif

Tückisch und eigentlich nur über den Debugger zu finden, wenn der Code nicht dort einspringt.

VBScript und Include

Je mehr Programme man schreibt, desto mehr baut man sich eine Library von Codeteilen auf, die man immer wieder verwendet. Ich habe mir z.B.: Klassen für Debugging, CSV-Lesen, CSV-Schreiben etc. gebaut. Natürlich kann ich bei einem neuen Skript auch einfach wieder diese Klasse per Copy&Paste in den neuen Code übernehmen. Das ist aber ungeschickt da eine Korrektur oder Erweiterung der Klasse sich nicht auf alle Programme auswirken, die diese Klasse nutzen, es sei denn ich ersetze die alte Version durch die neue Version in jedem Programm. Warum nicht auch Codeteile einfach "auslagern" in eigene Dateien. Leider kenn VBScript keine "Include"-Anweisung. ASP kann über die "#include file=name"-Anweisung anderen ASP-Code einbinden. Bei VBScript kann man sich das aber auch selbst schreiben. Hier ein Beispiel, dass Programm main.vbs die include1.vbs einfach einbindet und ausführt.

' Inhalt von main.vbs
wscript.echo "Main gestartet"

includecode("include1.vbs")
call include1
wscript.echo "Main beendet"


sub IncludeCode (fname)
    dim strcode
   
    wscript.echo "IncludeCode loading " & fname
    Dim fso, f
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set f = fso.OpenTextFile(fname, 1) ' forreading
    strcode = f.ReadAll
    executeglobal strcode ' muss global sein, da sonst nur in dieser SUB erreichbar
end sub

' Inhalte von include1.vbs
sub include1
   wscript.echo "include1 gestartet"
end sub

Der Trick über "ExecuteGlobal" führt den Inhalt des Strings einfach aus.

VBScript mit Kommandozeilen und PIPE

Nicht erst seit der PowerShell wird die "PIPE" immer wichtiger. Während aber die PowerShell direkt .NET-Objektreferenzen übergibt, ist VBScript wie Unix auch auf einen einfachen Textdatenstrom angewiesen. Das macht es aber dennoch wichtig, diesen Weg zu können. Schließlich kann ein Administrator ganz einfach per PowerShell eine Liste von Benutzern erstellen und diese über eben diese PIPE an ein VBScript-Programm übergeben.

dim Inputstream
Inputstream = wscript.stdin.readall()
dim ArrLines
arrlines = split(Inputstream ,vbcrlf)
wscript.echo arrlines.count
' Optionale Abfrage per Kommandozeile.. NICHT MIT Pipe verwendbar

Wscript.StdOut.Write "Enter your name: "        ' prompt user
name = Wscript.StdIn.ReadLine                   ' get username
' Zeilenweises Einlesen mittels Schleife 

Do While Not wscript.stdin.AtEndOfStream
    alias = wscript.stdin.ReadLine
    wscript.echo "Reading STDIN: Alias = " & alias 
Loop

Ein zweiter Aspekt ist natürlich die Auswertung von Kommandozeilen und optional eine Abfrage von fehlenden Parametern. Hier ein Beispiel:

Dim param1
param1 = wscript.arguments.named("param1")
' InputBox(prompt[,title][,default][,xpos][,ypos][,helpfile,context])
if param1 = "" then param1 = InputBox("Please enter Parameter1", "Parameter 1","Vorschlag")
wscript.echo "Param1" & param1

VBScript kompilieren und verschlüsseln

Schon immer war es für Firmen besonders wichtig, ihre Leistung zu schützen. Daher ist es natürlich gar nicht gerne gesehen, wenn Wettbewerber den Code einer Firma in Klartext erhalten, anpassen und weiter verwenden könnten. Natürlich gibt es auch genau die andere Seite, die Als "Open Source" gerade jeden Quellcode offen legt und die Lizenzbedingungen z.B. fordern, dass davon abgeleiteter Code ebenfalls "offen" sein muss. Fakt ist aber, dass jeder Code von einer CPU ausgeführt werden muss und dazu "lesbar" ist. Natürlich ist ein kompilierter Maschinensprachecode nicht wirklich lesbar, aber es gibt Disassembler, die es schon vereinfachen, die ein oder andere Logik zu dekodieren.

VBScript hingegen ist quasi immer Sourcecode, da der Windows Scripting Host diesen erst im Moment des Aufrufs "kompiliert". Das macht ja gerade die Flexibilität aus, aber macht es natürlich auch schwer, die Vorgänge zu verbergen. Seit es aus Schutzbedarf aber auch einfach um z.B.  Kennworte zu verbergen, die in dem ein oder anderen Code enthalten sind.

Für VBScript gibt es einen "Script Encoder", durch den aus einer VBS-Datei dann eine VBE-Datei wird, die verschlüsselt ist. Allerdings kann nicht nur CSCRIPT.EXE und WSCRIPT.EXE diesen Code entschlüsseln, sondern auch einige Programme von Drittherstellern.

Insofern können Sie sich das Verschlüsseln auch einfach sparen, da es kein echter Schutz ist. Nur wenn Sie ihren Code direkt auf eine sehr niedrige Abstraktionsebene kompilieren, wird es möglichen Interessenten sehr schwer gemacht. Das Problem der Dekompilierung ist auch bei .NET vorhanden, da die "Intermediate language" noch sehr abstrakt ist und durch aus "gelesen" werden kann.

VBScript signieren

Gerade im Einsatz innerhalb von Firmen sind Makros und Viren immer ein besondert kritisches Thema. Dazu zählen natürlich auch Skripte, die mit Berechtigungen des Benutzers oder sogar eines Administrators gestartet werden. Skripte sind ja sehr einfach zu ändern und ein Angreifer könnte daher einem Administrator ein verändertes Skript unterschieben. Um dies zu verhindern, können Sie als Administrator natürlich die Ausführung von Skripten in ihrem Netzwerk über Gruppenrichtlinien steuern. So könnten Sie erzwingen, dass nur signierte VBScripte von Benutzern ausgeführt werden dürfen. Diesen "Schutz" sollten Sie für Installationskonten nicht aktivieren, da einige Installationsprogramme ebenfalls VBS-Dateien nutzen. In Kürze geht dies durch folgende Schritte

  • Zertifikat erstellen
    Zum Signieren benötigen Sie ein Zertifikat. Das können Sie mit dem Programm "MAKECERT.EXE" natürlich schnell selbst anlegen, von ihrer unternehmens-CA anfordern oder von einer Firma kaufen.

makecert.exe -n "cn=Testzertifikat" -ss my -eku 1.3.6.1.5.5.7.3.3

  • Vertrauen sicherstellen
    Ale nächstes müssen Sie sicherstellen, dass auf den Systemen, auf denen das Skript ausgeführt wird, die ausstellende CA natürlich vertrauenswürdig ist. Dieses Problem gibt es mit offiziellen Zertifikaten meist nicht. Auch beim Einsatz einer unternehmens-CA ist das Zertifikat meist schon über das Active Directory und Gruppenrichtlinien verteilt. Lokal können Sie dies durch folgende Zeile aktivieren:

Setreg.exe 1 true

  • VBScript signieren
    Nun ist es an der Zeit das VBScript digital zu signieren. Dazu dienst das Programm "signcode", mit welchem das Script entsprechend signert wird.

signcode.exe -cn "Testzertifikat" -t http://timestamp.verisign.com/scripts/timstamp.dll meinskript.vbs

  • Trust überprüfen
    Um zu prüfen, ob das Skript auch wirklich "richtig" signiert ist, könnten Sie natürlich das Skript einfach starten. Aber mit chktrust.exe gibt es einen Weg, einfach nur die Gültigkeit der Signatur zu prüfen. Nebenbei wird so auch geprüft, dass die Zertifikatskette und die Zertifizierungsstelle vertrauenswürdige ist:

chktrust.exe hello.vbs

Eine ausführliche Beschreibung der Zertifizierungsprozedur finden Sie auch auf http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/rstrplcy.mspx.

Scriptomatic Helfer

Microsoft Script Links

Exchange/Outlook und Scripting

Andere Links zu Scripting