Spørgsmål:
Brug for hjælp til en USB-gamingmus
user1475122
2017-09-23 15:46:50 UTC
view on stackexchange narkive permalink

Jeg har en kinesisk USB-gamingmus ( 04d9: a070 ), som har 4 farvetilstande og 4 lysniveauer. Jeg ved med sikkerhed, at denne mus er i stand til at vise mindst 5 forskellige farver, så det skal være en RGB-ledet (4 ben). Softwaren er den værste, jeg nogensinde har set, og det er utroligt svært at ændre farve, lysstyrke og tilstand, så den fungerer og ikke bare slukker. Nu planlægger jeg at lave min egen kontrolsoftware (til Linux først).

Jeg er startet med en simpel guide "Reverse Engineering en USB-mus (Opdateret 3. maj 2017)" hos Bytepunk (kan ikke skriv et link, men Google eller DuckDuckGo skal finde den vejledning)

Jeg har allerede snuset de fleste af de ting, jeg har brug for. Jeg brugte USBlyzer på Windows med den forfærdelige kontrolsoftware og fik et par sekskantstrenge og fandt ud af, hvordan jeg kunne ændre farve, lysstyrke og tilstand i hexstrengene. Jeg indsatte de data, jeg opdagede her (Pastebin) 

  Klik på tænder lys fra Windows kontrolsoftwareout: 07 07 01 00 00 00 00 00 < - Er dette en "Kommandoer, der kommer i opkald"? ud: 07 09 01 02 00 00 00 00 < - 07 09 01 0X hvor X er farvestrålingen: 07 0C 01 04 00 00 00 < - 07 0Y 01 0Z hvor Y er lysstyrken og Z er mode ud: 07 13 04 00 00 00 00 00 < - Er dette et "kommandoer sendt opkald"? X - FRA: 0 RØD: 1 BLÅ: 2 GRØN: 3 ROSE: 4Y - LAV: B MED: 9 HØJ: CZ - STATIK: 1 SLOW PULSE: 2 MED PULSE: 3 HURTIG PULSE: 4

Mit problem er, at når jeg prøver at "skrive" noget til enheden, hænger det bare, og jeg får en "[Errno2] Enhed ikke fundet" fejl, og musen har brug for at blive tilsluttet for at få det til at fungere igen. Det "frakobles" ikke, men det forbliver i lsusb , og intet særligt vises i dmesg.

Jeg har indsat mit modificerede python-script til Pastebin

Jeg anvendte også en brugerdefineret udev-regel

SUBSYSTEM == "usb", ATTR {idVendor} == "04d9", ATTR {idProduct} == "a070", GROUP: = "plugdev", MODE = "0666"

Jeg er ny inden for seriel kommunikation og reverse engineering, så jeg ved ikke, hvad jeg skal søge efter. Jeg tror, ​​jeg kan sende billeder og flere data fra USBlyzer i kommentarerne. Dette er mit første indlæg her, så jeg har ikke ry for at give flere links.

Hilsen, Santeri

En svar:
Spektre
2017-09-24 12:56:30 UTC
view on stackexchange narkive permalink

min forståelse af USB er i bedste fald meget lav (selvom jeg udvikler nogle enkle USB enheder til at leve af) så læs dette med store fordomme ...

  1. Din førerklasse og konfiguration skal matche USB-enheden (mus)

    Jeg ved ikke, hvordan din USB mus er programmeret, men grænsefladen skal være den samme ( CDC klassen kan have flere grænseflader), og hvis den ikke stemmer overens, fungerer USB ikke korrekt.

    Så du skal vide, hvilke rør der bruges, og hvilke der er input og output, hvis de bruger bulk eller afbryder overførsler.

    Min indsats er, at din mus bliver en HID klasse med kun brug af afbryd overførsler. Men hvis det er noget vanvittigt multimedie ergonomisk multifunktions tåbelighed, er det måske endda CDC►.

  2. Overførsel af data

    Lad os antage, at du har HID så enheden kommunikerer med kontrolrør0 og eller afbryder rør (1,2 ...).

    Afhængigt af musen firmware kan det have brug for en bestemt rækkefølge af læse / skrive-kommandoer, ellers fryser firmwaren eller lægger den på indtil timeout.

    For eksempel returnerer nogle kommandoer ingen data og kan sendes når som helst ...

    Nogle kommandoer returnerer data i et bestemt rør, og hvis de ikke læses tilbage af værten i tide, kan firmwaren gå ned / fryse.

    Et andet problem, musen kan være konfigurerbar og anmode om en initialiseringssekvens af koder / kommandoer, der bestemmer musens formål / specifikationer / hvad som helst. Igen, hvis firmwaren forventer det først, kan afsendelse af en hvilken som helst anden kommando fryse din mus.

    Også nogle firmware forventer kommandoer med timing og afsendelse for ofte eller for sjældent er forkert i et sådant tilfælde.

    Dine sniffedata tager ikke højde for noget af dette. Prøv at snuse også de andre rør (måske med tidsstempler) og logge alt til noget som dette:

    Når du er færdig, skal du se, hvad enheden sender tilbage. Det er vigtigt at se, hvor mange byte der er i hvilket rør. Derefter kan du opdatere dit script, og efter at du har sendt din kommando, skal du læse det passende antal bytes tilbage til værten, så din firmware på musen ikke fryser.

1. stort set løst mit problem. Jeg havde den forkerte _bmRequestType_-værdi. Jeg er ikke sikker på hvorfor, men jeg fik en ugyldig værdi fra _USBlyzer_. Jeg brugte _Wireshark_ denne gang og fik den korrekte værdi (0x21). Nu kan jeg styre lysdioderne og andre indstillinger. Tak for forklaringen!
@user1475122 glad for at være til hjælp.


ⓘ
Denne spørgsmål og svar blev automatisk oversat fra det engelske sprog.Det originale indhold er tilgængeligt på stackexchange, som vi takker for den cc by-sa 3.0-licens, den distribueres under.
Loading...