#raspberry pi gpio traffic light

[raspberrypigk]

Controlling Raspberry Pi GPIO Pins from Bash Scripts: Traffic Lights ☞ https://medium.com/coinmonks/controlling-raspberry-pi-gpio-pins-from-bash-scripts-traffic-lights-7ea0057c6a90 #pi #raspberrypi

[markjsaterfiel66]

Fun with NASA's Open Data Portal

One of the most powerful tools available to tinkerers and prototypers is the Application Program Interface. An API is the structure by which two computer programs talk to each other – think of it as a traffic cop for information traveling between two applications.

In a workshop at SXSW EDU last year, I encountered NASA’s open data platform. My mind was blown by the fact that a good percentage of NASA’s projects reveal their data and code through an open API, and it’s all fairly well supported and reasonably easy to get started with.

To begin, I navigated to the cover page for the Open Data Portal. From there I selected the data catalog; I’m pretty into the asteroid thing these days, so I used the Near Earth Object database.

From here I clicked on the API button:

This brought me to the opening page for the NeoWs.

If you go to the Getting Started documents, it will ask you to sign up for a development key. You don’t necessarily need one; you can browse the API catalog and pull out example URLs and use them at will without a key. I chose object 2018GG – there’s a nifty visual of this house-sized space rock here.

After pulling out the URL for the data on 2018GG, I put together a simple Python script that I ran in Trinket.

import urllib.request contents = urllib.request.urlopen("https://api.nasa.gov/neo/rest/v1/neo/3542519?api_key=DEMO_KEY").read() print(contents)

When I ran this, I actually got a return in the console matching all the data available for 2018GG:

I called in the urllib library and used the request method. Next, I created a variable and stored the return coming from the URL connected to 2018GG. Finally, I printed out what’s stored in the variable. That’s a lot of data for this simple call. We can simplify things by loading everything into a Json object using the code below.

import urllib.request import json contents = urllib.request.urlopen("https://api.nasa.gov/neo/rest/v1/neo/3802394?api_key=DEMO_KEY").read() varab = json.loads(contents) print(varab)

This gave me a value and an object notation connected to the value, all comma-separated.

I wanted to find out what the key titles associated with each element of data are, so I wrote a short script that separates out and prints just the keys.

import urllib.request import json contents = urllib.request.urlopen("https://api.nasa.gov/neo/rest/v1/neo/3802394?api_key=DEMO_KEY").read() varab = json.loads(contents) print(varab.keys())

The printout now shows a whole list of the keys I can work with.

Continuing to narrow things down, I picked out a single element from my list of keys and added some text to it and built a small, very specific printout. I separated out the element line I really wanted by a set of asterisks for readability.

import urllib.request import json contents = urllib.request.urlopen("https://api.nasa.gov/neo/rest/v1/neo/3802394?api_key=DEMO_KEY").read() varab = json.loads(contents) print(varab.keys()) print('*' * 79) print(('object 3802394 is: ')+varab['close_approach_data'][0]['miss_distance']['miles']+(" miles away!!!")) print('*' * 79)

The fun part of all this is that not only can this be implemented in the Trinket environment like I’ve used here, but it’s a great project for Python on the Raspberry Pi. Further steps might include a warning light or buzzer if an object got too close for comfort. This example would employ the GPIO pins on the Raspberry Pi and give a great overview of connected data through an API and physical computing.

I hope you have fun with this and happy hacking.

comments | comment feed

[terabitweb]

Original Post from Talos Security Author:

New 4CAN tool helps identify vulnerabilities in on-board car computers

By Alex DeTrano, Jason Royes, and Matthew Valites.

Executive summary

Modern automobiles contain hundreds of sensors and mechanics that communicate via computers to understand their surrounding environment. Those components provide real-time information to drivers, connect the vehicle to a global network, and in some cases use that telemetry to automatically drive the vehicle. Like any computer, those in vehicles are susceptible to threats, such as vulnerabilities in software, abuse via physical-access, or even allowing remote control of the vehicle, as recently demonstrated by Wired and a DARPA-funded team of researchers.

Allied Market Research estimates the global connected car market to exceed $225 billion by 2025. To help secure this emerging technology, Cisco has dedicated resources for automobile security. The Customer Experience Assessment & Penetration Team (CX APT) represents the integration of experts from the NDS, Neohapsis, and Portcullis acquisitions. This team provides a variety of security assessment and attack simulation services to customers around the globe (more info here). CX APT specializes in identifying vulnerabilities in connected vehicle components.

