Possiblity of Pok3r firmware replacement

[hasu]

Recently I'm thinking about buying new Vortex Pok3r keyboard, the keyboard itself really looks worth the money for typing as normal usage. But if it is hacakable with custom firmware it would be more attractive to me.

Looks like it has holtek Corex MCU and no doubt it is flashable and updatable, my concerns are that it is possible to flash custom firmware with tool publicly available from chip vendor or open source tools. I didn't look into datasheet, app notes and tools of the chip, by any chance, does anyone know about these things?

See this video in HD mode   Let me know if you have links to high resolution pics of Pok3r PCB.
Marking on the chip says HT32F1655.

Vendor page:
http://www.holtek.com/english/docum/32bit_flash_mcu/ht32f1655_1656.htm


So my questions are:
Is Pok3r controller flashable? If so How?
Or the chip is locked by Vortex?


With doing this I'll lose default Vortex firmware and functionality but I don't mind this and I have other keyboards for daily usage:D
And if it is flashable I or someone of the community will be able to write custome firmware for Pok3r hopefully, in the end.

Thanks in advance,



[Update]
Resources:

twiddle's analysis of firmware in updater executable:
https://geekhack.org/index.php?topic=72262.msg1796931#msg1796931

pacet capture of updater by einalex:
https://geekhack.org/index.php?topic=72262.msg1956377#msg1956377
https://geekhack.org/index.php?topic=72262.msg1990025#msg1990025


[Update 160202]
https://geekhack.org/index.php?topic=72262.msg2037084#msg2037084

Snake hack for Coolermaster Quickfire Rapid-I:
  Update protocol
  http://spritesmods.com/?art=rapidisnake&page=3

  firmware update tool:
  http://spritesmods.com/?art=rapidisnake&page=7

[hitaki]

Maybe try asking on their Facebook page.

[engicoder]

Many cortex-M microcontrollers have some type of flash read protection to prevent reverse engineering of firmware, but most do no prevent overwriting the flash memory. I believe Holtek has a proprietary programmer, but I imaging standard SWD or JTAG would also work. That may require desoldering the chip depending how those pins are used on the board.

[FuriousGeorge]

I don't have anything useful to add, but I do want to wish you luck. A Pok3r with space-fn would be amazing.

[hasu]

Many cortex-M microcontrollers have some type of flash read protection to prevent reverse engineering of firmware, but most do no prevent overwriting the flash memory. I believe Holtek has a proprietary programmer, but I imaging standard SWD or JTAG would also work. That may require desoldering the chip depending how those pins are used on the board.

Thanks.
Yes. What you said is exactly what occured on Poker II firmware hacking project.
https://github.com/erichkeane/poker2firmwarehacking

Probably Pok3r also can be overwritten with hardware programmer and it is far better than completely not flashable.
But if we can flash the MCU through USB just with software tool it would be great so that everyone can flash custom firmware without special hardware.

[wakko]

Subscribing.

[twiddle]

You could probably make some sort of test jig with contacts that press down onto the chip's legs or the part of the traces which extends beyond them. There's an ISP/IAP bootloader that uses a special serial based protocol, the product page you linked to has a document about it. The jig could either use that or SWD - no point using JTAG (many more pins, and some Cortex M chips dont support it anyway).

From looking over the documentation there's no USB bootloader, though, so I'm guessing there's something being sent to the chip (custom USB report perhaps? certain key combination being pressed when the board is plugged in?) that either forces it into ISP mode or more likely just uses flash memory commands to reprogram itself.
If anybody has a USB protocol analyzer, getting a capture of the firmware update process would probably be helpful.

[mecano]

Heng Yu (the manufacturer) has matrix programming programs (windows and linux) anyone succeed in getting these?
Really a shame, they would sell even more keyboards if they provide these.

[jackiecanev2]

Many cortex-M microcontrollers have some type of flash read protection to prevent reverse engineering of firmware, but most do no prevent overwriting the flash memory. I believe Holtek has a proprietary programmer, but I imaging standard SWD or JTAG would also work. That may require desoldering the chip depending how those pins are used on the board.

Thanks.
Yes. What you said is exactly what occured on Poker II firmware hacking project.
https://github.com/erichkeane/poker2firmwarehacking

Probably Pok3r also can be overwritten with hardware programmer and it is far better than completely not flashable.
But if we can flash the MCU through USB just with software tool it would be great so that everyone can flash custom firmware without special hardware.

I'm planning to des older my switches tomorrow, so I can probably get shots of both sides of the board if that will help.

