swiftgeek / hykker-re Goto Github PK

Existing reverse engineering projects:

• https://github.com/gashtaan/sinowealth-8051-dumper/
• @castleberrysam gists describing USB HID fw update protocol
  • https://gist.github.com/castleberrysam/a0bb370382339acfaac461a2359d0f94
  • https://gist.github.com/castleberrysam/2510f3e87b3d313a27320f165ef5e1cc (Image extractor/decrypter for BYK8xx firmware updater utilities)
    • Sadly updates do not contain ISP area, so we need to dump it from MCU if it happens to not implement compatible USB protocol (and may implement UART instead of USB)
    • @castleberrysam mentions here BYK870 to be SH79F6489 (LQFP80)
  • https://gist.github.com/castleberrysam/755c3abfdc996c1dd1a294c74286f5eb (pin mapping/function for BYK870)
  • https://github.com/castleberrysam/byk870-fw
• BYK916 key remap
• HID fw update tool written in rust for MCUs using sinowealth's USB ISP code - currently only tested with BYK916

SH68F881-specific findings

Should be not related to firmware it's running (BYK801)
Normally LQFP64 package would have "SH68F881Q" marking (when chip package marking is not customized - like it is the case for BYK801)

• INSCON.BKS0 (SFR 0x86, bit6) is utilized in SH68F881
  • Most noticeable near routines using USB and in headers where mutliple peripheral SFRs points into the same SFR address
  • From ghidra:
    • uVar1 = read_volatile_1(0x86);
    • write_volatile_1(0x86, uVar1 | 0x40);
  • Some SFRs are present at the same address, in both banks, while others aren't despite lack of conflict. No rule whatsoever as seen in SH79F3283
  • G80F930A (sinowealth rebrand) likely shows banking split/location for FLASH/USB/EUART/SPI/PWM/CLOCK/WDT/BT/TIMER2/TIMER3/GPIO/Interrupt registers
    • Missing TIMER0/1 and ISP registers
• Due to above, from public datasheets, SH88F6161/6162 is likely most similar when it comes to how general memory map works (actual registers are different)

SFRs

• Current state of mapping registers in SH68F881 (as datasheet is not available)
• Some SFRs are missing from both headers and G80F930A datasheet, yet they are used in firmware. Though they are merely cleared during init (one function in ISP fw and one in main firmware):
  • 92h 93h 95h A2h AAh ABh ACh ADh
• Since SFRs are banked and I don't know how to deal with it, ghidra pspec uses format of BANK0_SFR__BANK1_SFR and BANK0_SFR__BANK1_SFR.BANK0_BIT__BANK1_BIT for bit addressable registers
• In disassembly SFR bank switching is done by single instruction:
  • Switch to bank 1: ORL INSCON,#0x40
  • Switch to bank 0: ANL INSCON,#0x3f (Bank selection field is 2 bit wide)

ISP

ISP is a firmware block typically at end of (flash/otp/mask) ROM memory space - last 1KiB sector. May use different storage technology to main code area depending on particular chip. There are also some logic features associated with it, allowing for:

• Starting on POR from main or ISP area depending on special area setting
• Entering ISP based on pin strapping. Typically two GPIO pins pulled to GND. Which ones depends on particular chip part number.
• Software reset to/from ISP area via ISPLO/ISPCON register write sequence.
  • Documented in SH88F6161/6162 (CN) and (EN)
• Jump from main FW to ISP entry point via instruction sequence (Documented in SH61F83)
• When MCU is strapped to run ISP code (either by pins or options), it will start from 0x7C00

8051 extensions

• 16-bit operand extension via AUXC and INSCON (MUL/DIV)
• Two data pointers - DPTR and DPTR1, selected via INSCON.DPS

KEIL summary

Contained in one of SH51.CDB μVision Device Databases:

8051 based Full Static CMOS controller with two-Level Program Memory Lock
72 I/O lines, 3 Timers/Counters, 13 Interrupts sources, 1 BaseTimer, 3 PWM, UART,
WDT, LVR, Regulator, SPI, Full Speed USB,
32K Flash Memory, 2560 Bytes On-chip RAM, 2048 Byte EEPROM

IRAM(0 - 0xFF) IROM(0-0x7FFF) XRAM(0-0x8FF) CLOCK(24000000)

strings SH51.CDB | grep '^SH68F881$' -A13
Though sinowealth's *.CDB files don't match datasheets perfectly, so take it with a grain of salt, especially on interrupt sources count

