build details

Is there a way to read the build details like build time etc of a driver in
it’s DriverEntry? I want this feature to abort driver loading if the driver
build is older than ‘x’ days.

thx

AP

This information (build time) is available in the COFF header and (most likely) as a part of the fixed resources, but if you want to
do this, I would personally include it as a constant that gets set by -D on the command line by a custom step of your build process,
because you won’t have to figure out where you are loaded and then do some binary parsing.

Good luck,

mm

A P wrote:

Is there a way to read the build details like build time etc of a driver
in it’s DriverEntry? I want this feature to abort driver loading if the
driver build is older than ‘x’ days.

thx

AP

> Is there a way to read the build details like build time etc of a driver
in it’s DriverEntry?

Something like

KdPrint((“DriverEntry [” DATE " " TIME “]\n”));

works fine. It’s easy to convert DATE and TIME into something
comparable to current time.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Thursday, May 29, 2008 6:21 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] build details

Is there a way to read the build details like build time etc of a driver in
it’s DriverEntry? I want this feature to abort driver loading if the driver
build is older than ‘x’ days.

thx

AP

— 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

That only works if the compilation unit containing that statement is built.
If it isn’t, it’s date is stale. Instead isolate the date information in its
own compilation unit and force that to get built every time.

On Thu, May 29, 2008 at 10:23 PM, Alex Shvedov wrote:

> > Is there a way to read the build details like build time etc of a
> driver in it’s DriverEntry?
>
> Something like
>
>
>
> KdPrint((“DriverEntry [” DATE" " TIME"]\n"));
>
>
>
> works fine. It’s easy to convert DATE and TIME into something
> comparable to current time.
>
>
>
>
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *A P
> Sent: Thursday, May 29, 2008 6:21 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] build details
>
>
>
> Is there a way to read the build details like build time etc of a driver in
> it’s DriverEntry? I want this feature to abort driver loading if the driver
> build is older than ‘x’ days.
>
>
>
> thx
>
>
>
> AP
>
> — 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
>
> —
> 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
>


Mark Roddy

> Instead isolate the date information in its own compilation unit and force
that to get built every time.

Well, one of the ways.

What to do with these macros is question #2.

The point is that there is no [simple] way to get the build timestamp
(=linking).

I assume the OP cannot get the drv.sys (or dll or whatever) file
modification time

otherwise the question would not make sense)

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, May 29, 2008 11:39 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] build details

That only works if the compilation unit containing that statement is built.
If it isn’t, it’s date is stale. Instead isolate the date information in its
own compilation unit and force that to get built every time.

On Thu, May 29, 2008 at 10:23 PM, Alex Shvedov wrote:

> Is there a way to read the build details like build time etc of a driver
in it’s DriverEntry?

Something like

KdPrint((“DriverEntry [” DATE" " TIME"]\n"));

works fine. It’s easy to convert DATE and TIME into something
comparable to current time.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Thursday, May 29, 2008 6:21 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] build details

Is there a way to read the build details like build time etc of a driver in
it’s DriverEntry? I want this feature to abort driver loading if the driver
build is older than ‘x’ days.

thx

AP

— 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


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


Mark Roddy — 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

folks,

Thanks for all the replies. SOme of which I couldn’t understand properly. I
have a few questions:

  1. Martin: "I would personally include it as a constant that gets set by -D
    on the command line ". I didn’t quite get this line. Kindly elaborate how a
    compiler switch helps.

  2. Alex: “It’s easy to convert DATE and TIME into something
    comparable to current time” If I use KdPrint it will simply print, I need to
    store it permanently as build time seed in the driver. So I guess something
    more like *g_pStringDate = DATE is closer? Also how do you convert it to
    current time, are you referring to TIME_FIELDS structure? IS there a
    function to do it, or do we simply write one ourselves?

  3. Alex: “What to do with these macros is question #2.” Once again this is
    not clear. Sorry my english is weak.

  4. Alex: 'I assume the OP cannot get the drv.sys (or dll or whatever) file
    modification time otherwise the question would not make sense)". I am in
    DriverEntry and I need to check whether the Driver has built before a
    DeltaTime or not. If so, we sill stop loading the driver. So please explain
    your last statement,

Thanks

AB

On Fri, May 30, 2008 at 7:05 PM, Alex Shvedov wrote:

