Readme: how to build on raspbian

README.md

@@ -25,7 +25,7 @@ sudo apt-get install rfkill
 sudo rfkill unblock wifi
 ```
 
-### Reactive Jamming
+#### Reactive Jamming
 
 Our current implementation of our reactive jammer allows you to block an Access Point. More precisely, all beacons and probe responses will be jammed. Execute it using:
 
@@ -46,7 +46,7 @@ sudo iw wlan1 set monitor fcsfail
 
 This will instruct the driver to also pass corrupted frames to the userland (when in monitor mode). Be warned though, not all drivers properly support this flag. Some will always show corrupted frames. Others will never show corrupted frames. Our drivers and firmware handle this flag correctly!
 
-### Disabling Carrier Sense
+#### Disabling Carrier Sense
 
 Want to disable carrier sense in order to perform an experiment? Then execute this:
 
@@ -60,7 +60,7 @@ root@ubuntu:~$ echo 1 > ignore_virt_cs
 
 Writing 1 to `force_channel_idle` disables physical carrier sense (channel is busy). Writing 1 to `ignore_virt_cs` disables virtual carrier sense (RTS/CTS). Random backoff parameters can also be changed.
 
-### Constant Jamming
+#### Constant Jamming
 
 If you have the firmware capable of doing constant jamming, you can execute:
 
@@ -70,13 +70,13 @@ modwifi@ubuntu:~/modwifi/tools$ sudo ifconfig wlan0 up
 modwifi@ubuntu:~/modwifi/tools$ sudo ./constantjam wlan0 6
 ```
 
-This performs constant jamming on channel 6. Because channels overlap, nearby channels will also be jammed. Remember that the constant jamming implementation is not public, but can be requested personally.
+This performs constant jamming on channel 6. Because channels overlap, nearby channels will also be jammed. Remember that the constant jamming implementation is not public, but can be requested privately.
 
-### Unfair Channel Usage
+#### Unfair Channel Usage
 
 The specific scripts we used to easily configure a device to act unfairly are not public. The reason behind this is that it's hard to defend against these kind of attacks. However, some parameters can still be accessed as `debugfs` entries in `/sys/kernel/debug/ieee80211/phy*/ath9k_htc/registers/`.
 
-### Forcing Corrupt Packets
+#### Forcing Corrupt Packets
 
 You can force the wireless chip to calculate a wrong CRC (FCS) using:
 
@@ -87,7 +87,7 @@ root@ubuntu:~$ cd /sys/kernel/debug/ieee80211/phy*/ath9k_htc/registers/
 root@ubuntu:~$ echo 1 > diag_corrupt_fcs
 ```
 
-### TKIP Broadcast Attack
+#### TKIP Broadcast Attack
 
 This is an advanced attack and not for the fainthearted. It clones an existing Access Point on a different channel. This allows us to reliably manipulate encrypted traffic. We used this to break TKIP. See [our paper]() for details. An example on how we used it to verify that our awesome-sauce attacks work:
 
@@ -120,6 +120,38 @@ cd tools && make all
 
 If you want to compile the firmware as well, clone the [ath9k-htc repository](https://github.com/vanhoefm/modwifi-ath9k-htc), and follow the instructions there. If you want to modify the driver, you can use the downloaded code in `drivers.tar.xz`. I recommend putting that code in our own repository to keep track of changes. But even better would be to apply patches to the latest Linux kernel, and then either compiling the kernel or using [backports](https://backports.wiki.kernel.org/index.php/Main_Page) to create a release similar to mine. Still, the truly best option would be to contribute patches to this project (git pull request or just mail your patches)!
 
+## Raspberry Pi
+
+Our drivers and firmware can be run on a Raspberry Pi. We tested this using raspbian. In order to get it working first download and update some dependencies:
+
+```bash
+sudo apt-get install linux-image-3.12-1-rpi linux-headers-3.12-1 g++-4.7 iw
+sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.7 50
+```
+
+As you can see, we tested this on the 3.12-1-rpi kernel. You can use another kernel if you want, just be sure to download the kernel headers. To enable the 3.12-1-rpi kernel we just downloaded edit `/boot/config.txt` and append:
+
+	kernel=vmlinuz-3.12-1-rpi
+	initramfs initrd.img-3.12-1-rpi followkernel
+
+And to assure our raspberry pi will recognize the device when we plug it in, execute:
+
+	echo "ath9k_htc" | sudo tee -a /etc/modules
+
+Everything is now ready to install our drivers and firmware. Just **follow the instructions under section "Installation"**. Compilations of the drivers can take a few minutes. Finally we have to prevent raspbian from automatically trying to enable and manage WiFi (this interferes with our attacks). First edit `/etc/network/interfaces` and comment out the following two lines:
+
+	#allow-hotplug wlan0
+	#iface wlan0 inet manual
+
+Now edit `/etc/default/ifplugd` and change the `INTERFACES` and `HOTPLUG_INTERFACES` to:
+
+	INTERFACES="eth0"
+	HOTPLUG_INTERFACES="eth0"
+	ARGS="-q -f -u0 -d10 -w -I"
+	SUSPEND_ACTION="stop"
+
+This will prevent raspbian from automatically enabling and managing the wireless interface (so we can first put the device in monitor mode and only then enable it). You can now compile the tools and execute the attacks!
+
 ## Source Code
 
 The work is divided other several git repositories:
@@ -136,8 +168,8 @@ mkdir modwifi && cd modwifi
 bash <(curl -s https://raw.githubusercontent.com/vanhoefm/modwifi/master/init.sh)
 ```
 
-Apart from the `tools` repositories, all work and modifications are performed on the `research` branch. When a new Linux kernel (or firmware) is released, we can easily merge with it. As a result **our code is relatively easy to keep up-to-date**.
+To compile the Linux and ath9k-htc firmware, read the documentation of these projects. To backport the modified drivers using the backports project, also see the official documentation of that project. Finally, our tools can be compiled using a simple `make all`. Apart from the `tools` repositories, all work and modifications are performed on the `research` branch. When a new Linux kernel (or firmware) is released, we can easily merge with it. As a result **our code is relatively easy to keep up-to-date**.
 
-For those who also want to start hacking away at the driver and firmware, I recommend first going reviewing our patches. This allows you to focus on a subset of code for each patch. That way it's easier to learn step by step. Maybe you will even find bugs or can make improvements (let us know). Also, in the `ath9k-htc` repository, there is a directory called `docs`. While still terse to read, these documents should be an excellent guide while reading and understanding the code.
+For those who also want to start hacking away at the driver and firmware, I recommend first reviewing our patches. This allows you to study what our changes do, and inspect the firmware code at small chunks one at a time. That way it's easier to learn step by step. Maybe you will even find bugs or can make improvements (let us know). Also, in the `ath9k-htc` repository, there is a directory called `docs`. While still terse to read, these documents should be an excellent guide while reading and understanding the code.
 
 If you have any questions, don't hesitate to send us a mail.