I want to distribute my software on flash (thumb) drives. The software protection will check that the product runs from a flash drive with predefined Serial Number thus protecting me from the software unauthorized duplication.
My question is if it possible to somehow create another flash drive with the same Serial Number? E.g. if a flash drive exist which allows for SN modification? Or are some other ways exist to cheat such protection?
First of all, make sure you actually read the hardware SN rather than the partition ID. The USB spec does not require a hardware SN, but there usually is one.
E.g. if a flash drive exist which allows for SN modification?
It's certainly possible to build such a device.
Or are some other ways exist to cheat
such protection?
The USB driver could be modified to spoof the serial, or (probably easier) the checking code could be removed from the program. Such software modifications are a much bigger threat than hypothetical "SN faking hardware", because unlike hardware they can be distributed over the internet instantly and for free.
Related
Scenario: A critical computer system is operator-controlled via standard USB keyboard and mouse. Also, there is a DVI-monitor connected to view the operator-targeted GUI. The computer system runs a soft-PLC system based on Windows 7 Professional or, alternatively, Windows Embedded Standard 7 (the "system software").
Question: Is there a software solution, to detect the loss (disconnect/failure) of USB HID-devices such as the keyboard or mouse, and the single DVI-display? This is important, since the critical system can no longer be expected to function properly, without the operator able to manipulate it or see displayed content.
Own considerations: This likely requires low-level WINAPI calls, which is fine. I am thinking that a windows service might be constantly seeking to enumerate the number of keyboards and displays - perhaps even identify them via model or serial number. If this enumeration and/or identification reaches zero or fails entirely, the system-software must of course react fast and appropriately (i.e. go to fail-mode or similar).
As far as I see it, this is general issue with all critical operator-controlled systems. Question is then: Is there already software or hardware for this in existence perhaps?
Note: Operator is always human.
Alas, as for an answer this isn’t going to be much more than a “read the docs” plus some links... Sorry.
First, MSDN documentation.
RegisterDeviceNotification
Detecting Media Insertion or Removal
Talking to USB devices, start to finish (Windows Store app)
I found a C# class on CodeProject.com that does this; the accompanying article is pretty good.
Detecting USB Drive Removal in a C# Program.
I admit that the last time I did anything like this was some years ago, and only for CD notifications. I’ve since lost the code (both my primary and backup hard drives failed within days of each other, LOL).
I’m trying to write a little tool to simplify inventorying my removable media. Getting and storing a list of files on the media is simple enough, but I want to be able to catalog them according to what type of drive they are.
There is an API function to get the drive type, but it is old and limited to floppy, CD, fixed, removable, network, and RAM. it does not give fine-grained information to determine whether a drive is a flash-drive or a memory-card (let alone even more detailed like what kind of memory-card). Even a newer function meant for USB drives doesn’t seem to specifically differentiate between types of USB media.
Is there a reasonably easy and reliable way (preferably C++) to determine that? (Yes, I know that some media can be modified to present as different types, but it only needs to work well enough for normal, standard media.) There is definitely some way to do this because Windows contains different icons for all kinds of media in shell32.dll, and Explorer usually uses the correct one when you plug them in.
I have an application I want to protect by requiring my users to register.
I also want to ensure that they can't install on more than two machines.
To do this I need to know where to find a unique hardware ID number, and utilize that in the registration code.
All I need to know is how to get that number using code.
As others have pointed out, there is really no such thing as a unique hardware ID. Others who have come before you have tried to use various things (e.g. motherboard serial number, CPU serial number, HDD serial number, MAC address) or combinations of those things, but they are all problematic in their own way. Serial numbers are not always returned by all drivers and even if they do, they can easily change if the hardware is upgraded or replaced. Also, the serial numbers can technically be repeated by different vendors and especially on virtual machines. MAC addresses are problematic because there are often multiple and they change often, especially with VPN's. Also, MAC addresses are often duplicated by multiple machines using the same VPN software. You could use the Windows Installation serial number, but this can also be duplicated and changes with OS upgrades. The simple answer is, when possible, don't. If you must do something like this, it would be better to have a way to programmatically mark each computer that your software is installed on by writing an encrypted GUID to someplace on the harddrive and provide an easy mechanism for your support staff to retag any computer at will.
I have written a software which I would like to bind to mac. Is there any specific algorithm to bind mac address with my software? Thank you for help !
Edit:
I want to provide serial number according to user's mac address.
The comment above is right - the MAC address is widely used for node-locking, but it is a poor choice as it is easily changed in OS.
A more secure approach is to use a combination of hardware and software system parameters, such as hard disk ID, system name, user OS login name, CPU ID etc.. The selection available will depend on the specific OS and programming language you use.
However, to avoid problems down the road, I'd suggest you think about the following:
How do you obtain the system parameters? If you ask the user to provide them there is opportunity for human error, such as entering a '1' for an 'l' or a '0' for an 'O'. Then the license won't work and the user will be inconvenienced.
What if the parameter you lock to changes, say if the user upgrades their system by changing a piece of hardware? Will it break your system and need the user to request a new license from you?
What if the user wants to move their license to another system, or to a new machine? Can your licensing system allow this without making it easy for the user to run one license on both the old and new systems?
These are the kinds of issues that cause home-built licensing systems to annoy legitimate users, and not be very secure against would-be hackers.
Commercial licensing systems should of course have dealt with these and other issues already.
Write MAC Adress into a kind of license file.
On startup read the MAC-Adress and compare it with configured.
If not equal --> stop with error.
To create a unique serial number out of a mac address you have to apply an algorithm to macaddress. There are some comercial tools for that for you professionally.
Some thoughts to licensing can be found here and here
I take it you're looking to achieve some sort of node-locking of your app to a specific device. If so, you might be disappointed to learn that the MAC address is not always a persistent value on a device. In fact, some devices have multiple MAC addresses, so it's not a particularly reliable value to use when looking to find a persistent hardware ID to bind to.
Our solution for Node-Locking Licenses to a device at LicenseSpring (we specialize in this sort of stuff) is that we generate a device fingerprint by hashing the serial numbers of some of the hardware we read on the device (such as the CPUID + BaseboardID + SystemDiskID). When the end user retrieves the license key, they use that hash along with the license key to perform a license check, which is computed on the fly. The license key is set to only be usable on a finite number of devices, so if another device tries to use the license key, they will compute a different hardwareID and be blocked.
So long as you're hashing those serial numbers in the same way, you won't run into any trouble...
You CAN store information in the key itself, such as product info / device info etc.
but I would also advise against that. Mainly because there's only so much info that can fit into a key, and then it makes it quite easy to reverse engineer.
Instead, I'd suggest you use the server response from the online license check to send back license entitlements as well as signing the server response, and use that to control the state of your application.
I'm concerned about the dangers of using memory-mapped IO, via CreateFileMapping, on FAT filesystems. The specific scenario is users opening documents directly from USB sticks (yeah, you try and ban them doing this!).
The MSDN Managing Memory-Mapped Files article doesn't say anything about file system constraints.
Update
I didn't have any real reason to be concerned but a vague feeling that I'd read about problems with them at some point (my career spans over 25 years so I have a lot of vague depths in my memory, all the way back to 8-bit micros!). The issue of whether or not they should be supported is pretty important for me to recommend so I wanted to ask if anyone could corroborate my concerns. Thanks for putting my mind at rest.
Memory-mapped files is one of my favorite features. It's absolutely no danger. It's one of the base extremely optimized Windows I/O features. If one starts an EXE or load indirect a DLL it is implemented internally as memory-mapped file mapping.
It is supported on all types of file systems including FAT.
By the way atzz say that memory-mapped files are allowed on network drives. I can add it is not only allowed, but it is strictly recommended to use memory-mapped file also with files from network. In the case the I/O operation will be cached in very good way, which is not done with other (C/C++) I/O.
If you want that the EXE will not crash if you open it from the CD or network one can mark Program Executable with one bit in the header (linker switch /SWAPRUN see http://msdn.microsoft.com/en-us/library/chzz5ts6.aspx). There are no option for documents opened from USB stick.
But what exact problem do the users have? Do they don't use "Safely Remove Hardware" Icon? Then they have to learn to do this exactly like they have to learn to not switch computer power, but shutdown the computer properly.
Could you explain why you find dangers to use memory-mapped files, and in what situations you have problems and is usage of other I/O operation has no such problem?
Yes it does. It even supports mapping of files on CDFS or on network drives. What is the source of your doubts?