> > Instead isolate the date information in its own compilation unit and
> force that to get built every time.
>
> Well, one of the ways?
>
> What to do with these macros is question #2.
>
>
>
> The point is that there is no [simple] way to get the build timestamp
> (=linking).
>
>
>
> I assume the OP cannot get the drv.sys (or dll or whatever) file
> modification time
>
> otherwise the question would not make sense)
>
>
>
>
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Mark Roddy
> Sent: Thursday, May 29, 2008 11:39 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] build details
>
>
>
> That only works if the compilation unit containing that statement is built.
> If it isn’t, it’s date is stale. Instead isolate the date information in its
> own compilation unit and force that to get built every time.
>
> On Thu, May 29, 2008 at 10:23 PM, Alex Shvedov
> wrote:
>
> > Is there a way to read the build details like build time etc of a driver
> in it’s DriverEntry?
>
> Something like
>
>
>
> KdPrint((“DriverEntry [” DATE" " TIME"]\n"));
>
>
>
> works fine. It’s easy to convert DATE and TIME into something
> comparable to current time.
>
>
>
>
>
>
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *A P
> Sent: Thursday, May 29, 2008 6:21 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] build details
>
>
>
> Is there a way to read the build details like build time etc of a driver in
> it’s DriverEntry? I want this feature to abort driver loading if the driver
> build is older than ‘x’ days.
>
>
>
> thx
>
>
>
> AP
>
> — 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
>
>
> —
> 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
>
>
>
>
> –
> Mark Roddy — 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
>
> —
> 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
>

More Tips:

A P wrote:

Thanks for all the replies. SOme of which I couldn’t understand
properly. I have a few questions:

  1. Martin: "I would personally include it as a constant that gets set
    by -D on the command line ". I didn’t quite get this line. Kindly
    elaborate how a compiler switch helps.

For example, you could have a little batch file that sets an environment
variable to the number of days since 1/1/1970, then in your sources file
you could do:
C_FLAGS = $(C_FLAGS) -DBUILDDATE=$(DAYS_SINCE_1970)

Now in your driver code you can do:
static int DaysSince1970 = BUILDDATE;

Now you have an integer you can compare against, assuming you can figure
out how to find the current date and time. However, this has one of the
same shortcomings of the DATE scheme: the variable will only be
updated when the .obj that contains it is recompiled. If you recompile
and relink the rest of the driver without recompiling this file, the
value will be old.

  1. Alex: “It’s easy to convert DATE and TIME into something
    comparable to current time” If I use KdPrint it will simply print, I
    need to store it permanently as build time seed in the driver. So I
    guess something more like *g_pStringDate = DATE is closer? Also
    how do you convert it to current time, are you referring to
    TIME_FIELDS structure? IS there a function to do it, or do we simply
    write one ourselves?

You would have to parse it yourself. That, and the issue that DATE
is only updated when that .obj is recompiled, is the reason I didn’t
jump in with this suggestion earlier.

  1. Alex: “What to do with these macros is question #2.” Once again
    this is not clear. Sorry my english is weak.

Same problem as above. The macros give you a string. To do
computations on it, you need to convert the string to an integer.

  1. Alex: 'I assume the OP cannot get the drv.sys (or dll or whatever)
    file modification time otherwise the question would not make sense)".
    I am in DriverEntry and I need to check whether the Driver has built
    before a DeltaTime or not. If so, we sill stop loading the driver. So
    please explain your last statement,

What he’s saying is that the most obvious way to determine the build
time of the .sys file is to go to the file system and check the
modification time of the .sys file. He assumed that you would only ask
your question if you were unable to do that.

Is this supposed to be some kind of boneheaded security scheme?
Wouldn’t it be much easier (and just as secure) to put a “number of
times to load” count into the registry, decrement it each time you load,
and refuse to load any more when the count goes to 0?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> Alex: "It’s easy to convert DATE and TIME into something
comparable to

current time" If I use KdPrint it will simply print

KdPrint was used as a working example, nothing more.

Once we know that these #define’s work in a driver (and KdPrint is used

as a proof here) we can use these constants in any way we like.

Maybe, this (in fact unnecessary) step will clarify things for you:

const char* compilationDate = DATE;

const char* compilationTime = TIME;

// here is the code that extracts normal timestamp

// from compilationDate and compilationTime,

// gets the current timestamp and compares the two

Note however that the first timestamp refers not to a time of build

(that is, when the resulting binary has been created) but to a time when

the current source file (ok, “compilation unit”) is compiled.

If your “sources” refer to mydrv.c and mylib.c and mydrv.c was last

