Skip to content

Software License Dongle for VBA, Excel and Access

Serious Excel and Access solutions get sold, copied and passed around, and VBA offers no protection of its own — project passwords are a formality. A dongle changes the economics.

64-bit Office

Import the supplied .bas module, which declares the API with PtrSafe, and deploy the 64-bit library.

Dim h As Long
Dim license() As Byte

If KeyNubDeviceCount() = 0 Then
    MsgBox "Please plug in your KeyNub license dongle."
    Exit Sub
End If

h = KeyNubOpen()                     ' first dongle found
Debug.Print "Serial: " & KeyNubVerifyGenuine(h)

KeyNubSessionOpen h
license = KeyNubRecordRead(h, "license")
KeyNubSessionClose h

KeyNubClose h                        ' always: the library holds 32 handlesCode language: VB.NET (vbnet)

32-bit Office: Use COM Instead

The core library uses the cdecl calling convention; VBA’s Declare emits stdcall. In a 64-bit process there is only one calling convention, so the difference does not exist and the Declare module is correct. In a 32-bit process neither side cleans up the arguments and the stack pointer drifts with every call.

This is a property of the calling convention, not something a careful Declare can work around: VBA has no equivalent of the CDecl keyword on Windows. So on 32-bit Office, use the COM interface instead — it is the same object VB6 uses, it works from VBA unchanged, and the calling convention stops being your problem. On 64-bit Office the Declare module is correct and is what we recommend.

Set dongle = CreateObject("KeyNub.Dongle")Code language: VB.NET (vbnet)

Gate on Data, Not a Message Box

A MsgBox and an Exit Sub are trivially deleted — anyone who can open the VBA editor can remove them. Encrypt the rate tables, pricing constants, formulas or thresholds the workbook needs, and decrypt them through the dongle at run time. Then a copied workbook opens perfectly and computes nothing.

Shipping the Native Library with an Excel Workbook

The VBA binding is a module of Declare PtrSafe statements over the SDK’s flat API, and it is verified for 64-bit Office, where Windows has a single calling convention. Deployment is keynub_licdongle_flat.dll next to the workbook or in a folder on the system PATH; it is self-contained. The DLL must match Office’s bitness, not Windows’: 32-bit Excel on 64-bit Windows needs the x86 build, and a mismatch reports file not found.

For 32-bit Office the COM server (KeyNub.dll, the Visual Basic 6 binding) is the better route, because Declare in a 32-bit process meets the cdecl-versus-stdcall difference. Access and Word take the same module as Excel.

Questions VBA Developers Ask

Can an Excel Workbook or Add-In Be Protected with a Hardware Dongle?

Yes. The workbook calls the dongle through VBA, and the data the workbook needs (rate tables, coefficients, a model) ships encrypted and is decrypted through the dongle when the file opens. A password on the VBA project protects nothing; the dongle’s data gating does.

Does the DLL Need to Be Registered or Installed?

No. The flat DLL is loaded by name from the workbook’s folder or PATH; no regsvr32, no installer, no administrator rights.

Does a VBA License Check Need an Internet Connection?

No. Verification is a local exchange between your program and the dongle over USB: the SDK checks the dongle’s certificate chain to KeyNub’s root and runs a live challenge-response. There is no activation server and no account, so the check works on air-gapped machines.

Who Can Read the License Records on a Dongle?

Anyone holding the dongle: a program opens a session and reads records, and can decrypt data sealed for that dongle. Writing records, erasing them and incrementing counters need your write key. What the dongle guarantees is that none of it is available without the dongle present.

Can Several Dongles Be Connected at Once?

Yes. The SDK enumerates every attached dongle with its serial number and device path, and you open one by serial; with no serial given, the first dongle found is used.

Can a License Written from VBA Be Read by a Program in Another Language?

Yes. Every binding drives the same core library and the same dongle, and records and sealed data are language-neutral bytes. Your issuing tool can be written in one language and your product in another.

Code

Runnable sample: vba/verify_and_read.bas. Binding source: bindings/vba. Both are Apache-2.0, in the public SDK repository; the prebuilt native libraries are in the repository’s natives/ folder, one per platform.

All supported languages · All industries · Buy a KeyNub · Ask us something