Mobile Weather Balloon Chasing Rig

A few locals (mostly part of the SecKC crew) have been chasing weather balloons for the past few months. It's an interesting way to get out of the house and go do something. We are also trying to reverse engineer the guts of these weather balloon payloads, but that's a story for another post.

Weather Balloons and Radiosondes

In the US, a number of National Weather Service offices (I'm guessing about a third to half of them) deploy weather balloons every day at about 0:00 and 12:00 UTC, give or take an hour either way. They often launch at about 45 minutes ahead of time, but they can be delayed by severe weather. That's over 700 weather balloons per year from each of the dozens of stations that launch them!

The weather balloons carry something called a radiosonde into the stratosphere. This package contains a battery, radio transmitter, GPS, and weather sensors. The radio transmissions include position information, humidity, temperature and other metrics, once per second. Position information is used to determine wind speed and elevation to correlate with the other metrics. This data is shared internationally and is used for local forecasts and models, and worldwide climate trends. 

Close up of the bottom panel of a 400 MHz Lockheed-Martin Sippican LMS-6 Radiosonde.

The air gets thinner and the pressure lowers as the balloon climbs past 100,000 feet, and it eventually bursts. The package, weighing less than a pound, falls back to the ground under a small parachute so that it doesn't hurt anyone or anything when it lands. 

Here's a video I shot through a telescope, of a weather balloon bursting at about 130,000 feet. You can faintly see the radiosonde swinging beneath the balloon. When it bursts, the parachute expands as the package falls.


A recovered weather balloon, after untangling all of the rope.

The National Weather Service does not recover these devices from the field. Some of them have a mailing bag and shipping label attached so that folks who find them can return them to be refurbished. The radiosondes that we've been finding have no instructions aside from "dispose safely". That is to say, once they have fulfilled their mission and landed, these radiosondes are very much "finders keepers" and are no longer government property. They can land more than a hundred miles away from the launch site, depending on jet streams and wind conditions closer to the surface.


To facilitate the tracking of these devices, a number of software tools have been created to make use of software-defined radio receivers (such as the RTL-SDR or HackRF One) or simple audio-decoding from a computer sound card. My favorite tools are radiosonde_auto_rx and chasemapper, both part of Project Horus, an amateur radio high-altitude-ballooning project in Australia. The tools to monitor amateur balloons happens to work just fine for tracking weather balloons, and folks have added code to help decode the payload data for weather balloons. 

radiosonde_auto_rx scans a small range of frequencies you define, looking for a signal that's likely to be a radiosonde. It then tunes to that frequency and tries to decode the location data. Once it's locked on, it continuously tracks the location of the balloon. It can also upload balloon location data to websites like sondehub (radiosonde tracking) and habhub (high-altitude balloon tracking), so folks can share data about these balloons' trajectories with a world-wide audience.

Screen shot from sondehub.org showing multiple weather balloons in flight, and locations of auto_rx sites:

Chasemapper acquires the balloon location data from radiosonde_auto_rx, and your location from local GPS data, then draws a map of your location and the payload's location, in a browser session. This is a nice visual aid when you're planning on recovering a radiosonde. Here's a screen shot showing my vehicle's track and a radiosonde payload location on a recent balloon chase. The payload location doesn't have a track following it because I rebooted my setup to move it to my car. The movement was from me hiking toward my car while unplugging the battery.

Building the mobile tracker

I decided I'd like to build a semi-mobile balloon tracker that I could leave running at home most of the time, but also quickly toss into my car or even carry with me if a radiosonde was going to be landing nearby, to help me recover it from some corn field or woods or an 8-foot tall patch of thistles and prairie grass out in the middle of nowhere. These things never seem to land anywhere convenient, like in the ditch of a dirt road. 

I decided to make do with stuff I already had laying around. You may recognize some pieces from previous articles. The below links are Amazon affiliate links to the parts I used if you wish to reproduce my exact setup, and purchasing from these links supports this site).

