vlmcsd Documentation

repository·master·Indexed 20 days ago

https://github.com/kkkgo/vlmcsd

A portable, open-source KMS (Key Management Service) emulator written in C. It includes vlmcsd, a Microsoft-compatible server; vlmcs, a testing client for debugging and charging servers; and vlmcsdmulti, a combined binary. The project supports a wide range of CPUs (x86, arm, mips, PowerPC, Sparc, s390) and operating systems including Linux, Windows, macOS, Android, and various BSDs.

Tokens
10K
Snippets
27
Records
46
Agent score
70%

What's inside vlmcsd

  1. Overview of vlmcsd components

    master

    The vlmcsd project provides three primary binaries for KMS (Key Management Service) emulation and testing:

    • vlmcs: A client used for testing or 'charging' KMS servers. It can be used to debug KMS servers or interact with genuine KMS servers.
    • vlmcsd: A fully Microsoft-compatible KMS server emulator.
    • vlmcsdmulti: A multi-call binary that contains both vlmcs and vlmcsd in a single executable.

    Usage patterns:

    • For vlmcs: vlmcs [ options ] [ target ] [options ]
    • For vlmcsd: vlmcsd [ options ]
    • For vlmcsdmulti: vlmcsdmulti vlmcs [options ] [ hostname|ip-address[:port] ] [ options ] OR vlmcsd [ options ]
    vlmcs [ options ] [ target ] [options ]
    vlmcsd [ options ]
    vlmcsdmulti vlmcs [options ] [ hostname|ip-address[:port] ] [ options ]
  2. Use the vlmcsd floppy administrative menu

    master

    The floppy144.vfd image includes a menu system accessible via the console on /dev/tty8 (press ALT-F8). This menu allows for administrative tasks without needing full Unix command knowledge.

    1. (Re)start vlmcsd: Restarts the KMS emulator (useful after editing /etc/vlmcsd.ini).
    2. Stop vlmcsd: Stops the emulator.
    3. (Re)start inetd: Restarts the inetd service (telnet/ftp).
    4. Stop inet: Stops inetd and drops all connected clients.
    5. Change the time zone: Interactively updates the time zone and restarts vlmcsd.
    6. Change keyboard layout: Selects a different keyboard map.
    7. Show all kernel boot parameters: Displays the APPEND line from syslinux.cfg.
    8. Show boot log (dmesg): Displays the kernel boot log.
    9. Show TCP/IP configuration: Shows network settings and active connections.
    10. Show running processes: Displays a real-time process list (CPU/Memory).

    Other Controls:

    • Shutdown/Reboot: Options s and r are available in the menu, though a hard power-off/reset in your hypervisor is also acceptable.
    • Shell Access: Press s during the 5-second startup window to escape to a shell.
  3. Accessing vlmcsd documentation

    master

    Documentation is available via man pages or local files within the distribution's man directory. If man is not installed, you can use the .txt, .html, or .pdf files located in that directory.

    Man page targets:

    • man/vlmcsd.8: Documentation for the vlmcsd server.
    • man/vlmcs.1: Documentation for the vlmcs client.
    • man/vlmcsd.7: General documentation regarding KMS.
  4. Customize floppy144.vfd configuration

    master

    You can customize the behavior of the floppy image by editing the syslinux.cfg file located on the image. To do this, you must mount the .vfd file.

    • Linux: Attach the file to a loop device.
    • Windows: Use software like OSFMount to mount the image.

    The configuration contains two main labels: dhcp (default) and static. To use a static IP, change the default line in syslinux.cfg from dhcp to static and configure the APPEND line under the static label.

  5. Modify the initrd filesystem permanently

    master

    Because the system is a diskless RAM disk, any changes made inside the VM are lost on reboot. To make permanent changes (like modifying /etc/vlmcsd.ini or /sbin/init), you must rebuild the initrd file on the mounted floppy.

    Unpacking the initrd

    Assuming the floppy is mounted at /mnt/floppy:

    mkdir ~/vlmcsd-floppy-initrd
    cd ~/vlmcsd-floppy-initrd
    cat /mnt/floppy/initrd | unlzma | cpio -i

    Rebuilding the initrd

    After making your modifications inside the directory:

    cd ~/vlmcsd-floppy-initrd
    find . | cpio -o -H newc | lzma > /mnt/floppy/initrd

    Warning:

    • Do not use lzma -9 for compression; the kernel will be unable to read it.
    • On Windows, you cannot unpack the initrd directly to an NTFS filesystem because NTFS does not preserve UID/GID. Use WSL on a non-mounted directory (VolFs) if working on Windows.
    mkdir ~/vlmcsd-floppy-initrd
    cd ~/vlmcsd-floppy-initrd
    cat /mnt/floppy/initrd | unlzma | cpio -i
    
    # After changes:
    cd ~/vlmcsd-floppy-initrd
    find . | cpio -o -H newc | lzma > /mnt/floppy/initrd
  6. Setup a virtual machine with floppy144.vfd

    master

    The floppy144.vfd image is a bootable 1.44 MB floppy containing a minimal Linux environment and vlmcsd(8). It is designed to run in a small virtual machine to activate the host computer (especially useful for Windows 8.1 and up).

    VM Configuration Requirements

    • RAM: Assign exactly 16 MB.
    • Storage: Add a floppy drive and attach floppy144.vfd. Do not create a virtual hard disk; the system is diskless and runs entirely from RAM.
    • CPU: Set to 1 CPU (the kernel does not support SMP).
    • Boot Mode: Use plain BIOS. If using UEFI, you must enable Compatibility Support Mode (CSM).
    • Network: Set up an ethernet card. Supported models include:
      • Intel PRO/1000
      • AMD PCNET III
      • AMD PCNET32
      • VMWare vmxnet3 (paravirtualized)
      • virtio (paravirtualized for VirtualBox, QEMU, KVM)

    Hypervisor Specifics

    • VirtualBox: Floppy boot is disabled by default; ensure it is enabled. You can select virtio in the network configuration.
    • VMWare: To use the paravirtualized driver, add ethernet0.virtualDev = "vmxnet3" to your .vmx configuration file.
    • QEMU: You must set up a TAP adapter. Port redirection will not work for host activation.

    Supported Hypervisors

    VMWare, VirtualBox, Hyper-V, and QEMU.

  7. Overview of vlmcsd

    master

    vlmcsd is a fully Microsoft-compatible KMS (Key Management Service) server designed as a drop-in replacement for a Microsoft KMS server. It provides product activation services to clients and supports KMS protocol versions 4, 5, and 6.

    It is designed for POSIX-compatible operating systems (Linux, macOS, BSD, etc.) and can run on embedded systems like routers, NASes, and mobile devices. It also has support for Windows and Cygwin.

  8. Configure ePID generation and randomization

    master

    The -r option determines how Endpoint IDs (ePIDs) are generated:

    • -r0: No randomization. Uses default ePIDs built into the binary. Behaves like a real KMS server but is easier to detect.
    • -r1 (Default): Generates random ePIDs when the program starts or receives a SIGHUP. This is the recommended mode for avoiding detection.
    • -r2: Generates a new random ePID on every single request. This is a debugging option and is very easy to detect as an emulator.

    Other ePID controls:

    • -C <LCID>: Use a specific decimal Locale ID (e.g., 1033 for English-US).
    • -H <HostBuild>: Use a specific host build number (e.g., 17763).
  9. Use vlmcsdmulti as a multi-call binary

    master

    The vlmcsdmulti binary is a combined executable that contains both the vlmcs (client) and vlmcsd (daemon/server) programs. Using this single binary reduces disk space because both programs share common code and data.

    To use it, you can either call vlmcsdmulti followed by the full command-line arguments for either vlmcs or vlmcsd, or create symbolic links to make them appear as separate executables.

    # Example of calling vlmcs via the multi-call binary
    ./vlmcsdmulti vlmcs [options] [hostname|ip-address[:port]]
    
    # Example of calling vlmcsd via the multi-call binary
    ./vlmcsdmulti vlmcsd [options]
  10. Memory considerations when using vlmcsdmulti as a daemon

    master

    While vlmcsdmulti saves disk space, running it as a daemon (KMS server) requires more RAM than running the standalone vlmcsd binary.

    To mitigate memory usage, consider running vlmcsdmulti via an internet superserver such as inetd or xinetd instead of running it as a persistent background process.

  11. Understand the risks of using OpenSSL with vlmcsd

    master

    Using OpenSSL with vlmcsd or vlmcs introduces several technical risks and constraints that developers should be aware of:

    1. Reliability Risks: The openssl_with_aes modes rely on 'hacking' OpenSSL's internal structures to support the modified AES encryption used in KMSv4 and KMSv6. This can cause the software to fail or perform unreliably, even if it worked correctly in previous runs.
    2. Compatibility Issues: The internal OpenSSL hacks are sensitive to:
      • OpenSSL version.
      • OpenSSL compile-time configuration (e.g., whether it uses compiled C code or assembler).
      • CPU architecture and features (e.g., hardware AES support).
    3. Resource Usage: Using OpenSSL generally increases the memory (RAM) footprint of vlmcsd or vlmcs compared to the default implementation.
    4. No Feature Gain: Compiling with OpenSSL support does not add any new features to vlmcs or vlmcsd; it only affects the underlying cryptographic implementation.
  12. How KMS activation works with vlmcsd

    master

    KMS (Key Management Service) is a method for activating Microsoft products using a General Volume License Key (GVLK), also known as a KMS client key. Instead of contacting Microsoft servers, the product contacts a KMS server on the local network.

    vlmcsd is an open-source KMS server implementation. It acts as the central point that clients reach out to for activation.

    Key Concepts:

    • GVLK (KMS Client Key): A special key entered into the product to tell it to look for a KMS server instead of Microsoft's servers.
    • Activation Lifecycle: KMS activation is not permanent. Standard products remain activated for 180 days (or 30/45 days for consumer-only products). Activation can be renewed as often as needed by reaching the KMS server again.
    • Server/Client Separation: Starting with Windows 8.1, the KMS server (vlmcsd) must reside on a different computer than the client being activated. You can use a virtual machine or an always-on device like a router to host vlmcsd.