Ubertooth - building and using

I'm working on a pen test for a client, which includes some bluetooth signal analysis. I decided to go a step above and actually do some ubertooth work--and immediately found myself in over my head. My first step was to buy a HackRF device, hoping I could use it for several purposes but soon discovered that the ubertooth tools aren't built for HackRF platform. After a good week beating on that, I gave up and had the Hak5 folks overnight me an Ubertooth.

I have followed the Ubertooth build guide to a T, but when I plugged in my ubertooth and tried to use the Spectrum Analyzer (as described in the Getting Started Guide), I encountered problems.

FeedGnuPlot

My first problem was:

jo@ubuntubox:~/ubertooth/ubertooth-2014-02-R2/host/ubertooth-tools$ ubertooth-specan -G -q | feedgnuplot --stream 0.5 --domain --3d

The program 'feedgnuplot' is currently not installed. You can install it by typing:

sudo apt-get install feedgnuplot

ubertooth-specan: command not found

Yah, oops - that's an easy fix:

jo@ubuntubox:~$ sudo apt-get install feedgnuplot

Reading package lists... Done

Building dependency tree       

Reading state information... Done

The following extra packages will be installed:

  aglfn gnuplot-qt

Suggested packages:

  gnuplot-doc

The following NEW packages will be installed:

  aglfn feedgnuplot gnuplot-qt

0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.

Need to get 1,014 kB of archives.

After this operation, 3,354 kB of additional disk space will be used.

Do you want to continue? [Y/n] y

BTBB CMake Error

The next error I got was at the bottom of the first set of command text above, also here:

ubertooth-specan: command not found

Hmm. CD'ing into the tools folder I realized duh - I hadn't build the tools yet. So the timeless march begins:

mkdir build

cd build

cmake ..

make

sudo make install

But wait, error! 

jo@ubuntubox:~/ubertooth/ubertooth-2014-02-R2/host/ubertooth-tools/build$ cmake ..-- The C compiler identification is GNU 4.8.2

-- Check for working C compiler: /usr/bin/cc

-- Check for working C compiler: /usr/bin/cc -- works

-- Detecting C compiler ABI info

-- Detecting C compiler ABI info - done

CMake Error at src/CMakeLists.txt:24 (find_package):

  By not providing "FindBTBB.cmake" in CMAKE_MODULE_PATH this project has

  asked CMake to find a package configuration file provided by "BTBB", but

  CMake did not find one.

  Could not find a package configuration file provided by "BTBB" with any of

  the following names:

    BTBBConfig.cmake

    btbb-config.cmake

  Add the installation prefix of "BTBB" to CMAKE_PREFIX_PATH or set

  "BTBB_DIR" to a directory containing one of the above files.  If "BTBB"

  provides a separate development package or SDK, be sure it has been

  installed.

CMake Warning (dev) in CMakeLists.txt:

  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 2.8)

  should be added at the top of the file.  The version specified may be lower

  if you wish to support older CMake versions for this project.  For more

  information run "cmake --help-policy CMP0000".

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring incomplete, errors occurred!

See also "/home/jo/ubertooth/ubertooth-2014-02-R2/host/ubertooth-tools/build/CMakeFiles/CMakeOutput.log".

What the...? 

This took some research, but I finally found the following comment from Govind-mukundan on the GreatScott Github issues discussion:

Thanks a lot for your information (I'm a bluetooth noob so have lots of reading up to do). I'll try to do some more tests tomorrow and add the capture. I also have some BLE devices and I'm curious to see them in action.
To add on the build requirements - in the setup guide it's mentioned that to install the wireshark plugin you should run:
$ cmake -DCMAKE_INSTALL_LIBDIR=/usr/lib/wireshark/libwireshark1/plugins ..
But this didn't work for me (I couldn't find the btbb inside the wireshark filters). I tried both libwireshark1 and libwireshark3 folders. However the instructions inside the README at libbtbb/wireshark/plugins/btbb/ says that you should run
$ cmake .
That did work for me, perhaps this should be updated in the guide too? It's all quite confusing :)

This actually works!

ubertooth-specan

The Getting Started says to run "ubertooth-specan" as explained in the readme. When I tried the read-me's command line, I kept getting errors:

jo@ubuntubox:~/ubertooth/ubertooth-2014-02-R2/host/ubertooth-tools$ ubertooth-specan -G -q | feedgnuplot --stream 0.5 --domain --3d

