poker2firmwarehacking
poker2firmwarehacking copied to clipboard
erichkeane
About decode Firmware
Hi,
I think we maybe need to use the nu-link to connect the keyboard.
Um. I can confirm the poker 2 keyboard has 5 pin JTAG pins, because I rebuild a poker2 keyboard to GH60 keyboard (just switch the PCB)
Do the pins need headers added? I've been slowly trying to decompile the flashing-tool that they provided with very little luck. I was hoping to find an easy way to figure out the file format, but wasn't very successful :/
Perhaps buying a nu-link (digikey has them for ~$40!), I could just start writing firmware from scratch instead.
You can try Bu-link, same function as nu-link.
This picture shows these pins,
the pins in the right bottom corner, total 5 pins, ICE_CK1, ICE_DAT1, RST, GND, VCC(not show in the picture). I don't think normal headers fit these pin port, because the hole is too small, it need to solder the cable on it.
I just picked up a nu-link pro, so if I get time this weekend i"ll be trying to solder pins to my board and see if I can pull the program off it. It'll be nice to see how it compares to the firmware file that Vortex provides with their flashing tool.
I set up the flashing tool yesterday (I had a friend solder some leads for me), and unfortunately there is a 'flash lock' bit that prevents the tool from reading the data. It seems that I would be able to do a complete clear of the device, however that would require anyone wanting to USE my firmware to have a flashing tool.
I'm not completely given up on this, but I would still love the ability for others to upgrade to a custom firmware without having to go through the flashing tool.
Um, they lock the flash. Except use flash tools to clear the flash, user cannot upgrade they keyboard.
Is possible to decode flash via directly read flash rom?
If we want to support that user can upgrade their keyboard via usb, how would we can do? Decode bootloader?
Um, they lock the flash. Except use flash tools to clear the flash, user cannot upgrade they keyboard.
No, they locked reading the flash. You can still write new contents to the flash using the ISP (via USB)
The only problem is that we need to reverse engineer the format that is used to send a new firmware to the keyboard.
Note that we could flash completely NEW images with the Nu-Link flashing tool right now, just not read what is currently on the keyboard. I'm tentative to do that as the keyboard then becomes unrecoverable without writing a completely new firmware, and is incompatible with anyone who doesnt have a Nu-Link.
I would love to decode the KBC tool's flashing format so ANYONE could flash it, either using the stock KBC tool, or have us write a flashing tool that'll work without having to encode the file.
I received my nulink today!
The icp tool did not all me to read the flash of the keyboard, it look it they lock the flash. If still continue, icp tool will clear the flash.
I think the KBC is locked the bootloader, but we still can write our own firmware and upload this firmware to keyboard via Nu-link. I do not know much about bootloader, but I could write the new keyboard firmware. I will do some research on it later.
Do you have some advices on how to write new firmware?
There are a number of existing keyboard firmwares to start with, so I'd lean toward doing that. It might be possible to port this: https://github.com/tmk/tmk_keyboard
AT the moment, I'm trying to see if I (we?) can decode the USB messages enough to figure out what it would take to use the stock ISP tool to flash. The best thing at the moment is to look at the captures I uploaded to this project, open them in Wireshark and see if you can decode them.
Otherwise, take a look at the demo code of the flasher, it seemed like a good way to get started. The HID code and actual keyboard code is pretty trivial, but just figuring out which GPIO goes to which keys would be a pain.
There are a number of existing keyboard firmwares to start with, so I'd lean toward doing that.
Most of these are written for Atmel AVR, which is quite different from a ARM processor.
GCC should still be able to target ARM with them. At worst, there will be only bit of porting that would be required.
I have nothing against trying to write our own, I just think that using something like tmk would be a good starting place.
@erichkeane
We are not really write our own, I mean we check the matrix of poker2 and transplant tmk from avr to arm Cortex-M0.