cookhoogl.blogg.se

1. Cambridge silicon radio bluetooth filter driver driver#
2. Cambridge silicon radio bluetooth filter driver code#
3. Cambridge silicon radio bluetooth filter driver ps3#
4. Cambridge silicon radio bluetooth filter driver windows#

UrbFunctionBulkInTransferCompletedĕ-21:13:01.742 TRACE_LEVEL_INFORMATION ++ PSM: 0x11 UrbFunctionBulkInTransferCompletedĕ-21:13:01.742 TRACE_LEVEL_INFORMATION > L2CAP_Connection_Request UrbFunctionBulkInTransferCompletedĕ-21:13:01.742 TRACE_LEVEL_VERBOSE UrbFunctionBulkInTransferCompleted Entry Oh yeah, registering a proxy PSM for PSM_HID_INTERRUPT as well shoots us even further forward: UrbFunctionInterruptInTransferCompletedĕ-21:13:01.717 TRACE_LEVEL_INFORMATION HCI_Connection_Complete_EV very interesting! Let's see where the road leads me from here on.

Cambridge silicon radio bluetooth filter driver driver#

This grants us a way around bthport.sys!BthIsSystemPSM denying the connection right away, so far so good! But that's not enough how should the Bluetooth stack now know what to do with a non-existent PSM? Well, we need to register a custom Profile Driver for it, of course! 1-15:26:31.001 TRACE_LEVEL_INFORMATION ++ Trying to register PSM 0x5053ġ-15:26:31.001 TRACE_LEVEL_INFORMATION ++ Got PSM 0x5053ġ-15:26:31.001 TRACE_LEVEL_VERBOSEěthPS3RegisterPSM Exitġ-15:26:31.001 TRACE_LEVEL_VERBOSEěthPS3RegisterL2CAPServer Entryġ-15:26:31.001 TRACE_LEVEL_VERBOSEěthPS3IndicationCallback Entryġ-15:26:31.001 TRACE_LEVEL_VERBOSEěthPS3IndicationCallback Exitġ-15:26:31.001 TRACE_LEVEL_VERBOSEěthPS3RegisterL2CAPServer Exitġ-15:26:42.763 TRACE_LEVEL_VERBOSEěthPS3IndicationCallback Entryġ-15:26:42.763 TRACE_LEVEL_INFORMATIONěthPS3IndicationCallback ++ IndicationRemoteConnectġ-15:26:42.763 TRACE_LEVEL_VERBOSEěthPS3IndicationCallback ExitĪnd we actually receive the connection request in our own profile driver now UrbFunctionBulkInTransferCompletedđ-15:26:42.733 TRACE_LEVEL_INFORMATION ++ Patching PSM to 0x5053 UrbFunctionBulkInTransferCompletedđ-15:26:42.733 TRACE_LEVEL_INFORMATION ++ PSM: 0x11 UrbFunctionBulkInTransferCompletedđ-15:26:42.733 TRACE_LEVEL_INFORMATION > L2CAP_Connection_Request I've currently set up a BTHUSB lower filter driver simply looking for an incoming L2CAP connection request with the dredded PSM 0x11 and patching it to an artificial fixed value (currently 0x5053) UrbFunctionBulkInTransferCompletedđ-15:26:42.733 TRACE_LEVEL_VERBOSE UrbFunctionBulkInTransferCompleted Entry Will further go down and explore the lower BTHUSB filter route

Cambridge silicon radio bluetooth filter driver windows#

On Windows however this is a pretty big deal and the showstopper for an out-of-the-box working connection of a DS3 with standard Windows Bluetooth stack.Ī pretty neat hack around this limitation was discovered a few years back, but API hooking or binary patches in kernel space are strictly forbidden (mainly for stability and security reasons, even Anti-Virus vendors had to back down from this approach starting with the Vista kernel) so while having this info as a fallback, it's not something we can use in production and therefore a KMDF Bluetooth Profile Driver won't be helpful here.

Cambridge silicon radio bluetooth filter driver ps3#

It is well-known that the DS3 establishes communication channels via PSM 0x11 and 0x13, which works fine on the PS3 (custom Bluetooth stack firmware) and Linux (no such reservations/limitations). Some PSMs are reserved for use by Windows: Why this happens is actually documented, especially: So the L2CAP ping-pong should be looked at in greater detail and find the stage where it starts to break. Next is building the L2CAP connection, which seems to get initiated as well a few requests later:Īs buffer = 0x01 & buffer = 0x00 represents the L2CAP control channel. The HCI_Command_Remote_Name_Request is the last HCI command which has to succeed, which looks like it does. On Interrupt Pipe (HCI communication) connection seems to work at least until receiving HCI_Remote_Name_Request_Complete_EV:

Generic Bluetooth Radio (Cambridge Silicon Radio Ltd.).

Cambridge silicon radio bluetooth filter driver code#

While we're already having a working code base for a dedicated Bluetooth host dongle function driver supporting genuine and fake DS3s I wanna also explore the path of a different approach: keeping the default Windows Bluetooth driver stack in place and patching it in a way that it will accept a DS3 connection transparently in parallel to other devices (keyboards, headsets etc.) via filter driver.