#$K+{bml mainicon.bmp}  DongleKnacker
Dieses Programm dient zur Emulation eines vorher angelernten Kopierschutzsteckers (Dongle) am Parallel-Port des PC für ein beliebiges DOS- oder Windows-Programm. In einer Anlernphase ist der Dongle zu benutzen und das Programm ausgiebig zu testen. Das entstehende Protokoll kann abgespeichert werden. Im Wiedergabemodus versucht dieses Programm, anhand wiederkehrender Sequenzen die Dongle-Hardware zu simulieren.
Obwohl es sich hierbei um ein "klassisches" 16-bit-Programm handelt, ist der entscheidende Teil Code in 32-bit-Assembler geschrieben, um keine Performance-Wünsche offen zu lassen.
Ich übernehme keine Haftung für den Einsatz dieses Programms, weder für Schäden, der durch Fehlfunktionen (Bugs) entsteht, noch solche kopierschutzrechtlicher Art.

Inbetriebnahme
Funktionsprinzip
Hauptmenü
Dialogelemente
Kommandozeile
VDONGLE.386-Referenz
Aufbau der .DK-Datei
Fehlermeldungen und bekannte Bugs
Windows-Hilfe DKNACK.HLP Version 1.04 (05/97)

#$+K Inbetriebnahme
Voraussetzungen:
Dieses Programm benötigt mindestens Windows 3.1 im Enhanced Modus - demzufolge einen AT386 oder besser. Außerdem ist mindestens ein Druckerport erforderlich, sowie zum Anlernen der Dongle.

Installation:
Nachdem das Archiv ausgepackt wurde, geht es wie folgt weiter:

	** Windows 3.x **
Das Programm wird gestartet, stellt jedoch die Nichtpräsenz von VDONGLE.386 im Kernel fest, und geht in die Installationsroutine, die den Treiber automatisch in die SYSTEM.INI einträgt und Windows neu startet (mit Erlaubnis des Anwenders natürlich!)
Die Datei VDONGLE.386 kann auch "von Hand" in die SYSTEM.INI unter [386Enh] eingetragen werden:
device=/pfad/vdongle.386
Danach wäre Windows ebenfalls neu zu starten, um diesen Treiber wirksam werden zu lassen.
Nun kann DKNACK.EXE "richtig" gestartet werden. Es empfiehlt sich eine Einbindung des Icons in den Programm-Manager.

	** Windows95 **
Unter Windows95 sind prinzipiell keine Änderungen irgendwelcher Systemdateien erforderlich. DKNACK kann ganz einfach so gestartet werden, dynamisch ladbare VxD's und das virtuelle Druckerport machen's möglich.
Wird statisches Laden à la Windows 3.x gewünscht, kann das Emulationsport auch auf ein standardmäßig von VPD.VXD alloziertes Port gelegt werden, per Init_Order schiebt sich das VxD vor den sonst störenden VPD.VXD (und der läßt dann die Portadressen schweigsam in Ruhe). Ein Menüpunkt dafür erspart das manuelle Editieren der SYSTEM.INI.

	** OS/2 Warp4 **
Hier fehlt z.Z. der geeignete Treiber: ein Ersatz-Treiber für VLPT.SYS ist wahrscheinlich und ein VDONGLE.VDD mit Sicherheit erforderlich. Allerdings ist die Wirksamkeit von VDONGLE.VDD auf Windows- und DOS-Programme beschränkt, da verdongelte echte OS/2-Programme sicherlich ein I/O-privilegiertes 16-bit-Segment im Ring 2 verwenden. (Bliebe noch die Verwendung eines Debugregisters ab Pentium.)

	** Windows NT **
VDONGLE.386 ist unter NT nicht anwendbar. Und es wird sicherlich nicht einfach sein, überhaupt ein verdongeltes NT-Programm aufzutreiben. Nein danke, mein Rechner ist langsam genug. (Und außerdem will ich nicht wegen irgendwelcher OOB-Daten im Computernirwana verschwinden!)

