LOL. This is like a religious discussion now. Let’s come up with a
categorization of sins, from most heinous to most benign.
- Calling unexported, undocumented functions. Most of the people who
can figure out how to do this know how to make it work right when the
function is different or no longer works.
- Using undocumented data structures; people change data structures to
suit the changing needs of the OS.
- Using exported but undocumented functions. These do tend to change
less than most other functions. Within this category I generally think
“functions that are most heavily used are least likely to change”. What
happens instead is that someone replaces the function with a new
function (NtCreateFileExGoldProfessionalExtendedEdition2) that replaces
the old one, and the old one calls the new one.
I think the gist of much of the religious war here is that some people
seem to eschew doing things in the most documented fashion simply
because they CAN and make it work. I can demonstrate things I’ve had to
do that violate all of these rules at one time or another, although most
*NOT* in shipping product! Last month I needed to add some debugging
code to find APC Index mismatch problems. The issue is that there’s no
documented mechanism to retrieve the APC Index - and the OS reports
index mismatches is to bug check when the thread exits, which is
generally WAY too late. If you run the checked build it will do it on
exit of the system call, but even that can be too coarse when trying to
track down a problem of this type. So I came up with a way of finding
the APC disable field in an OS version independent fashion. But that
was DEBUG code. It doesn’t appear in production code.
Each of the cases you mention is familiar to me as well and those fall
into the category of “log a bug, work around the issue”. The
work-arounds have become less extreme over the years and we’ve been able
to get most of these problems resolved.
Finally, I don’t want to lose my point that if you know enough how to
make it FAIL gracefully, then you’re doing ok. But many of the
newcomers to this field do not have sufficient experience or insight to
know how to make it fail cleanly - they are struggling just to make it
work cleanly. Thus, we need to teach them the “right” way to do things
before we teach them that there are other, more nefarious black arts
that can be employed.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, August 08, 2005 2:39 PM
To: ntdev redirect
Subject: Re: SPAM-LOW: Re: SPAM-LOW: Re: SPAM-LOW: Re: Re:[ntdev]
Referencing a RegKey Object from handle
Tony, do you agree that using undocumented APis like
PsLookupProcessByProcessId is the least sin of all of this?
Very, very many undocumented functions do not change from NT4 to
2003
Server.
Also - sometimes it is impossible to do something without using the
undocumented function. For instance, before XP we had no SeIsTokenAdmin,
so, to
have this facility, the undocumented ZwQueryInformationToken was used.
Another task. GetProcAddress analog for the kernel mode. How to do
this
without using the undocumented functions (or the undocumented
DRIVER_OBJECT
field) to get the image base address?
I do not think that using undocumented functions “here and there” is
good.
But sometimes they are the only way.
Now about structures. I rememeber a nasty bug in NT4 where
STATUS_REPARSE
mechanism was not working at all for relative file opens. To bypass this
bug, I
needed to patch the Parse handler for the File object type. Any other
ways of
doing this, if the OS forgotten to clear the RelatedFileObject field in
some
internal structure passed from IoCreateFile to IopParseDevice on getting
STATUS_REPARSE from the stack?
Hooking and other kinds of patching is another song. Very, very
dangerous.
Using undocumented stable and well-known stuff at least gives us the
stable
code on this particular OS version.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “Tony Mason”
To: “Windows System Software Devs Interest List”
Sent: Monday, August 08, 2005 10:17 PM
Subject: RE: SPAM-LOW: Re: SPAM-LOW: Re: SPAM-LOW: Re: Re:[ntdev]
Referencing a
RegKey Object from handle
The best part about using undocumented APIs, relying upon internal data
structures, calling unexported functions, patching system call entry
point tables and overwriting existing code is that when it breaks on the
next service pack, security fix (reminder: tomorrow is Security
Tuesday!) or upgrade, is that the finger of blame will be pointed square
at MICROSOFT, not the original developer.
Remember: last component added that causes the break is blamed, guilty
or not!
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Monday, August 08, 2005 1:34 PM
To: ntdev redirect
Subject: RE: SPAM-LOW: Re: SPAM-LOW: Re: SPAM-LOW: Re: Re:[ntdev]
Referencing a RegKey Object from handle
Do you charge your customers for the update to fix the bug you
introduced by relying on an undocumented data structure? What do they
do when you’ve moved on from doing driver development? You’re handing a
time-bomb to every customer you give/sell this too - do you warn them
about this? Can they get their money back when it blows up?
As to verifying that a particular object pointer is a registry key - if
you’re getting the handle from user-mode you can call the Nt API to get
the same effect (as discussed earlier on this thread). If you’re
getting the handle from a kernel component there’s no reason to be
validating what it gives you.
The assumption that an undocumented function won’t change simply because
it hasn’t in the past is not a good one to make. If you really think
this is the path you have to go down, you should (a) inform your
customers of the risk you’re forcing them to take and (b) figure out
some mitigation strategy ahead of time - license your source code to
them as well, provide a way to turn off the bug-magnet you’ve added to
your driver so they can limp along when it breaks, etc…
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, August 08, 2005 9:09 AM
To: Windows System Software Devs Interest List
Subject: Re: SPAM-LOW: Re: SPAM-LOW: Re: SPAM-LOW: Re: Re:[ntdev]
Referencing a RegKey Object from handle
> I can’t believe this is even up for discussion.
>
> It hasn’t changed – YET. Do you want to bet on it never changing?
Do you
> want to bet on [random data structure X] never changing?
OK, I will create the new build of the binary to support the next
Windows
version 
is this bad?
> Show me a solid example of a common problem that you simply cannot
solve
> without relying on undocumented structures.
Verifying that this particular object pointer is a registry key.
BTW - using undocumented functions seems to be absolutely fine in most
cases
(especially in the cases when any other way is too complex).
For instance, PsLookupProcessByProcessId never changed since NT4. Some
of these
functions are documented in IFS kit why not copy-paste this
definition from
the IFS kit to my own source and build it? or just require ntifs.h for
building?
Sometimes using the undocumented stuff is really bad. NDIS internals,
for
instance, or EPROCESS - it is too huge and thus changes from SP to SP.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Fortunately, for me I can find my way inside your OS regardless you make