I dug out this old step by step I used to use for setting up Raspberry Pi Zeros as OTG devices. I had lost this for a while, so rather than filing it away somewhere that I may lose track of it again, I figured I’d share it here. This may be a bit dated as I think I wrote this a couple years back. This was pieced together from other guides, but I don’t recall where from. I can’t take full credit for all of this.

1) Flash Raspbian to SD card

2) Mount SD card

3) vim /boot/config.txt add dtoverlay=dwc2 on a new line at the end.

4) touch /boot/ssh

5) vim /boot/cmdline.txt (Be careful with this file, it is very picky with its formatting! Each parameter is seperated by a single space not newlines) Insert ‘modules-load=dwc2,g_ether’after rootwait

6) Unmount SD card and power on Pi

7) sudo dmesg
[ 1943.306812] usb 1-12: new high-speed USB device number 14 using xhci_hcd
[ 1943.494324] cdc_ether 1-12:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-12, CDC Ethernet Device, 2e:2f:d7:3d:10:88
[ 1943.526965] cdc_ether 1-12:1.0 enp0s20f0u12: renamed from usb0

8) sudo avahi-autoipd -D enp0s20f0u12

9) avahi-resolve -n raspberrypi.local

10) ip a (Note the inet6 address of the device)

11) ssh -6 -o BindAddress=fe80::ccf3:3fff:3ff3:ccc1%enp0s20f0u12 pi@raspberrypi.local

12) sudo vim /etc/network/interfaces

# Start of file (you don't need to include this line)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
    address 10.2.2.3 # IP you want to assign to the RPi
    gateway 10.2.2.2 # IP you want to assign to the ethernet port
    network 10.2.2.0
    netmask 255.255.255.0
    broadcast 10.2.2.255

13) sudo vim /etc/resolv.conf

nameserver 10.2.2.2
nameserver 8.8.8.8
nameserver 8.8.4.4

14) sudo reboot

Part III: Seting up forwarding to the pi (from Arch)
1) First make sure your pi is still the same name as before, and also note the name of the device you intend to share internet from (for me its my ethernet adapter enp3s0) by running:

ifconfig

and checking to see if the device name shows up
2) Lets make sure our device is up by running:

sudo ip link set up dev enp0s20f0u12

(NOTE: make sure to change the enp020f0u12 to your device name)
3) Lets add the IPv4 address for the device by running

sudo ip addr add 10.2.2.2 dev enp0s20f0u12

(NOTE: again the device name…)
4) Lets enable packet forwarding to the device by running

sudo sysctl net.ipv4.ip_forward=1

5) Enable the NAT for the device by running the following 3 commands, making sure to use your device id, and changing enp3s0 to be the ethernet device id that you want to share with your pi!

sudo iptables -t nat -A POSTROUTING -o enp3s0 -j MASQUERADE
sudo iptables -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i enp0s20f0u12 -o enp3s0 -j ACCEPT

6) Lets assign the ip addresses to the Pi zero by running the following 3 commands, making sure to use your device id, and changing enp3s0 to be the ethernet device id that you want to share with your pi!

sudo iptables -I INPUT -p udp --dport 67 -i enp0s20f0u12 -j ACCEPT
sudo iptables -I INPUT -p udp --dport 53 -s 10.2.2.0/24 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 53 -s 10.2.2.0/24 -j ACCEPT

Part IV: Setup a network bridge to the pi so we can effectively share our internet with the pi zero
1) Lets use netctl to create a network bridge by copying the example network bridge file included in the netctl package by running

sudo cp /etc/netctl/examples/bridge /etc/netctl/bridge
cd /etc/netctl/

2) Lets modify the example network bridge to share internet between our devices, making sure to replace enp3s0 with the device id you want to share internet from and enp0s20f0u12 with the device id of your pi by running

sudo vim bridge

and changing the file to:

# Start of file (you don't need to include this line)

Description="Example Bridge connection"
Interface=br0
Connection=bridge
BindsToInterfaces=(enp3s0 enp0s20f0u12 )
IP=dhcp
## Ignore (R)STP and immediately activate the bridge
#SkipForwardingDelay=yes

