vlmcsd/man/vlmcs.1.unix.txt

VLMCS(1)                     KMS Activation Manual                    VLMCS(1)



NAME
       vlmcs - a client for testing and/or charging KMS servers


SYNOPSIS
       vlmcs [ options ] [ target ] [ options ]

       target can be one of the following:

              hostname|ipaddress[:tcp-port]  to  query  a  specific KMS server
              (example: vlmcs kms.example.com:1688).
              .domain to automatically detect KMS servers via DNS  for  domain
              (example:  vlmcs  .example.com).  Please  note  the  dot  before
              domain.
              - (a single dash) to detect KMS servers in your own domain.

       If you use ipaddress:port as the target, the ipaddress must be enclosed
       in  brackets  if it contains colons, e.g. [2001:db8:dead:beef::1]:1688.
       If you use a link-local IPv6 address on Unix systems, you must append a
       percent  sign and the interface identifier of the source interface, for
       example fe80::dead:beef%eth0.

       If you omit the target, 127.0.0.1:1688 will be used except if  you  use
       -i6. In this case the default target is [::1]:1688.


DESCRIPTION
       vlmcs  is a program that can be used to test a KMS server that provides
       activation for several Microsoft products. The KMS server may  also  be
       an emulator. It supports KMS protocol versions 4, 5 and 6.

       vlmcs  generates  one  or  more activation requests for a Microsoft KMS
       product and sends it to a KMS server. It then analyzes and displays the
       responses of the KMS server.

       vlcms  checks  both the DCE-RPC protocol and the activation message for
       correctness and reports any errors that it finds.

       vlmcs can also be used to "charge" a KMS server. A Microsoft KMS server
       sends  correct activation messages only if it detects a certain minimum
       of clients (25 for Windows client OSses, 5 otherwise) on  the  network.
       This is Microsoft's futile attempt to prevent running a KMS server in a
       home environment.


