CODEWITHSUNDEEP
javadesktop
Jahongir Sabirov
Jahongir Sabirov

Reputation: 470

Secure application from being copied from one PC to another

I've created a JavaFX application. Now I would like to secure it from being copied to other computers. More detailed I sell the application to one customer and after installation of this application, I need to secure it from being copied from one computer to another.

How I can prevent someone from copying the application?

Upvotes: 1

Views: 910

Answers (2)

CBHacking
CBHacking

Reputation: 2122

The term you're looking for is DRM ("Digital Rights management") and it is, for the most part, a lost cause. It is impossible to implement unbreakable DRM, because anything one computer can do another computer can also do, so there's no way to prevent somebody from faking "oh it's still the same computer". Things like checking hardware similarity and serial numbers and so forth can be attempted, but those can all be spoofed (at least in theory) and in practice will also break legitimate use cases such as replacing a failing hard disk.

It's also impossible to prevent somebody from simply modifying your program to remove or cripple the DRM. Even techniques like encrypting the whole non-DRM-implementation part of the binary and only obtaining the decryption key if the DRM check passes is insufficient, because that decryption key can be captured out of the process' memory and used to decrypt the encrypted parts, and then the DRM part can just be thrown away. Obfuscation can make it harder to do this, but if a computer can execute the program, then a human can (with enough time and/or helpful software) reverse engineer the program.

All that obfuscation and DRM do is make it take longer for somebody to reverse engineer / pirate the program successfully. You might theoretically raise the difficulty enough that, given currently-available tools, there isn't anybody on Earth who can reverse-engineer the software enough to remove the DRM in less time than it would take to just clone the program's behavior, but you can't make it impossible and you can't prevent people from writing better reverse engineering tools.

EDIT: DRM is so pointless that some people break it just for fun, and pirate the broken-DRM version instead of a DRM-free release of the same software. A fun story about the hopelessness of DRM, from the Wikipedia article linked above (emphasis added):

[CEO of CD Projekt Red, Marcin] Iwinski stated of DRM, "it's just over-complicating things. We release the game. It's cracked in two hours, it was no time for Witcher 2. What really surprised me is that the pirates didn't use the GOG [DRM-free] version, which was not protected. They took the SecuROM [commercial DRM] retail version, cracked it and said 'we cracked it' – meanwhile there's a non-secure version with a simultaneous release. You'd think the GOG version would be the one floating around."

Upvotes: 0

Serge Ballesta
Serge Ballesta

Reputation: 148975

The rule is: you cannot prevent a user having admin priviledges on his machine to copy the bits of any file present on that machine. Full stop.

The best you can do, is to find a hardware identifier that identifies that specific machine, and obfuscate that value somewhere (either inside the executable itself or in a auxilliary file, or even via network on a server that you own).

When the program is run, it can compare the hardware identifier with its stored identifier and chokes if they are different.

Limits:

  • unless you do the installation yourself, it is very hard to prevent the user to copy the program before installation. That means that you will need an online step at installation time to prevent multiple installation from the same source
  • If the user has to change the piece of hardware that you monitor because of any reason, the test will fail while the user should be allowed to use your program => be ready to provide support about that. And be sure that if you do not ask for that explicitely, a casual user will not imagine that his program does not work anymore just because the internal network interface has gone out of use.

TL/DR: you are trying to use a technical way to solve a legal problem. Refrain if you can. I can remember old programs that required a special hardware on a parallele port. And that caused so many nightmares because it suddenly went wrong that the organization I was working for decided to never buy any more a software requiring a hardware key, even if better of less expensive. User experience is indeed a choice criterium, and those @#&! security tools provide a very poor user experience.

Upvotes: 3

Related Questions