# End of file (you don't need to include this line)

Save the changes to the file…

3) Now test the bridge connection using netctl by running:

sudo netctl start bridge

4) Now when we run

ifconfig

we should see our our bridge connection br0 in the output like so:

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.104  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::3490:aff:f37f:fdf3  prefixlen 64  scopeid 0x20<link>
        ether 01:20:3f:27:1f:ff  txqueuelen 1000  (Ethernet)
        RX packets 34442  bytes 47881180 (45.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 29738  bytes 4640292 (4.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

If you don’t see this, something went wrong, so try hunting it down, or if you really can’t find it on your own, as a question and be sure to post exactly what you did. Please don’t waste my time without first really looking into it on your own first (at least spend a few hours debugging on your own…).

5) Let’s try ssh’ing into that ipv4 address (inet):

ssh pi@192.168.0.104

Note: replace the 192.168.0.104 with whatever your inet address is.

6) If you can, then your pi now also has whatever internet connection your ethernet device has. Congrats! Now to ensure we can ssh into raspberrypi.local instead of having to specify the ip, run:

sudo avahi-resolve -n raspberrypi.local

Note: this may not always be necessary

7) Now we can ssh like normal:

ssh pi@raspberrypi.local

8) Now if you intend on leaving your pizero plugged into the same usb port and want to be able to ssh into it without having to do any setup when you reconnect or reboot, run:

sudo netctl enable bridge

Otherwise, if you intend on reconnecting the same pi device with the same operating system periodically, just run the

sudo netctl start bridge

Some friends and I have been toying with setting up our own little mesh VPN dark net of sorts. Below are the first baby steps I’ve been able to take in setting up ZeroTier on OPNSense. A few things this configuration enables are as follows.

• A self hosted ZeroTier controller through ZTNCUI
• Bridging the ZeroTier subnet to locally provisioned devices without the need to have the ZeroTier client installed.
• NATing of other local subnets which are not natively in the ZeroTier network to be able to mostly transparently route to hosts in the ZeroTier network.
• Afformentioned NATing allows port forwarding to these local hosts not natively in the ZeroTier network through the network bridge.
• Easy to remember IP allocation bounds.

01 Set up a VM to host ZTNCUI.
I set up a VM with Debian10.

01 A Install OS.
The OS install is outside the scope of this guide, but below are some items to ensure are configured.

Give the VM at least 32 GB storage for scratch space and future growth.

Set up an administrative user other than root.

If you have a local domain set the domain name. The domain I use in my internal LAN is just “lan”.

Set strong passwords.

01 B If you used Debian then set up sudo access for the admin user.
root@Deb10:~# sed -i "s/$(grep sudo /etc/group)/$(grep sudo /etc/group)/g" /etc/group

01 C Again if you used Debian edit apt sources to exclude the install cd/dvd.
root@Deb10:~# grep -i "s/deb cdrom/#deb cdrom/g" /etc/apt/sources.list

01 D Update OS, install some requisites and quality of life packages then reboot.
root@Deb10:~# apt update && apt full-upgrade -y
root@Deb10:~# apt install vim curl wget dnsutils
root@Deb10:~# /sbin/reboot

01 E Install ZeroTier and ZTNCUI.
https://www.zerotier.com/download
https://key-networks.com/ztncui
john@Deb10:~# sudo curl -s 'https://raw.githubusercontent.com/zerotier/ZeroTierOne/master/doc/contact%40zerotier.com.gpg' | gpg --import && if z=$(curl -s 'https://install.zerotier.com/' | gpg); then echo "$z" | sudo bash; fi
john@Deb10:~# sudo apt-get install ./ztncui_0.5.8_amd64.deb
john@Deb10:~# sudo sh -c "echo 'HTTPS_PORT=3443' > /opt/key-networks/ztncui/.env"
john@Deb10:~# sudo systemctl restart ztncui

01 F Log onto ZTNCUI and change the default credentials.
In a web browser navigate to https://127.0.0.1:3443 on the ZTNCUI host.

Log on with the following credentials.
UserName: “admin”
PassWord: “password”

