Identifying the MCU from RT85 handheld Radio - Page 1
Forum section: electronics / general

author: Cassus
author_rank: Newbie
timestamp: June 11, 2021, 03:36:29 pm
content: Hello,I am trying to reverse engineer a RT85 Retevis handheld radio in order to produce a custom firmware. The main problem I have is to figure out the microcontroller they are using. They went through the effort of grinding the top of the chip to make it harder for people to guess what it is.The remains of a logo is still distinguishable on the bottom of the chip. Does anyone recognize a brand logo? I doubt it is an obscure Chinese manufacturer otherwise they would have tried to mask it.Also, the programming port has only 4 pins so I guess VDD, VSS, Data and Reset. That already excludes some brands like Microchip which uses at least 5 pins.I have access to a J-Link, ST-Link, ICD3, Oscilloscope and Logic Analyzer if that can help.here are the pictures:BTW, The TH-UV88 handheld radio from TYT uses the same PCB and doesn't erase the markings so if anyone has one lying around...

author: geggi1
author_rank: Frequent Contributor
timestamp: June 11, 2021, 08:08:18 pm
content: I guess this is a game of elimination.Start finding possible candidates for MCU same packages is a good start.Reverse engineer the circuit around the MCU to find pins that are detectable like power, gnd, databusses for cummunication to other devices and programming of the radio.Do the elimination by checking datasheets for the possible candidates.

author: Cassus
author_rank: Newbie
timestamp: June 12, 2021, 08:08:59 am
content: the problem with the package is that there is an insane number of different MCU when you dig a little. There are the common brands like Microchip, Atmel and STM but tons of small ones too. that's like finding a needle in a hailstack.+ the remains of the logo kinda looks familiar so that's even more frustrating

author: Cassus
author_rank: Newbie
timestamp: June 12, 2021, 09:25:58 am
content: I think I found the logo. it is similar to the one from another chip on the PCB. that make sense that they would use chips from the same manufacturer.can't find any infos on any QFP 48 chip on Beken's website though

author: amyk
author_rank: Super Contributor
timestamp: June 14, 2021, 01:25:30 pm
content: That's because it's a QFN32...http://antena.fe.uni-lj.si/literatura/Razno/BK4815/BK4815N_Datasheet_v1.0.1.pdfBut Beken don't make MCUs. I'd say the erased logo looks more like Silabs or Cypress.

author: EOZ
author_rank: Newbie
timestamp: June 18, 2021, 04:16:56 pm
content: It is a SC95F7617 from SinOne. A 8051 based microcontroller.

author: DavidAlfa
author_rank: Super Contributor
timestamp: June 18, 2021, 07:29:27 pm
content: http://radiochief.ru/raznoe/obnovlenie-proshivki-dlya-retevis-rt85-tyt-th-uv88/

author: andynvkz
author_rank: Contributor
timestamp: June 22, 2021, 02:50:17 pm
content: Quote from: EOZ on June 18, 2021, 04:16:56 pmTEA 32bit block 64bit keyhttps://vrtp.ru/index.php?showtopic=32228&st=0- the most up-to-date information

author: EOZ
author_rank: Newbie
timestamp: June 26, 2021, 10:58:19 pm
content: Thank you for the info but I need some proof or at least a good clue before putting a computer to break the key, because It can be TEA, but it can be also Skip32, SkipJack, SPECK, RC5, or any other of the hundreds 32-bit block ciphers available out there.Unfortunately I have only a few pairs plain text <--> cipher text so it is impossible to make any analysis to guess the cipher used.

author: andynvkz
author_rank: Contributor
timestamp: June 29, 2021, 11:06:25 pm
content: Forgot about keeloq, in fact, there are not so many algorithms suitable for this processor, I also wondered, but the documentation on SC contains descriptions of a bootloader working via UART with encryption, I asked SinOne for this information, they sent me the source codes of the bootloader and ready utilities for working with it, and lo and behold ... TEA is used there, I'm 90% sure that TYT did not change anything

author: EOZ
author_rank: Newbie
timestamp: July 05, 2021, 03:53:28 pm
content: Interesting... I have the SinOne bootloader tool, documentation and source codes but no encryption in any of these bootloaders or documents.It would be nice to have a look to the source code of a bootloader supporting encryption.