Looks like it's a universal board; there are extra placements for an ISO enter, short left shift, short right shift and others - the top plate is ANSI but the board should be the same.

Some of the poker 2 functions were inadvertently moved to other keys; I found that you can you can program the volume controls directly to another layer using the default, layer1, and layer2 bindings to another layer key. Maybe the previous backlight controls are blocked in the firmware main layer but it's blocked function still be bound to a non-default layer?

The led resistors are soldered (LRXX) but in the way of things that are fill-soldered, the led pins are filled and there are smd resistor pads soldered but with no resistors, six pairs that I can see. RRD2/RRU2, 3 and 4 are visible in the second picture.

Once I desolder the switches I'll try and scan the pcb on both sides.

[hasu]

Once I desolder the switches I'll try and scan the pcb on both sides.

It would be definitely useful!

[KaLam1ty]

I know that the Poker II had firmware upgrades via Vortex's proprietary flasher. The update allows NKRO via USB, among a few other things.
But the most notable thing though, was that there WAS a custom firmware released which allowed remapping of PN, FN, Caps, and LWin: https://geekhack.org/index.php?topic=64916.0

From what I've read here and there, the Pok3r will eventually get a firmware update for LED compatibility (as the PCB itself has holes for LED leads, but is currently not programmed for LED usage).
My guess is Vortex will eventually release this firmware once they start releasing Pok3r's with LEDs.

With this, there will most definitely be some proprietary firmware flasher.

[jpec]

I don't have anything useful to add, but I do want to wish you luck. A Pok3r with space-fn would be amazing.

I totally agree with you !


I already asked them for SpaceFn support or opensourcing their firmware on facebook : https://www.facebook.com/Vortexgear/posts/748409298608405

[hoz]

Ducky mini/YOTH mini uses HT32F1655 and KBP V60 Mini HT32F1755, both had firmware updates released

[Giorgio]

asking them to open source the firmware maybe it's too much. Right now what people are really interested in is an easy way to configure the keyboard, something like the software used to configure the gon's nerd, which allows to program any key with any value-combination, not only with those actually present on the keyboard.

We should start a poll, and show vortex how much we want an easy way to configure the keyboard.




https://geekhack.org/index.php?topic=50577.msg1105404#msg1105404

[mecano]

Interresting documentation, debuggers and tracers for M3 from Keil: http://www.keil.com/dd/chip/7462.htm
not sure if the lite version allows you much to do (i'm on OSX, looks like Windows only).

[thismat]

I'd definitely buy a pok3r if there was a good way to configure multiple layers.

[twiddle]

Interresting documentation, debuggers and tracers for M3 from Keil: http://www.keil.com/dd/chip/7462.htm
not sure if the lite version allows you much to do (i'm on OSX, looks like Windows only).

I already have a J-link, it would just be a matter of whether the manufacturer properly set their flash protection settings to prevent dumping the binary out to a file.

[mecano]

Curious to know what you'll find out.

[twiddle]

I'm pretty sure I've managed to dump the firmware out of the executable.
In the update program are a number of areas where the software calls ReadFile on itself then loops over a function that transforms the data that was read, changing it.


Notice Sub_401000 in the bottom left hand corner? That looks like this:


(the green arrows are showing how the code loops around a byte at a time to change the data)
Its pretty obvious that it is decrypting the firmware, because the first time we see this Read-Convert process happening, we convert from:



to



The second time this happens we get the following result:



Notice those funny repetitive bits at the start? they line up quite nicely with the Vector Table at the start of an ARM chip's firmware.
(the first address in the file at address 0 corresponds to the bottom entry in the diagram, moving upwards in the diagram as we keep going through the data, in groups of 4 numbers, cos thats just how memory really works)


They're basically addresses which is why they are all pointing into a similar region of code.

I can't test with anything because I don't have a POK3R but it looks like if you could replace the memory region in the application with your own custom firmware you could reflash the controller. You'd also need to skip the decryption process, I guess, but that shouldn't be much more than erasing the instructions that decrypt it.

On another note it looks like there's some sort of data being sent to the controller to initialise IAP (programming mode), based on this string I can see in the code:


I'm guessing, but I think sub_405480 is sending data to the keyboard to enter IAP mode.  The error happens if theres a timeout after a certain period.
With more effort perhaps this process could be hijacked but actually using a USB protocol analyser would take almost all of the guesswork out of it.

I've attached the firmware update I've been reversing, and included an archive containing the IDA Pro database and the dumped and decrypted data if people want to take a look.

[Giorgio]

Fantastic job :-) now hackers will take down the server again :-)))))

