Support for Key-combinations possible?

[userx14]

Good evening, the Calibur's standard software seems to only support remapping an key with new functions like menu to mouse left. But for such a small keyboard something like fn+key for numpad or other functionality would be more useful. Do you know how this part of the drevo protocol works in which they download the keymappings on the keyboard / what did you use to reverse engineered the protocol? Because I'm not sure if the current firmware can even support this I tried to find out which processor drevo is using, it says m103cb which reminded me of stm32f103cb, but it seems to be another cip because the quarz pins don't seem to match. Greetings Beny

[Fail-0815]

Do you know how this part of the drevo protocol works in which they download the keymappings on the keyboard / what did you use to reverse engineered the protocol?

Windows VM, passed the keyboard through to it and used Wireshark to monitor usb traffic. I did not look very much into the protocol for macros yet, but i think that simple macros like fn+something should have been possible in the Windows tool. I'll have a look in the near future. (Expect updates within the next 2-3 weeks)

Because I'm not sure if the current firmware can even support this I tried to find out which processor drevo is using, it says m103cb which reminded me of stm32f103cb, but it seems to be another cip because the quarz pins don't seem to match.

I also tried to find out what kind of chip that is, but didn't find out anything more than that. I wanted to take a look into the firmware images Drevo supplied once to help identify what kind of chip this is. I'll update when i find something new.

[userx14]

I have tried to find out what the pinout of the microcontroller is: sorry for the awful drawing: So the 5-pin port seems to be a programming port of some sort, and one of the pins should be something like a reset or boot configuration pin for programming. The device with 8 pins on the left should be a flash memory.

[userx14]

So our microcontroller should have the following pins: USB: 15,16 Oscillator: 44,45 Reset/boot: 46 GND: 1, 12 V+: 11,13,37 Serial for BT: 17,18 Programming Port: 35,36 Flash: 4,5

[Fail-0815]

So, in theory it seems like one could try to attach a UART Bridge/Serial Console to P3. Since the firmware images i have are only for flashing via the supplied (windows exclusive...) flashing utility it's hard to know if these could potentially be directly flashed via P3 + UART. This would at least allow experimentation with the chip, since we could recover from a bricked state.

[userx14]

Yeah, I will try that later today and see if the chip outputs something during bootup... I also inspected the .bin file and they seem to have a regular structure where 0x15 is appearing at the beginning of each line. The beginning and end of the file look interesting too...

[userx14]

Ok, there seems to be no communication at bootup at there pins. The mcu operates at 3.3V and both are on logic high if the mcu is powered.

[userx14]

But there is communication with the flash chip at bootup...

[Fail-0815]

But there is communication with the flash chip at bootup...

I'd suppose lighting and macro config are saved there and loaded on bootup

[userx14]

Very stange, I compared the pinout with nearly every microcontroller available on Mouser and no one matches. So as far as I can tell it can't be an ST, NXP, Atmel, Renesas, Cypress, Microchip, Silicon-Labs. Maybe an analysis of the .bin file would be more productive, I will try that now....

[userx14]

