A lot of times, speaking to people about home wifi and security, i hear something like this: “Why should I encrypt my home wireless network, I don’t mind sharing my internet connection, I’m ok with it as long as I don’t need my whole bandwidth”. And I can’t tell that’s wrong at all.
But what these people don’t think, which is not obvious for those who doesn’t know how it works, is the whole question of security: when you connect to a wifi network, you usually exchange data over the air with an access point, which is the only device supposed to receive and process it.
But when you send data through your wireless card, you’re just broadcasting it over the air, and every device close enough to your computer which is capable of receiving wireless data could potentially receive it.
As you could imagine, when you establish a connection through an access point, you’re sending data but you’re also receiving data from it. That means that every wireless card has the capability of receiving data of a wireless connection. Obvious.
But then, how comes that I can surf the Internet without seeing the traffic of all the other people of the network? Of course, the wireless protocol grants that only the data meant to be sent to my wireless card will be processed, ignoring all the packets sent to other’s. That’s clear and reasonable.
But what you should ask now is: who is granting that the wireless protocol is working that way?
Nice question. It’s the operating system. It speaks directly to the hardware, which is meant to receive bits correctly and not much more. The card then turns the bytes received to the operating system, which interprets them and decides what to do. Usually operating systems are built to avoid people messing up with the hardware itself, which is usually a good idea, so the protocols are deeply integrated with them. Here is when you come and say: “The hardware is mine and I want to do what I want with it”. That’s why you should use Linux. Linux is free, and so are you when you use it over your computer hardware. Linux is programmed to work as you expect it would, but it always lets you do what you want if you know how (and have the right permissions).
That means yes, you can actually receive data packets the other people are broadcasting, as long as you’re close enough with the source of the wireless signal and you have a wireless card capable of doing that (most of the cards will work, but some cards which are hardware-blocking this possibility exist).
Now that you understood that you can receive other’s data, let’s go back to the encryption problem. Of course, since you’re broadcasting data over the air, you can always be received by someone else’s wireless card. But if you’re connected to a unencrypted network, you are also sending data in clear. That means you’re broadcasting to potentially anyone everything you’re sending to the network, and they can read it in clear. The funny thing is that, when you’re only receiving data, no one can notice it since you’re not transmitting anything yourself. You don’t even need to be connected to the same network, you just have to listen on the right “channel”.
Fortunately, you’re not beaten yet in this privacy war. If you’re connected to an unencrypted wireless network but you’re using an encrypted service, such as https, you’re still transmitting data in clear, but that data is https data, which has already been encrypted by the https protocol, which you and the endpoint are using (and want to use). So when the malicious listener receives the wireless data, he can see it, but he’ll found it’s encrypted data.
You can now understand that all the unencrypted traffic sent through an unencrypted connection can be intercepted and read in clear by a potential attacker.
Some examples of unencrypted services that transmits unencrypted data are ftp, pop3, smtp, http. If you use one of these protocol over an unencrypted connection you can be easily read by someone other’s computer nearby.
I’ve created a little bash script which looks for an unencrypted wireless network and starts listening for packets sent through it. Then you can use your preferred packet sniffer software to display and analyze the packets received from your wireless card.
Here’s the code:
echo "Setting $dev to managed mode"
sudo rfkill unblock wifi
sudo ifconfig $dev down; sudo iwconfig $dev mode managed
sudo ifconfig $dev up
echo "Searching for unsecured network channels"
for word in `sudo iwlist $dev scan`;
if [ "$word" == "Cell" ]; then
buf=`echo "$word" | grep "Channel:" | cut -d':' -f 2`
#echo "Buf: $buf"
if [ "$buf" != "" ]; then
echo "I've got a channel! The channel $buf"
essid=`echo "$word" | grep "ESSID:" | cut -d':' -f 2`
if [ "$essid" != "" ]; then
echo "The essid is $essid"
if [ "$unencryptedchannel" != "" ]; then
enc=`echo "$word" | grep "key:" | cut -d':' -f 2`
#echo "enc: $enc"
if [ "$enc" == "off" ]; then
echo "The channel $channel has no encryption!"
if [ "$unencryptedchannel" == "" ]; then
echo "No unencrypted network. Quitting"
echo "Your channel is $unencryptedchannel, on wifi network $ssid. Proceeding with sniffing"
echo "Putting $dev in monitor mode"
sudo ifconfig $dev down; sudo iwconfig $dev mode monitor
sudo ifconfig $dev up
while [ "`iwconfig $dev | grep Monitor`" == "" ]; do
echo "Monitor mode not set, retrying"
sudo ifconfig $dev down; sudo iwconfig $dev mode monitor
sudo ifconfig $dev up
echo "Setting $dev to channel $unencryptedchannel"
sudo iwconfig $dev channel $unencryptedchannel
echo "Interface $dev ready for sniffing."
This code is not intended to be used for malicious purposes, this is just a proof-of-concept to understand which are the real risks of transmitting through an unencrypted network. Use this code to try and intercept your own traffic while sending emails with smtp, or retrieving them with pop3, or connecting to your ftp host. You’ll better understand what I explained in this post.
It’s even possible to intercept images you are seeing on your browser through http, yes, like Facebook photos and similar. That’s because Facebook by default avoids using https after the login due to its bandwidth cost.
I should conclude encouraging you to encrypt your wireless connection if you want to protect your privacy, or at least to be aware of the risks you can take by using it with unencrypted services.
Then going to the system “Add printer” dialog, select Network Printer while connected to the same network of the printer, and you should see the printer showing up. Just select it and then the system will do the rest. It should download the drivers and set up the printer, which should be working fine.
Now the package manager should be complaining about the missing dependencies, but you can resolve the error with a
apt-get -f install
which should just remove the previously installed epson package.
Even if it’s now removed, and the package manager is now working again, the printer should still work fine, and you can still print over the network, so everything is ok
In these months, I attended course of Computability and Complexity, ending with some concepts of cryptography.
It’s been really interesting, so I wanted to experiment something about it.
I created a little web page using Angular.JS and just a little PHP, to implement some kind of “secure chat”, which uses a given passphrase to encrypt every message directly on the client, and then stores the messages in an online database. This chat can host multiple users with the same passphrase, which will be able to see each other messages, doing all the encryption/decription on the client side.
This means that all the traffic going through the internet has already been encrypted, so everything is stored in the database must be decrypted with the key to be read. In theory, even accessing to the database wouldn’t give any information about the messages sent through the chat.
I really don’t know exactly how commercial messaging systems do work, but I always suspected that if the provider of the service wanted to, it would be able to read the messages going through its servers, because the ‘secure’ connection (if any) is established between the server and the clients, and not between the very two endpoints of the communication.
In the system I implemented, instead, the server makes only the ‘buffering’ of the data, it never gets in touch with the encryption keys, so that it can’t read the messages it saves to the database.
I don’t really believe commercial systems work exactly that way, but the doubt was enough to get me developing this little project
The AES encryption is a simmetric key encryption, which means that every user share a secret key and then use it to encrypt the data sent through an unsecure channel.
My experiments with genetic programming are going on. I’m trying to focus on something more useful, so I’ve made a little page which uses gp to search the shortest path to connect a number of points, randomly generated, or specified by the user.
It is possible to modify the parameters of the genetic algorithm, editing the JSON object in the textarea.
I started reading something about genetic programming, and i must say it’s really interesting. I decided to try to implement a genetic algorithm just to go deeper and better understand how it works, so i developed a little gp evolving enviroment.
Everything in that page is really messed up, and it doesn’t completely work for now: anyway, if you want to give it a try, it’s here.
The Shotter is one of my first project I used the Raspberry for, and the idea is very simple: using a Raspberry PI and a webcam to take a photo every n seconds, and eventually mounting a video from the taken frames.
I made this with one of my PIs, and i configured it to automatically start taking the photos when I plug a usb drive, and to save the photos directly to the key. If you want to stop it, you just unplug the usb key or switch off the power. The photos are saved with an alphabetical friendly format, that is a increasing number padded with zeros: ‘00000001.jpg’, ‘00000002.jpg’, … This makes easy to make the final video, for example with mencoder:
The photos have a small size, about 70-80KB, so that a 1Gb usb key can handle more than one day of photos taken every 10 seconds.
I also added a led to the PI, which it’s blinking when the PI is waiting for the timeout to expire, just to say that everything is working fine (it’s been very useful while debugging).
Here are some videos I made with my shotter:
I think it’s great for taking photos during a party (I did it but I won’t publish the video here )
Here’s a stupid python code to do the job (launched by a usbmount script, see this other post where I explain something more about usbmount or just search the Internet)
import RPi.GPIO as GPIO
f = open('/home/pi/shotter_service/index', 'r')
text = f.read()
index = int(text)
index = 0
f = open('/home/pi/shotter_service/index', 'w')
def padding(what, length):
what = str(what)
for i in range(length - len(what)):
what = "0" + what
dev = 0
secs = 10
version = "0.1"
index = getIndex()
state = False
if len(sys.argv) > 1:
dev = int(sys.argv)
if len(sys.argv) > 2:
secs = int(sys.argv)
print "Current Index is " + str(index)
os.system("fswebcam -r 640x480 -S 15 --subtitle "Daniele Nicassio's Projects" --banner-colour 80000000 --line-colour 00FFFFFF --title "Raspberry PI Shotter "+version+"" --info "http://www.nicassio.it/daniele/blog" --no-timestamp --jpeg 95 -d /dev/video"+str(dev) + " --save /media/usb0/""+padding(index, 10)+".jpg"")
index += 1
for i in range(secs):
state = not state
This video shows a cheap RC car hacked to be controlled by the Raspberry PI. It is completely autonomous, it uses a webcam to turn and point the light. The computation is made with the OpenCV libraries.
Today i’m going to write about my new project, a Raspberry PI powered radio car. For now it can provide only basic functionalities, but it can be easily improved by upgrading the software, on which i didn’t focus very much so far.
In this post i will explain how I configured the PI to accomplish the task.
What I used in this project?
a Raspberry PI
a standard 16×2 character LCD display (HDD44780 compatible)
a wheel from an old mouse
The idea is to make a car radio capable of playing music from a usb pen plugged in the PI. My radio can only shuffle the songs found, but that’s just about software, it can be improved in many ways, that is where a lot of customization may take place.
Getting the display working with the PI
The first thing to do is to understand how to drive the LCD display from the PI. This is made by connecting the display to the PI’s GPIO, and then sending the commands from the programming language, usually using a library for the HDD44780 standard.
After I was able to write to the display, I wrote a little python script to print something to the display from the command line, which could be useful to write something to the lcd from a shell script later:
To play music through a USB device, the PI must be configured properly. In my case, I had some operation to do before everything worked, and my speakers are still showing some problems when playing from the PI (I hear a little noise, but i didn’t search enough to tell it can’t be resolved).
Anyway, if you want to use your PI as a car radio, you probably want the USB speakers to be the default audio device for it. You can do this by editing the /etc/modprobe.d/alsabase.conf adding the following line, or modifying the relative line if it already exists with another value (which in raspbian should be the case):
options snd-usb-audio index=0
I had also another problem which seemed to be quite common, and I also had to add another line at the end of that file, to avoid an “expected delay” error which I discovered running dmesg:
options snd-usb-audio nrpacks=3
I choose the higher value which didn’t give me errors in the log. After modifying the file i restarted alsa with
sudo service alsa-utils restart
This wasn’t enough to play music through the speakers, I also had to specify the right device when i played the music with mplayer. I had to discover the name of the device running the following command:
which gives a list of the recognized devices, from which i selected the right one, and finally got mplayer to play some mp3s:
mplayer -ao alsa:device=front my_music_file.mp3
Usb automount and autoplay
Now that the display is working correctly and we can play music through the speakers, let’s figure out how to handle the mounting/umounting actions:
The next step is to configure the PI to automatically mount any usb drive plugged in. This can be done by using the usbmount software avaiable in the raspbian repository:
sudo apt-get install usbmount
Now, I want to autoplay music when the usb is plugged in, so I add a custom script to the default usbmount script folder /etc/usbmount/mount.d :
python /home/pi/lcd/char/print.py "Madre foca:
sudo -u pi mplayer -slave -input file=/home/pi/fifofile -ao alsa:device=front -shuffle $UM_MOUNTPOINT/* $UM_MOUNTPOINT/*/* $UM_MOUNTPOINT/*/*/*
The first command uses the python script I created before to print something to the LCD when music is starting, while the third line starts the playback.
As you can guess, the $UM_MOUNTPOINT variable contains the path to the mounted drive.
The -slave mplayer option is a very useful way to let you send commands to mplayer even if it’s backgrounded. It tells mplayer to read input commands from a file, but if we provide a fifo file instead of a normal one, mplayer will read from it only when we will write something. This allows mplayer to be controlled by writing to a file, from python, shell or whatever you prefer. To create a fifo file you should use
If you want to know more on the -slave option of mplayer, see here.
I had to add the sudo -u pi part because it seemed that the user of usbmount wasn’t allowed to read from the fifo, I don’t know exactly why.
Finally, I also created a script for the umount event, which simply killed mplayer, and placed it in the /etc/usbmount/umount.d directory:
python /home/pi/lcd/char/print.py "Music stopped.
I'm a super PI."
Connecting the inputs: the button and the wheel
I’m not very good with electronics, so i won’t explain this part very deeply, also because that’s pretty basic.
The scheme to read the state of a button should be something like this:
The mouse wheel should have three connectors, and it behave like two button together, with the central pin in common. The only thing to know about it is that the two “buttons” are switched on and off while you turn the wheel, but one of them is triggered a little before the other, giving you information about the direction.
I decided to use a wheel (or two button) and an additional button to provide basic input for a “menu” structured OS for the radio, which is the minimal input for a fair usability.
Reacting to the inputs
The last thing to do is to react to the input of the user, writing the real “operating system” for our radio. I wrote this in python, and the interface is really minimal, providing the wheel to control the volume and the button to skip to the next song.
As usual the code is really bad written, and it should be used only to understand how it works. I encourage you to write a real interface, you could really do anything with that.
The script (bad written of course) is this:
import RPi.GPIO as GPIO
from Adafruit_CharLCD import Adafruit_CharLCD
lcd = Adafruit_CharLCD()
lcd.message("Hello!nI'm the SuperPI.")
os.system("amixer set PCM 5+");
os.system("amixer set PCM 5-");
lcd.message("Skipping tonnext song")
f = open('/home/pi/fifofile','w')
f.write('seek 100 1n')
last_a = False
last_b = False
last_c = True
paired = True
a = GPIO.input(4)
b = GPIO.input(18)
c = GPIO.input(2)
#print "4: "+str(a)+ " 18: " + str(b)
if c == False and c != last_c:
if a != b and paired:
if a != last_a:
paired = False
paired = True
last_a = a
last_b = b
last_c = c
Note that it uses the previous created fifo to send to mplayer the command to skip to the next song.
I’m sure that anyone can assemble this project better than I did. And to prove it i’ll show a picture:
Here’s a little video (in italian) in which I show the (few) functionalities of the radio:
I’m thinking, when I have some spare time, to extend its functions by attaching a webcam and trying to do something more complex, given the wide range of possibilities the PI can offer.
I downloaded the FM transmitter C program from the link above and figured out a way to drive my usb audio card mic input to the program, to be able to broadcast that in FM: wonderful.
The result was a short range Raspberry PI powered FM transmitter, and i was able to tune my radio to the right frequency (in this case 100.00 MHz) and to listen for the music i was playing from my device.
Since there has been some interest about how I made this, I post here the little scripts I wrote for this project, even if they are not written very well, and may not be easy to understand and adapt to your needs. Here they are: