Intellectual property protection in a kernel service?

NTDEV
1

Hello,

We are developing a kmdf, non-PnP, kernel service that will be used by several of our commercial applications. This driver will require thousands of hours to develop, so, naturally, we are interested in protecting our work… Like a lock on the door of a house, we want to implement some simple barriers. Of course, someone really intent on opening the “door” and reverse engineering our product, would be able to do it. We would like to implement some simple protection schemes that, hopefully, would make most people want to buy our product rather than spend the time to reverse engineer it and using it in their products.

I have scoured the Internet searching for discussions on how others are implementing intellectual property protection in kernel mode services, but did not find anything. I hope that this posting will start this kind of discussion. I understand that some people will find this topic offensive or consider it foolish, but when we are investing thousands of dollars in creating a high quality product, it does not seem unreasonable to want to protect it.

Here are some ideas as to how to implement some simple protection. Of course, protection must be balanced by its impact on performance.

  1. LEGAL.
    The first line of defense is to ensure that you are inserting copyright messages into your product’s source code and binaries, and to prosecute offenses.

  2. ENCRYPTION/DECRYTPION.
    For kernel mode services that use IOCTL, rather than simply sending in a binary buffer containing input data and returing a binary result, I wonder whether encrypting/decrypting the input and output would be a good idea. I’ve found information on the kernel mode, FIPS Crypto Driver, and wonder whether it could be used. I have not found much information on using it within a device driver.

Another option would be to encrypt output files that may be used by user mode appliations.

  1. RANDOM CHECKS.
    Throughout the code, insert random validations like CRC checks against the original device driver file that was installed. Yes, someone could spend the time looking for these validations and removing them, but would it be worth all their effort to do it?

Anyway, I hope that we can start a discussion of this topic because I believe it would be helpful for others as well as for our team.

Thanks,

Mike

2

Ultimately, all such schemes are defeated. The question is, is your product so interesting that somebody could be bothered to even dig into an unprotected code?

Also, why do you want to make it a kernel driver? Do you need to attach to any existing driver stack? Or you think you’ll get better performance out of it (answer: no, you won’t).

I’d rather advise you to make sure your driver can’t be exploited for privilege elevation vulnerabilities. It’s so easy make such mistakes.

3

Fundamentally, I’m afraid this goal of protecting your basic IP is doomed to fail: if it truly is groundbreaking then

a) It’s mechanisms can be eventually determined by watching the system respond to your driver (sort of like a reverse stimulus-response, or an accident reconstruction) to determine what’s going on. To see how this is done, read Hoaglund’s Rootkit book and substitute the words “our driver” for “windows kernel” … the techniques, and eventual outcome, are the same
b) Any sort of anti-debugging methods can be overcome, likely by the malware-hunting folks or just people curious to see how your anti-debugging works (read http://www.codeproject.com/KB/security/AntiReverseEngineering.aspx for some examples)
c) You can protect the implementation of an idea, *not* the idea itself. JPEG itself is an idea and isn’t patented, the various methods of JPEG encoding/ decoding *are* patented. Note that the process of patenting itself exposes your implementation, see items a) and b)

Ultimately, it’s not the idea that sells but the implementation. I can give you detailed information on the operations required for a PCIe core (heck, they are public domain!) but nobody writes their own cores these days, they buy them from Synopsys or the like. If your IP implementation truly would require thousand of man-hours to replicate *and* it’s an IP that people care about then, like the PCIe core vendors, people will buy your product without regard to any sort of barriers …

Cheers!

4

On 03/07/2011 12:23 AM, xxxxx@a-bit-of-help.com wrote:

[intellectual property protection in kernel mode services]

If you really need to protect your intellectual property,
don’t place it onto any untrusted computer in the first place.

Run the critical functionality within an external device. Possibly even
make it available as a remote service running on your computers.

Anything else will (a) not work against anybody determined enough (=your
competitors?), and (b) makes life much harder for your loyal customers.

(b) implies (c): people will buy from any other source (not employing a
system-destabilizing “protection” scheme) if / as soon as they can.

[If you want to prevent any unintentional license violation, however,
have a look at “Matt On Software Licensing” and their short discussion
of what software license managers can protect and what not.]

5

I would agree with this, but I would also add that if you do decide to
implement some sort of protection scheme, consider purchasing one instead
and focusing your resources - both for development and moreover down the
road during maintenance - on your product.

Good luck,

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
choward@ix.netcom.com
Sent: Monday, March 07, 2011 12:58 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Intellectual property protection in a kernel service?

Fundamentally, I’m afraid this goal of protecting your basic IP is doomed to
fail: if it truly is groundbreaking then