Anlernen:
Nach dem Anstecken des Dongles am Druckerport LPT1 ist das Programm DKNACK.EXE zu starten. Danach wird das betreffende dongle-benutzende Programm gestartet. Das Knacken im Lautsprecher markiert die Donglezugriffe akustisch.
Wenn man meint, sämtliche Programmteile 1mal angeklickt zu haben, kann das Programm beendet werden. Die Daten können nun in einer .DK-Datei gespeichert werden.
Achtung! - Die Datei kann in kurzer Zeit sehr groß werden, 1 Megabyte ist durchaus normal! Entsprechend speicherhungrig ist auch das Programm, sodaß ein üppiger Speicherausbau nur von Vorteil ist. 2 verschiedene Pack-Optionen helfen, die Dateilänge erträglich zu machen.

Wiedergeben:
Sofern noch nicht laufend, wird DKNACK.EXE gestartet, die .DK-Datei geladen, und danach das Dongle-benutzende Programm gestartet. Das Dongle kann abgezogen werden, mit etwas Glück merkt es nichts von der Nichtpräsenz des kleinen Dings. Der Dateiname kann auf dreierlei Art dem Programm mitgegeben werden:
* mit Hilfe eines Dateiauswahldialogs, erreichbar über den "Laden"-Schalter
* per Drag'n'Drop vom Datei-Manager
* mit der Kommandozeile

Emulation mehrerer Schutzstecker gleichzeitig:
Ausgehend von einer geladenen .DK-Datei des ersten Programms wird die zweite .DK-Datei nachgeladen, wobei der Schalter "Anhängen" im Dateiauswahldialog markiert werden muß. Danach wird die (nun größer gewordene) .DK-Datei gespeichert. Mit diesem Verfahren lassen sich beliebig viele Dongles virtuell kaskadieren, die - an einem Druckerport angeschlossen - unverträglich sind. Allerdings kann die Performance in die Knie gehen...
Das Starten mehrerer DKNACK.EXE ist nicht möglich bzw. vorgesehen, denn es gibt auch nur ein VxD (und es sagt sich so schön: "Es kann nur einen geben").

Emulation an einem Rechner ohne Druckerport:
Diese Variante ist problemlos möglich. Ohne Druckerport macht selbstverständlich nur der Emulationsmodus Sinn.

Freihalten einer vorhandenen Schnittstelle:
Durch verschiedene Einstellungen vom physikalischen und emulierten Druckerport ist es möglich, im Emulations-Modus die vorhandene Schnittstelle von Zugriffen freizuhalten. So kann nun andere Hardware komplikationslos am Druckerport betrieben werden.
Allerdings suchen übliche Programme beim Starten alle Druckerports nach dem Dongle ab; so ist leider dennoch mit Zugriffen zu rechnen.

Emulation der Uhrzeit:
Es ist denkbar, daß Programme Zufallszahlen zum Dongle schicken und diese wieder rückzulesen versuchen. Ein solches Vorgehen würde das „Papagei“-Schema von DKNACK problemlos unterlaufen. Da jedoch die erste Zufallszahl in der Regel mit Hilfe der Uhrzeit festgelegt wird, und nachfolgende Zahlen eben nur pseudo-zufällig (determiniert) sind, ist das Vorgaukeln derselben Uhrzeit wie bei der Aufnahme erfolgversprechend. Angezapft wird die DOS-Funktion Int 21h / AH=2Ch. Erst VDONGLE.386 ab Version 1.05 unterstützt dieses Trapping. Eine Erweiterung des Dateiformates war ebenfalls vonnöten.

Dieses Programm besteht aus:
DKNACK.EXE	das Programm (z.Z. Version 1.05)
DKNACK.HLP	diese Hilfedatei (z.Z. Version 1.04)
VDONGLE.386	den Virtuellen Gerätetreiber (z.Z. Version 1.06)

