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.
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.
Once I desolder the switches I'll try and scan the pcb on both sides.
I don't have anything useful to add, but I do want to wish you luck. A Pok3r with space-fn would be amazing.
Interresting documentation, debuggers and tracers for M3 from Keil: http://www.keil.com/dd/chip/7462.htm (http://www.keil.com/dd/chip/7462.htm)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.
not sure if the lite version allows you much to do (i'm on OSX, looks like Windows only).
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(http://i.imgur.com/hLQe6SI.png)
Notice Sub_401000 in the bottom left hand corner? That looks like this:Show Image(http://i.imgur.com/b5EpYBD.png)
(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(http://i.imgur.com/XDMpkiF.png)
toShow Image(http://i.imgur.com/ojJDufF.png)
The second time this happens we get the following result:Show Image(http://i.imgur.com/fjYBJeL.png)
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(http://i.imgur.com/abHdI1j.png)
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(http://i.imgur.com/P7Lvopk.png)
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.
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.
Would this enable TMK, or just remapping?
0x001a7dba 09 => f2 0x001a7dbaarm-none-eabi-objdump -D -EL -b binary -m arm -M force-thumb firmware.binI 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
great idea gianniI 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?
I have put my reverse-engineering project for the Pok3r firmware on GitHub, here: https://github.com/ChaoticConundrum/pok3r_re_firmware (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.