Dll injection from driver

NTDEV
21

Again, Dejan, I’m not sure I get your point. But… again… if I understand what yuo’re saying…

Let’s start out by establishing the fact that there are many different classes of “undocumented” solutions. Some are merely undocumented because, well, nobody’s ever gotten around to documenting them, or the usage cases are judged to be very narrow, the dev owner isn’t aware that anyone externally wants to use the function, or the dev owner of the function doesn’t want to document a function externally for his own reasons… BUT the use of the undocumented feature is such that it is well understood, widely used internally within Windows, and is likely to be – not guaranteed to be but merely likely to be – stable in the foreseeable future. Yes, I recognize this isn’t clear-cut and is a judgement call.

Using such features is edgy engineering… but it is occasionally necessary to take reasonable engineering risks when one needs to innovate. As long as the client understands the risks, and they judge those risks to be consistent with their business case, that’s all fine. I’m totally ready to help them.

OTOH, there is a DIFFERENT class of undocumented solutions/features/functions that amount to pure irresponsible hackery. Into this class I place using hard-coded offsets into structures, calling functions that are internal to a particular module (functions with KiXxxx prefixes are a reasonable example here), or manipulating “private” lists without appropriate serialization. This isn’t clever “edgy” engineering, it’s irresponsible, stupid, shitty engineering.

At my company, we draw the line at NOT doing irresponsible engineering in production software, regardless of how eager a client is for us to do so. And we tell such clients to go elsewhere and wish them good luck. If that client tells EVERYONE THEY KNOW that we told them to go elsewhere, I’m TOTALLY good with that. You know why? Because if we acquiesced, and then the irresponsibly engineered solution breaks, you can be SURE that such a client WILL tell EVERYONE THEY KNOW that we were the ones who were responsible for the ensuing cataclysm. And when some peer of mine looks at that code 5 years from now and sees that I was the one who wrote it, I’ll be embarrassed and ashamed of the work.

So, no, sorry. Irresponsible engineering can NOT be bought from my firm. I can’t BELIEVE it can be bought from ANY responsible professional consultant. By definition.

Who cares? Let them learn on some other list how to do shitty engineering. From some other shitty, irresponsible, engineer.

Peter
OSR

22

A lot of AV software (if not all) used the undocumented stuff that you would not. And I am not thinking of some 1.000.000 users only AV, but 100.000.000+ user base ones.
Bad engineering? Sure is. Nothing we can do about it.

Now let me ask you - if any of those breaks your DMK/FDDK customers’ solution, what would you do? Just say “it’s not our problem”?
It will work for a while, and then stop. There’s a lot of “do it fast” engineers coming out lately. I hope I am wrong, but I feel that’s the case.

Personally, I don’t do such solutions because I can do something else. But when it comes to a point where I can’t - I already doubt I will feel bad about doing them.

xxxxx@osr.com wrote:

Again, Dejan, I’m not sure I get your point. But… again… if I understand what yuo’re saying…

Let’s start out by establishing the fact that there are many different classes of “undocumented” solutions. Some are merely undocumented because, well, nobody’s ever gotten around to documenting them, or the usage cases are judged to be very narrow, the dev owner isn’t aware that anyone externally wants to use the function, or the dev owner of the function doesn’t want to document a function externally for his own reasons… BUT the use of the undocumented feature is such that it is well understood, widely used internally within Windows, and is likely to be – not guaranteed to be but merely likely to be – stable in the foreseeable future. Yes, I recognize this isn’t clear-cut and is a judgement call.

Using such features is edgy engineering… but it is occasionally necessary to take reasonable engineering risks when one needs to innovate. As long as the client understands the risks, and they judge those risks to be consistent with their business case, that’s all fine. I’m totally ready to help them.

