#3: Kali Linux on the Beaglebone Black

Ethernet and USB Problems

I tried Fedora on the BBB, but it is slightly behind the curve (strange for Fedora, which is usually bleeding edge), the ethernet and USB ports do not work yet since it needs a newer kernel.  The Debian distributions are better on the BBB.

So, one can blow against the wind, or try Debian...

Penetration Tests

I am working on a networked project which is an island system - it is not connected to anything else at the moment.  I say at the moment - since I know that sooner or later, the bosses will demand that it be connected to the something else, at which point the lack of attention to security will come to bite everyone.

There is a small security and penetration test oriented Debian based distribution called Kali Linux that you can get here http://docs.kali.org/armel-armhf/install-kali-arm-on-a-beaglebone-black

Kali installs on a SD card, so your original Angstrom Linux on the BBB will remain unaltered, which makes it worth a try.

An interesting feature of Kali, is the website, which was nicely translated into 13 languages.

With this version, you should be able to do various nefarious things to your fellow developers using the Metasploit package...

Get it and Prepare an SD Card

You can download the ARM HF image here http://www.kali.org/downloads/

Specifically:

http://cdimage.kali.org/kali-latest/armhf/kali-linux-1.0.6-armhf.img.xz

Uncompress it with xzcat:
(For a Mac, get the xz utilities here: http://macpkg.sourceforge.net/)


$  xzcat kali-linux-1.0.6-armhf.img.xz > kali-linux-1.0.6-armhf.img


and copy it to the SD card with Data Definition like this: 
$ su -
password
# dd if=kali-linux-1.0.6-armhf.img of=/dev/sdb bs=512k

Using Data Definition on a Mac

Stop the automounter called diskarbitrationd temporarily, otherwise the SD card will be mounted and 'busy': 
$ sudo launchctl list | grep diskarbitrationd
16 - com.apple.diskarbitrationd 
$ sudo kill -SIGSTOP 16

Only now, stick the SD card into the Mac SD slot.

Open a terminal and type
$ ls /dev/disk*
/dev/disk0    /dev/disk0s2    /dev/disk1
/dev/disk0s1    /dev/disk0s3    /dev/disk1s1
 
The disk0 is your SSD and you don't want to mess with that!
The disk1 is the SD card.

Now, with the SD card unmounted, you can use dd to copy the BBB image to disk1:
$ sudo dd if=kali-linux-1.0.6-armhf.img of=/dev/disk1 bs=512k

On a Mac, Ctrl-T will show the dd progress.

Note that if you accidentally dd to /dev/disk0, then you will destroy your Mac system.
So, don't do that!

Finally, re-enable the automounter:
$ sudo kill -SIGCONT 16

Accessing the SD card from a Virtual Machine

I run Fedora 20 on my Macbook Pro and getting Virtualbox to see the SD card is somewhat painful.

First of all make sure that the Fedora virtual machine is NOT running.

Stop the automounter as above to ensure that the SD card is not mounted, then access it using a raw disk image.

Make a raw disk image file for Virtualbox:
$ VBoxManage internalcommands createrawvmdk -filename /path/to/file.vmdk -rawdisk /dev/disk1


Attach the raw disk to a guest VM within the VirtualBox UI:

1. Ensure the guest VM is not running.
2. Open the settings area for the guest VM
3. Click on "Storage" in the toolbar
4. Next to the controller click on the icon to "Add Hard Disk"
5. Select "Choose existing disk"
6. Navigate to the /path/to/file.vmdk you used in step 3 and select it
7. You should now be returned to the Storage tab and see your file.vmdk in the list.
8. Start the VM
9. The SD card will then be available as /dev/sdb 

Now you can use the Fedora VM to access the SD card normally and finally, when done, you can re-enable the automounter using kill -SIGCONT.

Boot Kali

Unplug the USB power cable, install the serial cable (Black wire at the little dot), plug in both USBs and run screen:

$ screen /dev/ttyUSB0 115200

or on a Mac:

$ ls /dev/tty.usb*

/dev/tty.usbserial-AH0142BF

$ screen /dev/tty.usbserial-AH0142BF 115200

Now plug in the USB power cable again and watch her boot.

There is also a little reset button on the corner at the 4 LEDs.

Bugs

Finally, I managed to boot the SD card and got this:
Hit any key to stop autoboot:  0
gpio: pin 53 (gpio 53) value is 1
mmc0 is current device
micro SD card found
mmc0 is current device
gpio: pin 54 (gpio 54) value is 1
SD/MMC found on device 0
** File not found uEnv.txt **
gpio: pin 55 (gpio 55) value is 1
** Invalid partition 2 **
U-Boot#

Hmm... now I'm wondering whether the mods on the Fedora BBB page are required here too:
$ cd /media

$ cp __/usr/share/uboot-beaglebone/* uboot/ 

$ cp uboot/uEnv.txt.beaglebone uboot/uEnv.txt

$ nano uboot/uEnv.txt 
abcboard=am335x-bone > abcboard=am335x-boneblack 

Some more sleuthing is required to sort this out.

Soooo, remove the USB power cable, remove the SD card and stick it into the Mac.
Aaaargh! Stupid automounter and stupid Mac that doesn't support the file system...

Boot a Linux machine and stick it in again.

An error occurred while accessing DEBIAN_LIVE...

Bah, humbug!  No wonder it won't boot either.

It really looks like it is time to find another distro again, or to build the darn thing myself.

Build It Yourself

If you are more adventurous, the Kali build scripts are on github here https://github.com/offensive-security/kali-arm-build-scripts

Get bbb.sh and README.md for the details.

I think I'll rather install QEMU and build my own version of Fedora ARM, since that is the distribution I like the most.   More on this later.

Eish...

#2: Doing Something with the Beaglebone Black

Something Useful: Retroshare

I actually want to run Streamtuner and Retroshare on the BBB.   More about Retroshare here: http://www.aeronetworks.ca/2013/07/your-own-darknet.html

The BBB will make a nice static DHT reference for my small circle of friends and devices on Retroshare, to ensure that all can always connect no matter how much anyone or anything moves around.

Expand the SD Linux File System

If you followed my first BBB post, then you have probably seen this already:
grep: write error: No space left on device

It looks like the first thing to do, is expand the root partition to fill the SD card, otherwise there is no room to do anything :(

On you computer, use screen to connect to the serial console over a FTDI USB serial cable:
$ screen /dev/ttyUSB0 115200

On a Mac, screen works the same, but the device is something like /dev/tty.usbserial-AH0142BF

So, what was that about Macs having sensible device names? Sigh...

Then power the BBB up using the USB cable, or a 5V PSU.

Login and set user to root:
Login: username
password
$ su -
password

See what is there:
# fdisk /dev/mmcblk0
Disk /dev/mmcblk0: 7.5 GiB, 8010072064 bytes, 15644672 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00036e16

Device         Boot     Start       End  Blocks  Id System
/dev/mmcblk0p1 *         1953     41015   19531+  c W95 FAT32 (LBA)
/dev/mmcblk0p2          41016    291015  125000   c W95 FAT32 (LBA)
/dev/mmcblk0p3         291016  15644671 7676828  83 Linux
 
The above tells me that the SD card is 8GB and there are 3 partitions.  The 3rd one is the Linux partition that we got to fix.  Note that the Linux partition fills the whole device, meaning that the partition is OK, but the file system doesn't fill the whole partition.  So it is only a file system problem, not a partition problem.

Grow the File System

Grow the filesystem over the rest of the partition:
$ su -
password
# resize2fs /dev/mmcblk0p3

La voila!

Well, assuming that it still works, otherwise you are back at square one and need to rewrite the SD card again, as per my other BBB post...

Make a SD Backup

At this point, it may be a smart idea to make a backup of the whole SD card, so that next time you have to rewrite the stupid thing, you don't need to do the setup steps again.  So shutdown now, power off and plug the SD card into a laptop computer then use dd or cat with gzip to make a copy of the SD card:
# cat /dev/mmcblk0 | gzip -9 > bbb-f20-1.gz 

or on a Mac, which will likely do a partial automount, you got to unmount it first:
$ sudo umount /dev/disk1s1
$ sudo cat /dev/disk1 | gzip -9 > bbb-f20-1.gz

Why does Macs have sensible device names while Linux is such a mess lately?

Since at this time the SD image is still mostly zeroes, the compressed image will be manageable, but it will take a looong taaaime to do, so go and get a tall, cold one...

Accessing the BBB Hardware

The serial ports are available in /dev/ttyox (that 'o' really is a letter, not a zero), while the GPIO ports are available in /sys/class/gpio:
$ ls /dev/ttyo* 
$ ls /sys/class
ata_device  graphics     mem            ptp          scsi_generic  vc
ata_link    hidraw       misc           pwm          scsi_host     vtconsole
ata_port    hwmon        mmc_host       raw          sound         watchdog
bdi         i2c-adapter  net            regulator    spi_master
block       ieee80211    pci_bus        rfkill       thermal
bsg         input        pcmcia_socket  rtc          tty
dma         leds         power_supply   scsi_device  udc
gpio        mdio_bus     pps            scsi_disk    usbmon

$ ls -al /sys/class/gpio
total 0
drwxr-xr-x.  2 root root    0 Jan  1  2000 .
drwxr-xr-x. 45 root root    0 Jan  1  2000 ..
--w-------.  1 root root 4096 Jan  1  2000 export
lrwxrwxrwx.  1 root root    0 Jan  1  2000 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx.  1 root root    0 Jan  1  2000 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx.  1 root root    0 Jan  1  2000 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx.  1 root root    0 Jan  1  2000 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w-------.  1 root root 4096 Jan  1  2000 unexport

Feel free to poke around, don't be shy...

Hardware Information:

• https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true
• http://www.ti.com/lit/ds/sprs717f/sprs717f.pdf
• http://www.ti.com/lit/ug/spruh73i/spruh73i.pdf

Using GPIOs on Linux:

• https://www.kernel.org/doc/Documentation/gpio/gpio.txt

It is relatively straight forward to access a GPIO from a script, using simple echo statements, but one has to configure them before one can use them.

See table 10 on page 70 for the P8 header and table 11 on page 72 for the P9 header in the reference manual https://github.com/CircuitCo/BeagleBone-Black/blob/master/BBB_SRM.pdf?raw=true

For example, P9 pin 15 is gpio[16] and is on gpiochip32, which has an offset of 32, so pin 15 is 16+32 = gpio48.

Two P9 header GPIO pin number mapping to kernel names:

• pin 15 = gpio48
• pin 16 = gpio51

To enable both pins:
# echo 48 > /sys/class/gpio/export
# echo 51 > /sys/class/gpio/export 

Now, there should be two new subdirectories in /sys/class/gpio representing these two pins and one can set the direction and a value for pin 15 and watch it toggle with an oscilloscope:
# echo out > /sys/class/gpio/gpio48/direction
# echo 0 > /sys/class/gpio/gpio48/value
# echo 1 > /sys/class/gpio/gpio48/value

Note that the BBB uses 3.3V logic and a pin can drive up to 5mA, so be careful with what you connect to it so you don't blow the pin drivers up.

You could use something like this opto-coupled solid state relay to control things with only 0.5mA per pin:
http://www.vishay.com/docs/81646/vo14642a.pdf 

A 3.3V supply minus 1.5V forward diode voltage, divide by 0.5mA, means using either a 270 or 330 Ohm series resistor on this type of opto-coupler.

La voila!

#1: Beaglebone Black (BBB) with Fedora Linux

I bought a Beaglebone Black open embedded processor board about 6 months ago and it has been lying on the dining room table ever since.  Now that the missus went on a holiday to Poland and Slovakia, I finally got around to firing it up to see if it works.

Where to get it

The BBB project is here: http://beagleboard.org/Products/BeagleBone+Black

In the mean time, the Fedora project has released an ARM distribution that includes rudimentary support for the BBB: https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation

First of all, to see if the hardware is OK, I just connected a USB cable to it and started it up with the default Linux version residing on the device and it worked fine.  After installing a USB network driver on my Mac and restarting it, I could SSH to address 192.168.7.2 and poke around in Angstrom Linux.

Unfortunately, Angstrom Linux http://beagleboard.org/latest-images is not well supported - the project is very small with maybe just one or two not very active developers.

Anyhoo, the little board booted up fine, lights flashing merrily and I even got the ethernet port to work with SSH after a few minutes of futzing around with it and then I got the inevitable 'success depression': It works, now what do I do with it?  I cannot use Angstrom, since it is just too limited: No NFS, no SMB, no whatever I could think of.  What can I do with it?

Fedora to the Rescue

When dealing with these little boards, there is always the danger that one can do an update and render the board unbootable.  Therefore, I prefer leaving the original Angstrom system intact and experimenting with the micro SD card instead.

The Fedora project page states:
Support for the BeagleBone Black has been added in Fedora 20. The GA release includes basic support which will be extended to include HDMI and USB with the release of the 3.12 kernel. A remix is planned when support is available. In the interim, the minimal image is recommended. 

So there is hope.  Let's get it and try it.  I was out of luck on my Mac, since I don't have zcat on it, so I switched to an older Linux machine with KDE and quickly got everything:

$ cd

$ mkdir BBB

$ cd BBB

$ TYPE=Minimal $ wget http://download.fedoraproject.org/pub/fedora/linux/releases/20/Images/armhfp/Fedora-$TYPE-VFAT-armhfp-20-1-sda.raw.xz

Micro SD

Hmm, now I needed a small SD card and Carrefour had a special with two cards in one package - a small 8GB plus a 32GB.  So 30 minutes later and a few Dirhams poorer - well, nothing is free and few things are cheap - I stuck the SD card into the laptop and copied the image to the base of the SD device:

$ dmesg

$ ls /dev mmcb*

/dev/mmcblk0 /dev/mmcblk0p1

If you see multiple partitions, then this is probably a used SD card, so it may be best to zap it first:

$ su -

password

# dd if=/dev/zero of=/dev/mmcblk0

and go and get some coffee, or a non-alcoholic beer...

On a Mac, you first have to install xz from here:

http://macpkg.sourceforge.net/

Xz, xzcat and the rest of the zoo will install itself into /usr/local/bin by default.

Now you can write the image:
$ xzcat Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz > /dev/mmcblk0
(or $ /usr/local/bin/xzcat ... on a Mac)

Popping the SD card out and sticking it back in again, caused an automount in /media with two visible directories called "__" and "uboot".

According to the Fedora page a few little mods are required:

$ cd /media

$ cp __/usr/share/uboot-beaglebone/* uboot/ 

$ cp uboot/uEnv.txt.beaglebone uboot/uEnv.txt

$ nano uboot/uEnv.txt 
abcboard=am335x-bone > abcboard=am335x-boneblack 

Now, we are in business!

Boot Her Up

Stick the little card into the BBB, insert the USB cable to power it and watch the lights.  When the flashing stops after a couple minutes, Fedora is running, but now I need a serial cable to be able to connect to it...

Rummaging through my radio control junk box, I found a Sparkfun 3.3V FTDI USB serial cable https://www.sparkfun.com/products/9717, which is exactly what is needed.

So, unplug the USB power cable, install the serial cable (Black wire at the little dot), plug in both USBs and run screen:

$ screen /dev/ttyUSB0 115200

La voila! 

Fedora on the BBB works and after a few minutes it gets a menu where one can configure the root password, configure a user account and set the time zone.

So, now what can I do with it?

:)

US Navy Overreach

The US Navy was outed for collecting Pawnshop and Parking Ticket data on all and sundry in their LinX database - sigh...

What makes it even more silly, is that this data is already in a FBI database too.  If we ignore the fact that trivial data really should not be stored, the FBI is where it should be.

A few years ago, the US Air Force had a program called TALON that was also doing domestic spying, but it was shut down after a public outcry.  It appears that nobody learned anything.

There is an ancient proverb, dating back to the age of the dinosaurs that says:
Garbage In, Garbage Out (GIGO).

The gigantic GCHQ, CSE, NSA, Navy, Airforce, Army(?) server farms are not databases.  They are digital garbage bins.

Storing nonsense data at great cost is a total waste of money and resources and will not help catch any criminals - let alone supposed terrorists.  Spying on hundreds of millions of honest citizens is a total waste of time.  Reducing crime requires old fashioned police work - gumshoes pounding the pavement.  The online spying money can be much better spent on hiring and putting more Bobbies on the Beat.

It seems that nowadays public outcries don't help anymore and insanity is prevailing.

International Covenant on Civil and Political Rights

"Would the delegation recognize that the United States’ position on extraterritorial activities allowed the United States to commit violations everywhere except in their own territory?  The non-applicability of the Covenant to extraterritorial activities led to impunity and rights violations.  If all States were to share that interpretation, there would be no protection of rights at all.  Was the Government ready to review its position concerning the extraterritorial application of the Covenant?"

http://www.ohchr.org/EN/NewsEvents/Pages/DisplayNews.aspx?NewsID=14383&LangID=E

The US NSA and the UK GCHQ are so obtuse that it doesn't warrant further comment.

Electric Feet

I have now caught two of these little guys in the house in one week - released back in the garden.

Why don't their sticky feet get dirty?

Apparently they stick to surfaces through Coulomb forces with the nanoscale hair on their feet, but while that explains how it works, it doesn't explain why their feet are not permanently covered in leaves and other detritus.

Can they control their electric feet at will?  Can they reverse the charge and repel dirt?

It is still one of life's little mysteries.

Network Debugging

With embedded systems, it is frequently necessary to look at the packets flowing on the network in order to see whether a problem is isolated, or caused by something else.

The problem is that there can be an enormous amount of data on the net and only one or two packets that you want to look at.  Especially when you have video streams flowing on the net, it becomes a search for a needle in a haystack.

The standard interactive network test tool is tcpdump.  It is also available on Windows as windump (http://www.winpcap.org/windump/install/).  Wireshark is also a nice front end for packet capture, but it works in a capture first, analyze later fashion.  With tcpdump, you can see what is going on in real time.

Packet Capture Examples

Tcpdump has a good man page, but it can be a bit overwhelming.  Once you saw a few real examples, though, deciphering the man page will be much easier.  The windump man page is exactly the same - they didn't even bother to change the name of the man page.

Display all packets on the wired port em1:
# tcpdump -nlX -i em1

Display all packets to/from a specific device:
# tcpdump -nlX -i em1 host 192.168.111.3

Display all packets to/from a specific host on a specific Berkeley port:
# tcpdump -nlX -i em1 host 192.168.111.3 and port 2000

Advanced Packet Capture Examples

Display all packets that has a specific byte in a specific place:
# tcpdump -nlX -i em1 ether[58] == 0x05

Display all packets that don't have two bytes in two specific places and are coming from a specific device:
# tcpdump -nlX -i em1 src host 192.168.111.3 and port 2000 and ether[58] != 0x05 and ether[59] != 0x7b

The trick is that you got to add the 14 byte ethernet frame header to the byte position (start counting your data from 0). The first byte (45H) that the below packet starts with is ether[14].

The result of the first search will look something like this:

14:52:56.860160 IP 192.168.111.12.55338 > 192.168.111.4.sieve-filter: UDP, length 66
    0x0000:  4500 005e 1513 4000 8011 861a c0a8 6f0c  E..^..@.......o.
    0x0010:  c0a8 6f04 d82a 07d0 004a cd76 3130 0000  ..o..*...J.v10..
    0x0020:  0000 0000 0000 0000 00d4 0000 057b 0000  .............{..
    0x0030:  0020 ffff ffff ffff ffff 41d4 c6bd 9c40  ..........A....@
    0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
    0x0050:  0000 0000 0000 0000 0866 0000 0daf       .........f....

I bolded the 057bH that I was looking for.  The second search will show packets where the 057bH is missing.  

This can settle an argument between two developers very quickly!

PCAP Files

You can also start a capture and let it save to a file, then analyze it later if you have to.  Tcpdump smart file handling can be configured to create multiple log files and rotate them, so that it will not overflow your available storage space.

It is easy to write data to a file:
# tcpdump -nlX -i em1 -w filename.pcap

Read from a file:
# tcpdump -nlX -r filename.pcap

It works exactly the same when analyzing a file offline as when you analyze data real-time.

La voila!

Embedded Networking

Nowadays everything and anything are connected using Internet Protocols: TCP, UDP, RTP, ARP, IGMP... the list goes on and on.  However, embedded systems are frequently island systems, that are not connected to the usual support services such as DHCP and DNS.  IP addresses are static and there are no gateways to other nets.

Island Networks

When you plug an office laptop computer into a typical embedded net, nothing happens, your machine remains unconfigured and you cannot access anything. Testing and debugging a modern system therefore requires a little bit of advanced networking knowledge.

In order to communicate on a net, your machine needs at least two things to be configured: IP Address and Subnet Mask, but before you can set it, you first have to disable the NetworkManager auto-configuration utility, since in an embedded system, it is more of a hindrance than a help.

Each time you unplug a cable or power down the device your laptop computer is connected to, Network Manager tends to forget the IP settings and when you replug it, you got to set everything up all over again.  This gets annoying super quick.

Network Manager

To save your sanity, disable NetworkManager with one of these commands:
# service NetworkManager stop

or
# systemctl stop NetworkManager.service
# systemctl disable NetworkManager.service

or
# killall NetworkManager

Network Settings

Once NetworkManager is truly dead, see what the available network devices are:

# ifconfig

or

# ip link show

Now you can set a static address and be assured that it will stick:

# ifconfig em1 192.168.111.1 netmask 255.255.255.0 up

or

# ip addr add 192.168.111.1/24 dev em1

# ip link set em1 up

There Is More Than One Way To Do It (TIMTOWDI).

Going back to Normal

When you need to check you email or do a search for information and you need to plug the machine back into a wall socket, you got to restart the network, or just restart Network Manager.

# systemctl restart network.service

or

# systemctl restart NetworkManager.service

Happy debugging!