If only we could convince vortex to allow us to program the layouts using an external software....

I'm pretty sure I've managed to dump the firmware out of the executable.
In the update program are a number of areas where the software calls ReadFile on itself then loops over a function that transforms the data that was read, changing it.

Show Image

Notice Sub_401000 in the bottom left hand corner? That looks like this:

Show Image

(the green arrows are showing how the code loops around a byte at a time to change the data)
Its pretty obvious that it is decrypting the firmware, because the first time we see this Read-Convert process happening, we convert from:

Show Image

to

Show Image

The second time this happens we get the following result:

Show Image

Notice those funny repetitive bits at the start? they line up quite nicely with the Vector Table at the start of an ARM chip's firmware.
(the first address in the file at address 0 corresponds to the bottom entry in the diagram, moving upwards in the diagram as we keep going through the data, in groups of 4 numbers, cos thats just how memory really works)

Show Image

They're basically addresses which is why they are all pointing into a similar region of code.

I can't test with anything because I don't have a POK3R but it looks like if you could replace the memory region in the application with your own custom firmware you could reflash the controller. You'd also need to skip the decryption process, I guess, but that shouldn't be much more than erasing the instructions that decrypt it.

On another note it looks like there's some sort of data being sent to the controller to initialise IAP (programming mode), based on this string I can see in the code:

Show Image

I'm guessing, but I think sub_405480 is sending data to the keyboard to enter IAP mode.  The error happens if theres a timeout after a certain period.
With more effort perhaps this process could be hijacked but actually using a USB protocol analyser would take almost all of the guesswork out of it.

I've attached the firmware update I've been reversing, and included an archive containing the IDA Pro database and the dumped and decrypted data if people want to take a look.

[tofgerl]

Any movement on this?

[ocodo]

