All posts by John

I recently got a cheap WiFi FPV drone. Specifically the Visuo XS809HW. I can’t legally use it past line of site in the U.S., but I thought it’d be cool to take a shot at boosting the WiFi range. Initially I installed an external antenna which on its own will probably take the little thing out of my line of site, but I really wanted to take it a step further.

There are a couple cheap WiFi repeaters that can be used with pretty good results and I did buy one of them, but I really wanted to get it repeating from my 1000mw alfa with a nice 9dbi antenna to really be able to drive it out. On top of that I wanted to be able to easily take pcaps of the traffic so I can maybe work on reversing the protocols to get FPV and control native on the Pi.

Well I got it working with mixed results, but be warned, what follows isn’t exactly kosher networking. It’s not something I’d advise implementing on a real network, or for that matter, on a drone you’re not willing to see crash and burn.

The control latency is pretty good, but the FPV is pretty lossy with a full 1-2 second lag. In the future I’m likely to try a DDWRT repeater, and I’m considering working an angle to get my rtl8187 supported on LineageOS on my Pi via a custom kernel build or chrooted nix so I can run the XSW UFO app natively with the high power card and high gain antenna. Thats for a later day though, so lets begin with what we’ve got now.

Everything beginning with “pi#” is to be run on the Pi’s shell. Boxes following “CONFIG:” are inside a config file.

Starting with a fresh install of Raspbian Stretch lite install all updates and the requisite softwares. I use vim so if you like another editor then use that. Unless it’s emacs then you can just go suck an egg. 😛 If you’re not a nix nerd then you should probably use the nano editor instead of vim.

Generate network interface names based on their mac addresses. This way even if one wireless card is brought up before the other during boot the config files wont need to be changed because the cards swapped the wlan0 and wlan1 names.

After the device reboots ensure both of your WiFi devices are plugged in and run.

pi# ifconfig

You should see something similar to the following picture. The device names beginning with wlx are what you want to take note of. These are the names with which we will be addressing the WiFi cards in the following config files. If you’re unsure which card is which then just unplug one of them and run ifconfig again. The one that is still plugged in shows up. For the rest of this tutorial I will refer to the wired NIC as enx0 the card connecting to the drone as wlx0 and the card broadcasting the local network as wlx1, but you will need to use your device names.
Edit your /etc/network/interfaces file to reflect the following. I just delete everything in there and use the following config. If your drone broadcasts a secured network then see this link and make changes as appropriate. Adafruit WiFi Connection

Set up the dnsmasq.conf for the dhcp server. This bit is not exactly kosher. We’re starting a second dhcp server on the same subnet. This makes me cringe, but its listening on a different interface, there should never be more than a couple hosts on this machine at any time, and the ip range is well away from where the drone’s ip lease range starts. If someone out there can get dhcp-helper working reliably then that would be a much better solution.

Now we need to make sure that this hostapd file is actually getting loaded when hostapd starts. Modify the following /defaults/ file to match this.

pi# sudo vim /etc/defaults/hostapd

CONFIG:

DAEMON_CONF="/etc/hostapd/hostapd.conf"

Now we’re going to set up the avahi daemon. We need to enable mDNS relaying here. Do so by uncommenting the following line and ensuring it mirrors this.

pi# sudo vim /etc/avahi/avahi-daemon.conf

CONFIG:

enable-reflector=yes

Next make sure you’re in your /home/ and create a little script to reconnect your Pi to your drone whenever you inevitably change the battery. Then make it executable.

pi# cd ~
pi# vim ~/DroneConn.sh

CONFIG:

#!/usr/bin/env bash
sudo ifdown wlx0
sleep 2
sudo ifup wlx0

pi# sudo chmod +x DroneConn.sh

Finally disable unwanted services, enable the services you want to run at boot, reboot everything, and cross your fingers. I find that some times things fall over, but if I’ve got the drone on to hand out an I.P. to wlx0 then the Pi boots fine.

