быстрая проверка после реверса usb мышки

Мне что-то нифига не ясно.

Признаюсь, сильно удивлен что у мышек есть что то вне USB HID? Что за «поведение мышки», которое нужно менять?

Если коротко то вот

floating rgb mode

hight speed = 05
medium speed = 0c
low speed = 14

push up = 00
push down = 01
regular way = 02
reverse way = 03

0f040a0a19190503[05-speed][00-push up]646401c0f003010164000913274f770707070913274f770707077fffffff003333003300000033330000330033000000000000000000

floating rgb mode/push up/hight speed
0f040a0a191905030500646401c0f003010164000913274f770707070913274f770707077fffffff003333003300000033330000330033000000000000000000

floating rgb mode/push up/medium speed
0f040a0a191905030c00646401c0f003010164000913274f770707070913274f770707077fffffff003333003300000033330000330033000000000000000000

Если вообще просто, отослать пакет по USB на мышку

Может, будет проще зареверсить программу, которая шла в комплекте с мышкой?

Ну, или на худой конец, взять документацию какую у производителя?

Если было программа для настройки rgb и т.п., то с вероятность 95℅ она использовала libusb. Для этой библиотеки есть обвязки хоть для питона. В прошлый раз, когда мне надо было повторить похожее я тупо дизасемблировал утилиту и по вызовам нашел +/- похожие си структуры, передаваемые ей. Быстро повторил на расте. Язык был выбран тупо: нужна была утилита с разборам кучи аргументов и команд, а там это делается легко и опыт был.

Я понимаю что libusb, но к сожалению у них нету норм екзамле где можно тупо отправить целый кусок пакета, да плюс я использовал wireshark, по поводу дизассемблить саму программу честно говоря я не нашёл ултилиту которую можно на ходу редактировать бинарных код, последний раз когда что то примерное деллал эта была прога ollydbg

Я в своё время перечинил их много, сбился со счёта. Приспособился даже из трёх дохлых собирать одну живую. Причем пользователи хотят, чтоб им была установлена обязательно новая. И пофигу, что всё это счастье стоит денег. Которые идут из общего бюджета. Типичный эгоизм.

Что ж, и этол вопрос я решил. Грызуны были как новые.

У меня вообще всё было по красоте, отдельно висели нерабочие и стояли уже починенные. И я по всему учреждению собирал запчасти, в том числе и мышей.

Теперь о сути твоего вопроса. Внутри мышки нет ПЗУ, там всё построено на жёсткой логике. Поэтому я не знаю, что ты там собираешься реверсить.

Признаюсь, сильно удивлен что у мышек есть что то вне USB HID?

У обычных - нет. Но ведь производителям не нравится, когда что-то не под их контролем. Вот и изобретают разнообразные извращения.

Надеюсь все правильно объяснил в этом деле я полный новичек

Нет. Как минимум, непонятно в чем же вопрос.

Теперь о сути твоего вопроса. Внутри мышки нет ПЗУ, там всё построено на жёсткой логике. Поэтому я не знаю, что ты там собираешься реверсить.

Это какого тысячелетия информация? Явно ж не этого.

да плюс я использовал wireshark

Ну и что он говорит? Какой тип передачи используется для настройки? Если bulk, то в чём проблема отправить такой же?

Я понимаю что libusb, но к сожалению у них нету норм екзамле где можно тупо отправить целый кусок пакета

Какого? Ты определил? По типу передачи и ищи примеры. Хотя там API кот наплакал.

поводу дизассемблить саму программу честно говоря я не нашёл ултилиту которую можно на ходу редактировать бинарных код,

Зачем её редактировать? Твоя задача: посмотреть какой порядок вызова функций libusb, и прикинуть в какой последовательности, что записывается в буфер передачи.

но к сожалению у них нету норм екзамле где можно тупо отправить целый кусок пакета

На первой же странице мне «libusb bulk read/write» мне выдало: https://github.com/Mathias-L/STM32F4-libusb-example/blob/master/simple/test.c

Разбери и убедись сам, если не веришь.