author: andynvkz
author_rank: Contributor
timestamp: July 06, 2021, 03:15:50 pm
content: Here are the files sent from SinOnehttps://drive.google.com/file/d/16l8N0sKpBvrAZYgUDFbezGwMamc1Qe97/view?usp=sharing

author: EOZ
author_rank: Newbie
timestamp: July 09, 2021, 07:44:55 pm
content: Thank you!You were right. They didn't modify a single bit of the TEA32 algorithm.Time to crunch some keys.

author: EOZ
author_rank: Newbie
timestamp: August 17, 2021, 09:42:31 pm
content: Hello. Just a quick message to show the progress in finding the encryption key used for the RT85 firmware.Cypher UsedA quick look at the firmware files shows the cipher is some kind of block cipher with a 32-bit block size. Thanks to andynvkz, who was able to get a Bootloader Toolkit from SinONE (the microcontroller manufacturer) we can confirm the cipher used is TEA, the Tiny Encryption Algorithm, in the 32-bit block size / 64-bit key version.You can find a working code of the algorithm used at:https://github.com/0x000000AC/Tiny-Encryption-Algorithm/blob/master/tea16.cInteresting to note the Bootloader Toolkit includes a tea library for the Keil compiler to be used with your bootloader. This means it is very probable the firmware was compiled also with the Keil 8051 C Compiler.EndiannessThe endianness used is the native one from the 8051 microcontroller. Let's call a the byte at address n, b the byte at address n+1, c the byte at address n+2 and d the byte at address n+3. These four bytes creates the 32-bit word ( a << 24 ) | ( b<<16 ) | ( c << 8 ) | dBecause the TEA algorithm divides the 32-bit word into two 16-bit chunks, we have V0 = ( a << 8 ) | b , and V1 = ( c << 8 ) | dCleartext / ciphertext pairsIf you are not familiarized with the 8051 microcontroller this is the most difficult part to understand. Getting pairs of cleartext / ciphertext was the most difficult part, because the entire firmware files are encrypted, but because it is code for a 8051 microcontroller, some information can be extracted from the first bytes, where the interrupt vector table resides. For example, these are the first bytes from one firmware file:file: A_UV88V1_09_20190929.bin00000000: d298fb36 e1628796 f8ce2d23 d389995d ...6.b....-#...]00000010: e1628796 e1628796 f8ce2d23 5c8948c3 .b...b....-#\.H.00000020: f8ce2d23 94f7c212 e1628796 e1628796 ..-#.....b...b..00000030: e1628796 e1628796 e1628796 e1628796 .b...b...b...b..The first 8051 interrupt vectors are:Address Interrupt======= ===========0x0000 Reset0x0003 INT00x000B Timer 00x0013 INT10x001B Timer10x0023 SerialThe Reset vector is located at address 0x0000. Almost every 8051 compiler places a LJMP instruction there pointing to the start of the code, so we know the first byte is 0x02, the LJMP opcode, followed by the jump address (two bytes).The next interrupt vector (INT0) is located at address 0x0003, and virtually any 8051 compiler places there a LJMP instruction (0x02) followed by the jump address in every used interrupt vector. In this case this will take bytes at address 0x0003, 0x0004 and 0x0005. The same for all the other interrupts: a LJMP opcode followed by the jump address.There are 8 bytes between interrupt vector addresses, and only three bytes are used (LJMP + address). The unused bytes usually are filled with zeros and we know the Keil compiler fills all these unused bytes with zeros. We also see for addresses over 0x0028 the same 32-bit sequence is repeated over and over: 0xE1628796. It is simple to deduce this is the encrypted version of 0x00000000.Now let's see the addresses 0x000B (Timer0), 0x001B (Timer1) and 0x0023 (serial) They all are inside a 32-bit block with value 0xF8CE2D23 and all of them correspond to the "23" part of it. All these blocks are followed by no zero blocks, this means they are used interruptions vectors, so we can asume they contain a LJMP as last byte. And analyzing the bytes before it, it is easy to see they are zero filled bytes.With all this information we can "partially decode" the first bytes of the firmware:00000000: 02xxxx00 00000000 00000002 xxxx000000000010: 00000000 00000000 00000002 xxxx000000000020: 00000002 xxxx0000 00000000 0000000000000030: 00000000 00000000 00000000 00000000So we can get the following correspondences:E1628796 ---> 00000000F8CE2D23 ---> 00000002And the following partial correspondences:D298FB36 ---> 02xxxx00D389995D ---> xxxx000094F7C212 ---> xxxx0000If you analyze some firmware files you will find many partial correspondences, but unfortunately only these two full ones.In few words: the goal is to find a 64 bit key that translates 0xE1628796 into 0x00000000and0xF8CE2D23 into 0x00000002.Breaking TEAThis is the funniest part. A simple web search and you will find some people saying a 32-bit block cipher is insecure or even that TEA is broken. Well... it is obvious they have never tried to break a real world TEA cipher.Some even dare to publish papers and code that are supposedly capable of breaking TEA but when you read it you discover they are breaking a one round TEA version (something that is trivial to break). The real TEA uses 32 rounds: they are trying to demonstrate how to open a safe breaking a cardbox shoe box.Some "serious" papers describe a method to guess the key that requires the key (!). This is the case of a description about related key attack on TEA that requires to cipher a number of cleartexts under the unknown key (how? It is unknown) and a related key, constructed using some math to the original key (how? it is unknown). Then comparing both ciphertexts they affirm the original key can be deduced. The problem is you need the original key to cipher some plaintexts, and also you need it to created the related key. If you have the original key, what is the point?An interesting paper talks about the relationship between the bitsum of the key and the bitsum of the chiper text under certain keys with a defined pattern. The bitsum of a binary number is just the number of ones in its binary representation. I made a lot of tests and I can't see this bitsum relation using "normal real world keys"My findings: The only property of TEA I have tested and confirmed is the equivalent key problem, which reduces the keyspace from 2^64 to 2^62 keys. It is a nice reduction, but not enough.It is really easy to find a key that decodes E1628796 into 00000000. With a 32-bit block size and 64-bit key a first guess is there must be about 2^32 keys that decodes E1628796 into 00000000 but hopefully there must be only ONE (four) that decodes E1628796 into 00000000*AND*F8CE2D23 into 00000002. Only one, but because of the equivalent key disadvantage of TEA, there are four equivalent ones.To check this premise I used a version of TEA using 16-bit blocks and 32-bits keys and encoded 0000 and 0002 under a random 32-bit key. Then I tried all possible 32-bit keys (a few seconds under a modern CPU) and got a little bit over 2^16 keys that decoded into 0000 and only four (all of them equivalent) that decoded both values into 0000 and 0002. The numbers seems to hold.As today, I have nearly 150000 keys that decodes E1628796 into 00000000, for example - 00000000 - 992C0C2D - 00000000 - 5D4A3022 - 00000000 - C92F088D - 00000000 - 9F5B9947 - 00000000 - C9FDAC48 - 00000000 - 8D629136 - 00000000 - BBE93F6C - 00000000 - 2D7245B7 - 00000000 - 0FA130C1 - 00000000 - D3FEA581 - 00000000 - DF51694F - 00000000 - 8C775878 - 00000000 - AC5D320F - 00000000 - 64397638 - 00000000 - E603E976First column is the key in order K0:K1:K2:K3. Second column is the decoding of E1628796, and third column is the decoding of F8CE2D23. You can use these values as test vectors. The "best" matches I have found yet are: - 00000000 - 0000D7E2 - 00000000 - 000088F3 - 00000000 - A10C0002And, if bitsum is a thing with real world TEA, this one is also interesting: - 00000000 - 11804000Although promising, they can't be used as a starting point to find the real key because the smallest change in the key and everything in the output changes a lot. TEA is a really powerful random number generator.Any idea? Any expert in cryptography out there? Any clue or algorithm to reduce the search space way down from 2^64 (2^62)?I started using the CPUs, and later, motivated by andynvkz I switched to GPU but still my worst case scenario is a bit over 500 years. Just too muchAny idea will be welcomed.andynvkz: I wrote you but your inbox is full, so I got the messages back.

