Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>The eaysiest way to hide a key or a value is to create a key/value having '\0' inside of the name. You can do this wth respect of the native functions <code>NtCreateKey</code> (see <a href="http://msdn.microsoft.com/en-us/library/ff556468.aspx" rel="noreferrer">http://msdn.microsoft.com/en-us/library/ff556468.aspx</a>) <code>NtSetValueKey</code> (see <a href="http://msdn.microsoft.com/en-us/library/ff557688.aspx" rel="noreferrer">http://msdn.microsoft.com/en-us/library/ff557688.aspx</a>) which use <code>UNICODE_STRING</code> as parameters instead of <code>LPCTSTR</code>. You can read more about usage of native registry API in <a href="http://www.codeproject.com/kb/system/NtRegistry.aspx" rel="noreferrer">http://www.codeproject.com/kb/system/NtRegistry.aspx</a> for example. A Delphi code you will find here <a href="http://www.delphi3000.com/articles/article_3539.asp" rel="noreferrer">http://www.delphi3000.com/articles/article_3539.asp</a>.</p> <p><strong>UPDATED</strong>: Because many people read this question I want to add some words to my answer. I want divide the part of the question which we can read also in the title <strong>"best place to hide a key in the Windows Registry"</strong> from the subject with <strong>license keys</strong>. Because I read some answers (written before me) which concerned almost only the part of license keys and read practically no answer on the question from the title I wrote me answer.</p> <p>The subject with license key I find very complex. It depends on the licensing model choosed. It's important how to generate, to distribute (to install) and to verify the key. Is key should be hardware depended or not? It can be one per computer or one per computer group. The key generation, key installation or key verification can be either with respect of some online services (also from the internet) or without there. I can continue... There are a lot of aspects, advantages and disadvantages of different approaches.</p> <p>So I decide to answer <strong>only on the main question from the title</strong> which is clear and have a separate interest. All other questions about license key should be discussed in my opinion in the separate question after clearing all requirements.</p> <p><strong>UPDATED 2</strong> based on the updated question: It seems to me in your case would be better to use some scenario based on <em>cryptographic signing of an activation ticket</em>. For example the schema can looks like following:</p> <ul> <li>You software installed on the client computer will need an activation. Before activation it can not work or work in very restricted form (for example only some menus needed for software activation are enabled).</li> <li>You write a server component which will be used by client during the activation to generate the license key based of the activation request received from the client.</li> <li>If a client pay for the software you include the information about the client's "machine ID" (in any form which you want) in the database on the server.</li> <li>After starting of the activation process from the client software (either at the program start of from menu or in any other way like you want) it collects some information about the computer like computer name ("machine ID"), some serial numbers or some other information about hardware or operation system which can not be changed without a new activation. This information the software send to your server (it is the activation request).</li> <li>The server verify that the the client with the "machine ID" payed for the software and is not yet activated. Then the server calculate the hash (SHA1, MD5 or some other) from the information send from the client and sign the respond with the server's private key (or servers certificate). The signed ticket server will be send back to the client. This ticket will play the role of licence key.</li> <li>The server can add any additional information to the ticket before signing. For example it can add the information about the date till one the software should be valid (for example, current day plus one year). So the ticket which will be send back to the client can contain the hash of input activation information and any additional information, all what you want. Important is only that the information should <em>be signed</em>. In general you can include full client's request as clear text in the servers ticket instead of including of the hash, but the usage of the hash a) reduce the ticket size and b) makes the ticket a little more secure.</li> <li>Every client <em>have public key</em> corresponds to the private key used by server for signing of the activation ticket. The client save the ticket received from the server during activation in any place in registry of in the file system.</li> <li>Every next time if the client software will be started the software will read the saved activation ticket from the registry (or from the file system). Then the software collect the same information, which are used for generation of the activation ticket, calculate the hash and compare it with the hash from the saved ticket. It verify of cause the signature of the ticket with respect of the public key (or with respect of the server's certificate). Moreover the software can verify any other additional policy information from the ticket like the time till one the ticket is valid.</li> </ul> <p>All written is a roughly schema only, but it is very simple and it is extensible. You need only study how use some simple cryptographic operation and implement there in your software. </p> <p>As a option you can don't have a server online, but instead of that implement in the software (in menu for example) a possibility <em>to generate the activation request</em> and <em>send it per email</em> for example. Then you can offline (!!!) generate an activation ticket based of the server request and send the ticket back to the client also per email. A simple Reg-file which can be imported by double-click or some other simple import possibility in your software (cut &amp; paste in the activation dialog) can end the process of the software activation.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload