Hi AnubhavKhetan, thanks for your reply. You are correct: I'm trying to write down a simplified version of EMS' java applet to burn key.
When you want to burn a key a page is presented with a list of keys supporting the chosen licensing schema. I think that basing on feature complexity and number, some keys would be excluded (i.e. I know that Pro key cannot hold more that 39 features, but this number could be reduced to 11 if feature are somewhat complex).
I need to do the same to help my colleagues that will produce keys to be sure the key they chose is suitable for the license they're going to write. My concerns is about our old HL keys (as you can see they are v 3.25 with hw version 6.1, produced on 27 Oct 2011, five years ago...): I have to be sure, when writing on key, that that will hold all the information we need, features and R/O memory, and eventually the R/W memory.
So basically with my own key I read
and I see that I have an hasphl key, Pro model.
Then in supported keys I have to read all keys with <key_type configuration="hasphl"> and check if my <key_type> value is contained (but not equal) to one of them. If so, I can use this key, otherwise I cannot use it.
If I plug a new Pro key instead, I would read
and then I would have to look for all keys with <key_type configuration="sentinelhl"> and again check if my <key_type> is still contained in one of them. Same apply if I use a new Max key.
In other words, I cannot simply locate the Pro, Max or any <key_type> string I read into the supported keys list, without taking into account the <configuration> type; otherwise I could think an old HASP Pro key could be used while only a Sentinel DL Pro key is allowed.
Am I correct?
Thanks in advance and regards,
Stefano
When you want to burn a key a page is presented with a list of keys supporting the chosen licensing schema. I think that basing on feature complexity and number, some keys would be excluded (i.e. I know that Pro key cannot hold more that 39 features, but this number could be reduced to 11 if feature are somewhat complex).
I need to do the same to help my colleagues that will produce keys to be sure the key they chose is suitable for the license they're going to write. My concerns is about our old HL keys (as you can see they are v 3.25 with hw version 6.1, produced on 27 Oct 2011, five years ago...): I have to be sure, when writing on key, that that will hold all the information we need, features and R/O memory, and eventually the R/W memory.
So basically with my own key I read
- ...
- <configuration>
- <hasphl />
- </configuration>
- ....
- <key_type>Pro</key_type>
- ...
and I see that I have an hasphl key, Pro model.
Then in supported keys I have to read all keys with <key_type configuration="hasphl"> and check if my <key_type> value is contained (but not equal) to one of them. If so, I can use this key, otherwise I cannot use it.
If I plug a new Pro key instead, I would read
- ...
- <configuration>
- <sentinelhl />
- <driverless />
- </configuration>
- ...
- <key_type>Pro</key_type>
- ...
and then I would have to look for all keys with <key_type configuration="sentinelhl"> and again check if my <key_type> is still contained in one of them. Same apply if I use a new Max key.
In other words, I cannot simply locate the Pro, Max or any <key_type> string I read into the supported keys list, without taking into account the <configuration> type; otherwise I could think an old HASP Pro key could be used while only a Sentinel DL Pro key is allowed.
Am I correct?
Thanks in advance and regards,
Stefano