Nope i didn´t dumped it. GPS is working fine but battery seems to drain soooo fast. I´ll take a look at your tools to write/dump and find what´s going on. Maybe a checksum, or maybe due to downgrade.
BTW ,I´ve found a “forgotten” string in cps refering to dh9800… About your tools , I need a python setup ,I´ll try later.
In windows “md1702_dfu.py versions” results in
<class ‘usb.core.NoBackendError’> md1702_dfu.py 462
No backend available…This command works in linux ,but not dumping or flashing without timeout errors
In Windows, you would have to configure libusb to create a filter driver for the device.
But what do you mean by timeout error? What type of the message does it display? And in which mode of the radio? You must be in normal mode to dump firmware and in flashing mode (#) to upload it.
Dumps ok , hex edited my dump and your dump of .22 matches. The dump can be flashed with your code ,but only boots in recovery mode. The .19 flash ends with “<class ‘usb.core.USBError’> md1702_dfu.py 448
[Errno None] b’libusb0-dll:err [_usb_reap_async] timeout error\n’” ,and also ends only booting in recovery mode.
In this case, it seems they either changed the flashing process in V2 bootloader or there is some issue with the flash memory in your processor. I would probably need captured communication (e.g. from wireshark in USB mode) of the stock application flashing .22 to see the difference.
But it may also indicate the problem with flashing V2 .19 firmware in stock .66 CPS. If my code times out, maybe the stock flashing in CPS does as well. Does it show correctly the percent bar when flashing there?
Do I understand it correctly that in case of .22 you can flash, but the result does not boot and in case of .19 it times out? Do you see the dots drawn in the first case after “Sending file name succeeded, starting upgrade” (I suppose they are not drawn in the second case). And do you see the “Upgrade finished, turn the device off and on normally” in the end of either cases?
I have tried flashing .19 V2 on V1 radio with my script and it successfully started the flashing process without a timeout.
One comment concerning the reduced battery life - is it really this way, or are you judging it from battery indicator? Because the battery indication in .22 seems to show less than in previous versions. It can be tuned by changing the value in test mode, the discussion was in the first 1/3 of this thread.
EDIT: I have increased the timeout in flashing script to 60 seconds if this was the issue and pushed the changes
Hello.
We tried with Daniil to update the radio firmware in a descriptive way holding down # and turning on the radio. Unfortunately it doesn’t. The software says no connection. I have a 2nd radio the same as this. It updated without any problems. The software says no connection. Do you have any idea why you won’t let me update?
Thanks in advance
Hi,
I suppose you are talking about stock CPS application and its upgrade menu? If it is not the issue mentioned in post #51 (i.e. failing to read the model number, indicating the V2, or maybe some newer version), I don’t know. Normally, it says this error message if it boots to normal mode, not the bootloader mode. Or they have created V3, which has a different bootloader mode not compatible with original CPS? 
I use 1.00.78 version of CPS. The firmware is 1702_v02.02.022. With them, I was able to update the firmware of one radio. The other, which is absolutely the same, does not want it.
And the version of the radio is correct? Maybe the radio is -V2 and the CPS does not want to flash it because of that as mentioned in previous posts (they edited the binini to make it work, but reported issues when trying to get back to .19 so I would not suggest it now)?
Can you use e.g. Wireshark in Windows to capture the USB communication during the failed upgrade to check the version or to save the communication and let me check?
I am guessing that the os this radio is running is microc/os-ii rtos running on arm. And if so is there any way we could get our hand on the ide and perhaps read the firmware file? I assume that its impossible because the firmware has already been build but you never know.
Yes, it is uCos-II RTOS, but the source is not available, the IDE project is probably hidden somewhere in the factory. You can download IDE for the processor, but without sources you would have to patch the firmware like they did for md380tools, separately for each version, or build the firmware fully from scratch.
It is possible to identify parts of the code, but there are over 1000 functions after decompilation and I identified what only tens of them do.
I’ll try to do that. How and where can I send you my result
Either post a link to the capture file here, or PM me with it here in the forum.
Ok. When I’m ready i send the results
Hello friends 
I would like to share important information with you about the radio discussed. From the Chinese site @bbree.com in the new version of firmware and CPS there is a virus.
Be careful
73! LZ1INP
Ugh, you mean the .78 version we have discussed in posts 25 - 45 including the virus? We have a healed version for the CPS version in those posts.
Actually you are not able to list the files on the web site download server in many web browsers as it is on malware list right now because of that. I tried to contact them in June, but they never did anything about the virus infection.
I wrote to them today. Expect an answer.
I also wrote to the dealer from whom I bought the radio. She urged me to stop my antivirus and firewall. There in China, it was opened without problems. I’m thinking of writing an official letter to Baofeng.
DO NOT STOP the AV or FIREWALL on original CPS. It really IS VIRUS INFECTED (writing just in case someone misunderstands your message).
Luckily I tested it in virtual machine I just reset to previous state. But you can heal it using some antivirus software. I did not see any misbehavior from the healed version, and the virus is quite old, but still dangerous.
Of course, I didn’t even think to stop my protection