#$+K Funktionsprinzip
Der Kernel-Treiber VDONGLE.386 fängt sämtliche Portzugriffe auf die 3 Ports einer parallelen Schnittstelle ab und informiert darüber ein beliebiges Windows-Programm mit einem Callback. Damit ist ein universeller Einsatz dieses Treibers möglich; durchaus auch zur Emulation eines Druckers oder zum Propagieren beliebiger Hardware über ein Netzwerk.
Zusätzlich reicht dieser Treiber die Portzugriffe tatsächlich auch zur Hardware durch (abschaltbar), und quittiert jeden Zugriff durch ein Knacken im Lautsprecher (ebenfalls abschaltbar).
Da die Anzahl der Callback-Rufe bei diesem Verfahren enorm sind und die Systemgeschwindigkeit lähmen, können mehrere OUT-Zugriffe zusammengefaßt werden. Erst bei einem IN-Zugriff wird in diesem Falle der Callback gerufen. Die Ansammlung und Übergabe der kodierten Befehle erfolgt hierbei über einen Puffer. Sollte der Puffer voll sein, ohne daß ein IN-Befehl erfolgt, wird auch dann der Callback gerufen.

Die Strategie des Abfangens der I/O-Zugriffe weist keine Besonderheiten auf und ist im DDK beschrieben und mit mehreren Beispielprogrammen unterlegt. Der Aufruf der Callback-Funktion bereitet ebenfalls keine Schwierigkeiten, solange der Portzugriff in der System-VM erfolgt; der Callback kann unmittelbar erfolgen. Demgegenüber erfordert das Abfangen des Portzugriffs aus einer DOS-Box das kurzzeitige Einschläfern derselben über einen Semaphor, verbunden mit einem erzwungenen Taskwechsel zur System-VM.
Bemerkenswert ist, daß keinerlei verwendeter Speicherbereich seiten-gesperrt (page-locked) sein muß, da das Port-Trapping immer aus einem Anwenderprogramm heraus geschieht, d.h. der Kernel ist immer "synchronisiert" und wird niemals reentrant gerufen.

Das Anwendungsprogramm DKNACK.EXE benötigt die Präsenz von VDONGLE.386 im Windows-Kern. Es verwendet die Funktion des Zusammenfassens mehrerer OUT-Befehle in einen Puffer.
Jeder solcherart gefüllter Puffer wird als "String" aufgefaßt, mit einem Längen-WORD am Anfang und einem IN-WORD am Ende. Während der Aufzeichnung werden diese Strings einfach hintereinander in den Speicher abgelegt. Dieser Speicher wird als ein einziges 32-bit-Segment von GlobalAlloc() verwaltet. (Wenig bekannt ist Programmierern die Tatsache, daß der erste Selektor als Limit den gesamten (und nicht nur 64K) allozierten Speicher adressiert.) Der Zugriff auf den Speicherblock erfolgt ausnahmslos mit externem Assembler geschriebenen Code in der Datei DKNACK.ASM. Die Größe des Speicherblocks wird dem aktuellen Bedarf stets angepaßt (GlobalReAlloc()).
Das Laden und Speichern des Speicherblocks gestaltet sich mit _hread() und _hwrite() sehr einfach - warum zum Teufel auch immer Borland diese Funktionen nicht in die Unit WinProcs aufgenommen hat!?

Die Anzahl der getätigten IN- und OUT-Zugriffe werden mitgezählt und zur Anzeige gebracht. Überschlägig kann man damit den momentanen Speicherhunger abschätzen: Allozierter Speicher = 2*Anzahl OUT-Befehle + 8*Anzahl IN-Befehle, in Bytes.

Im Wiedergabe-Modus erfolgt bei jedem Callback-Ruf ein Vergleich aller gespeicherten Strings mit dem Muster. Dabei wird vom zuletzt gefundenen String ausgegangen, um Folgen (Sequenzen) gleichartiger OUT-Strings ggf. mit verschiedenen IN's beantworten zu können. Zur Erreichung maximaler Performance wurden die hierzu erforderlichen Prozeduren in Inline-Assembler kodiert.
Auch hierbei werden die getätigten I/O-Befehle mitprotokolliert; jedoch hat dies keinen Einfluß auf den Speicherhunger des Programms mehr.

