[OneDev #27] peripherals: trim Frida 437-write replay to minimum activation subset #12

Open
opened 2026-05-24 04:46:37 +00:00 by joseph · 0 comments
Owner

Imported from OneDev issue #27 (id 35527)
Original project: internal-joseph
Original state: Open
Original submitterId: 5
Original submitDate: 2026-05-05T15:31:36.771+00:00
Original lastActivity: {'date': '2026-05-05T15:31:36.771+00:00', 'description': 'opened', 'userId': 5}

Original fields:

  • Type: New Feature
  • Priority: Normal
  • Assignees: None

Context

peripherals/scripts/g915x_open_writes_frida.txt is a literal 437-write replay of what G HUB does during init. It works (vendetta achieved 2026-05-05), but most of those writes are RGB streaming, profile-data paging, periodic state polling, etc. — NOT required to put the keyboard in event-emit mode.

Goal

Find the smallest subset that still activates feat=0x1B05 event-emit, then ship that as the canonical sequence. Faster startup, less surface area for breakage on G HUB updates.

Approach

  1. Bisect: split 437 in half, replay first half + verify event mode active. If yes, recurse on first half. If no, recurse on second half.
  2. Likely candidates for the required subset (per v3/v4 Ghidra findings):
    • feat=00 ROOT lookups for 0x1B05, 0x8101, 0x8051
    • feat=0c fn=8 LONG (14 calls) — the v4 missing piece
    • feat=0d cookie + setFKCState handshake (5 calls per FKC.start trace)
    • feat=0e LogiModifiers config
  3. Likely not required:
    • All feat=06 RGB writes
    • All feat=0c fn=c memory paging reads (those are reads disguised as writes — probably state queries)
    • feat=07 PER_KEY_LIGHTING setup

Done when

  • Sequence is < 100 writes (target: < 50)
  • Replay activates event-emit cold from a freshly-killed-G-HUB state
  • Documented per-write purpose so future G HUB versions can be diffed against this baseline

Files

  • peripherals/scripts/g915x_open_writes_frida.txt (current 437)
  • peripherals/scripts/g915x_open.py (replay tool)
  • peripherals/lghub-agent-handshake-findings-v4.md (Ghidra-derived call list)
Imported from OneDev issue #27 (id 35527) Original project: internal-joseph Original state: Open Original submitterId: 5 Original submitDate: 2026-05-05T15:31:36.771+00:00 Original lastActivity: {'date': '2026-05-05T15:31:36.771+00:00', 'description': 'opened', 'userId': 5} Original fields: - Type: New Feature - Priority: Normal - Assignees: None ## Context `peripherals/scripts/g915x_open_writes_frida.txt` is a literal 437-write replay of what G HUB does during init. It works (vendetta achieved 2026-05-05), but most of those writes are RGB streaming, profile-data paging, periodic state polling, etc. — NOT required to put the keyboard in event-emit mode. ## Goal Find the smallest subset that still activates `feat=0x1B05` event-emit, then ship that as the canonical sequence. Faster startup, less surface area for breakage on G HUB updates. ## Approach 1. Bisect: split 437 in half, replay first half + verify event mode active. If yes, recurse on first half. If no, recurse on second half. 2. Likely candidates for the *required* subset (per v3/v4 Ghidra findings): - `feat=00` ROOT lookups for `0x1B05`, `0x8101`, `0x8051` - `feat=0c fn=8` LONG (14 calls) — the v4 missing piece - `feat=0d` cookie + setFKCState handshake (5 calls per FKC.start trace) - `feat=0e` LogiModifiers config 3. Likely *not required*: - All `feat=06` RGB writes - All `feat=0c fn=c` memory paging reads (those are reads disguised as writes — probably state queries) - `feat=07` PER_KEY_LIGHTING setup ## Done when - [ ] Sequence is < 100 writes (target: < 50) - [ ] Replay activates event-emit cold from a freshly-killed-G-HUB state - [ ] Documented per-write purpose so future G HUB versions can be diffed against this baseline ## Files - `peripherals/scripts/g915x_open_writes_frida.txt` (current 437) - `peripherals/scripts/g915x_open.py` (replay tool) - `peripherals/lghub-agent-handshake-findings-v4.md` (Ghidra-derived call list)
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
joseph/internal-joseph#12
No description provided.