OTOH, there is a DIFFERENT class of undocumented solutions/features/functions that amount to pure irresponsible hackery. Into this class I place using hard-coded offsets into structures, calling functions that are internal to a particular module (functions with KiXxxx prefixes are a reasonable example here), or manipulating “private” lists without appropriate serialization. This isn’t clever “edgy” engineering, it’s irresponsible, stupid, shitty engineering.

At my company, we draw the line at NOT doing irresponsible engineering in production software, regardless of how eager a client is for us to do so. And we tell such clients to go elsewhere and wish them good luck. If that client tells EVERYONE THEY KNOW that we told them to go elsewhere, I’m TOTALLY good with that. You know why? Because if we acquiesced, and then the irresponsibly engineered solution breaks, you can be SURE that such a client WILL tell EVERYONE THEY KNOW that we were the ones who were responsible for the ensuing cataclysm. And when some peer of mine looks at that code 5 years from now and sees that I was the one who wrote it, I’ll be embarrassed and ashamed of the work.

So, no, sorry. Irresponsible engineering can NOT be bought from my firm. I can’t BELIEVE it can be bought from ANY responsible professional consultant. By definition.

Who cares? Let them learn on some other list how to do shitty engineering. From some other shitty, irresponsible, engineer.

Peter

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

23

cheap solutions, cheap engineering.
sometimes you don’t have time to think all that things you should.
this is cost of solution.

24

You have never said what you are going to do with the injected DLL. At
this point one has to assume you don’t give a damm about good software
or else this is MALWARE.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:

> cheap solutions, cheap engineering.
> sometimes you don’t have time to think all that things you should.
> this is cost of solution.

25

What you are proposing is neither a solution, nor engineering; it’s better termed “butchery”. Cheap??? Highly unlikely since it can lead to costly efforts to unscrew what you propose screwing, simply because of minor changes in legitimate and agnostic code.

Gary G. Little

----- Original Message -----
From: xxxxx@hotmail.com
To: “Windows System Software Devs Interest List”
Sent: Thursday, July 28, 2011 6:15:06 AM
Subject: RE:[ntdev] Dll injection from driver

cheap solutions, cheap engineering.
sometimes you don’t have time to think all that things you should.
this is cost of solution.

—
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

26

ANYtime our clients have an interoperability problem when using our software we:

  1. Attempt to design a good engineering work around to assist the client and their customers in the most timely fashion possible. However, these work-around do not use irresponsible, shitty engineering. As previously stated, we will not do that type of engineering at my firm.

  2. Attempt to reproduce the problem on a system where our toolkit (DMK/FSDK/FDDK/etc) is not running.

  3. Attempt to collaboratively work with the vendor and/or Microsoft to correctly FIX the root cause of the problem. We find the vast majority of vendors happy, even eager, to find a solution that allows their products to co-exist with those built by our clients using our toolkits.

If none of the above works, which is very very rare, and the problem is demonstrably the result of a bug or shitty engineering in the 3rd party product, then… YES. We say “It’s not our problem.”

Peter
OSR

27

i need to know what files, registry keys and other objects processes have open, which DLLs they have loaded, which handles are opened etc.

yep, i am new to kernel developing. i think i would not find solution here.
maybe, i am shitty engineer…

28

> [quote]

Now let me ask you - if any of those breaks your DMK/FDDK customers’
solution, what would you do? Just say “it’s not our problem”?
[/quote]

ANYtime our clients have an interoperability problem when using our software we:

  1. Attempt to design a good engineering work around to assist the client and their customers in the most timely fashion possible. However, these work-around do not use irresponsible, shitty engineering. As previously stated, we will not do that type of engineering at my firm.

Wasn’t suggesting that, rather:

  1. Attempt to reproduce the problem on a system where our toolkit (DMK/FSDK/FDDK/etc) is not running.

So? If your software cannot coexist with an antivirus, your software is at fault - always. (not yours in particular, I mean this is is how any big company or development company thinks - AV is required. You have to coexist with it!)
In the end run, if an AV breaks your software, at most you can talk to the AV guys to see if they are going to change what broke your software, or entice them to change it. You have to make a workaround otherwise.
Now, I am not suggesting that you do cheap engineering here, rather big guys are doing it, and you have to work around it.