compiled on Jan 1, 1900 and mylib.c last was last compiled on May

30, 2008, and DATE and TIME are referred to in mydrv.c,

they will point to 1/1/1900.

As someone noted, you have to deal with this fact.

Note also that all of this is not necessary if you have the luxury

to get your binary file modification (not creation) date/time through

“normal” channels.

Sorry for not making myself clear.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Friday, May 30, 2008 10:33 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] build details

folks,

Thanks for all the replies. SOme of which I couldn’t understand properly. I
have a few questions:

  1. Martin: "I would personally include it as a constant that gets set by -D
    on the command line ". I didn’t quite get this line. Kindly elaborate how a
    compiler switch helps.

  2. Alex: “It’s easy to convert DATE and TIME into something
    comparable to current time” If I use KdPrint it will simply print, I need to
    store it permanently as build time seed in the driver. So I guess something
    more like *g_pStringDate = DATE is closer? Also how do you convert it to
    current time, are you referring to TIME_FIELDS structure? IS there a
    function to do it, or do we simply write one ourselves?

  3. Alex: “What to do with these macros is question #2.” Once again this is
    not clear. Sorry my english is weak.

  4. Alex: 'I assume the OP cannot get the drv.sys (or dll or whatever) file
    modification time otherwise the question would not make sense)". I am in
    DriverEntry and I need to check whether the Driver has built before a
    DeltaTime or not. If so, we sill stop loading the driver. So please explain
    your last statement,

Thanks

AB

On Fri, May 30, 2008 at 7:05 PM, Alex Shvedov wrote:

> Instead isolate the date information in its own compilation unit and force
that to get built every time.

Well, one of the ways.

What to do with these macros is question #2.

The point is that there is no [simple] way to get the build timestamp
(=linking).

I assume the OP cannot get the drv.sys (or dll or whatever) file
modification time

otherwise the question would not make sense)

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Thursday, May 29, 2008 11:39 PM

To: Windows System Software Devs Interest List

Subject: Re: [ntdev] build details

That only works if the compilation unit containing that statement is built.
If it isn’t, it’s date is stale. Instead isolate the date information in its
own compilation unit and force that to get built every time.

On Thu, May 29, 2008 at 10:23 PM, Alex Shvedov wrote:

> Is there a way to read the build details like build time etc of a driver
in it’s DriverEntry?

Something like

KdPrint((“DriverEntry [” DATE" " TIME"]\n"));

works fine. It’s easy to convert DATE and TIME into something
comparable to current time.

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of A P
Sent: Thursday, May 29, 2008 6:21 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] build details

Is there a way to read the build details like build time etc of a driver in
it’s DriverEntry? I want this feature to abort driver loading if the driver
build is older than ‘x’ days.

thx

AP

— 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


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


Mark Roddy — 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


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

— 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

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, May 30, 2008 6:47 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] build details

Now you have an integer you can compare against, assuming you
can figure
out how to find the current date and time. However, this has
one of the
same shortcomings of the DATE scheme: the variable will only be
updated when the .obj that contains it is recompiled. If you
recompile
and relink the rest of the driver without recompiling this file, the
value will be old.

I’m probably biased but isn’t the only sane way how to release a driver
(or anything else) to rebuild it completely at the machine dedicated for
this task?

> 2. Alex: “It’s easy to convert DATE and TIME into something
> comparable to current time” If I use KdPrint it will simply
print, I
> need to store it permanently as build time seed in the driver. So I
> guess something more like *g_pStringDate = DATE is closer? Also
> how do you convert it to current time, are you referring to
> TIME_FIELDS structure? IS there a function to do it, or do
we simply
> write one ourselves?

You would have to parse it yourself.

I’m affraid it was a kind of question where the only good answer is: if
you have to ask, you’re probably unable to make it properly. Basic C
which is the prerequisite for any driver developer.

What he’s saying is that the most obvious way to determine the build
time of the .sys file is to go to the file system and check the
modification time of the .sys file. He assumed that you
would only ask
your question if you were unable to do that.

I don’t think it is the most obvious way. It depends on the purpose. If
it is to make a time limited version which doesn’t allow user to load a
driver after some date, it is quite easy for user to change binary
timestamps and bypass it. Much easier than to hack binary and modify
built-in DATE expanded there (not impossible, thought).