Change the password to something more secure.

Log out then log back in.

01 G Create the ZeroTier Network and define the subnet.
In the top panel select “Add network”.

Define the network name. In this example we will use the name “DorkNet” to refer to our example ZeroTier network.

Select “Create Network”

Make note of the Network ID.

Select “easy setup”

Define your subnet and IP assignment pools. In this example we will use the following values. Some further explanation to follow in next steps.

“Network address in CIDR notation” = “10.222.0.0/16”
“Start of IP assignment pool” = “10.222.201.1”
“End of IP assignment pool” = “10.222.255.254”

02 Log onto your OPNSense router as an administrative user.

02 A Install and activate the ZeroTier plugin then add the previously created DorkNet network.

Navigate: System > Firmware > Plugins

Scroll to the bottom and click the “+” to install the ZeroTier Plugin.

Navigate: VPN > ZeroTier > Settings

Select the “Enabled” check box.

Navigate: Networks

Select “+”

Fill out the “Network ID” and “Local Description”.

Select “Save”

Select “i” button for the newly added network.

Make note of the first space delimited string. This is the Leaf ID of the bridge router.

Select the check box under the column “Enabled” to enable the network.

02 B Approve the OPNSense VPN client and assign it a static IP.
Open the ZTNCUI WebUI.

Navigate: Networks > DorkNet / members

Identify the Leaf ID of the newly enabled OPNSense ZeroTier client / bridge router.

Select “Authorized” and “Active Bridge”.

Wait some moments and select the “Refresh” button. An IP address should be assigned to this leaf.

Select on the IP address which has been assigned to this leaf.

Identify a new static IP address for this bridge. Since I am using a large(ish) /16 subnet for the DorkNet I chose to break the bridge IPs into /24 subnets so that each bridge could then have roughly a /24 subnet of natively routable internal clients(excluding NAT clients) and be very easy to remember where the IP allocation bounds lay. Below are some example IP allocations for this scheme.

1st Bridge Router IP: 10.222.1.1
1st Bridge Client IPs: 10.222.1.{2-254}

2nd Bridge Router IP: 10.222.2.1
2nd Bridge Client IPs: 10.222.2.{2-254}

17th Bridge Router IP: 10.222.17.1
17th Bridge Client IPs: 10.222.17.{2-254}

Define the IP Address for this Bridge Router then click the “+” to assign it.

Select the trash can icon next to the old IP allocation to delete it.

Select “Back”.

Open the OPNSense WebUI.

Navigate: VPN > ZeroTier > Overview > Networks

Select the down arrow next to the DorkNet Network ID to expand it.

Validate the IP allocation is accurate. If not then you may want to try cycling the ZeroTier plugin.

02 C Set up the ZeroTier interfaces and bridge interface
Navigate: Interfaces > Assignments

At the bottom of the screen next to “New interface:” select the drop down box and select the interface starting with “zt”.

Select the “+” button then click “save”.

Under the column “Interface” click on the name of the newly assigned interface for the “zt” “NIC”.
Select “Enable Interface”.
Select “Prevent interface removal”.
Add “ZT_DN_GW” to the “Description” field.
Select “Save”.

Navigate: Interfaces > Assignments

At the bottom of the screen next to “New interface:” select the drop down box and select the interface you wish to use as the internal LAN interface to route to the clients and servers hosted locally.

Select the “+” button then click “save”.

Under the column “Interface” click on the name of the newly assigned interface for the LAN “NIC”.
Select “Enable Interface”.
Select “Prevent interface removal”.
Add “ZT_DN_LAN” to the “Description” field.
Select “Save”.

Navigate: Interfaces > Other Types > Bridge

Select “+ Add”.

Under the “Member interfaces” drop down box select the “ZT_DN_GW” and “ZT_DN_LAN” interfaces.
Add “ZT_DN_RB” to the “Description” field.
Select “Save”.

Navigate Interfaces > Assignments

At the bottom of the screen next to “New interface:” select the drop down box and select the bridge interface just created. It should be something like “bridge1”.

Select the “+” button then click “save”.

