Documentation

[ghost]

Hi,

I'm interested in dumping the firmware of a GK61 keyboard, but can't modify it exactly as you have done, since my firmware might differ slightly.

How did you get a hold of and reverse engineer the firmware in the first place? Are you using a chip programmer from the manufacturer (e.g Weltrend)?

[wgwoods]

Are you using a chip programmer from the manufacturer (e.g Weltrend)?

Nope, this was all software. Used Wireshark to watch USB traffic while running the Windows GK6x tools/drivers in a qemu VM w/USB passthru. Reconstructed the firmware blob from a packet dump of a firmware update.

(The firmware images are in the firmware update utility, but they're obfuscated/encrypted. I'm still not sure how that algorithm works; luckily decryption happens in the firmware utility, which then sends the decoded/decrypted firmware image over USB, and packet dumping was much easier than breaking unknown crypto or reverse-engineering Windows binaries.)

If you want to follow this path, I'm 99% sure the GK61 uses the same USB protocol as the other GK6x keyboards. And it might be possible to just run Wireshark on the Windows system itself - no idea, haven't tried it, YMMV. But once you get a firmware update traffic dump it's not too hard to reconstruct the firmware image. I think I did it interactively/by hand using Scapy - so I don't have code here to help with that, but I'll check my backups and see if I can find anything.

Once you manage to get a complete, decoded firmware dump, you just need a disassembler that handles nds32 - it's supported by GNU Binutils 2.25 or newer, and I think there's a prebuilt nds32 toolchain in the v4.2.0 BSP offered on knect.me. I also hacked nds32 disassembly support into radare2 to help with the reverse-engineering... but it looks like I never pushed my code. Guess I should go dig out my old laptop and find that, too.

Finally, once I found a function in the firmware dump that was accessing host-provided memory addresses, I hand-edited the firmware binary to remove the bounds check on the address, uploaded that firmware, and used that to get a full dump of the chip's flash. Simple, right?

Anyway, I did all of this while on break from work for 6 weeks, two years ago. It was good fun but sadly the sketchy English-language WT59F164 datasheet I once managed to find has gone missing (I have screenshots of a couple pages, but that's it). I just don't have the time or energy to continue fumbling around in the dark trying to figure it all out myself. In the end I bought a different keyboard with a well-documented ARM chip and moved on.

I'm still happy to help share what I learned, but without info/datasheets from Weltrend or Semitek or Jikedingzhi I don't know how how far you're gonna get. Still, best of luck!

[ghost]

Thank you so much for the comprehensive reply. I have never sniffed USB packets, but that's all the more reason to finally start getting into it 😀.

In the meantime I've found a great little project which allows configuring the keyboard more easily (and on linux without a VM), which fulfills most of my needs.

If I do eventually get frustrated enough with it and try to write my own firmware, I will be sure to leave a post about it here. Thanks again.