Is this supposed to be some kind of boneheaded security scheme?
Wouldn’t it be much easier (and just as secure) to put a “number of
times to load” count into the registry, decrement it each
time you load,
and refuse to load any more when the count goes to 0?

It is quite different scheme. OS can run for months without reboot and
driver can be loaded only once.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

Well, that was my reasoning as well, and I thought the bit about having to rebuild it unnecessary, but completeness never hurt
anyone, I suppose.

mm

Michal Vodicka wrote:

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Friday, May 30, 2008 6:47 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] build details
>
> Now you have an integer you can compare against, assuming you
> can figure
> out how to find the current date and time. However, this has
> one of the
> same shortcomings of the DATE scheme: the variable will only be
> updated when the .obj that contains it is recompiled. If you
> recompile
> and relink the rest of the driver without recompiling this file, the
> value will be old.

I’m probably biased but isn’t the only sane way how to release a driver
(or anything else) to rebuild it completely at the machine dedicated for
this task?

>> 2. Alex: “It’s easy to convert DATE and TIME into something
>> comparable to current time” If I use KdPrint it will simply
> print, I
>> need to store it permanently as build time seed in the driver. So I
>> guess something more like *g_pStringDate = DATE is closer? Also
>> how do you convert it to current time, are you referring to
>> TIME_FIELDS structure? IS there a function to do it, or do
> we simply
>> write one ourselves?
> You would have to parse it yourself.

I’m affraid it was a kind of question where the only good answer is: if
you have to ask, you’re probably unable to make it properly. Basic C
which is the prerequisite for any driver developer.

> What he’s saying is that the most obvious way to determine the build
> time of the .sys file is to go to the file system and check the
> modification time of the .sys file. He assumed that you
> would only ask
> your question if you were unable to do that.

I don’t think it is the most obvious way. It depends on the purpose. If
it is to make a time limited version which doesn’t allow user to load a
driver after some date, it is quite easy for user to change binary
timestamps and bypass it. Much easier than to hack binary and modify
built-in DATE expanded there (not impossible, thought).

> Is this supposed to be some kind of boneheaded security scheme?
> Wouldn’t it be much easier (and just as secure) to put a “number of
> times to load” count into the registry, decrement it each
> time you load,
> and refuse to load any more when the count goes to 0?

It is quite different scheme. OS can run for months without reboot and
driver can be loaded only once.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

> I’m affraid it was a kind of question where the only good answer is: if

you have to ask, you’re probably unable to make it properly. Basic C
which is the prerequisite for any driver developer.
I second that, OP, I’m sorry.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-325725-
xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, May 30, 2008 1:36 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] build details

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Friday, May 30, 2008 6:47 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] build details
>
> Now you have an integer you can compare against, assuming you
> can figure
> out how to find the current date and time. However, this has
> one of the
> same shortcomings of the DATE scheme: the variable will only be
> updated when the .obj that contains it is recompiled. If you
> recompile
> and relink the rest of the driver without recompiling this file, the
> value will be old.

I’m probably biased but isn’t the only sane way how to release a driver
(or anything else) to rebuild it completely at the machine dedicated
for
this task?

> > 2. Alex: “It’s easy to convert DATE and TIME into something
> > comparable to current time” If I use KdPrint it will simply
> print, I
> > need to store it permanently as build time seed in the driver. So I
> > guess something more like *g_pStringDate = DATE is closer? Also
> > how do you convert it to current time, are you referring to
> > TIME_FIELDS structure? IS there a function to do it, or do
> we simply
> > write one ourselves?
>
> You would have to parse it yourself.

I’m affraid it was a kind of question where the only good answer is: if
you have to ask, you’re probably unable to make it properly. Basic C
which is the prerequisite for any driver developer.

> What he’s saying is that the most obvious way to determine the build
> time of the .sys file is to go to the file system and check the
> modification time of the .sys file. He assumed that you
> would only ask
> your question if you were unable to do that.

I don’t think it is the most obvious way. It depends on the purpose. If
it is to make a time limited version which doesn’t allow user to load a
driver after some date, it is quite easy for user to change binary
timestamps and bypass it. Much easier than to hack binary and modify
built-in DATE expanded there (not impossible, thought).

> Is this supposed to be some kind of boneheaded security scheme?
> Wouldn’t it be much easier (and just as secure) to put a “number of
> times to load” count into the registry, decrement it each
> time you load,
> and refuse to load any more when the count goes to 0?

It is quite different scheme. OS can run for months without reboot and
driver can be loaded only once.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]


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