-1

I'm working on a Windows Native C++ Desktop Software Licensing Mechanism and I'm trying to be as unobtrusive as possible. The idea behind it is simple and I'm trying to deter people from sharing it primarily through adding their personal information in the software and also locking it on an array of target machines.

How Licensing Works:

When someone downloads the software from my server they get a new personalized PE section added to it that contains personally identifiable information and a hash key that protects it from tampering. The hash is checked against an embedded public key and generated by a private key on server.

When the tool runs, it checks itself against the hash key, then calls home and only runs if local tests succeed and it gets the green light from home. As the tools are internet tools that require being online all the time, calling home should almost always be possible, unless blocked through DNS (but I'll include a custom DNS client in the tools to avoid Windows when resolving to call home).

Question:

My main concern is if it's possible for antivirus software to frown upon my custom section embedded in the PE structure? I'm not talking about free data appended to the end of the file. I'm embedding a new section and rewriting the PE.

I did some tests and had no problem but I'm wondering if others have more experience with such things.

Kevin Brown-Silva
  • 40,873
  • 40
  • 203
  • 237
CodeAngry
  • 12,760
  • 3
  • 50
  • 57

2 Answers2

2

I see a few red flags:

  1. Your application isn't signed by Authenticode, or (worse) your new section invalidated the Authenticode signature. Solution: don't reinvent the wheel, use the Authenticode mechanism instead of your own.

  2. Since your executable is unique, it can't be whitelisted.

  3. Your app contains its own DNS client. This will be noticed by AV software.

The custom PE section itself isn't going to score too bad, but why so complex? A RT_RCDATA resource seems more appropriate.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • 1. Resources are really easy to edit. 2. For the moment, signing the tools is not an issue either. Luckily, it's for a tech savvy audience so they don't get easily intimidated. And one can use `CryptUIWizDigitalSign(CRYPTUI_WIZ_NO_UI, ...);` to sign on the fly. 3. Why would a low-level (UDP socket level) statically linked DNS client be noticed by AV? I've never had such an issue... – CodeAngry Mar 17 '14 at 11:58
  • @CodeAngry: 1: So? Still protected by signature. 2. I'm tech-savvy, a missing signature is a red flag to me precisely because I know it should be there. 3. Because the AV monitors network traffic at socket level, and sees a DNS request not originating from the OS. The phrase "I have never had such an issue" becomes rather pointless when you have more than a handful of customers. They will. – MSalters Mar 17 '14 at 12:16
  • Ok. I'm new to larger scale distribution of software. Could you also give me a hit on the following: **Are there code signing certificates for individuals? And what's the paperwork and embedded signature personal information?** --- I'm not very comfortable to bundle my personal information with the tools... – CodeAngry Mar 17 '14 at 12:23
  • @CodeAngry: That probably should be a separate question, on programmers.SE (if itś not already there) – MSalters Mar 17 '14 at 12:44
1

It is a common misunderstanding that signatures prevent tampering. They do not prevent it, they only reveal it.

If a user is complicit (they intend to use a cracked/improperly licensed version), allowing them to discover the tampering doesn't get you anywhere.

Your best bet is not to use the unique fingerprint to block operation of the software, which will surely just lead to a warez version which has the license checks patched out, but merely collect data on multiple installations which may be used when pursuing legal action in a civil suit for unauthorized copying.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • **You're right.** Now I'm also preventing execution if tampered with AND it calls home to verify each installation machine as tools need to be online to do their jobs anyways. – CodeAngry Jul 17 '14 at 15:21
  • 1
    @CodeAngry: If you prevent execution, it will be obvious that you have tamper detection... and it won't be long before a cracked version exists without tamper detection. If you don't take any action based on the unique fingerprint, it's less likely to be removed, and then when you encounter cracked versions, you can trace their pedigree. It might be worthwhile to have two unique fingerprints, with two different methods, one of which is reported home and the other sits completely inactive, ready for you to analyze after discovering a cracked binary. – Ben Voigt Jul 17 '14 at 16:13