Ok I took a look on the .bin file. First of all the file only contains ascii characters. The characters coming after 15: seem to be the hex characters. I have stripped the number: from the file and converted it into hexadecimal. 71m.zip I would guess it could be thumb assembly. If it is this would be the first vew instructions: 0x0000: ldr r3, [sp, #0x274] 0x0002: str r1, [sp, #0x314] 0x0004: strh r0, [r7, #0x30] 0x0006: lsls r4, r3, #2 0x0008: subs r0, #0x55 0x000a: strb r1, [r7, #0x16] 0x000c: subs r0, r6, r2 0x000e: ldr r6, [sp, #0x68] 0x0010: cmp r7, #0xcb 0x0012: strh r0, [r6, #0xc] 0x0014: adds r2, #0x2a 0x0016: add r4, sp, #0x94 0x0018: str r7, [r0, r4] 0x001a: bgt #0xec 0x001c: stm r4!, {r1, r2} 0x001e: ldm r4, {r1, r3, r4, r5} 0x0020: strb r3, [r1, #0xd] 0x0022: asrs r7, r1, #0xe 0x0024: ldr r5, [r5, #0x44] 0x0026: subs r2, #0xa8 0x0028: subs r0, #0xac 0x002a: cbz r1, #0x50 0x002c: str r4, [r7, #0x34] 0x002e: cmp r0, #0x31 0x0030: str r6, [sp, #0x3e4] 0x0032: subs r2, #0x31

Another interesting find it that drevos functions for updating the keyboard, writing the rgb-configuration and so on are all located inside "UpgradeHWI.dll"/"DREVO72HWI.dll". the interesting functions are called: getHardwareVersion() setKeyConfiguration(int,int,int*,int) setKeyLight(int,int*) setKeyboardLightArea(int *) getKeyConfiguration(int,int,int*,int) getKeyLight(int,int*) getKeyboardLightArea(int *) WriteKeyConfigurationToDev(HWND__ *) ReadKeyboardVersion(wchar_t *) DetectDevice() and WriteFirmwareToKeyboard(char *,int,HWND__ *) most of them seem to call __createDev()

[userx14]

I might have found a match: NuMicro NUC120 series seem to have a matching pinout: Osc, Usb and I2C for flash seem to fit, it would be a cortex m0

[userx14]

So the other pin at the programming port is a reset pin...

Nuvoton even provides an example with an rgb keyboard and this microcontroller, this design features an 5pin programing header absolutely identical to the one found on the calibur...

I don't have an Nuvotec programmer, but acccording to some threads it should work with a stlink which I have laying around.

I wonder if the printing on the chip was just there to cause confusion and make reverse engineering more difficult.

EDIT: correct picture from numicro datasheet

[userx14]

Hmm, I attempted to find the usage of all pins of the microcontroller. Pinout.pdf

---

---

Please ignore the upper left keyboard (it is the lower two combined and just for my reference), the other two keyboards depict how the keyboard switches are connected as a matrix. The RGB-LED's follow a similar pattern but are connected to the shift registers and not the Microcontroller: The shift registers are daisy chained according to the numbers (output to data input) and shift registers (2-5) control the RGB_Pins of the Led which are connected in the "Row-Like-structure" of the keyboard switches and shift register 1 + the pin "Transistor_Next_To_Shift1" seem to control the common pin of the LED's.

So it has an EEPROM, not a flash which seems identical to 24C256C. Things I couldn't find out are: -Usage of the "Voltage Divider" above the USB Voltage-Divider. edit seems to go to Q1 an transistor next to the lipo 8dip protection circuit edit2 could this be for battery level detection? -Usage of the other grey pins, I suspect they are not connected but there could be traces underneath the chip.

For the 71-Key-version the additional switch is simply missing and the new switch uses the pins of the outer one.

If you want the ".svg" directly or find out what q1 is for, please let me know.

[userx14]

Some news: I hooked the StLink up to the keyboard and I the chip reports that it is a NUC123LD4AN, so I was a bit off with my guess. Unfortunately, I can't extract the flash because the device's flash has been security locked.

Steps to get the nuvoton chip connected: 1) Connect the pins of P3 as the following (see pictures for reference): | | -> GND of ST-Link | | -> RST (*) | | -> NotConnected (Power keyboard with USB instead) | | -> SWDIO | | -> SWCLK

2) Connect the micro USB to the keyboard

3) Install: StLinkDriver: https://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stsw-link004.html (bottom of page, you need to be registered) OpenOCD: http://gnutoolchains.com/arm-eabi/openocd/ Putty: https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

4) extract OpenOCD archive and copy the content of bin folder into share/openocd/scripts/ (3 files including openocd.exe)

5) go into the scripts folder if you are not already there and

Shift+Rightclick in openocd and "Open command window here"

6) Enter openocd.exe -f interface\stlink.cfg -f target\numicro.cfg

6b) if it says something like " Error: init mode failed (unable to connect to the target) in procedure 'init' int procedure 'ocd_bouncer' " You have probably misswired the stlink, like connecting the data pin acciedentaly to SWIM and not SWDIO (thats the way I found out about this problem).

7) Open Putty, switch connection type to Telnet, enter localhost in Host Name field, enter Port 4444 and click open