ubertooth-specan: command not found

After building and rebuilding I realized - there is no ubertooth-specan. The tool is ubertooth-specan-ui! So I modified the command and voila - another error!

jo@ubuntubox:~/ubertooth/ubertooth-2014-02-R2/host/ubertooth-tools$ ubertooth-specan-ui -G -q | feedgnuplot --stream 0.5 --domain --3d 

Traceback (most recent call last):

  File "/usr/local/bin/ubertooth-specan-ui", line 260, in <module>

    window = Window()

  File "/usr/local/bin/ubertooth-specan-ui", line 227, in __init__

    self._device = self._open_device()

  File "/usr/local/bin/ubertooth-specan-ui", line 250, in _open_device

    return Ubertooth(device)

  File "/usr/local/lib/python2.7/dist-packages/specan/Ubertooth.py", line 38, in __init__

    self._device.set_configuration()

  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 559, in set_configuration

    self._ctx.managed_set_configuration(self, configuration)

  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 91, in managed_set_configuration

    self.managed_open()

  File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 70, in managed_open

    self.handle = self.backend.open_device(self.dev)

  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 733, in open_device

    return _DeviceHandle(dev)

  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 618, in __init__

    _check(_lib.libusb_open(self.devid, byref(self.handle)))

  File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 571, in _check

    raise USBError(_str_error[ret], ret, _libusb_errno[ret])

usb.core.USBError: [Errno 13] Access denied (insufficient permissions)

Well, alright, this one is easy - USB permissions. The readme talks about a few fixes that I haven't implemented yet - I simply ran the same command as sudo and voila for real - introducing "Ubertooth Spectrum Analyzer"

I am happily seeing 2.4 gHz spectrum.

Flipping the “Production” bit on a Nexus 7

As a security researcher, I’m constantly battling the lack of access on my retail Nexus 7. I spent about 12 hours today messing with this, rooting the device and modifying boot images. Each time, my device would get stuck in a “soft-brick/bootloop’.

It was frustrating.

I followed every step-by-step I could find, continuously modding the setting in build.prop but to no avail. Funny enough – the trick I was using to root and recover my device is what ended up offering a solution!

Root Your Device, For Real

There are a number of roots out there, but none as good as “Nexus Root Toolkit’ by WugFresh. I was a little hesitant, but believe me – if you follow EVERY STEP (esp deleting and installing drivers) it works fantastic.

Run through the wizard. Follow the YouTube videos. A child can do this.

But Not Really

However, after you’ve rooted your device, you’re still in “Production” mode and you still can’t get root in shell. To accomplish that, you need to flip the production bit. But, as mentioned, I could never figure out how to flip the bit and then restore the boot image. Whenever I flashed the image back onto the device, it would go into a continuous reboot. At some point, however, I was poking around the Nexus Root Tooklit UI and saw the “Advanced Utilities” option to temporarily boot on an opened image.

I used it a couple times to see what was going on with my device – it would boot on the “modified boot image,” even when it wouldn’t boot on my slightly modified image. And when I adb shell’ed into the device, I had that wonderful root option!

 

It was only around hour 11.5 that I realized I could have flashed that image (their modified boot image) onto the boot partition, and my device would no longer be in production mode.

So it’s simple…

• Launch NRT
• Click “Advanced”
• Under “Boot Flash Image,” switch the option from “Boot (Temporary)” to “Flash (Permanent)”
  
• Select the modified boot image in the \data\modified boot image directory in the NRT install folder
• Let it flash

Your device is now no longer in production mode – you can mount it as root:

Further Research

I’m sure I could simply flip that bit somehow, but I just haven’t figured out how. After a full 12 hours (on top of an 8-hour work day), I decided to just move on. Anyone with better ideas – leave a comment!

WiFi Pineapple Radios

I've been slowly poking away trying to figure out definitively which antenna/radio corresponds (by default) to which WLAN. The support forums don't have much information, so I spent an hour or so today searching the web for info. I finally have it figured it, I believe.

Looking at front w/antennas on bottom:

Light Radio radio   wlan# Location
Blue AR9331 radio0  wlan0 Lower right by SD card
Red RTL8187 radio1  wlan1 Lower left near dip switches

Some of this info came from https://forums.hak5.org/index.php?/topic/33485-physically-what-is-the-wlan0wlan1-antenna/?hl=%2Bwhich+%2Bantenna