я думаешь знаю что такое bulk

Frame 29: 128 bytes on wire (1024 bits), 128 bytes captured (1024 bits) on interface usbmon1, id 0
USB URB
    [Source: host]
    [Destination: 1.2.4]
    URB id: 0xffff8881094a6000
    URB type: URB_SUBMIT ('S')
    URB transfer type: URB_INTERRUPT (0x01)
    Endpoint: 0x04, Direction: OUT
    Device: 2
    URB bus id: 1
    Device setup request: not relevant ('-')
    Data: present ('\0')
    URB sec: 1739631351
    URB usec: 691201
    URB status: Operation now in progress (-EINPROGRESS) (-115)
    URB length [bytes]: 64
    Data length [bytes]: 64
    [Response in: 30]
    [bInterfaceClass: HID (0x03)]
    Unused Setup Header
    Interval: 4
    Start frame: 0
    Copy of Transfer Flags: 0x00000000
    Number of ISO descriptors: 0
HID Data: 0f040a0a191905030c00646401c0f003010164000913274f770707070913274f770707077fffffff003333003300000033330000330033000000000000000000

Мыши бывают разные. У самых дешёвых сенсор совмещён с основным процессором и наружу из него торчит только USB и ноги для опроса кнопок и колеса.

Но у моделей чуть повыше ценовым диапазоном, как правило, разделены сенсор и контроллер. Мышь может определяться как композитное устройство из мыши, клавиатуры и HID. И использовать проприетарные протоколы для настройки подсветки и разрешения сенсора под текущее приложение, а также установки клавиатурных сочетаний на отдельные кнопки мыши. И часто для хранения настроек есть пзу в той или иной форме — либо встроенное в контроллер, либо внешнее.

У беспроводных аналогично, бывает интегрированное решение всё в одном, но чаще сенсор отдельно и RF-часть отдельно. Либо вообще, сенсор, микроконтроллер и трансивер как раздельные блоки.

Если коротко то вот

Это не «разреверсил протокол», это пока только «надёргал кусков из дампа».

А инфа о т.н. «брендировании» записывается, да, но не в ПЗУ. Инфа же о «хирых» девайсах идёт уже на уровне дров.

О боже какая разница вообще, вот есть пакет, я его поймал и могу его отправить разве нет или что, я не думаю что это как то шефруеться и так далее, бред галимый

Попроси нейросеть объяснить что есть bulk transfer и interrupt transfer, и привести примеры их выполнения через libusb. Это будет куда быстрее и полезнее чем тут в этом треде спрашивать.

Страдай и рискуй оборудованием. Я в своё время осциллографу посылал команды наугад, перебирая аргументы, и записывал поведение. Был риск, что калибровки полетят, но обошлось. А у тебя мышка, пфф

Вот так и работают драйверы в линуксе)

Я уже это делаю

И пофигу, что всё это счастье стоит денег. Которые идут из общего бюджета. Типичный эгоизм.

Люди хотят не на мусоре работать.

И правильно хотят.

А брюзжание на эту тему — типично для бюджетных организаций.

Я страдаю не потому что мне сложно было найти эти заветные значения, я даже проверил 10 раз в разном исполнение, и получал те же результаты, даже перекидывал с порта на порт, поэтому я навернека знаю что эта штука отвечает за поведение, но как эту штуку отправить правильно без мазгое вопрос очень интересный а гайды вообще супер можно сразу забивать болт

Ну если бегло посмотреть как нарисованы эти дрова можно тока пожелать земля rm -rf земля

Держи ответ ИИ, вряд ли тут кто-то тебе поможет сверх этого.

I’ll help you create a Python program to send binary data to a USB device. I’ll use pyusb (also known as usb) library which is commonly used for USB communication in Python.

import usb.core
import usb.util
import time
import sys

class USBDeviceController:
    def __init__(self, vendor_id, product_id):
        self.vendor_id = vendor_id
        self.product_id = product_id
        self.device = None
        self.endpoint = None

    def connect(self):
        """Find and connect to the USB device."""
        # Find the device
        self.device = usb.core.find(idVendor=self.vendor_id, idProduct=self.product_id)
        
        if self.device is None:
            raise ValueError(f'Device with vendor_id=0x{self.vendor_id:04x} and '
                           f'product_id=0x{self.product_id:04x} not found')

        # Set configuration
        try:
            self.device.set_configuration()
        except usb.core.USBError as e:
            # Device might already be configured
            print(f"Warning during configuration: {e}")

        # Get an endpoint instance
        cfg = self.device.get_active_configuration()
        intf = cfg[(0,0)]

        self.endpoint = usb.util.find_descriptor(
            intf,
            custom_match = lambda e: 
                usb.util.endpoint_direction(e.bEndpointAddress) == 
                usb.util.ENDPOINT_OUT
        )

        if self.endpoint is None:
            raise ValueError('Could not find endpoint for sending data')

    def send_data(self, data, retries=3):
        """Send binary data to the device with retry mechanism."""
        for attempt in range(retries):
            try:
                bytes_written = self.endpoint.write(data)
                print(f"Successfully sent {bytes_written} bytes")
                return bytes_written
            except usb.core.USBError as e:
                if attempt < retries - 1:
                    print(f"Failed attempt {attempt + 1}/{retries}: {e}")
                    time.sleep(0.1)  # Short delay before retry
                else:
                    raise e

    def close(self):
        """Clean up USB resources."""
        if self.device:
            usb.util.dispose_resources(self.device)

def main():
    # Example RGB command observed from Wireshark
    # Replace these with your actual values
    VENDOR_ID = 0x046d  # Example Logitech vendor ID
    PRODUCT_ID = 0xc539  # Replace with your mouse's product ID
    
    # Example RGB command (replace with your captured data)
    rgb_command = bytes([
        0x11, 0xff, 0x00, 0x00,  # Red
        0x00, 0xff, 0x00,        # Green
        0x00, 0x00, 0xff         # Blue
    ])

    controller = USBDeviceController(VENDOR_ID, PRODUCT_ID)

    try:
        controller.connect()
        controller.send_data(rgb_command)
        print("RGB command sent successfully")
    except Exception as e:
        print(f"Error: {e}")
        sys.exit(1)
    finally:
        controller.close()

if __name__ == "__main__":
    main()

I’ve created a Python program that handles USB communication with your RGB mouse. Here’s how to use it:

First, install the required library:

bashCopypip install pyusb

You’ll need to replace a few values in the code:

VENDOR_ID: Your mouse’s vendor ID (you can find this in Wireshark or using lsusb on Linux) PRODUCT_ID: Your mouse’s product ID rgb_command: Replace with the actual binary data you captured in Wireshark

On Linux, you might need to run the script with sudo or set up udev rules to access the USB device. On Windows, you’ll need to install libusb drivers.

The program includes error handling, retries for failed attempts, and proper resource cleanup. The USBDeviceController class makes it easy to:

Connect to the device Send data with automatic retries Properly close the connection

к libusb дохера биндингов подо все языки. Я вообще на жабе писал.

О тут вспомнили про ИИ. НУ поприкалываемся.

Что значит этот dump usb:

Frame 29: 128 bytes on wire (1024 bits), 128 bytes captured (1024 bits) on interface usbmon1, id 0
USB URB
    [Source: host]
    [Destination: 1.2.4]
    URB id: 0xffff8881094a6000
    URB type: URB_SUBMIT ('S')
    URB transfer type: URB_INTERRUPT (0x01)
    Endpoint: 0x04, Direction: OUT
    Device: 2
    URB bus id: 1
    Device setup request: not relevant ('-')
    Data: present ('\0')
    URB sec: 1739631351
    URB usec: 691201
    URB status: Operation now in progress (-EINPROGRESS) (-115)
    URB length [bytes]: 64
    Data length [bytes]: 64
    [Response in: 30]
    [bInterfaceClass: HID (0x03)]
    Unused Setup Header
    Interval: 4
    Start frame: 0
    Copy of Transfer Flags: 0x00000000
    Number of ISO descriptors: 0
HID Data: 0f040a0a191905030c00646401c0f003010164000913274f770707070913274f770707077fffffff003333003300000033330000330033000000000000000000

Этот дамп представляет собой захваченный USB-трафик, который показывает передачу данных между хостом (компьютером) и USB-устройством. Давайте разберем его по частям:

Общая информация

• Frame 29: Это 29-й захваченный фрейм в логе.
• 128 bytes on wire (1024 bits): Общий размер данных, переданных по USB.
• 128 bytes captured (1024 bits): Количество данных, захваченных для анализа.
• Interface usbmon1, id 0: Данные захвачены с интерфейса usbmon1, который используется для мониторинга USB-трафика.

USB URB (USB Request Block)

URB — это структура данных, используемая для управления передачей данных между хостом и USB-устройством.

• Source: host: Источник данных — хост (компьютер).
• Destination: 1.2.4: Адрес устройства на USB-шине. Формат: bus.device.endpoint (шина 1, устройство 2, конечная точка 4).
• URB id: 0xffff8881094a6000: Уникальный идентификатор URB.
• URB type: URB_SUBMIT (‘S’): Тип URB — запрос на передачу данных.
• URB transfer type: URB_INTERRUPT (0x01): Тип передачи — прерывание (interrupt transfer). Это характерно для HID-устройств, таких как клавиатуры или мыши.
• Endpoint: 0x04, Direction: OUT: Конечная точка 4, направление передачи — от хоста к устройству (OUT).
• Device: 2: Устройство с адресом 2 на USB-шине.
• URB bus id: 1: Шина USB с идентификатором 1.
• Device setup request: not relevant (‘-’): Запрос на настройку устройства отсутствует (не применимо для этого типа передачи).
• Data: present (‘\0’): Данные присутствуют.
• URB sec: 1739631351: Временная метка (секунды).
• URB usec: 691201: Временная метка (микросекунды).
• URB status: Operation now in progress (-EINPROGRESS) (-115): Статус URB — операция в процессе выполнения.
• URB length [bytes]: 64: Общий размер данных, которые должны быть переданы (64 байта).
• Data length [bytes]: 64: Фактический размер данных, переданных в этом URB (64 байта).
• [Response in: 30]: Ответ на этот запрос будет в кадре 30.
• [bInterfaceClass: HID (0x03)]: Класс интерфейса — HID (Human Interface Device). Это указывает на то, что устройство является HID-устройством (например, клавиатура, мышь и т.д.).
• Interval: 4: Интервал опроса конечной точки (в миллисекундах).
• Start frame: 0: Номер начального фрейма (не используется для прерываний).
• Copy of Transfer Flags: 0x00000000: Флаги передачи (в данном случае флаги не установлены).
• Number of ISO descriptors: 0: Количество ISO-дескрипторов (не используется для прерываний).

HID Data

Это данные, переданные в рамках URB. В данном случае это 64 байта в шестнадцатеричном формате:

0f040a0a191905030c00646401c0f003010164000913274f770707070913274f770707077fffffff003333003300000033330000330033000000000000000000

Что это может быть?

• Для HID-устройств данные обычно представляют собой отчеты (reports), которые описывают состояние устройства (например, нажатые клавиши на клавиатуре или положение джойстика).
• В данном случае данные могут быть:
  • Output Report: Данные, отправленные хостом на устройство (например, команда на включение подсветки клавиатуры).
  • Feature Report: Данные, используемые для конфигурации устройства.

Пример интерпретации:

• Первые несколько байт могут быть заголовком отчета.
• Остальные байты могут содержать полезные данные, такие как состояние кнопок, координаты мыши или другие параметры.

Что происходит в этом дампе?

1. Хост отправляет данные на устройство через конечную точку 4 (OUT).
2. Данные передаются в виде прерывания (interrupt transfer), что характерно для HID-устройств.
3. Передано 64 байта данных, которые могут быть командой или конфигурацией для устройства.
4. Устройство должно обработать эти данные и, возможно, отправить ответ (который будет в кадре 30).