author: andynvkz
author_rank: Contributor
timestamp: August 24, 2021, 01:09:19 pm
content: hello, what video card are you using for the password? a couple of days ago I bought a Geforce RTX3080Ti, but I'm thinking of rewriting the program from OpenCL to Cuda, like Cuda 30% faster

author: EOZ
author_rank: Newbie
timestamp: August 25, 2021, 06:21:41 pm
content: I'm using the internal GPU in the Intel processor. A toy GPU, but nearly 70 times faster than a single CPU core. Not bad at all :-)I had the opportunity to make a quick test on a RTX2070 and whoa!, it is fast! but not enough. The worst case scenario is still around 15 years.I'm wondering if a FPGA or an small number of them would be a better approach.

author: andynvkz
author_rank: Contributor
timestamp: August 26, 2021, 04:48:03 am
content: I bought myself an rtx3080ti, if you have a ready-made bruteforce program, would you like to share it? since I don't have much time to study cuda yet

author: amyk
author_rank: Super Contributor
timestamp: August 27, 2021, 01:52:45 am
content: Quote from: EOZ on June 18, 2021, 04:16:56 pmTry power glitching or other side-channel attacks. That's probably going to be easier than bruteforcing a key. (Do we know what else could contain the key, besides the MCU itself?)

author: andynvkz
author_rank: Contributor
timestamp: August 30, 2021, 01:46:36 am
content: Quote from: amyk on August 27, 2021, 01:52:45 amhello, there is no password in the firmware for the firmware, it is only in the MCU-LDROM, or hack the TYT server, then maybe we will get the firmware source)))

