Substantially, this signature is obtained using the MAC (Medium Access Control) address (i.e., usually an Ethernet address) as a seed. This “machine code” can be viewed as a signature of the machine in which the tool “ softwarekey_customertool.exe” has been run and in which the “ protected_comp.exe” will be executed. Then he needs to send this “machine code” to us. In order to use our component, the customer needs to generate a “machine code” using the tool “ softwarekey_customertool.exe” we provide to him. Let's suppose we are the vendor of a certain component “ protected_comp.exe”. If he tries to install our executable on a different machine, the component won’t run.

In particular, it allows us to grant to the customer the right to use our component (EXE) only on a certain machine. The software key we propose in this article, with the mentioned limitations, allows us to get the above intention. Let’s assume we would like to control how many installations our customers do. Note that the following notes are suitable for other types of components as well (e.g., DLL, COM, etc.). Let’s suppose we have a software product encapsulated in an executable (EXE) with a policy fee based on installations. In order to explain the background idea, we need to describe the context in which our software key could be useful. However, we think that this article could be useful in allowing us to better understand the mechanisms underlain a software key.īy the way, in the following sections, we'll mention how to by-pass this protection and some ideas that could be useful to make attackers work harder. We are aware that it is quite simple by-passing the protection offered by the software key presented in this article. We want to highlight that this is just an example. In this article, we’ll show a way to implement a simple software key that could be useful for protecting software components (e.g., EXE, DLL, COM, etc.) against misuse and for keeping track of installations.

Dll tool license key