Not sure how many people remember, but one of the biggest AV names had a filter which kicked every previous filter out of the filter stack because they incorrectly called IoAttachDevice. Even broke FltMgr. It was lucky that it hit MS drivers also, otherwise, I doubt they’d
bother changing it :slight_smile:

Cheap engineering is all around us, we have to accept it. If we don’t have to do it, it’s awesome. But IMO, it will come up more and more often, and eventually, we’ll have to do it :frowning:
Just look at the amount of silly questions on the list lately. One would think that at least people would search for “prevent file copy” before asking it the third time this week :slight_smile: And that is an extremely simple one.

  1. Attempt to collaboratively work with the vendor and/or Microsoft to correctly FIX the root cause of the problem. We find the vast majority of vendors happy, even eager, to find a solution that allows their products to co-exist with those built by our clients using our toolkits.

That works great with most western companies. I guess you did not have much touch with non-western ones then, because my experience (and I worked at a big S. Korean name at the time) is quite the opposite - unless their bug hurts them in a way (not working with out solution is
not counted as such), they won’t bother much.

If none of the above works, which is very very rare, and the problem is demonstrably the result of a bug or shitty engineering in the 3rd party product, then… YES. We say “It’s not our problem.”

If the product is an AV and your product doesn’t work with it (because of the AV), you don’t care? (i.e. don’t do anything?). Wow. I wish I could have that luxury :frowning:

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

29

There are standard ways in the kernel to do most of these:

Files - a file system filter driver will handle this well
Registry - the CmRegisterCallback function and its related functions can
give you this data

For the other objects, it depends on which ones you care about.

DLL - PsSetLoadImageNotify provides a callback to record this.

So the answer is you are likely not to need any DLL injection to get the
information you want. I refer you to the Peter Pontification on asking
questions.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:

> i need to know what files, registry keys and other objects processes have open, which DLLs they have loaded, which handles are opened etc.
>
> yep, i am new to kernel developing. i think i would not find solution here.
> maybe, i am shitty engineer…

30

Disagree.

We don’t have to accept it, and we don’t have to do it. Accepting it results in a race to the bottom. Doing it is a violation of professional responsibility and ethics, and just results in an “arms race” over who can do the shittiest engineering.

You would guess wrong.

If an AV product and a client’s product that uses one of our toolkits cannot co-exist because the AV product demonstrably has a bug or uses shitty engineering, and the AV company won’t fix it, and there’s no good engineering workaround? I *care*… but I won’t fix it by resorting to a shittier engineering hack.

To me, Mr. Maksimovic, it’s about having professional standards and integrity.

I think as professional engineers, and leaders in the community, we OWE our clients, their end-user customers, and the community of our peers adherence to reasonable set of standards. Where each professional draws the line will be a matter for them to determine.

I’m not saying there’s NOTHING that’ll get me to violate my standards, but I sure as hell don’t sell my company’s integrity for the price of a toolkit.

I’m done discussing this topic.

Peter
OSR

31

another method is to use PostProcessInitRoutine from PEB.
http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/7cc3f741-91d1-4633-8999-e75ba2a5b7fd

32

HAVE YOU EVEN TAKEN A MINUTE TO EVALUATE WHETHER YOU REALLY NEED THIS
TYPE OF SHIT PROGRAMMING!!! You gave a list of things you wanted to
do with the DLL, and there were suggestions on how to do this without
injecting a DLL. If there were problems with the suggestions or other
needs not covered a responsible individual would have stated this. You
on the other hand keep driving ahead with an approach that is at best
poor and from there goes quickly to malicious. Please go read
http://www.osronline.com/article.cfm?article=575 since you are still
trying to make this pig fly.

Don Burn
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr

“xxxxx@hotmail.com” wrote in message
news:xxxxx@ntdev:

> another method is to use PostProcessInitRoutine from PEB.
> http://social.msdn.microsoft.com/Forums/en-US/wdk/thread/7cc3f741-91d1-4633-8999-e75ba2a5b7fd

33

An injected DLL operates in an untrusted space, anyway, and any data about possible hostile code it might be able to gather can not be trusted. The hostile code will just hack around it. That’s it.

34

> i need to know what files, registry keys and other objects processes have open, which DLLs

they have loaded, which handles are opened etc.

You don’t seem to need a driver here, in the first place…

Basically, you want to spy on all processes in the system. This part, is indeed, best done with DLL injection so that you can spy on win32 calls. However, you should do it from the user mode so that it is perfectly “supported” solution…

Anton Bassov

35

I am not sure what DLL injection has to do with this question. But first,
I’d suggest reading Gary Nebbit’s “Windows NT/2000 Native API Reference”.
Note that on the whole, using undocumented interfaces is risky, but I can
find a lot of information without using either the native interfaces or
kernel programming. Look at APIs like GetModuleFileName, or go to
EnumProcesses and click on the link for “Enumerating all modules for a
process”. With the undocumented API, you can find out information about
Registry keys, what handles are active, etc. Since you have not described
your actual need, and use the phrase “etc” which means “A whole whopping lot
of stuff I am too lazy to describe in useful detail”, I have no idea how to
identify APIs that might be useful, but try searching under GetProcessEtc()
to see if that helps. It probably won’t, but that’s the best answer I can
give if all you can ask is something that uses “etc” as if it is a useful
description.

At no point in any of this do I see any need for DLL injection, so I fail to
understand why DLL injection of anything, anywhere, let alone from the
kernel, has any relevance to your question. Perhaps if you asked a useful
question, you might get a useful answer.

Why do you think that ordinary, already-defined APIs are insufficient for
your needs? Why do you assume you have to do kernel programming? There
might actually be reasons, but you seem to have latched onto some weird idea
that the only way to locate this information is by kernel programming, and
then you wander off into even weirder domains, such as the idea of injecting
a DLL from a driver, without having justified the need to do so.

So first, identify all the user-level APIs that would be useful for this.
Explain why they are inadequate (note: this proves you have actually
bothered to study what is available, and have valid grounds for rejecting
these solutions). Then, read Nebbit’s book. Explain why using the Win32
native interface (risky though it may be) is insufficient for your needs.
Only then would concepts like injecting DLLs (and it is not clear why you
need to do this from a driver) might be relevant. Then explain why the
mechanisms that were introduced by Vista, such as integrity levels, are
something that you feel you can reasonably justify violating.

For example, demonstrate that you have examined the ToolHelp library,
EnumProcesses, EnumProcessModules, and have grounds for rejecting these.

You haven’t even explained your goals. Why should any of this matter? What
problem do you think you are solving by obtaining this information? Also,
why are the Process Explorer or Process Monitor from www.sysinternals.com
inadequate? If we know what problem you are trying to solve, we might have
a clue as to what the solution looks like. And vague handwaves about “etc”
don’t even describe what you want, let alone *why* you need the information.

You are a considerable distance from having asked an answerable question or
justifying anyone wasting time to answer such a silly, vague question.

Don Burn pointed you at Peter’s guidelines for asking questions. Unless you
can answer my questions, I am going to have to assume you are just totally
clueless, both in terms of understanding what is actually available from
user space and in how to ask a question.

[I regularly get trashed in some of the newsgroups I participate in for beating up people who ask silly questions, and I’m not nearly as blunt as Peter has been. Let’s just say that he \*understates\* the annoyance we feel when we see questions like yours]
joe

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Thursday, July 28, 2011 11:39 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Dll injection from driver

i need to know what files, registry keys and other objects processes have
open, which DLLs they have loaded, which handles are opened etc.

yep, i am new to kernel developing. i think i would not find solution here.
maybe, i am shitty engineer…

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