author: EOZ
author_rank: Newbie
timestamp: August 30, 2021, 12:21:40 pm
content: Yes... the key is in the LDROM (bootloader), but of course it is read protected.Glitching or sidechannel attacks? It would be nice but I have no experience in that and the manufacturer's datasheet say it is resistant to glitching attacks: "The SC95F751X has very excellent anti-jamming performance". If it is true, it will not be easy.I'm going to try the FPGA route. It is a good excuse to play with them.

author: andynvkz
author_rank: Contributor
timestamp: July 16, 2022, 07:17:38 am
content: Hello, about new versions of TYT UV88, I found an interesting document, MCU SWM181CBT6-50 may be

author: andynvkz
author_rank: Contributor
timestamp: July 16, 2022, 08:14:38 am
content: Foto 1

author: andynvkz
author_rank: Contributor
timestamp: July 16, 2022, 08:15:19 am
content: Foto 2

author: eb4fbz
author_rank: Regular Contributor
timestamp: December 29, 2022, 10:56:30 am
content: This new version with SWM181CBT6 MCU uses a much simpler encryption.

author: andynvkz
author_rank: Contributor
timestamp: January 03, 2023, 10:26:07 pm
content: Perhaps simpler, but I have not yet figured out which one, looks like xor, with a key of 1024 bytes, such as the MD9600, yet possibly protected chip is also easy to read as STM32

author: andynvkz
author_rank: Contributor
timestamp: January 04, 2023, 07:51:00 am
content: ha part of the firmware opened with a simple XOR 0xAF

author: andynvkz
author_rank: Contributor
timestamp: January 06, 2023, 04:51:57 am
content: We discard the first six bytes, the beginning of the file is xorim 0x5F further (presumably 6F,7F,8F)since there are 9F and AF approximately at the end of the file, the file is xed in blocks, how to guess the size of the blocks?

author: andynvkz
author_rank: Contributor
timestamp: January 09, 2023, 11:09:08 am
content: the file uses a different XOR, but if you look closely, you will see labels like 0x5F575757xx57 if I'm not mistaken, this is the beginning of the block, and xx^=0x08 values ​​​​for the XOR block