Die Möglichkeit des Speicherns bzw. des Ladens der im Speicher befindlichen Tabelle samt Ein- und Auspacken in ggf. unsichtbaren DOS-Boxen rundet das Programm ab. Die durchgehende Verwendung von Windows-API-Funktionen hält das Programm in einer angenehmen Kürze von ca. 25 Kilobyte (davon über 75% für Oberfläche und Packfunktionen). Beim Laden erfolgt ein Plausibilitätstest der eingelesenen Daten, um spätere Schutzverletzungen zu vermeiden (Keine Prüfsumme).

#$+K Das Hauptmenü
{bml mm.shg}
Klicke mit der Maus auf Dialogelemente, oder drücke TAB, um zum gewünschten Menüpunkt Hilfe zu bekommen.

#Löschen des internen Speichers. Ggf. erfolgt eine Abfrage, ob Änderungen verworfen werden dürfen. Einsetzbar beispielsweise vor einem neuen oder nach einem mißglückten Anlern-Vorgang

#Dieser Menüpunkt bringt einen Standard-Eingabedialog zum Vorschein, der zum Laden einer DK-Datei auffordert. Damit können vorher abgespeicherte Sequenzen wiederholt verwendet werden. Die Datei wird auf Konsistenz exakt geprüft, um spätere Schutzverletzungen auszuschließen. Falls bereits eine Datei geladen wurde, erscheint rechts ein Schaltfeld "Anhängen", mit dem das Aneinanderketten mehrerer .DK-Dateien (und damit mehrerer virtueller Dongles) gelingt

#Retten des internen Speichers in bereits benannte Datei. Ist die Datei unbebannt, verzweigt "Speichern" zu "Speichern als"

#Dieser Menüpunkt bringt einen Standard-Eingabedialog zum Vorschein, der zum Speichern einer DK-Datei auffordert. Damit können soeben aufgezeichnete Sequenzen gesichert werden. Zur Übertragung und Speicherung empfiehlt es sich, diese Datei packen zu lassen. Die erreichbaren Komprimierungsraten liegen um 95%, d.h. die Dateien fallen auf das Zwanzigstel ihrer Ursprungsgröße zusammen. Zwei Packverfahren stehen zur Verfügung: COMPRESS/EXPAND (ist Windows-Stil) und ZIP/UNZIP (ist schneller und portabel)

#Muß ich diesen Menüpunkt wirklich erläutern? Allerdings: Bei aufgezeichnetem und nicht gerettetem Speicherinhalt erscheint eine Sicherheitsabfrage, sofern der entsprechende Menüpunkt markiert ist.

#Anzeige der LPT-Portadressen, die im BIOS-Datenbereich stehen. Die Adressen sind gültig für die System-VM, d.h. für Windows-Programme, nicht aber zwangsläufig für DOS-Programme

#Zu Debugzwecken dient dieser Punkt zur zusätzlichen Allokation eines weiteren Megabytes zum internen Speicher hinzu

#Die Pfade, Dateinamen und Optionen zum ZIP-Packer und -Auspacker werden im folgenden Dialog eingestellt. Die Angabe der Pfade ist unnötig, sofern die Programme im DOS-Suchpfad stehen. Zu Debugzwecken kann die ansonsten {bmc check0.bmp} unsichtbare DOS-Box {bmc check1.bmp} sichtbar (Fenster) oder {bmc check2.bmp} als Icon dargestellt werden. Hinweis: Die Angabe zu COMPRESS.EXE fehlt - es wird schlicht angenommen, daß es im Pfad steht

#Viele verdongelte Programme greifen sicherheitshalber jeweils 2mal schreibend auf das Druckerport zu, was den Speicherverbrauch verdoppelt und nichts bringt. Mit diesem Schalter können identische OUT-Befehle zusammengefaßt werden. Die Einstellung und Speicherung erfolgt im VxD. Beachte: Solche mit "Out-Befehle zusammenfassen" aufgenommenen .DK-Dateien lassen sich nur in der gleichen Schalterstellung wiedergeben!

#Bei Aktivierung dieses Schalt-Menüpunkts werden Aktionen, die zur Löschung des internen Speichers nach ungespeicherter Aufzeichnung führen, mit einer Sicherheitsabfrage versehen