The MiFi 8800L not only offers 4G wireless connectivity so radiosonde_auto_rx can upload location data and chasemapper can download map data, but it also has a GPSd server integrated so other devices (like the Raspberry Pi) can use the GPS location of the hotspot. You must log in to the MiFi admin page to activate the GPS Service. By default, it runs on port 11010, and it's recommended to leave that default set.

Actually getting chasemapper to use that GPS data turned out to be more trouble than I had bargained for. You may be better-off connecting a USB GPS to your Raspberry Pi. I'll cover how I managed to cobble everything together as I go through this post. 

The first order of business was installing the latest RasPiOS to a fresh 16GB SD Card. There is more than enough documentation on raspberrypi.org to get you started. The Rii keyboard works both with a nano-receiver or via Bluetooth. Pick your poison. I chose to use the nano-receiver because bluetooth seems to not like to auto-reconnect on reboot some of the time. Feel free to use whatever kind-of-portable human-interface device you like.

Next, I had to get the display working. 

I had really good luck with the fbcp-ili3941 driver on this Raspberry Pi with Kali Linux, and the instructions I wrote about setting up fbcp worked fine on the latest RasPiOS. You can follow most of the instructions in that article to get the AdaFruit TFT working, just keep in mind the touch screen won't work with the fbcp driver. The digitizer on my display actually broke a few years ago, so I don't miss it.

For my setup, I uncommented the following lines in config.h. Note that these lines need the # at the beginning of the line. I removed the // from these two lines to uncomment them:



I used the following options to build fbcp:


As per the Kali instructions, I put the call to /usr/local/bin/fbcp near the top of /etc/rc.local so that it runs on boot.

I set my display up to run in 480p mode since the display is so tiny. The entirety of my /boot/config.txt file is:






Reboot and make sure the TFT display works.

Now for Radiosonde_auto_rx. The setup instructions mostly work. You'll need to install a bunch of dependencies. They recommend installing rtl-sdr from source. I just added it via apt, and it supported the bias-tee option. Make sure you install the udev rules and module blacklist options per the instructions. 

Keep following the instructions. Maybe, if you're lucky it'll just work. For me, though, I had to do some hacky garbage to get it to compile. If build.sh fails, you can try these tricks: 

I had to tell the compiler use the c11 standard for compiling fsk_demod by adding “-std=c11” to line 50 of auto_rx/build.sh, which now looks like this:

gcc -std=c11 fsk_demod.c fsk.c modem_stats.c kiss_fftr.c kiss_fft.c -lm -o fsk_demod

I had to tell the compiler to use the built-in alloca() for some reason, and the real baffler was having to define the meaning of freaking Pi, twice.

In utils/fsk.c, I added these lines to the "includes" block near the top:

#define alloca(x)  __builtin_alloca(x)

#ifndef M_PI

    #define M_PI 3.14159265358979323846


And I added the following to utils/modem_stats.c, also near the top. 

#ifndef M_PI

    #define M_PI 3.14159265358979323846


With all that out of the way, the instructions for setting up Radiosonde_auto_rx work just fine. Make sure to edit station.cfg. You probably want to specify a name, callsign or handle for uploading to HabHub (and enable uploads), and you should specify your latitude and longitude. You could, in theory, also use gpsd for radiosonde_auto_rx as well. I didn't set up auto_rx to use gpsd, so even when I'm mobile, the reports appear to come from the hard-coded location in auto_rx. I'm fine with that.

It seems that the National Weather Service relies mostly on radiosondes made by Lockheed Martin Sippican. The LMS-6 Radiosonde comes in two "flavors", one operating between 400 and 406 MHz and the other one operating around 1680 MHz. The Vaisala RS41 is a newer radiosonde model used at some locations, and it also operates around 400 MHz. You should ensure the proper frequency range for your location is enabled. The 1680  MHz radiosondes also work best with a circular-polarized antenna, similar to those you might use for certain FPV drone video.

