Hi Ashish,
To resurrect this old thread: we're recently started to implement a more complex licensing mechanism utilizing key memory. We plan to not just use the envelope for the feature-based licensing (which we have been using for many years now) but also we'll use sub-feature/parameters utilizing key memory. For that we are using the C APIs hasp_login, hasp_read and hasp_logout in our protected application. To successfully log into the key, we need to pass the vendor code to hasp_login (so, the vendor code must be present in our resulting app binary). But after logging in, we are also able to call hasp_write, modifying the key memory. This contradicts your statement that passing around binaries with the vendor code, especially in non-enveloped form, is not a protection risk, as a potential attacker would use the vendor code for hasp_login and hasp_write, overwriting the key memory.
Is there any way that would allow us to prevent modification of the key memory? Perhaps leaving the authentication to envelope, and calling hasp_login+hasp_read to only read the key memory without the vendor code?
Thanks for your comments.