I hadn't checked this thread for a while, but I independently came to the same solution randomize did, somewhat inspired by sprite's work. I was able to dump the 128KB flash and the 8KB read-only boot loader directly from the Pok3r over USB, after running the patched v1.1.7 updater. All three are attached if anyone else wants to look at them. I take no responsibility if the patched updater bricks your keyboard, you have been warned.
The flash image is set at 0x0 in the ARM memory map, and the bootloader image is set at 0x1F000000. I haven't tried dumping the entirety of the address space, but everywhere else, including peripheral registers and SRAM seems to read 0's. It seems most likely there is another test in the program before the function randomize and I each changed.
As far as I can tell, there are three vector tables between the two images, at 0x0 and 0x2C00 in the flash image, and 0x0 in the boot loader.
I've also done some reading in the HT32 user manual, trying to figure out the program flow of the whole firmware. The boot pins on the processor are both grounded, so according to the manual, the program counter should start at the value of the SBVT1 register, with reset value 0x20000155. This doesn't make sense to me, since SRAM is volatile. If anyone knows what I'm missing here, it'd be great to know. Datasheet and user manual are attached, just for simplicity.
I wrote my own code for decoding firmware from the updaters, encoding patched firmware back into an updater, and reading from the keyboard in C++. I'll eventually make my version of the code public, but it's tangled up in my personal C++ libraries, which I haven't made public yet. I have a bunch of small projects to clean up and release at some point.
Also, for disassembling code, I like to use
arm-none-eabi-objdump -D -EL -b binary -m arm -M force-thumb firmware.bin
I have investigated JTAG options on the HT32 in the Pok3r. Fortunately, the chip does not need to be desoldered to connect a debugger to it. There is an unpopulated 5-pin header on the board (CN2), which exposes SWD signals. The pinout is (from 1 to 5, pin 1 is denoted by square pad) 3.3V, SWDIO, SWCLK, nRST, GND. Unfortunately, SWD support isn't very good in many debug interfaces or software. I wasn't able to get it to work with a JLink.
I think the end goal of this project should be an alternative to the official updaters, so it may be more useful to figure out how the existing bootloader and USB code are implemented. This way, the firmware can be rolled back by the official updaters. Just in case vortex releases new features, people can have the option to update to it.
I just wanted to join this conversation, put in my two cents. Thoughts and ideas appreciated.