1
2
3
4
5
6
7
8
9
10
11
12
13

#!/bin/sh
 
PREFIX=/var/develbackup
SVNFOO=/home/svnuser/repos/foo
TRACFOO=/home/svnuser/trac-env/foo
 
DATE=$( date +%Y%m%d )
BACKUPDIR=backup-${DATE}
 
mkdir ${PREFIX}/${BACKUPDIR}
 
svnadmin dump ${SVNFOO} | gzip > ${PREFIX}/${BACKUPDIR}/svn-foo.dump.gz
trac-admin ${TRACFOO} hotcopy ${PREFIX}/${BACKUPDIR}/trac-foo

And the crontab line is as follows:

1

30 22 * * * /home/svnuser/develbackup.sh

The paper presents a series of techniques which goal is to detect the presence of RF signal from different devices such as bluetooth, Zigbee, etc. They main contributions is the use of commodity WiFi adapters which allows anyone to use the solution proposed.

The image below show an schematic view of the process of fingerprinting RF Signals and the pattern matching stage:

airshark modules

The detection rate is pretty awesome as shown in the next table:

• Embedded Multicore [PDF Version]

This paper is pretty long paper by Freescale describing several features of MultiCore Systems from a developer point of view both Operating Systems and application programmers. It covers basic techniques when dealing with MultiCore systems but provides some good aspects to state-of-the-art on this area and where the industry is heading.

Freescale's QorIQ(tm)

 It also describes how virtual platforms allow developers to make better use of these kind of systems for example running a dedicated RTOS in a core a having a general purpose OS in another.

It is a good reading to brush up some concepts and get a better picture since MultiCore System will become the standard in the near future.

• Packets in Packets by Travis Goodspeed et al. [pdf version]

This paper present a technique to inject raw frame at Layer 1 from the payload of upper-level Layers, for example HTTP. Tested for  IEEE 802.15.4 and 2-FSK radio protocols.

This attack doesn’t work on encrypted channels since the raw frame inserted in the payload is encrypted too.

The image below shows a representation of the of the attack compared to a normal packet transmission:

• Empirical Analysis of Solid State Disk Data Retention when used with Contemporary Operating Systems by Christopher King et al. [pdf version]

• Verification: Check whether we are building the product right
• Validation: Whether we are building the right product

Some authors propose several strategies to improve software testing results:

• Quantify Requirements long before the testing begins: So testers can measure how close the product is to the client’s idea.
• Specify testing goals: Time between failures, cost of fixing a failure, etc
• Understand the client’s behaviour and develop a profile:  Focus software testing on its real usage
• Testing plan featuring ‘Quick Testing Cycles’
• Self-ControlProduct: Failure detection
• Formal Testing Techniques: (Alright, they might be cool but too expensive)
• Continuous Integration

 Strategies for Testing Software

Unit Testing:

• Verification of each module to check whether it implements the contract it relays on.
• Since some other components it depends on might not be yet available, some interface simulation must be developed.

Integration Testing:

• The goal of this process is to test the interaction between modules and prevent any problema when interconecting interfaces
• Top-Botton Aproach needs to generate simulators for no yet available modules
• Bottom-Up Approach tests first low-level modules and keeps adding higher-level ones so no simulation is needed
• Regression Tests are needed to be sure that when some modules has been modified all other keeps working ok
• Smoke Testing is a lightweight tests which aims to detect problem in a early stage. It must be tested daily

Validation

• Focuses to check whether the product stays close to the requirements
• Uses Alpha (developer + user) and Beta (only user) tests

This is the first article in a serie about CANBus and higher-level protocols, which are extensibily used in Industrial environtmens along with Embedded Systems.

CANBus standard describes only the layer 1 and 2, from an OSI point of view, dealing with physical and datalink activities. On the other hand, CANOpen is a protocol which lies in the OSI layer 7.

There is no need for intermediate layers in these kind of busses since all of them belong to the same network segment; neither the notion of session is available in CAN networks.

CANBus

As can be seen in the image above, CANBus uses two wires for the communication bus and transceiver only need hook these two lines (and the ground). In some representations, as the above, you may see the bus both sides ended, this is usually done by a 120 Ohms resistor which is only mandatory when the bus exceeds a normal length.

For now, the fields, in a CANBus Frame, we are going to care about are identifier, which is 11 bit wide in the base version, and the data field holding as much as 8 bytes in each frame, the rest of the fields deal with synchronization of frames and error checking, you can find them in Wikipedia CAN Entry.

CANOpen

CANOpen is a protocol built on top of CAN, but can run in different link layers, which implements an object centric message system. The main entity in CANOpen is the Object Dictionary, which is a description of all the objects supported by an specific device, it doesn’t matter the format it is delivered in as long as both side of the communication are aware of it. The protocol is profile based defining each of them different objects that must be implemented by the device

