Hi,

Do you have any resources or docs about this? I looked and couldn't find any.

Hi,

Well this is a result of my own reverse engineering of the Asus drivers, that's why there are no resources about this. What do you need? I could tell you more about it.

A link to the driver or how to get it would help.

It's AsIO3.sys, used to be called AsusSAIO.sys.
AsIO3.zip

It's the Asus laptop kernel driver. Comes installed in all Asus laptops by default, as it's mostly used to log EC info alongside reading and writing to the EC by Asus's apps.

For now I obviously have to use winring for this which has been really horrible, but other than that I replicate the driver's behaviour for EC access and it's been really easy. I need this for an app I'm making.

You can see the ports being handled in the driver if you want:

I think you posted the wrong driver, there isn't a function at 140001734:

You're right, my bad.
AsusSAIO.zip

Here you go ^^

Function 140001828 is the handler for the read/write of the EC mailbox.

This is a tough one, this is the first driver I see that has any synchronization, with a proper KMUTANT even. How do you plan to handle cooperation with this driver?

Well, this worked perfectly for me and I've done multiple PoC's with it and tried it on many Asus laptops.. I write and read from the ports directly and handle the logic, I've also reverse engineered many Asus EC firmwares to confirm the endpoints are basically copy pasted. It doesn't need mutex as it's handled inside the EC, and the IBF and OBF. I even tried to spam write and was never able to cause any crashes as the EC will just return 0 if it's busy.

Any updates on this?

Apologies, I planned to look into what exactly the original driver needs (besides synchronization, for which I'll add a comment to avoid having the original driver loaded) to allow the ports, but haven't gotten around to do that yet.

Thanks a lot! I understand what you mean but yeah, theoratically I've tried all sorts of stress testing, e.g spam writing to the ports while another app was already writing to the ports via the driver while I was also accessing the EC through the 2e/2f (or 4e/4f) ports. So there's definitely an EC level hardware mutex as well, but putting a warning comment is better regardless.

By the way, I'm raising this so that G-Helper also gets access to these ports. Currently it uses the ports via the driver but it's bringing up too many issues, using these ports will make it so much better.