Pinout of MCU itself

• USB is likely to be on P0.2 and P0.3
• SET2/DG5 is likely also on P0 and likely provides EUART TXD/RXD. Which would be pretty convenient as it's N/C on this particular board.
• JTAG is on P4. One indication of that is in GPT/OPT files explicitly mentioning P4.7 having R̅E̅S̅E̅T̅ alt function.
  • P4.0 - TDO
  • P4.1 - TMS
  • P4.2 - TDI
  • P4.3 - TCK
  • P4.7 - R̅E̅S̅E̅T̅
• Indicator LEDs (BYK801):
  • Pin1 - P3.5 - SCRLOCK
  • Pin2 - P3.6 - CAPSLOCK
  • Pin3 - P3.7 - NUMLOCK
• So far it looks like pinout is going to roughly match LQFP64 SH79F6489. Previously BYK870 was identified to be that chip, but for LQFP80. Peripheral wise, SH68F881 doesn't have ADCs/LCD driver/OP/PGA. Headers would also indicate that SH68F881 has more timers, but that was not confirmed yet
• SP6/2.0 on PCB next to JTAG port means Pitch 2.00mm, and not GPIO Port P2.0. Schematics to be updated.

USB RAM

Likely 0A00H - 0AAFH , since XRAM and USB RAM ranges seem to be paired together. But that's just a guess for now
0A00H - 0AAFH - Confirmed with BYK801 firmware

Dangerous pins connected to straight into some rail, that could be fried very easily when misconfigured:

• RS1 - Pin25 (WTF1 signal) - 0Ω link to GND!
  • It's probably better to replace it with a high value resistor before testing alt firmware
• columns, when rows are driven (or other way around). Two possibilities exist here:
  • GPIOs don't have true "1" state - "0" (GND) path is low impedance but "1" has relatively high impedance acting more like a pull-up (like older MCUs from sinowealth)
  • GPIOs have true low impedance "1" state, and separate configurable pull-up (like newer SH68F90)
• VDP/ USB D+ is connected directly to two pins

Since SH68F88 headers mention PxPCR registers, we have a true GPIO here (like SH68F90)!

Safe pins:

• CAPSLOCK (LED) - unknown register
• NUMLOCK (LED) - unknown register

Describes build I'm using in particular. Different build/fw revision may manifest different behavior

Compiler

Most likely Keil uVision2, since at the time of this board being shipped sinowealth didn't provide packages for newer uVision. JET51A_Keil_V1.8.10.3.zip is the last available sinowealth package for UV2.

Bootloader (ISP FW)

• Extends beyond 1KiB ISP area (0x7C00-0x7FFF) defined by MCU, to cover last 4KiB of flash (0x7000-0x7FFF). BYK916 similarly has 4KiB bootloader at end of flash.
• Reset vector (3 bytes at 0x00) seems to immediately jump to ISP FW (0x7000), so with default firmware looking for ISP pin straps (MCU defined, OP_ISPPIN/OP_ISP) is pointless. Furthermore, ISP pinstrap entrypoint defined by MCU (OP_ISPPIN, 0x7C00) doesn't even appear to be functional in BYK801, as it lands us in the middle of random USB routine!
  • Actually after running host bootloader software once, bootloader seems to have copied contents of 0x6FFB-0x6FFD into 0x0000-0x0002, then filled 0x6FFB-0x6FFD with 0x00. This changed reset vector from 02 70 00 to 02 3b cc
• There appears to be no HID sequence to jump back to ISP FW, as LJMP to 0x7F00 is nowhere to be found.
  • IRQs in pspec fixed this, jump to ISP FW appears in main FW. 0x7F00 entrypoint appears to be functional. 0x7F00 offset is firmware defined (BYK916 has similar entrypoint at 0xFF00)
  • After testing with host bootloader software, it's clear that HID sequence works and USB VID:PID in bootloader is 0603:1020
• ISP FW seems to be waiting for particular state on P0.2 and P0.3 pins, which is likely to correspond to USB D+ and D- pins. Likely follows "USB ISP Boot Circuit" from SH61F83.
• When special P0.2 P0.3 condition is not detected, ISP FW will jump to 0x3BCC entrypoint (defined by ISP FW) in main FW. But when the condition is met, it will first erase 1KiB sector starting from 0x3B00, which would include main FW entrypoint.

Interrupts