During a recent engagement, the Connected Vehicle Security practice identified a gap in tooling for automobile security assessments. With ease-of-use, modern car computing requirements, and affordability as motivating factors, the Connected Vehicle Security practice has built and is open-sourcing a hardware tool called “4CAN” with accompanying software, for the benefit of all automobile security researchers. We hope 4CAN will give researchers and car manufacturers the ability to test their on-board computers for potential vulnerabilities, making the vehicles safer and more secure for drivers before they even leave the lot.

What does a car’s network look like?

Before jumping into the 4CAN hardware module itself, let’s start with some automobile basics. For a modern vehicle to operate effectively, its network of hundreds of sensors and computers must communicate with each other. While vehicles and components employ Wi-Fi, Bluetooth, and cellular communication protocols, the backbone of a vehicle’s network is a Controller Area Network (CAN), also referred to as the “CAN bus.”

Access to the CAN bus from a physical perspective is typically via an ODB2 connector, often located on the driver-side lower dash, though it can sometimes also be accessed by removing side mirrors or external lights. Compromising the CAN bus can lead to total control of the vehicle, making it a prime target for pen testers and malicious attackers. Often, attacks against peripheral components such as Wi-Fi or LTE are ultimately an attempt to gain access to the CAN bus.

CAN Bus background

A typical vehicle’s CAN bus is shown below. In a secure configuration, the critical components such as airbags and brakes communicate on separate CAN buses from the non-critical components, such as the radio or interior lights. Pen testers and attackers with access to the CAN bus test for this separation of services looking for insecurely configured vehicles.

The CAN bus is a two-wire multi-master serial bus. Each device connected to the CAN bus is called a “node” or Electronic Control Unit (ECU). When a device sends out a message, or CAN frame, that message is broadcast to the CAN bus and received by every node. When two nodes broadcast a CAN frame at the same time, the arbitration ID, a type of unique node identifier on every CAN frame, determines message priority. The CAN frame with the lower arbitration ID takes priority over the higher arbitration ID.

Electrically, the CAN bus uses differential signaling as a means to reduce noise and interference. There is CAN-HI and a CAN-LO signal, and the two signals are inverse from each other. The bus also has a 120 ohm characteristic bus impedance. When performing a CAN-in-the-middle, the bus must be terminated with a 120 ohm resistor. The image shown below is from Wikipedia, which has an excellent overview of the CAN bus if you’re interested in more detailed information.

Single CAN bus with multiple nodes

The simplest implementation of an automobile’s network uses a single CAN bus. An example with 3 nodes is shown below. All connected nodes will see every CAN message published to the CAN bus. There is no ability to separate critical from non-critical nodes.

Multiple CAN buses with a gateway

A typical vehicle setup has multiple CAN buses combined with a gateway to arbitrate access between the CAN buses. This gateway acts as a firewall and can check CAN IDs to determine if the message should be allowed to traverse CAN buses. In this way, critical ECUs can be isolated from non-critical ECUs.

The vehicles that we have been testing have 4 CAN buses inside, all of which are connected to the gateway. The architecture looks something like this:

The security of each ECU on the bus is partly dependent on the gateway’s ability to segregate traffic. Testing the gateway involves sending and looking for messages allowed to traverse disparate CAN buses. On four-bus systems, this test requires pen testers can access the four buses simultaneously.

Existing solutions

Several devices exist that allow testing of the CAN bus. Most of the devices use the MCP2515 CAN controller, which provides a serial peripheral interface (SPI) to connect with a microcontroller, and a MCP2551 CAN Transceiver or NXP TJA1050 CAN Transceiver, which generates and receives the electrical signals on the physical CAN bus. This table describes some of the CAN hacking solutions currently available on the market.

Each device has its pros and cons, but none completely met our needs of being easy to use, allowing access four buses, and doing so at an affordable price point. Here’s how the currently available devices align with our needs.

In the absence of a compatible device we set out to solve this problem, doing so with the following technical motivators:

Raspberry Pi compatible

Easily enable or disable 120 ohm bus terminating resistors

Natively supported by SocketCAN for easy Linux integration

Inexpensive

Our Solution

We call the solution “4CAN,” and designed it with the following goals in mind:

Validating communication policy for intra-CAN bus communication.