#In einer künftigen Version wird mit dem hierbei erscheinenden Dialog die etwas komplizierte Kommandozeile für ein Programm-Manager-Icon halbautomatisch erstellt

#Wie's dasteht: VDONGLE.386 in SYSTEM.INI eintragen. Damit erreicht man unter Windows95 die Emulation der "echten" Druckerports. Dies ist für einige lausig geschriebene Programme erforderlich. Unter Windows 3.x ist der Treiber auf jeden Fall dort erforderlich. Hier ist der Menüpunkt auch dann anzuwählen, wenn man das DKNACK-Verzeichnis bewegt hat. Andere Zeilen, die VDONGLE.386 laden würden, werden stets dabei entfernt.

#Wie's dasteht: VDONGLE.386 aus SYSTEM.INI entfernen. Macht eigentlich nur unter Windows95 Sinn und schaltet die Emulation der "echten" Druckerports wieder ab. Das spart etwas Kernel-Speicher, solange DKNACK nicht läuft

#Nach einer Sicherheitsabfrage wird folgendes entfernt:
* VDONGLE aus der SYSTEM.INI
* REG.DAT-Einträge (Registrierungs-Datenbank: Dateiverknüpfungen)
* WIN.INI-Einträge
* die Dateien DKNACK.EXE, DKNACK.HLP und VDONGLE.386 werden gelöscht
Danach beendet sich das Programm umgehend.
Bei geladenem Share versagt das Löschen von DKNACK.EXE (und unter Windows95 evtl. auch VDONGLE.386). Diese Dateien müssen dann von Hand gelöscht werden

#...bringt diese Hilfe zum Vorschein

#Programminformationen mit Versionsnummer der .EXE und des .386

#$+K Dialogelemente
{bml main.shg}
Klicke mit der Maus auf Dialogelemente, oder drücke TAB, um zum gewünschten Dialogelement Hilfe zu bekommen.

#Das System-Menü beinhaltet neben den üblichen Menüpunkte 2 zusätzliche:
* "Immer im Vordergrund" macht das Fenster zu einem stets obenauf liegenden
* "Verstecken" verbirgt das Fenster vollkommen - hervorholen läßt es sich nur durch nochmaligen Aufruf von DKNACK.EXE

Hinweis: Aufgrund der Tatsache, daß es sich um ein gewöhnliches Dialogfenster handelt, läßt sich dieses Programm mit der ESC-Taste beenden. Ich habe keine brauchbare Lösung gefunden, dieses Verhalten abzustellen, also Vorsicht!

#Dieses Feld verkleinert das Programm zum Symbol. Das Programm bleibt weiterhin in Funktion

#Das ist eine Anzeige. Hier wird die Anzahl der getätigten OUT-Befehle auf die Portadressen des Druckerports mitgezählt. Beim Laden werden (in Klammern) die in der Datei vorgefundenen OUT-Befehle angezeigt

#Das ist eine Anzeige. Hier wird die Anzahl der getätigten IN-Befehle auf die Portadressen des Druckerports mitgezählt. Beim Laden werden (in Klammern) die in der Datei vorgefundenen IN-Befehle angezeigt

#Das ist eine mit einem Schaltfeld kombinierte Anzeige. Die Anzeige stellt die Anzahl der getätigten Uhrzeit-Abfragen dar. Mit dem Schaltfeld wird das Uhrzeit-Trapping {bmc check1.bmp} ein- oder {bmc check0.bmp} ausgeschaltet. Der Zustand wird im VxD gespeichert und ist somit systemglobal

#Das ist eine Anzeige. Hier wird die Anzahl der festgestellten Vergleichsfehler bei der Stringsuche mitgezählt. Bei einer Anzeige <>0 ist eine Programm-Fehlermeldung wahrscheinlich, jedoch zeigt die Praxis eine gewisse Fehlertoleranz in den Programmen

#Mit diesem Knopf werden alle 4 Zählerstände links daneben auf Null zurückgesetzt. Dann lassen sich Zugriffe leichter erfassen, wenn die Zahlen inzwischen groß geworden sind