Typically WLAN0 is the access point clients connect to (the access point) and WLAN1 is the NIC used to connect to another wireless network. Why is this important?

1. If you're trying to lure users to connect to your pineapple, having a high-gain antenna connected to WLAN0 would be helpful. That's the blue antenna, AR9331 radio, lower right by the SD card.
2. If you're trying to connect/assess remote wireless networks (say with a Yagi directional antenna) connecting your antenna to WLAN1 would be helpful. That's the red antenna, lower left near the dip switches.

There was apparently at some point a problem with radios switching, but it seems that problem has been addressed (it was back in Sept 2013).

You can confirm this by connecting to your Wifi Pineapple over SSH:

root@Pineapple:/# cat /etc/config/wireless

config wifi-device 'radio0'

option type 'mac80211'

option channel '11'

option hwmode '11ng'

option macaddr '00:13:37:##:##:##'

option htmode 'HT20'

list ht_capab 'SHORT-GI-20'

list ht_capab 'SHORT-GI-40'

list ht_capab 'RX-STBC1'

list ht_capab 'DSSS_CCK-40'

config wifi-iface

option device 'radio0'

option network 'lan'

option mode 'ap'

option ssid 'Pineapple5_2342'

option encryption 'none'

config wifi-device 'radio1'

option type 'mac80211'

option hwmode '11g'

option macaddr '00:13:37:93:58:d2'

option channel '5'

config wifi-iface

option device 'radio1'

option mode 'sta'

option network 'wan'

option ssid 'HOME-8858'

option key 'Sn1ckers'

option encryption 'psk2+ccmp'

Note on MAC addresses: 

• 00:11:37 is associated with "Orient Power Home Network Ltd (this is radio0, the AR9331)
• 00:13:37 is also associated with "Orient Power Home Network Ltd" (this is radio1, the RTL8187)

WarPi–The Build

In my other blog post, I documented the stop/start challenge I had building a War Pi. Now that all the equipment is ready, it’s time to actually start building. I’ve picked up a number of tips and tricks along the way, and I’ll be documenting them here.
The War Pi is a Raspberry Pi project running Kismet, with GPS enabled. The project is a SANS Gold Paper project by Scott Christie; you can read the paper here. For the WarPi to work “mobile”, you need the following:

• Raspberry Pi
• SD Card (4 GB or larger)
• Alfa wireless network adapter
• USB GPS
• USB battery pack
• Misc USB cables

Here’s my setup:

Operating System

The first step was choosing from the several options for operating systems. The folks at RaspberryPi.org are awesome about building, updating and releasing operating systems (you can find them here). I chose Raspbian because it is the most common OS, and because it was the base OS for the WarPi build. There’s potentially a reason to go with one of the OS’s (for instances, Arch Linux), to have a smaller kernel and such. For the purpose of this project, sticking with the norm is probably the best solution.

Configuring the OS

I’ve written a longer blog on how to image, update, upgrade, and reimage the Raspberry Pi operating system, you can read it here. These are the steps I took to get to my current base image.

Customizing the Hostname

My base image includes SSH server running at startup, so I can get logged in whenever it’s live on a network. One thing I like to do is customize my hostname—in this case, it’ll be “WarPi”. Some people recommend a stealthier name, but given that the WarPi will only be used for client engagements, I want to be completely transparent.
There’s a nice article on the steps to accomplish this. You can read it here.

Expanding Filesystem

Scott Christie’s article calls for expanding the file system as a first step. I don’t do this, because once the system is built I want to image it back off. If I expand the file system, my image will be quite large (my card is 6 GB). So I’ll hold off until all the apps are installed and working.
Next: build the WarPi.

Installing Applications

Scott Christie’s WarPi build follows these steps:

1. Install and configure GPSD (the GPS Daemon)
2. Install and configure Kismet
3. Auto-start Kismet

GPSD – The Good, the Bad, the Ugly

In my initial efforts to build a WarPi, I was using an older Microsoft Streets and Trips GPS device. My early proof of concept was just using it with minicom to review serial communications – that worked fine and I blogged a bit about it. When I combined GPSD and my old GPS unit, however, I ran into trouble and learned a lot about debugging GPS units. Unfortunately, it appears GPSD fried my old SiRF GPS unit – even though I’ve got it back to NMEA mode, the unit cannot get a GPS fix anymore. So I’m understandably wary of GPSD. In some testing I did the other day, I discovered that Kismet works fine with my new GPS unit in NMEA mode over serial, so my plan now is to skip the GPSD installation and let Kismet speak serial/NMEA to the GPS.
Therefore, my build steps will be:

