FeelTech FY6600 60MHz 2-Ch VCO Function Arbitrary Waveform Signal Generator

[fremen67]

I now got 49 packets: 48 packets of 2048 bytes and one of 1727, that is 100031 bytes

More details on the protocol:

PC: <PrSTM32_START 0x0A
BP: START 0x0A
PC: <IAPSTM32_PacketLength_PacketNumber_16bitChecksum0x0A
BP: 0x0A
PC: 2048 binary packet
BP: "WrEND" when write OK or "error"
PC: <IAPSTM32_PacketLength_Packet+1_16bitsChecksum 0x0A
…..
On "error" reply to a packet, PC Software retries 4 times then stops

After the last packet:
PC:<PrSTM32_DO 0x0A
… and I don't know yet what to reply ...

First packet is 0.

I suppose there is some kind of CRC Checksum so that the FP MCU can check the packet before writing it.

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.

Yes the decoding seems to be made in the FP MCU.
When you remove a 13 bytes header in the firmware file, you get the same values as in packet 0.

I attached the first packet plus the capture of the whole tranfer made with my DSLogic analyser.

Edit: CRC replaced with Checksum

[fremen67]

I hope we can at least get the offsets and sizes of the encrypted/compressed packages. It will help with the decryption/decompression.

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. The MCU has not a lot of power and it has to go fast.
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...

Best of luck and if you need an extra pair of eyes/hands and a sacrificial device, I'm around  .

You are more than welcome! Not sure we need a sacrificial device for decoding. We have to think of some code or constants that might be in the update and that could lead to the key.
Constants like "FY6600_60M" may be in the bootloader but strings like "V3.4" could be in it… or many other 

[tsman]

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.

I'd expect there to be lots of repeated sequences if it was a simple constant key XORed with the data but there aren't any. A block cipher like AES is easily implemented in a STM32 so my guess is that it is encrypted but with something stronger that constant key XOR. ST uses the same STM32F103 in their ST-Link dongles and they use AES to encrypt the firmware as well. They've implemented it in a really bizarre way however and decrypt the binaries in the update tool then reencrypt it with a random key supplied by the ST-Link bootloader.

[cybermaus]

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.

[tsman]

Either they are using the "undocumented" 128KB of the MCU, or there is a lot of extra code for obfuscation.

I'd say this was nearly certain. There are enough manufacturers out there that don't care about the official specs by doing things like using a STM32F101 for USB even though that part doesn't officially support it. Exploiting the extra unofficial flash in a "64KB" STM32F103 is fairly common now. Supposedly there have been some STM32F103C8s found that do only have 64KB flash though. The GD32 clones don't but they're completely different inside.

[ds]

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.

I noticed that the last four bytes of the firmware image are so far not used, not sure if they have a meaning.

[cybermaus]

I remembered there was this 256 byte count up from 01~FF in the WinBond firmware (position 0x0f0000) and I found this common "rolling XOR" technique and decoder NoMoreXOR (more explanation here), that typically uses these sort of 256 byte strings to decode.

But its a python script and python-yara does not want to install.
And I need to stop this, and start packing for my work trip.

So if anyone else want to explore this...

[fremen67]

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.

Well... basically that is already a CRC, even if you don't take the 2-complement. And there are a lot of different CRCs ... 

[fremen67]

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.

FPGA update could come later on but for the moment I would go for CPU only: 100KB + Bootloader could also make 128KB …
I can't see how easily erasing and programming the whole CPU from the inside...

When analyzing the upgrade protocol, a flash write seems to occur every 2048 bytes block. As a page flash size is 1024 byte on the MCU, there are 2 possibilities: either it decodes 2048 into 2048 bytes and writes 2 pages, either it decodes 2048 bytes into 1024 and write only one page.

[ds]

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.

[fremen67]

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.

You are right, I should have said checksum. I will correct the protocol description post.

The problem I see now is that even if we are able to decode the firmware updates, there are chances that we won't be able to use them easily without the bootloader. That would require efforts that could be useless at the end.
As far as I am concerned, I will switch back to the bluepill firmware. We are almost at the GUI stage and that will be more rewarding I guess 

[soundtec]