Setting up Chasemapper

The instructions for Chasemapper mostly work out of the box, with the exception of GPSd in my case. The version of GPSd on the MiFi 8800L doesn't support JSON output which Chasemapper requires, so I ended up running a modern version of  GPSd on RasPiOS, pointing it at the GPSd on the hot-spot. Details on that toward the end of the article. I also had some trouble running GPSd on the default port of 2947, so of course I ran it on port 1337. 

For horusmapper.cfg, I changed only the following lines:

car_source_type = gpsd 

gpsd_port = 1337

habitat_call = [my amateur radio callsign]

Tying it all together

I didn't set up systemd services for anything, but you may want to follow the instructions in the git repositories to enable systemd services if you plan on building a dedicated tracker. I run gpsd, auto_rx and chasemapper on-demand with a simple shell script that I call "loon.sh":


gpsd -S 1337 gpsd://

cd ~/radiosonde_auto_rx/auto_rx

python auto_rx.py&

cd ~/chasemapper/

python horusmapper.py&

Everything runs in the background, and the terminal will fill up with logs about both chasemapper and auto_rx status. You can fire up your Raspberry Pi's web browser and hit localhost:5001 for ChaseMapper, and localhost:5000 for the auto_rx status page. 


GMRS and You

With the availability of handheld radios that are more powerful than cheap walkie-talkies, even more powerful radios for your home and vehicles, antenna masts and a small network of repeaters, GMRS allows your family some of the benefits of amateur radio, at a marginal cost, and without every member having to pass an exam. With a decent home and mobile GMRS radio set-up, your family could likely stay in touch even if you stray several miles from home for work or errands.

With the potential of a wide-spread infrastructure outage in an emergency, and increased tracking of location data via smart phones, payment card transactions and the like, adding GMRS to your family's communications strategy can make a lot of sense.


General Mobile Radio Service (GMRS) is a UHF Land Mobile Personal Radio Service, not much unlike Citizens Band (CB) or Family Radio Service (FRS). In fact, 14 frequencies used by GMRS are shared with FRS.

Up until the rules changed in 2017, one had to obtain a GMRS license to use channels 15-22 on FRS/GMRS handheld radios that look a lot like the one on the left in the title photo above. That radio is actually a 5 watt Midland GXT-1000 GMRS radio, but with a few caveats, it can be used for FRS as well.

Recent changes were made to allow up to 2 watts on channels 1-7 and 15-22 as part of FRS without obtaining a license. Channels 8-14 are still reserved solely for FRS use in the US, with a maximum of 500mW output. A number of FRS radios are available that run close to 2W on legal channels, but today I'll be focusing on GMRS specifically. The primary differences between FRS and GMRS are:
  • GMRS handheld radios are allowed to transmit up to 5W
  • GMRS mobile and base-station radios are allowed up to 50W
  • Removable antennae are allowed
  • Repeaters can be used on GMRS
  • An FCC license is required for GMRS, but there is no exam.
  • Businesses can legally use FRS for operations, but business use of GMRS is mostly disallowed.

The Rules

A short, multi-page primer on GMRS is provided by the FCC.
The full rules for operating on GMRS are in FCC Part 95 subpart E.

The short, short version of the rules that should cover most of the highlights:
  • No "public broadcast" messages, advertising or music
  • No profanity
  • Only communicate with other GMRS or FRS users. Communication with amateur radio stations is not allowed.
  • No "Jamming" or continuous transmissions
  • Don't use GMRS to assist in any criminal activity
  • You must identify your call sign (e.g. WRBX000) in English or morse code
    • At the end of a single transmission that you do not expect a reply to
    • At the end of a conversation
    • At least once every 15 minutes while communicating
  • You can authorize any family members to use your license with your permission.
    • Your parents, children, grandparents, nieces, siblings and uncles can legally operate on GMRS under one single license, if you give them permission and ensure they know the rules.
    • If they break the GMRS rules under your license, your license is likely in jeopardy. You are ultimately responsible for the actions of those using your license.