#Mit diesem Schaltfeld wird zwischen {bmc check0.bmp} Aufnahme und {bmc check1.bmp} Wiedergabe umgeschaltet. Es entscheided also maßgeblich das Programmverhalten. Beim Programmstart ist es leer; nach dem erfolgreichen Laden einer DK-Datei wird es automatisch angekreuzt

#Mit diesem 3-Zustands-Schaltfeld wird der Zugriffs-Tick {bmc check2.bmp} laut, {bmc check1.bmp} leiser oder {bmc check0.bmp} aus gestellt. Der Zustand dieses Schalters wird im VxD gespeichert und ist damit systemglobal. Die Schaltstellung ist auch nach dem Beenden des Programms wirksam. Die „laute“ Einstellung macht vereinzelte Zugriffe günstiger hörbar; es kann jedoch u.U. zum nervtötenden Dauerton kommen.
Es ist Multimedia, wenn der Rechner unter ohrenbetäubendem Lärm abstürzt.

#$+K Kommandozeile
DKNACK unterstützt eine Kommandozeile zum Laden der .DK-Datei sowie zur Steuerung des Erscheinungsbildes. Die einzelnen Zeichenketten sind durch Leerzeichen zu trennen.

<dateiname>
Die Angabe eines Dateinamens bewirkt das Laden dieser Datei beim Programmstart. Die Endung (.dk) muß unbedingt mit angegeben werden. Das Laden erfolgt nach der Darstellung des Dialogs, um bei langen Ladevorgängen nicht vor einem scheinbar blockierten Rechner zu sitzen.
Enthält diese Datei Uhrzeit-Informationen, wird das entsprechende Schaltfeld automatisch aktiviert (z.Z. nicht implementiert).

-title <titel>
Wem der Fenster-Titel "DongleKnacker" zu heiß ist (für den Fall, der Chef schaut über die Schulter), der kann diesem Programm einen x-beliebigen Fenster-Titel geben. "-title" an das Ende der Kommandozeile gestellt ergibt eine leere Titelzeile.

-hidden
Noch weiter geht das Versteckspiel bei Angabe dieser Option (hidden (engl.): versteckt, verborgen). Nach einem kurzen Auftauchen des Programms (ggf. als Icon) verschwindet es gänzlich von der Bildfläche. Nur verbesserte Task-Manager (wie z.B. FTaskMan) können solche Programme anzeigen. Hervorholen läßt sich dann das Programm durch nochmaligen Start des Programms. Wieder verschwinden kann es nur durch Beenden und Neustart von DKNACK.EXE.

-run <dateiname>
Hiermit wird DKNACK.EXE angewiesen, automatisch das angegebene Programm zu starten. Damit läßt sich eine Vereinfachung der Benutzung erreichen. Man beachte hierbei, daß sich DKNACK.EXE mit dem Beenden des bei -run angegebenen Programms ebenfalls beendet. Dazu filtert es Rundrufe aus der Toolhelp-Bibliothek, um das Programmende zu erfassen.

-quiet
Der Lautsprecher-Pieps, der bei Verwendung des VXDLDRs unter Windows95 per default immer angeschaltet ist, wird hiermit bei Programmstart ausgeschaltet.

Das Schalterzeichen darf "/" oder "-" sein; die Groß- und Kleinschreibung der Optionen ist unerheblich.

#$+K VDONGLE.386-Referenz
VxD-ID
Die VxD-ID ist 3B48h. Das VxD kann auch dynamisch geladen werden (unter Windows95).
Um Registrierungsschwierigkeiten aus dem Weg zu gehen, wurde das VxD unter dem Namen VELGNOD registriert.