Each Object has its own 16bit wide index and another 8bit wide address for referecing subdata fields.  As can be seen in the next table there range of these address which are mapped to specific functions described in different profiles e.g. CiA 301 (communication profile area):

So with this new specification we have 4 bits to specify the function the message is requesting to perform and 7 bits spare for device’s ID which span from 1 to 127, being 0 forbidden.

Function Codes can be either pre-defined by the standard or custom, modified after the devices powers-up.

The tables below shows the configuration for the pre-defined connection set; the first for broadcast messages and the second one for peer-to-peer object messages:

Administrative Messages:

• This messages fall in the category of Master – Slave communication such as those dealing with initialization or  network configuration. As an example NMT is used to initialize, start/stop nodes, etc

Service Data messages (SDO):

• This messages provide access to device’s objects using the Object Dictionary index and subindex and allows data transfer of any length.
• Each message needs to be confirmed and each request / reply transports 8 bytes rendering this kind of service not suitable for RT data transfer.

Process Data Object (PDO):

• Used to transfer RT data from one producer to several consumers and each message is limited up to 8 Bytes.
• Each PDO is described by two objects, one for setting the COB-ID, transmission type, inhibit time and timer period and the other to map list of objects from the Object Dictionary mapped into the PDO.
• The objects mapped to a PDO are configured using SDO messages.
• There are to modes: SYNC (triggered by a SYNC object, ASYNC (triggered by a device event)
• Inhibite time: Minimun time betweet 2 PDOs
• Event Timer: Transmission Trigger

Predefined Messages:

• SYNC: Used to synchronized operations across the network, when device receive a SYNC message the perform the expected action.
• Time – Stamp: Common time frame reference
• Emergency: Triggered by an error in a device
• Node/Life Guarding: Monitor state of Devices, detects network errors, etc
• Boot-up: By sending an NMT message the slave change from state Initialising to Preoperational

After presenting this talk first at RootedCon and a month later at Hackito Ergo Sum the time for releasing the code behind it has arrived.

To understand the source code, you only need to have a look at the deployment diagram where the attacker is drawn in red and the victim in green.They have been designed as two independent components which exchange method invocations using a simple Marshalling/UnMarshalling scheme.

Although the proof is conceptually multiplatform I have only implemented the windows part so the source code is a Microsoft Visual Studio Solution with two projects, Attacker and Victim.

Attacker

• It is a dll implementing the PKCS#11 API ready to be added as a Security Device in Firefox as follows: Tools->Options->Encryption Tab->Security Devices->Load
• Instead of accessing any local device each method marshalls the parameters and sends them to the remote peer then  waiting for the response to arrive.
• A file at C:\pkcs11-ip.cfg must contain the IP address where the library will be sending requests.

Victim

• Binds a socket and waits for PKCS#11 requests to arrive
• After a new request has been read, the official PKCS#11 library is used to perform the selected operation and retrieve its output sending it back to the Attacker.

I have uploaded the source code to github, it is provided with known issues so do not blame for them, this is just a PoC.

Here you can find the presentation in Spanish and here in English, they are pretty much the same.

Any question, bug, improvement, whatever please leave a comment below!

QEMU + Linux + BuildRoot

Here are some basic steps to get a virtual ARM Development board which will allows to practice our embedded systems skills or test code / firmware or whatever we want to do but without the need of having a physical device.

The following takes place in a Linux machine running on Virtual Box (512MB RAM), which I first thought would’ve taken much more time to compile the whole stuff but it only took ~2h.

For the whole procedure you are gonna need some development packages such as gcc, g++, bison, flex, gettext, texinfo, zlib, ncurses, uml-utilities and maybe others, just install them when the process complains.

We need to make use of tun/tap device to create a local lan in order to let the embedded linux find the NFS mount point.

• Setting up tap0:

$ sudo tunctl -u youruser
 
Set 'tap0' persistent owned by 10101
 
$ sudo ifconfig tap0 192.168.10.1 up

• Setting up NFS mount point:

Since we want this set-up for development I assume we want to add new binaries or modify configuration on-the-fly so I have created ~/root-nfs where the file system for our embedded device will reside. Update /etc/exports appropriately:

$ echo "/home/someuser/root-nfs" 192.168.10.0/192.168.10.255(rw, sync,no_root_squash)" > /etc/exports

Remember the no_root_squash method or files only accessible by root will no be exported through NFS.

Second Step: Configuring QEMU

Grab the source from www.qemu.org and compile it, or if you prefer just used some prebuilt binaries. It shouldn’t make any difference.

QEMU not only emulate CPUs but also a bunch of development boards with its attached hardware so you can run real software that interacts with the ethernet or whatever other peripheral available.

For our purpose we are going to use versatilepb which is an ARM based development board which you can physically have it but thanks to QEMU we can use a virtual one.

The only thing you need be sure when configuring/compiling/installing QEMU is that it supports ARM as target and the versatilepb machine is available.

Third Step: Getting BuildRoot

Buildroot is a great framework for crosscompiling, targeting mainly embedded systems. It is a bunch of Makefiles and configuration files which automatizes the toolchain generation for the target platform, building bootloader, kernel, libraries, binaries and preparing the appropriate images for booting a device.

The configuration is pretty similar to the Linux Kernel so if you are used to deal with menuconfig this will not show any difficult to you.

After  decompressing buildroot we have to perform some minor configuration to produce the binaries we need for our target device.

Just type:

$ make menuconfig

And change the following entries:

• Target Architecture = arm
• Target Architecture Variant = generic_arm
• Target ABI = EABI
• Target Options -> Generic Serial Port Config -> serial port to run getty on (ttyAMA0)
• Package Selection, make sure Busybox is selected
• Target FileSystem Options -> check tar the root filesystem
• Kernel -> set deconfig name to “versatile”
• Kernel -> Kernel binary format to zImage

Afterwards do:

$ make linux26-menuconfig

Accept the default configurations and change anything you feel like changing

Note: I had a problem with the provided fakeroot version so I downloaded the fakeroot_1.11 from the debian repository and copied it to buildroot/dl/ (which is the place where downloaded packages are stored) and changed the verson to 1.11 in buildroot/packages/fakeroot/fakeroot.mk and then make again.

Just type:

$ make

And let the whole Makefiles produce the desired images!

They will be placed under buildroot/output/images, there you will find the zImage and the root.tar containing a whole filesystem with everything need to boot a Linux Operating System.

Final Step: Booting QEMU

Just before booting we should uncompress the root fs to the exported NFS directory as root, otherwise the special files under /dev will not be properly created which will stop our system working properly.

Now we just need to tell qemu the following parameters to run our system:

• -M versatilepb # our target platform
• -kernel buildroot/output/image/zImage # our generated kernel image targeting ARM
• -net nic # so qemu emuletes a NIC interfaces as part of the versatilepb platform
• -net tap,ifname=tap0,script=no # tell qemu to link the emulated NIC to the preconfigured tap device
• -append “console=ttyAMA0 root=/dev/nfs rw nfsroot=192.168.10.1:/home/someuser/root-nfs ip=192.168.10.2″ # to instruct the booted linux kernel to search for the root-fs in the specified NFS server using the provided ip as its own
• -nographic # to output everything to stdout

And all together:

qemu-system-arm -M versatilepb -kernel buildroot/output/image/zImage -net nic -net tap,ifname=tap0,script=no append "console=ttyAMA0 root=/dev/nfs rw nfsroot=192.168.10.1:/home/someuser/root-nfs ip=192.168.10.2" -nographic

Now you should see the booting process of Linux and then the busybox login, as seen in the image above; just use root and no password to log in.

Introduction to the PSP

The book is written in a pretty informal way, the author seems to talk to his son or someone really close, which I don’t really mind but, from my point of view, adds extra literature not necessary at all to explain the PSP.

The author focuses in two aspects along the book, measuring / planning and defects. The most valuable part and which I found more interesting is the one dealing with personal planning since it can help you not only when dealing with software projects but in your real life.

I really think that applying techniques such as registering tasks durations, interruptions management and creating week summary can help you become more productive and eliminate those periods of the day you think you are working but your not.

I also agree with the author that using his techniques you can become more realistic when planning a new project I think it is not because of the whole planning stuff but you can know exactly how many time are you really working in your projects without all that bloat of interruptions.

The part I don’t really like is the second half of the book which focuses in dealing with defects. The author ideas are only applicable when dealing with beginners defects and I don’t find useful any of the metrics he proposes.

In few words, this books is worth reading if you feel you are wasting your time and want to become more productive and/or want to make sure you can make realistic project plans.

• A design must present an architecture built using known pattern designs, components with the right characteristics and that can be implemented in an incremental way.
• Must be modular, divided in subsystems
• Must lead to interfaces which reduce the complexity when connecting components
• Must be generated from a reproducible method and the information produced during the analysis
• Must use notation to express its meaning correctly

COQ takes into account the following costs:

• Failure costs: All costs of fixing a defect e.g. Patching a deployed product, using the debugger, reviewing code, etc
• Appraisal costs: Work done evaluating whether a product has defects, excluding time spend on fixing them.
• Prevention costs: Resources used to improve the process to reduce the number of defects.

Following I will describe the PSP approximation to COQ a simplified way of calculating this measurement. The author states than this version of COQ shows the same effectiveness as the long COQ version.

• Failure costs: all compiling time, all testing time.
• Appraisal cost: All review time

Cost of Quality is calculated as a percentage of total development time:

• Appraisal COQ: Sum of all review time as percentage of total development time.
• Failure COQ: Sum of all compile and test time as percentage of total development time.