How to try and support another TYT radio? [Help!]

[alvaroemtnez]

Hi! I've got a couple Retevis RT50 (aka TYT MD-680D) and I'm trying to port the OpenGD77 firmware to them. As far as I know, the binary file with the compiled fw has to be encrypted before flashing it to the radio, and I'm having trouble with this. As this is not a really popular device, there aren't any firmware loaders I can use, and I think nobody has cracked this encryption, as it happened with the GD-77, MD-380 and others.

I don't have access to any binaries with the original firmware to try and crack this encryption (and even if I did, I don't really know where to start), because the manufacturer provides an .exe file that does all the firmware upgrading (there is not a firmware loader and a firmware file like in the GD-77, the loader does it all and there's no way that I know to access the original firmware).

I've been told that the HD1 works in a similar way (only a fw loader and no fw file), and it's supported by radio_tool as its encryption was cracked. I was wondering whether this is possible with my radio, and how that was done, to try and do it with my MD-680D. I'm no expert but I've used C quite a lot, and I'm a bit stuck with this :(

Thank you so much

[alvaroemtnez]

By the way! I tried to connect the radio to dump the bootloader and when i use the "./radio_tool -d 4 --info" command, the terminal does nothing (it just stays still), until I unplug it and shows "Error: Failed to open port: /dev/tty.usbserial-1420". I suppose this is because it's not supported (or because it doesn't communicate properly as it's a Mac, I'll try it again on Windows or Linux when I get the chance). Of course, I couldn't dump the bootloader.

[v0l]

Have you started the radio in program mode?

There is a command to dump the bootloader as some bootloaders allowed reading from the bootloader section, this has worked for me on the DM1701 and i was able to extract the XOR key

[alvaroemtnez]

Yes, I've started the radio in program mode, and when I run "./radio_tool --list" I see the device ("[/dev/cu.usbserial-1410]: idx=3, Generic serial radio" and "[/dev/tty.usbserial-1410]: idx=4, Generic serial radio" appear).

But then if I use "./radio_tool -d 4 --info" to see if it reads something from the radio or if I run "./radio_tool -d 4 --dump-bootloader" to dump the bootloader, nothing happens. Terminal just freezes until I unplug the USB, and then displays "Error: Failed to open port: /dev/tty.usbserial-1410" (obviously, because I just unplugged it).

I don't know if I'm doing something wrong or if it's just a problem of the radio. Maybe my mac has some kind of issue communicating with the serial devices, because when I connect a Baofeng DM-1801 in DFU mode, it doesn't show using the list command (but it does when it's just turned on, it's weird).

Btw, I'm attaching the firmware upgrade tool Retevis provides, but I doubt it'll be of any use, as it's a compiled exe.
Firmware Update - RT50-V4.4.6_2.zip

[v0l]

Serial devices are for YModem style radios, since there is no way to identify what the device is we just list all serial devices.

Does this radio use DFU mode? or is it really a serial device?

[alvaroemtnez]

I'm not sure. I think the cable itself handles all the communication, because as soon as I plug it, a new serial device appears in terminal when I run the "ls /dev/tty.*" command (doesn't matter if the cable is attached to the radio, the serial port shows anyway). The cable has a small circuit next to the usb port.

The Baofeng shows only as a serial port when it's turned on (not when it's in program mode), and the cable has no chip, it's just a regular usb to headset jack cable. But I'm not sure how the MD-680D handles the firmware upgrading process, as it looks like the serial device is created by the cable's circuit itself, not the radio.

Edit: I just checked the cable circuit and it has a PL2303TA USB to TTL integrated circuit.

[v0l]

Yea seems to be serial device. Normally you can start with trying to identify what protocol the firmware program uses, you can do this by sniffing the serial port and using the stock firmware tool to issue commands to the radio.

You can google how to do that on your pc but here is a guide for linux using usbmon

If it happens to be YModem device, you can identify the commands by looking at the src code to see if it follows that protocol.

If it doesnt appear to be YModem then its currently not supported and you need to try and reverse engineer the process

[alvaroemtnez]

Thank you so much! I found an open source serial sniffer for windows (the firmware upgrade tool and the CPS only work on windows) and if over the weekend I have a some spare time, I'll have a look and see what i can find out.

I remember the stock firmware upgrade tool had a couple features: it could read basic info of the radio (model, etc.) and flash the firmware, so I hope I can find what commands uses and then work from there to flash my custom fw.

Even if I can communicate to the radio, there's still the firmware encryption problem... so, still a long way ahead :(

Thank you so much for your help! I'll check it as soon as I can :)

[alvaroemtnez]

Hi! I've been checking how the original firmware loader communicates with the radio and I'm pretty sure it's a YModem device (it starts the first frame with 0x01 and then the rest with 0x02, ACK is 0x06, etc.). I've used a sniffer tool and checked how the tool sends the fw to the radio:
writes.txt
reads.txt

With the write data the sniffer logged, I could even get the original .bin file of the firmware (by removing the header and CRC of each frame and then writing the whole thing to a .bin file using an hex editor):
TYT-MD359S-V4.4.6_2.bin.zip
I don't know if this is enough to crack the fw encryption or if I still need the bootloader.

