I am likely new compared to most of the vets on this forum. But I just want to mention that I have devised a little custom system which does the following:
provides obfuscation for security sensitive strings/data (password, api keys, etc.,)
256-bit encrypt persistent data
IPC helper app to check for MD5 (avoiding hacks to main executable)
creates unique identifier for computer hardware
software checks license key system on server to check for:
license activation status
system authorization based on unique identifier
License keys issued upon purchase, (Accept any currency, including crypto-currencies, bitcoin, etc.,)
This system involves, 1 xojo plugin, and 2 or 3 wordpress plugins
My question is; is anyone looking for help in this area ? Secondly as a freelancer, I’m looking for work, does anyone think this is valuable information to package and sell either as project files or as a consultation service ?
Nothing new I am afraid. Xojo can do this out of the box.
When code signing your app this takes care of this. Although I would advice to check the code signing in run-time on random times.
MBS plugins can do this (on various hardware components).
I use Joris Vervuurt code for this. It checks license keys online. Works very nice. If I am not mistaken he will release this code in the near future (together with his awesome Sparkplug update class).
I don’t claim to have anything unique. I claim to have the code to all of these things. Code signing, I’m not sure matters when someone hex hacks your executable. The MBS plugins are not reliable for getting unique hardware identifiers, as declared in the documentation for the plugins. Once again nothing new here; except everything needed to provide basic security against hacking, issue license keys for your desktop apps, and have a store sell the apps which auto-issues keys.
When I was new, I wouldn’t have been able to find any of this, so I’d like to offer it to other people.
That’s probably why he was asking the questions (his last paragraph) in the first place, to learn what the market was interested in.
My thoughts…while I’d definitely take a look at the source just to see how it works, I’d be more comfortable developing my own system (and that’s what I’ve done). My system may or may not be as robust (it probably isn’t) but I know exactly what it does and how it does it.
Sure it matters. Any modification breaks the code signing. And prevents the execution if the app is sandboxed.
[quote=138679:@chris ridgeway]Once again nothing new here; except everything needed to provide basic security against hacking, issue license keys for your desktop apps, and have a store sell the apps which auto-issues keys.
[/quote]
Anything can sell if you do your homework with a thorough market survey first to avoid mistakes. That includes looking at what the competition already provide. Seems there is plenty already :
I can only talk from the experience I’ve had with crackers, but the biggest ‘loopholes’ is code written on a if statement. i.e.
if checkRegistration( serialNumber) and checkActivation( serialNumber, UUID) then
// --- Registered
~
else
// --- Not registered
~
End if
This is the easiest thing for a cracker to change.
if not checkRegistration( serialNumber) and not checkActivation( serialNumber, UUID) then
// --- Registered
~
else
// --- Not registered
~
End if
This is all done in machine code (Xojo code is just for explanation).
I’ve never been able to figure out a satisfactory way of removing a boolean switch. The only advice I can give is to NOT use a single validation routine and to put verification code in various places.
Also as @Christophe points out, checking the code signature is the same as the MD5 solution, and as @Michel points out any modification to the application package will invalidate the code signature and by default people who download the cracked version won’t be able to just double click your application.
The other thing to bear in mind is that with modern piracy, the chances of a pirate downloading a genuine cracked copy of your application is as low as 10%. Our most successful product “HDRtist Pro” for example, at the height of it’s sales I checked various ‘torrent’ sites for a cracked copy, out of 10 copies I downloaded, only 1 was actually a cracked copy of HDRtist Pro. The others were either MacKeeper, a Windows app or some weblink file. I checked out the cracked copy and it was 20mb in file size larger than the app on my site, also the code signature didn’t validate. The actual binary was 20mb bigger, which leads me to believe that the ‘cracker’ had loaded it up with something nasty, and quite frankly if people download the cracked copy of my app, they deserve whatever the cracker has planned for their machine.
Use that UUID as a decipher key to generate a hex-encoded cipherText that I send over (as the license key) that contains the property values and important class names that need to get called within the application.
I then decipher that within the application using the UUID and let introspection ‘fill-in’ the property values and for calls to the internal classes.
If they don’t have the correct license key (from either using an incorrect UUID or incorrect cipherText based on their UUID) then it’s like trying to decipher something with the wrong key… and all they get is junk. The application checks for this junk, and terminates/goes into evaluation mode. If they somehow bypass this ‘check’ (like most hackers today do), they’re still at a road-block… because unless they’re able to pre-populate the property content and somehow hard-code the calls to the classes with matching names, they’re not going to be able to pirate the application.
A variant I had to this was to not hardcore the .top, .left, and contents of labels, etc. and let those all be contained within this cipherText. All the positions and contents of the objects on the UI were encoded in this cipherText (for the FULL version of the application). If they bypassed the simple verification, all they got was a UI with random crap all over the Window.
