0

I want to prevent executable being copied to another PC and thus i need to somehow save information inside my EXE file about that it was already used somewhere else on another PC.

Can i embed small piece of information like user's hard drive number into my EXE file so this information would be available when this EXE is copied to another PC?

I thought maybe there is a way to read and write to some resource file embedded in an EXE file but i presume that resource file is read only and if so is there is a place inside EXE file where i could keep information which i need?

Anonymous
  • 1,823
  • 2
  • 35
  • 74
  • While I suspect this is possible, it would only provide a trivial amount of protection... and no more protection than storing the data elsewhere on installation (e.g. the registry). – Jon Skeet Aug 25 '13 at 16:28
  • 3
    I'm not sure why people keep downvoting this question. It's not a great question but it definitely doesn't deserve so many downvotes. – xxbbcc Aug 25 '13 at 16:46
  • Why not just make an unmanaged text file read that would make the program crash on other computers? I.e read from a hard coded file path – Sayse Aug 25 '13 at 17:57
  • @Sayse : i presume you mean to create an installator and during installation put some text file to hardcoded path in the system so when app starts it could check it - in this case how can i prevent the installator itself being distributed? Otherwise (if i misunderstood you) could you please clarify how exactly this text file will appear in that hardcoded path? – Anonymous Aug 25 '13 at 18:17
  • @Art - I literally mean do a File.ReadAllText("hardcodedpath") which will work on the machine you want it to, but then all others the program will crash on – Sayse Aug 25 '13 at 20:45
  • @Sayse : i still do not get it - how this can help me to identify that program was copied from another PC? Could you provide more descriptive algorithm as a separate answer? – Anonymous Aug 25 '13 at 21:05
  • @Art - It can't but it will be useless as noone will be able to use it, I recognise this is a *very* weak security effort – Sayse Aug 25 '13 at 22:24

2 Answers2

3

You're fighting an uphill battle this way. It's possible to create a home-grown licensing scheme but be prepared to do a lot of work (I did it, so I speak from first-hand experience). Just some problems to solve:

  • If the hard drive fails and needs to be replaced, your user won't be able to use the program. Every time this happens, you'll get a support call with an angry user.
  • If the user runs your program inside a virtual machine, the hard drive serial number won't be unique - anyone can clone the virtual machine and now your program can be run on another machine.
  • Hard drive serial numbers can be changed - they don't come directly from the hardware.
  • What if the hard drive is a removable drive? Your user can run your program from a removable drive and then keep moving it to different machines.
  • Even if you get it done, how do you protect the license information from being modified?

If you really want to license your product, look at existing licensing products - they're not cheap but they already did the (considerable amount of) work that's necessary to have any kind of reliability.

Even if you only want to have minimal protection, consider this: you'll have to do a lot of work to get even minimal security of your secret token (whatever that is). If its security is minimal, then what's the point of you even doing all that work? If all you do is force people to put in a meaningless serial number, you'll just annoy your honest customers. If anyone wants to steal something that's not well protected, they will steal it. All a 'simple' protection scheme does is annoys your users and gives you a false sense of protection.

I ended up using Reprise RLM - I'm not associated with this company but I had a good experience with their sales and support people and their product worked well in the testing scenarios.

xxbbcc
  • 16,930
  • 5
  • 50
  • 83
  • well, i do not suppose to create kind of extra powerful protection system i know that any system can be cracked, all i want is just to create some simple (e.g. key / pass) check to ensure that it stops at least non-professional hackers ... nothing special – Anonymous Aug 25 '13 at 16:31
  • @Art Yes, that's what I thought. I updated my answer for that, too. That homegrown, _simple_ protection system that I worked on ended up being over 15,000 lines of C++ code (not counting external libraries). It was working well but it was still a very naive system with a number of security holes. That's why my company eventually switched to RLM. – xxbbcc Aug 25 '13 at 16:35
2

Ok, I analyzed all the variants that were proposed and decided that in my case it will be better to develop my own copy-protection system, due to the reason that I am an indie developer and not going to work with extra large applications.

Just in case, somebody faces to the same issue - here is the algorithm (well, one of them):

  1. User starts APP1.EXE
  2. APP1.EXE reads itself to some variable and adds HDD serial number to the end of it, e.g. HDD serial number - when you add something to the end it does not break EXE file and you do not have to worry about PE headers
  3. Unfortunately, EXE cannot save itself in runtime so it saves its copy called APP2.EXE with the information about HDD
  4. When APP2.EXE is saved APP1.EXE starts it as a separate process via Process.Start() and terminates itself
  5. Now APP2.EXE is running and has the same content as APP1.EXE + HDD serial number so we simply write all bytes from APP2.EXE back to APP1.EXE, close current process and start APP1.EXE again
  6. From now on APP1.EXE is running and have all needed information about current HDD so each time user starts APP1.EXE it compares HDD number at the end of its content with the actual one on user's PC, if they differ - terminate the process
  7. Delete APP2.EXE so that user would not realize how these files exchange information about his HDD.

Useful info about self-deleting EXE can be found here :

P. S. I know that it is like a huge hole of security (I will not mention all of them) but implementation of this algorithm took just 20 lines of code in C# and was moved to a separate DLL which I can use everywhere and it works. There is NO any registration in the algorithm above and user can simply take this app and use it and I am sure that ~ 80% of them will not realize how this app is protected from copying.

Link to implementation : https://bitbucket.org/artemiusgreat/examples/src/ef7b60142277?at=master

Anonymous
  • 1,823
  • 2
  • 35
  • 74
  • Doesn't this only work if you yourself manually copy the app1.exe to the target machine? If you use an installer that the user can use, to generate the exe, your method would prevent the exe from being copied but not the installer. How do you distribute the exe? – leoinlios Feb 02 '19 at 08:43
  • @leoinlios That wasn't my intention to control all possible way of copying, but if I had to, I'd use some installer that adds hard drive ID to EXE file at the moment of installation. Users can't use EXE without installation, so they're obligated to run it at least once. Some of these packages should do this https://helpdeskgeek.com/free-tools-review/4-tools-to-create-windows-installer-packages/ – Anonymous Feb 04 '19 at 08:17