Power Driver Reverse Engineering

Hello list,

I apologize for another open ended question. This is supposed to be
about best practices and workflow, not about how to take RE in general
(which I doubt anyone would want to inform me of on this list).

My goal is to reverse engineer power drivers. Without starting with
working code, it is hard to discover all facets of a device’s power
interface. Luckily, reverse engineering for interoperability’s sake is
not covered by IP and patent law.

I believe I asked a question in this vein before and received some
useful information. However, I can’t find those posts and what I
remember was being told to install filter drivers to receive power
events. I apologize if I am wasting anyone’s time twice.

This gives me a good starting place - if I know when the power events
are happening I know when to look for the other events, and can pause
the system momentarily (per my understanding) to record those events.
But the other crucial information is what those events actually are.

The simplest option seems to hook *every* interface over which power
events could be sent, but I do not know the list of all such
interfaces, or, better, a more convenient way of hooking all of them.

Then, once I have that information, how do I decide which traffic is
power events? Compare timestamps to the time I received power events
on my filter driver? Are power events marked in any way? I certainly
expect the contents of the events to vary considerably between
devices.

Cheers,
R0b0t1

I?m afraid I don?t understand your question. What do YOU mean by the phrase ?power driver?? What is it, very specifically, that you are trying to learn or understand?

Peter
OSR
@OSRDrivers

P.S. Bravo for understanding the ?safe harbor? about careful observation of the external behavior of a system for the purposes of achieving interoperability. This is a US-specific carve out, please note.

On Sat, Apr 21, 2018 at 5:20 PM, xxxxx@osr.com wrote:
> I?m afraid I don?t understand your question. What do YOU mean by the phrase ?power driver?? What is it, very specifically, that you are trying to learn or understand?
>

Ah, sorry - I mean the power aspects of ordinary drivers. I’m not sure
how I confused myself.

Basically, the issue is that while the main functionality of most
drivers will eventually be gotten working on alternative operating
systems, the power management very rarely, if ever, is, so there are
stupendously shortened battery lifetimes.

Most of these systems are x86 so I might be able to track hardware
access from outside of the OS, in a hypervisor, but it seems cleanest
to monitor these events from within the OS if possible.

Cheers,
R0b0t1

> Peter
> OSR
> @OSRDrivers
>
> P.S. Bravo for understanding the ?safe harbor? about careful observation of the external behavior of a system for the purposes of achieving interoperability. This is a US-specific carve out, please note.
>

P.S. The exemption may be codified only in the US, but I think the
alternative, where it does not exist, leads to some ridiculous
situations. For example - if I make a system which processes
biological samples, and it contains trademarked and patented
technology, but I sell it to someone who disconnects half of it and
connects it to something else - can I really go after them for
something? What? How would I even know they did it?

> I mean the power aspects of ordinary drivers

Ah, so… In WDM (the basic interface in the Windows I/O Subsystem) power operations are models as I/O operations. So… there are IRPs sent for each potential power operation, and those IRPs have the major function code IRP_MJ_POWER.

If you look at the WDK sections starting with “Power Management for Windows Drivers” (Google this) you’ll get a long and incredibly description of what goes on with Power in Windows. The problem with this, like a lot of the MSDN documentation, is that it is so very detailed and task-oriented. if you don’t understand the overall power model that Windows uses to begin with, the overall flow of control, it can be very hard to wade through the vast sea of “IRP_MN_QUERY” this and “IRP_MN_SET” that…

Peter
OSR
@OSRDrivers