While GMRS is provided as a convenient way for family members to stay in touch, an authorized GMRS user is allowed to talk to others outside of their family. They do not need to be physically close enough to you to communicate with you as the license holder as long as they obey the rules.


Most adult United States citizens are eligible to apply for a GMRS license. As of 2020, the license fee is $85, and it is valid for 10 years from the date of issue.

One can apply for a GMRS license online through the Universal Licensing System, or by mail. Either way, you must fill out FCC Form 605. Filing online requires you to register for an FCC Registration Numer (FRN) if you do not already have one. Amateur radio operators may use their existing FRN, for example.

Once logged in to ULS, click "Apply for a new license" and choose "ZA - General Mobile Radio Service" from the very bottom of the drop-down list.

Upon completion of FCC Form 605 for GMRS, you will be required to make an online payment. Your license will usually show up within a few hours or on the next business day. You will also likely receive an email about your license grant.



Transceivers specifically designed for amateur radio are not allowed on GMRS. Some hams use commercial radios that have been tuned to work on amateur radio frequencies, and there's a bit of a grey area there.

Until recently, hardware specifically designed to take full advantage of GMRS was pretty rare. Radios must be type-certified under FCC Part 95 to operate on GMRS and strict standards must be met with regard to channel deviation, frequency stability at a wide variety of temperatures, and spurious emissions. It just so happens that commercial land mobile UHF Radios type-certified under FCC Part 90 meet or exceed the specifications for GMRS, so long as they do not exceed 50 watts of output power. As such, many GMRS users will re-program commercial UHF radios to operate on GMRS frequencies. The FCC hasn't ever given a straight answer about if this is allowed, but most repeater operators are okay with it. The Motorola Radius in the above photo is one of these, but a variety of 15-45 watt mobile radios and 2-5 watt handhelds from the commercial lines of Motorola, Kenwood, Bendix/King and others can often be found inexpensively on the used market. Just make sure you, or the seller, can program them properly.

BTech (purveyors of the ubiquitous, cheap "Baofeng" ham radios) markets two GMRS-specific radios: the GMRS-v1 handheld and the GMRS-50X1 mobile radio. These two have been type-certified for GMRS, have the ability to use GMRS repeaters, and are legal. The GMRS-V1 is, in fact, the only GMRS-specific handheld radio I was able to find that has repeater capability.

Midland, Cobra, and Uniden have also been making a variety of type-certified GMRS radios. Most of the handheld units, like the Midland GXT-1000 I have, do not have the capability to use GMRS repeaters, but the Midland Mobile and Micro-Mobile radios, designed to be installed inside vehicles, do have repeater capability.

Most GMRS radios are interoperable with FRS radios. The GMRS-specific radios mentioned above may have more than 22 channels, but channels 1-22 are almost guaranteed to work between any GMRS and FRS radio. If your family does a lot of outdoor activity, you may find that inexpensive FRS radios work fine for kids, and your GMRS radios will let you communicate with them.

Many old-school GMRS users refer to frequencies -- and especially repeaters, by the kilohertz part of the frequency only. I suspect this persists in part because GMRS users are begrudgingly sharing practically all of their frequencies with FRS users and dislike the concept of channel numbers. At any rate, "700" refers to either 462.700 MHz, or a repeater that uses 467.700 MHz on the input and 462.700 MHz on the output.

You can see actual frequencies in this chart on Wikipedia:


Like amateur radio, GMRS operators can run repeater systems. These repeater systems listen 5MHz higher than the base frequency, and re-transmit the signal on the base frequency so that all radios listening can hear the message. Not all regions have GMRS repeaters, but here in the Kansas City area, there are several to choose from. Unlike amateur radio repeaters, most of them require permission from the repeater operator before you use them.

