Group Details Private

Vigemites

ViGEm devs or other highly privileged

  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    Alright, time to properly polish and fix power management.

    I've implemented dropping all connections in case of bthenum surprise removal (unplugging the USB Bluetooth dongle without warning), freeing memory and instructing child device (PDO) removal. This works well and allows unloading the driver, so no dangling objects here. But as soon as the function driver attaches, everything stalls on surprise removal. I haven't yet had the time to debug/implement it but I can document a few assumptions to help me later when I pick it up again.

    • EvtWdfIoQueueIoInternalDeviceControl sends BRBs synchronously out of convenience, this probably isn't the brightest idea, will adjust that to asynchronous
    • PDO might be missing PNP/Power capabilities
    • Queue I/O stop callback isn't invoked
    • Maybe implement self-managed I/O flush callback?

    I bet it's an easy fix and I'm just overthinking the issue. Will pick up development again in a few days 👋

    posted in Research & Development
  • RE: Shibari/FireShock Gen 2 - Restart/Shutdown Infinite Hang Bug

    Thanks for the report, maybe I can find something obvious in the v2 sources and provide a fix.

    posted in Discussion and Support
  • RE: vmulti.sys

    Heya,

    I don't. I had a play with it and forked it to fix building it with WDK 10 but didn't do more with it. Having an EV cert alone isn't enough, to get it to work on all Windows editions you gotta go through WHQL certification. I can give that a try once I have the new lab set up approximately next month.

    Cheers

    posted in Discussion and Support
  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    Going the extra mile today: testing the PS Move Navigation controller 😈 Connection established:

    2019/02/10-18:32:19.445	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
    2019/02/10-18:32:19.445	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from 70401E341 arrived
    2019/02/10-18:32:19.445	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
    2019/02/10-18:32:19.446	TRACE_LEVEL_ERROR	BTHPS3_GET_DEVICE_NAME failed with status STATUS_INVALID_PARAMETER (0xC000000D), dropping connection
    2019/02/10-18:32:19.446	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnect Entry
    2019/02/10-18:32:19.446	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnectCompleted Entry (STATUS_SUCCESS (0x00000000))
    2019/02/10-18:32:19.446	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnectCompleted Exit
    2019/02/10-18:32:19.446	TRACE_LEVEL_VERBOSE	L2CAP_PS3_DenyRemoteConnect Exit
    2019/02/10-18:32:19.446	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
    2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
    2019/02/10-18:32:20.247	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5053 from 70401E341 arrived
    2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
    2019/02/10-18:32:20.247	TRACE_LEVEL_INFORMATION	++ Device 70401E341 name: Navigation Controller
    2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Exit (STATUS_SUCCESS (0x00000000))
    2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
    2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFFFA80074DE0C0)
    2019/02/10-18:32:20.247	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
    2019/02/10-18:32:20.497	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ControlConnectResponseCompleted Entry
    2019/02/10-18:32:20.497	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
    2019/02/10-18:32:20.497	TRACE_LEVEL_INFORMATION	HID Control Channel connection established
    2019/02/10-18:32:20.497	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ControlConnectResponseCompleted Exit
    2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Entry
    2019/02/10-18:32:20.689	TRACE_LEVEL_INFORMATION	New connection for PSM 0x5055 from 70401E341 arrived
    2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Entry
    2019/02/10-18:32:20.689	TRACE_LEVEL_INFORMATION	++ Device 70401E341 name: Navigation Controller
    2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	++ Found desired connection item in connection list
    2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	L2CAP_PS3_HandleRemoteConnect Exit (STATUS_SUCCESS (0x00000000))
    2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	BthPS3IndicationCallback Exit
    2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x0, Context: 0xFFFFFA80074DE0C0)
    2019/02/10-18:32:20.689	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
    2019/02/10-18:32:20.783	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Entry (Indication: 0x4, Context: 0xFFFFFA80074DE0C0)
    2019/02/10-18:32:20.783	TRACE_LEVEL_INFORMATION	L2CAP_PS3_ConnectionIndicationCallback ++ IndicationRemoteConfigRequest
    2019/02/10-18:32:20.783	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionIndicationCallback Exit
    2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	L2CAP_PS3_InterruptConnectResponseCompleted Entry
    2019/02/10-18:32:20.824	TRACE_LEVEL_INFORMATION	Connection completion, status: STATUS_SUCCESS (0x00000000)
    2019/02/10-18:32:20.824	TRACE_LEVEL_INFORMATION	HID Interrupt Channel connection established
    2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionStateConnected Entry
    2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	L2CAP_PS3_ConnectionStateConnected Exit
    2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	L2CAP_PS3_InterruptConnectResponseCompleted Exit
    2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	BthPS3_EvtWdfChildListCreateDevice Entry
    2019/02/10-18:32:20.824	TRACE_LEVEL_VERBOSE	BthPS3_EvtWdfChildListCreateDevice Exit
    

    And there we have the HID Input Report in the function driver 🎉

    2019/02/10-18:34:23.749	TRACE_LEVEL_INFORMATION	InputReport_EvtTimerFunc Entry
    2019/02/10-18:34:23.757	TRACE_LEVEL_INFORMATION	A1 01 00 00 00 00 00 80 80 7D 85 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 03 14 FF C2 00 00 23 D6 77 00 40 02 00 02 04 01 A3 01 FF 
    2019/02/10-18:34:23.757	TRACE_LEVEL_INFORMATION	InputReport_EvtTimerFunc Exit
    

    posted in Research & Development
  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    There we go 😎

    2019/02/10-17:52:51.880	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfIoQueueIoInternalDeviceControl Entry
    2019/02/10-17:52:51.880	TRACE_LEVEL_VERBOSE	BthPS3_EvtWdfIoQueueIoInternalDeviceControl Entry
    2019/02/10-17:52:51.880	TRACE_LEVEL_VERBOSE	bufferLength: 50
    2019/02/10-17:52:51.885	TRACE_LEVEL_VERBOSE	brb->BufferSize: 50, brb->RemainingBufferSize: 0
    2019/02/10-17:52:51.885	TRACE_LEVEL_INFORMATION	A1 01 00 00 00 00 00 7A 81 80 7D 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 05 16 FF CD 00 01 33 00 77 00 40 01 FA 01 ED 01 91 00 05 
    2019/02/10-17:52:51.885	TRACE_LEVEL_VERBOSE	BthPS3_PDO_EvtWdfIoQueueIoInternalDeviceControl Exit
    

    What threw me off for quite a few hours was the weird behavior of the RemainingBufferSize member of the _BRB_L2CA_ACL_TRANSFER structure, which was increasing fast to values way higher than the buffer I supplied could hold. Turns out this field is not talking about the Buffer member the caller supplies but the internal buffer of the Bluetooth host which tells you how many bytes have already come in from the remote device and are available to be read by further calls with that same BRB. I don't think the reference code I had a peek at did take that into account as this value was subtracted from BufferSize which could lead to a negative value resulting in 💥

    Now that that's sorted out off to cleaning up this mess and looking for leaking memory 😇

    posted in Research & Development
  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    Turns out reading from the HID interrupt channel the right way is a bit more challenging than I expected. Unfortunately there's no Bluetooth equivalent of the continuous reader for USB pipes in WDF so you've to implement that thing yourself. There are reference implementations available but they're so "ripped apart" and all over the place I'll instead try to write it from scratch to better understand what's happening. Maybe I get somewhere today, we'll see 🎖

    posted in Research & Development
  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    It's communicating! 😄

    ezgif.com-gif-maker.gif

    I've managed to quickly hack together an ugly demo function driver for the SIXAXIS PDO in under an hour and test it with only two crashes 😇

    _Use_decl_annotations_
    VOID
    OutputReport_EvtTimerFunc(
        WDFTIMER  Timer
    )
    {
        WDFDEVICE device = WdfTimerGetParentObject(Timer);
        WDFIOTARGET ioTarget = WdfDeviceGetIoTarget(device);
        PDEVICE_CONTEXT devCtx = DeviceGetContext(device);
    
        TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_DEVICE, "%!FUNC! Entry");
    
        static UCHAR G_Ds3HidOutputReport[] = {
        0x52, 0x01, 0x00, 0xFF, 0x00, 0xFF, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x1E, 0xFF, 0x27, 0x10, 0x00,
        0x32, 0xFF, 0x27, 0x10, 0x00, 0x32, 0xFF, 0x27,
        0x10, 0x00, 0x32, 0xFF, 0x27, 0x10, 0x00, 0x32,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00
        };
    
        static BOOLEAN toggle = FALSE;
    
        toggle = !toggle;
        G_Ds3HidOutputReport[11] = (toggle) ? 0x02 : 0x04;
    
        PBTHPS3_HID_CONTROL_WRITE controlWrite;
        NTSTATUS status;
    
        WDF_MEMORY_DESCRIPTOR  MemoryDescriptor;
        WDFMEMORY  MemoryHandle = NULL;
        status = WdfMemoryCreate(NULL,
            NonPagedPool,
            'aylB',
            sizeof(BTHPS3_HID_CONTROL_WRITE),
            &MemoryHandle,
            &controlWrite);
    
        BTHPS3_HID_CONTROL_WRITE_INIT(controlWrite);
    
        controlWrite->BufferLength = 0x32;
        controlWrite->Buffer = ExAllocatePoolWithTag(
            NonPagedPoolNx,
            0x32,
            'aylB'
        );
        RtlCopyMemory(controlWrite->Buffer, G_Ds3HidOutputReport, 0x32);
    
        WDF_MEMORY_DESCRIPTOR_INIT_HANDLE(&MemoryDescriptor,
            MemoryHandle,
            NULL);
    
        status = WdfIoTargetSendInternalIoctlSynchronously(
            ioTarget,
            NULL,
            IOCTL_BTHPS3_HID_CONTROL_WRITE,
            &MemoryDescriptor,
            NULL,
            NULL,
            NULL
        );
    
        ExFreePoolWithTag(controlWrite->Buffer, 'aylB');
    
        if (!NT_SUCCESS(status)) {
            TraceEvents(TRACE_LEVEL_ERROR,
                TRACE_DEVICE,
                "WdfIoTargetSendInternalIoctlSynchronously failed with status %!STATUS!",
                status
            );
            return;
        }
    
        WdfTimerStart(devCtx->OutputReportTimer, WDF_REL_TIMEOUT_IN_MS(0x01F4));
    
        TraceEvents(TRACE_LEVEL_INFORMATION, TRACE_DEVICE, "%!FUNC! Exit");
    }
    

    This is a timer callback function getting called around every 500 ms and cycling through LED 1 and 2 by submitting an output report to the HID Control endpoint via IOCTL_BTHPS3_HID_CONTROL_WRITE. The driver is very minimal, inefficient with memory handling and horribly named but for a demonstration just perfect 😆

    4c2d7745-b075-4ec9-8c92-64719155effa-image.png

    Next I'm gonna try to read from it 💥

    posted in Research & Development
  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    Wrapped all necessary driver (un-)installation tasks in a small self-contained tool and finished proper error handling:

    cd8e8aa4-2962-427e-903a-a514d6ce6085-image.png

    This tool can then assist a setup in automating the installation and also making test installations more bearable 😉

    What happens in the picture for each line:

    • BluetoothSetLocalServiceInfo is invoked which causes bthenum to spawn a PDO for the profile driver to latch onto
    • Bluetooth profile driver gets installed in driver store and device driver installation for newly spawned PDO gets kicked off
    • bthusb lower filter driver service (BthPS3PSM) gets created
    • BthPS3PSM gets added as lower filter driver for GUID_DEVCLASS_BLUETOOTH device class
    • Same action is invoked again, leading to a different response
    • Service creation is invoked again, failing because it's already registered

    That'll be all for today, folks! 🤠

    posted in Research & Development
  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    A lot of progress was made today. Nothing much to present yet but I've basically started to design and implement the interface that will be used to talk to the exposed PDOs via own function driver. This causes the code base for the profile driver remain encapsulated for Bluetooth related stuff only. Higher level functions (HID mini-driver, LED, Rumble, ...) will then be implemented by one or more individual function drivers latching onto the PDOs.

    Cheers

    posted in Research & Development
  • RE: Bluetooth Filter Driver for DS3-compatibility - research notes

    Couldn't fall asleep last night, implemented bus enumerator instead:

    Youtube Video

    What's going on in the video: once the connection of both HID Control and Interrupt channels has been established, the wonderful KMDF bus driver API kicks in and spawns a new PNP device:

    WDF_CHILD_IDENTIFICATION_DESCRIPTION_HEADER_INIT(
            &pdoDesc.Header,
            sizeof(PDO_IDENTIFICATION_DESCRIPTION)
        );
    
    pdoDesc.RemoteAddress = ClientConnection->RemoteAddress;
    pdoDesc.DeviceType = ClientConnection->DeviceType;
    
    //
    // Invoke new child creation
    // 
    status = WdfChildListAddOrUpdateChildDescriptionAsPresent(
    	WdfFdoGetDefaultChildList(ClientConnection->DevCtxHdr->Device),
    	&pdoDesc.Header,
    	NULL
    );
    

    In order to de-clutter the profile/bus driver I decided to outsource the device-specific logic into one or more additional function drivers, introducing IOCTLs to fetch data from and send to the PDOs without having to deal with Bluetooth-specific paradigms at all. I've introduced artificial GUID-based hardware IDs for every distinct device:

    • DS_DEVICE_TYPE_SIXAXIS - SIXAXIS or DualShock 3 compatible (including 3rd party controllers)
    • DS_DEVICE_TYPE_NAVIGATION - PlayStation Move Navigation Controller
    • DS_DEVICE_TYPE_MOTION - PlayStation Move Motion Controller
    • DS_DEVICE_TYPE_WIRELESS - DualShock 4 Revision 1 or 2 Wireless Controller

    On a personal note; I'm quite pleased about the pacing here, implementing the bus logic was done almost entirely from memory and implemented once again without crashing the test host 👏

    posted in Research & Development