Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Best Of
Re: why Task Manager can kill my protected process easily?
the short answer is, don't try to do this. If I am admin or have physical access to the system, there is nothing you can do except delay and frustrate me. I can always press the power button to terminate your process. and prevent it from running again by deleting the .sys / .exe files from another OS.
non-admin users can't terminate service processes because of simple ACL checks. So this is malware
MBond2
Re: Disable USB-C ports
What ready product would you recommend?
Most of so called "endpoint security" products have some kind of USB control.
I haven't used this stuff recently (concur with Mr. Roberts on products that exist to tamper with normal operation of my Windows system)
If you find the freedesktop link interesting, the maintainers of this thing are on this forum. They may be able to help you.
-- pa
Pavel_A
Re: Easiest way to find the type of storage port driver?
That doesn't help find the port for a given miniport. A port/miniport pair share a single FDO.
Re: Network data transfers to/from user mode
seems like a much simpler approach than issuing & pending requests for buffer access
Really? I mean... that's just ordinary Windows user-mode talks to a driver stuff, isn't it??
Sending stuff to/from KM via Sockets? You COULD... but, isn't that what ReadFile and WriteFile are for? I dunno... I probably shouldn't get involved in this thread. I haven't understood anything, including the first post. Your apps sends reads. Your driver puts those reads on a queue. When you have data, you use that data to satisfy the read. Heck, the students in my KMDF seminar do that by Thursday afternoon, never having written a Windows driver before. What am I missing?
Peter
Re: Network data transfers to/from user mode
This has GOT to be the world's most confusing, over engineered, thread.
If the idea is to "glue" the output of Software A (which sends data via Sockets) to Software B (which receives data via sockets)... and for some reason they can't talk directly to each other (hmmm... OK? They talk using different ports or something, I GUESS)... Then, write a user-mode sockets program that gets stuff from A and sends it to B, and your done.
Like I said... I should so stay out of this thread. I just don't understand any of this.
ETA:
Gad! I'm not insane! I see that Mr. Roberts said exactly this, some days ago:
write a very simple this-to-that that listens on port A and writes to port B? That's about 10 lines of Python code.
Peter
Re: Help with design decision (using sysvad virtual driver as base)
Virtual Audio Cable certainly lets you route sound from Skype to another user-mode application. That doesn't "replace ioctl", that eliminates the entire need for a custom driver. It becomes the boxes in blue up above.
Re: Disable USB-C ports
The best scenario (if possible): the user plugs any device - it won't even power on
Disabling USP ports or specific devices/classes is a quite common need (as Peter noted), so you can google around and find a ready solution for this. Get it right now, no development & testing time, no bluescreens.
The type C, however, is a less familiar point. Is there a requirement specific for type C? Like, disable high-power charging from the port (without any i/o at all)?
-- pa
Pavel_A
Re: Disable USB-C ports
I think I must have missed something, but is this all devices on a particular port, or particular devices (inclusively or exclusively) on any port?
the viability of any solution on any os depends to a great extent on these answers i think
MBond2
Re: Disable USB-C ports
There are examples of hub access from usermode, based IIRC on some Intel's example from WinXP times.
Some classes of devices can be disabled by Windows group policy - no coding needed at all.
For useful start in USB hub filtering, see here: https://github.com/freedesktop/spice-usbdk
Sorry I cannot share code from commercial projects. In the linuxy opensourcey world, when they make anything, they put it on GitHub and write a dozen blogs and tweets. Not so in Windows.
Again, consider a ready product. Reinventing a wheel is not cool. If the UI needs customization, maybe they can do that.
Unless, there's some special new type C quirk - as type C connector is more than USB.
-- pa
Pavel_A
Re: Disable USB-C ports
Peter gave a good answer, much better than my snarky one. I happen to have a particular aversion to driver projects whose primary aim is to PREVENT the normal operation of my Windows system, as yours is, so my sarcasm boils to the surface.
The problem with selective suspend is that it is managed by the hub driver, based on the current state of the system and its child devices. There's no way for you to interfere in its decision process. If you tried to force a port into selective suspend, the hub driver would stubbornly put things back.
However, the PORT_POWER thing is a possibility. You can shut down individual ports that way. I'm not sure it would survive sleep/resume, but that's an issue you could work on. Most hubs can be addressed from user mode; I'm not sure you'd even need a driver. Look, for example, at the USBView sample app. It communicates directly with the hubs to get the information it needs.