Retrieve raw Ublox log files and manually PPK post-process it using RTKLIB 

TLDR

• AeroPoints upload raw ubx-format log data over clear HTTP to AWS S3.
• Intercept using mitmproxy/wireshark/tcpdump/whatever
• Extract binary payload
• Post-process ubx data in RTKLIB; PPK or PPP mode.
• Enjoy accurate Ground Control Points.

Propeller AeroPoints are sold as a convenient way of placing Ground Control Points on an aerial imagery survey. You lay them out, turn them on, acquire your imagery and after collecting them, turn them on again in the presence of WiFi. Your data is uploaded to the cloud, and by magic the locations of your control points are given to, they claim, an accuracy of 5cm. $6000 for a set of 10, plus $600/year to keep your subscription to their cloud processing service active.

If Propeller stop paying their AWS bill, or you stop paying your subscription, these things become doorstops.

Long story short, I ended up with a set that someone was too cheap to keep up the subscription on, and I had some survey points I wanted to get at. In a commercial setting I’d pony up, but, $600 to get 10 control points was more than I could justify for a home project. And, philosophically, it’s my data. So, let’s have at it.

Reverse Engineering

So what’s actually going on inside these? Claims of kinematic GNSS accuracy for $600 a unit, and their cloud platform suggest it’s almost certain that low cost components are being used. But which?

GNSS Receiver

The ubiquitous Ublox M8-T module is a likely candidate, though I haven’t taken the foam off the back to actually find out for sure. It seems like a destructive process ripping off the foam backing. The M8T doesn’t perform real time RTK corrections by itself, but it doesn’t matter. As position solutions are being post-processed on Propeller’s cloud service, only raw log data from the receiver is required.

Logging and WiFi

The front panel of the AeroPoint tells us that it contains a part with ID 2AHMR-ESP12S. an ESP12. This is an FCC certified/SMT version of the popular ESP8266 WiFi-SoC, and host of a thousand low power embedded projects due it being available retain for a couple of bucks.

This tells me a few things:

• They’re using external storage, for the 4GB of log space. My guess is an SD card reader connected over SPI.
• They’re probably not TLS securing the data upload to the cloud. HTTPS support is known to be flaky on the ESP8266. It doesn’t really have enough memory to store the necessary certificates to validate the certificate chain and your application code.
• Even if they did get TLS working, they’d also need a full over-the-air upgrade stack, because what if a certificate expires or is revoked? Which means they also need a means of securing the OTA process.

My money is on this thing having baked-in firmware and communication in the clear.

And this is the problem with a lot of “IoT” devices. Poor or no security,  unmaintainable software, consigned to rapid obsolescence.

Admittedly, these are essentially GNSS data loggers that are only network connected for minutes at a time, infrequently. Outside of crypto-ned territory,  if ‘the man’ is your adversary, exploiting a buffer overflow via a man in the middle attack on your data logger’s HTTP client, you already know you need to be not running devices like this on your network. Or at least you should.

For everyone else, the real security risk is academic. Rant over. Moving on.

Extracting GNSS log data

The AeroPoint uploads data to an AWS instance over unsecured HTTP. Intercepting this is trivial. My approach in this instance was to use:

• Raspberry Pi-3 running Debian and running softAP wireless hotspot
• mitmproxy running in transparent proxy mode
  • There is no way to configure SOCKS/HTTP proxies on the AeroPoint
  • iptables configured to NAT preroute and route to mitmproxy’s listening port

See the mitmproxy documentation for a tutorial.

Ensure you have positively verified that traffic flows are saved and that you can extract the binary payload data from other hosts before attempting this process. Once the data is uploaded, it’s deleted from the AeroPoint.

Setup your Access Point with the WPA settings Propeller require, and power up the first AeroPoint. You should see some back and forth to:

• groundcontrol.propelleraero.com
• propeller-data-us-east-1.s3-accelerate.amazonaws.com

The initial API calls acquire an access key for the S3 data upload. You want the multi-megabyte payload of the POST calls to S3. The log data is sent as binary, in raw ubx format, no additional compression or packing.

Now, repeat for as many of the AeroPoints as you have. Refer to the mitmproxy documentation if you’re unsure how to do this.

Post Processing in RTKLIB

As with traffic interception, there’s more than one way to achieve the next step and I’m just going to refer you to the documentation.

In my case I loaded the ubx data into RTKLIB, and used PPK processing with a local CORS station acting as the base.

The folks at emlid have some good instructions on PPK techniques using RTKLIB. They’ve done a fair amount of work to improve the performance of RTKLIB on low-end hardware too. Check out their RTKLIB fork and their hardware too. Beyond retrieving the log data from their receiver, their process is applicable here.

In my case, I used RINEX logs from the AUSCORS archive (I’m in Australia) for a local CORS station, Fortunately I had a short enough baseline to a public CORS site for high accuracy solutions.

• AUSCORS high frequency daily data

One valuable thing a Propeller subscription buys is access to several commercial  CORS networks.

For additional accuracy, I waited a couple of weeks for the final GPS/GLONASS orbital data to be published and used the following data from IGS:

Final SP3 ephemeris 
File name format: WWWW/igsWWWWD.sp3.Z https://cddis.nasa.gov/Data_and_Derived_Products/GNSS/orbit_products.html 

Final clock data (30 second) 
File name format: WWWW/igsWWWWd.clk_30.Z https://cddis.nasa.gov/Data_and_Derived_Products/GNSS/clock_products.html

• https://www.ngs.noaa.gov/CORS/Gpscal.shtml
• https://www.ngs.noaa.gov/CORS/gpscal2019.txt

I hope that was useful to you. Don’t get me wrong, I don’t mean to put down Propeller or their cloud processing product. It looks like a nicely integrated service that I’ve not been able to try. For commercial use their system is likely going to save a heap of time compared to this approach.

A note on accuracy

Propeller don’t mention where the phase centre of the AeroPoint’s antenna is. I have assumed that it’s under the centre of the marker. The reason being that if the antenna was offset, there is no IMU/compass/gyro data present to provide the extra information about the panel’s orientation, which we need to know if the antenna is not in the centre. I also assume that it is directly below the surface of the panel. It may be that a few millimetres of vertical offset are required. If anyone has actually torn one down and can confirm please let me know.