1
\$\begingroup\$

I have ready made working electronic product. I am applying reverse engineering on it. The WiFi module is connected to micro-controller via UART( RX & TX). The android app sends command to WiFi and micro-controller works as per the command. I have attached a USB to TTL cable on RX and TX also command ground as well of WiFi module. The cable is connected to serial monitor on PC. When the app send data to WiFi, the serial monitor shows Indecipherable value. I have checked every baud rate possible. Instead of USB to TTL cable, I also used HC05 Bluetooth module. But it shows Indecipherable data. How can I get the readable values on my serial monitor. Do i need to disconnect micro controller from WiFi?

No RS232 is used in whole design.

The first two images has similar data but with different baud rate. First image data is set at 4800 and second one at 9600 with No parity, 8 bit data, stop bit 1. "0D" is just enter command( For readability).

enter image description here enter image description here

Improve this question
\$\endgroup\$
  • 5
    \$\begingroup\$ The "garbage" might be binary-encoded data. There's no particular reason to think that the protocol might be directly human-readable. Indeed, many "app + gadget" applications do most of the software heavy lifting (including all of the UI) in the app, and send very simple commands to the gadget. \$\endgroup\$ – Dave Tweed Jun 26 '16 at 16:00
  • 2
    \$\begingroup\$ You expect its designers to have made reverse engineering easy for you? \$\endgroup\$ – Brian Drummond Jun 26 '16 at 16:00
  • 2
    \$\begingroup\$ By garbage value, do you mean that the same stimulus does not yield the same value? Otherwise, if the values are predictable, how are they garbage? \$\endgroup\$ – Jacob Jun 26 '16 at 16:03
  • 1
    \$\begingroup\$ Use a 'scope to determine the actual bit rate, and then dump the data to a file and try analyzing the data for patterns using a hex editor. See whether the data correlates in any way with your actions in the UI. \$\endgroup\$ – Dave Tweed Jun 26 '16 at 16:11
  • 2
    \$\begingroup\$ @AnujMattóõ What I meant was that in your place I would study it, not that I would do it for you 😊 \$\endgroup\$ – Jacob Jun 26 '16 at 19:03
5
\$\begingroup\$

It looks like 4800 bps is the correct speed. The 9600 data is obviously (!) the same data sampled twice as often. Here is how you do that analysis:

Here's the 9600 baud data as it would appear as a bit sequence. The data is written LSB first, and I've represented the start and stop bits as lower-case o (zero) and i (one), respectively.

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

Here's the 4800 baud data, stretched out to the same time scale:

| 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

Note that each bit in the lower stream corresponds to two bits of the same value in the upper stream. Keep in mind that when running at 9600, your wiretap is resynchronizing on a high-to-low transition, so there's a little bit of "slop" around the byte boundaries at that speed.

It's also clear that an even slower speed would NOT be correct — there are single isolated ones and zeros in the data at 4800, which means that this is the minimum sampling rate for this data.

Improve this answer
\$\endgroup\$
5
\$\begingroup\$

The first hex screengrab (at 4800 baud) looks promising:

What you are seeing is a 4-byte message. The message is not in ASCII so it's not human readable. The message is coded in binary (or hexadecimal, if you prefer) and so we need to view and interpret it in that way. Binary typically results in shorter messages than ASCII.

enter image description here

Figure 1. The ASCII table may help in some cases. 'OD', which appears in your screengrabs, is the 'CR' (carriage return) character.

  • Each line starts with ASCII character 'q' (0h71). It's probably a preamble.
  • The second character in the responses you have posted is ASCII '$' (0h23) or '#' (0h24).
  • The third character is fixed as 0h0F.
  • The fourth character appears to be a checksum. You can confirm this using your computer's calculator in Programmer mode. Select 'byte' data type (to truncate to 8-bits):
    • 0h71 + 0h24 + 0h0F = 0hA4.
    • 0h71 + 0h23 + 0h0F = 0hA3.

You haven't given any information what you did to generate the $ and # symbols so I can't help any further at this time.

Improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.