author: true
author_rank: Frequent Contributor
timestamp: January 12, 2023, 12:10:07 pm
content: I don't have one of these newer BS firmware radios, but this is what I've found from the provided updatertotal data portion is 66720 bytes. Is this a 128K flash MCU?Code:header: 6 bytes, xor'd with 0x57b[0:1] - length of payload, big endianb[2:5] - target address or offset of data block, 32 bits, big endiandata portion of the blocks is thus 0x801 (2049) bytes long, too long by one byte. doing some checks, the last byte doesn't seem to be a basic checksum. could be some other checksum method. is the last byte extra or is it some byte in the middle? can this byte be ignored or is it important?(edit: is confirmed the last byte is not the data, but we still don't know what it is yet. likely a checksum of some kind but I don't think it is simple summation.)here's a breakdown of the 31st data block, which has ASCII text:Code:08 00 (length)00 00 F0 00 (address / offset)and a breakdown of 33rd (last) data block, which has a different length:Code:04 a0 (only 1184 bytes)00 01 00 00 (address / offset)Using XOR 0x5F on the first data block gives what could be an ARM vector table (stack pointer looks sane, a couple jumps point to PC change) though almost every vector points to a block filled with 0xE7FEE7FE. I don't reverse engineer much; is this some compiler filler or intentional?Just a guess but it looks like the blocks are in groups of four. each block of these four is xor'd with [0x1f, 0x17, 0x0f, 0x07] though the first three bits of each page differ. so the first 4 blocks add 0x40, blocks 5-8 add 0x60, blocks 9-12 add 0x00... I don't know a pattern yet. where does the pattern come from? is it hardcoded or does it have to do with that extra byte? haven't checked in depth yet.(edit: I believe the key uses a bit pattern: 2, 1, 0, 3, then left shifted 1: 6, 5, 4, 7. doing this creates a table which I have attached. I've not yet assembled the firmware to determine if this is valid but this pattern results in some sensical data, gives 0x5F for the first block and gives 0xAF for the block with ASCII. this pattern seems to work for the first 32 blocks. I don't know what should be used for the 33rd block.)I don't know if a single byte key is used for each entire block as the entire firmware seems filled with data, so there aren't good zeroed out areas to test. Would have to test all values until getting valid and sane looking ARM code but it's harder to do (though possible) with block chunks.I haven't checked the MCU datasheet to determine if there is a built-in bootloader. Perhaps there is a built-in ROM bootloader that will let us read contents. I would guess the bootloader used for updates is not a ROM bootloader since it has this encryption stuff and weird protocol. Where is it located? Does this MCU have a way of jumping to different base address when booting, or is the main firmware responsible for jumping to the bootloader upon button held at boot? I ask this because the potential vector table in the decrypted firmware points to early addresses, so this firmware is likely loaded at the beginning of flash and executed first.I'll keep working on this BS series firmware stuff if you ultimately can't figure it out with this information.Right now my efforts are on getting the key for the BQ firmware (8051) key. Just a note: the TEA encryption is slightly modified in SinOne's tools and library code. I may try out of band attacks on this chip in April or May to recover the key if a key is not discovered by then.

author: andynvkz
author_rank: Contributor
timestamp: January 13, 2023, 04:34:07 am
content: about the beginning of each block (0x5F575757xx57) everything was confirmed, I didn’t think about the last byte, the beginning of the firmware is decompiled correctly

author: andynvkz
author_rank: Contributor
timestamp: January 13, 2023, 04:42:58 am
content: I tried the attack on TEA, it is real in time only if you know the first couple of bytes of the key, otherwise it takes a lot of time and it is not known how many rounds were used for encryption

author: true
author_rank: Frequent Contributor
timestamp: January 13, 2023, 05:53:16 am
content: Assuming the firmware vendor (TYT, or whoever they contract) used the SinOne tools, then we in fact do know exactly how they used and implemented TEA.It's one thing to decrypt, but what about sending new firmware? It would be good to know what this last byte does, and if it is necessary for sending new firmware to the radio with the existing bootloader. Perhaps write a short program that fits in the first page to send the bootloader contents out via UART?I forgot to attach my decryption notes so here it is.

author: andynvkz
author_rank: Contributor
timestamp: January 13, 2023, 06:07:05 am
content: I confirm, the last byte is the checksum, the block size is 2048 bytes, without the last byte the firmware is completely decompiled

author: true
author_rank: Frequent Contributor
timestamp: January 13, 2023, 06:12:20 am
content: What method is being used for checksum? Simple summation? Because I tested that and it doesn't seem to work. Is the checksum also XOR'd or no?Mind publishing the decrypted binary or should I do it?

author: andynvkz
author_rank: Contributor
timestamp: January 13, 2023, 06:26:35 am
content: IDA Pro 7.6

author: true
author_rank: Frequent Contributor
timestamp: January 13, 2023, 06:54:48 am
content: For this last byte, I have tried simple simmation, negated summation, and xor. None match.I looked at the updater in dnspy and see a single-byte checksum function there. However I don't see it being used. It may or may not be used by the bootloader to verify loaded data but isn't used by the updater. At this point I can only assume this is the function used. Even then, the output doesn't match whether I am checking a block with the header or without, decrypted or not.Do you want to try setting this checksum byte to 0 (every 0x806 bytes) and see if you can load the firmware to the radio? If so, we can ignore it.