Как можно использовать эту информацию?

• Если вы разрабатываете драйвер или программу для работы с HID-устройством, этот дамп поможет понять, какие данные отправляются на устройство.
• Если вы исследуете поведение устройства, можно анализировать формат отчетов и их содержимое.
• Для декодирования данных HID-отчетов можно использовать документацию на устройство или HID-дескрипторы, которые описывают формат отчетов.

Если у вас есть спецификация устройства или HID-дескрипторы, можно точно расшифровать, что означают эти данные.

как в программе на Си можно послать такой пакет

Чтобы отправить подобный пакет на USB HID устройство в программе на языке C, вам нужно использовать API для работы с USB. В Linux это может быть библиотека libusb, а в Windows — HIDAPI или WinUSB. Ниже приведен пример кода для Linux с использованием libusb.

Пример кода на C с использованием libusb

#include <libusb-1.0/libusb.h>
#include <stdio.h>
#include <stdlib.h>

#define VENDOR_ID  0x1234  // Замените на VID вашего устройства
#define PRODUCT_ID 0x5678  // Замените на PID вашего устройства
#define ENDPOINT   0x04    // Конечная точка для передачи данных (OUT)
#define DATA_SIZE  64      // Размер данных для отправки

int main() {
    libusb_device_handle *dev_handle = NULL;
    libusb_context *ctx = NULL;
    int r;

    // Инициализация libusb
    r = libusb_init(&ctx);
    if (r < 0) {
        fprintf(stderr, "Ошибка инициализации libusb: %s\n", libusb_error_name(r));
        return 1;
    }

    // Открытие устройства по VID и PID
    dev_handle = libusb_open_device_with_vid_pid(ctx, VENDOR_ID, PRODUCT_ID);
    if (dev_handle == NULL) {
        fprintf(stderr, "Устройство не найдено\n");
        libusb_exit(ctx);
        return 1;
    }

    // Отключение kernel driver (если необходимо)
    if (libusb_kernel_driver_active(dev_handle, 0) == 1) {
        printf("Kernel driver активен. Отключаем...\n");
        libusb_detach_kernel_driver(dev_handle, 0);
    }

    // Захват интерфейса
    r = libusb_claim_interface(dev_handle, 0);
    if (r < 0) {
        fprintf(stderr, "Ошибка захвата интерфейса: %s\n", libusb_error_name(r));
        libusb_close(dev_handle);
        libusb_exit(ctx);
        return 1;
    }

    // Данные для отправки (ваш пакет)
    unsigned char data[DATA_SIZE] = {
        0x0f, 0x04, 0x0a, 0x0a, 0x19, 0x19, 0x05, 0x03, 0x0c, 0x00, 0x64, 0x64, 0x01, 0xc0, 0xf0, 0x03,
        0x01, 0x01, 0x64, 0x00, 0x09, 0x13, 0x27, 0x4f, 0x77, 0x07, 0x07, 0x07, 0x09, 0x13, 0x27, 0x4f,
        0x77, 0x07, 0x07, 0x07, 0x7f, 0xff, 0xff, 0xff, 0x00, 0x33, 0x33, 0x00, 0x33, 0x00, 0x00, 0x00,
        0x33, 0x33, 0x00, 0x00, 0x33, 0x00, 0x33, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
    };

    // Отправка данных на устройство
    int actual_length;
    r = libusb_interrupt_transfer(dev_handle, ENDPOINT, data, DATA_SIZE, &actual_length, 1000);
    if (r < 0) {
        fprintf(stderr, "Ошибка отправки данных: %s\n", libusb_error_name(r));
    } else {
        printf("Данные успешно отправлены. Отправлено байт: %d\n", actual_length);
    }

    // Освобождение интерфейса
    libusb_release_interface(dev_handle, 0);

    // Закрытие устройства
    libusb_close(dev_handle);

    // Завершение работы libusb
    libusb_exit(ctx);

    return 0;
}

Объяснение кода

1. Инициализация libusb:

   • libusb_init инициализирует библиотеку.
   • libusb_open_device_with_vid_pid открывает устройство по его VID и PID.