Fuzzing (sending randomized payloads) to components to identify vulnerabilities.

Exploring the CAN commands used to control/interact with the vehicle.

Simplify our testbench setup to keep everything organized and in sync.

Design

George Tarnovsky, a member of CX APT, is the originator or the 4CAN’s design. The Raspberry Pi contains five hardware SPI channels so we decided to use the MCP2515 CAN Controller since it could interface with the Pi via SPI. We added a four-port DIP switch instead of physical jumpers or a solder bridge to easily enable the 120 ohm bus terminating resistors. The MCP2551 CAN transceiver was used as the CAN transceiver.

The high-level design is described in the below schematic.

PCB layout

To be as compatible as possible, we aimed to conform to the Raspberry Pi HAT specification as closely as possible. The HAT spec limits the hardware dimensions, requiring us to use creative solutions to pack all the components on the board. Since we did not include an EEPROM and did not leave a cutout for the camera connector, the module is not HAT compliant per spec. These were conscious design decisions, since we will not be using a camera add-on and do not make use of the EEPROM.

All components are surface mounted, using the smallest component sizes we could find to minimize space on the board. The only exception to using the smallest components is the USB-UART connection. Instead of adding all the components ourselves, we went with a premade board containing all the circuitry. This board sits on top of the 4CAN. A resistor pack further reduces part-count and has a smaller footprint than four individual resistors. Rather than drive all four CAN controllers with individual crystal oscillators, we opted to use just one. This can introduce clock skew, because each component receives the clock in serial, rather than in parallel at the same time. To limit the effect of clock skew, we kept the clock lines as short as possible. In order to keep costs down, we used a 2-layer PCB design. While this limits routing options, the cost is significantly cheaper than a board with more layers. We also added the standard 40-pin GPIO header, so that the remaining GPIO can be used.

The final layout is shown below.

Before and after

Before

In order to test four CAN buses simultaneously, we required three CAN devices. Two TT3201 three-channel CAN Capes attached to Beaglebones, and one CanBerryDual attached to a Raspberry Pi. We also have another Raspberry Pi to remotely control the test vehicle. With this configuration, we can test sending CAN frames between any two combinations of CAN channels. Although this setup works, it is a bit unwieldy, requiring lots of wires making connection tracking and test aggregation difficult.

After

Using 4CAN, the test bench setup is vastly simplified. With a single Raspberry Pi, we can simultaneously test four CAN channels, and since the 4CAN exposes the entire 40-pin GPIO header, we can remotely control the test vehicle.

The simplicity of using 4CAN is easily observable on the physical test bench.

Before 4CAN:

Using 4CAN:

Usage

For the 4CAN to communicate with the Raspberry Pi, the Pi must be configured with four SPI channels enabled and tied to specific GPIO pins. Additionally the Pi’s linux kernel requires additional drivers such as SocketCAN, which implements the CAN device drivers as network interfaces. From a user-space perspective, can-utils loads the SocketCAN drivers and provides capabilities to sniff CAN traffic, send CAN messages, replay captured CAN traffic, implement a CAN gateway to facilitate CAN-in-the-middle, and more.

CAN-in-the-Middle

To determine whether an ECU is sending or receiving a message or to modify CAN traffic in-flight, the 4CAN can be inserted between the CAN bus and an ECU to capture or possibly modify the traffic, to perform a CAN-in-the-Middle (CITM) attack. The required bridging can be enabled by combining can-util’s ‘cangw’ command and a script we have provided.

Sniffing Inter-CAN communication

The 4CAN allows us to test inter-CAN communication by sending a CAN message with a known payload on one CAN bus, and seeing if that same message appears on a different CAN bus. Doing so allows us to learn whether and how the CAN gateway is filtering or modifying messages. In some instances we have observed the CAN ID change for the same message across different buses. We provide a script to facilitate this “transcan” testing.

Tool Release

The 4CAN is available on GitHub here.

#gallery-0-5 { margin: auto; } #gallery-0-5 .gallery-item { float: left; margin-top: 10px; text-align: center; width: 33%; } #gallery-0-5 img { border: 2px solid #cfcfcf; } #gallery-0-5 .gallery-caption { margin-left: 0; } /* see gallery_shortcode() in wp-includes/media.php */

Go to Source Author: Original Post from Talos Security Author: New 4CAN tool helps identify vulnerabilities in on-board car computers…