Recently I purchased a rather large Cloud At Cost service plan. It was like $240 for 8 CPUs, 8g memory, and an 80g HDD.

That’s pretty great even though the machine crashes and burns wayyy more often than it should. Well I do dig that it’s still somewhat powerful and I don’t much care that it dies weekly as I only use it for hacking on till I break it anyway, but I don’t like having to entirely rebuild my machine every time CaC borks it up.

To be a bit lazy there I hacked up a little script that helps me take their out of box Ubuntu 14 server and get it up as a remote desktop with some of my preferred tools. This could probably be used on any Ubuntu 14.04 server with minimal hackage.

It’s a bit vulgar, but we’re all adults here and it was hard to pass on this joke.

I did this write up like a year or so ago, but I want to post it up here in case it disappears; though, I think that’s a long shot. I don’t have the very original write up I did and I’m too lazy to dig through github to get my original, so I need to give some credit to the others that edited the page as I didn’t do literally everything you’ll read.

Pinout. You may want to download the image so you can zoom in on the text.

Pin #

SPI Pin Name

Raspberry Pi Pin #

1

not used

not used

2

3.3V

1

3

not used

not used

4

not used

not used

5

not used

not used

6

not used

not used

7

CS#

24

8

S0/SIO1

21

9

not used

not used

10

GND

25

11

not used

not used

12

not used

not used

13

not used

not used

14

not used

not used

15

S1/SIO0

19

16

SCLK

23

Note: The raspberry pi 3.3V rail should be sufficient to power the chip during flashing, so no external power supply should be required; however, at the time of writing that has only been tested and confirmed for one chip, the MX25L6405D.

Macronix Spec sheet so you can adjust your pinout for 8 pin 4Mb chips as necessary

At this point connect your SOIC clip to the rom chip before powering on your PI.

Power on your Pi, and run the following. Ensure you swap out “your_chip_name” with the proper name/model of your chip. Check that it can be read successfully. If you cannot read the chip and receive an error similar to “no EEPROM Detected” or “0x0 Chip detected” then you may want to try powering off your PI, and switching the two pins which are connected to the IO ports. I.E. Connect pins (clip)8 to (pi)19 and pins (clip)15 to (pi)21

This is a list of talks which I think are pretty great as supplemental study materials for anyone interested in learning a bit of the art and science behind keeping their computers and online presence a bit more secure. I selected these specifically to supplement crypto party workshops and talks, but each one stands on its own merit. With the exception of the first video, I listed them in alphabetical order as I feel they’re all pretty vital, and I can’t really pick and choose a fair ordering method.

Many of these videos use examples of people who did not use proper OpSec, Infosec, tools, etc. You may question why we should use these as materials to learn from. This is a fair question to pose. We certainly should study the right way to do things or else we will have nothing to model our security posture on, but that does not mean that we should not study those who failed so that we may learn from their lessons. I feel that the following riddle best explains my thoughts on this method. The answer to it is at the foot of this post.

Following the bombing of a major German city durring WWII the bomber crews were being debriefed by their Colonel. The Colonel asks the crews “From what direction did the luftwaffe attack?” Immediately and unanimously the entirety of the crews responded “From above and behind.” The Colonel wrote down the information and handed it to a courier ordering him to deliver it to the outgoing bomber crews immediately stating “This information could save their lives.” As the courier was about to exit the door the flight chief grabbed him by the arm and told him “belay that order, that information could cost the outgoing flight crews their lives.”

What was it that the flight chief was aware of that the colonel was not?

All of these can be found on youtube, but I also mirror them on my site for posterity here. I don’t hold any copyright on these videos, and have accredited them to their presenters and organizations as best I can. If you’ve got any comments or ideas of other videos to add to this list then please let me know. I’d love to hear from you!

The answer to the riddle above is: The flight chief was aware that since all of the men stated that they were attacked from above and behind the most fatal attacks might have come from a different direction, and the outgoing crews, equipped with incomplete information, would possibly fall to the same fate as the men that were shot down and did not return.