Under the column “Interface” click on the name of the newly assigned interface for the Bridge “NIC”.
Select “Enable Interface”.
Select “Prevent interface removal”.
Add “ZT_DN_BR” to the “Description” field.
Select “Static IPv4” as the “IPv4 Configuration Type”.
Add the Bridge Router IP previously assigned in the ZTNCUI under “IPv4 address”.
Select “Save”.

02 D Modify relevant tunables
Navigate: Settings > Tunables

Modify “net.link.bridge.pfil_member” to be “0”
Modify “net.link.bridge.pfil_bridge” to be “1”

02 E Define relevant firewall pass rule
Navigate: Firewall > Rules > ZT_DN_BR

Click “+ Add”

“Action” = “Pass”
“Quick” = “Unselected”
“Interface” = “ZT_DN_BR”
“Direction” = “in”
“TCP/IP Version” = “IPv4”
“Protocol” = “Any”
“Source” = “ZT_DN_BR net”
“Destination” = “ZT_DN_BR net”
Select “Save”.

02 F Optional set up NAT for other local subnets into the DorkNet.
Navigate: Firewall > NAT > Outbound

Select “Hybrid outbound NAT rule generation”
Select “Save”

Select “+ Add”

“Interface” = “ZT_DN_BR”
“TCP/IP Version” = “IPv4”
“Protocol” = “any”
“Source address” = Whatever LAN subnet you may have for your other internal traffic
“Source port” = “any”
“Destination address” = “ZT_DN_BR net”
“Destination port” = “any”
“Translation / target” = “Interface address”
Select “Save”

Thats it, now go and help some of your friends get in on the fun.

I’m still waiting on the first print of the 3D printed base I drafted to come in to test fit before I work on the internal chassis model more, but in the mean time I put together a much safer version of the PlugPi with proper heat shrink tubing rather than hot glue and duct tape. A reddit comment pointed out that power creates heat and things like hot glue and duct tape get soft when heat is introduced. Please don’t use hot glue, but instead spring for the heat shrink tubing. I don’t want you to burn your house down.

WARNING: This project deals with hacking on mains AC power. Please proceed carefully.

I've wanted an inconspicuous wall wart style raspberry pi case / enclosure for the longest time, but there aren't many options out there. I've seen the PiPlug developed by the dude that runs n-o-d-e.net, but it wasn't quite what I was looking for. After some research; though, I think I've hit on the just the right ingredients to easily build out very sleek and inconspicuous cases.

These are links to the components I landed on.

Case:
https://www.polycase.com/pm2314
USB Chargers:
https://www.amazon.com/gp/product/B076C6PW2V
16 AWG Stranded Wire:
https://www.amazon.com/gp/product/B0746HRVZP
Assorted Heat Shrink:
https://www.amazon.com/gp/product/B0771K1Z7Q
30mm Heat Shrink Tubing:
https://www.amazon.com/gp/product/B00MJVQP5C
Reversible Right Angle Micro USB Cables:
https://www.amazon.com/gp/product/B07CBTVR8G

Here is one of the USB power supplies ripped apart next to an intact one. These things seem to be the best way to get cheap clean power in a small form factor. There are some other appealing options like the RAC05-05SK that are a bit cleaner and probably safer than cannibalizing a USB charger, but at 3x the price I decided I'd go this route.

As you can see the Raspberry Pi and this power adapter board sit nicely in this little project enclosure.

Soldering to the power adapter is quite easy. The pads for the mains AC were large, and soldering the cannibalized USB cable to the USB pads was easy enough. I secured all of these wires with hot glue as well.

Soldering to the poles inside the Polycase enclosure was tricky. I ruined the first one because I was hanging the soldering iron on the pole for too long and it melted the case causing it to become very unstable.

I then ripped off the little ground tab and hot glued the power adapter straight into the bottom of the enclosure. I would have used the 30mm heat shrink tubing to entirely wrap the power adapter entirely prior to securing it to the enclosure if I had actually thought about the size it for two second before impulsively hitting buy on Amazon and getting tubing that was 2x too large. I'll have it for the next iterations of this project though.