Int2F-API-Funktionen (Nur für System-VM):
AH=0	Versionsnummer besorgen
AH=1	Callback-Adresse festlegen (ES:BX=Adresse)
Callback wird mit AL=Datenbyte und AH=Port-Festlegung gerufen
AH Bits 0..1 geben Portadresse an, AH Bit 2 ist beim Lesen gesetzt
AH=2	Callback und Puffer ausschalten
AH=3	Emulationsmodus einschalten (AL=1) oder ausschalten (AL=0), liefert in AL die vorhergehende Schalterstellung.
Bei inaktivem Callback bezieht sich die "Emulation" auf das Vorgaukeln eines fehlenden Dongles - Vermeidung von Portzugriffen z.B. bei schlecht gecrackten Programmen in Verbindung mit LPTDAC
AL=0FFh fragt aktuelle Stellung ab; Ergebnis in AL
Standard ist AUSgeschaltet.
AH=4	Zugriff-Knack laut (AL=2), leiser (AL=1) oder aus (AL=0) schalten, liefert in AL die vorhergehende Schalterstellung.
AL=0FFh fragt aktuelle Stellung ab; Ergebnis in AL
Standard ist laut geschaltet, beeinflußbar über SYSTEM.INI-Eintrag (z.Z. nur laut oder aus)
AH=5	Puffer aktivieren (ES:BX=Adresse, CX=Länge in WORDs)
Der Puffer ist in Words organisiert, ähnlich einem Pascal-String mit Unicode-Zeichen, und mit vorangestelltem Längen-Word.
Abschluß der Kette bildet ein IN-Befehl, der ebenfalls mit abgespeichert wird (jedoch nicht in die Längen-Zählung eingeht).
Ist der Puffer zu kurz, enthält das Längen-Word CX-1 und nur OUT-Befehle (kein IN am Ende). Deshalb: Puffer ausreichend dimensionieren, z.B. 2048 Words groß.
Ist ES=0, reserviert VDONGLE.386 einen internen Puffer mit der angegebenen Größe, und gibt in AX einen GDT-Selektor zurück. Der Offset des Puffers ist 0.
AH=6	Uhrzeit-Trap einschalten (AL=1) oder ausschalten (AL=0), liefert in AL die vorhergehende Schalterstellung.
Der Callback läuft über dieselbe Adresse wie bei AH=2 angegeben; dabei wird der Callback mit AX=2C01h und EDX=Uhrzeit (??) gerufen. Liefert der Callback AL=0 zurück, wird die weitere Interruptkette nicht aufgerufen, und EDX liefert dem Programm die Uhrzeit. Das Abrufen der Uhrzeit ist „verschachtelt“ möglich; VDONGLE ruft den Callback dann nicht mehr auf.
AL=0FFh fragt aktuelle Stellung ab; Ergebnis in AL
Standard ist AUSgeschaltet.
AH=7	IO-Traping einschalten einschalten (AL=1) oder ausschalten (AL=0).

Die emulierte Portadresse wird durch "VDonglePort=LPTx" oder "...=xxx" unter [386enh] festgelegt Standard ist "LPT1" - falls nicht vorhanden, dann "378h". Falls ein anderes VxD diese Portadresse trappt (z.B. beim dynamischen Laden unter Windows95 in Verbindung mit VPD.VXD) wird die emulierte Portadresse auf "37Ch" oder "27Ch" festgelegt. Das VxD trägt die neu entstehende Portadresse auf jeden Fall in die BIOS-Parametertabelle bei 40:08 ein.
Standardmäßig ist die emulierte gleich der physikalischen Portadresse (es sei denn, siehe oben). Ist dieses Verhalten nicht erwünscht, kann mit "VDonglePhys=LPTx" oder "...=xxx" eine andere Vorgabe für die hardwaremäßige Portadresse gemacht werden.
Das Knackgeräusch kann mit "VDongleTick=off" unter [386enh] per defaut ausgeschaltet werden

VDONGLE.386 wurde entwickelt, um Dongle-Zugriffe auf einen zentralen Netzwerk-Server weiterzuvermitteln. Die Ankopplung von DKNACK.EXE ist eine Zusatzlösung.

#$K+ Aufbau der .DK-Datei
Die .DK-Datei (DongleKnacker) ist eine Binärdatei. Dem 2-Byte-Header "DK" schließt sich direkt der Speicherabzug des 32-bit-Datenpuffers an, also x-mal
1 Word OUT-Words-Zahl (n)
n Words, die die OUT-Befehle beschreiben
1 Word, der den IN-Befehl beschreibt.
Ein solcher Datenblock hat demnach die Länge 2*(n+2) Bytes.

