Сообщения

1

Трансиверы, приемники КВ/УКВ / Re: Rytera 6900DMR

« : 21 Октября 2025, 18:40:43 »

Внимание! Rytera 6900DMR изменила аппаратную платформу! Прошивки имеют другую ревизию!

CMIIT ID: 25Z35N05D690







Прошивка для новой аппаратной ревизии в аттаче

2

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 20 Октября 2025, 06:41:27 »

Эксперимент с инверсией цветов, насколько будет эффективно на солнце не знаю.

3

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 15 Октября 2025, 19:54:14 »

Для коллекции, прошивка DM32_047_firmware

4

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 15 Октября 2025, 19:45:46 »

Ты в этом всём разбираешься?

Мне очень и очень сложно  В Ghidra немного понятней что происходит но не до конца... Реверсинженеринг прошивки это кошмар 

5

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 14 Октября 2025, 19:14:42 »

а там весь интерфейс кракозябрами.

В папке с программой лежит файл cps.ini, открой блокнотом найди строчку lang=cn и замени на lang=en

6

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 14 Октября 2025, 05:34:34 »

Сейчас можно говорить только в канал напротив которого горит стрелочка.

У DM-32 одна кнопка приём/передача и пара функциональных. Стрелка указывает на выбранный диапазон A/B

7

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 13 Октября 2025, 18:39:33 »

Мой DM32UV не держит канал, выхожу на связь на 2501 и через несколько секунд скидывает на другой.

А если в настройках канала указать нужный контакт.

8

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 12 Октября 2025, 09:11:30 »

но я никуда не продвинулся, потому что ничего толком не сработало.

Я пока нашёл функцию чтения из флешь и подготовку для сравнения данных кода ALPU. Пока не понятно где вызывается эта проверка... Что-бы исключить её 
Да и кстати я попробовал IDA7.7, процессорный модуль от  andynvkz работает. Приаттачу ниже.

9

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 11 Октября 2025, 08:45:56 »

Я скинул пару функций DeepSeek  , ищем дальше...

Код: [Выделить]

int FUN_300dc690(uint param_1,uint param_2,undefined *param_3)

{
  int *piVar1;
  int iVar2;
  uint uVar3;
  int iVar4;
  uint uVar5;
 
  if (*DAT_300dc764 == 1) {
    iVar2 = -1;
  }
  else if (param_3 == (undefined *)0x0) {
    iVar2 = -1;
  }
  else if ((uint)DAT_300dc764[4] < param_1) {
    iVar2 = -1;
  }
  else if (param_2 == 0) {
    iVar2 = -1;
  }
  else {
    iVar2 = FUN_300dc574(0xfffffff);
    FUN_300dc410(0x14);
    piVar1 = DAT_300dc764;
    while (iVar2 == 0) {
      iVar4 = piVar1[3];
      uVar3 = piVar1[1];
      iVar2 = FUN_300dc574(0xfffff);
      if (iVar2 != 0) {
        return iVar2;
      }
      if (param_2 <= uVar3) {
        uVar3 = param_2;
      }
      uVar5 = iVar4 - (iVar4 - 1U & param_1);
      if (uVar5 < uVar3) {
        uVar3 = uVar5;
      }
      FUN_300dc47c(6,1,0,(undefined *)0x0);
      iVar2 = FUN_300dc47c(param_1 & 0xffffff | 0x2000000,4,uVar3,param_3);
      if (iVar2 != 0) {
        return iVar2;
      }
      param_2 = param_2 - uVar3;
      iVar2 = FUN_300dc574(0xfffffff);
      FUN_300dc410(0x14);
      if (param_2 == 0) {
        return iVar2;
      }
      param_1 = param_1 + uVar3;
      param_3 = param_3 + uVar3;
    }
  }
  return iVar2;
}


void UndefinedFunction_300dc8d0(void)

{
  uint uVar1;
  int iVar2;
  char cVar3;
  undefined auStack_24 [4];
 
  func_0x330c1578(0x10c,auStack_24,4);
  FUN_300c0964();
  FUN_300c0a14();
  FUN_300dc5c0(0x300b000,0x1000);
  uVar1 = DAT_300dc988;
  cVar3 = '\0';
  do {
    iVar2 = FUN_300dc690(uVar1,4,auStack_24);
    if (iVar2 != -1) break;
    FUN_300de844(100);
    cVar3 = cVar3 + '\x01';
  } while (cVar3 != '\v');
  FUN_300c0a38();
  FUN_300c0974();
  return;
}


подскажи что происходит
We are given two functions. The first one (FUN_300dc690) is a complex function that does some kind of I/O operation (likely reading from a device) and the second one (UndefinedFunction_300dc8d0) uses the first function to read 4 bytes and does so with retries.

Let me break down the first function in more detail:

FUN_300dc690:
Inputs:
param_1 (uint): offset or address
param_2 (uint): size to read
param_3 (undefined*): buffer to read into

Returns: int (0 on success, -1 on error, or other error codes)

Steps:

Check if *DAT_300dc764 is 1 -> return -1

Check if param_3 is NULL -> return -1

Check if DAT_300dc764[4] (maybe a max offset) is less than param_1 -> return -1

Check if param_2 is 0 -> return -1

Call FUN_300dc574(0xfffffff) and then FUN_300dc410(0x14). These might be setup or lock functions.

Then we enter a loop that breaks when iVar2 != 0 (which is set by the call to FUN_300dc574 inside the loop) or when we've read all data (param_2 becomes 0).