Here I just used some duct tape to keep the power adapter seperated from the Raspberry Pi. The 30mm heat shrink tubing will replace this mess in the future.

And here you can see that the USB cable can simply plug into the Pi's power port. The Pi has to sit in the enclosure at a slight angle, but it does sit in there will, and even with just a bit of wiggle room.

Finally here it is all buttoned up. Kind of boring, perfect.

Prior to enclosing everything it would probably be wise to configure the Pi for remote access as all the ports are occluded with this enclosure. This is my standard headless config that I use for a base on nearly all my headless Pi based projects.

-1: Flash Raspbian to SD card and sync

sudo dd if=~/Downloads/Raspbian_Image.img of=/dev/sdb bs=1M progress=status && sudo sync && sudo sync

-2: Remove and re-plug SD card if new partitions are not visible.
-3: Mount SD card.

sudo mkdir /mnt/piboot
sudo mkdir /mnt/piroot
sudo mount /dev/sdb1 /mnt/piboot
sudo mount /dev/sdb2 /mnt/piroot

-4: Enable SSH on boot.

sudo touch /mnt/piboot/ssh

-5: Set up interfaces file to enable WiFi roaming.

vim /mnt/piroot/etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)
Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

allow-hotplug eth0
auto eth0
iface eth0 inet dhcp

allow hotplug wlan0
iface wlan0 inet manual
	wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf

iface default inet dhcp
iface FBISurveilanceVan inet dhcp
iface BackupFBISurveilanceVan inet dhcp
iface CoffeeHouseWiFi inet dhcp

-6: Set up WiFi APs with priorities.

vim /mnt/piroot/etc/wpa_supplicant/wpa_supplicant.conf

update_config=1
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
country=US
ap_scan=1

network={
	ssid="FBISurveilanceVan"
	psk="SecretPassword01"
	id_str="FBISurveilanceVan"
	scan_ssid=0
	priority=11
}

network={
	ssid="BackupFBISurveilanceVan"
	psk="SecretPassword01"
	id_str="BackupFBISurveilanceVan"
	scan_ssid=0
	priority=10
}

network={
	ssid="CoffeeHouseWiFi"
	psk="NotSoSecretPassword"
	id_str="CoffeeHouseWiFi"
	scan_ssid=0
	priority=9
}

-7: Set crontab to invoke wpa_cli scan every 5 minutes

vim /mnt/piroot/etc/crontab

# m h  dom mon dow   command
*/5 * * * *	/usr/sbin/wpa_cli -i wlan0 scan

-8: Unmount SD card.

sudo umount /mnt/piboot
sudo umount /mnt/piroot

-9: Plug SD card into Pi, power it on, SSH to it, and continue configuration as desired.

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.

pi# sudo apt update && sudo apt full-upgrade
pi# sudo apt install vim dnsmasq hostapd parprouted avahi-daemon

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.

pi# sudo rm /etc/systemd/network/99-default.link
pi# sudo vim /etc/systemd/network/99-default.link

CONFIG:

[Link]
NamePolicy=kernel database onboard slot path mac
MACAddressPolicy=persistent

Reboot the Pi.

pi# sudo reboot

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

pi# sudo vim /etc/network/interfaces

CONFIG:

auto lo
iface lo inet loopback

auto enx0
iface enx0 inet dhcp

auto wlx0
allow-hotplug wlx0
iface wlx0 inet dhcp
    wireless-essid Your-Drones-essid-Here
    post-up parprouted wlx1 wlx0
    post-up ip addr add $(/sbin/ip addr show wlx0 | perl -wne 'm|^\s+inet (.*)/| && print $1')/32 dev wlx1
    post-down pkill -9 parprouted
    post-down sudo ip addr flush dev wlx0
    post-down sudo ip addr flush dev wlx1

auto wlx1
allow-hotplug wlx1
iface wlx1 inet manual

Set some iptables rules to set up NAT and allow multicast and broadcast forwarding. If someone who knows iptables a bit better can double check this I’d be grateful.

pi# sudo vim /etc/iptables.ipv4.nat

CONFIG:

*filter
:INPUT ACCEPT [5:388]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [3:392]
-A FORWARD -m pkttype --pkt-type multicast -j ACCEPT
-A FORWARD -m pkttype --pkt-type broadcast -j ACCEPT
-A FORWARD -i wlx1 -o wlx0 -j ACCEPT
-A FORWARD -i wlx0 -o wlx1 -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [1:160]
:POSTROUTING ACCEPT [1:160]
-A POSTROUTING -o wlx1 -j MASQUERADE
COMMIT

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.

pi# sudo vim /etc/dnsmasq.conf

CONFIG:

interface=wlx1
listen-address=192.168.0.2
bind-interfaces
server=192.168.0.1
domain-needed
bogus-priv
dhcp-range=192.168.0.100,192.168.0.150,4h

Edit rc.local so we start dnsmasq on boot and load in our iptables rules. Add the following lines just above the line “exit 0”

pi# sudo vim /etc/rc.local

CONFIG:

iptables-restore < /etc/iptables.ipv4.nat
service dnsmasq start

Now we will enable ipv4 forwarding. Go into the sysctl.conf file, find and uncomment or add the following line to the file.

pi# sudo vim /etc/sysctl.conf

CONFIG:

net.ipv4.ip_forward=1

Next we will set up hostapd to manage the local repeated WiFi access point. I’m boring, but you can change the values below to make your access point something more fun.

pi# sudo vim /etc/hostapd/hostapd.conf

CONFIG:

interface=wlx1
driver=nl80211
hw_mode=g
channel=6
ieee80211n=1
wmm_enabled=1
ht_capab=[HT40][SHORT-GI-20][DSSS_CCK-40]
macaddr_acl=0
ignore_broadcast_ssid=0
auth_algs=1
wpa=2
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
ssid=PiBridge
wpa_passphrase=PassPhrase

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.

pi# sudo systemctl disable dhcpcd.service
pi# sudo systemctl enable hostapd.service
pi# sudo systemctl enable dnsmasq.service
pi# sudo reboot

Finally I want to shout out to the resources I used to piece this together.
Surfer Tim on the RasPi forums
This pimylifeup.com guide
The Debian Wiki
This Adafruit Tutorial

Questions, Comments, Suggestions? Let me know. I’m open to all of it.

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.

https://github.com/snuffeluffegus/ErectMyCAC

Some notes to be aware of.

1. You need to have the ‘expect’ package installed. I think everything else is default.
2. It’s not fire and forget yet. Keep an eye on it, you will be prompted for user input for grub and iptables.
3. It does not handle errors. I’m too lazy to implement that in a non vital script.
4. If your latency is bananas then you probably need to up the sleep time inside the expects. Sometimes CaC is stupid slow.
5. Edit the line around ~118 if you want to add or remove packages.
6. The firewall is set up with ports for ssh, http, https, and NoMachine.
7. If you want to update the NoMachine.deb file go ahead and download the latest .deb package and just rename it correctly.
8. Bro is the coolest IDS ever so we installed that slice of awesome.
9. Your new passwords will be output to ‘CAC_{$CACIP}.txt’

That’s it. If you like it then enjoy, and if you’ve got ideas then please let me know.

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.

Copyright © 2014, 2015 Lawrence Wu sagnessagiel@gmail.com
Copyright © 2015 snuffeluffegus <>
Copyright © 2015 Kevin Keijzer <>
Copyright © 2016 Leah Rowe info@minifree.org

Also I’d like to tip my hat to the LibreBoot folks, they’re doing great work!

Requirements:

• An x86, x86_64, or arm7l (for changing the libreboot.rom image mac address)
• Raspberry Pi and peripherals
• Relevant SOIC clip
• 6 female – female jumpers
• Internet connection
• Screw drivers

Follow the ThinkPad X200: Initial installation guide to disassemble the laptop, and access the BIOS rom chip.

Note: x86# refers to commands to be run on the x86 computer, and pi# refers to commands to be run on the pi. A good practice is to make a work directory to keep your libreboot stuff inside.

x86# mkdir ~/work

If you’re running Raspian, you can do sudo raspi-config, enable SPI under Advanced and then spidev will be enabled. Simple, eh?