[teamsupergood]

Plantr is an automated participatory community garden project that aims to create greenspaces across public spaces. The gardens use sensors and irrigation to keep track of the condition of the plants within it and relay the information to a website. Participation is done on a purely voluntary basis and can be as simple as replenishing a water reservoir or as involved as building and installing a whole new garden. The system measures user involvement and rewards them with Plantr points which can then be exchanged for perks and bonuses. The goal of the project is not only to greenify open spaces but to give the possibility to passers-by to feel part of the project and learn basics in gardening, coding and DIY design. In order to make the project as accessible as possible, costs are kepts to a minimum, materials are chosen to be readily available and all necessary resources are made publically available. Although this version of the build is better suited to growing small plants and herbs, it can easily be adapted and modified to grow fruits or vegetables in order to increase access to locally grown, fresh produce. Moreover, by modifying materials, the project could also be made to function outdoors to create rooftop gardens. Our project therefore responds to multiple sustainabilty concerns: energy needs for food production, urban heat island effect and more generally, global warming. In creating this project the work load was split into different modules of developement each with their own set of challenges, and decisions. Each module necessitated research for materials, design and technolog; protoptyping; building and testing. After completing what we are calling Plantr v.1.0 we also have a better idea of how to improve the project and how to make the building of each module mode accessible for would-be participants.

1. The garden. Pintrest is littered with design ideas for decorative indoor gardens so it's probably safe to say that pretty much everything has been done in this departement. Instead of trying to reinvent the wheel, we chose the tried and true tower design as it would offer an effecient use of space with its limited footprint and vertical design.

Although PVC is the most commonly used material when looking at examples online, we were hoping to steer away for the usage of new plastics. Therefore we opted for a cylindrical concrete pouring form. This is an object that is easy to work with and to cut into and the waxy coating on its surface makes it sufficiently water resistant in case of spills. To insure some stability we designed two base pieces that give the whole project an unintentional but welcome space-rocket look. Another objective was to keep as much of the electronics and irrigation out of sight in order to make the final object visually appealing. This proved to add to the challenge especially when trying to troubleshoot faulty wires with the electonic devices anchored to the inside of the tube.

In order to add a bit of polish we wanted to paint the outside of the tube. Spray paint would have been an easy choice but would have clashed with our sustainability objectives. We therefore opted for an acrylic based chalkboard paint which would give participants an extra outlet of creativity. After all, this first prototype is installed in the art building of concordia.

2. Sensing and watering system. The choice for sensors compatible with single-board computers and microcontrollers is vast, ever expanding and can be overwhelming. A multitude of data points were discussed along with various methods to collect them. Ambient humidity, temperature, atmospheric pressure and light levels were all discussed but discarted for simplicity and cost's sake. We narrowed it down to hygrometers (soil moisture sensors) for each plant and a water level sensor for the reservoir.

Hygrometers for DIY project come in two main flavors, capacitive and inductive. The choice here was not particularly difficult as the inductive type can cost upwards of 40$ each. While they do offer a more precise and durable output, especially for outdoor use, we needed 8 of these for the initial prototype which would make the system cost prohibitive. The capacitive snesors on the other hand ranged from 2$ to 8$ depending on the materials used in their fabrication. Although we would have been thrilled to see the cheaper variety (Sparkfun SEN-13322) succeed, we noticed performance degrading corrosion on these while testing and were forced to upgrade to the 8$ gold plated versions (DFRobot SEN0114). The output of these sensors are analog so the use of an ADC (analog digital converter) is necessary if the computer or microcontrol used does not have analog inputs. Luckily the MCP3008 works perfectly for this application using the SPI serial communication protocol present on most GPIO pins of single-boards. As for water level, again there are two main schools: float or ultrasonic sensor. Intuitively, we were drawn to the float sensor as it seemed easier to use. Unfortunately, the less expensive variety of these only offer the ability to measure whether the water level has exceeded a certain level. This would give us an indication when the reservoirs would need to be refilled but we preffered having an acual level to work with. Luckily, the ultrasonic sensor HC-SR04 can give supprisingly accurate and reliable readings of the distance between it and the surface of the water. Wiring and programming slightly more involved as it needs one pin to output a ping and another one to measure the time taken for the ping to bounce back.