1. Test the GPS
2. Install and configure Kismet for serial NMEA GPS
3. Test Kismet with the GPS
4. Auto-start Kismet

Step 1: Testing the GPS

Install Minicom

Minicom is a great little serial tool, but it doesn’t come preinstalled in the OS, so we’ll be installing that prior to using the GPS. Simple:
sudo apt-get install minicom
And voila – you have minicom installed! To make sure it works, enter the following:
sudo minicom –s
And the minicom app will start at the settings screen:

Just choose “Exit from Minicom” by arrowing down—we have to get the GPS working before we can use minicom.

Connect the GPS

When you connect the GPS over USB, the sudden change in power can cause your Pi to restart. The best strategy is to shut down your Pi, connect the GPS, and then power up.
Once the system boots, you’ll need to discover your GPS’s “location” in the system. Type the dmesg command and scroll through the output looking for “USB-Serial” or such. Eventually you’ll see a series of entries for the GPS, ending in “pl2303 converter now attached to ttyUSB0” or something similar, as highlighted below:

Now you’re ready to use minicom to view NMEA strings coming from the GPS. Type:
sudo minicom –s
to enter the settings screen. Let’s get going!

1. First select “Serial Port Setup” by mousing down to it and pressing the Enter key.
2. Next, press the “A” key, then backspace and edit the entry to read /dev/ttyUSB0 (or wherever your GPS unit ended up). Then press “Enter” to set your changes.
   
   NOTE: the location for your GPS is case sensitive!
   
   
3. Now we need to modify the serial communications settings. Press “E” to open the Comm Parameters menu:
   
4. Press “B” until the Current comm speed is 4800:
   
5. Make sure the “Current” reads 4800 8N1 as above. If it doesn’t, press “Q” to set the second half of the string.
6. Once the settings are correct, press “Enter” to exit each screen (two times).
7. Now arrow down to “Save setup as dfl” and press “Enter”
8. Next, arrow down to “Exit” and press “Enter”. You will drop directly into minicom and see NMEA strings pass by…
   
   The big white box is an attempt to anonymize my location.
9. To close out of minicom, press “Ctrl+A” then press “Q” and choose to leave without reset.

Installing Kismet

It’s actually not an “install” per-say, but a download and build. Christie’s instructions are still accurate – the link is correct as of September 2014, and the instruction steps are all accurate. I’ll summarize:

1. First perform the wget command to download the source.
2. Next, install the dependencies as documented
3. Then extract the source
4. Then prepare the code to compile and install
5. Finally, make and install Kismet

The make part… That takes a long time. Be patient—go for a walk with the dog, spend time with family, etc.

UPDATE: 03/2016
NOTE that there is a bug in Kismet, so it places access points all over the antarctic. Not kidding. See this Kismet forum article for details on how to fix it (you're going to have to modify code).

If you look for the K7JTO repository on Github, you can download the updated Kismet files, or just hand-fix them yourself.

Configuring WLAN0 Out

By default, Raspbian wants to hot-plug and use a wireless device as much as it does an ethernet device. Kismet however wants full access to the WLAN device, so it will squawk at you:

I poked around quite a bit, but ultimately fixed this by editing /etc/default/ifplugd and changing the line INTERFACES=”auto” to “INTERFACES=”eth0”

This instructs ifplugd to only look at eth0 to autoconfig, and not to the WLAN. Inconvenient if I actually want it to auto-configure a WLAN connection, but I actually don’t want it to. Kismet needs full control of wlan0.

Smoke Test

This is a good time to make sure Kismet is working. It’s simple – just type
sudo kismet
If it’s working, you’ll get a bunch of prompts as recorded in the whitepaper. Eventually you’ll see the Kismet server logs, which will look like this:

Pressing the Tab key will highlight the “Close Console Window” and take you to the Kismet interface, which will look like this:

(GPS coordinates blanked out)
If you’ve gotten this far, you are golden – configure Kismet to auto-start and to log output and you have a WarPi. Congrats!
From this point on, you can follow the WarPi directions in the article and everything should go just fine. NOTE that you might want to use dd again to make a base WarPi image so you don’t have to go through all of this again if your card dies or something.

Basic Raspberry Pi Hacks

I've put a fair amount of time into setting up Raspberry Pi images lately. Between work and fun, my son and I have four serious Pi projects on our immediate backlog:

1. AirPi Tracker: using a cheap USB SDR dongle, track local flight paths. Why? I'm not interested in flight paths actually, just interested in Pi and using it with SDR. This project comes from the fantastic book "Raspberry Pi Hacks" (loaded with great ideas)
2. PiGame: another project from Raspberry Pi Hacks, this sets up your Pi as an emulated game console for a series of classic games. Having three teen sons, I am thinking this one is going to be a hit.
3. War Pi: this is the main project for the time being, creating a "war walking" 802.11 analysis device. With an Alpha wireless adapter and a GlobalSat BU-353S4 GPS, I can walk around client buildings and assess the location and signal strength of surrounding 802.11 access points (which pose the threat of employees connecting to external wireless points).
4. Pi Fence: this project is in its infancy, but the idea is to build a Pi distro for home network security, including a firewall and an authenticated proxy (authenticated by user, not by device).

Fun projects - they all require a good basic Pi image. This article captures my lessons learned in creating that base image.

Base Pi Image

The great Pi community has created a number of Pi images (found here). They maintain and update these images often--this is the place to go to get that beginning image. I went with Raspbian for my current projects, simply because it's tried and true. For Pi Fence, I may go with a lighter OS, but for now this works.

Before you can really get started, you need to download your image. Not that difficult....

Next, you'll need get the image onto your SD card. An image isn't really a set of files, it's actually a bit-by-bit copy of a disk. You can't just drag and drop it onto an SD card and have a functioning Pi. You need to "image" it to the card.

Windows absolutely stinks at this. My Win8 machine is at the point where it can't even see a card with a Pi image on it - it's very frustrating. Luckily I do a lot of work in Linux (my personal project laptop runs Mint, and my workstation runs Ubuntu), so I have been able to work very efficiently with the SD card process. If you don't have a Linux machine, you could try running Linux in a Virtual Box virtual machine. If you have a USB SD card reader, you could (rather ironically) use a Pi to do all of this. That's what this blog post is all about - getting the image onto your card, upgrading it, customizing it, and then storing your personal image.

Step 1: Clear Your Card

You can skip this step if your card is brand-new and unformatted. Otherwise, you'll want to get rid of any file partitions and the likes which are present on your SD card. To do this, you'll want GParted (it can be done with the "fdisk" command, but it's cumbersome).

Boot GParted (it will require you to enter your password) and make sure the selected device is your SD card. It'll look roughly like this:

If the device in the upper right corner is /dev/sda, do NOT proceed. That's your computer's hard disk, and what you are about to do will completely nuke your hard drive. Select /dev/mmcblk0 or whatever is showing that's roughly the size of your SD card.

How do you know what your SD card is? Just after you insert your SD card, in a terminal window type the command dmesg. The last few lines of output will look like this:

[64576.492079] mmc0: card 0007 removed

[64580.605642] mmc0: new high speed SDHC card at address 0007

[64580.612048] mmcblk0: mmc0:0007 SD8GB 7.42 GiB 

[64580.616186]  mmcblk0: p1 p2

[64580.873309] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

[64581.005227] EXT4-fs (mmcblk0p2): recovery complete

[64581.005237] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)

The third line of output is the path to the SD card, proceeded by /dev/. So in my case, /dev/mmcblk0.

If your card has already had a Pi build on it, it'll look like the one above. Select each partition (in my case, /dev/mmcblk0p1 and /dev/mmcblk0p2) and from the Partition menu, select "Delete". When you've selected all the partitions to delete, you have to click the "Apply all operations" button (the last button on the left). Otherwise, none of your changes actually occur.

NOTE: deleting a partition is permanent...

Step 2: Image Your Card

The next step is to get the bits from the Pi OS image onto your card. You'll use the dd command for this. From the command line, type:

sudo dd if="base_pi_image.img" of="/dev/mmcblk0"

Notes:

• The "if" option is the source file. Enter the path to the image you have downloaded from the Raspberry OS downloads page.
• The "of" option is the destination--in this case, enter whatever your SD card is

Now just wait. It looks like nothing is happening, but slowly, bit by bit, that 2.x GB image is being created on your SD card. Be patient.

Once the image has been copied, you are almost ready to boot your Pi--but not quite. One of the next steps will be to upgrade the base image to include the latest kernel updates and such (stuff that's not rolled back into the base image, but that you'll want). It's a long process to upgrade your Pi OS and I think it's worth doing before you create your personal Pi image. The problem is, the base Pi image is small and leaves little room to download and install updates, so you'll need to temporarily grow your Pi image just a bit.

Step 3: Grow Your Pi Image

You may have noticed that, when you used the dd command to image your SD card, there was a large chunk of unallocated space. Don't worry - you'll get to use that space eventually. For now, we just want to grab a little bit of it, so you can upgrade your Pi OS and then create your own, updated, base image. 

You can skip this step if you don't care about having an updated personal image lying around (with 4 projects going, I wanted to do this only once).

To grow your image,

1. Open GParted again
2. Click on the file system partition (usually /dev/mmcblk0p2 for me)
3. From the "Partition" menu, select "Resize/Move"
4. Increase the size by about 500 MB (just add 500 or so to the "New Size"

Easy as Pi. Sorry, bad joke... But now that you have some extra space, you will be able to boot your Pi and update/upgrade the image.

Step 4: Update and Upgrade

The nice thing about the Linux community is that there's just so much going on out there, and people take a lot of time to actually help each other. With your Pi image set, go ahead and boot up your Pi and get connected to the network (from a personal perspective, I prefer to use ethernet but wireless is fine). Open a terminal window and type the following command:

sudo apt-get update

This will cause your Pi to search the corners of the Internet looking for updates to the software packages installed in the base OS. 

Next, you're going to start a rather long process - the process of updating the kernel itself. In the terminal window, type

sudo apt-get upgrade -y

Now would be a good time to walk the dog, play with the kids, read a book, or chat with a loved one. This can take quite some time.

When that's done, the next command is

sudo apt-get clean

This command cleans off any temporary files left over from the update and upgrade processes.

Step 5: Make Any Other Changes

There are a number of additional changes you could make at this point:

• Networking: you have already set up networking so you could get to the Internet, but if you want to make any changes that will be part of your base image, do so. For me, I disable the wireless network and I specify a static IP address so when my Pi boots, it's a known host on my internal LAN.
• Firewall: you may want to enable a firewall at this point, or install anti-virus (Clam is a great AV tool for Linux)
• Add or remove applications: if there are applications you know you won't need (perhaps Scratch or another programming application) you can remove those at this time. If there are other apps you need or want, install them.
• Disable services: there may be services running which you don't need, and disabling them means you free up system resources. Go for it.

At this point, your Pi is as up to date as it gets, and it's time to create your personal base image. 

Step 6: Create Your Personal Base Image

In this step, you'll create a base image which you can use going forward. I'm a bit of a geek, so I actually perform an added step, which is reducing the size of the base image - it's not needed, I just like to do it. I learned it from a very helpful blogpost by xalixo on the Raspberry Pi forum.

1. Back on your main computer, insert your SD card and use the dmesg command again to make sure you know how to reference it.
2. If you want to shrink your image again, do the following

• Open Gparted again
• See how much space is used on the /dev/mmcblk0p2 partition and how much is free

1. Next, you are going to use the dd command, but in this instance you'll reverse directions and copy from the SD card to a base image.
2. In the terminal window type sudo dd if="/dev/mmcblk0" of="personal_pi_image.img"
3. OPTIONAL If you want to shrink your image, you can take a chance, modify the dd command, and copy fewer bytes from your card. The dd command looks like this: sudo dd if="/dev/mmcblk0" of="personal_pi_image.img" bs=1M count=2700

• Note: the value for count should be the desired size in MB of your final image. That's what you found in step 2. Add some free space just in case.

Now you have a base image that's updated, configured how you like it, and ready to use. If you have other SD cards (I have one for each project I'm working on), copy that image onto them using the dd command from step 2 above.

Storing Your Cards

I hate having clutter on my desk. I have a lot of clutter, but I do hate it. I poked around for a "lifehack" for storing SD cards and didn't find anything I liked. Then I stumbled across an Altoids Smalls tin and realized it's perfect! I took some foam and lined the tin (with a piece in the middle to separate stacks), and I used snippets of an Avery shipping label to identify the card:

There are some who will point out there's a risk of static discharge because I'm using a metal container. True. Images are easily recreated and cards are cheap so I'm not all that concerned - that attitude will likely change when my first card is zapped. Meanwhile I *am* looking for a non-metal alternative, but needed something short-term to help.

Conclusion

That's about it - you now have one or more base images which you can use to tweak however you need. Enjoy!