MyGMRS.com is probably the closest thing there is to a directory of all GMRS repeaters in the United States. You can browse the repeater listings without signing up for an account, but many repeater details (such as the CTCSS or DCS codes to use them) are hidden until you log in. Some of these details are completely unlisted, instead requiring you to ask the repeater owner for permission. You can only create a MyGMRS account once your GMRS license has been active for a day or two and the website has imported your license from the FCC.

You can also buy or build your own GMRS repeater, and it probably comes as no surprise that commercial repeater hardware is also quite common. Repeater building is a complex topic I won't cover here, but the cost is usually pretty significant.


Yaesu FTM-400XDR - Undocumented Cross-Band Repeater Mode

I was in the market for a new dual-band amateur radio. I'm a bit of a Yaesu fan, and I was torn between trying to find a used workhorse like the  FT-8900R, or trying something a bit more modern, like the FTM-400XDR. The one thing I really wanted the '8900R for was its cross-band repeater. That was the only thing missing from the new '400XDR.

Cross-band repeater mode will listen on two different bands (usually 70cm and 2m) and repeat what's being "heard" on one of the bands, transmitting it on the other. You can use this for a variety of purposes, but it's most commonly used to boost the range of a small handheld radio when you can't feasibly take a high-powered radio with you -- such as into an office building, down in your basement storm shelter, or keeping in touch with a group of spread-out friends while in an area without good repeater coverage.

Lo and behold, the FTM-400XDR does have a cross-band repeater built-in. It's just not documented officially. It's actually pretty easy to set it up.

Start by configuring your radio's tuners the way you want them to work together. Check that the frequencies, repeater offsets, squelch are all correct, and disable APRS if you had it enabled.

In this case, I configured the top tuner to communicate with a local repeater, on medium power. It might be kind of hard to see, but there are indicators "-" and  "T-TRX" in the header of the top tuner that indicate a negative repeater offset, and "Tone Squelch on Transmit and Receive" which are common radio configurations for repeater use. You could instead set the upper tuner to a simplex frequency if you want to run it as a stand-alone temporary repeater.

The bottom tuner has to be on the other band. Since the repeater I wanted to talk through is on the 2m band, I selected a simplex frequency from within the 70cm band.  Since I plan on staying pretty close to my radio for this test, I set the power level on the bottom tuner to low power, and made sure there was no auto-repeater-shift offset. You'll notice there are no indicators in the header of the lower tuner. You would not want to accidentally link two other repeaters together. Don't cross the streams.

Power the radio off. Next, hold the SETUP, F and GM buttons under the power button at the same time. Keep holding them while you power the radio on.

When it powers up, you will see an "X-Repeater" indicator in the middle of the screen.

If you're setting up a stand-alone repeater, all users will have to configure their dual-band handheld radios for "split" operation. This varies by make and model, but you'll want them to transmit on the same frequency as the bottom tuner, and receive on the same frequency as the top tuner of the '400XDR. Anything transmitted by members of your party on the lower tuner's frequency will be repeated out to everyone else listening on the upper tuner's frequency.

To use the cross-band repeater with another repeater like I did, you'll want  to set your handheld radio to use the simplex frequency, without a repeater shift, that's displayed on the bottom tuner. The cross-band will relay bi-directionally, so whatever you transmit will be sent to the repeater configured on the upper tuner, and whatever the repeater transmits will be sent back to your handheld via the simplex frequency on the lower tuner.

To disable cross-band repeater mode, power the radio off, then use the same 3-finger-salute while powering it back on.

  • When the repeater isn't being actively used, you're still responsible for ensuring it is functioning properly. Your cross-band repeater has no way to identify itself. (e.g. CW ID) and lacks the sophistication of a real repeater.
  • You or someone you trust should be close enough to your cross-band repeater to shut it off quickly should it malfunction or otherwise transmit undesired activity (such as static, intentional interference, radio pirates).
  • Turn the radio off or disable cross-band repeater mode if you are not actively using it or are unable to monitor it.
  • Use the minimum power level possible for the communications required. This is just best-practice, but also, if you end up cross-band repeating a long-running discussion, you may overheat your radio and/or drain your car battery. Mobile radios like this are designed for a relatively low duty cycle -- transmitting only for a few minutes at a time, then given a chance to cool down while others talk. Low power (5 Watts) is probably safe for extended, continuous bidirectional operation.
  • The FTM-400XDR is capable of operating on Yaesu System Fusion (C4FM) digital modes, but under cross-band repeater mode, it will only operate in analog FM mode. You cannot cross-band repeat to a digital repeater from an analog handheld radio.
    • I do wonder if another Fusion radio could communicate through a cross-band repeater to a Fusion Repeater and vice/versa... I don't have a second Fusion radio to test this with.


