 |
Zentitle SDK and Library
|
Information passed to nalpeiron
There are three methods by which information is passed to Nalpeiron. Online licensing requests, offline activation requests and analytics. The analytics portion of the library is under your control and passes the information you choose to pass to Nalpeiron. The offline and online licensing pass similar information. A licensing or activation request will contain the current license if one exists. If there is no license present on the system a "stub" license will be created for internal use and passed to Nalpeiron. In general, this would mean that the request contains standard licensing information: computerID, timestamps, your customerID/productID, features, elements pools, etc. Unless you have included the xmlRegInfo string in your call to NSLRequestActivationCert(or NSLGetLicense) there will be no personally identifiable information in the request. If you have used the xmlRegInfo string, whatever you put into it will be included in the request.
WorkDir: the storage location for licensing and analytics files
The Nalpeiron libraries have a few files they need to create and store. These files are created in the WorkDir. The WorkDir can be specified at startup during the call to NalpLibOpen using the <WorkDir> tag. When you chose a directory for the WorkDir you should ensure that your user will have the correct permissions to create files in it, open and read/write files. For more information see https://support.nalpeiron.com/hc/en-us/articles/360005759374-Developers-API-Latest-. If the WorkDir does not exist the library will attempt to create this directory.
It is best practices to supply this value at initialization but, if it is not, the library will fall back to its default path which varies by OS.
On Unix-like systems (Linux, OSX, BSD, etc) the default location of the WorkDir is ~/.nalpeiron (where ~ indicates the user's home directory).
On Windows systems the default path is CSIDL_COMMON_APPDATA/Nalpeiron where CSIDL_COMMON_APPDATA is a environment variable set by the OS but user modifiable.
Again, you are encouraged NOT to rely on these default values but to specify the location of the WorkDir at library initialization. In general, different users should not share the same WorkDir.
Nalpeiron V10 uses AES-256 to encrypt both the local license file and licensing transactions with the Nalpeiron server or daemon. The transaction between the server and client is conducted in SOAP with an AES-256 encrypted payload. In addition, if you have selected the https option on you library during creation, the entire SOAP envelop will be encrypted as well. If you have selected https, the https encryption will be an envelope containing the normal encryption.
If you use the analytics section of the library, the information is encrypted in transit with an internally developed encryption method. As in the case of licensing the transport protocol is SOAP. If https is enabled, the entire envelope is encrypted as well. If the analytics is stored locally in a cache file due to transmission failure, it is stored in modified plain text.
Port and website information for online licensing
The library contacts my.nalpeiron.com (184.106.60.185) port 80(http) or 443(https) for licensing.
The library contacts nsa.nalpeiron.com (184.106.60.183) port 80(http) or 443(https) for analytics collection.
These are the ONLY ip addresses and ports that need to be white listed for licensing and analytics to occur.
Default library uses only port 80 but is encrypted
The default Nalpeiron library uses ONLY port 80. This is so that most firewalls and corporate connections will allow passage of Nalpeiron communications without modification. The communication is carried out with a SOAP protocol and ALL sensitive information is encrypted inside a CDATA tag. We believe this format provides the best of all worlds – secure, encrypted data that is valid http and able to pass over port 80.
You can enable https in the library if you prefer. This may be done when the library is created by selecting force https on the Nalpeiron website. If this option is selected the library will always use https regardless of intialization options.
Alternatively, you may select https at library initialization by passing
<HTTPSEnabled>1</HTTPSEnabled>
if this option is enabled the library will use https (port 443) for all connection to the nalpeiron server. This option must be enabled at each library initialization. It is not persistent.
Heap growth with repeated dlopen/dlclose The Nalpeiron library uses OpenSSL (LibreSSL actually but both behave in the same manner) internally for encryption, TLS, etc. The growth in RSS and VSZ is caused by the way that OpenSSL intializes and then cleans up after itself when dlopen/dlclose are used in combination with threads. The growth is small (approximately 8k for each dlopen/dlclose combination) and, in most applications could be ignored. If your application will use dlopen/dlclose enough that you feel the 8k is a problem, you should use RTLD_NODELETE in your dlopen call. Doing so will stop the growth of RSS/VSZ.
NSLGet*ExpSec vs NSLGet*Expdate
Both functions return the information about expiration dates. NSLGet*ExpSec is the primary function. It returns either the remaining seconds in the period (*sec parameter) or the absolute period expiration date (expEpoch) as seconds since the epoch start (midnight Jan 1, 1970). returns the date of the expiration. If the expiration date has past then the number of seconds remaining until expiration (*sec) will be 0.
The NSLGet*ExpDate function is a convenience function that converts the number of remaining seconds until expiration into a future date. If the number of seconds remaining is 0, it will return the current date.
Permissions and ownership on unix-like systems (WorkGroup tag)
The "WorkGroup" tag may be included in a call to NalpLibOpen to set the group ownership of the files in you WorkDir on Unixlike systems. To use this tag, you'd send in something like <WorkGroup>wheel</WorkGroup>. At initialization the library will ensure that group exists (you'll get a -3072, "invalid group", if it does not) and any files created will be accessible by the group specified inside the tag.
By default (WorkGroup = NULL) the library leaves everything alone and the permissions on the files created are set by the system default (0666 for files and 777 for directories) as changed by the system's default umask (002 on most Linux and FreeBSD systems which results in 0664 for files, 0775 for directories. 022 on OSX which results in 0644 for files, 0755 for directories).
If a group is set via WorkGroup, we chown the files to that group and force our umask to 002. This gives 0664 permissions on both Linux and OSX on files and 0775 for directories.
There is a special group called "nalpworld". If you use it in the WorkGroup tag, everyone will have access to all the libraries files. That is, if the group is set to nalpworld the umask is set to 000 and the file permissions to 0666 and directory permissions to 0777.
To allow all users on a system access, you should be able to either add all users to a group and pass that group into NalpLibOpen (ie all users are members of the Anime group and pass in <WorkGroup>Anime</WorkGroup>. Or, you can just pass in <WorkGroup>nalpworld</WorkGroup> which will give everyone access.
A couple of caveats to all this... The library won't change the permissions of existing files. Before testing or running you should make sure that you delete all the existing file (sinfo, cache, log and lic). On an enduser's system, you could change the permissions and ownership of existing files/directories with your installer.
On Windows, WorkGroup will have no effect. However, you can include it in the NalpLibOpen XML without harm. To control ownership on Windows, you can create the containing directory with the permissions you want and let the files inherit those permissions.
Clearing out an existing Activation Certificate Request (-1121 Error)
When a request for an activation certificate is made the library creates a "receipt" of that request. When the activation certificate is installed on the local system if is verified against that receipt for security purposes. Unfortunately, the activation certificate might arrive hours, or days, or months or ... after the request was initiated. If, during this delay, a second request for an activation certificate is made the local receipt will change. If the originally requested activation certificate is presented to the system it will fail as the system now has the receipt for the second request. Disallowing a second certificate request until the first is complete is the easiest way of preventing confusion.
That said, one way of allowing a second certificate request to be initiated is to call NSLImportCertificate with the string "clear" in place of the certificate. That is" ```NSLImportCertificate(licenseNumber, &licenseStat, "clear");```
This call will clear the receipt and return an error condition if one has occurred. In older versions of the library (< 3.2.7) you may clear the existing receipt by passing a NULL pointer into the library in place of the certificate. However, the library will return an error even as the receipt is cleared indicating that the activation certificate is invalid. Alternatively, removing all files from the WorkDir will also clear out the receipt.
NSLValidateLibrary, PSLValidateLibrary, NSAValidateLibrary returning error When providing a customer ID or product ID to the library, you should only provide the last 5, non-zero digits. That is, if your productID were 2134000005678 all calls into the library that require a product ID would use 5678. Calling a ValidateLibrary function with your full customer ID and/or product ID will result in an error indicating an invalid library.
WorkGroup tag and permissions To use this tag, you'd send in something like wheel. At initialization the library will ensure that group exists (you'll get a -3072, "invalid group", if it does not) and any files created will be accessible by the wheel group. Some details as to how this works. Normally (WorkGroup = NULL) the library leaves everything alone and the permissions on the files we create are set by the system default (0666 for files and 777 for directories) as changed by the system's default umask (002 on most Linux -> 0664 for files, 0775 for directories and 022 on OSX -> 0644 for files, 0755 for directories). If a group is set via WorkGroup, we chown the files to that group and force our umask to 002. This gives 0664 permissions on both Linux and OSX on files and 0775 for directories. There is a special group called "nalpworld" (ie nalpworld). If you use it, everyone will have access to all the libraries files. That is, if the group is set to nalpworld the umask is set to 000 and the file permissions to 0666 and directory permissions to 0777. To allow all users on a system access, you should be able to either add all users to a group and pass that into NalpLibOpen (ie all users are members of the Anime group and pass in Anime. Or, you can just pass in nalpworld which should give everyone access. A couple of caveats to all this The library won't change the permissions of existing files however. Before testing or running you should make sure that you delete all the existing file (sinfo, cache, log and lic). On an enduser's system, you could change the permissions and ownership of existing files/directories with your installer. On Windows there will be no effect. However, you can include it in the NalpLibOpen XML on Windows without harm. That way you can use the same XML on all three OSes. For Windows, you can create the containing directory with the permissions you want and let the files inherit those permissions.
Authentication values and security offset The error code used by Nalpeiron begin at -1000 and proceed downward from there. If you are getting a return value outside this range, it is almost certainly a problem with the security offset.
The security offset is calculated using some of the values you pass into the library's initialization function then added to the return value of every function for added security. All return values must have the offset removed (as simple as retval = retval - offset) to find the "real" return value.
Here is the pertinent part of the docs:
When you stamped your library, you were offerred the chance to include three authentication values. These three values along with a random number are used to generate an offset to the return values from the Nalpeiron library. This "security offset" is used to help prevent "spoofing" of the library. In your code, you generate the same offset and subtract it from the library returns. The offset is generated as shown in the snippet below:
unsigned int xauth = your xauth value; unsigned int yauth = your yauth value; unsigned int zauth = your zauth value; int offset;
srand((unsigned)time(NULL)); security = 1 + (unsigned int)(500.0 * rand() / (RAND_MAX + 1.0)); offset = xauth + ((security * yauth) % zauth);
The security value is passed into NalpLibOpen with the tag. offset is the part you have to calculate in you code and subtract from each return value.
SSO license expiration vs authentication expiration The OpenID JWT passed into the library is used for authentication of users credentials. After validation, the credentials are passed to the Nalpeiron server when retrieving a license. Both the JWT and the returned license have expiration dates associated with them. These two expirations are used for different things. The license's expiration dates work in the same manner as they always have. The JWT's expiration will cause the authentication values to expire.
In practice, this means that when a license is retrieved so long as that license is not refreshed it will remain valid for its normal duration (ie expiration will occur due to lease period expiration, subscription period expirations, etc as appropriate). However, once the credentials (JWT) expire they will no longer be considered as a valid authentication method. So, after JWT expiration you will not be able to use the credentials to retrieve a new license or refresh an existing license.
**-1074 library already initialized**
A 1074 error indicates that you are re-initializing (ie calling NalpLibOpen) from a process that has already initialized the library.
The library can only be initialized once from a given process. If you wish to use the library in a multi-threaded process, you should initialize the library in the main thread before other threads are started. Once the library has been initialized in this manner it is safe to use in other threads.
Using the library in different processes should be fine and shouldn't result in this error.
The error return -1089 has been replaced with -7089 in Nalpeiron libraries 3.2.x and newer.
-1089/-7089 errors are indications of suspicious licensing data. Of course, the majority of these errors are going to be normal issues and not attempts at piracy or tampering. The first attempt at handling a 1089/7089 error would be to call NSLGetLicense. This will "refresh" the local license file with correct information.
If the 1089/7089 error is a return from NalpLibOpen this won't work as the library must be initialized before calling other functions. A 1089/7089 error during initialization is a little more suspicious than such a return from other functions but, as a first correction attempt, can be handled in a similar manner. In this remove the license file (delete it from the WorkDir) and call NalpLibOpen again.
If the 1089/7089 error persists after either calling NSLGetLicense or deleting the license file then the issue needs to be examined more closely. At that point, you should increase the LogLevel to >= 4 and examine the log (or pass the log to Nalpeiron for examination).
**-1114 Error in offline activations**
The receipt is a security measure to prevent an offline activation from being used multiple times or on different machines. When the library initiates an offline transaction of some sort, it keeps a local record of the fact– the "receipt". That record stores the sort of transaction has been requested, uniquely identifies the transaction, etc. When it receives the certificate that originated at the Nalpeiron server, it checks the certificate against the receipt. If the check fails an error is returned.
A -1114 error indicates that the receipt is missing.
When an offline transaction is complete, the library deletes its receipt. So attempts to reuse a certificate could cause this error. This error will also occur if the receipt has been deleted by the end user. Or, if the WorkDir of the library had been changed for some reason. The receipt is stored in the license file. So, if you are able to access the license file on the user's computer (ie getting a license status from it or something similar) then I would say attempted re-use of the certificate is the most likely cause.
**-1152 Cached credentials need auth**
A -1152 (Cached credentials need auth) indicates that the library was shutdown while having a valid ABL license in place.
If, when using Account Based Licensing (ABL), you shutdown the library with a valid license in place (license status > 0) then the library will require you to authenticate against the value used to obtain the license on restart. Until you validate credentials against the license, the license will remain in a -70 license status and this error will be returned when you attempt to access entitlements and information.
To validate against the existing credentials, first call NSLSetCredentials with the required credentials then call NSLCheckCredentials to authenticate. Once you have done this, the license will return to its original status and you should no longer receive -1152 errors.
There is some related information you might like to be aware of:
If you wish, you can avoid this situation entirely by returning the license before shutting down the library.
Also, even if the license is in a -70 state it can still be returned to the Nalpeiron server (NSLReturnLicense or similar). In this case, if the license is returned with a -70 status the server will still return a "seat" to the available checkout pool along with any outstanding features, elements, etc. A forced return of this type may be used if the end user forgets their credentials or similar situations.
**-2023 most likely indicates a corrupt license file**
A -2023 error is an "invalid encryption" error. This means that the library was unable to decrypt the license file which usually indicates a corrupt license file. The only solution is to delete the license file, restart the library and refresh the license with NSLGetLicense or NSLImportCertificate as appropriate.
**-4006 Server returned invalid XML**
The Nalpeiron server responds to the client using XML. This error message indicates that the incoming communication is not valid XML. Usually the error is caused by an intervening proxy server (or similar type of server) issuing a message.
**-4200 to -4299 error returns**
The -4200 to -4299 errors are licensing error messages returned from the Nalpeiron server in response to the client's request. Some of the more common are:
-4211 The default lease period is missing from the license code's configuration -4212 The license number included in the request is invalid -4213 Client has invalid date (resolve by having end user set correct time/date on their system) -4215 End user's system is a virtual machine indentical to one in use. Only occurs with VM detection set. -4216 Account based licensing account not found -4217 Account based licensing password failed
**-7135 heartbeat terminated**
When a client library requests a license (network seat) from the daemon via a call to NSLGetLicense it automatically begins and maintains a heartbeat with the daemon. The library does this by starting a heartbeat thread which contacts the daemon once every heartbeat period. During this contact, if any changes have been made to the product license on the daemon, the client license will be updated. The heartbeat thread is terminated when the license is returned to the daemon (NSLReturnLicense) or at library close (NalpLibClose).
When requests for floating features, elements or even license returns come into the daemon, the daemon checks for the existence of corresponding heartbeat. If the heartbeat for that client doesn't exist then the daemon will refuse the transaction with a -7135 error.
If the library is closed with an outstanding heartbeat then the library will attempt to restart that same heartbeat when NSLGetLicense is next called. Whether or not this is successful will depend on how much time has elapsed since the heartbeat thread was terminated. If more than 3 heartbeat periods have passed then the daemon will have returned the client's entitlements to their respective pools and discontinued the heartbeat. If this is the case then a new heartbeat will be started.
Likewise, if the daemon is shutdown with outstanding heartbeats it will do its best to restart them when it is restarted. However, if more than 3 heartbeat periods have passed then the client will have marked its license as invalid and terminated its heartbeat thread.
The most common cause of a -7135 error is a sequence of event similar to
1.) NalpLibOpen
2.) NSLGetLicense
3.) NalpLibClose
4.) NalpLibOpen
5.) NSLReturnLicense
In step 2, the library will have obtained a license and created a heartbeat thread. At step 3, the heartbeat is terminated. When step 5 occurs, there is no heartbeat thread communicating with the daemon and the daemon will refuse the return with a -7135. To resolve this error the proper sequence of events would be
1.) NalpLibOpen
2.) NSLGetLicense
3.) NalpLibClose
4.) NalpLibOpen
4a.) NSLGetLicense
5.) NSLReturnLicense
where step 4a will restart the existing heartbeat if possible and, if not, start a new heartbeat thread.
**-10000000 or return of that magnitude**
Short explanation of -10000000 return:
A negative return value indicates an error occurred. That particular error would indicate that a call has been made into the library without first having been initialized with a call to NalpLibOpen.
Longer:
When the library is initialized it sets up internal structures needed to operate. One of the things passed into the initialization routines are the authentication constants. These constants are used to construct a psuedo-random security offset that is added to the return value from many functions. The security offset is intended to make spoofing of the library more difficult.
If one of the library functions is called without the library having been initialized the library needs to return an error condition (return value < 0). It cannot use the security offset because without initialization the library cannot construct the security offset. In this situation, the library returns a large, negative value (-10000000) that will still be a large, negative value even after the calling program adjusts with the security offset.
An error return in the neighborhood of -10000000 means a library function has been called but NalpLibOpen was never called or was called and failed (with a < 0 error return) or NalpLibClose was called and then further calls into the library were made.
Invalid Error Codes: Security offset value and authentication values
The error code used by Nalpeiron begin at -1000 and proceed downward from there. If you are getting a return value outside this range, it is almost certainly a problem with the security offset.
The security offset is calculated using values placed in the library at creation and with values passed into the library's initialization function. The security offset is then added to the return value of every function for added security. All return values must have the offset removed (retval = retval - offset) to find the "real" return value.
Here is the pertinent part of the docs:
When you stamped your library, you were offerred the chance to include three authentication values. These three values along with a random number are used to generate an offset to the return values from the Nalpeiron library. This "security offset" is used to help prevent "spoofing" of the library. In your code, you generate the same offset and subtract it from the library returns. The offset is generated as shown in the snippet below:
``` unsigned int xauth = your xauth value; unsigned int yauth = your yauth value; unsigned int zauth = your zauth value; int offset;
srand((unsigned)time(NULL)); security = 1 + (unsigned int)(500.0 * rand() / (RAND_MAX + 1.0)); offset = xauth + ((security * yauth) % zauth); ```
The security value is passed into NalpLibOpen with the tag. offset is the part you have to calculate in you code and subtract from each return value.
Interactions between dynamic and passive libraries
If the passive library is initialized with a WorkDir containing both a passive license file and a dynamic license file, the dynamic file will be ignored.
If NSL is initialized with a WorkDir containing both a passive and dynamic license file, the passive file will be ignored.
If NSL is initialized with a WorkDir containing ONLY a passive, the passive license file will be opened and information read from it. The passive license's license status will be changed to PROD_SHAFER_INVALID(-60) and be written back to disk. NSL will then create a dynamic license file from this information and write it to disk. The license status of this new file will be -1 and any active features or UDF value will be marked inactive. Thus, immediately after opening NSL in this situation, NSLGetLicense or NSLImportCertificate should be called to obtain a license. NOTE - For shafer to read the simon file at initialization, the simon license code (decrypt key) must be passed into the shafer initialization XML in the "LicenseCode" tag.
**-1138 return from dynamic licensing (NSL) library** If the dynamic licensing library's (NSL) WorkDir contains a passive license file but NOT a dynamic license file, the library will attempt to read the passive license and, to do so, it must be able to generate the encryption key used for the passive license file. A -1138 error return indicates that NSL was not provided the license code needed to generate the encryption key. That is, it was initialized without the "LicenseCode" tag containing the "clientID" for the passive library (see Interactions between dynamic and passive libraries).
A status of -112 indicates that the computer has at some point had a full licensing install but is asking for a trial.
That is, at some point the computer in questions had a trial license which either expired or was replaced by a full license. A trial license is obtained from NSLGetLicense when that function is called without a License Code (a NULL pointer really). Such a request has been done and the Nalpeiron server is responding to the request with a -112 status.
If you are testing and want to allow a computer to have a second trial, you will have to go to the Nalpeiron website and delete information about your trial computer from the server. To do so, navigate to Nalpeiron's website then to "View and Manage Codes". From the resulting list, find the code in question and choose "Devices and Activity". From the list of devices that have used that code pick the one to have a second trial and delete it.
A license status of -113 indicates that the trial period for the license has expired.
If you are testing and want to allow a computer to have a second trial, you will have to go to the Nalpeiron website and delete information about your trial computer from the server. To do so, navigate to Nalpeiron's website then to "View and Manage Codes". From the resulting list, find the code in question and choose "Devices and Activity". From the list of devices that have used that code pick the one to have a second trial and delete it.
Hashing the library before loading
In our experience, the most common piracy exploits involve modifying the program binary so that it does not call into the licensing library. We have a number of tips available to help make such modifications more difficult. Those changes are the most important steps you can take to prevent tampering. In addition, the licensing library itself has a number of anti-tempering devices built into it. Among these are the security constants and the NSA/NSLValidateLibrary functions. If, in addition to these measures, you would like to take extra steps to ensure the validity of the licensing library we suggest using a cryptographic hash.
A cryptographic hash function associates a number with a given input. The hash's output has a couple of important properties. It is impractical or impossible to invert the function (reproduce the input given its associated number). Also, it is impractical or impossible to find different inputs that would result in the same output. These two features make it possible to ensure that the library you load into your program is in fact the Nalpeiron licensing library that you downloaded from our server.
There are various hash functions available including md5, sha1, sha256, etc. The md5 and sha1 are theoretically vulnerable to attack while sha256 is considered safe and we recommend its use.
The general verification procedure would be to calculate the sha256 hash of your STAMPED Nalpeiron library and record that hash value in your binary. When your program is run on an end user's system before loading the library you would re-calculate the hash. The re-calculated hash value should be compared to the stored hash value. If they don't match, your program should refuse to load the library and exit. If they do match, you should load the library and continue with no further changes.
Following this guideline will ensure that the library you are loading into your binary is the Nalpeiron licensing library and not an attempt to subvert licensing.
It's impossible to create a software application which is impervious to all possible 'cracking' attacks. However, we suggest the following practices for making a would-be cracker's task more difficult:
* Use the security constants for the API calls. * Obfuscate Code. * Code Sign filechck DLL and check signature in application. * Check License Status at various places in your application not just at the app start (e.g. have a background thread running which checked this every few minutes.) * Don't use literal strings * Flood the cracker with bogus calls and hard-coded strings. Decoys are fun. * Never use meaningful procedure names such as function RegistrationOK: Boolean; * Add long delays. Don't warn the user right after a violation is made. Wait later, maybe until the next day or two (crackers hate that). * Have fun with Spaghetti-Code, it simply eats his time and nerves. * Update often.
You would need a persistent storage method for the Nalpeiron license file as moving it away and copying it back into place will cause a problem. If you are using the devicemapper driver for persistent storage then the Nalpeiron libraries will continue to function in the same manner as they would on a normal virtual machine.
However, if you are using Overlay2 you will encounter problems as its implementation affects the inner workings of the library in several ways. The Overlay2 filesystem uses a unionfs type setup. It will take multiple underlying filesystems and present them as a single, merged filesystem to your container. This merging process affects the security features of the Nalpeiron library. Specifically,
1.) Every Overlay image will have a different computerID even if detectVM is disabled. 2.) The license file will be tagged as corrupt on image restart.
The consequences of these effects depend largely on the details of your licensing implementation. For most implementations, having a distinct computerID for every running container is expected behavior. The only exception would be those who have disabled virtual machine detection and are using multiple activations to license multiple Docker containers. This method of licensing will no longer work with the Overlay2 storage driver.
License file corruption will also have little effect. You will only notice this corruption if you have created an image of a licensed product.
Overlay2 workarounds:
Use online concurrent license, checkout a license from Nalpeiron or the LAN daemon at startup and return license at image shutdown. This is the most commonly used licensing method for containers and it will continue to work with Overlay2 without change.
If you wish to have a locally stored license with an Overlay2 system, you will have to create a volume for persistent storage and use it as the workdir for the license. One method of creating such persistent storage is shown below:
You can create and attach a volume with docker run -it –name lictest -v workdir:/mnt centos
Then run that image again (with attached storage) using docker run -it -v workdir:/mnt centos
NOTE - This approach requires a separate dir on the persistent storage for each running image in /mnt as every image will have a different ComputerID
HyperV is a type 1 hypervisor. It runs on bare metal.
Once you "install" HyperV on your windows OS, that OS is virtualized. You no longer have a "physical" version of windows running on your machine. The HyperV is a very basic OS itself (similar to ESX in VMware) and the thing that used to be your physical OS is now just another virtual machine running in HyperV. Here's a good link that explains more about HyperV and its relationship to the OS it is installed into: https://superuser.com/questions/836116/hyper-v-appears-to-runs-on-top-of-the-host-os-so-why-is-it-considered-a-native.
Here's an excerpt from that link
>One more thing, Hyper-V isn't actually installed on the host OS. When >you install Hyper-V you think it's being installed on top of a host OS but >it is not. The setup converts the original OS in something like a VM and > puts the hypervisor below. This is what is called the root or parent >partition of Hyper-V. That's why you experience the same speed in what you >see as the "real machine" and the virtual machines.
That first virtual machine that HyperV creates (the one that used to be your physical desktop and is called the root or parent partition in the above excerpt) is identified differently by HyperV than all the other virtual machines. In the normal course of things, this distinction doesn't matter but, if you are attempting to identify virtual machines for licensing purposes, it does.
Once you've installed HyperV EVERYTHING you see on that computer is a virtual machine. Most of our customers want the parent partition treated differently (ie more like the host OS in a VMWare WorkStation installation) than a normal virtual machine. To make that possible, when using vm detection in the parent partition, you can enable the " Treat Hyper-V hosts as physical machines" when configuring your library at the Nalpeiron website. When that option is enabled, you should see isVM = 0 but vmType = "PhysicalHVHost". Without this option set, a Hyper-V host will show isVM = 1 and vmType = "HVHost". In either case, on ALL other virtual machines on that system you should see isVM=1 and vmType="HyperV".
While vmdetection is enabled you should see 1.) Your "parent partition" is returning isVM=1 and vmType="HVHost" 2.) Other vms on that system are returning isVM=1 and vmType="HyperV" 3.) Physical copies of Windows are returning isVM=0 and vmType="Physical"
HVCI results in a virtualized system
When HVCI (HyperVisor-protected Code Integrity) is enabled on a system, that system has been virtualized even if HyperV is disabled. The situation is very similar to the case of HyperV having been enabled (see HyperV). In the case of an enabled HVCI system without HyperV enabled:
While vmdetection is enabled you should see isVM=1 and vmType="HVHVCI"
Windows Hard Drive Serial Number
If you have enabled the hard drive serial number check in you library then the HDSN is incorporated into the computerID to aid in the differentiation of enterprise machines that had been cloned from a single image. There is a known bug in the Windows OS which causese the hard drive serial number (HDSN) to be returned differently depending on the privilege of the user calling for it. In these cases, the admin user's computerID will differ from that of a normal user. The change in computerID will not affect the licensing of the software. That is, the licensing client and Nalpeiron server will detect the change in computerID and the client will silently "heal" the license. The end users will not be aware that anything has happened.
However, if you wish to avoid this computerID change, you will have to disable the hard drive serial number check when downloading a library. On the "Integrate" page there is a check box labelled "Switch on HardDisk Serial number check" that is NOT enabled by default. So long as this checkbox is unchecked, your library will not attempt to use the hard drive serial number which should stop the computerID from changing.
Some links about the problem for the curious.
Microsoft HDSN and Microsoft HSDN2
Win7 and changing computerID with USB drive when HDSN enabled
The computer ID can change when a USB memory stick (or similar) is inserted into a Windows 7 (32-bit or 64-bit) computer which does not have Microsoft hotfix kb2664203 when hard drive serial number is enabled.
The dynamic linker ld-linux.so.x finds and loads the shared libraries needed to run a program. On compilation, the path and name of the dynamic linker are fixed. When compiling the Nalpeiron library we use the standard location and name, /lib and ld-linux.so.x respectively. On most systems these choices will work without issue. However, if you system has a different location for or name of the dynamic linker you will receive an error similar to
ld-linux.so.3: cannot open shafer object file
To rectify this create a symbolic link from the dynamic linker on your system to /lib/ld-linux.so.3. Below is the listing of the dynamic linkers in the /lib directory from a Raspberry PI ARMv7 system.
lrwxrwxrwx 1 root root 30 Jan 28 2015 ld-linux-armhf.so.3 -> arm-linux-gnueabihf/ld-2.13.so lrwxrwxrwx 1 root root 24 Feb 15 2015 ld-linux.so.3 -> /lib/ld-linux-armhf.so.3
Both of the named linkers, ld-linux.so.3 and ld-linux-armfh.so.3, are symbolic links. These links were created by the OS during installation. However, if the ld-linux.so.3 link were not present, you could create it with
ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3
Currently there is no official support for Apple M1 (aarch64). If you would like to use our library with M1 the simplest solution is to use the 64 bit portion of the library with 64 bit Java. The result will run on Appple M1 using Rosetta 2. When either Oracle or OpenJDK becomes available for the M1, we will reevaluate the situation.
NSA and very short lived applications
NalpLibClose shutdowns the library's threads and caches any data that has not yet been sent to the NSA servers. As NSA calls do not block, it is possible to lose some data during shutdown if precautions are not taken. The most likely scenario for data loss would be a very short lived application. That is, an application whose run time was on the order of a few seconds. The solution for these cases is to place a few second pause just after NalpLibClose is called.
When NSA is started in NalpLibOpen, it initilizes its threads. Soap transactions with the Nalpeiron server are handled by a pool of threads while the cache file and logging are each handled by a single thread each. Immediately after the creation of these threads a request for location information is sent to Nalpeiron. The location request is to ensure all data transmissions have current geographical data so that local privacy laws may be followed. Until the response to the location request reaches the library, all transactions are cached rather than sent to Nalpeiron.
The general progression of a transaction through the library is as follows. When a data transaction is initiated, the data is handed off to the first available thread in the transaction thread pool for transmission to Nalperion's server. If location data is missing or some error occurs (lack of connectivity, for instance), the data is moved to the cache thread where it will eventually be written to disk.
During NalpLibClose, all data remaining in the transaction pool is moved into the cache thread and written to disk as soon as possible. NSA calls do not block, so when called, they return immediately. The decision was made that all NSA library functions should return immediately while necessary processing takes place in threads in the background. This means that under certain circumstances, such as a short lived application, there is the possibilty of data loss. This may occur if the library itself is closed (with a dlclose or similar command) before threads finish.
For example, suppose your application uses the NSA library; a login, an app start, a feature start, a feature end, app end, a logout and then closes the library with NalpLibClose. Depending on connectivity speeds, when the call to NalpLibClose is made there may be a total of 6 transactions pending with an ongoing request for location data being processed. Once NalpLibClose is called, the transaction pool will move the six pending transactions to the cache thread then the transaction thread will be shutdown. The cache thread will write the six pending transactions out to cache where they will be available to send to Nalpeiron on the next run of you application. If the app completely closes before this process is complete, you may lose some of these pending transactions, especially if the time between NSA calls and closure is very short (couple seconds).
The simplest way to prevent data loss from occuring is to pause a bit (sleep, for example) after calling NalpLibClose, allowing threads time to finish. Alternatively, it might be possible to transfer all your data to nalpeiron quicker by increasing the minimum/maximum number of threads in the transaction pool using the <SoapThreadsMax>/<SoapThreadsMin> tags.
Although const char *nsaClientData has been added to most NSA calls on the client side, NULL should be used for this parameter until the corresponding server-side equivalents are implemented.
1.8.9.1
