Similar keyboard: KBP v60Mini

[pellettiero]

Hi, I tried your tool with a similar keyboard that shares the same microcontroller as the POK3R, the KBParadise v60Mini. I can confirm your tool works correctly and reads the version after changing the PID:

[00:00:01:359] N Proceeding...
[00:00:01:407] N Opened POK3R
[00:00:01:410] N Version: 1.0.7

Could you give me any indication on how to go on from here? Me and other people have started a repo here, and the decryption already works: https://github.com/pellettiero/V60Mini-firmhack

Thanks!

[ChaoticEnigma]

Very interesting! Thanks for noticing this. It seems there is likely some entity "CYKB" that develops these keyboards and firmware for Vortex, Cooler Master, and KBParadise, at the least. Thus we have seen the same update protocol on a number of Holtek-based keyboards.

I looked at your repo, decrypting the cykb112_v107 firmware worked fine, looks like thumb code to me. The firmware is based at 0x2c00, same as the pok3r.

As for next steps, you will want to disassemble the firmware, write a patch for the update protocol that will allow pok3rtool to read the contents of flash off the chip, circumventing the JTAG flash protection, and upload this patched firmware. With a dump of the whole flash, you can disassemble the bootloader, and get any constant data that may not be included in the firmware updates.

I will poke at that firmware a bit this weekend. I know waaaayyyyy too much about these Holtek chips and Thumb by now, so it shouldn't take too long to make the patch mentioned above, if it's anything like the patch for the pok3r. You can also look at my disassembly of the pok3r firmware, under disassemble/pok3r/v117. Ignore the .sym files, they are used for a super unstable disassembly tool I am working on.

It looks like the KBP v60 Mini uses the HT32F1755, rather than the 1654 and 1655 the Vortex keyboards use. I haven't read up on the differences, but they are probably very similar. The firmware I am working on for the Vortex keyboard would probably work on the KBP v60, accounting for the different matrices.

I've wanted to try a Matias KBP v60 Mini for some time, maybe I'll have to get one now...

[pellettiero]