8) Putty should display Open On-Chip Debugger, enter reset halt. The keyboard's backlight should have gone out. Sometimes Polling target NuMicro.cpu failed, trying to reexamine appears, in this situation enter init and reset halt and if this is not helping connect the RST pin of the keyboard to the other GND pin of the StLink for 1 sec and restart openocd.

9) Interesting commands: flash info 0 (displays info of flash bank 0) flash banks (displays all four flash banks and their size) mdw 0x50000100 (reads memory from addres 0x50000100) numicro read_isp 0x00300000 (seems to be requiered to read flash config0 register (0x00300000) which locks flash)

The procedure might as well work with other programmers, but the startup command interface/xxx.cfg must be edited.

So maybe we can still get the firmware with the update file provided by drevo...

[userx14]

I've found another repository at: https://github.com/GonzaloAlvarez/ifd68 which is about a simmilar looking board.

[LouWii]

Hi @BenjaminRenz

I might be able to help, or I might not.

I have a very similar board but sold under no name, and as a kit (disassembled). I bought it on Aliexpress. My board came with no software at all, almost no information. But when testing fn + key features, they are the same as the Drevo keyboard.

I took some picture and I do see some differences though. Mainly the Bluetooth chip and missing R76 resistor. But other than that it looks pretty darn close.

The board version says TY71M-RGB-BT-V1.1 and date is 20160106. The main chip is M103CB just like yours.

I'd be happy to try things using the P3 port but I don't have an Stlink. I do have an Arduino Leonardo that might be able to help?

[userx14]

Hi @BenjaminRenz

I might be able to help, or I might not.

I have a very similar board but sold under no name, and as a kit (disassembled). I bought it on Aliexpress. My board came with no software at all, almost no information. But when testing fn + key features, they are the same as the Drevo keyboard.

I took some picture and I do see some differences though. Mainly the Bluetooth chip and missing R76 resistor. But other than that it looks pretty darn close.

(Image)

The board version says TY71M-RGB-BT-V1.1 and date is 20160106. The main chip is M103CB just like yours.

I'd be happy to try things using the P3 port but I don't have a Stlink. I do have an Arduino Leonardo that might be able to help?

I would guess it's an older version of the keyboard, probably the one without Bluetooth 4.0 but an earlier version. It is possible that they didn't put the read protection in those older models.

According to: https://electronics.stackexchange.com/questions/9258/is-it-possible-to-make-a-jtag-interface-with-an-arduino it is difficult to create an Arduino jtag programmer with atmel based arduinos. Problems are:

• Voltage level -> you would need a level shifter from 5.0v to 3.3v
• as far as I have seen no driver support for openocd

You might be able to use other programmers, openocd has a list in their readme on Github. And considering that the Chinese st-link-clones can be had for 2$, which is only twice as much as you would pay for a level shifter. There are very cheap stm32f10X board out there called "blue pill" which can also be used with openocd for under 2$, which can also be used as standalone microcontrollers with usb.

[LouWii]

I looked a bit more into using an Arduino for that and it seems harder than necessary. The annoying part is that getting an Stlink in Canada is annoying: it's either more expensive than it needs to be, or it's delivered from the other side of the planet. I'm going to take the cheap but slow way, so this gonna have to wait unfortunately.

[userx14]

I have setup a codeblock project for the nuc122 including IDE, Compiler, Debugger and so on. It is still work in progress, but debugging seems to work but I haven't yet figured out what libraries I will need and how to initialize the numicro. See: https://github.com/BenjaminRenz/FirmwareTY71M

[LouWii]

Nice! So you're starting from scratch there, right?

I'll keep you posted once I receive my Stlink.

[userx14]

I'll keep you posted once I receive my Stlink.

Yeah, looking forward to that.

Nice! So you're starting from scratch there, right?

I started from scratch because I suspect that the hardware is kind of unique (selection of quartz, io and Bluetooth). I saw https://github.com/lactide/tmk_nuvoton for the poker II keyboard, but I am unsure if it would be even possible to patch Bluetooth / Uart into that. The clock initialisation and so on is something that needs to be done regardless if there is gonna be something else on top of that. But nuvotons documentation is a bit lacking in some parts, I could not find any information which clocks the USB peripheral needs, from datasheets for other microcontrollers of Nuvoton I found something with 48MHz. And the clock selection of HCLK wich CLK_CLKSEL0_HCLK_S_PLL in the manual is contradicting with the library they provide, so yeah this will take a while.

