Bluetooth Filter Driver for DS3-compatibility - research notes



  • Let's welcome this new week by finishing a major bug fix: properly hardening the shutdown sequence to disconnect remote devices and free resources afterwards 🀠

    972d30ca-3706-4250-832d-f6d3d84ad145-image.png

    Now entering hibernation πŸ’€



  • @nefarius said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    Now entering hibernation πŸ’€

    I really liked that one πŸ˜‚ I registered to the forum just to reply to this...

    Now getting serious, I've been following this topic, let me tell you that is awesome. I was a programmer myself when I was young, like 20 years ago, nothing like this, mostly enterprise application, databases and stuff, so I have a fair idea of the whole development process thing. This thread has been very interesting to follow, I didn't know how many things got involved in developing drivers and stuff related to hardware, very interesting.
    Also, your previous post about hunting the bug related to the crash when device got disabled, it got me thinking in other things that could happen that could be related...

    What happens when

    1. The controller is moved out of range of the bluetooth receiver
    2. The bluetooth receiver is disabled in the Device Manager (eg. if the receiver is embedded in a wifi card like the Intel ones on laptops)
    3. The bluetooth receiver is disconnected from the host (eg. the receiver it's a USB dongle type)
    4. If the controller get connected to host via USB cable while operating/connected via Bluetooth protocol, do it still operates or got it disconnected???
    5. Does the controller start to charge its internal battery when is connected to host via USB cable?

    I'm sure you already considered this scenarios, but I got curious about the answer to this events.
    Anyway, let thank your for your effort in this, I really appreciate it.
    It's really amazing to see that somebody got the time, knowledge and motivation to write this. In other OS like linux, this works out-of-the-box, also on NVidia Shield TV, but on windows it's disappointing to have to resort to third-party solutions to be able use our gamepads properly.

    Also, what is the HARDWARE id that get reported to OS when the PS3 controllers are connected via this driver?



  • @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    Now getting serious, I've been following this topic, let me tell you that is awesome. I was a programmer myself when I was young, like 20 years ago, nothing like this, mostly enterprise application, databases and stuff, so I have a fair idea of the whole development process thing. This thread has been very interesting to follow, I didn't know how many things got involved in developing drivers and stuff related to hardware, very interesting.

    Welcome, mate πŸ™‚ I've been trying to steer my career towards programming as a full-time profession but so far that hasn't really worked so I went back to doing everything the way I like and devote time to device driver development. Not my loss so far 😝 I struggled a lot in the past while developing the other projects and found this style of "blogging" to be a good way to both reflect on what I've been doing and as a reference and timeline for myself and other people interested. Sounds like it's a good strategy.

    @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    Also, your previous post about hunting the bug related to the crash when device got disabled, it got me thinking in other things that could happen that could be related...
    What happens when

    Thanks for participating, let's go through the points one by one:

    @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    The controller is moved out of range of the bluetooth receiver

    Then after a certain timeout the host driver (the one which controls the Bluetooth host device, a.k.a. "stock driver") will initiate a disconnect sequence and notifies the profile driver that the device is gone and now my clean-up code takes over. So far this case is handled properly. Should test it though πŸ€”

    @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    The bluetooth receiver is disabled in the Device Manager (eg. if the receiver is embedded in a wifi card like the Intel ones on laptops)

    That's a typical power down event and since the profile driver is a child of the bthport.sys which then gets unloaded it receives shutdown indication as well and needs to dispose all connections and free memory before unloading the profile driver. So far this is handled already.

    @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    The bluetooth receiver is disconnected from the host (eg. the receiver it's a USB dongle type)

    This case is called "surprise removal" and is also handled. When the parent is gone, the whole stack gets demolished. The profile children (PDOs) get removed, the profile driver enters clean-up and unloads, then the stock drivers unload. This is also implemented and tested.

    @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    If the controller get connected to host via USB cable while operating/connected via Bluetooth protocol, do it still operates or got it disconnected???

    This is in fact an absurd case because the SIXAXIS/DS3 does not disconnect from Bluetooth when connected to USB while also connected wireless. That's a scenario I haven't tackled yet ❗

    @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    Does the controller start to charge its internal battery when is connected to host via USB cable?

    Yes, despite all the BS and false information you find on the web there is no special driver required for the controller to charge via a standard 500 mA USB outlet. It also charges with a simple mobile phone charger, if it doesn't it has a hardware issue, not a software one. It does report battery charge level via software though on both USB and Bluetooth.

    @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    I'm sure you already considered this scenarios, but I got curious about the answer to this events.

    I try to think of all aspects, especially because I wanna get this through WHQL so the quality and robustness has to be stellar πŸ˜‰

    @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    Anyway, let thank your for your effort in this, I really appreciate it.
    It's really amazing to see that somebody got the time, knowledge and motivation to write this. In other OS like linux, this works out-of-the-box, also on NVidia Shield TV, but on windows it's disappointing to have to resort to third-party solutions to be able use our gamepads properly.

    Thanks, I might have just slipped into insanity without noticing πŸ˜† Seriously though, it's been quite the challenge getting this and real-life obstacles handled in one go but as I'm adapting my life to support this stuff I might be able to keep this rodeo going until production-ready πŸ˜… Linux has the advantage of the open kernel and contributors have added the Sony-specific customization a long time ago. On Windows you need to play after the rules of Microsoft. And dance with the devil in kernel-land where the forbidden fruits grow and magic can be found even to this day!

    @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    Also, what is the HARDWARE id that get reported to OS when the PS3 controllers are connected via this driver?

    I created some custom, GUID-based Hardware IDs the function drivers will use in the future.

    Hope I got everything, cheers!



  • @nefarius said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    Hope I got everything, cheers!

    Wow, I'm really impressed... I'm pretty sure that I'm going to use this driver when it get released intro production.
    I only regret having bought a Mayflash Wireless Adapter like 3-4 months ago to use my SIXAXIS/DS3 wireless without having to sacrifice the bluetooth receiver on a PC that I use to play retro games. πŸ˜… I needed to use a wireless headphones to play at night, so that's why I needed the bluetooth device on the host working with standard drivers (not dedicated to just the controller), to be able to connect the headphones... you know, I didn't want the wife to be mad at me for being playing games at night.... πŸ˜’

    I forgot to ask... how is going to be the process to pair the controller with the host receiver? I don't remember exactly, but in the old days of ScpToolkit and Motioninjoy there was a small utility to set the host's bluetooth mac to which the controller should connect when the user pressed the PS button... please correct me if I'm wrong... how is going to be now?



  • @pnkiller78 said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    I forgot to ask... how is going to be the process to pair the controller with the host receiver? I don't remember exactly, but in the old days of ScpToolkit and Motioninjoy there was a small utility to set the host's bluetooth mac to which the controller should connect when the user pressed the PS button... please correct me if I'm wrong... how is going to be now?

    That's still the same; you send a single request to the device via USB updating the host MAC address it shall connect to. This can be done via SCP, FireShock or even WinUSB and a bit of custom code. No biggie.

    I'll provide a tool for that.



  • Ugh, I'm on a hunt. A bug hunt. And it's always issues I've introduced myself πŸ˜†

    2: kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************
    
    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
    An attempt was made to access a pageable (or completely invalid) address at an
    interrupt request level (IRQL) that is too high.  This is usually
    caused by drivers using improper addresses.
    If kernel debugger is available get stack backtrace.
    Arguments:
    Arg1: ffffe000c63b0dd4, memory referenced
    Arg2: 0000000000000002, IRQL
    Arg3: 0000000000000000, value 0 = read operation, 1 = write operation
    Arg4: fffff800ccac6434, address which referenced memory
    

    DRIVER_IRQL_NOT_LESS_OR_EQUAL is the most misleading bugcheck there is because the IRQL has little to do with this particular case, it's just me accessing freed memory:

    ca8ee713-3e75-4251-8632-5c2c9e29e881-image.png

    A classic 😁



  • Hello @nefarius,
    What wonderful work you have been doing!

    If you could put the code on github, (possibly just your β€œsrc” ans β€œinclude” directories {and licence of course}, so that noobs won’t compile and break their system.). It would allow some of us to have a more in-depth read-through of your code.

    Otherwise, keep up the amazing work; I look forward to seeing the code in person.

    Cam.



  • @da2ce7 Greetings. The plan is indeed to move to GitHub once the project is mature and stable enough. Right now it will stay private 😁



  • Pop the champagne, another milestone reached 🍾

    SIXAXIS/DualShock 3 and Navigation controller playable through Shibari

    Youtube Video

    After all this time of tinkering and watching byte streams I wanted to experience some results so I've modded Shibari to support the exposed children of the BthPS3 bus and look at them go πŸ˜„

    Now I can enter some serious testing and do benchmarks without having to write the function driver. In this example the bus children are in Raw PDO mode meaning that the PNP-Manager will bring them up without a function driver required and exposes them to user-land applications which then can talk to them via classic Win32-API CreateFile and DeviceIoControl.

    This is of course only an "intermediate stage", I'll still provide HID-minifilter drivers so no additional software will be required to expose the controllers via HID/DI and (probably) XInput.

    Stay tuned!



  • Castlevania Chronicles Pro-Gameplay by Gordon Freeman

    Youtube Video

    Pardon the shit quality, recorded this on my HTPC for authenticity and the i3 wasn't really happy πŸ˜…



  • @nefarius Looking good there! Almost like it's ready for beta testers? πŸ˜„ It's been over a week without updates on my favorite tech blog! πŸ˜‰



  • @Locksmith said in Bluetooth Filter Driver for DS3-compatibility - research notes:

    @nefarius Looking good there! Almost like it's ready for beta testers? πŸ˜„ It's been over a week without updates on my favorite tech blog! πŸ˜‰

    Hey,

    no worries, I'm still here, had to take a bit of a break, need to wipe my development PC and reinstall all the fun. Plus I've quit my day job and had to organize a few things and regain a proper sleep schedule πŸ˜…

    There'll be more updates soon.

    Cheers



  • Hi Nefarious, i'm actually using your scp toolkit driver for windows, even if incomplete it works well, i have both a ds3 and a ds4, and i really hope that when this project will be finished, both pads will be supported! Congratulations for all the latest progress you made! ^^



  • @Luke76bg I hope for the same, mate πŸ˜† glad it brings you joy, we're getting very close, just stay with me πŸ˜…



  • @nefarius I'm not going anywhere! I can't wait! ^___^



  • 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 canteen DS3 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_ALL sounds 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 BthPS3Util should/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 πŸ˜…

    7056b9f7-0e38-41ca-a873-b4ada6ca4028-image.png

    Bless you, VMware πŸ˜ƒ

    9a354b73-cd02-4bd7-a572-b2836b41e2ab-image.png

    That's quite quick, RAM-cached hard disk provides quite the I/O πŸ˜†

    2ac88313-e079-4eed-9595-a22d537b1c6c-image.png


Log in to reply