author: andynvkz
author_rank: Contributor
timestamp: January 14, 2023, 05:28:55 am
content: if you really need, you can flash the firmware 256 times until the bootloader accepts

author: true
author_rank: Frequent Contributor
timestamp: January 14, 2023, 06:48:14 am
content: Quote from: andynvkz on January 14, 2023, 05:28:55 amAs I said, I don't have a BS radio yet. I only have BQ radios with the SinOne MCU.Still, that would be 256 times per block - what about when re-flashing with more blocks? It would be nice to know the method. This method could be used for a firmware that fits in one block to then dump the contents of flash out of the serial port.My intention is to write a replacement firmware for this radio, and maybe other BK4815 radios like the RA685 (easy encryption, GD32F330 ARM MCU). The user interface provided with these radios sucks. I want to make an amazing user interface and add features.Were you able to figure out the xor key for the last block?

author: andynvkz
author_rank: Contributor
timestamp: January 14, 2023, 10:28:39 am
content: I also have BQ, I found this firmware on the forum, a person bought this station and the seller sent him this firmware, what last block are you talking about?station serial number starts with Srewriting firmware is cool, but I'm only interested in removing the restriction on frequency input

author: true
author_rank: Frequent Contributor
timestamp: January 14, 2023, 05:47:22 pm
content: In the BS firmware we've been discussing, there are 33 blocks.I sent the pattern for decoding the first 32 blocks. I was wondering if you figured out the xor key for the last block.The last block may only be data and not code, so maybe you didn't...

author: true
author_rank: Frequent Contributor
timestamp: January 15, 2023, 12:58:36 am
content: I think I've figured out the checksum. I've only verified on the first two blocks so far but it matches.It's a standard summation of all decrypted bytes in a block, including the header. Decrypt each with its own key: 0x57 for header, and whatever for data block.Then do (256 - sum) & 0xff.Then xor with the block's xor key.So if you want to hack your functionality into an update, use the following function (pseudocode) to encrypt your data and include a checksum. pass in unencrypted data with a large enough buffer size.Code:/* assumes a full data block. (and perhaps block size influences the cipher?)* todo: check data length from passed header.*/void encrypt_and_checksum_block(uint8_t data, uint8_t xorkey){uint8_t sum = 0;uint16_t i;for (i = 0; i < 6; i++) {sum += unencrypted_data;data ^= 0x57;}for (i = 6; i < 0x806; i++) {sum += unencrypted_data;data ^= xorkey;}data = ((uint16_t)(0x100 - sum) & 0xff) ^ xorkey;}If interested I can write a bash shell, php script, python, C code or anything else to do this automatically: to convert a factory firmware file to a binary, or convert a binary to an uploadable firmware file.Knowing this may also help me bruteforce the last block's xor key. I'll write some code in a little bit to try that.edit:wrote a script to bruteforce matching checksums on each block (is in a future post). I have confirmed my analysis for previous xor values is correct. was also able to determine thatthe xor key for the 33rd block is 0xF2.of course this does not tell us what checksum to use with further blocks should we want to use this additional space for more code. if I get my hands on a BS radio, I'll write code to attempt to dump the bootloader to determine the sequence.

author: andynvkz
author_rank: Contributor
timestamp: January 15, 2023, 02:54:10 am
content: on the checksum, I matched the second block, the first did not matchof course, if there is a station, one first block is enough to write a program that will issue a bootloader via UART

author: true
author_rank: Frequent Contributor
timestamp: January 15, 2023, 03:10:55 am
content: All blocks matched what I earlier guessed.Here's my bruteforce code which determines the key based on checksum matching.Code:<?phpif (!@$argv) die('usage: '.$argv.' <single data block incl header and cksum>'>$b=unpack("C*",file_get_contents($argv));for ($keytest=0;$keytest<=0xff;$keytest++) {$sum=0;end($b);$last=key($b);for ($i=1;$i<=6;$i++)$sum+= ($b[$i] ^0x57);for ($i=7;$i<$last;$i++)$sum+= ($b[$i] ^$keytest);$sum= (256-$sum) &0xff;if (($sum^$keytest) ==$b[$last])printf("key %02X matches\n",$keytest);}?>And yes, as discussed before I think it would be nice to dump the bootloader with a small program that fits in one block.

