- Forum
- Windows Programming
- Anti-cracking protection for my C++ app
Anti-cracking protection for my C++ app
Hello, I've been trying to protect my 32-bit music plugin (DLL) using a protection solution called Pelock https://www.pelock.com/
It provides an extended licensing SDK for C/C++ available at GitHub:
https://github.com/PELock/PELock-Software-Protection-and-Licensing-SDK/
and I'm trying to implement my own hardware identifier routine so the license key is bound to this hardware identifier and doesn't work on any other machine.
The example is here:
https://github.com/PELock/PELock-Software-Protection-and-Licensing-SDK/tree/master/Examples/English/1.%20License%20system/SetHardwareIdCallback%20-%20custom%20hardware%20id%20callback/C/console
and I would like you to ask for help in this matter. The problem is I want to generate this hardware identifier from as many as possible hardware components, so the license key cannot be used on any other machine. Default implementation uses hard drive serial number and CPU identifier only, what would you recommend to use to build this identifier from?
I've been thinking about using USB serial number and network card MAC? How to read it from C++? Can I read it using C++ only or should I use some external libraries to read those serial numbers?
Any other ideas would be great! Thank you for your time
It provides an extended licensing SDK for C/C++ available at GitHub:
https://github.com/PELock/PELock-Software-Protection-and-Licensing-SDK/
and I'm trying to implement my own hardware identifier routine so the license key is bound to this hardware identifier and doesn't work on any other machine.
The example is here:
https://github.com/PELock/PELock-Software-Protection-and-Licensing-SDK/tree/master/Examples/English/1.%20License%20system/SetHardwareIdCallback%20-%20custom%20hardware%20id%20callback/C/console
and I would like you to ask for help in this matter. The problem is I want to generate this hardware identifier from as many as possible hardware components, so the license key cannot be used on any other machine. Default implementation uses hard drive serial number and CPU identifier only, what would you recommend to use to build this identifier from?
I've been thinking about using USB serial number and network card MAC? How to read it from C++? Can I read it using C++ only or should I use some external libraries to read those serial numbers?
Any other ideas would be great! Thank you for your time
What you risk doing is alienating the users you have.
> The problem is I want to generate this hardware identifier from as many as possible hardware components
In the extreme, "Hey, I moved the mouse and now the software is unlicensed!? - wtf"
The more you tie your s/w to a given bit of hardware, the more support questions you're going to get from people changing their systems.
Be careful of how much time/effort/money you spend on "protection" vs "product improvement".
Every well known (and less well known) "protection" scheme has it's own following of miscreants ready to break it.
https://duckduckgo.com/?q=pelock+keygen
If someone wants your work badly enough, the answer is only a few clicks away.
Remember, it only takes 1 person to break the lock and then through the magic of the internet, everyone else knows as well.
> The problem is I want to generate this hardware identifier from as many as possible hardware components
In the extreme, "Hey, I moved the mouse and now the software is unlicensed!? - wtf"
The more you tie your s/w to a given bit of hardware, the more support questions you're going to get from people changing their systems.
Be careful of how much time/effort/money you spend on "protection" vs "product improvement".
Every well known (and less well known) "protection" scheme has it's own following of miscreants ready to break it.
https://duckduckgo.com/?q=pelock+keygen
If someone wants your work badly enough, the answer is only a few clicks away.
Remember, it only takes 1 person to break the lock and then through the magic of the internet, everyone else knows as well.
OK, cool. Let's say you've completely scanned the system and identified the exact environment that the program was initially installed on and that happens to be Docker or some clone there of. Or heck, a full VM.
The problem here is your approach. No one uses hardware ID's anymore. First of all they can be trivially spoofed and secondly it annoys customers that they can't upgrade anything on their PC without having to call your tech support line. Tying your installation instance to the PC's root certificate is probably the cleanest way I can think of. That stuff is found here: https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/
The problem here is your approach. No one uses hardware ID's anymore. First of all they can be trivially spoofed and secondly it annoys customers that they can't upgrade anything on their PC without having to call your tech support line. Tying your installation instance to the PC's root certificate is probably the cleanest way I can think of. That stuff is found here: https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/
A few pricey programs still use the usb key (you insert some stupid usb thing in or it won't run) which requires a driver for the usb device and stops working if the usb device wears out (usb is designed with disposable over durable, the connectors are poor quality) and tend to not work across OS nor OS upgrades. But its an option if your program costs as much as a new car per copy or something if you want to support it.
The 3 types I encounter most are the root mentioned above, some sort of networking (eg steam ID vs game being played, do you own it?), and the hardware usb lock. Not sure what else is used a ton? Agreed with above, locking to the pc's hardware serial numbers is a horrible user experience.
The 3 types I encounter most are the root mentioned above, some sort of networking (eg steam ID vs game being played, do you own it?), and the hardware usb lock. Not sure what else is used a ton? Agreed with above, locking to the pc's hardware serial numbers is a horrible user experience.
For games networked DRM seems to be the most common thing. EA and Steam use a network login app to ensure a user owns the game(s).
Games used to require a serial number, enclosed in the package, but now with game purchases are done virtually through the DRM app.
A lot of non-game software has a company generated keyfile that is hashed so the actual key is encrypted.
No matter what scheme protection that is used, if the software is popular it will be hacked. NOTHING will stop that.
Games used to require a serial number, enclosed in the package, but now with game purchases are done virtually through the DRM app.
A lot of non-game software has a company generated keyfile that is hashed so the actual key is encrypted.
No matter what scheme protection that is used, if the software is popular it will be hacked. NOTHING will stop that.
No matter what scheme protection that is used, if the software is popular it will be hacked. NOTHING will stop that.
Yes, and often, the stupidest thing will work, like back-dating the computer still works on many trials, and unplugging the internet still confuses a lot of programs as well. A electronics engineer at one of my jobs got 2 more months out of the toner cartridges with a wire to bypass the 'tell them I am empty and to buy more' chip. Multiple times the latest / greatest protection has fallen to dumb (meaning disgustingly simple/ lack of effort) hacks, my favorite still being the sharpie hack for DVD/CD copying.
Yes, and often, the stupidest thing will work, like back-dating the computer still works on many trials, and unplugging the internet still confuses a lot of programs as well. A electronics engineer at one of my jobs got 2 more months out of the toner cartridges with a wire to bypass the 'tell them I am empty and to buy more' chip. Multiple times the latest / greatest protection has fallen to dumb (meaning disgustingly simple/ lack of effort) hacks, my favorite still being the sharpie hack for DVD/CD copying.
Last edited on
I'm not trying to alienate anyone, just bind the license to most hardware components. Simple as that.
I thought you would give me any C++ code tips, not your biased opinions that have nothing to do with my question.
Right now I'm using WMI to gather more system info from the hardware components. Works great.
I thought you would give me any C++ code tips, not your biased opinions that have nothing to do with my question.
Right now I'm using WMI to gather more system info from the hardware components. Works great.
Oh, so you want FREE coding support from us here that you will use to make money.
You got that. You not liking what you received gratis isn't OUR problem.
You got that. You not liking what you received gratis isn't OUR problem.
usb cards go bad at alarming rates, largely due to power overdraw or other voltage related goofs on the user's part, but they are also not exactly well made. I would skip that.
Network MAC is a reasonable pick, but here again, network cards DO fail, so you have to deal with that when it happens, and that is not to mention other odd things that can go on in that realm.
Maybe this will help, some more opinions.
https://stackoverflow.com/questions/3443093/what-is-a-good-unique-pc-identifier
You can also get a little funky and use some of the bios or cmos info. Its not unique, but it varies a lot from machine to machine, and could be 'part of a fingerprint' of a box.
There isnt a lot of C++ here, its all going to be OS or hardware level interface, not generic language stuff here.
Network MAC is a reasonable pick, but here again, network cards DO fail, so you have to deal with that when it happens, and that is not to mention other odd things that can go on in that realm.
Maybe this will help, some more opinions.
https://stackoverflow.com/questions/3443093/what-is-a-good-unique-pc-identifier
You can also get a little funky and use some of the bios or cmos info. Its not unique, but it varies a lot from machine to machine, and could be 'part of a fingerprint' of a box.
There isnt a lot of C++ here, its all going to be OS or hardware level interface, not generic language stuff here.
Last edited on
Topic archived. No new replies allowed.