Hey, thanks for the tips!
Will try to unlock the keyboard now! edit actually waiting for updates, too afraid of bricks :(

EDIT What if I brick it? What will I need to fix it? I also have a solution for the custom firmware, it seems you can implement TMK or QMK by using a Real Time Operating System such as ChibiOS: https://github.com/tmk/tmk_keyboard/blob/master/tmk_core/protocol/chibios/README.md http://chibios.org/dokuwiki/doku.php

[ChaoticEnigma]

Yes, I should elaborate. The reason for patching the firmware and updating it is explicitly to allow the bootloader to be obtained. The bootloader can't be read directly with JTAG, because the flash protection is enabled, so flash can only be read by code executing from flash (not SRAM).

Until you have a copy of the bootloader, you want to be very careful. Once you crack the firmware and have all of the code/data needed, you can connect a JTAG debugger and erase the chip, clearing the flash protection, then write the firmware back. After that, you can be much less careful, since you can always restore it.

I am 3/3 so far, so fingers crossed. If you do end up bricking it, all is not lost. You will need a JTAG debugger (https://www.adafruit.com/product/1369). This is an essential tool for embedded development anyway, so I do recommend. If you get a JTAG debugger, I have a fork (https://github.com/ChaoticConundrum/openocd-ht32) of OpenOCD that supports writing/erasing the HT32 internal flash.

If you end up actually erasing the bootloader, you would have to rewrite it, which might not be difficult, using the pok3r's bootloader for reference.

ChibiOS seems to only support ST chips, so it would take a lot of porting to get TMK working on Holtek chips. I am working on the USB stack for my custom firmware now, once that works, everything else shouldn't be difficult.

[ChaoticEnigma]

Would you be able to perform a USB packet capture of a firmware update on the KBP v60? I am skeptical of the disassembly from the decoded firmware. Parts of it are fine, and other parts are less so. Namely, the reset handler at 0x2d54 jumps to 0x3fc0, which should be a clock init function, but which starts with an undefined instruction. Here is the full disassembly: kbp60.txt

If you could record the USB packets in a firmware update with Wireshark, I can compare what the updater is sending to the keyboard to the decoded firmware, and look for issues with the decoding. For reference: https://wiki.wireshark.org/CaptureSetup/USB

[pellettiero]

Sure, I did one beforehand: pcap.zip

For that reason, I think it's the same as the Pok3r, when the firmware is encrypted and decrypted on the fly in the keyboard, or something like that.

I also have found a porting guide for ChibiOS on other boards, it seems it's not so difficult to port (2nd or 3rd paragraph, I think?) http://wiki.chibios.org/dokuwiki/doku.php?id=chibios:guides:port_guide

edit I found the relevant code that zeroes out the flash, as in the Pok3r:

    1eb2:   2046        movs    r0, #70 ; 0x46
    1eb4:   e8bd 9ff0   ldmia.w sp!, {r4, r5, r6, r7, r8, r9, sl, fp, ip, pc}
    1eb8:   f5a4 5120   sub.w   r1, r4, #10240  ; 0x2800
    1ebc:   f5b1 6f80   cmp.w   r1, #1024   ; 0x400
    1ec0:   d308        bcc.n   0x1ed4
    1ec2:   f5b4 4f78   cmp.w   r4, #63488  ; 0xf800
    1ec6:   d205        bcs.n   0x1ed4
    1ec8:   4a10        ldr r2, [pc, #64]   ; (0x1f0c)
    1eca:   f5a4 4178   sub.w   r1, r4, #63488  ; 0xf800
    1ece:   4291        cmp r1, r2
    1ed0:   d300        bcc.n   0x1ed4
    1ed2:   2000        movs    r0, #0               <======== NOP
    1ed4:   f84b 0025   str.w   r0, [fp, r5, lsl #2]

Hope this helped!

[ChaoticEnigma]

Yes, that's all very useful. I'll look into ChibiOS some more, I'm sure many people would be very happy to have TMK on the pok3r. Their documentation is out of date, but I'll look through the templates and examples. I also need to pin down exactly how TMK builds on top of ChibiOS.

I'm not really sure what to make of that pcap, it doesn't look anything like the pok3r pcaps I have. Maybe I'm looking in the wrong place, but it looks like parts of the protocol may be different.

Either way, it looks like you found the flash reading code at 0x4ad2. Everything around that code looks the same as the pok3r. So, I replaced that 2000 movs r0, #0 with a 46c0 nop, and encrypted the firmware again (run your dec.c again). Then, wrote that back into the exe. Diffing the original and patched exe shows only two bytes different, which would be expected from XOR encryption. Here is the result: cykb112_v107_patched.zip

If you are feeling adventurous, this firmware updater should allow flash to be read out of the KBP v60. Feel free to check my work before risking your keyboard.

This is the same method that originally cracked the pok3r. I believe it is relatively low-risk, because the modified code is only run when you use the read commands. If it has problems, you can always reset to the bootloader and re-flash from there.

If you run that updater and your keyboard seems fine (if it works, I don't know if there is any integrity checking, there wasn't for any of the Vortex keyboards), you can use the pok3rtool dump command. The HT32F1755 has 128k flash, so you shouldn't need to change anything else (besides the VID and PID).

Good luck!

[pellettiero]

Yes, I tried the patched program on Windows, tried to dump the flash and it seems to have worked! :+1: Here's the dumped flash: v60minidump.zip

By looking at the disassembly, I noticed that there are no more zeroes on the important parts of the dump, and it looks like a complete dump, but some instructions are still undefined or illegal, and I don't know if it's normal or not... Also, the version is reported to be 1.0.7id#, is this normal too?

(There's a lot of free space BTW, especially at the end of the dump, they didn't insert too much stuff, apparently) Could you take a look please?

[ChaoticEnigma]

That's very good news. Your flash dump looks perfect, everything is pretty much what I'd expect. Note that there are two pieces of firmware in there, the bootloader at 0x0 and the updateable firmware at 0x2c00. Most of the rest of flash is 0xff, which it erases to. Here are the pieces of firmware: kbpv60_firmware.zip

Do you mean pok3rtool reports the version as 1.0.7id#? That could be, it doesn't look it it has a null terminator in flash, but the length is stored before it.

Since this firmware is the "true" firmware, I compared it to the version decoded from the updater. Here are the highlights:

Similar to the pok3r firmware, part of the firmware is encrypted again in the updater, and decrypted on the keyboard. This is why we want the bootloader, so we can figure out how to do this encryption, and send new firmware to the bootloader with pok3rtool.

Here is the instruction we changed to allow the flash to be read.

The extra data is here is not part of the firmware, it is likely the firmware metadata stored in the updater.

[pellettiero]

Interesting! So what will be the next course of action? Should I try to figure out how the encryption works in the bootloader?

By the way, both pok3rtool and the firmware updater report the version to be 1.0.7id#, when it was just 1.0.7 before, how come is that?

I'll update my repository with the new information, much obliged :1st_place_medal:

[ChaoticEnigma]

My plan so far has been to just replace the updateable firmware and leave the bootloaders intact. This way you can use the official updaters to put the original firmware (or new firmware) back on the keyboards. This also means in order to use pok3rtool to upload custom firmware, we have to encrypt the firmware the way the bootloader expects it.

So, if you want to follow my method, you should reverse-engineer the decryption in the bootloader, and write a class in pok3rtool to implement it. (probably start from the ProtoPOK3R class). If you don't care about backwards compatibility, you could always write a simple new bootloader.

I am working on porting ChibiOS's HAL to the HT32F1655 and 1654, which will cover all the vortex boards. I'll also look at how different the HT32F1755 would be, it may use a lot of the same peripherals.

I don't know why pok3rtool started reading 1.0.7id#. From the flash, I would have expected it to always read that, pok3rtool expect a null terminator. I have to assume the version it was changed at some point, but I don't know why the official updater would do that. I will fix it in pok3rtool, to use the version length right before the string.

[dragonfax]

lovin all of this.

On Sun, Mar 19, 2017 at 11:32 AM Charlie Waters notifications@github.com wrote:

My plan so far has been to just replace the updateable firmware and leave the bootloaders intact. This way you can use the official updaters to put the original firmware (or new firmware) back on the keyboards. This also means in order to use pok3rtool to upload custom firmware, we have to encrypt the firmware the way the bootloader expects it.

So, if you want to follow my method, you should reverse-engineer the decryption in the bootloader, and write a class in pok3rtool to implement it. (probably start from the ProtoPOK3R class). If you don't care about backwards compatibility, you could always write a simple new bootloader.

I am working on porting ChibiOS's HAL to the HT32F1655 and 1654, which will cover all the vortex boards. I'll also look at how different the HT32F1755 would be, it may use a lot of the same peripherals.

I don't know why pok3rtool started reading 1.0.7id#. From the flash, I would have expected it to always read that, pok3rtool expect a null terminator. I have to assume the version it was changed at some point, but I don't know why the official updater would do that. I will fix it in pok3rtool, to use the version length right before the string.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ChaoticConundrum/pok3r_re_firmware/issues/4#issuecomment-287636734, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4_rt_DcgwmG7AzfGC3Boda1dI1Hcvjks5rnXSngaJpZM4MPuPS .

[pellettiero]

Hi, I've got updates:

• Updated my repo with scripts that can unlock or patch the updater and keyboard
• Also, it seems that the XOR key is the exact same between the POK3R and the v60Mini

Pok3r flash from 2188 to 21b8:

    2188:   55aa        strb    r2, [r5, r6]
    218a:   55aa        strb    r2, [r5, r6]
    218c:   aa55        add r2, sp, #340    ; 0x154
    218e:   aa55        add r2, sp, #340    ; 0x154
    2190:   00ff        lsls    r7, r7, #3
    2192:   0000        movs    r0, r0
    2194:   ff00 0000   vhadd.u8    d0, d0, d0
    2198:   0000        movs    r0, r0
    219a:   00ff        lsls    r7, r7, #3
    219c:   0000        movs    r0, r0
    219e:   ff00 0000   vhadd.u8    d0, d0, d0
    21a2:   0000        movs    r0, r0
    21a4:   ffff ffff           ; <UNDEFINED> instruction: 0xffffffff
    21a8:   0f0f        lsrs    r7, r1, #28
    21aa:   0f0f        lsrs    r7, r1, #28
    21ac:   f0f0 f0f0   bl  0x4f2390
    21b0:   aaaa        add r2, sp, #680    ; 0x2a8
    21b2:   aaaa        add r2, sp, #680    ; 0x2a8
    21b4:   5555        strb    r5, [r2, r5]
    21b6:   5555        strb    r5, [r2, r5]
    21b8:   0000        movs    r0, r0

The same is for the v60 from 20f4 to 2124:

    20f4:   55aa        strb    r2, [r5, r6]
    20f6:   55aa        strb    r2, [r5, r6]
    20f8:   aa55        add r2, sp, #340    ; 0x154
    20fa:   aa55        add r2, sp, #340    ; 0x154
    20fc:   00ff        lsls    r7, r7, #3
    20fe:   0000        movs    r0, r0
    2100:   ff00 0000   vhadd.u8    d0, d0, d0
    2104:   0000        movs    r0, r0
    2106:   00ff        lsls    r7, r7, #3
    2108:   0000        movs    r0, r0
    210a:   ff00 0000   vhadd.u8    d0, d0, d0
    210e:   0000        movs    r0, r0
    2110:   ffff ffff           ; <UNDEFINED> instruction: 0xffffffff
    2114:   0f0f        lsrs    r7, r1, #28
    2116:   0f0f        lsrs    r7, r1, #28
    2118:   f0f0 f0f0   bl  0x4f22fc
    211c:   aaaa        add r2, sp, #680    ; 0x2a8
    211e:   aaaa        add r2, sp, #680    ; 0x2a8
    2120:   5555        strb    r5, [r2, r5]
    2122:   5555        strb    r5, [r2, r5]
    2124:   0000        movs    r0, r0

I guess the swap key should be the same... but what do I need exactly to write a similar class to ProtoPOK3R?

Thanks!

[ChaoticEnigma]

For the POK3R, there were two sets of encryption. The first is decrypted by the update exe, which we don't need to worry about (and you already broke). After that, part of the firmware is still encrypted (first two images a few comments back), and it is sent to the keyboard like this. The encrypted part of the firmware is decoded on the keyboard. This consists of an XOR and a byte swap.

I just confirmed that the XOR and swap encryption is the same as on the POK3R. However, what I am not sure of is the format this is sent in over USB for the update. When I read through the POK3R update pcaps, I see write addresses, and some bits of unencrypted firmware, like the vector table. I don't see that in the V60mini pcaps, so I believe the update packet format is different, or some other encryption is applied, etc.

I recommend finding the place USB packets are handled in the firmware, and following how they are handled/decoded for write commands. This is the direct reverse-engineering approach, which I did for the POK3R RGB. It is fairly tedious, but at least you know exactly what's going on. You can use the POK3R firmware as a guide to find the code you're looking for.

[pellettiero]

Just a second though: what did you use to sniff the USB packets? UsbPCap or a Windows VM under Linux?

That's because my pcap is encapsulated with USBPcap on Windows, and it's different from the packets under usbmon.

Thanks!

[ChaoticEnigma]

The POK3R packet captures I'm using for comparison were captured with USBPcap through Wireshark on Windows. The pcap you sent me earlier in this thread has the same packet headers, size, etc. I'm looking at the "Leftover Capture Data" (e.g. the payload) of USB interrupt transfers to the keyboard.

If you open the v60mini.pcap in wireshark and use the filter usb.device_address == 2 && usb.transfer_type == 1 && (usb.endpoint_number.endpoint == 3 || usb.endpoint_number.endpoint == 4), you should see the entire captured conversation with the keyboard update protocol.

Packet 352 in that capture looks exactly like the response to the command that would read the version number (same data as flash for the version number, except 1.0.6 instead of 1.0.7).

v60mini.pcap, Frame 352 IN
0000
0010                                    05 00 00 00 31             ....1
0020   2e 30 2e 36 00 00 00 ff ff ff ff ff ff ff ff ff  .0.6............
0030   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
0040   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
0050   ff ff ff ff ff ff ff ff ff ff ff                 ...........

Compare this to the POK3R response packet 545 in dump/to117.pcapng in this repo. So, 352 looks normal.

dump/to117.pcapng, Frame 545 IN
0000
0010                                    05 00 00 00 31             ....1
0020   2e 31 2e 37 00 00 00 ff ff ff ff ff ff ff ff ff  .1.7............
0030   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
0040   ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
0050   ff ff ff ff ff ff ff ff ff ff ff                 ...........

Before it, packet 544 sends the read command, to read 52 bytes from 0x2800.

dump/to117.pcapng, Frame 544 OUT
0000
0010                                    01 02 7c 79 00            ...|y.
0020   28 00 00 3c 28 00 00 00 00 00 00 00 00 00 00 00  (..<(...........
0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050   00 00 00 00 00 00 00 00 00 00 00                 ...........

But on the v60mini capture, what should be the read command doesn't look right at all.

v60mini.pcap, Frame 351 OUT
0000
0010                                    be 21 98 f1 89             .!...
0020   57 cd 25 fc 63 d1 5f 23 6d 8d c5 fd 17 77 78 06  W.%.c._#m....wx.
0030   6b 77 ef ef 72 75 17 c2 85 ef cd 41 ce f7 d8 00  kw..ru.....A....
0040   37 b2 20 f4 51 d6 d8 75 8a 7c 24 eb 66 39 09 7d  7. .Q..u.|$.f9.}
0050   3c 59 2d 89 bf 1b a6 c8 19 65 85                 <Y-......e.

In fact, all of the OUT packets in the v60mini capture look like this, as opposed to the clear format in the POK3R OUT command packets. I can't make much of it, which is why I have no idea if the flash update commands are the same as the POK3R.

Actually, given these packets, I don't know how pok3rtool is even able to read the version from the v60mini. Generally I would solve mysteries like this before writing more code.

[pellettiero]

Well, I have another pcap captured yesterday on the update to the patched version, maybe that one's too old or I didn't capture it right. Could you take a look at it and see if it's somehow different? v60.zip

In the meantime, I'll try to figure out something by confronting the flash and the packets. Edit yeah the pcap is now in a different format (pcapng), maybe the old one has something different Cheers!

0-47: Keyboard connected via USB 48-187: Bootloader mode via updater 188-688: Flash erase, write and CRC, reboot to system

edit2 It seems that the version is actually sent 2 times in this pcap? (174, 184)
Also the version is still written inside as 1.0.7id#... wat?

edit3 It seems that pok3rtool is also capable of rebooting the keyboard into bootloader and out. I also confirm that the keyboard has indeed a fallback firmware in the bootloader, I can still type only basic keys, but not the advanced functions such as light control and arrow keys. What if the flash command is the exact same? (won't try though, too risky) What I don't understand is how these commands are already working, because the OUT packets in the pcap are garbled. It's obvious that the updater encrypts the packets before sending them, but maybe something will come out if we decode the packets with the updater key?
btw the updater key is inside dec.c

edit4 Here's an excerpt from an old conversation with Sprite on Reddit:

I've been looking through the code. It seems like both the USB data as well as the stored data in the exe are encrypted. I can't really find out the way the USB data is encrypted, but the firmware updater looks like a trivial encryption: I see a bunch of patterns where the firmware likely contains FFFFFF's. The encryption of the USB protocol probably isn't very hard either: signsearch sees no proof of encryption constants except for a signature of a rand() implementation.

The flash packets probably also are obfuscated in some way; because the updater knows how this works, you may be best off disassembling that or the full firmware. And yes, you will require to do a full dump, if only so you can fix the keyboard when you mess it up.

Basically the USB data packets are encrypted with a rand() implementation, and the problem is where to find it? The POK3R fw doesn't use it, weird.

edit5 yep, there it is: (from signsrch on the patched updater exe)

  offset   num  description [bits.endian.size]
  --------------------------------------------
...
.
  0043a837 1299 classical random incrementer 0x343FD 0x269EC3 [32.le.8&]      <===== here
  004490e8 2545 anti-debug: IsDebuggerPresent [..17]
  00458b54 3032 PADDINGXXPADDING [..16]

- 3 signatures found in the file in 1 seconds
- done

signsrch also can place an INT3 byte for debugging on the rand() offset. Tried it out, it interrupts when I press on the "Connect" button. Coincidence? I don't think so. Pity I don't have a JIT debugger.

[ChaoticEnigma]

Thanks for the info. The pcap looks about the same, with a different version number returned from the read commands. The version is written as 1.0.7id#, but before that the length is still 5, so it should really be read as 1.0.7. I don't know why they added the id#.

As for this encryption, I don't completely get how it works yet, but I have learned some things. I've done more disassembly on the v60mini firmware, and compared the code to the POK3R firmware. v60mini_v107_firmware.s.txt v60mini_bootloader.s.txt The code is very similar between the pok3r and the v60mini. The "decryption" is done in handle_update_packet, and the decrypt_packet_byte functions. The interesting bit is that there is a path for it to skip the "decryption" and pass through the packet, and that this decryption is done the same for every command, so if the unencrypted read / reboot commands work from pok3rtool, write commands should work.

The safest way to test this would be to use the pok3rtool to set the version string, because this uses the same write commands as the firmware update. If that works, I would expect a firmware update to work.

[pellettiero]

% sudo ./pok3rtool -t pok3r setversion 9.9.9
[00:00:00:000] E WARNING: THIS TOOL IS RELATIVELY UNTESTED, AND HAS A VERY REAL RISK OF CORRUPTING YOUR POK3R OR POK3R RGB, MAKING IT UNUSABLE WITHOUT EXPENSIVE DEVELOPMENT TOOLS. PROCEED AT YOUR OWN RISK.
[00:00:00:000] E Type "OK" to continue:
OK
[00:00:03:536] N Proceeding...
[00:00:03:539] N Opened POK3R
[00:00:03:542] N Old Version: 1.0.8
[00:00:03:542] N Reset to Bootloader
[00:00:05:545] N Clear Version
[00:00:05:577] N Write Version: 9.9.9
[00:00:05:581] N New Version: 9.9.9
[00:00:05:581] N true
[00:00:05:581] N Reset to Firmware
[00:00:07:623] N true
% sudo ./pok3rtool -t pok3r version
[00:00:00:003] N Opened POK3R
[00:00:00:006] N Version: 9.9.9

It works! Very nice!
This should mean that the flash is safe to write to, right?

But that doesn't solve the problem of how the USB packets are actually encrypted and how to decrypt them eventually, just to be safe.

The only thing left to try is the actual firmware update from pok3rtool... If I somehow recklessly wanted to try, what file should I use to flash that?

Cheers!

[ChaoticEnigma]

Very nice. Yes, a firmware update should work. I've done everything I can to make the update procedure as safe as possible. Use the firmware_v107.bin image I sent earlier: kbpv60_firmware.zip. This was dumped from the keyboard, so we know that it works. While there is some safety from uploading non-firmware files on the keyboard (it checks the stack and reset vectors), uploading the wrong firmware can cause the keyboard to get stuck, preventing another update.

So, sudo ./pok3rtool -t pok3r flash "1.0.7b" firmware_v107.bin. (don't do this on an actual pok3r, this assumes you're using the v60mini vid/pid)

Also, what are the USB VID and PID for the v60 mini? It looks like it will be simple to add "support" to pok3rtool.

As for the encryption... the same code is present in the pok3r firmware, but it never did anything, so I never figured it out then. I can't think of any reason we would want to encrypt update packets, now that we've reverse engineered it. I would say we are completely safe just using the unencrypted update commands. There won't be any new information in those encrypted packets.

If you want to implement that encryption / decryption as an exercise, be my guest, but I'd say you don't strictly need to.

[pellettiero]

As for the encryption... the same code is present in the pok3r firmware, but it never did anything

Oh, alright then. Guess I'll call it a day then.

Output from lsusb: Bus 002 Device 013: ID 04d9:0112 Holtek Semiconductor, Inc. Basically just changed the IDs in proto_pok3r.h https://github.com/pellettiero/pok3rtool-v60mini EDIT

[00:00:00:000] E WARNING: THIS TOOL IS RELATIVELY UNTESTED, AND HAS A VERY REAL RISK OF CORRUPTING YOUR POK3R OR POK3R RGB, MAKING IT UNUSABLE WITHOUT EXPENSIVE DEVELOPMENT TOOLS. PROCEED AT YOUR OWN RISK.
[00:00:00:000] E Type "OK" to continue:
OK
[00:00:07:461] N Proceeding...
[00:00:07:464] N Opened POK3R
[00:00:07:465] N Update Firmware: firmware_v107.bin
[00:00:07:465] N Reset to Bootloader
[00:00:09:469] N Current Version: 1.0.7
[00:00:09:470] N Clear Version
[00:00:09:504] N Erase...
[00:00:11:506] N Write...
[00:00:11:745] N Check...
[00:00:11:938] N Clear Version
[00:00:11:971] N Write Version: 1.0.7b
[00:00:11:975] N New Version: 1.0.7b
[00:00:11:975] N Reset to Firmware
[00:00:14:019] N true

YESSSS! IT WORKS!!! The keyboard works exactly as before, it changed only the version!

[pellettiero]

Man, that's great! The only thing left is porting TMK or QMK with ChibiOS! I'd like to help however, in the limit of my possibilities, with the developing...

Speaking of which, is there a way to boot a firmware directly from USB instead of flashing it every time? I guess this should involve modding the bootloader to allow this, though I don't even know if it's possible to accomplish (as an anti-brick method, just reboot keyboard to have it working again, or boot into DFU unless a key is hold, something like that. Also flash can wear out after many writes)

I would like to thank you again for all the help and I'm looking forward to hear what you think.

[ChaoticEnigma]

That's great news! It takes 2 lines to add support for the the KBP v60 mini to pok3rtool, so I will do that shortly. Yes, TMK / ChibiOS porting is in the works. Because of all the forks involved it lives in another repository. I will push it to github when there is something interesting to show. (by the way, QMK is an AVR-only fork of TMK, and AFAIK doesn't use ChibiOS).

As for booting from USB, you could write a bootloader to download firmware to SRAM, and jump to it. The trouble is, the size of SRAM is very limited, and the firmware also uses some SRAM. Here is the breakdown of the chips and firmware:

Chip	SRAM Size
HT32F1655	32KB
HT32F1654	16KB
HT32F1755	32KB

Keyboard	Firmware Size	Chip	Fits?
POK3R	25KB	HT32F1655	Probably
POK3R RGB	20KB	HT32F1654	No
CORE	20KB	HT32F1654	No
KBP V60 Mini	10KB	HT32F1755	Yes

It may work for some, but you would have to link it very carefully. It's not a bad idea, but I'm not personally worried about bricking a board (JTAG debugger totally worth it).

Also, it would really be pretty difficult to wear out a flash chip by manually rewriting it for each code change. Typically flash chips can be erased tens to hundreds of thousands of times, so issues are only usually encountered when you have something that periodically writes the flash for a long time. I expect the HT32 chips use NOR flash, but the documentation doesn't confirm this.

Well, we have firmware, and we can flash the v60mini, so I think I can close this issue now. When I've made some more progress with ChibiOS for the HT32F1654 and 1655, I'll make it public, and if you want, you could try your hand at porting it for the 1755 too. That will be done eventually one way or another, because I think I've seen at least one other keyboard that uses the 1755.

Cheers!

[pellettiero]

Thanks for adding support to your tool, I appreciate it. Anyway, I just remembered I have a Raspberry Pi that I could use that as a JTAG programmer device using GPIO pins (openocd has support for this), so maybe I'll arrange something.

Cheers!