2

This is my first reverse engineering project! I recently bought a Ducky Mini keyboard, which is controlled by an ARM Cortex-M3 SoC (to be specific, a Holtek HT32F1655,) and noticed that other keyboards based on the same or similar chips have had their firmware successfully modified, such as a Quickfire Rapid playing snake.

Using the link above as a guide (albeit a crude one - the article was written as more of a general process than a guide to firmware hacking these keyboards,) I've started work on creating CFW for the Ducky Mini (which will hopefully work later on any Holtek32-based keyboards such as the Poker 2 and Pok3r.)

My progress so far: I've successfully isolated the firmware from an executable updater released by Ducky, and accomplished XOR decryption to scrambled and partially encrypted assembly code. From what's disassemblable, I believe I've found and fixed the small bit of assembly that prevents reading flash data over USB past 0x2C00 (the keyboard firmware version is held in a memory region between 0x2800 and 0x2C00 for simplicity,) something similar to the Quickfire Rapid. I'm far from an expert at ARM assembly, and following segmented code in IDA is a pain, but I'm pretty sure the small changes I made were correct.

Where I'm stuck: The author of the article above mentions writing a small program using libusb to dump the unencrypted firmware directly from the keyboard. Unfortunately, I have absolutely none of the knowledge of libusb or USB protocols needed to accomplish this step. Thus, I can't even confirm that the changes to the firmware I've made make the flash readable past 0x2C00, let alone allow me to dump the firmware. Can someone interested and experienced help here?

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.