author: andynvkz
author_rank: Contributor
timestamp: January 15, 2023, 03:35:28 am
content: yes checksum applies to all blocks, block headers separately xor 0x57

author: true
author_rank: Frequent Contributor
timestamp: January 15, 2023, 05:05:31 am
content: Quote from: andynvkz on January 14, 2023, 10:28:39 amDo you have a radio with BQ or BS series firmware? Or do you have both kinds of radios? This firmware will not work with a BQ radio, only with BS radio. I'm pretty sure you know this though.Quote from: andynvkzThis is exactly what my code shows...

author: andynvkz
author_rank: Contributor
timestamp: January 15, 2023, 05:46:45 am
content: I have BQ, I know that different MCUs, as I understand the block header consists of two bytes block size and 4 bytes block address, each byte XOR each other + XOR 0x57 we get the keyit's strange why the TYT website does not have this firmware ...Compiled a program for encrypting and decrypting the firmware

author: true
author_rank: Frequent Contributor
timestamp: January 15, 2023, 07:16:20 pm
content: Appreciate the decrypter. However, it does not work. It's also a random binary and not source code. We generally prefer source code on this forum when available: we all like to share and improve for each other =) I can always make one too.For us BQ radio owners I'll have time to do side channel attacks to recover the key in April or may. I know you may not be interested in a new firmware, but imagine a cheap HT like this with better, simpler and clearer menus in your native language... that's only one of my goals =)

author: yanki
author_rank: Newbie
timestamp: February 15, 2023, 03:10:44 pm
content: UV 88 programı bulamıyorum servisi cihaz parası kadar para istiyor bende yenisini aldım

author: yanki
author_rank: Newbie
timestamp: February 15, 2023, 03:13:23 pm
content: lazer ile yakmamışlar entegrenin ismini arkadaşlar bu entegre gerçekten fiziksel olarak yanıyormu yoksa programmı uçuyor bilgisi olan varmı yeniden programlanabiliyormu entegreyi söktüm ama boşunamı söktüm diye merk ediyorum cevaplarsanız teşekkür ederim

author: andynvkz
author_rank: Contributor
timestamp: February 16, 2023, 03:51:35 am
content: MCU uzun zamandır biliniyor

author: eb4fbz
author_rank: Regular Contributor
timestamp: June 24, 2023, 12:57:45 pm
content: Quote from: true on January 15, 2023, 07:16:20 pmHi. Did you found that time? It would be interesting to hack this firmware as they are doing on the UV-K5. I prefer RT-85/UV-88 radios.

author: true
author_rank: Frequent Contributor
timestamp: June 25, 2023, 09:01:07 am
content: I haven't tested in depth but I think this radio has a better designed front-end than the K5. Could be wrong.But with how cheap it is, the larger screen, and the better volume knob, I'm focusing efforts on UV-K5. I may come back around to this after August, and after I get new written firmware started for UV-K5. I have the equipment to perform an attack and attempt to recover the encryption key. I also have the development tools and spare MCUs to get started even if I don't successfully hack it.

author: eb4fbz
author_rank: Regular Contributor
timestamp: June 26, 2023, 04:15:52 pm
content: Forget about the RT-85 BQ encryption. It doesn't make any sense to spend time on breaking it if you can only buy BS version nowadays.RT-85 or UV-88 is definitely better. It has better shielding, better filtering, with a separate cavity for the BK4815, and one 6W power amplifier (HTL7G06S006P) per band instead of the single and 2W rated RD02LUS2 transistor used in UV-K5. Case feels way superior as well. The only drawback is they use BK4815 instead, which is only 128-590MHz.Other options are Retevis RA685 and Abbree AR-F5, using ARM MCU + BK4815.

author: true
author_rank: Frequent Contributor
timestamp: June 29, 2023, 10:14:06 am
content: Re: RT85 BS radio, I still haven't found one. All I have are BQ radios. (edit: I ordered two more brand new and they are both BQ. so I still only have BQ radios.) If I can get a BS radio, then I can simultaneously target firmware for it.As to it making sense to break it, isn't writing firwmare for these also a bit ridiculous and possibly seen as a waste of time? For me, breaking it would be for fun.Re: RA685, the units I have have yet a different board. MCU is not marked. Differs from other boards I have seen online. Voice is different too. Another issue is the top lights are way too bright and annoying.