Run Dongle Protected Software Without Dongle
The software works under Windows XP to Windows 8th To activate an Internet connection is required. The trial version is fully functional. Serial number pdf to excel 3.3. The use of the trial version is time limited.
I have read all the existing discussions on piracy and hardware support, so this is not the same old question. I have a new twist on this old discussion. You can now purchase dongles for USB that allow you to put some of your important code into the dongle. If you have a complex algorithm and you put it into the dongle, someone would have to reverse engineer the contents of the dongle. If they tried to spoof the dongle, as was possible in the past, this would not work. All they can see is that data goes into a 'black box' and result data comes out. It is no longer a matter of finding a jump true/false to bypass a license check in the source code.
Dec 6, 2013 - Software protection is not any different, and by adding hardware via a dongle. JZ 00618496; RUN APPLICATION IF DONGLE IS ATTACHED. Yes and No: it won't stop thieves who will break a window to get into the house. Avoid Dongle Disasters. Without requiring an Internet connection. Dongle-protected software will only run on the machine that has the dongle.
Perhaps a mathematician with a lot of idle time on his hands could eventually reverse it, but that is an extreme level of interest! The other option is that the hardware dongle itself would need to be hacked. There are many protections against this built in, but this is probably the most effective approach.
So I want to take a scenario and see if I've missed something. I put the important part of my algorithm into the dongle to protect it. 6 doubles and 1 int go into the dongle, 1 double and 1 int are returned. This happens for thousands of data points. This is one of several functions of similar complexity. A hacker can see the rest of my assembly code (which I do as much as possible to obfuscate), but lets assume it is easily hacked. My question is, how hard is it to break into the dongle to access my assembly code in this proprietary hardware? Let's take as an example this companies product: http://www.senselock.com
I am not interested in lectures on how I'm inconveniencing customers and should open source my product, please. I am looking for a technical discussion on how a software/hardware engineer might approach extracting my assembly object from such a device. And I am not asking in order to hack one, but to know how much hassle I have as my discouragement against tampering. I know if there is a will, there is always a way. But at first glance it looks like it would take several thousand dollars worth of effort to bypass this scheme?
Given the response so far, I am adding some more specifics. The dongle has the following property, 'Access to the chip is protected by PIN, and the maximum re-tries is pre-set by software developers. For instance, under a dictionary attack, once the number of re-tries exceed the pre-set value, the chip will trigger a self-locking mechanism'. So to access the chip and thus the code inside it, you have to know the PIN, otherwise after let's say 10 tries you will be locked out. I personally can't see any way anyone could compromise this system. It doesn't matter what goes in or out, what matters is what runs inside the dongle ARM processor. Physical forced access would destroy the chip. Electrical access would require the PIN, or the chip locks up. How else could it be compromised?
1 Answer
I pretty much agree with your point of view that all dongles could be hacked, it just the matter of time and cost. If your encryption scheme is well-designed the EAL 5+ chip should be secure enough to prevent your software form malicious attacks.
And I think if you can READ the dongle it's probably means you already hacked the dongle, or it proofs there is a fatal vulnerability in the encryption scheme.
BTW, the link you give above is not work. Are you referring to this dongle? http://www.senselock.com/en/productinfor.php?nid=180&id=142&pid=
Not the answer you're looking for? Browse other questions tagged reverse-engineeringdonglesoftware-protection or ask your own question.
Various software companies distribute their software with hardware security, usually a dongle which must be mounted in order for the software to operate.
I don't have experience with them, but I wonder, do they really work?
What is it that the dongle actually does? I think that the only way to enforce security using this method, and prevent emulation of the hardware, the hardware has to perform some important function of the software, perhaps implement some algorithm, etc.
3 Answers
Clearly Peter has addressed the main points of proper implementation. Given that I have - without publishing the results - 'cracked' two different dongle systems in the past, I'd like to share my insights as well. user276 already hints, in part, at what the problem is.
Many software vendors think that they purchase some kind of security for their licensing model when licensing a dongle system. They couldn't be further from the truth. All they do is to get the tools that allow them to implement a relatively secure system (within the boundaries pointed out in Peters answer).
What is the problem with copy protection in general? If a software uses mathematically sound encryption for its licensing scheme this has no bearing on the security of the copy protection as such. Why? Well, you end up in a catch 22 situation. You don't trust the user (because the user could copy the software), so you encrypt stuff or use encryption somehow in your copy protection scheme. Alas, you need to have your private key in the product to use the encryption, which completely contradicts the notion of mistrusting the user. Dongles try to put the private key (and/or algorithm and/or other ingredients) into hardware such that the user has no access in the first place.
However, since many vendors are under the impression that they purchase security out of the box, they don't put effort into the correct implementation. Which brings me to the first example. It's a CAD program my mother was using. Out of the knowledge that dongles connecting to LPT tend to fail more often than their more recent USB counterparts, I set out to 'work around' this one. That was around 2005.
It didn't take me too long. In fact I used a simple DLL placement attack (the name under which the scenario later became known) to inject my code. And that code wasn't all too elaborate. Only one particular function returned the value the dongle would usually read out (serial number), and that was it. The rest of the functions I would pass through to the original DLL which the dongle vendor requires to be installed along with the driver.
The other dongle was a little before that. The problem here was that I was working for a subcontractor and we had limited access only to the software for which we were supposed to develop. It truly was a matter of bureaucracy between the company that licensed the software and the software vendor, but it caused major troubles for us. In this case it was a little more challenging to work around the dongle. First of all a driver had to be written to sniff the IRPs from and to the device. Then the algorithm used for encryption had to be found out. Luckily not all was done in hardware which provided the loop hole for us. In the end we had a little driver that would pose as the dongle. Its functionality was extended so far as to read out a real dongle, save the data (actually pass it to a user mode program saving it) and then load it back to pose as this dongle.
Conclusion: dongles, no matter which kind, if they implement core functionality of the program to which they belong will be hard to crack. For everything else it mostly depends on the determination and willingness to put in time of the person(s) that set out to work around the dongle.As such I would say that dongles pose a considerable hindrance - if implemented correctly - but in cases of negligence on part of the software vendor seeking to protect his creation also mere snake oil.
Take heed from the very last paragraph in Peters answer. But I would like to add one more thought. Software that is truly worth the effort of being protected, because it is unique in a sense, shouldn't be protected on the basis of customer harassment ( most copy protection schemes). Instead consider the example of IDA Pro, which can certainly be considered pretty unique software. They watermark the software to be able to track down the person that leaked a particular bundle. Of course, as we saw with the ESET leak, this doesn't help always, but it creates deterrence. It'll be less likely that a cracker group gets their hands on a copy, for example.
Problem description
Let's make a couple of assumptions. Software is divided into functional components. Licenses are for functional components within that software package. Licenses can be based on time, on version or on a number of uses, i.e you may use the functionality until a set point in time, you may the functionality of the version you purchased or some minor derivative of it or you may use it a number of times. There are two main scenarios you have to solve, where an attacker doesn't have access to a license and where he does.
Attacker with no license
The first scenario is where your attacker does not have access to a valid license to your product. This problem is easy to solve. Simply assign a separate encryption key to each of the functional licenseable parts of your software. Encrypt each functional part with the encryption key designed for that part. Now you can distribute your software without worry of someone being able to decrypt functions they have not licensed since you never send them the key.
Attacker with access to license
The second scenario, which is much harder to solve, is when your attacker has a valid license to your software but he either wants to redistribute the functions he has licensed or to extend his license time wise.
Now you need a reliable time source, this can be solved by:
- embedding a public key into a dongle and having the dongle issue a random challenge which must be forwarded to a time server. The time server responds by signing the current time and the challenge and returning it to the client which then sends it to the key and the key then updates its internal clock and unlocks.
- updating the internal clock based on the time it has been plugged into the computer. The USB port supplies power to your dongle all the time while its plugged in.
- updating the internal clock based on timestamps sent from drivers installed on the machine its attached to. Only allow timestamps forward in time. Only allow movement backwards in time if the time source is a remote trusted time server supplying a signed timestamp.
If your license is based on versions you actually have an attacked who does not have access to a license because your key derivation function for the functional unit takes both the identifier of the functional unit and the version of it as input.
Key distribution
So once you have separate keys for each functional unit your licenses basically becomes a matter of distributing symmetric keys so that they can be sent to the dongle. This is usually done by embedding a secret symmetric key in the dongle, encrypting the license decryption keys with the shared secret key and then signing the encrypted key update files. The signed update files are then passed to the dongle which validates the signature on the update, decrypts the new keys with the shared symmetric key and stores them for later use.
Key storage
All dongles must have access to secure storage in order to store license decryption keys, expiration timestamps and so on. In general this is not implemented on external flash memory or EEPROM. If it is it must be encrypted with a key internal to the ASIC or FPGA and signed such that it can not be changed.
Plain text hole
Hayley kiyoko this side of paradise zip. Once the user has a license to your functional component, even if he can't extract your secret key, he can use your dongle to decrypt that functional component. This leads to the issue that he may extract all your plain text and replace the decryption call with a direct call to the extracted plain text. Some dongles cover this issue by embedding a processor into the dongle. The functional component is then sent encrypted over to the dongle which decrypts the component and executes it internally. This means that the dongle essentially becomes a black box and the functional components sent to the dongle needs to be probed individually to discover their properties.
Oracles
A lot of dongles are encryption and decryption oracles which leads to potential issues with Chosen-ciphertext attacks, e.g the recent padding oracle attacks.
Side channel attacks
Logitech Dongle Software
Besides the oracle issues you also have a lot of concerns with all of the so far well known side channel attacks. You also need to be concerned with any potential but undiscovered side channel.
Decapsulation
Dv Dongle Software
Be aware that there are a number of companies in the world who specialize in picking apart and auditing secure chips. Some of the most well known companies are probably Chris Tarnovsky of flylogic, now part of IOActive and chipworks. This sort of attack is expensive but may be a real threat depending on the value of your target. It would surprise me if but a few, possibly none of, dongles today are able to withstand this sort of high budget attacker.
Do they work
Given a dongle which is based on strong encryption, isn't time based since you can not expire encryption keys based on time nor is time an absolute, free of any side channel attacks and executes the code on the chip, yes it will make discovering the underlying code equivalent to probing a black box. Most of the breaks that happen with these dongles are based on implementation weaknesses by the licensees of the hardware licensing system due to the implementer being unfamiliar with reverse engineering and computer security in general.
Also, do realize that even software where a majority of the logic is implemented on an internet facing server has been broken simply by probing the black box and inferring server side code based on client code expectations. Always prepare for your application to be broken and develop a plan for how to deal with it when it happens.
As Peter has indicated, looking at how the dongle is used for security is the starting point to identify the attack vectors. In most cases, the software developers implementing the dongle security is the weakest point.
In the past when I have tested software with dongles, I have used free tools like ProcessMonitor and RegShot to identify simple vulnerabilities to defeat bad implementations of dongle security.
Free Bluetooth Dongle Software
I have seen software that on startup checks for the presence of dongle and then proceeds with its operation without using the dongle until its restarted. In these cases, patching the application with OllyDbg is not that difficult to tell the app to run with full functionality as long as the dongle is NOT plugged in to the system.
I have also seen software that allows a user to click on a button in the software so that the user doesn't have to have the dongle inserted. The software claimed that is an extra functionality like 'Remember Me' option. RegShot and ProcessMonitor showed me that a file is written with some information and as long as the file is present in the expected folder, I can run the software on multiple systems without a dongle.
Just because someone uses AES or Hardware Dongles or any XYZ doesn't mean they are secure. All that maters is whether they are implementing those security measure in the right manner assuming that there are now known (or 0-day vulnerabilities) in the security measure.
protected by Community♦Nov 9 '15 at 12:26
Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?