[userx14]

Successfully uploaded the first test firmware, which does nothing except for clock configuration. But I was able to verify that it has changed the clock configuration registers as it should with openocd debugging. But my keyboard is currently as much use as a brick, but with randomly set backlight led's probably because of letting the output pins floating and configured as input pins. As I have to write exams in the next couple weeks the development will probably slow down a bit.

[userx14]

Was able to set the backlight to solid blue manually with the programmer and direct register write. So I can start to write the functions for controlling the backlight. I'm starting with that part because it is simpler to get visual confirmation if it's working.

I'm still thinking about how to get RGB colour support for every single key and if that is possible with the performance of the chip. The instructions required increase dramatically if one wants 8bit RGB colour for every individual key. 8colums*5instructions_per_fill*35shifts_to_fill_rgb*256_eight_bit_colour*n_FPS

But each of the 8 colums can be active only 1/8 of the time, this would probably result in dim color, maybe thats why drevo only uses 8 background colors and tends to do animations only in one row.

[userx14]

Quick update: Now the led's are configurable in an array from the program, it is now configured in such a way that if you press a button it will light up. So key read and rgbLEDwrite are working. Todo's: -there is noticable flickering with low rgb values and very high ones, this might be fixable by moving code into the section where the led's are active, so that the delay can be reduced. -usb endpoints for keyboard and mouse output -bluetooth and usart0 testing -eeprom and i2c1

If you want write access to the repo please let me know.

[LouWii]

@BenjaminRenz I received my stlink and try connecting to the keyboard, but I keep getting an error when running openocd.