a) It’s mechanisms can be eventually determined by watching the system
respond to your driver (sort of like a reverse stimulus-response, or an
accident reconstruction) to determine what’s going on. To see how this is
done, read Hoaglund’s Rootkit book and substitute the words “our driver” for
“windows kernel” … the techniques, and eventual outcome, are the same
b) Any sort of anti-debugging methods can be overcome, likely by the
malware-hunting folks or just people curious to see how your anti-debugging
works (read
http://www.codeproject.com/KB/security/AntiReverseEngineering.aspx for some
examples)
c) You can protect the implementation of an idea, *not* the idea itself.
JPEG itself is an idea and isn’t patented, the various methods of JPEG
encoding/ decoding *are* patented. Note that the process of patenting
itself exposes your implementation, see items a) and b)

Ultimately, it’s not the idea that sells but the implementation. I can give
you detailed information on the operations required for a PCIe core (heck,
they are public domain!) but nobody writes their own cores these days, they
buy them from Synopsys or the like. If your IP implementation truly would
require thousand of man-hours to replicate *and* it’s an IP that people care
about then, like the PCIe core vendors, people will buy your product without
regard to any sort of barriers …

Cheers!

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

adding to what all everyone already has suggested…

1, Try Armadillo for user mode binary protection. Binary mode components
can’t be encrypted. so your driver will remain unprotected.
2. You can try debugger detection in driver, I have tried it, but it is not
worth it. Also, you will run into issues with patch guard.
3. You can research on Hash Message Authentication Code (HMAC) and see if it
helps you in any way.
4. The Windows Crypto library is not documented IIRC and you are on your own
there.
5. By design FIPS doesnt store your keys, so even if you figure out how to
use the functions, you gotta find a way to secure your key. Attackers can
you entropy analyzers to scan your memory/binary for high randomness chunks
and try them out as keys.
6. Try reconstructing the stack on each call (both user and kernel level) to
see who called your function. but remember stack frames can be tampered with
too.

I have tried all the above and many others and found that it is madness. It
digresses the scope from the product to something that also understands
security and is an anti malware -> in other words an AV. Which essentially
you are not.

You will be spending so much resource on implementing ths, and the attacker
will be able to break it pretty fast.

instead buy a commercial protection software (after reading the fne print
very carefully), atleast you wil have someone to sue later on :slight_smile:

On Mon, Mar 7, 2011 at 4:53 AM, wrote:

> Hello,
>
> We are developing a kmdf, non-PnP, kernel service that will be used by
> several of our commercial applications. This driver will require thousands
> of hours to develop, so, naturally, we are interested in protecting our
> work… Like a lock on the door of a house, we want to implement some
> simple barriers. Of course, someone really intent on opening the “door” and
> reverse engineering our product, would be able to do it. We would like to
> implement some simple protection schemes that, hopefully, would make most
> people want to buy our product rather than spend the time to reverse
> engineer it and using it in their products.
>
> I have scoured the Internet searching for discussions on how others are
> implementing intellectual property protection in kernel mode services, but
> did not find anything. I hope that this posting will start this kind of
> discussion. I understand that some people will find this topic offensive or
> consider it foolish, but when we are investing thousands of dollars in
> creating a high quality product, it does not seem unreasonable to want to
> protect it.
>
> Here are some ideas as to how to implement some simple protection. Of
> course, protection must be balanced by its impact on performance.
>
>
> 1) LEGAL.
> The first line of defense is to ensure that you are inserting copyright
> messages into your product’s source code and binaries, and to prosecute
> offenses.
>
> 2) ENCRYPTION/DECRYTPION.
> For kernel mode services that use IOCTL, rather than simply sending in a
> binary buffer containing input data and returing a binary result, I wonder
> whether encrypting/decrypting the input and output would be a good idea.
> I’ve found information on the kernel mode, FIPS Crypto Driver, and wonder
> whether it could be used. I have not found much information on using it
> within a device driver.
>
> Another option would be to encrypt output files that may be used by user
> mode appliations.
>
> 3) RANDOM CHECKS.
> Throughout the code, insert random validations like CRC checks against the
> original device driver file that was installed. Yes, someone could spend
> the time looking for these validations and removing them, but would it be
> worth all their effort to do it?
>
> Anyway, I hope that we can start a discussion of this topic because I
> believe it would be helpful for others as well as for our team.
>
> Thanks,
>
> Mike
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

–

- amitr0

7

> We would like to implement some simple protection schemes that, hopefully, would make most people

want to buy our product rather than spend the time to reverse engineer it and using it in their products.

