At the moment I only have the first 2048 bytes but when I find the correct answer, I should receive the remining blocks.
I suppose that we may miss the 4096 remaining bytes of the bootloader at the end so this won't be usable like this. But one step at a time...
More after lunch ;-)
You noticed that the data are just the bytes from the firmware binary file?
The decryption (if my assumption of encrytped data is correct) most certainy takes place inside the STM32 and not in the PC executable.
I hope we can at least get the offsets and sizes of the encrypted/compressed packages. It will help with the decryption/decompression.
Best of luck and if you need an extra pair of eyes/hands and a sacrificial device, I'm around .
Almost all the packet having the same size, and the decoding being done by the FP MCU, I would suppose there is no compression but rather some sort of XOR treatment with a constant key.
Either they are using the "undocumented" 128KB of the MCU, or there is a lot of extra code for obfuscation.
If I am right and if the last parameter is a sort of 16bits CRC, than it would make sens to check the CRC and decode at the same time. Which would lead to a 16 bits key...
If I am right and if the last parameter is a sort of 16bits CRC, than it would make sens to check the CRC and decode at the same time. Which would lead to a 16 bits key...
The last parameter is just the 16-Bit sum of all the bytes in a block, so no real CRC.
Did a simple XORSearch for strings that must be in there, to find it with common simple obfuscations like XOR, ROL, ROT, SHIFT, ADD. No luck
(tried case insensitive FeelTech, Wave, Sine, Freq as strings). No luck. So its a little more then so simple 1 byte obfuscation. Maybe a better 32 bit hash or so. Or they stacked 2 obfuscations.
Also I'd like to point out the file is 100048 bytes. Too much for a CPU update, too little for a CPU+FPGA update.
And of course, any proper update should be MCU+ FPGA (64K + 384K)
So if a 64KB firmware, then there is 32K+1744B too much.
Either they are using the "undocumented" 128KB of the MCU, or there is a lot of extra code for obfuscation.
Well... basically that is already a CRC, even if you don't take the 2-complement. And there are a lot of different CRCs ...
Well... basically that is already a CRC, even if you don't take the 2-complement. And there are a lot of different CRCs ...
I don't think so. A CRC is based on polynomial division and not on an arithmetic sum, see https://en.wikipedia.org/wiki/Cyclic_redundancy_check
I am not sure if there is a polynom which would give the same result as the arithmetic sum, so maybe it is a special case.
Anyway, the difference is not really important here. Regarding encryption: AES would be easy to implement and is fast and small enough. And then of course there are many different other encryption algorithms which are more than good enough for this kind of application and which require less space than AES.
Just reading back your latest post Fremen, do you think theres a hidden function accessed by front panel buttons that drops the unit into update mode?
@fremen67 - the main purpose of this exercise is not to get hold of feeltech buggy crap, but to be able to offer a comfortable way to the people to upgrade the device without having to resort to extra programmers and even opening the device. And also offering a way back to the original firmware if needed (i.e. for warranty purposes).
This is why it's still interesting to try to get a hold of the firmware update process, load a custom fw to read and send back the bootloader, to see which key combination activates the update process and then managing the firmware updates will be much easier.
Cheers,
DC1MC
For me it was only several '?' and somewhere in between these the text 'USB' in a dialog (an ok/cancle dialog I think) directly after you hit the start button. There you hit the left button and then it runs for some seconds and you get a new error dialog with some '?' the text 'USB' and a '!'.
Looks like the software asks the unit to to do the update but the unit does not respond like expected concerning what we already know about the process of what you can read here.
No change on the display of the unit ,I already tried swapping out ch340 drivers extracting feeltechs original infs ,but that was just the same , incidently running the machine in chinese language made no difference either
I tried changing the baud rate of the com port ,no difference , I think there has to be a routine to drop the unit into boot mode that were missing out ,thats why they cant com , I wonder would translating the latest chinese released documents the give us any clues ?
Try to power it up while pressing 1, 2 or more random buttons. You may find something.