Datos indescifrables en el monitor serie

Tengo un producto electrónico de trabajo listo para usar. Estoy aplicando ingeniería inversa en él. El módulo WiFi está conectado al microcontrolador a través de UART (RX y TX). La aplicación de Android envía un comando a WiFi y el microcontrolador funciona según el comando. He conectado un cable USB a TTL en RX y TX y también controlo la conexión a tierra del módulo WiFi. El cable está conectado al monitor serial en la PC. Cuando la aplicación envía datos a WiFi, el monitor serial muestra un valor indescifrable. He comprobado todas las velocidades de transmisión posibles. En lugar del cable USB a TTL, también usé el módulo Bluetooth HC05. Pero muestra datos indescifrables. ¿Cómo puedo obtener los valores legibles en mi monitor serial? ¿Necesito desconectar el microcontrolador de WiFi?

No se utiliza RS232 en todo el diseño.

Las dos primeras imágenes tienen datos similares pero con diferente tasa de baudios. Los datos de la primera imagen se establecen en 4800 y el segundo en 9600 sin paridad, datos de 8 bits, bit de parada 1. "0D" es simplemente ingresar el comando (para facilitar la lectura).

ingrese la descripción de la imagen aquí ingrese la descripción de la imagen aquí

La "basura" podría ser datos codificados en binario. No hay ninguna razón particular para pensar que el protocolo podría ser directamente legible por humanos. De hecho, muchas aplicaciones de "aplicación + dispositivo" realizan la mayor parte del trabajo pesado del software (incluida toda la interfaz de usuario) en la aplicación y envían comandos muy simples al dispositivo.
¿Espera que sus diseñadores le hayan facilitado la ingeniería inversa?
Por valor basura, ¿quiere decir que el mismo estímulo no produce el mismo valor? De lo contrario, si los valores son predecibles, ¿cómo son basura?
@DaveTweed ¿Hay alguna solución posible para esto? ¿Cuáles son los factores que debo revisar?
Use un 'scope para determinar la velocidad de bits real, y luego descargue los datos en un archivo e intente analizar los datos en busca de patrones usando un editor hexadecimal. Vea si los datos se correlacionan de alguna manera con sus acciones en la interfaz de usuario.
@Jacob La misma función en la aplicación envía el mismo valor, pero si no puedo entenderlo o no puedo leerlo, es un valor basura para mí.
@DaveTweed Claro, también lo hará.
@AnujMattóõ En ese caso, echaría un vistazo a la hoja de datos u otra documentación para el módulo WiFi. Supongo que está viendo un paquete de datos y que debería ser posible identificar el principio y el final y, por lo tanto, los datos (que probablemente aún no tengan sentido para usted). Tal vez podría identificar algunos mensajes estándar del módulo WiFi. ¿Qué es exactamente lo que estás tratando de lograr?
Las máquinas hablan en binario, los humanos no pueden leerlo. Esto no significa que todos los binarios sean basura. Tienes que analizar cuidadosamente los paquetes. Dado que puede obtener valores repetidos para una acción específica, intente comparar dos acciones entre sí. Lo que cambia y lo que permanece igual. Depende de ti encontrar el patrón que tenga sentido.
@Jacob Este es el enlace a la página del módulo WiFi [enlace] ( hi-flying.com/products_detail/… ).
@AnujMattóõ Lo que quise decir es que en tu lugar lo estudiaría, no que lo haría por ti 😊
@Jacob Sí, por supuesto. Tengo que hacer eso. Solo ayúdame. No pude adjuntar la hoja de datos. Así que tuve que adjuntar el enlace. Mi única necesidad es saber qué comandos o datos envía la aplicación al microcontrolador. Eso es todo. Ayudará en el diseño del producto.
Publique muestras de la "basura" etiquetándolas con los comandos que representan. Un diagrama de su configuración sería mucho más útil que todo el texto. Hay un botón de esquema en la barra de herramientas del editor. Publique enlaces a hojas de datos en su pregunta y no salpicados a través de los comentarios. Cambia la palabra "basura" en el título y publica a "no descifrable" si eso es lo que quieres decir.
Ahora presione el botón "Mostrar hexadecimal" y copie y pegue los resultados en su publicación para que podamos ver cuál es el "." los personajes son. Este código parece bastante trivial.
@transistor No se puede descifrar qué "." medio. Ocurre en cada comando. También pegué el código HEX.
@Jacob ¿Encontró algo sobre el módulo WiFi?
@DaveTweed Adjunté la captura de pantalla de los datos que estaba obteniendo en Serial Monitor. Por favor échale un vistazo.
La tasa de baudios predeterminada para el módulo WiFi es 115200. ¿Lo has probado?
@TomCarpenter Sí, también lo he intentado. El monitor serial solo muestra "." carácter repetidamente en secuencia.