You seem to be mixing up two totally unrelated things:

  1. Protection against “competitors who want to disassemble your product and reuse your code in theirs”. This idea is simply ridiculous in itself, simply because such “code reuse” is not worth an effort - it is much easier for them to write a totally new product from the scratch, rather than trying to make heads and tails out of disassembled code and write C source that is based upon it. If you don’t believe me try it yourself - although it may work fine for small pieces of code using it on larger scale seems to be …ugh, simply unrealistic.

  2. Protection against crackers who want to remove your protection/key validation scheme and distribute your product. This kind of protection is, indeed, worth an effort. There are different approaches to this problem. In any case, as Martin already pointed out, don’t try to develop your own scheme and, instead, purchase the one from some vendor who is specialized in products like that…

Anton Bassov

8

>

  1. Protection against crackers who want to remove your protection/key
    validation scheme and distribute your product. This kind of protection
    is,
    indeed, worth an effort. There are different approaches to this
    problem. In
    any case, as Martin already pointed out, don’t try to develop your own
    scheme
    and, instead, purchase the one from some vendor who is specialized in
    products
    like that…

Is there any sort of code protection that requires breaking any more
than one time for it to be useful for them?

Like just about every piece of copy protection I’ve ever seen before,
will it end up inconveniencing the people who actually paid for your
product, your customers, while the pirates strip away all the copy
protection and use your software unencumbered?

More importantly, will it be easier for the customer to purchase the
product from you and suffer through registration and activation, or just
download it from their favourite torrent source?

And probably just as importantly, how much will it cost to implement and
how much will it save you in ‘lost sales’?

James

9

> Is there any sort of code protection that requires breaking any more than one time for it to be useful for them?

Certainly there is no such thing as 100% reliable protection. However, it does not necessarily mean that you should not even try to make cracker’s task at least a bit more challenging, right?

Like just about every piece of copy protection I’ve ever seen before, will it end up inconveniencing
the people who actually paid for your product, your customers, while the pirates strip away
all the copy protection and use your software unencumbered?

Well, your customer is not supposed to know anything beyond the simple fact than he/she has to enter a valid registration key upon product installation. Does not really seem to be that demanding, right? Certainly, If you go further than that (say, follow MSFT example and request the additional product activation), then you are, indeed, risking just to lose a customer who may get simply annoyed with the whole thing …

Anton Bassov

10

>>2) ENCRYPTION/DECRYTPION. For kernel mode services that use IOCTL, rather than simply sending in a binary buffer containing input data and returing a binary result, I wonder whether encrypting/decrypting the input and output would be a good idea. I’ve found information on the kernel mode, FIPS Crypto Driver, and wonder whether it could be used. I have not found much information on using it within a device driver. Another option would be to encrypt output files that may be used by user mode appliations.<<

IIRC, you can’t use fips, because it may be removed in future OS. Encrypting files … Well, one can just fire up windbg, set a bp before you start to ecrypt and fetch the key. Right? Afterwards, this key can be used to read your files. You can make some dynamic key, yes, but there should be some pattern how you are going to generate it. It can be also cracked.

You can use some implementations of popular symmetric algorithms in kernel mode, like aes, bw/tw, etc. But still you can’t be sure key is not compromised.

>3) RANDOM CHECKS. Throughout the code, insert random validations like CRC checks against the original device driver file that was installed. Yes, someone could spend the time looking for these validations and removing them, but would it be worth all their effort to do it?<<

If I would be an offender, I would not care about these. I would try to fetch data from ioctls by substituting your client part. Of course, it all depends what your driver is reporting.

What is so valuable in your driver?

V.

11

Hello Everyone,

Thank you very much for taking the time to respond to my posting. I understand that anyone who is intent on accessing our code, will do it, but I was hoping to implement some basic protection to impede a casual but curious person. Having read your comments, it seems that the prevailing opinion is that it doesn’t make sense to implement intellectual property protection at this level because it is easily circumvented. So, if there is a truly unique algorithm, it may be best to move it to user mode where there are more options available. And even there, your comments still apply.

Thank you again for your ideas and comments!

Mike

12

>

> Is there any sort of code protection that requires breaking any more
than
> one time for it to be useful for them?

Certainly there is no such thing as 100% reliable protection. However,
it does
not necessarily mean that you should not even try to make cracker’s
task at
least a bit more challenging, right?

Unless you make it too challenging and it comes to the attention of the
cracker community that your protection is really good. Then they’ll be
falling over themselves to crack it and history tells us it won’t take
them very long at all, especially if you use a commercial protection
suite for which they already probably have a solution.

James

13

It reminds me the lock picking contests I had watched. It’s fun.

Calvin

14

To OP: try to remove logs from your driver (it is funny for me to see that most of AVs still log even in release to KdPrint(…) in their drivers) or make them less convinient to understand (use ids of errors instead of human readable name, thus attacker might be slightly more confused).

Turn on optimizations in user mode helpers, remove logs from it as well. Rely on windows security, i.e., when creating dev object allow only admin to ioctl your driver.

