Notes on the GK64 USB protocol

gk64-usb-notes.md

notes on reverse-engineering the iGK6X USB protocol

Basic info:

• Packets are 0x40 (64) bytes long
  • Byte 0-1: Command & Subcommand
  • Byte 2-3: Offset (or Result for packets from keyboard)
  • Byte 4: padding? (always 00)
  • Byte 5: Size of payload (max 0x38)
  • Byte 6-7: checksum
    • CRC16/CCITT-FALSE: little-endian, polynomial 0x1021, IV 0xFFFF
  • Byte 8-63: payload

Commands are normally sent to endpoint 4 and get answers from endpoint 3.

In firmware update mode, send to endpoint 2 and get answers on 1.

USB Command Info (in Keyboard mode)

• Command 01: Get Info
  • 01:01 (no data): replies with Result 01, data 01 39 10 02 12 01 00 00
    • gotta be version ID - after update... data 01 39 10 02 09 01 00 00
    • yoooooo the firmware filename: 02-1039-01
  • 01:02 (no data): replies with Result 01, data ff ff ff ff ff ff ff ff
  • 01:08 (no data): replies with Result 01, data 0c 00 12 27 00 00 6a f0
  • 01:09 (no data): replies with Result 01, data 0f 08 00 00 00 00 00 00
• Command 03: Reset / Switch Mode
  • 03:01 (no data): reply Result 01, reboots into Keyboard Mode
    • ID 1ea7:0907
    • iManufacturer 1 SEMITEK
    • iProduct 2 USB-HID Gaming Keyboard
    • iSerial 3 SN0000000001
  • 03:02 (no data): reply Result 01, reboots into CDBoot Mode
    • ID 1ea7:0905
    • iManufacturer 1 SEMITE
    • iProduct 2 CDBoot
    • iSerial 0
  • 03:03 (no data): reply Result 01, reboots into Factory Reset Mode(?)
    • ID 040b:6821 Weltrend Semiconductor
    • iManufacturer 1 .
    • iProduct 2 USB Device
    • iSerial 0

USB Command Info (in CDBoot mode)

• Command 02: Update Firmware / Send Data?
  • 02:01 (no off/size, 0x20 bytes of .bimg header)
  • 02:02 (offset, size, data) - send (unscrambled) .bin data
    • .bimg is descrambled to .bin in the driver on the host side!
  • 02:03 (no off/size, 8 byte struct)
    • sent immediately after finishing .bin upload
    • first 4 bytes are timestamp (little-endian)
    • last two bytes are different every time (checksum?)
  • 02:05 (no off/size, data 0c 00 12 27 00 00 6a f0)
    • sent immediately after 02:03, response is the same data
    • HEYYYY THAT'S THE REPLY FROM 01:08!!
    • recovery tool doesn't do this..?

Messing with the device via pyusb

Commands that give a reply:

• 1:1, 1:2, 1:8, 1:9

Commands that respond with NAK:

• 4:1 - 4:254
• 11:{01,02,03,04,05}
  • that's 0x0b, decimal 11
• 12:1 - 12:254

Commands that respond with.. the last reply??

• 11:6, 11:15, 11:17, 11:18
• 11:10: replies with extremely weird packet:

00 00 00 00 00 00 00 00  00 00 00 00 ff ff ff ff   ........ ........
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ........ ........

Info gleaned from disassembly

As far as I can tell from the firmware disassembly, it understands the following COMMAND bytes (in hex):

01, 03, 04, 0b, 0c, 15, 16, 17, 1a, 1f, 22, 23, 24, 25, 26, 27, 31

(Notably missing: 02, which is used by the firmware updater...)

Here's a list of the commands that the firmware seems to handle, plus what I think they're used for.

• 01: Device Info
• 03: Reset / switch mode