Of course, with this data being input into our single-board, we now needed to use this interpreted data to trigger the automated irrigation to water our plants. Our initial plan was to split the water output of the reservoir to 8 individual soft tubed lines that would each have an electronically controlled valve and would run to each plant. While this idea remains feasable and applicable for projects with larger plants, having a costly valve per plant made little sense for our build. We instead chose to have a single valve leading to a rotating piece of plumbing that would direct the flow of water to one of 8 funnels, each leading to one of the palnts. With a single valve and a servo motor, we are able to water the plant that needs it. Those who have worked with servos may know that their range is often limited to around 180 degrees. We found two viable solutions to this, either going with a specialized, more expensive, winch servo for model sail boats which does cover a full 360 degrees, or go with a standard servo and use gearing to give us the range we needed. Although we beleive that using a gear system would be more advantagous in terms of cost and availability, it would require extra time and testing which were running low on at this point in the project. We therefore opted for the more expensive sail winch servo which is still reasonably priced at around 20$ (vs 8$ for a servo with 180 degrees range).

3. Gathering, analyzing and sending the data The valve, motor and sensors need to plug into something to be interpreted and sent out to the world and this is where the single-board computer or microcontroller comes in. Ever since the advent of the arduino uno and the raspberry pi, dozens of companies have decided to offer their own variation on these devices with different features with some even offering hybrids. While the arduino type devices offer direct control, dedicated resources and a mix of analog and digital inputs, the raspberry pi type devices offer every possible feature of a linux based computer including integrated wi-fi, storage and support for multiple programming languages. Hybrid boards like the Udoo Neo offer the best of both worlds with the same pinout as an Arduino Uno and an arm based CPU to run a full fledge linux distribution. Obviously, the extra features come at a cost and in the end, even the least expensive option is overkill in terms of computing power for this project. While we used a raspberry pi 2b that we had on hand to do the build, a pi zero W would do the trick and its cool 10$ price tag definately fits in with our goal of low cost accessibility.

Setting up the pi for wi-fi connectivity proved to be one of the most annoying challenges of this project. While it's easy enough to do so on a home network with standard WPA2-PSK security, Concordia (and most campuses) use a form of WPA2-Enterprise PEAP without certificate. Without getting into technical details, this meant hours of testing, tinkering and half a dozen e-mails exchange with Concordia technical support to get a connection going. Once that was done, the next step was to find a way to remotely control the Pi (having a screen and keyboard hooked up to it while it is anchored to the inside of the planter is obviously not ideal). Although it is easy enough to connect to a device via SSH on a home network, doing so on a campus network is usually prohibited. In order to circumvent this issue, the SSH port had to be bridged to an external server that is publically visible. This acts as an intermediary connection that redirects the traffic directly to the Pi. A script was written to ensure that the Pi would automatically re-establish the bridge if the device were to reboot or the bridge to fail. The advantage with this method is that it is now possible to remotely control the Pi from anywhere, even outside Concordia's network. As a matter of fact, a decent part of the code was written from the comfort of my living room while the Pi was locked away in a room in the arts building. Speaking of code, the script that controls the sensors and watering system was written in python as it offers all the necessary compatible libraries to interface with the Pi's GPIO pins. The algorithm is relatively simple. If one of the plant's hygrometer has a reading that is below a certain threshold and if the plant has not been recently watered, the motor moves the plumbing towards correct funnel and the valve is opened for 3 seconds. At every loop, the ultrasonic sensor checks the water level. All the data is collected. If the information has not been updated in more than 15 minutes, the Pi connects to the website's server via FTP and updates a json file containing all the information.

4. Displaying the information and point system Once all this information is collected and uploaded, it needs to be displayed online for users to see. We use a bare-bones virtual server from OVH that has a datacentre in Beauharnois that uses water-cooling to reduce energy usage of their machines. By using a combination of google API and javascript, we can parse the data from the json file and display the status of the plants on a map in a way that is meaningful to users. The website is also designed to offer users the possibility to create an account and accumulate points for their participation. This feature however was not implemented and a dummy version is displayed for demoing purposed. The map however does show live data from the garden.

While we were succesfully able to test the technical functionalities and how the organic interacts with the electronic we would need more time to measure the social aspect of the project. This would enable us to have a reading of how feasible it would be to implement in an uncotrolled environement. Still, the build has proven to work and be adaptable for personal or educational use for anyone who would want to reproduce it in their home or classroom. We welcome any initiative to iterate on the current design to adjust it to different situations.