02/02/2020! The first palindrome date since 11/11/1111

It's been almost a decade since I've seen an "only happens every several hundred years" thing floating around that seemed too out-there to be real.

So let's debunk the "first palindrome date since 11/11/1111" shall we? Surely these happen more frequently than that. And for shame not using ISO-8601 format. Fortunately, today also works as an ISO-8601 palindrome: 2020-02-02.

I whipped up a quick bash script to scan for dates n-days before and after today's date looking for palindromes in ISO-8601 format as well as the two other formats that are commonly (ab)used here in the United States, DD-MM-YY and DD-MM-YYYY. It's inefficient, relying on a lot of calls to date(1) and rev(1) but it is what it is.

export i=1
while true
# ISO-8601 or GTFO.
idtb=`date -v-${i}d +%Y%m%d`
idtf=`date -v+${i}d +%Y%m%d`

# MM-DD-YYYY format
ydtb=`date -v-${i}d +%m%d%Y`
ydtf=`date -v+${i}d +%m%d%Y`

# MM-DD-YY format
dtb=`date -v-${i}d +%m%d%y`
dtf=`date -v+${i}d +%m%d%y`

if [ "$idtb" -eq "`echo $idtb | rev`" ]
echo YYYYMMDD $idtb was a palindrome.

if [ "$idtf" -eq "`echo $idtf | rev`" ]
echo YYYYMMDD $idtf will be a palindrome.

if [ "$ydtb" -eq "`echo $ydtb | rev`" ]
echo MMDDYYYY $ydtb was a palindrome.

if [ "$ydtf" -eq "`echo $ydtf | rev`" ]
echo MMDDYYYY $ydtf will be a palindrome.

if [ "$dtb" -eq "`echo $dtb | rev`" ]
echo MMDDYY $dtb was a palindrome.

if [ "$dtf" -eq "`echo $dtf | rev`" ]
echo MMDDYY $dtf will be a palindrome.
export i=`expr $i + 1`

A quick run for a minute or so shows a lot of palindromes past and future.
MMDDYY 021120 will be a palindrome.
MMDDYY 022220 will be a palindrome.
YYYYMMDD 20211202 will be a palindrome.
MMDDYYYY 12022021 will be a palindrome.
MMDDYY 121121 will be a palindrome.
MMDDYY 122221 will be a palindrome.
MMDDYY 112211 was a palindrome.
MMDDYY 111111 was a palindrome.
YYYYMMDD 20111102 was a palindrome.
MMDDYYYY 11022011 was a palindrome.
MMDDYY 012210 was a palindrome.
MMDDYY 011110 was a palindrome.
YYYYMMDD 20300302 will be a palindrome.
MMDDYYYY 03022030 will be a palindrome.
YYYYMMDD 20100102 was a palindrome.
MMDDYYYY 01022010 was a palindrome.
MMDDYY 031130 will be a palindrome.
MMDDYY 032230 will be a palindrome.  


AppSec Lab: RasPwn with a MiFi-8800L JetPack Router

I'm hosting a few Application Security workshops later this year. I settled on RasPwn for the lab because it comes pre-configured with a bunch of vulnerable applications out of the box.

