PDB matching and code signing

WINDBG
1

I’ve only recently started being exposed to having to sign code that
we’re building.

I have to assume that the modification / appended data introduced by
signing a binary is already well accounted for in the PDB matching
process.

At a guess, I would assume that the PDB matching isn’t affected
because the PE link time stamp is still the same & the fact that extra
data was appended is ignored.

Is the technology more complex than that (just for my own
edification), or are there other gotchas related to this
post-modification of the binary that are useful to know from a
debugging perspective?

Thanks.

Alan Adams

2

This whole subject (signing) is a very complicated, non-static, not
completely functional mess/pain in the ass. Mercifully, I have not had
to venture in to this yet (one of the perks of R&D, so I don’t know a
great deal. However, there are a ton of threads on this subject on this
list. If you’re looking for a place to start, I would check out the 2
(maybe three) articles by Peter of OSR at osronline.com. In addition to
sorting out what works and what doesn’t, et. c., at least one of these
articles contains links to the Microsoft overviews, which, if you’re
totally new to the subject, are probably the place to start.

As far as your specific question (PDB), I do not know the answer; it is
a possibility, but I would bet against it. Whatever the case, what you
state about time date stamp matching is not correct. PDB’s are not
matched by timedate stamps; they are matched by an internal UUID that is
located in the IMAGE_DEBUG_DIRECTORY in the PE and buried in an
undocumented (but well known) location in the PDB.

This (PDB) is the very end of the problem; there is a staggering amount
of procedure that comes before this issue, if it is in fact a problem.

This is the best I can do; you need to check out the archives,
osronline and/or the Microsoft articles.

mm

>> alanadams@dr.com 2006-11-06 16:17 >>>
I’ve only recently started being exposed to having to sign code that
we’re building.

I have to assume that the modification / appended data introduced by
signing a binary is already well accounted for in the PDB matching
process.

At a guess, I would assume that the PDB matching isn’t affected
because the PE link time stamp is still the same & the fact that extra
data was appended is ignored.

Is the technology more complex than that (just for my own
edification), or are there other gotchas related to this
post-modification of the binary that are useful to know from a
debugging perspective?

Thanks.

Alan Adams

You are currently subscribed to windbg as: xxxxx@evitechnology.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

3

“Martin O’Brien” wrote:

> This whole subject (signing) is a very complicated, non-static, not
> completely functional mess/pain in the ass.

Thanks for the references. I’m actually signing successfully at this
point, which is why I was finally able to venture on to look for any
other potential fallout. Not that signing itself is new, but I just
never had it happening on code where I was also the one producing the
.PDB file.

Sounds like .PDB matching is something I’ll have to go spend some more
time investigating too. The last I had investigated problems
(problems meaning that the URL SYMSRV would attempt wasn’t correct for
the path SYMSTORE had actually deemed the PDB should be saved on), I
thought I was seeing documentation to the effect of a time/date being
involved. Makes sense it would be more deterministic than that; I
just need to learn more. Thanks for the UUID hint.

Alan Adams

4

It used to be based on a timestamp in the VC6 era or so and was switch to a
GUID after that.

–
Ken Johnson (Skywing)
Windows SDK MVP
http://www.nynaeve.net

“Alan Adams” wrote in message news:xxxxx@windbg…
> “Martin O’Brien” wrote:
>
>> This whole subject (signing) is a very complicated, non-static, not
>> completely functional mess/pain in the ass.
>
> Thanks for the references. I’m actually signing successfully at this
> point, which is why I was finally able to venture on to look for any
> other potential fallout. Not that signing itself is new, but I just
> never had it happening on code where I was also the one producing the
> .PDB file.
>
> Sounds like .PDB matching is something I’ll have to go spend some more
> time investigating too. The last I had investigated problems
> (problems meaning that the URL SYMSRV would attempt wasn’t correct for
> the path SYMSTORE had actually deemed the PDB should be saved on), I
> thought I was seeing documentation to the effect of a time/date being
> involved. Makes sense it would be more deterministic than that; I
> just need to learn more. Thanks for the UUID hint.
>
> Alan Adams
>

5

“Skywing” wrote:

> It used to be based on a timestamp in the VC6 era or
> so and was switch to a GUID after that.

Well, there isn’t any code around here building with old tools like
that. Whoops, I mean “All of this code is building with old tools
like that…” :wink:

Indeed, I was trying to go back and push some of our old, disorganized
symbol files built with VS6 into a convenient SYMSRV.

But I didn’t have much luck because it seemed like 50% of the files
could never be found by SYMSRV clients. Had reached the suspicion
that it might have been because I lost time (seconds) resolution by
the .PDBs having been moved to and from FAT-compatible media, but had
to give up before being able to prove or disprove that.

Thanks for the additional info. Sounds like I’m going to find
SYMSRVing the output from the Vista WDK and SDK to be much smoother.

Alan Adams

6

Hello Adam. I didn’t see the beginning of this thread, but I might be
able to help you. Could you restate you original question?

.pat styles (msft)

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alan Adams
Sent: Monday, November 06, 2006 7:55 PM
To: Kernel Debugging Interest List
Subject: Re:[windbg] PDB matching and code signing

“Skywing” wrote:

> It used to be based on a timestamp in the VC6 era or
> so and was switch to a GUID after that.

Well, there isn’t any code around here building with old tools like
that. Whoops, I mean “All of this code is building with old tools
like that…” :wink:

Indeed, I was trying to go back and push some of our old, disorganized
symbol files built with VS6 into a convenient SYMSRV.

But I didn’t have much luck because it seemed like 50% of the files
could never be found by SYMSRV clients. Had reached the suspicion
that it might have been because I lost time (seconds) resolution by
the .PDBs having been moved to and from FAT-compatible media, but had
to give up before being able to prove or disprove that.

Thanks for the additional info. Sounds like I’m going to find
SYMSRVing the output from the Vista WDK and SDK to be much smoother.

Alan Adams

—
You are currently subscribed to windbg as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

7

Pat Styles wrote:

> Hello Adam. I didn’t see the beginning of this thread, but I might be
> able to help you. Could you restate you original question?

Thanks. The original question was actually in context of code
signing. I was wondering if there is any behavior I needed to be
aware of in having a .PDB successfully match up to a binary that has
been signed.

i.e. Does the modification of the binary post-LINK have any particular
ramification to being able to successfully match up the LINK-time .PDB
with the binary image later.

The question was then indirectly cracked into two logical parts: “What
effect might singing have on WinDBG / DbgEng being able to match a
.PDB to an image?”, and “What effect might signing have on SYMSRV /
SYMSTORE being able to store or get the correct .PDB or image?”

The most recent part you would have seen was my discussing how I had
not been successful in using the WinDBG 6.5.x SYMSTORE / SYMSRV to
organize a bunch of Visual Studio 6.0-era .PDBs. They all stored
“successfully” of course, but in 50% of the cases I tested SYMSRV did
not make a GET request that matched the path the PDB had actually been
stored on.

And I was suspecting, but had to abandon the project before proving,
that it might have been related to loss of time resolution by moving
the .PDBs to/from FAT-compatible media. (i.e. The 2-second rounding.)

Alan Adams