Bluetooth Filter Driver for DS3-compatibility - research notes
-
Thank you very much for the effort you're putting into this project. I can't wait for the beta to be released and being able to use both bluetooth audio and my trusty
Vault 13 canteenDS3 controller. Should you need testers, please count me in.
-
@nefarius any news?
-
Dear me, it's been a month! Time to see if the sources still compile
-
Alright, until the next demo is ready I shall at least write down a little To-Do kind of list of open topics
Profile driver
Auto-disconnect on buffer overrun threshold
I've seen that the Bluetooth sub-system keeps all input reports buffered if they're not "consumed" by the profile or function driver which could lead to non-pageable memory exhaustion in case of a bug where the function driver stops consuming and inherently emptying the buffer. I plan on realizing that with a buffer size threshold value of a few kilobytes which, when exceeded, will drop the connection of the controller as there is no "stop sending input reports" command to my knowledge. This protection mechanism should be part of the profile/bus driver as it is the last bastion to system stability
Same for the control endpoint if the "OK bytes" are forgotten to be consumed. Running out of precious non-pageable memory has to be avoided at all costs
Harden (dis-)connect state machine
The state machine is almost a 100% finished, I didn't cover a few edge-cases I can't test because I would need to introduce radio connection errors which I can't without the proper equipment, although should implement fallback paths so the driver won't end up in an unknown state and cause hangs or orphaned objects. Again, no open paths allowed in kernel land. They will bite back one day
Filter driver
This little fella basically works well but needs attention.
Add sideband channel
A filter can't be directly accessed to e.g. send it configuration changes. Therefore a sideband channel or control device object has to be introduced. This is a very good template to base it upon. The control object will be protected by ACLs only allowing administrative users access to protect against abuse.
SDDL_DEVOBJ_SYS_ALL_ADM_ALLsounds right for this purpose (context).Add support for multiple radios
The current assumption is that there's only one radio to work with. In a real world scenario this may be false since multiple "filter-able" Bluetooth host radio devices may be present. Therefore the filter should - in conjunction with the sideband mechanism - keep a reference to every device it's attached to and provide some sort of identification (bus serial, name, etc.). This will also impact the way the filter can be configured.
User-land configuration
It should be convenient for the end-user to enable or disable the drivers patching capabilities during runtime without the need of unloading the filter or having to re-plug or re-enable any devices. Some simple IOCTLs should be introduced for the sideband channel which can then be sent by a simple GUI tool. The driver should then store the state change in the according registry sections it can access (Hardware key sounds like the right place).
User-land tool for control
I plan on providing a simple C#-based tool which displays the available filtered radios with some basic information and some toggle switches to enable or disable PSM patching on the fly and other possible useful information which might come up (host radio MAC address for easy pairing access for example or entirely integrate PS3 pairing).
Setup tools
The recent discoveries of the ViGEm.Setup toolset may certainly benefit this project as well. Maybe portions of
BthPS3Utilshould/could be ported to WiX custom action
Shibari/Function driver
Not entirely sure if I should continue/publish my Shibari hack which already makes this stack usable. Proper function drivers should be the end goal but those will once again eat quite a bit of time as well. We'll see about that.
So far so good, will ramp up the pace again soon.
Cheers
-
About to test the latest filter modifications (added sideband code), here we go again
Bless you, VMware
That's quite quick, RAM-cached hard disk provides quite the I/O
-
And we have a Desktop, that install only took 5 minutes
-
Oh, this if funny, I thought I've checked this already but apparently not; it's not possible to have two (or more) USB Bluetooth host dongles active at the same time
Windows 8.1
Windows 10
Well, that's good to know but hasn't interfered with anything I've implemented today because I wanted to have the capability of storing device-specific settings through a control device anyway. So I guess this is true
-
Phew, everything still works after my mayhem
And on a completely fresh machine as well!
Time for a game and/or slumber
-
Alright, breakfast is done, back to work
Looks like disabling the patching is working as expected:2019/05/18-11:29:22.504 TRACE_LEVEL_VERBOSE UrbFunctionBulkInTransferCompleted Entry 2019/05/18-11:29:22.504 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-11:29:22.504 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-11:29:22.504 TRACE_LEVEL_VERBOSE >> Bulk IN transfer (PipeHandle: FFFFE000E7133D20) 2019/05/18-11:29:22.504 TRACE_LEVEL_VERBOSE UrbFunctionBulkInTransferCompleted Exit 2019/05/18-11:29:23.355 TRACE_LEVEL_VERBOSE UrbFunctionBulkInTransferCompleted Entry 2019/05/18-11:29:23.355 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-11:29:23.355 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-11:29:23.356 TRACE_LEVEL_VERBOSE >> Bulk IN transfer (PipeHandle: FFFFE000E7133D20) 2019/05/18-11:29:23.356 TRACE_LEVEL_VERBOSE UrbFunctionBulkInTransferCompleted ExitNow onto making it dynamically changeable and storing it in the registry to make it survive device power cycling.
-
Wait a minute...
After the first few denied connection requests when the controller shuts off and I retry to connect it there are no more requests flowing through the filter 
Is this due to VMware? I don't think so... Hm, that sure is surprising me, I thought the host controller driver always has to be contacted in case of a new connection request but apparently it's cached in the actual chip somehow. Well, there goes my fabulous plan of making it dynamically configurable
I'll do a bit more testing and if I can't get it to work I'll simply rip out the control device again (was a good practice anyway) and introduce two
Parametersregistry values to globally control the patching. Taking a few steps back and not over-complicating things. There's other stuff in the pipeline
-
Hm, somehow VMware is not happy at all with what I'm doing, I'll now switch over to a physical machine and see how it's going there.
-
Aha! Deception! It actually was VMware!
On a physical Windows 10 machine it works flawlessly like expected even with a 5 meter USB repeater:Test with Nav Controller
--------------------------- Pressed PS button --------------------------- 2019/05/18-12:40:54.722 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:40:54.722 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:41:13.495 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:41:13.495 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:41:32.280 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:41:32.280 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:41:51.049 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:41:51.049 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM --------------------------- Pressed PS button --------------------------- 2019/05/18-12:42:55.355 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:42:55.355 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:43:14.135 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:43:14.135 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:43:32.912 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:43:32.912 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:43:51.675 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:43:51.675 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSMTest with DS3 Controller
--------------------------- Pressed PS button --------------------------- 2019/05/18-12:46:10.193 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:46:10.193 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:46:28.964 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:46:28.964 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:46:47.736 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:46:47.736 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:47:06.502 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:47:06.502 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM --------------------------- Pressed PS button --------------------------- 2019/05/18-12:48:06.959 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:48:06.959 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:48:25.733 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:48:25.733 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:48:44.510 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:48:44.510 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:49:03.293 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:49:03.293 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM --------------------------- Pressed PS button --------------------------- 2019/05/18-12:50:40.865 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:50:40.865 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:50:59.650 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:50:59.650 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:51:18.423 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:51:18.423 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-12:51:37.183 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-12:51:37.183 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSMAs you can see the controller tries for a total of 4 times to connect to the host its programmed to before giving up and shutting off. When I press the PS button again to wake it up within the same session the requests arrive again (and get blocked because patching is disabled in this example) as expected. Good stuff!
Now that I know I'm not entirely bonkers it's time to define some IOCTLs for the control channel. And some coffee
-
Good progress so far
Time for a break and go for a little cycling tour 
while the weather is this nice 
-
Oooopsie...
Mistake identified, copypasted a variable which in this case isn't initialized, argh!
-
Ha, there we go!
Let's go for a test:
2019/05/18-19:09:31.570 TRACE_LEVEL_INFORMATION BthPS3PSM_SidebandIoDeviceControl Entry 2019/05/18-19:09:31.570 TRACE_LEVEL_VERBOSE PSM patch disabled for device 0 2019/05/18-19:09:31.570 TRACE_LEVEL_INFORMATION BthPS3PSM_SidebandIoDeviceControl Exit 2019/05/18-19:09:36.919 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-19:09:36.919 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-19:09:55.703 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-19:09:55.703 TRACE_LEVEL_VERBOSE -- NOT Patching HID Control PSM 2019/05/18-19:09:57.801 TRACE_LEVEL_INFORMATION BthPS3PSM_SidebandIoDeviceControl Entry 2019/05/18-19:09:57.801 TRACE_LEVEL_VERBOSE PSM patch enabled for device 0 2019/05/18-19:09:57.801 TRACE_LEVEL_INFORMATION BthPS3PSM_SidebandIoDeviceControl Exit 2019/05/18-19:10:14.487 TRACE_LEVEL_VERBOSE >> Connection request for HID Control PSM 0x0011 arrived 2019/05/18-19:10:14.487 TRACE_LEVEL_INFORMATION ++ Patching HID Control PSM to 0x5053 2019/05/18-19:10:14.877 TRACE_LEVEL_VERBOSE >> Connection request for HID Interrupt PSM 0x0013 arrived 2019/05/18-19:10:14.877 TRACE_LEVEL_INFORMATION ++ Patching HID Interrupt PSM to 0x5055Splendid!
-
Storing and loading settings implemented, that will be all for today
-
One more command
Now off to important things
-
BthPS3 + Shibari Demo with Nav and DS3 Controller [19.05.2019]
It's time for another video
I wanted to see if everything still works after the latest rework and so far everything's looking fine, also performance is stellar, even through Shibari which has to go from kernel to user to kernel context many times per second I notice no input lag whatsoever.Next I'll implement the buffer overrun protection.
-
@nefarius It looks great! I'm looking forward to testing this myself, keep up the good work!
-
@enricorov I still need a strategy on how to involve testers without unfinished binaries spreading...