Wow some interesting developments overnight .
I have to admit I'm way out of my depth with regards to encryption etc ,but you guys seem in your element trying to get this jack out of the box .

Does the appearance of this firmware file show that a way to upgrade the machine does exist already ?
I must re- read the last few pages again for it to sink in .

I'll send an email to Feeltech asking about any plans for firmware updates etc .
If theres any specific questions or points that you guys would like me to mention in the email just say and I can add them ,but hopefully Ive captured the general feeling in a few paragraphs for them at any rate .

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?

[DC1MC]

@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

[fremen67]

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?

I have no way to be sure but the v5.8 PC software did not required to do something special, appart maybe not to remove the USB cable during update. It just seems to be serial commands like other commands it uses (wave download for example). My V3.2 firmware did not respond to the update requests so I would guess that this function is at least not supported by device with firmware <= v3.2.
Wheter there is a special key combination to do before or not, I don't know...

@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

I understand clearly the benefit of upgrading firmware for every one but as already said, even with a decoded upgrade firmware, we will still miss the boatloader to make the whole think work: the code which does the upgrade can't erase itself... and if the upgrade functionnality is not available with firmware < v3.2 at least, then none of use would have access to this bootloader. It would be easier to wait for someone to receive a v3.4 device and see if that function is available.
Once again, I don't say it is useless to try. I just say that as far as I am concerned, I have to focus on the bluepill/replacement firmware at the moment.

[Miti]

Can someone post the error message that you get when you try to upgrade? I have enough Chinese colleagues that can translate for me.
 

[Candid]

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.

[Miti]

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.

I think you need to install traditional Chinese characters to see anything meaningful... to a Chinese.

[soundtec]

On both my computers I had an issue running the new english fy6800 software installer , on the win 10 pc ,windows defender reports the installer contains a virus or pup ,and a minute later the unpacked installer is deleted by windows ,on an older os the archive cant be opened . I had to resolve a couple of dependencies ,two .ocx files needed to be added to windows before the chineese version update would run ,I tried the firmware update option and it seemed to be working first time around ,until the usb error message popped up . The version information panel now reports that I have my fy6600 15mhz connected, confirms that software update 5.8  is installed and that the firmware revision of the machine is at 3.2 . This panel never worked properly in any version of the software for me up until now,it just caused the waveform view window to pop up .

Could it be that in order for the fy6600 to receive the chinese firmware update it needs to be run in chinese language mode instead of english by front panel selection ? I dont know if it will make any difference ,but I might give it a try this afternoon for giggles and sh!ts

[Miti]

Did anything change on the display when you started the update?

[soundtec]

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 ?

[Jon.C]

new version in pre-order     

https://www.banggood.com/FY6800-2-Channel-DDS-Arbitrary-Waveform-Signal-Generator-14bits-250MSas-Sine-Square-Pulse-VCO-Meter-p-1293929.html?rmmds=search&cur_warehouse=CN

[Miti]

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 ?

That may be an indication that the device is not in upgrade mode. Try to power it up while pressing 1, 2 or more random buttons. You may find something.

[DaveR]

Try to power it up while pressing 1, 2 or more random buttons. You may find something.

The engineering mode for frquency calibration is entered by pressing and holding the front panel power and Ch1 buttons whilst turning on the main power switch at the back.  It's probably the same, or something very similar (Power + ?), to go into update mode (assuming v3.2 has one).

[tsman]

If there was a bootloader update mode in an old FY6600 then wouldn't FeelTech have already mentioned it by now? It would have fixed the various corrupted units and saved them a lot of bad PR. They posted here about how their next unit would have the firmware update ability.

It is possible that an update mode does exist but the old FY6600 bootloaders don't support encrypted firmware updates. Doesn't really help us now though because the FYbi file is decrypted inside the device so wouldn't be compatible.

*shrug*

[soundtec]

Ive tried many different combinations of buttons with the on off switch ,I can of course get the frequency cal mode up by pressing standby and channel 1 button while hitting the power switch ,there only a certain number of combinations of two or three buttons otherwise it would require more than one person to do it , the only thing I can find is holding the power button on the front panel down prevents  the unit starting  up from memory .

The 6800 hooked up ok to the software ,it wanted to update to 3.6 also ,but it didnt work in the end either .