Odin reaches the dongle through the SDK’s flat C API with core:dynlib, loading the native library at run time on the first call: there is no foreign import and nothing to link, so nothing sits in the path of the check that a customer could substitute for something more agreeable. No dependencies beyond Odin’s core library. The keynub_licdongle package, Odin dev-2026-03 or later, on Windows, Linux and macOS.
odin build . -collection:keynub=/path/to/KeyNub-SDK/bindings/odinCode language: JavaScript (javascript)
Reading a License
import kn "keynub:keynub_licdongle"
license :: proc() -> (data: []u8, err: kn.Error) {
d := kn.open() or_return // first dongle, or kn.open("<serial>")
defer kn.close(&d)
_ = kn.verify_genuine(d, context.temp_allocator) or_return // an error unless genuine
kn.open_session(d) or_return
defer kn.close_session(d) // closed on every exit path
return kn.read_record(d, "license")
}Code language: CSS (css)
What You Are Protecting
Odin software that is sold ships as a native executable: a tool, a game, an engine, a desktop application. A check that returns a bool compiles to one conditional branch, and patching one of those in a release binary is a beginner exercise.
So the strong pattern is the one to reach for: the data the program needs only exists when the dongle is present.
// Weak: one patched branch.
if !kn.is_genuine(d) {
os.exit(1)
}
// Strong: the parameters only exist with the dongle present.
kn.open_session(d) or_return
defer kn.close_session(d)
plain := kn.app_decrypt(d, sealed_blob_shipped_with_your_program) or_return
parameters := decode_parameters(plain)Code language: PHP (php)
Every call that can fail returns kn.Error last, so or_return works: a failed dongle call gives a Status (.No_Device, .Not_Genuine, .Auth_Required, …), a library that cannot be loaded gives a Library_Error, and error_message and last_error give the library’s detail text; is_genuine fails closed. Every procedure that allocates takes an allocator, and close makes a second close do nothing, so it sits in a defer. The package calls the SDK’s flat companion API, the one designed for foreign function interfaces: integer handles and buffers, no hand-written structure layouts.
Shipping the Native Library with an Odin Application
The keynub_licdongle package calls the SDK’s flat API through core:dynlib from the library it loads at run time: there is no foreign import, nothing is linked, and importing the package needs no library. Name the SDK clone’s bindings/odin folder as a collection (-collection:keynub=…), or copy the package folder next to your sources. A shipped executable takes keynub_licdongle_flat for its platform in natives/<platform>/ beside it, or names it with kn.set_library_path or KEYNUB_LICDONGLE_FLAT_LIBRARY.
The prebuilt libraries for every platform are in the SDK repository’s natives/<platform>/ folder, with a SHA-256 manifest: Windows x64, x86 and ARM64, Linux x86_64 and aarch64, and universal macOS binaries for Intel and Apple silicon. On Linux, install the udev rule from NATIVES.md once, so that ordinary users may open the device.
Questions Odin Developers Ask
Which Odin Versions Does the Package Support?
Odin dev-2026-03 and later, on Windows, Linux and macOS. The package has no dependencies beyond Odin’s core library.
Does the Odin Package Link Against the Native Library?
No. It loads the library with core:dynlib on the first call, so there is no foreign import and nothing to link, and importing the package needs no library.
Does a Odin Application Need Administrator Rights to Talk to the Dongle?
No, and no driver either: the dongle is a USB HID device that the operating systems handle with their built-in class drivers. On Linux, install the shipped udev rule once so that ordinary users may open it; without the rule the SDK reports access denied and names the cause in its error detail.
Does a Odin 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 a License Written from Odin 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: odin/verify_and_read.odin. Binding source: bindings/odin. 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