RasPwn acts as a stand-alone wireless access point using the Raspberry Pi's on-board Wi-Fi. If you plug in ethernet, it can route packets, but DNS forwarding seems broken. Some of the participants will have to be online and available during the workshops, so I wanted to make sure the lab has full Internet access. Additionally, it helps when folks can look up information about vulnerabilities while learning new concepts. I won't always be able to rely on on-site ethernet to provide Internet access to participants, so I decided to set up my MiFi 8800L hotspot as an Internet gateway on RasPwn, and I had to make sure DNS worked.

Hotspot setup:
When you plug in most WiFi hotspots over USB, some will only charge the internal battery, while others will immediately show up as a network device. Some also show up as a "virtual USB drive" with drivers and software. The Inseego MiFi-8800L touch-screen model prompts you when you plug it in, and has an option to serve Internet via USB only or USB+WiFi.

If you use the Web UI, you can set this option as the default. There's no way to set it up from the touch-screen interface. All other Inseego (and their previous brand, Novatel) hotspots I've used can be set up to provide USB Internet access by default, using the web admin portal. See owners' manual for details on accessing the admin portal. It'll probably vary widely by model. Example from my 8800L:

RasPwn setup:
  • Download the RasPwn software and follow the install instructions on the download page. If you've messed with Raspberry Pi distributions before, this should be pretty self-explanatory.
  • Place the card into a Raspberry Pi 3 and power it up. You won't need a screen or keyboard for anything. I did have to power-cycle the Raspberry Pi after the first boot for the WiFi network to show up. You may have to do the same.  
  • When RasPwn boots up, you'll see a new WiFi network called RasPwnOS show up. Connect to it. The default WiFi password is In53cur3! 
  • SSH to The username is pi and the password is pwnme!
    • ssh pi@
  • Set up eth1 (for the hotspot's USB interface)
    • edit /etc/network/interfaces with vi or nano
    • insert the two lines below, preferably after "eth0" is specified:
      allow-hotplug eth1
      iface eth1 inet dhcp
    • Save the file
  • Change the IP masquerading rules for iptables to use eth1
    • edit /etc/iptables.up.rules with vi or nano
    • change the MASQUERADE rule from
    • save the file
  •  Set up the DHCP server to issue an external backup resolver
    • edit /etc/udhcpd.conf with vi or nano
    • change the "opt dns" line from
      opt     dns
      opt     dns
(Note: the DNS stuff is kind of hacky. You could configure the on-board bind9 DNS server to resolve recursively, but it's more complicated and this works just fine)
  • Reboot RasPwn and test Internet connectivity.
    • sudo reboot
    • Close your SSH window
    • Wait a minute or so
    • Reconnect to the RasPwnOS wifi network
    • Try browsing the internet. If it doesn't work, make sure the HotSpot is showing a USB connection. You may need to unplug it and plug it back in, or unplug the hotspot, reboot RasPwn again, and plug the hotspot in after RasPwn boots up all the way. 
Okay, so let's hack something!
  • Go to playground.raspwn.org from your RasPwn WiFi connection 
  • Pick an app and start hacking!
The first thing in the playground is the OWASP Bricks practice application. It's intentionally vulnerable and designed to be increasingly complex with each challenge building on what you learned with the previous ones.

Some of the exercises will require an intercepting proxy such as BurpSuite, Charles Proxy, or OWASP ZAP, but the first login page can be hacked with just a browser. I actually didn't read any documentation for Bricks, and had never played with it before setting up RasPwn. My first login attempt was "admin" with a password of "admin" and it logged me in.

It wasn't until I saw the SQL in the footer that I knew this was supposed to be an SQL Injection challenge.Whoops. Okay, let's try this again with foo and a password of bar.
Okay, so that's what "access denied" looks like. Now let's throw some SQL injection into the username field. Here, I used a username of "foo ' OR 1=1 -- " (note the space after the -- comment, that's needed for MySQL and maybe other databases to acknowledge a comment).

And we've successfully used SQL Injection to hack the first Bricks challenge.

Happy hacking, friends!