Download Libreboot from their releases page. For your safety, verify the GPG signature as well.

x86# gpg --keyserver prefered.keyserver.org --recv-keys 0x656F212E

x86# for signature in $(ls *.sig); do gpg --verify $signature; done

Install dependencies:

pi# sudo apt-get update && sudo apt-get install libftdi1 libftdi-dev libusb-dev libpci-dev subversion libusb-1.0-0-dev pciutils, zlib, libusb, build-essential

Download and build flashrom.

pi# svn co svn://flashrom.org/flashrom/trunk ~/flashrom

pi# cd ~/flashrom

pi# make

pi# sudo make install

On your x86 box change the libreboot.rom mac address

x86# cd ~/work/libreboot_bin/

Change the mac address on the libreboot images to match yours.

x86# ./ich9macchange XX:XX:XX:XX:XX:XX

Move the libreboot.rom image over to your pi

x86# scp ~/work/libreboot_bin/<path_to_your_bin> pi@your.pi.address:~/flashrom/libreboot.rom

Shutdown your pi, write down your rom chip model, and wire up the clip

pi# sudo shutdown now -hP

Chip model name

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

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

pi# cd ~/flashrom

pi# ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 --chip <your_chip_name> -r romread1.rom

pi# ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 --chip <your_chip_name> -r romread2.rom

pi# ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 --chip <your_chip_name> -r romread3.rom

pi# sha512sum romread*.rom

If they are identical sha512 hashes then you can generally assume that it’s safe to flash your rom.

pi# ./flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 --chip <your_chip_name> -w libreboot.rom

It may fail a couple times, but keep at it and when you get the message Verifying flash... Verified or Warning: Chip content is identical to the requested image then you’re done.

Shut down your pi, put your box back together, and install a libre OS for great good!

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 1st presentation titled “OPSEC – Because Jail is for wuftpd” is from the Hack in the Box conference and is presented by The Grugq. This talk is about OPSEC (Operational Security). It is my personal favorite of this list, and if someone can find the time to watch only a single video from this list then this is the one I’d point them to. I’d be remiss to not link to The Grugq’s blog; it is the third link below.
https://www.youtu.be/9XaYdCdwiWU
https://exclusionzone.org/files/Videos/Crypto_Party/HITB2012-OPSEC-Because_Jail_is_for_wuftpd.mp4
https://grugq.github.io/

The 2nd presentation titled “TOR – Hidden Services and Deanonymisation” is from 31C3 (31st Chaos Communications Conference) presented by Dr. Gareth Owen. It is a bit more technical, but, in my opinion, is pretty vital to people who might want to use T.O.R. for sensitive things.
https://youtu.be/oZdeRmlj8Gw
https://exclusionzone.org/files/Videos/Crypto_Party/31C3-Tor-Hidden_Services_and_Deanonymisation.mp4

The 3rd video titled “Encryption and Security Agencies” is from the Computerphile youtube channel, and the speaker is Richard Mortier.
https://youtu.be/sWeVOXpTOhk
https://exclusionzone.org/files/Videos/Crypto_Party/Computerphile-Encryption_and_Seucrity_Agencies.mp4

The 4th video titled “Public Key Cryptography” is from the Computerphile youtube channel, and is presented by Robert Miles. It is a brief overview of how services like gpg work.
https://youtu.be/GSIDS_lvRv4
https://exclusionzone.org/files/Videos/Crypto_Party/Computerphile-Public_Key_Cryptography.mp4

The 5th video titled “Security of Data on Disk” is from the Computerphile youtube channel, and is presented by Professor Derek McAuley. This video explains a bit of how data is stored on solid state and magnetic disk mediums and can (or cannot) be securely deleted.
https://youtu.be/4SSSMi4X_mA
https://exclusionzone.org/files/Videos/Crypto_Party/Computerphile-Security_of_Data_on_Disk.mp4

The 6th presentation titled “Search and Seizure Explained – They Took My Laptop” was presented at Defcon 17 by Tyler Pitchford. It deals with some legal issues surrounding computers, encryption, privacy, and the like.
https://youtu.be/ibQGWXfWc7c
https://exclusionzone.org/files/Videos/Crypto_Party/DEFCON17-Search_and_Seizure_Explained-They_Took_My_Laptop.mp4