OPTIONS
       -h or -?
              Show help.


       -V     Displays extended version information. This  includes  the  com‐
              piler used to build vlmcs, the intended platform and flags (com‐
              pile time options) to build vlmcs. If you have the  source  code
              of vlmcsd, you can type make help (or gmake help on systems that
              do not use the GNU version of make(1) by  default)  to  see  the
              meaning of those flags.


       -x     Show valid applications that can be used with -l.


       -e     Show some examples how to use vlmcs correctly.


       -v     Be verbose. Instead of just displaying the returned ePID and the
              HwId (protocol v6 only) vlmcsd shows all details  of  the  query
              and the response.


       -l application
              Request  activation  for a specific application.  Valid applica‐
              tions can be displayed by using -x.  The default application  is
              Windows  Vista  Business.  The list of available applications is
              not complete. You may supply GUIDs with -a, -k and -s to specify
              applications  that are not listed with -x. The -l option is used
              as a shortcut for the most common applications.


       -K protocol-version
              Force a specific version of the KMS protocol. Valid versions are
              4.0,  5.0  and  6.0. The default is to select a suitable version
              according to the application selected. You may use -K to send an
              incorrect  protocol  version  to  the  KMS server and see how it
              behaves. Genuine KMS servers return HRESULT  0x8007000D  if  the
              KMS  protocol  is  not  4.0, 5.0 or 6.0. Emulators should do the
              same. When sending a request with an incorrect protocol  number,
              vlmcs ignores the minor protocol number (e.g. sends a v4 request
              for version 4.1). If the major version number is less then 4, it
              sends  a  v4 request. If the major version is greater then 6, it
              sends a v6 request. In any case the protocol-version  as  speci‐
              fied by -K is put in the version fields of the request.


       -4, -5 and -6
              Force  version  4, 5 or 6 of the KMS protocol. These options are
              actually shortcuts of -K 4.0, -K 5.0 and -K 6.0.


       -j filename
              Use KMS data file filename. By default  vlmcs  contains  product
              data  that is recent when vlmcs was compiled. You may use a more
              recent KMS data file that contains additional products.

              If vlmcsd has been compiled to use a default KMS data file,  you
              may use -j- to ignore the default configuration file.


       -m     Let  the  client pretend to be a virtual machine. Early versions
              of Microsoft's KMS server did not increase the client  count  if
              the  request  came from a virtual machine. Newer versions ignore
              this flag.


       -d     Use NetBIOS names instead of DNS names. By default vlmcsd gener‐
              ates  some random DNS names for each request. If you prefer Net‐
              BIOS names, you may use -d.  A real Microsoft activation  client
              uses  DNS names or NetBIOS depending on the client name configu‐
              ration. KMS servers treat the workstation name as a comment that
              affects  logging only. Clients will be identified by a GUID that
              can be specified using -c. -d has no effect if you also  specify
              -w.


       -a application-guid
              Send  requests with a specific application-guid.  There are cur‐
              rently only three known valid application-guids:


              55c92734-d682-4d71-983e-d6ec3f16059f (Windows)
              59a52881-a989-479d-af46-f275c6370663 (Office 2010)
              0ff1ce15-a989-479d-af46-f275c6370663 (Office 2013)


              A Microsoft KMS server uses these GUIDs to have  seperate  coun‐
              ters  for  the already activated clients. A client that does not
              contact the KMS server within 30 days will be deleted  from  the
              database. Emulated KMS servers are always fully charged.


       -k kms-guid
              Send  requests with a specific kms-guid.  A Microsoft KMS server
              uses these GUIDs as a product id  to  decide  whether  to  grant
              activation  or  not. A list of current kms-guids can be found in
              kms.c (table KmsIdList). Emulated KMS servers  grant  activation
              unconditionally and do not check the kms-guid.


       -s activation-guid
              The  activation-guid  defines  the actual product, e.g. "Windows
              8.1 Professional WMC KMSCLIENT edition". A activation-guid  maps
              1:1  to  a product key.  However, neither a Microsoft KMS server
              nor emulated servers check this id.  The activation-guid is use‐
              ful  in logging to get a specific product description like "Win‐
              dows 8.1 Professional WMC". A list of  current  activation-guids
              can be found in kms.c (table ExtendedProductList).


       -n requests
              Send  requests requests to the server. The default is to send at
              least one request and enough subsequent requests that the server
              is   fully  charged  afterwards  for  the  application-guid  you
              selected (explicitly with -a or implicitly by using -l).


       -T     Causes to use a new TCP connection for each request if  multiple
              requests  are  sent with vlmcsd. This is useful when you want to
              test an emulated KMS  server  whether  it  suffers  from  memory
              leaks.  To  test  for memory leaks use -n with a large number of
              requests (> 100000) and then test twice (with and  without  -T).
              This  option may become neccessary for future versions of Micro‐
              soft's KMS  server  because  multiple  requests  with  different
              clients-guids  for the same kms-id-guid are impossible in a real
              KMS szenario over the same TCP connection.


       -c client-machine-guid
              Normally vlmcs generates a random client-machine-guid  for  each
              request.  By  using  this option you can specify a fixed client-
              machine-guid This causes a Microsoft KMS not  to  increment  its
              client  count because it receives multiple requests for the same
              client. Thus do not use -c if you want  to  charge  a  real  KMS
              server.


       -o previous-client-machine-guid
              If the client-machine-guid changes for some reason, the real KMS
              client stores a previous-client-machine-guid which  is  sent  to
              the    KMS    server.    This   happens   rarely   and   usually
              00000000-0000-0000-0000-000000000000 is used. You can use -o  to
              specify a different previous-client-machine-guid.


       -G filename
              Grabs  ePIDs and HWIDs from a KMS server and writes the informa‐
              tion to filename in format suitable to be used as  a  configura‐
              tion file (aka ini file) for vlmcsd(8).  This is especially use‐
              ful if you have access to a genuine KMS server and want  to  use
              the same data with vlmcsd(8).

              If  filename does not exist, it will be created.  If you specify
              an existing filename, it will be updated to use the  information
              received  from the remote KMS server and a backup filename~ will
              be created.

              -G cannot be used with -l, -4, -5, -6, -a, -s, -k, -r and -n


       -w workstation-name
              Send requests with a specific workstation-name.   This  disables
              the  random  generator  for  the workstation name. Since it is a
              comment only, this option does not have much effect.


       -r required-client-count
              Also known as the "N count policy". Tells the  KMS  server  that
              successful  activation  requires  required-client-count clients.
              The default is the required-client-count that the product  would
              need  if  the  request  was  a  real activation. A Microsoft KMS
              server counts clients up to the double amount what was specified
              with -r. This option can be used to "overcharge" a Microsoft KMS
              server.


       -t status
              Reports a specific license status to the KMS server. status is a
              number  that can be from 0 to 6. 0=unlicensed, 1=licensed, 2=OOB
              grace,  3=OOT  grace,  4=Non-genuinue   grace,   5=notification,
              6=extended grace. Refer to TechNet ⟨http://
              technet.microsoft.com/en-us/library/ff686879.aspx#_Toc257201371⟩
              for  more  information.  A  Microsoft  KMS  server collects this
              information for statistics only.


       -g binding-expiration
              This tells the KMS server how long a client  will  stay  in  its
              current  license status. This can be the remaining OOB time (the
              grace peroid that is granted between installation of  a  product
              and  when  activation is actuall required) or the remaining time
              when KMS activation  must  be  renewed.   binding-expiration  is
              specified in minutes. A Microsoft KMS server apparantly does not
              use this information.


       -i protocol-version
              Force the use of  Internet  protocol  protocol-version.  Allowed
              values  are 4 (IPv4) and 6 (IPv6). This option is useful only if
              you specfiy a hostname and not  an  ip-address  on  the  command
              line.


       -p     Do  not  set  the RPC_PF_MULTIPLEX flag in the RPC bind request.
              This can be used to test if the KMS server uses the same setting
              of  this  flag in the RPC bind respone. Some KMS emulators don't
              set this correctly.


       -N0 and -N1
              Disables (-N0) or enables (-N1) the NDR64 transfer syntax in the
              RPC  protocol.  Disable NDR64 only in case of problems. If NDR64
              is not used, vlmcs cannot detect many RPC protocol errors in KMS
              emulators. If you want to test whether a KMS emulator fully sup‐
              ports NDR64, you must use the -n option to  send  at  least  two
              requests.  This  is  because Microsoft's client always sends the
              first request using NDR32 syntax and subsequent  requests  using
              NDR64 syntax.


       -B0 and -B1
              Disables  (-B0)  or  enables (-B1) bind time feature negotiation
              (BTFN) in the RPC protocol. Disable BTFN only in case  of  prob‐
              lems. If BTFN is not used, vlmcs cannot detect many RPC protocol
              errors in KMS emulators.


       Options that do not require an argument can be specified together  with
       a  single  dash,  e.g.  vlmcs -6mvT. If you specify an option more than
       once, the last occurence will be in effect.