> .\openocd.exe -f .\interface\stlink.cfg -f .\target\numicro.cfg
Open On-Chip Debugger 0.10.0 (2019-02-10) [https://github.com/sysprogs/openocd]
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
none separate
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : STLINK V2J17S4 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.240714
Info : NuMicro.cpu: hardware has 4 breakpoints, 2 watchpoints
Info : Listening on port 3333 for gdb connections
Error: jtag status contains invalid mode value - communication failure
Polling target NuMicro.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Polling target NuMicro.cpu failed, trying to reexamine
Info : NuMicro.cpu: hardware has 4 breakpoints, 2 watchpoints
Error: jtag status contains invalid mode value - communication failure
Polling target NuMicro.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms
Info : Previous state query failed, trying to reconnect
Polling target NuMicro.cpu failed, trying to reexamine
Info : NuMicro.cpu: hardware has 4 breakpoints, 2 watchpoints
Error: jtag status contains invalid mode value - communication failure
Polling target NuMicro.cpu failed, trying to reexamine
Examination failed, GDB will be halted. Polling again in 100ms

While this happens, Windows keeps playing the "device disconnected" sound again and again. It looks like the device is getting reset again and again indefinitely.

I'm gonna try to dig a bit more with that error but I'm not sure if I'll be able to fix it as all this is quite out of my league.

[LouWii]

I made progress, I think?

I disconnected the keyboard from USB and powered it from the STLink itself, 3.3v, and I was able to connect.

Here are the results of a few commands.

> flash banks
#0 : NuMicro.flash_aprom (numicro) at 0x00000000, size 0x00011000, buswidth 0, chipwidth 0
#1 : NuMicro.flash_data (numicro) at 0x0001f000, size 0x00000000, buswidth 0, chipwidth 0
#2 : NuMicro.flash_ldrom (numicro) at 0x00100000, size 0x00000000, buswidth 0, chipwidth 0
#3 : NuMicro.flash_config (numicro) at 0x00300000, size 0x00000000, buswidth 0, chipwidth 0

> flash info 0
Device ID: 0x00012335
Device Name: NUC123LD4AN
bank base = 0x00000000, size = 0x00011000
Nuvoton NuMicro: Flash Lock Check...
CBS=1: Boot From APROM
Flash is not locked!
#0 : numicro at 0x00000000, size 0x00011000, buswidth 0, chipwidth 0
        #  0: 0x00000000 (0x200 0kB) not protected
        #  1: 0x00000200 (0x200 0kB) not protected
        #  2: 0x00000400 (0x200 0kB) not protected
        #  3: 0x00000600 (0x200 0kB) not protected
        #  4: 0x00000800 (0x200 0kB) not protected
        #  5: 0x00000a00 (0x200 0kB) not protected
        #  6: 0x00000c00 (0x200 0kB) not protected
        #  7: 0x00000e00 (0x200 0kB) not protected
        #  8: 0x00001000 (0x200 0kB) not protected
        #  9: 0x00001200 (0x200 0kB) not protected
        ...
        #135: 0x00010e00 (0x200 0kB) not protected

> numicro read_isp 0x00300000
0x00300000: 0x78bfffbd

@BenjaminRenz Let me know if I can do more!

[userx14]

While this happens, Windows keeps playing the "device disconnected" sound again and again. It looks like the device is getting reset again and again indefinitely.

Is this also happening without the debugger attached? Which device is disconnecting (device manager)? Have use tried another usb port or an usb 3.0 port?

[userx14]

I made progress, I think?

I disconnected the keyboard from USB and powered it from the STLink itself, 3.3v, and I was able to connect.

Here are the results of a few commands.

> flash banks
#0 : NuMicro.flash_aprom (numicro) at 0x00000000, size 0x00011000, buswidth 0, chipwidth 0
#1 : NuMicro.flash_data (numicro) at 0x0001f000, size 0x00000000, buswidth 0, chipwidth 0
#2 : NuMicro.flash_ldrom (numicro) at 0x00100000, size 0x00000000, buswidth 0, chipwidth 0
#3 : NuMicro.flash_config (numicro) at 0x00300000, size 0x00000000, buswidth 0, chipwidth 0

> flash info 0
Device ID: 0x00012335
Device Name: NUC123LD4AN
bank base = 0x00000000, size = 0x00011000
Nuvoton NuMicro: Flash Lock Check...
CBS=1: Boot From APROM
Flash is not locked!
#0 : numicro at 0x00000000, size 0x00011000, buswidth 0, chipwidth 0
        #  0: 0x00000000 (0x200 0kB) not protected
        #  1: 0x00000200 (0x200 0kB) not protected
        #  2: 0x00000400 (0x200 0kB) not protected
        #  3: 0x00000600 (0x200 0kB) not protected
        #  4: 0x00000800 (0x200 0kB) not protected
        #  5: 0x00000a00 (0x200 0kB) not protected
        #  6: 0x00000c00 (0x200 0kB) not protected
        #  7: 0x00000e00 (0x200 0kB) not protected
        #  8: 0x00001000 (0x200 0kB) not protected
        #  9: 0x00001200 (0x200 0kB) not protected
        ...
        #135: 0x00010e00 (0x200 0kB) not protected

> numicro read_isp 0x00300000
0x00300000: 0x78bfffbd

@BenjaminRenz Let me know if I can do more!

My result for my locked numicro was 0x78bfffb8, so thats good news: Seems as if your flash has not been locked. Bit 1 so the 0x00000002 does indicate that (on for unlocked). So you should be able to read out the current programming. (info from http://www.nuvoton.com/resource-files/AN0001_NuMicro_Cortex-M_Code_Protection_EN_V1.00.pdf)

The openocd command for reading a flash bank is:

Command:` flash read_bank num filename [offset [length]]

Read length bytes from the flash bank num starting at offset and write the contents to the binary filename. If offset is omitted, start at the beginning of the flash bank. If length is omitted, read the remaining bytes from the flash bank. The num parameter is a value shown by flash banks. 

I'm still working on usb at the moment, but with the firmware dump we might be able to directly find out what the speed of the uart0/ i2c1 (the eeprom) is or or some commands for the bluetooth module (would guess that it uses AT-commands).

A dump of the aprom sould be the most interesting...

Is there a firmware file on the site you've bought it from or an updater?

[LouWii]

Here they are. I couldn't get a dump of the bank 3, it keeps throwing an error.

dumps .zip

I'd be interested to know how you're going to read this.

This is where I bought it from: https://www.aliexpress.com/item/71-DIY-Mechanical-Keyboard-Kit-Customized-RGB-Bluetooth-PCB-Plate-Plastic-Case-Switches-Stabilizers/32810693258.html?spm=a2g0s.9042311.0.0.27424c4d5Eg1oR And the seller didn't have any software info. The only thing I got is that he got the kits from Keycool, and that's supposed to be a Keycool 71. I remember searching about it but didn't find anything interesting.

Drevo has released firmware updates though, did you check them out?

[userx14]

Drevo has released firmware updates though, did you check them out?

Yeah but I havn't found out how their encoding works. But I guess they have some connection with keycool, maybe they have used the same code on the board to update the firmware. The question is if they pass the firmware in that encoded way or if they already decode it with the updater.

Here they are. I couldn't get a dump of the bank 3, it keeps throwing an error.

That's not a problem as this is only some configuration info which is beeing set by the code in the aprom.

Thanks for the dumps.

[userx14]

I've take a short look on the dumps, something must have gone wrong as all the files are just filled with 0xff's. I'm not sure what that means because this normaly occurs if the flash is locked, but according to config0 it isn't.

But there could also be a problem with openocd. Can you try the mdw command to read 4bytes from the beginning of the aprom and the numicro read_isp command aswell and see if they return something expect 0xfffffffff on the flash addresses 0x00000000 to 0x0000ffff? I also had problems that sections of the chip can be read by on of the commands but not both.

[LouWii]

I tried mdw 0x00000000 4096, mdw 0x00003fe0 4096 and more"

They all display ffff values

0x00000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
0x00000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
...
0x0000ffe0: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff

numicro read_isp 0x0000fda0, numicro read_isp 0x00000000 and other random addresses, I always got 0xffffffff

Not sure if that;s what you needed? Looks like it's not possible to dump it. Or maybe we could try another tool? I have an OSX machine, not sure if there are other software that we could try on there.

[userx14]

Oh, I see why this is happening, I swapped that last hex charactes while evaulating if the flash is locked, sorry for the wrong enthusiasm:

numicro read_isp 0x00300000 0x00300000: 0x78bfffbd

the 0xd is 0b1101 and therefore the flash lock bit is set to 0, hence the flash is read protected and reads as 0xff... . So we can't get a dump of this rom either.

But as you still have a original working keyboard so you might be able to help me in another way: I haven't found out what the speed of the serial interface for the bluetooth module is, so if you have an 3.3v compatible serial probe you could try to hook it up to the data pins of the blutooth module.

[LouWii]

I'm not sure I'll be able to help further. The only tools I have are: an STLink, a few arduinos and a multimeter. My knowledge of electronics is very basic so if I can do anything to help with what I have, you'll have to guide me a bit :)

[userx14]

If you don't have a 3.3v arduino then it's impossible without some additional circuitry to get the 3.3v signals detected by the 5v arduino. It would requiere at least a transistor, I have tested if the serial to usb converters on my 5v arduino boards are able to detect 3.3v signals but the tollerance isn't enough.

But there might be another way to gether some info about the uart and i2c communication:

Can you read the UART registers at 0x40050000 till 0x40050033 while the keyboard is connected to bluetooth (reset run if it's not starting with attached debugger)? I don't know if those registers are affected by the chip lock but it would be worth a try, as they would contain the uart divider they used.

The I2C clock divider register inside the area 0x40120000 to 0x40120043 would be interesting too, to know the maximum frequency of the eeprom, if it's possible to read that register.

The registers for clock configuration 0x5000_0200 to 0x5000_022F could help to determine the actual speed since the already mentioned just contain dividers which come after the clock controller's own dividers, to know the exact speed.

Thanks for the help 👍

[userx14]

Small update, I got basic usb-keyboard functionality working. Still investigating the bluetooth module, but I would guess it uses AT commands.

[WaseemAlkurdi]

@BenjaminRenz This is pure gold! The amount of sheer dedication in this is insane ... keep up the good work! ❤

[userx14]

Hi @WaseemAlkurdi unfortunatelly I'm currently short of time, so the the project is on hold. If you still have a keyboard with it's original rom would it be possible for you (or anyone else reading this) to find out which baudrate / start stop bitcount / AT commands the keyboard uses when initiating a bluetooth connection or sending key codes? Since I've overwritten the original firmware I have no clue how to initiate this Bluetooth module (should have measured this first in hindhsight).

BT1 and BT2 or BT_TX and BT_RX would be the interesting pins. An 3.3V compatible Serial to Usb adapter or an Oscilloscope would probably be neccesary.

Thanks for intrest in this project.

[HorrorTroll]

I’m sorry, but is this project still on? Well, i have a keyboard called Keydous NJ68. Have the same MCU here.

And I’ve saw that QMK Firmware supported for NUC123 chip too, Ducky One 2 Mini is already working with that firmware.

[userx14]

It's currently still on hold or abandoned, but there exists (not my project):

https://github.com/lactide/tmk_nuvoton

I talked to the author and confirmed that the basic functionality is working. My original plan was to support Bluetooth or the RGB LEDs, but that seemed difficult with tmk at the time I've been researching it.

I would guess that your keyboard is wired differently when it comes to row / columns for the key switches, so you probably need to create a configuration for which pins are inputs / outputs and which pins correspond to what row / column.

[HorrorTroll]

Thanks, i’ve figure out all the cols/row for that keeb. It is 7x10 matrix wiring, so it wouldn’t be hard. But i think, i’ll pass the backlight led. Since idk how it wiring to main mcu.

[HorrorTroll]

I'm sorry, but when I'm looking at the code from tmk_nuvoton. There is a file called board.c, there are many thing that idk what it mean.

For example:

• const keymap_column_mask cols[MATRIX_COL_PORTS]
• const PALConfig pal_default_config
• uint32_t board_read_column(void)

Here is my board file: nj68.zip

[cha512]

Hi, thank you for sharing your approach @userx14

It was very helpful, especially the mention of the SWD port and the schematic you drew.

I did an university graduation project about keyboard firmware and its manipulation.

In the process, I analyzed several manufacturers' keyboards and especially almost completely analyzed the firmware structure of this manufacturer (probably a Chinese OEM, whose firmware is a bin file and starts with :07 or :15).

I don't have a Drevo keyboard and the corresponding bin file either, but I was able to decrypt ifd68 firmware mentioned here and firmware of my keyboard .

import binascii
import sys

from Crypto.Cipher import DES
from struct import pack, unpack

u16_B = lambda x: unpack(">H", x)[0]

def main():
    with open(sys.argv[1], "r") as f:
        data = f.read().strip().split("\n")

    for k in range(0, 256, 2):

        block_dict = {}

        des_key = bytearray([k, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00])

        decryptor = DES.new(des_key, DES.MODE_ECB)
        result = b""

        try:

            for line in data:
                _len = int(line[1:3], 16)
                blocks = b"".join([decryptor.decrypt(binascii.unhexlify(line[b:b+16])) for b in range(3, len(line), 16)])

                size, offset, _type, data_block, checksum = blocks[0], u16_B(blocks[1:3]), blocks[3], blocks[4:_len-1], blocks[_len-1]
                calculated_checksum = ((sum(blocks[:_len-1]) ^ 0xff) + 1) & 0xff

                pad = blocks[_len:]

                #print(_type)

                assert size == len(data_block)
                assert pad == b"\x00" * len(pad)
                assert calculated_checksum == checksum

                if size == 16:
                    result += data_block
                else:
                    print(size, offset, blocks)

        except AssertionError:
            continue

        with open("decrypted-%02x.bin"%(k), "wb") as f:
            f.write(result)

if __name__ == "__main__":
    main()

As a result, I succeeded in decrypting the bin file (which corresponds to the APROM area) and extracted the LDROM.

The process of extracting the LDROM was a bit more complicated, I modified the firmware of the APROM area to add the ability to read the LDROM area and send it with a ctrl transfer.

Now that I have extracted both the APROM and LDROM, I can remove the LOCKBIT and reflash them to make the keyboard fully debuggable and continue with the project.