subscribed - I assume the outcome of this will be applicable to the KUL ES87 (same Holtek HT82K94E/HT82K94A MCU unless I'm way off!)

[ctm]

Subscribed. If I can flash in TMK firmware to Poker 3R it will be so great! I also have a KBP V60 that uses a similar chip. Does it mean V60 might also be hackable?

[einalex]

Hi guys!
I updated my firmware from 113 to 114 and captured usb packets of the process.
See the attached file.

best, alex

[einalex]

Hi guys!
A happy new year and another capture of updating the firmware from 1.1.4 to 1.1.5

[jcoffin1981]

I have read just last night that Vortex released a firmware update that allows for media controls on all four FN layers, not just the ones you program on a single layer.  However, I have gotten used to them and am not sure if I want to change.

[gurghet]

subscribed

[overclocked157]

I subscribed as well.

[hasu]

The other day, I found this hack in similar thread on reddit. And I looked into pcap logs attached in this thread and confirmed Pok3r update procedure is almost same as he described in here.
http://spritesmods.com/?art=rapidisnake&page=3

I think his tool can be used for Pok3r to update its firmware with slight modification.
http://spritesmods.com/?art=rapidisnake&page=7

I think we can make firmware updater for Pok3r based on his work. I'd recommend someone interested to read this article.
I can't try this because I don't have Pok3r but still update first post of this thread to share info.

[einalex]

Nice find hasu!
The usb commands are the same in the pok3r firmware. I'm currently implementing a pok3r specific version of his flashing tool in python.

[iLLucionist]

This is really cool. If anything workable comes out of this, I would buy the pok3r in a heartbeat. I really dislike the default mappings in layer-1 (tilde/backtick/esc for example... whhhyyyy??).

[tofgerl]

Would this enable TMK, or just remapping?

[jumbled]

@einalex please do this, you will gain much respect. If it works, stick it on a site with a donate button. I'm looking to convert the alt/fn/pn/ctrl buttons to arrows: without clunky workarounds.

[iLLucionist]

Nice find hasu!
The usb commands are the same in the pok3r firmware. I'm currently implementing a pok3r specific version of his flashing tool in python.

Really cool, are you going to put it in github?

[einalex]

No worries, I'm still working on it.
I have something working that can read the flash. But the firmware has a security mechanism that results in the script reading just zeros over large areas (same problem sprite had)
So I'm looking for the byte in the firmware that I can flip to disable that check.
For details read sprites article. He solved the problem for another keyboard already.

[einalex]

The flash script has it's own github repo now.
It's a little python thingy and still lacks most of what would make it usable (a user interface).

Find it here:
https://github.com/einalex/pok3r-flash-tool

Feel free to contribute.
Although if you poke through the firmware to find that part which turns most of our flash reading to zeros, that would be even better.

[einalex]

Would this enable TMK, or just remapping?

We would have to adjust the TMK firmware to work with this specific chip.
It should be doable, might take some work though.

[grav3serker]

I came across this the other day, but I'm not sure if it'll be any help or not, as it's for the V60.

https://github.com/pellettiero/V60Mini-firmhack

If this is of any use to anyone, awesome, if not, I tried! Haha. I'd love to re-write the firmware for the V60 so that I can change the layout to HHKB style.

 

[PaNaVTEC]

Is this project still alive? I can help with that UI if necessary, not an expert of python, but still I can do it.

[randomize]

Hi guys, just did some progress on this.

My goal is to replace US Dvorak mode with Programmer Dvorak in my WASD CODE (same hw as Pok3r), so I can happily type it with no extra software on target machine.
Firmware update process and protections around it are indeed pretty similar to ones Sprite described in his article.

Wrote two simple C tools to decode and encode firmware (can't call ROR and swap an encryption, ha) - keep in mind that alg can be slightly tweaked in future firmware updater executables from Vortex, and that there are two blocks of data at the end of firmware - a big one with vector table and arm instructions and a smaller one with string constants - because of that offset, smaller block needs to be decoded separately.
https://github.com/randomize/pok3r-dec

Top bytes (right after vector table) of decoded fw are mangled somehow, but the rest looks like valid code so I found instructions that do protect from reading.
Encoding back patched and flushing was simple - attached pwned exe of v1.1.5. here is radiff2 output - just one byte does it:

Code: [Select]

0x001a7dba 09 => f2 0x001a7dba
After that I was able to dump firmware (and some bootloader in high address I guess) with neat tool by einalex https://github.com/einalex/pok3r-flash-tool - thanks man.
Attached dump as flash.img
Comparing with decoded fw form updater reveals that blocks are indeed mangled - will find how these are decoded on kb side later.
Next and more hard step is to find where dvorak switch is implemented and tweak it

Thanks to all for this thread - was a good starting point

[Giorgio]

Has anyone tried to ask vortex???

I'm sure that the could open source their firmware if the community could help them in making an opersource configurator. Possibly adapting the existing ones?

[lunas]

My skillset doesn't offer much in this endeavor, but I'm very interested in better programability for the Pok3r. I'm a Pok3r owner and happy to assist in any grunt work.

[blastoid]

Any recent movement on this?

[pon10]

This is great! hope is coming from vortex one day.. but i also like the idea that everything is just in the board and i was born autistic....

[ChaoticConundrum]

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

Code: [Select]

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.

[giammin]

I asked Vortex about if they have any plan on opensource their firmware or if they will be compatible with tmk qmk firmware.


Waiting for a response

[Giorgio]

I asked Vortex about if they have any plan on opensource their firmware or if they will be compatible with tmk qmk firmware.


Waiting for a response

Are you willing to make an online petition?

[giammin]

I asked Vortex about if they have any plan on opensource their firmware or if they will be compatible with tmk qmk firmware.


Waiting for a response

Are you willing to make an online petition?

great idea gianni

[ChaoticConundrum]

I have put my reverse-engineering project for the Pok3r firmware on GitHub, here: https://github.com/ChaoticConundrum/pok3r_re_firmware.

I have also learned a bit about the maker of the pok3r firmware. First, the firmware has a *near* identical update procedure and encryption scheme to the CM Storm QuickFire Rapid-i, which Sprite successfully cracked. Second, while looking at the firmware update program for the Pok3r RGB, I found the version strings indicate Cooler Master as the Company Name and Legal Copyright. So, either Cooler Master writes the firmware for Vortex, or both Vortex and Cooler Master outsource firmware to another company, which seems the most likely.

It seems fairly unlikely to me that Vortex would be willing (or legally able) to open-source firmware they probably didn't write, especially if it is very similar to Cooler Master's firmware. It also shows to me that more firmware updates for any Pok3r model will likely be scarce, because each update to the firmware costs more money if it is outsourced, rather than already having programmer(s) in-house.

Just my opinion from my experience. I think open-source Pok3r firmware will have to be in our hands.

[condekind]

Zero knowledge on how to help with this, but I'm very interested in the results! Recently purchased a pok3r and it would be awesome to have it fully programmable