With Wireshark I've managed to isolate the first part of the Application & RMS1 communication. The package capturing was done on the RMS1 using the wifi_debug.sh script. The protocol frame is much different from https://developer.dji.com/onboard-sdk/documentation/protocol-doc/open-protocol.html, which is really frustrating atm.

When the client connects to the RMS1 the following frame is sent (#1 & #2 are just captured at different times, it did a lot of testing and the behavior is always the same):

• The first byte represents the length of the data, in our case 0x30 = 48 bytes
• 2nd Byte 0x80 seems the magic number for most of the WiFi commands. It works like 0x55 when we you use the serial connection 192.168.42.1 – 192.168.42.3, this explains why tools like DUMLdore are able to get the S1 into update mode... however RedHerring, aka "July 4th Independence Day exploit" will not work with the S1
• The next two byte look like a session ID, the RMS1 will answer with the same ID
• Bytes 5-7: Don't know
• Byte 8 looks like a checksum for the first 7 bytes. I was unlucky to recalculate it, even with use of the DJI method implemented in the duml_crc.py. Some help & ideas are highly appreciated
  

The RMS1 always answers with the following sequence:



As you can see it follows the same rules as mentioned above. Byte 8 changed, because in byte 7 the value also changed.  

  

After that we have to keep the connection alive. It's a bit more difficult to find the right frames which are send from the application, because the S1 sends signal strengths, battery power and so on. I have not identified the magic heartbeat package from the RMS1 application yet. At ~ frame 279 the Client Application also started so send a list of the current firmware files, versions & checksum. I hope this is not needed to keep the connection alive...

Cheers

  

Quick question. Are you monitoring all traffic between the S1 and the host or is it just for specific ports? The reason I ask is because there are multiple ports being used. For example, the initial pairing (starting when the S1 reads the pairing QR code) happens over port 45678 in the host (a.k.a. server) and port 56789 in the client. Note that this traffic is fully obfuscated so it needs to be decoded before it can be made sense of. This might also happen with other traffic.

BGA Posted at 11-26 08:48
Quick question. Are you monitoring all traffic between the S1 and the host or is it just for specific ports? The reason I ask is because there are multiple ports being used. For example, the initial pairing (starting when the S1 reads the pairing QR code) happens over port 45678 in the host (a.k.a. server) and port 56789 in the client. Note that this traffic is fully obfuscated so it needs to be decoded before it can be made sense of. This might also happen with other traffic.

Hi BGA,

I use the tcpdump on the S1, there is a debugger shell script available. Just looked at the script, there is no traffic exclusion. When the capture is done, I pull it from the S1 and import it to Wireshark.

The QR thing makes sense, because there is no "connection" until the S1 knows its WiFi for the 1st time.

This CRC in byte 8 drives me nuts.

Cheers

sevreNniarB Posted at 11-26 09:33
Hi BGA,

I use the tcpdump on the S1, there is a debugger shell script available. Just looked at the script, there is no traffic exclusion. When the capture is done, I pull it from the S1 and import it to Wireshark.

Oh, is that all, this is an easy one. It is a parity bit.

For each bit in the first 7 bytes, byte 8 will have a 1 in the same bit if the number of 1 bits at the same position in the previous bytes was odd. if it is even or only has zeros, the corresponding bit will be 0.

Here is an example of the 2 packets you used:

22:00100010
80:10000000
18:00011000
34:00110100       
00:00000000
00:00000000
01:00000001
------------------
8F:10001111

22:00100010
80:10000000
5F:01011111
69:01101001       
00:00000000
00:00000000
01:00000001
------------------
95:10010101       

You can easily find code to compute parity bits if you search for it.

BTW, a really col thing to figure out would be what is the packet identifier. At first,m that will allow us to separate specific traffic (camera feed, audio feed, control feed, etc). After that, it might be easier to infer what each of the feeds would actually be and, with a bit of luck, what is the format.

At least, based on your observations, it looks this specific traffic is not fully encoded/encrypted. It might still be that the payload itself is though.

BGA Posted at 11-26 11:00
Oh, is that all, this is an easy one. It is a parity bit.

For each bit in the first 7 bytes, byte 8 will have a 1 in the same bit if the number of 1 bits at the same position in the previous bytes was odd. if it is even or only has zeros, the corresponding bit will be 0.

I'm such an idiot Thank you so much!

I think I have the id for video but i need to do some further analysis. Keep you updated and thanks again.



Cheers