Inside the loop:

iVar4 = piVar1[3] (maybe a sector size or alignment value)

uVar3 = piVar1[1] (maybe a maximum chunk size we can read at once)

Then we call FUN_300dc574(0xfffff) again (maybe a wait for device to be ready?)

We set uVar3 to the minimum of param_2 and uVar3 (so we read in chunks)

uVar5 = iVar4 - (iVar4 - 1U & param_1) -> This calculates the number of bytes from the current offset to the next sector boundary?

Then we set uVar3 to the minimum of uVar3 and uVar5 (so we don't cross a boundary)

Then we call FUN_300dc47c(6,1,0,0) -> maybe a command to the device? (command 6, with 1 and 0 as arguments)

Then we call FUN_300dc47c with:

param_1 & 0xffffff | 0x2000000 -> maybe the address with a command bit set?

4 -> maybe the size of the address? or a mode?

uVar3 -> the size to read

param_3 -> the buffer

If that returns non-zero, we return that error.

Then we update:
param_2 -= uVar3
param_1 += uVar3
param_3 += uVar3

Then we call FUN_300dc574(0xfffffff) and FUN_300dc410(0x14) again (maybe for the next chunk)

If we break out of the loop because param_2 becomes 0, we return iVar2 (which should be 0).

So, the first function seems to be reading from a device in chunks, taking into account alignment and maximum transfer size.

Now the second function:

UndefinedFunction_300dc8d0:
This function:
- Declares a 4-byte stack buffer (auStack_24)
- Calls func_0x330c1578(0x10c, auStack_24, 4) -> this might be initializing the stack buffer or setting up a request?
- Then calls FUN_300c0964 and FUN_300c0a14 (initialization functions for the device?)
- Then calls FUN_300dc5c0(0x300b000, 0x1000) -> maybe mapping or setting up a memory region?

text
- Then it tries to read 4 bytes from the address stored in DAT_300dc988 (which is a global variable) into the stack buffer.

- It uses a loop that tries up to 11 times (cVar3 from 0 to 10) to read the 4 bytes.

- If FUN_300dc690 returns something other than -1, it breaks out of the loop.

- If it fails, it waits for 100 time units (FUN_300de844(100)) and tries again.

- Then it calls FUN_300c0a38 and FUN_300c0974 (cleanup functions) and returns.
So, the second function is trying to read a 4-byte value from a specific address (stored in DAT_300dc988) with retries.

Given the context, it seems like this code is for reading from a hardware device (like flash memory) that may require retries due to occasional read failures.

Note: The function names are automatically generated by the decompiler and don't convey meaning, but we can infer their purpose from the code.

If you have any specific questions or need more clarification, let me know.

Here's the analysis of the assembly code in English:

Function FUN_300dc690
Purpose: Read data from a device/memory with error handling and byte-by-byte access.

Logic:

Input parameter validation:

Checks global state (*DAT_300dc764)

Validates param_3 pointer

Checks param_1 boundaries

Verifies param_2 ≠ 0

Main read loop:

Calls FUN_300dc574 and FUN_300dc410 (likely device preparation)

Calculates available read block size:

c
uVar3 = min(param_2, piVar1[1]);  // Max size limitation
uVar5 = iVar4 - (iVar4 - 1U & param_1);  // Alignment/boundaries
uVar3 = min(uVar3, uVar5);  // Final block size
Executes commands via FUN_300dc47c (likely low-level device access)

Updates counters and pointers for next iteration

Returns: 0 on success, -1 on errors

Function UndefinedFunction_300dc8d0
Purpose: Read a 4-byte value with retry mechanism on failures.

Algorithm:

Initializes system (FUN_300c0964, FUN_300c0a14)

Configures memory access (FUN_300dc5c0)

Retry loop (up to 11 attempts):

Attempts to read 4 bytes via FUN_300dc690

On success - breaks loop

On error - waits 100 time units (FUN_300de844(100)) and retries

Cleans up system

Likely Context
This appears to be:

Device driver (e.g., Flash memory, EEPROM)

Hardware initialization system

Protected memory access

The code is typical for embedded systems where hardware failures are handled through retry mechanisms with delays between attempts.

10

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 09 Октября 2025, 19:56:18 »

JTAG отключил...
Ломать нужно прошивку 

11

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 06 Октября 2025, 18:37:04 »

Интересно. А что это даёт?

Недокументированная функция CPS для обновления прошивки.

12

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 06 Октября 2025, 06:42:20 »

Ещё один пароль CPS

Adjust Mode --> bfcps

13

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 05 Октября 2025, 21:27:08 »

Я, в лучшем случае, ковыряльщик.

Аналогично 

14

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 05 Октября 2025, 17:33:59 »

В конце концов, кажется, у меня получилось дизассемблировать код с помощью другого, уже готового специализированного инструмента для C-Sky с официального портала T-Head. Найти его было тем ещё геморроем, но в итоге я нашёл его здесь: https://occ-oss-prod.oss-cn-hangzhou.aliyuncs.com/resource/1356021/1619529111421/csky-elfabiv2-tools-x86_64-minilibc-20210423.tar.gz

Спасибо!
У меня идея!
Я пробросил порт 1025 в глобальную сеть  ты можешь подключится к плате через GDB target remote 94.181.174.35:1025
Ты можешь подключится?

15

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« : 05 Октября 2025, 09:41:42 »

С помощью дизассемблера нашёл место проверки кода ALPU но могу ошибаться