FILES
       vlmcsd.ini(5)


EXAMPLES
       vlmcs kms.example.com
              Request activation for Windows  Vista  using  v4  protocol  from
              kms.example.com.   Repeat  activation  requests  until server is
              charged for all Windows products.


       vlmcs -
              Request activation for Windows Vista using v4  protocol  from  a
              KMS server that is published via DNS for the current domain.


       vlmcs .example.com
              Request  activation  for  Windows Vista using v4 protocol from a
              KMS server that is published via DNS for domain example.com.


       vlmcs -6 -l Office2013 -v -n 1
              Request exactly one activation for Office2013 using v6  protocol
              from localhost. Display verbose results.


       vlmcs kms.bigcompany.com -G /etc/vlmcsd.ini
              Get  ePIDs  and  HWIDs from kms.bigcompany.com and create/update
              /etc/vlmcsd.ini accordingly.


BUGS
       Some platforms (e.g. Solaris) may have a man(7) system  that  does  not
       handle  URLs.  URLs  may be omitted in the documentation on those plat‐
       forms. Cygwin, Linux, FreeBSD and Mac OS X are known to work correctly.


AUTHOR
       Written by Hotbird64


CREDITS
       Thanks to CODYQX4, crony12, deagles,  DougQaid,  eIcn,  mikmik38,  nos‐
       ferati87, qad, Ratiborus, vityan666, ...


SEE ALSO
       vlmcsd(7), vlmcsd(8), vlmcsdmulti(1)



Hotbird64                        November 2016                        VLMCS(1)