Respuestas (2)

Parece que 4800 bps es la velocidad correcta. Los datos del 9600 son obviamente (!) los mismos datos muestreados con el doble de frecuencia. Así es como se hace ese análisis:

Aquí están los datos de 9600 baudios como aparecerían como una secuencia de bits. Los datos se escriben LSB primero, y he representado los bits de inicio y parada como minúsculas o(cero) y i(uno), respectivamente.

|06      ||3F      ||60      ||0C      ||FE      ||80      ||60      ||CC      |
o01100000io11111100io00000110io00110000io01111111io00000001io00000110io00110011i

Aquí están los datos de 4800 baudios, extendidos a la misma escala de tiempo:

| 71               | | 24              || 0F              | | A4               |
o 1 0 0 0  1 1 1 0 io 0 0 1 0  0 1 0 0 io 1 1 1 1 0 0 0 0 i o 0 0 1 0  0 1 0 1 i

Tenga en cuenta que cada bit en el flujo inferior corresponde a dos bits del mismo valor en el flujo superior. Tenga en cuenta que cuando se ejecuta a 9600, su escucha telefónica se vuelve a sincronizar en una transición de mayor a menor, por lo que hay un poco de "inclinación" alrededor de los límites de bytes a esa velocidad.

También está claro que una velocidad aún más lenta NO sería correcta: hay unos y ceros únicos aislados en los datos en 4800, lo que significa que esta es la tasa de muestreo mínima para estos datos.

La primera captura de pantalla hexadecimal (a 4800 baudios) parece prometedora:

Lo que está viendo es un mensaje de 4 bytes. El mensaje no está en ASCII , por lo que no es legible por humanos. El mensaje está codificado en binario (o hexadecimal, si lo prefiere) y, por lo tanto, debemos verlo e interpretarlo de esa manera. Binario normalmente da como resultado mensajes más cortos que ASCII.

ingrese la descripción de la imagen aquí

Figura 1. La tabla ASCII puede ayudar en algunos casos. 'OD', que aparece en sus capturas de pantalla, es el carácter 'CR' (retorno de carro).

  • Cada línea comienza con el carácter ASCII 'q' (0h71). Probablemente sea un preámbulo.
  • El segundo carácter en las respuestas que ha publicado es ASCII '$' (0h23) o '#' (0h24).
  • El tercer carácter se fija como 0h0F.
  • El cuarto carácter parece ser una suma de comprobación. Puede confirmar esto usando la calculadora de su computadora en el modo Programador . Seleccione el tipo de datos 'byte' (para truncar a 8 bits):
    • 0h71 + 0h24 + 0h0F = 0hA4.
    • 0h71 + 0h23 + 0h0F = 0hA3.

No ha proporcionado ninguna información sobre lo que hizo para generar los símbolos $ y # , por lo que no puedo ayudar más en este momento.

Datos indescifrables en el monitor serie
RespuestasAquíPolítica de privacidad1y, 0v