• Keil seems to optimize code size so hard, that it places unrelated functions in place of disabled interrupt handlers
• Following interrupts are clearly used due to RETI use:
  • IRQ0
  • IRQ3
  • IRQ5 - TIMER2 perhaps?
  • IRQ8
  • IRQ9
  • IRQ10
  • IRQ11 - USB/EUSB

Disclaimer

I do not have board with BYK916, but I still noticed some things, that would be good to follow/reference.
Some features/pins/polarity might be configurable in firmware.

I'm also prone to making loads of typos, so really please check with the board

Also this only covers BYK916-specific details, see #1 for general ones.

BYK916 pinout (this refers mostly to BYKxxx firmware, and not actual MCU - which is reported to be SH68F90A):

BYK916 kicad symbol (incomplete)

Read SH68F90 CV2.0.pdf for actual MCU pins

BYK916 charge features:
CH - connects to a charge controller, netname after a resistor CHARGE.
USB-CH - simply detects voltage being applied to USB connector

BYK916 connection to BT MCU - Beken BK3632

• CSNA / CLKA / MOSIA / MISOA - SPI/JTAG interface for BK3632, could be used for ICP/ISP of flash in BK3632.
  • Likely relevant repository for SPI flashing protocol, elektroda thread
• P42A (BK3632 GPIO P11) - Unknown, function implemented in BK3632 firmware
• MOTA (BK3632 GPIO P31) - Unknown, function implemented in BK3632 firmware

BYK916 RGB LED driving pins

• Driving pins are most likely called DR(0..5)_(R/G/B)
• V(R/B/G)(0..5) is the net powering led (so after transistors - usually S8050)
• Pin mapping to SH68F90:

Row0:
Red: VR0 -> P4_1
Green: VG0 -> P6_0
Blue: VB0 -> P4_0
Row1:
Red: VR1 -> P0_4
Green: VG1 -> P6_1
Blue: VB1 -> P0_3
Row2:
Red: VR2 -> P6_7
Green: VG2 -> P6_2
Blue: VB2 -> P6_6
Row3:
Red: VR3 -> P0_2
Green: VG3 -> P6_3
Blue: VB3 -> P5_7
Row4:
Red: VR4 -> P4_5
Green: VG4 -> P6_4
Blue: VB4 -> P4_6
Row5:
Red: VR5 -> P4_3
Green: VG5 -> P6_5
Blue: VB5 -> P4_4

Conventions (as on RE-K70-BYK800 board)

• 6 rows of cherry-compatible switches, plate mounted.
  • 1st row - SW0 (ESC) - SW15
  • 2nd row - SW36 - SW20
  • 3rd row - SW37 - SW53
    • Extra SW97-1 instead of SW50
  • 4th row - SW73 - SW62, SW98-1 last
    • Extra SW98-1 instead of SW61
  • 5th row - SW74 - SW86
  • 6th row - SW103 - SW93
    • SW97, SW98 exist in this row despite those extra switches with -1 suffix
• Switch contacts are connected on one side to Rx and other to D_Cx (custom netname, check customizations section)
• Switch LEDs are connected on one side to LEDx (derived from VDD5V) and other to VDRx (derived from GND)
  • What looks like GND pad is actually a very short trace to nearby long trace
  • They are part of switch footprint, despite being two components!
• DRx - Rows for LED diodes muxing DR0 .. DR5
  • DR4 -> RR4 / QR4 / R4
  • DR5 -> RR5 / QR5 / R5
    • Pin3 of QR5 (collector) has netname VDR5
    • Pin2 of QR5 (emitter) is connected to GND
• Rx - Rows for switches muxing - R0 .. R5. Connected directly to switch contacts.
• Cx - Columns for both switch (through diode) and LED muxing (through QCx transistors)
  • C17 -> RC17 -> QC17
    • Pin3 of QC17 (collector) has netname LED17
    • Pin2 of QC17 (emitter) is connected to VDD5V
    • Pin1 of QC17 (base) is connected to RC17 and has netname R_C17 (customized netname)
  • C17 -> SW14 / SW21 / SW52 / SW52 / SW86 / SW94 (connection to switch contact through a diode)

Customizations (deviations from BYKxxx conventions) in this repo:

• Netname between diode and switch contact will be called D_Cx to make it easier to highlight with OpenBoardView using prefix search feature. This way both D_C and C prefixes can be highlighted as regex is not yet supported - usual way would be to have _R/_D/etc suffix. Thanks to this shorted every diode in a column, need to come up with a better netname
• Netname between column transistor (QCxx) base will be called R_Cx for similar reasons as above

Reference pinout (mirrored):