Intro
Last time I've explained how to debug the Unity Assembly-CSharp.dll. As a result we were able to take a look under the hood of the S1 application (https://forum.dji.com/forum.php?mod=viewthread&tid=201392)

Today we are going to learn how to edit and recompile the .dll and get access to advanced debug features that are already built into the S1 application This will be a prerequisite for future tutorials, please follow exactly my instructions - I will not explain it in the future.

  

What you need

  

• Installed Robomaster App on your PC
• Text Editor
• Some C# knowledge
• dnSpy
• Optional: Wireshark & PacketSender
  

  

What you get

  

• Debug-Logs (files), directly from the S1 app
• Better understanding how the app communicates with the S1
  

  

Preparation

Just in case if something goes wrong during the process: Make a Backup of your Robomaster installation!

Open dnSpy with administrative privileges and load the Assembly-CSharp.dll (if you don't know where to find it, please take a look at my last reverse engineer post). First thing we want to do is to force a higher debug level. Select the root level of the DLL in the Assembly Explorer:

You will see something like this:  

Line 16 will look different for you, because I've already modified it on my system. Right-Click in the code window and select Edit Assembly Attributes (C#). Replace your Debuggable line with this (everthing in one line, no CR!):

[assembly: Debuggable(DebuggableAttribute.DebuggingModes.Default | DebuggableAttribute.DebuggingModes.DisableOptimizations | DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | DebuggableAttribute.DebuggingModes.EnableEditAndContinue)]  

Compile the changes you've just made by clicking the Compile button.

---

At the next step we want to change the debug behavior of the UnityBridge.dll. UnityBridge is a 3rd party tool for Unity which allows data sharing with running processes. It is heavily used in the S1 application and we are able to change its debug functionality for our (future) purposes.

Edit the code as shown above (we are still in the Assembly-CSharp.dll!), and change:

DJIUnityBridge.CreateUnityBridge("Robomaster", false); to DJIUnityBridge.CreateUnityBridge("Robomaster", true);

Hit the Compile button.

---

  

(Re-)Compile the thing

Now we have to recompile our changes. Within the Assembly explorer select the Assembly-CSharp.dll, click on the file menu and select save Module. The MD Write options have to look exactly like this:

Everything else keeps untouched. Click Ok and the module (DLL) will be recompiled and saved. The robomaster.exe should start normal, if it crashes you've made a mistake...

---

Last step, edit the boot.config file

Locate the directory where your S1 application is installed (robomaster.exe). Navigate to the [RoboMaster_Data] directory and open the file [boot.config]. Add the following line and save the file. Nothing else is changed:

player-connection-debug=1

---

What you can do with it

We are finally done! If you followed my steps, the S1 app will create 3 logfiles and a directory when you start it. On my PC the files are located in the root folder of the D: drive, because I've installed the app in D:\Robotics. Please ignore the Tools and Windows Kits directories, they are part of my installation.

At a first glimpse we cannot do much with it, right? Wrong

The log files will give us a better understanding of how the messaging system is actual working. Take a closer look at the cmd log (in the RM_LOG folder) and compare it with the duml_cmdset.py. Do you see a similarity? Uploaded examples for you, the .py file is important, the other one is a log from my system:

duml-cmdset.zip (8.07 KB, Down times: 12)

2019-11-20 Upload

Click on the file name to download attach Cmd-Log.zip (114.13 KB, Down times: 15)

2019-11-20 Upload

Click on the file name to download attach

If we take it one step further and start Wireshark, we can see the following happening when the first handshake happens. Handshake = press the connect button in the S1 app, the App sends a "I'm here" message to the S1:

The first data byte (30) indicates the length of the data sequence (48 decimal), everything before the byte 30 is just header information. MAC, IP, ...

With this knowledge we can use a tool like PacketSender and the S1 will answer with its sequence.

Our Sequence:

x30 x80 xee x4d x00 x00 x00 x13 x70 x6f x64 x00 x64 x00 xc0 x05 x14 x00 x00 x64 x00 x64 x00 x64 x00 xc0 x05 x14 x00 x00 x64 x00 x14 x00 x64 x00 xc0 x05 x14 x00 x00 x64 x00 x01 x01 x04 x02 x01

Answer:

At this point I don't know how the keep-alive sequences are working nor how to read something like battery status, etc. but I'm sure that some of you will find a way... well, and I'll keep digging

Cheers

FYI, for the handshake mechanism, the app dos not really to send anything. The Robomaster itself sends broadcast packets that can be read and used to set up the connection (i.e. without the app initiating a handshake explicitly).

BGA Posted at 11-20 12:39
FYI, for the handshake mechanism, the app dos not really to send anything. The Robomaster itself sends broadcast packets that can be read and used to set up the connection (i.e. without the app initiating a handshake explicitly).

Hi BGA,

thank you! This is absolutely possible, but the handshake is happening at some point. The frame I've posted is the first thing the App sends after you hit "connect". After that there is some back and forth, incl. a check for Firmware updates, etc.

I'll try an empty frame with the correct data format (the first byte) and see what happens. I Hope the duml is not outdated, because I restored it after a little "my S1 installs its initial firmware accident" from the ota.zip.

I think we are on the right path with this approach.

Cheers

sevreNniarB Posted at 11-20 12:59
Hi BGA,

thank you! This is absolutely possible, but the handshake is happening at some point. The frame I've posted is the first thing the App sends after you hit "connect". After that there is some back and forth, incl. a check for Firmware updates, etc.

Fair enough. as I mentioned in another post, I can reliably set the connection currently although I can not do much else. I will commit some sample code showing that happening.

In any case, a cool side effect of how the setup works is that I can easily control multiple S1s *EVEN* if they were initially setup with the official app. Should be fun when I get actual control going on. I have 2 S1s so I will try some coordination example with them.

Also, if I can get the camera feed, we can run OpenCV locally and do some even cooler stuff.

Very nice!!

I just realized why I was stuck on figuring out the post-connection stuff. It seems all network handling after a connection is made is done inside the unitybridge DLL, which seems to be native code. From now on the most efficient way to move forward would be to use packet sniffing and the debug logs.  

Hello and good day sevreNniarB. Thank you for reaching out and for sharing these information with us. Great work and thank you for your support.