I'm still having trouble communicating the device with radio_tool. I could even send commands to the radio using the "screen" command or PuTTY to open a 57600 baud port, but I haven't had any luck with radio_tool (in MacOS freezes, and in windows it does nothing, doesn't even show anything using the --list command). In case it helps, the radio responds to three commands (that I know):

• 0x31 (or an ASCII '1') tells the radio that you're gonna start sending the firmware (it starts sending back 0x43 because it doesn't receive the fw, but as it's shown in reads.txt, when it starts receiving frames, it sends back the 0x06 ACK).
• 0x32 (or an ASCII '2') displays basic info (the radio's fw version):

Version: TYT-MD359S-V4.4.6_2.bin
==========================================================

========================== Main Menu =====================

= (C) COPYRIGHT 2015 XiaMen Sloan Electronic Technology CO.,LTD

= Press 1 to Update application

= Press 2 to View Version

= Press 3 to Execute program

==========================================================

• 0x33 gets the radio out of the update mode and boots it.

So, for some reason, radio_tool doesn't communicate properly with the radio. I don't know if maybe this radio's commands are different to the other TYT devices supported (I don't know how those work), or if it doesn't open the port properly, or if I'm doing something wrong. Is there any way I can modify the firmware to make it work or is it too different? As it's also a YModem device, I think at least I should be able to flash the .bin file I retrieved (if there's a possibility to crack the fw encryption, but that's another thing...).

[v0l]

If i remember correctly i think the firmware tool actually decrypts the firmware to check something?
I think that was how it was reversed

[alvaroemtnez]

I managed to send the original .bin file I extracted with the sniffer using Tera Term and it gets installed correctly to the radio.

Basically I'm recreating what the original firmware loader does: open the serial port, send an ASCII '1' and then send the firmware file over using the YModem protocol. Then the radio checks the firmware binary (I suppose at this point it gets decrypted) and writes "Installation successful!" to the console.

I tried to send my modified firmware version (a basic compilation of the OpenGD77 firmware just to see if it turns on and does something) as an unencrypted binary. I wanted to try this out in case the binary wasn't encrypted, because in the RT50 original firmware you can see patterns, while in the encrypted binaries for other radios like the GD-77 and the MD-380 you don't see any (those look "fully encrypted" if that even makes sense). Anyway, didn't work, the radio just sends "Firmware verification failed" to the console, so I suppose it must be encrypted.

So, right now I'm stuck there. The firmware loader doesn't decrypt anything, it just sends the binary over via YModem and that's pretty much it. I can't get the bootloader using radio_tool because this radio only has three commands: one to program it, one to display the version number, and one to start the radio.

I've contacted Retevis and TYT in case I can get my hands on other firmware versions to see if there's any way to break the encryption code by comparing the versions, etc. If somebody knows a way to get the encryption key or has any ideas, please tell me (I suppose it must be encrypted using XOR or something really simple). The original binary is: TYT-MD359S-V4.4.6_2.bin.zip

Thank you so much

Edit: apparently if I just add the final part of the original binary (the last part with all the 0xFF and some random bytes in the middle) to my modified binary, it gets installed successfuly, but still doesn't work... weird

[n1zzo]

The radio you're trying to port looks a lot like the Ailunce HD1.
This means that the original firmware is obfuscated, and to need to crack that obfuscation too to load your firmare.
Hop on the OpenRTX matrix chat and we can give you a couple of hints about that!

Thanks,

Niccolò

[alvaroemtnez]

The radio you're trying to port looks a lot like the Ailunce HD1. This means that the original firmware is obfuscated, and to need to crack that obfuscation too to load your firmare. Hop on the OpenRTX matrix chat and we can give you a couple of hints about that!

Thanks,

Niccolò

Thank you so much but I decided to go the “easy” way and just attach a JLink, erase everything and load a modified version of the OpenGD77 (might even try OpenRTX when it supports M17 in the MK22 MCU!). Right now I’m mapping where each pin in the MCU is connected so I can compile a custom copy of the firmware that works on it.

And yes, this radio is quite obscure… I don’t know why they decided to use UART for the communication (and then needing an interface to convert it to USB) instead of just using the USB0 pins that the MK22 has. In fact, the headphone jack is connected to both the USB and UART pins of the MCU, so they could’ve just gone with a regular cable and no interface.

I wish I had the time and knowledge to decompile and understand the bootloader so I can flash the MCU using the USB cable, but I think it would be an enormous amount of work and it would take hundreds of hours. And if all that work could benefit the community, it would be worth it, but this radio is not popular at all and it has been discontinued by TYT/Retevis as far as I know. So I think the best option here is just to use a programmer and forget about the encryption and bootloader, etc.

Thank you so much for offering your help, I do appreciate it!
73

BTW: I’m following the OpenRTX project and it’s really exciting. I even bought an MD-UV390 to use with OpenGD77(now that they started supporting it) and OpenRTX. As soon as I have some time I’m gonna make the modifications and try it out. Congratulations and thanks for your work