If you care about any particular areas of code try to proxy the calls to routines, for example, if you fire up Ida, the first thing you do is checking the import table. Few clicks and you already in the place where particular functions is being used: you analyze the nearby code and voila - you understand what it is doing. Easy.

If you proxy call by storing in your DriverEntry pointer to function obtained via MmGetSystemRoutineAddress(…) you can confuse person where you use the function. You can encrypt all functions name and dycrypt them only after tons of code is executed, thus, for an attacker the only way will be to debug in windbg.

Debugging release driver is do-able, just takes time. At least it would not be just a few clicks in Ida.

Regularly re-check your binary in Ida to make sure looks not quite obvious before any major release.

Have fun,
V.

15

My esteemed colleague pointed out that there is a typo in point number 1
below. What I meant was…

1, Try Armadillo for user mode binary protection. *kernel* mode components
can’t be encrypted. so your driver will remain unprotected.

Thanks aditya!

amitr0

On Mon, Mar 7, 2011 at 2:30 PM, amitr0 wrote:

> adding to what all everyone already has suggested…
>
>
> 1, Try Armadillo for user mode binary protection. Binary mode components
> can’t be encrypted. so your driver will remain unprotected.
> 2. You can try debugger detection in driver, I have tried it, but it is not
> worth it. Also, you will run into issues with patch guard.
> 3. You can research on Hash Message Authentication Code (HMAC) and see if
> it helps you in any way.
> 4. The Windows Crypto library is not documented IIRC and you are on your
> own there.
> 5. By design FIPS doesnt store your keys, so even if you figure out how to
> use the functions, you gotta find a way to secure your key. Attackers can
> you entropy analyzers to scan your memory/binary for high randomness chunks
> and try them out as keys.
> 6. Try reconstructing the stack on each call (both user and kernel level)
> to see who called your function. but remember stack frames can be tampered
> with too.
>
> I have tried all the above and many others and found that it is madness. It
> digresses the scope from the product to something that also understands
> security and is an anti malware -> in other words an AV. Which essentially
> you are not.
>
> You will be spending so much resource on implementing ths, and the attacker
> will be able to break it pretty fast.
>
> instead buy a commercial protection software (after reading the fne print
> very carefully), atleast you wil have someone to sue later on :slight_smile:
>
>
> On Mon, Mar 7, 2011 at 4:53 AM, wrote:
>
>> Hello,
>>
>> We are developing a kmdf, non-PnP, kernel service that will be used by
>> several of our commercial applications. This driver will require thousands
>> of hours to develop, so, naturally, we are interested in protecting our
>> work… Like a lock on the door of a house, we want to implement some
>> simple barriers. Of course, someone really intent on opening the “door” and
>> reverse engineering our product, would be able to do it. We would like to
>> implement some simple protection schemes that, hopefully, would make most
>> people want to buy our product rather than spend the time to reverse
>> engineer it and using it in their products.
>>
>> I have scoured the Internet searching for discussions on how others are
>> implementing intellectual property protection in kernel mode services, but
>> did not find anything. I hope that this posting will start this kind of
>> discussion. I understand that some people will find this topic offensive or
>> consider it foolish, but when we are investing thousands of dollars in
>> creating a high quality product, it does not seem unreasonable to want to
>> protect it.
>>
>> Here are some ideas as to how to implement some simple protection. Of
>> course, protection must be balanced by its impact on performance.
>>
>>
>> 1) LEGAL.
>> The first line of defense is to ensure that you are inserting copyright
>> messages into your product’s source code and binaries, and to prosecute
>> offenses.
>>
>> 2) ENCRYPTION/DECRYTPION.
>> For kernel mode services that use IOCTL, rather than simply sending in a
>> binary buffer containing input data and returing a binary result, I wonder
>> whether encrypting/decrypting the input and output would be a good idea.
>> I’ve found information on the kernel mode, FIPS Crypto Driver, and wonder
>> whether it could be used. I have not found much information on using it
>> within a device driver.
>>
>> Another option would be to encrypt output files that may be used by user
>> mode appliations.
>>
>> 3) RANDOM CHECKS.
>> Throughout the code, insert random validations like CRC checks against the
>> original device driver file that was installed. Yes, someone could spend
>> the time looking for these validations and removing them, but would it be
>> worth all their effort to do it?
>>
>> Anyway, I hope that we can start a discussion of this topic because I
>> believe it would be helpful for others as well as for our team.
>>
>> Thanks,
>>
>> Mike
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> –
>
> - amitr0
>

–

- amitr0

16

On Mon, Mar 7, 2011 at 2:23 PM, wrote:
> but I was hoping to implement some basic protection to impede a casual but curious person.

So you will protect your IP from the casual and curious, for example
IT personnel trying to root cause system crashes, but not from the
willfully serious out to crack and steal. The point of this exercise
is what?

Mark Roddy