[device-report] BY Tech DELTACO GAMING WK95R

[jja2000]

Device Info

• Sinowealth Device: SH68F90A
• IC Label: BYK916
• Product Page: https://www.deltacogaming.com/product-page/wk95r-wireless-65-keyboard-nordic-layout-white-rgb

Part Info

firmware_size: 61440
vendor_id: 0x258a
product_id: 0x0049

Operations Tested

• Read
• Write

Platforms Tested

• linux
• macos
• windows

Dumps + Checksums

• Stock Firmware MD5: 90a3db2d3547379bae8aa39dc36cade7
• Bootloader MD5: 2d169670eae0d36eae8188562c1f66e8
• Full MD5: 3cb748c30570457f21517de425a4fba9

fw.zip

HID Dump

A dump from usbhid-dump, win-hid-dump or mac-hid-dump

HID Tool Output

# BY Tech DELTACO GAMING WK95R using usbhid-dump
...
001:070:001:DESCRIPTOR         1718872746.363847
 06 01 00 09 80 A1 01 85 01 19 81 29 83 15 00 25
 01 95 03 75 01 81 02 95 01 75 05 81 01 C0 05 0C
 09 01 A1 01 85 02 19 00 2A FF 02 15 00 26 FF 7F
 95 01 75 10 81 00 C0 06 00 FF 09 01 A1 01 85 03
 15 00 26 FF 00 09 2F 75 08 95 03 81 02 C0 05 01
 09 06 A1 01 85 04 05 07 19 04 29 70 15 00 25 01
 75 01 95 78 81 02 C0 06 00 FF 09 01 A1 01 85 05
 15 00 26 FF 00 19 01 29 02 75 08 95 05 B1 02 C0
 06 00 FF 09 01 A1 01 85 06 15 00 26 FF 00 19 01
 29 02 75 08 96 07 04 B1 02 C0 05 01 09 02 A1 01
 85 07 09 01 A1 00 05 09 15 00 25 01 19 01 29 05
 75 01 95 05 81 02 95 03 81 01 05 01 16 00 80 26
 FF 7F 09 30 09 31 75 10 95 02 81 06 15 81 25 7F
 09 38 75 08 95 01 81 06 05 0C 0A 38 02 95 01 81
 06 C0 C0

001:070:000:DESCRIPTOR         1718872746.365858
 05 01 09 06 A1 01 05 07 19 E0 29 E7 15 00 25 01
 95 08 75 01 81 02 95 01 75 08 81 03 95 06 75 08
 15 00 26 FF 00 05 07 19 00 2A FF 00 81 00 25 01
 95 05 75 01 05 08 19 01 29 05 91 02 95 01 75 03
 91 03 C0

PCB Photos

Will take a pic of the rest of the PCB if needed, but I'll have to disassemble it again hahaha.

[carlossless]

@jja2000 thanks for the report!

Stock Firmware MD5: Not sure, is the full one below enough?

You can get this MD5, by not supplying any additional parameters (-b or --full) to the read operation command. I'm also surprised that the bootloader MD5 is one that hasn't been seen until now. Could you share the hex files you got? (main firmware and bootloader, or a full read)

[jja2000]

Hi there!

@jja2000 thanks for the report!

Stock Firmware MD5: Not sure, is the full one below enough?

You can get this MD5, by not supplying any additional parameters (-b or --full) to the read operation command.

I will update OP, thanks!

I'm also surprised that the bootloader MD5 is one that hasn't been seen until now. Could you share the hex files you got? (main firmware and bootloader, or a full read)

Will add those to OP aswell, this is how I got the keyboard out of the box. I did not update the firmware using their driver program.

[jja2000]

Just to add, I'm planning to contribute to SMK if you think that's feasible. But I'd love to make sure that everything is at it's supposed to be before I start porting (considering the brick risk you mention in your blog).

[carlossless]

Thanks for sharing those dumps. I checked the bootloader dump and it's contents were very different from the rest of the bootloaders encountered so far. I then checked the bootloader portion of the full dump and found that the contents are different from the bootloader dump and is actually another instance of 2d169670eae0d36eae8188562c1f66e8. I'm going to go ahead and assume that's the actual checksum here.

I just noticed that you mentioned that the firmware size is 63487 although I'm sure it's actually 61440. Perhaps using that parameter lead to getting that initial bootloader checksum?

But I'd love to make sure that everything is at it's supposed to be before I start porting (considering the brick risk you mention in your blog).

Yeah, those dumps you made should be enough to restore your device to your stock state through the ISP bootloader. If you don't have a sinolink, I would recommend not touching the usb code as it can lead to not being able to boot back into isp through usb. If you do have a sinolink, there's a small modification you should make to the payload before writing back (refered to as the 2nd point here).

[jja2000]

Thanks for sharing those dumps. I checked the bootloader dump and it's contents were very different from the rest of the bootloaders encountered so far. I then checked the bootloader portion of the full dump and found that the contents are different from the bootloader dump and is actually another instance of 2d169670eae0d36eae8188562c1f66e8. I'm going to go ahead and assume that's the actual checksum here.

I just noticed that you mentioned that the firmware size is 63487 although I'm sure it's actually 61440. Perhaps using that parameter lead to getting that initial bootloader checksum?

Could be! I didn't think that parameter always needed to be 61440 so I bisected the proper amount going from a known successful dump at 61440 to a known failed dump at 70000 (it'll throw some index related error which I'm assuming is from having it loop i amount of times where i is the given fw size). 63487 was the last one that didn't fail so I ended up going with that. If you want me to try again with just 61440, let me know.

But I'd love to make sure that everything is at it's supposed to be before I start porting (considering the brick risk you mention in your blog).

Yeah, those dumps you made should be enough to restore your device to your stock state through the ISP bootloader. If you don't have a sinolink, I would recommend not touching the usb code as it can lead to not being able to boot back into isp through usb. If you do have a sinolink, there's a small modification you should make to the payload before writing back (refered to as the 2nd point here).

Good to know! I don't have a sinolink programmer currently, but if shit hits the fan I'll try to buy one. Thanks for the tip on the firmware_size offset. Is there a specific way to modify that if I want to write back the backup?

[carlossless]

Is there a specific way to modify that if I want to write back the backup?

Yeah, here are the steps for modifying the full dump you provided:

1. You need to change the reset vector to LJMP to start the bootloader, instead of the start of the main firmware. In your case change the bytes at 0x0000-0x0002 from 02 00 66 to 02 F0 00.
2. You need to set the LJMP to the start of your firmware at the designated address where the bootloader will look for it. In your case, it will be at 0xEFFB-0xEFFD. Set those blank bytes to 02 00 66.

You can do this by either modifying the ihex file directly (though you will have to recompute the checksums) or converting the ihex file to a binary, modifying the bytes in the binary as described, and converting it back to an ihex. Here's an example of the latter:

objcopy --input-target=ihex --output-target=binary jja2000-deltaco-wk95r-full.hex jja2000-deltaco-wk95r-full.bin
# modify jja2000-deltaco-wk95r-full.bin as described
# I generally use HexFiend on macOS, but there are many other options out there
objcopy --input-target=binary --output-target=ihex jja2000-deltaco-wk95r-full.bin jja2000-deltaco-wk95r-full-jtag-ready.hex

At the end, you will have an ihex file that represents how the firmware and bootloader are actually stored in device flash (bootloader modifications undone) and which is ready to be written through JTAG (via ProWriter).

P.S. I think I should probably build this conversion function into this tool...