Die OUT-Words haben folgenden Aufbau:
Low-Teil: das ausgegebene Byte
High-Teil: Adresse des OUT-Bytes als Offset von Basisadresse, also
	00000000b - OUT-Zugriff aufs Datenport (Basisadresse +0)
	00000001b - OUT-Zugriff aufs Statusport (Basisadresse +1)
	00000010b - OUT-Zugriff aufs Steuerport (Basisadresse +2)

Die IN-Words haben folgenden Aufbau:
Low-Teil: das eingelesene Byte
High-Teil: Adresse des IN-Bytes als Offset von Basisadresse +4, also
	00000100b - IN-Zugriff aufs Datenport (Basisadresse +0)
	00000101b - IN-Zugriff aufs Statusport (Basisadresse +1)
	00000110b - IN-Zugriff aufs Steuerport (Basisadresse +2)

Ein Uhrzeit-Datenblock hat folgenden Aufbau:
1 Word, Kennung 802Ch
1 DWord Uhrzeit, als Bytefolge gesehen Hundertstel Sekunden - Sekunden - Minuten - Stunden

Bei .DKZ handelt es sich um eine ZIP-gepackte .DK-Datei. Dagegen weist die Endung .DK_ auf COMPRESS-gepackt hin. Die Unterscheidung des Packformates erfolgt jedoch durch Auswertung der Dateiheader-Information.

#$K+ Fehlermeldungen
Kein Fehler: Das Programm kann nicht mehrfach gestartet werden.

Runtime Error 203: Akuter Speichermangel oder Fehler in der Speicherverwaltung, Windows-Absturz könnte bald folgen.

Schutzverletzung: Tja, scheint manchmal unvermeidlich zu sein. Die Umstellung voll zur 32-Bit-Speicherverwaltung dürfte das Risiko senken helfen.

Bekannte Bugs

+ Auf manchen Windows-Installationen ist beim Ein- oder Auspacken mit unsichtbarer DOS-Box das DongleKnacker-Fenster dauerhaft blockiert. Bei sichtbarer DOS-Box wird das Problem sichtbar: das Packprogramm arbeitet erst, wenn das Fenster aktiviert wird.
Ursache: Eine unglückliche Windows-Einstellung verhindert das Laufenlassen von Programmen im Hintergrund.
Umgehung: In der Systemsteuerung (CONTROL.EXE) ist unter "386Enh" der Schalter "Exklusiv im Vordergrund" zu deaktivieren!

+ Die Aufzeichnung in der DOS-Box funktioniert oftmals nicht: der Rechner klemmt vollkommen oder tickt in langen Abständen. Auch total fehlerhafte Aufzeichnungen wurden beobachtet.
Ursache: vermutlich Probleme während der Task-Umschaltung im VxD.
Umgehung: keine bekannt. Ich arbeite daran

+ Bisweilen ertönt ein nervtötender Speaker-Dauerton. Klangt wie Absturz, das System ließ sich ansonsten korrekt bedienen.
Ursache: Ein Programm programmiert ebenfalls am Lautsprecher herum, und da prallen zwei Systeme aufeinander...
Lösung: Veränderung der Art der "Ton"-Erzeugung. Allerdings nicht ohne Nachteil: leiseres Geräusch. Insbesondere können vereinzelte Zugriffe leicht überhört werden. Deshalb die Wahl zwischen laut, leiser und aus.

Weiter geht's

Ungeknackt bleiben z.Z. Fast-E-Y-E™-Dongles. (Man erkennt sie an dem "Glasauge" mit dem Chip dahinter.) Die Abfrage derselben verwendet einen noch nicht lokalisierten Zufallsgenerator (die Uhr ist es jedenfalls nicht oder nicht allein gewesen). Der besondere Schutz steckt also keinesfalls im Dongle, sondern im Dongle-Abfrageprogramm.