BSOD 0xC4 on Windows 10

NTDEV
1

Hello,

I have a driver built with WDK 8.1 which I’m trying to run on Windows 10 with the Verifier enabled with most checks(all except low resource simulation).
I receive the following BSOD when the driver is started:

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000002003, Code Integrity Issue: The image contains an executable and writable section.
Arg2: ffffe001c9e8a888, The image file name (Unicode string).
Arg3: fffff800be5e02b0, The address of the section header.
Arg4: ffffd001c9a6f5d0, The section name (UTF-8 encoded string).

0: kd> da ffffd001c9a6f5d0
ffffd001`c9a6f5d0 “INIT”

So, I placed the driver in a disassembler and I saw that the INIT section was RWX and this is not good for the Verifier.
I tried modifying the linker settings and tried the following options(one at a time, not all at once): /SECTION:“INIT,RW”, /SECTION:“INIT,RE”, /SECTION:“INIT,!E”, /SECTION:“INIT,!W”
I also tried writing in the source code #pragma section(“INIT”, read, write) or #pragma section("INIT, read, execute)

There was no effect to any of my efforts, each time I would look in the disassembler and see the section as RWX.

I tried compiling the driver using WDK 10.0 version. It worked without any problems (I didn’t have to modify the linker options or add any pragma’s).

My question is this: is there any way to ensure the INIT section will be either writable or executable but not BOTH using WDK 8.1?
If not, is there any way to build a driver which will pass all the checks made by the Windows 10 verifier using WDK 8.1?

2

Great question.

For those who may not be aware, there’s a much greater emphasis in Win10 on ensuring Executable sections are not also Writable for security reasons.

I’m not aware of the options that affect this… I’m hoping to hear something from the MSFT folks here in response to your post.

Have you tried just not bothering with an INIT segment? I almost never use them anymore, unless my INIT code is really, really, large.

Peter
OSR
@OSRDrivers

3

Well, I have no functions or variables declared to be part of the INIT section.

From what I can see in the disassembler, the only function present in this section is the ___security_init_cookie function and the variables are some import descriptors representing the libraries I use. Some examples are: __IMPORT_DESCRIPTOR_ntoskrnl, __IMPORT_DESCRIPTOR_NDIS and so on.

Is there an explicit method of telling the linker not to create the INIT section or what do you mean by “not bothering with an INIT segment”?

4

You don’t explicitly create the INIT section in your code?

If not, what you’re seeing is quite strange. Are you using the standard WDK?

Peter
OSR
@OSRDrivers

5

No I haven’t explicitly created an INIT section in the code. And I’m using
the standard WDK (downloaded from MSDN).

The only place where the INIT section was mentioned was in the linker in
the “Specify Attributes Section” where by default (when the project was
created) was set to INIT,d. Even if I removed this mention of the INIT
section it would still appear.

I did some more ‘experimenting’ with the linker options and it seems if I
go to Linker -> System -> Driver and place the option to NotSet(instead of
the /DRIVER option) everything seems to be fine. The
___security_init_cookie function remains in the INIT section but that’s all
(and it’s set as a RX section only).

From what I’ve read in the MSDN documentation the only thing the /DRIVER
option does is to set the output of the file to be .sys and it specifies
that the load address is not fixed -
https://msdn.microsoft.com/en-us/library/43a6z8s4.aspx.

Sorry for my spelling mistakes, but I’ve written this post in quite a hurry.

Thanks for your answers and for your help and if there are other solutions
(maybe cleaner), I hope to hear from you.

On 20 April 2015 at 16:26, wrote:

> You don’t explicitly create the INIT section in your code?
>
> If not, what you’re seeing is quite strange. Are you using the standard
> WDK?
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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

I really don’t know what to say. I’m running a driver right this second that has a driver built using the Win81 WDK on Windows 10, and it’s working. This PARTICULAR driver is a StorPort Miniport, but…

I actually had some information on this change in Windows 10, but I’ll be DAMNED if I can find it.

Sorry, I wish I could be more help…

Peter
OSR
@OSRDrivers

7

Security_init_cookie function comes from the real DriverEntry module, from the library. If it was compiled as RWX, it will stay as RWX. You can try to merge INIT to TEXT, but it may then inherit the W attribute:

/MERGE:INIT=.text

8

@PeterGV: I have tried building different drivers (from the WDK 10 samples)
with WDK 8.1 and the same problem appears to be occurring. Are you sure you
have the verifier turned on your StorPort Miniport driver?

@grigora: I tried merging, but the result is the same, the INIT section is
still present and remains RWX. No linker warning or errors happen.

On 22 April 2015 at 03:06, wrote:

> Security_init_cookie function comes from the real DriverEntry module, from
> the library. If it was compiled as RWX, it will stay as RWX. You can try to
> merge INIT to TEXT, but it may then inherit the W attribute:
>
> /MERGE:INIT=.text
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

9

Now that you mention it, no… I’m not 100% certain Verifier was enabled.

Is there a Verifier check that you can disable?

Let me see if I can repro your experience later today. I’ve got a recent Win10 build, and I’ve got a driver built with the Win8.1 Update 1 WDK. Let me turn on Verifier and see what I get. If your problem repos, this will be a BIG *pita* for the community.

Peter
OSR
@OSRDrivers

10

It seems that the verifier option responsible for this check is called
“Code integrity checks” and CANNOT be enabled from the GUI.

The way I enabled this check was by starting the verifier with the
following command: “verifier /driver MyCoolDriver /flags 0x02000000”. NOTE:
a reboot is necessary for this change.

I look forward to hearing your result!

On 22 April 2015 at 16:03, wrote:

>


>
> Now that you mention it, no… I’m not 100% certain Verifier was enabled.
>
> Is there a Verifier check that you can disable?
>
> Let me see if I can repro your experience later today. I’ve got a recent
> Win10 build, and I’ve got a driver built with the Win8.1 Update 1 WDK. Let
> me turn on Verifier and see what I get. If your problem repos, this will
> be a BIG pita for the community.
>
> Peter
> OSR
> @OSRDrivers
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

11

Ah! THAT’s where I remember seeing this. The description of the added Win10 non-GUI flags I saw someplace.

So, you have to MANUALLY enable this particular test? And drivers built with the Win8 WDK don’t pass it. OK, that makes sense! That would move this from “a *big* issue with the community” to a “who cares” issue in my book. I guess the question is, why do YOU care? Are you just experimenting to see if there’s a way to make this work?

Peter
OSR
@OSRDrivers

12

Well, those verifier checks are there to help us write better and more
secure code so I see no reason why we shouldn’t take advantage of it.

Because the check I mentioned is responsible for verifying that there is no
section which has both writable and executable attributes it ensures that
code injection is not possible and that is a big PLUS from a security point
of view.

Also, I mentioned in a post 3 days ago that if you remove the /DRIVER
option from the linker command line the problem will be SOLVED because the
INIT section will be executable and non-writable.

On 22 April 2015 at 20:42, wrote:

>


>
> Ah! THAT’s where I remember seeing this. The description of the added
> Win10 non-GUI flags I saw someplace.
>
> So, you have to MANUALLY enable this particular test? And drivers built
> with the Win8 WDK don’t pass it. OK, that makes sense! That would move
> this from “a big issue with the community” to a “who cares” issue in my
> book. I guess the question is, why do YOU care? Are you just
> experimenting to see if there’s a way to make this work?
>
> Peter
> OSR
> @OSRDrivers
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

13

Sure. All well and good. For drivers built with the Win10 WDK where this is designed to be supported.

Well, your post has been helpful in drawing people’s attention to this issue, and I certainly thank you for that.

Peter
OSR
@OSRDrivers