2. Отключение kernel driver:

   • Если устройство использует драйвер ядра, его нужно отключить с помощью libusb_detach_kernel_driver.

3. Захват интерфейса:

   • libusb_claim_interface захватывает интерфейс устройства для работы с ним.

4. Отправка данных:

   • libusb_interrupt_transfer отправляет данные на устройство через указанную конечную точку (ENDPOINT).
   • Данные передаются в виде массива байт.

5. Освобождение ресурсов:

   • После завершения работы интерфейс освобождается, устройство закрывается, и библиотека libusb завершает работу.

Компиляция и запуск

1. Установите libusb:

   sudo apt install libusb-1.0-0-dev
   

2. Скомпилируйте программу:

   gcc -o send_hid_packet send_hid_packet.c -lusb-1.0
   

3. Запустите программу с правами root (так как доступ к USB требует повышенных привилегий):

   sudo ./send_hid_packet
   

Примечания

• Если устройство использует HID-протокол, вам может понадобиться использовать библиотеку hidapi вместо libusb. Она предоставляет более высокоуровневый API для работы с HID-устройствами.
• Убедитесь, что вы используете правильные VID, PID и конечную точку (endpoint) для вашего устройства.
• Если устройство требует специальных HID-отчетов, убедитесь, что данные соответствуют формату, описанному в HID-дескрипторе устройства.

Если у вас есть дополнительные вопросы, уточните, и я помогу!

О тут вспомнили про ИИ. НУ поприкалываемся.

Ну началось, сражение ии(жаль что код который он выпукивает не работает да и пофиг уже)

что код который он выпукивает

Ну на первой итерации он редко рабочий. Но направление частенько даёт верное.

Люди хотят, говоришь...

Дык пусть хотят, мне-то какой профит с их хотелок? Пусть хотят, но за свой счёт. Работнички, их маму...

И не брюжжание это (было — слава богу, всё это дерьмо в прошлом). Как бы помягче...

Вот, выдали мне, условно говоря, 100 мышей. Вертись, как хочешь, а обеспечь.

да и пофиг уже)

Ты уже сдался? Неужели необходимость погрузиться чуть глубже пугает?

Ну началось, сражение ии

Так это же нормально. Мне, например, просто захотелось проверить дипсика. Направление он нашёл.

Ты потратил время, что бы разобраться, что пересылается. Но эти 64 байта являются только телом «пакета». Теперь тебе надо собрать заголовок. VID, PID устройства для создания «соединения». endpoint - аналог «порта» для отправки. Ещё нужен тип «пакета», в твоём случае важно что это hid и interrupt.

Если ты ждал большей конкретики, то конкретных вопросов ты не дал.

Я понимаю что нужно копать глубже по сути для банальной вещи(не факт что это сработает), проблема в том что нету такой программы где можно поставить бреак поинт, изменить пакет, а потом послать, плюс по наблюдениям по мимо одного этого пакета там посылаются другие пакеты которые похожи как две капли воды при других изменения что наводит меня на мысль что есть пакет который открывает возможность писать в мышь, а потом закрывает возможность(это моё предположение или шизофрения)

проблема в том что нету такой программы где можно поставить бреак поинт, изменить пакет, а потом послать,

Так напиши её. Никто тут не знает на чём ты пишешь. Но направления тебе дали.

наводит меня на мысль что есть пакет который открывает возможность писать в мышь, а потом закрывает возможность

По этому я и сказал сразу про дизассемблер.

Да той же Гидрой открой. Твоя задача понять порядок вызовов. Понять что пишут, какие поля, есть ли CRC, и т.д. и т.п.

Сопоставить с записью Wireshark, и разобрать где запрос-ответ на изменения, а где поток не нужных тебе данных.

Я плохой программист, допустим пайтон, видимо действительно придеться углубиться в настоящий дизассемблинг, ну спасибо хоть на этом

Теперь всё ясно. Нужно такое в самом описании темы в первом сообщении. Что четко ясно хочется конкретно управлять цветами подсветки мыши