The 7th presentation titled “Anonymous and Ourselves” was presented at Defcon 19 by Aaron Barr, Joshua Corman, and Jericoh. This is a panel discussion, among other things, what the anonymous organization is, and in what ways that kind of model might or might not be useful.
https://youtu.be/8NI21Zoqlu4
https://exclusionzone.org/files/Videos/Crypto_Party/DEFCON19-Anonymous_and_Ourselves.mp4

The 8th presentation titled “Crypto and the Cops – The Law of Key Disclosure and Forced Decryption” was presented at Defcon 20 by Marcia Hofmann. The title offers plenty of description here, and Marcia does an excellent job describing what kind of crap the “authorities” might try to pull on you.
https://youtu.be/Jt7D4AIfqlQ
https://exclusionzone.org/files/Videos/Crypto_Party/DEFCON20-Crypto_and_the_Cops-The_Law_of_Key_Disclosure_and_Forced_Decryption.mp4

The 9th presentation titled “Forensic Fails – Shift + Delete Wont Help you Here” was presented at Defcon 21 by Eric Robi and Michael Perklin. In this presentation they talk about how you would want to and not want to destroy data on a disk as well as some things you should account for and know if you are considering storage or data destruction.
https://youtu.be/NG9Cg_vBKOg
https://exclusionzone.org/files/Videos/Crypto_Party/DEFCON21-Forensic_Fails-Shift_+_Delete_Wont_Help_you_Here.mkv

The 10th presentation titled “Dont Fuck It Up” was presented at Defcon 22 by Zoz. This talk is pretty dank tbh fam. Zoz talks about how to not fuck it up where (it == OpSec) | (it == InfoSec).
https://youtu.be/J1q4Ir2J8P8
https://exclusionzone.org/files/Videos/Crypto_Party/DEFCON22-Dont_Fuck_It_Up.mkv

The 11th presentation titled “Dropping Docs on Darknets – How People Got Caught” was presented at Defcon 22 by Adrian Crenshaw a.k.a. Iron Geek. In this video Adrian talks about T.O.R., Bitcoin, and how some people got themselves caught while giving some pointers on how to not do that.
https://youtu.be/eQ2OZKitRwc
https://exclusionzone.org/files/Videos/Crypto_Party/DEFCON22-Dropping_Docs_on_Darknets-How_People_Got_Caught.mp4

The 12th presentation titled “Crypto and State of the Law” was presented at Defcon 24 by Nate Cardozo. It talks about the history of encryption legislation and how the U.S.A. government attempts to legislate on and control encryption technologies as of July(ish) 2016.
https://youtu.be/YN_qVqgRlx4
https://exclusionzone.org/files/Videos/Crypto_Party/DEFCON24-Crypto_and_State_of_the_Law.mp4

The 13th presentation titled “How to Overthrow a Government” was presented at Defcon 24 by Chris Rock. It might give you some tips on how you might implement some tools and tactics to work against a tyranical state.
https://youtu.be/m1lhGqNCZlA
https://exclusionzone.org/files/Videos/Crypto_Party/DEFCON24-How_to_Overthrow_a_Government.webm

The 14th presentation titled “Destroying Evidence Before its Evidence” was presented at ShmooCon 2012 by Hanni Fakhoury. It deals with legalities around destruction of data. Hint, the scorched earth data retention policy is the best data retention policy.  😉
https://youtu.be/lqBVAcxpwio
https://exclusionzone.org/files/Videos/Crypto_Party/Shmoocon2012-Destroying_Evidence_Before_its_Evidence.mp4

The final videos I’ll wrap this post up with is this youtube playlist. They’re pretty great.
https://www.youtube.com/playlist?list=PLC7A095EDCE81B09B

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.

Happy Hacking!

Welcome to the site
Something about a season
This is now haiku

This is the site’s rebirth. HTML was light and fast, but a pain to update. There might or might not be an influx of content generation and curation following.