Posts tagged ‘flash’

Raspberry Pi: Mudra: a Braille dicta-teacher

This post was syndicated from: Raspberry Pi and was written by: Liz Upton. Original post: at Raspberry Pi

Sanskriti Dawle and Aman Srivastav are second-year students at the Birla Institute of Technology and Science in Goa. After a Raspberry Pi workshop they decided they wanted to do something more meaningful than just flash LEDs on and off, and set this month’s PyCon in Montreal as their deadline.

team-mudra1

Aman Srivastav and Sanskriti Dawle

They ended up producing something really special. Mudra means “sign” in Sanskrit: the Raspberry Pi-based device is a learning tool for visually impaired people, which teaches Braille by translating speech to Braille symbols. Braille literacy among blind people is poor even in the developed world: in India, it’s extremely low, and braille teachers are very, very few. So automating the teaching process – especially in an open and inexpensive way like this – is invaluable.

In its learning mode, Mudra uses Google’s speech API to translate single letters and numbers into Braille, so learners can go at their own speed. Exam modes and auto modes are also available. This whole video is well worth your time, but if you’re anxious to see the device in action, fast-forward to 1:30.

Sanskriti and Aman say:

Mudra is an excellent example of what even programming newbies can achieve using Python. It is built on a Raspi to make it as out-of-the-box as possible. We have close to zero coding experience, yet Python has empowered us enough to make a social impact with Mudra, the braille dicta-teacher, which just might be the future of Braille instruction and learning.

We think Mudra’s a real achievement, and a great example of clean and simple ideas which can have exceptional impact. You can see the Mudra repository on GitHub if you’d like a nose around how things work; we’re hoping that Sanskriti and Aman are able to productise their idea and make it widely available to people all over the world.

Linux How-Tos and Linux Tutorials: The MarS DIY Platform for Around $100 (Without Screen)

This post was syndicated from: Linux How-Tos and Linux Tutorials and was written by: Ben Martin. Original post: at Linux How-Tos and Linux Tutorials

mars

The MarS single board computer is a solid, though more expensive, alternative to the BeagleBone Black and Raspberry Pi for your DIY hardware needs. At a minimum, it offers two headers, each with two columns of pin holes — perfect for just playing around. Another stand out feature is the touch screen kit which makes the MarS a great platform on which to build a custom tablet, for example.

At the heart of the MarS is a dual core Freescale i.MX6 Cortex-A9 with the Vivante GC2000 graphics processor. The board has 1 gigabyte (GB) of RAM and 4 GB of eMMC storage, many screen outputs including LVDS and HDMI, multiple USB 2.0 ports, gigabit LAN, and many other ways to interact through its headers like SPI. With the MarS kit, LVDS is a first class citizen, with a 9.7-inch LVDS multi-touch screen available.

We’ll take a look at the combination kit, which includes the MarS board with an additional 9.7-inch LCD that runs at 1024×768 and is capable of multi-touch input. The MarS itself goes for about $100 while the combination kit is around $290.

The 9.7-inch screen comes in what some might consider to be a tablet shell. The single LVDS cable is enough to provide both signal and power to the display. The multi-touch information is also sent back over the LVDS cable making it a single cable solution.

This might be a great combination for somebody who wants to build a custom tablet including a small board of chips that are accessed from the expansion headers of the MarS. Just add a battery and strap things to the back of the screen to build a rather thick, but custom and inclusive tablet! This leaves open the possibility of getting dual display on the LVDS and HDMI going at the same time so you can drive external screens as needed.

Android on the MarS

I took a look at what came already loaded onto the 4 GB of eMMC by connecting an HDMI screen, plugging in the MarS and letting it boot. This presented Android version 4.0.4 with a model number of ICS AOSP on imx6q. Turning things off, plugging in the external 9.7-inch touch screen, and powering on again I got a red light in the top right of the screen enclosure and some backlight but no signal. A power down and disconnect of the main HDMI didn’t magically move the primary Android display over to the external 9.7-inch toucscreen. You have to do a tiny bit of tinkering on the serial console to get the LVDS screen going with Android.

The mini USB port next to the network connector can be used to get a serial console to your MarS board. Hitting a key during the 3-second count down before boot, you can adjust the boot parameters. To get the 9.7-inch touch screen working you have to interrupt the boot procedure and run the below modification which I’ve mostly taken from the MarS user manual. There are seven different screen settings shown in the user manual for a few different external screen sizes (smaller LCDs and the 9.7-inch LVDS touch panel) and also HDMI. If you are running Android the manual also mentions support for running both an external screen and HDMI at the same time in a dual display mode. This setting is stored into persistent memory by the MarS, you can reset it to the default with the run clearenv command.

Board: MX6Q-MARSBOARD:[ WDOG]
Boot Device: I2C
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1
...
Net:   got MAC address from IIM: 00:00:00:00:00:00
----enet_board_init: phy reset
FEC0 [PRIME]
Hit any key to stop autoboot:  0 
MX6Q MARSBOARD U-Boot > setenv no_console_suspend 1
MX6Q MARSBOARD U-Boot > setenv bootargs console=ttymxc1,115200 init=/init
  rw video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 fbmem=10M vmalloc=400M
  androidboot.console=ttymxc1
MX6Q MARSBOARD U-Boot > saveenv
MX6Q MARSBOARD U-Boot > boot

The updated Android image is still version 4.0.4 of Android. Multitouch on the LVDS screen works as expected and zooming images in the gallery is nice and responsive. You will have to copy over any images for testing as the default Android distribution for the MarS is quite spartan.

With the MarS running Android, I plugged a USB cable into the OTG mini USB port on the MarS and the other end into a desktop Linux machine and I could then mount the MarS as a filesystem. So getting data to and from the MarS became fairly simple. Unfortunately, once the device goes into sleep mode I couldn’t work out how to bring it back to life other than using the reset button. While the screen has positions for some side buttons, without any hardware buttons I couldn’t think of a simple way to wake up stock Android again. There are apps for allowing wake up without hardware buttons of course.

Loading Linaro onto the MarS

The latest official release for the MarS is Linaro 11.10 (development branch).

Unfortunately the procedure for using a desktop Linux machine to update the MarS to a newer version of Android or changing the MarS over to Linaro isn’t shown in the MarS manuals. I used the mfgTool program to write the Linaro image to the flash on the MarS board. The tools are also available from Embest Tech. A word of caution here: If you were using the serial console to log in to the MarS you need to move the mini USB cable over to the OTG port (next to the HDMI port) in order to use mfgTool to update the MarS. I left the USB cable on the serial port and it took a while to work out this mistake.

To load an image, one of the jumpers (D2) on the MarS has to be switched to “On” and the board reset. After flashing, you need to reset that jumper back to “Off” and reset the MarS to boot into your new system. Refer to about page 30 of the User Manual for more information.

While there is nothing wrong with mfgTool, it would be nice to be able to flash the Linux image on the MarS from a desktop Linux machine.

Getting touchy under Linaro

Although the MarS documentation doesn’t mention support for running the LVDS under Linaro, I found that the above command which enabled the display on Android also enabled it on Linaro. Though at first I had no touch screen ability.

Digging around the git repository for the kernel used by the MarS I found the following commit:

commit 4006c19c6beda96a0bd5855a1ab27a7b2e380cb5
Author: luofuchong 
Date:   Thu Oct 24 15:10:09 2013 +0800
Add single touch support for LCD8000-97C using on ubuntu & emmc fix to mmcblk0.

Unfortunately the most recent Linux image for the MarS was from Sept. 17, 2013, so to test out single touch I had to compile and install a new kernel for the MarS. Hopefully a new Linux image will be released soon and you won’t be faced with having to do a kernel compile right off the bat to use the screen as a touch screen.

... The kernel version of the last updated images for the MarS.
$ uname -a
Linux linaro-ubuntu-desktop 3.0.15-01361-g6cd3d53-dirty #2 
SMP PREEMPT Wed Aug 28 13:42:52 CST 2013 armv7l armv7l armv7l GNU/Linux

The MarS user manual recommends setting up Ubuntu in a virtual machine and cross compiling your Linux kernel for the MarS. Since the MarS board is capable enough hardware to compile its own kernel I decided to compile on the MarS itself. I had to make the below links so that the compiler was found:

# ls -l /usr/bin/arm-fsl*
lrwxrwxrwx 1 root root 2 2014-03-27 23:55 /usr/bin/arm-fsl-linux-gnueabi-ar -> ar
lrwxrwxrwx 1 root root 3 2014-03-27 23:52 /usr/bin/arm-fsl-linux-gnueabi-gcc -> gcc
lrwxrwxrwx 1 root root 2 2014-03-27 23:54 /usr/bin/arm-fsl-linux-gnueabi-ld -> ld
lrwxrwxrwx 1 root root 2 2014-03-28 01:17 /usr/bin/arm-fsl-linux-gnueabi-nm -> nm
lrwxrwxrwx 1 root root 7 2014-03-28 01:06 /usr/bin/arm-fsl-linux-gnueabi-objcopy -> objcopy
lrwxrwxrwx 1 root root 7 2014-03-27 23:54 /usr/bin/arm-fsl-linux-gnueabi-objdump -> objdump

Then the below commands will grab the latest kernel from the same branch as the one that was already running. That kernel also happens to contain the touch interface update. It does take a long time, on the order of easily over an hour to compile the kernel, so if you are doing development on the kernel then the cross compile environment would likely be the way to go.

$ git clone https://github.com/embest-tech/linux-imx.git
$ cd ./linux-imx
$ git checkout embest_imx_3.0.15_12.04.01
$ make imx6_defconfig
$ make KALLSYMS_EXTRA_PASS=1 uImage
...
  Image arch/arm/boot/uImage is ready
$ ls -l arch/arm/boot/uImage
-rw-rw-r-- 1 ben ben 3645672 2014-03-28 01:24 arch/arm/boot/uImage

Although there is an uImage file in /boot that is not the kernel that the MarS is using. If you look at the partition table for the 4 GB of flash on the MarS you will see that there is a gap left before the only partition. That gap is where the boot loader and currently running Linux kernel are loaded from.

root@linaro-ubuntu-desktop:~# fdisk -l /dev/mmcblk0
        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1           20480     7798783     3889152   83  Linux

Watching the boot up procedure on a serial terminal you can see the exact location from which the U-Boot bootloader loaded the Linux kernel. The following dd command will grab the current Linux kernel from the flash memory and use od to display it in a more human readable format. Notice that starting at byte 32 (40 octal) the Linux kernel version is stored.

root@linaro-ubuntu-desktop:/tmp# dd if=/dev/mmcblk0 of=test bs=1024 count=10000 skip=1024
10000+0 records in
10000+0 records out
10240000 bytes (10 MB) copied, 0.319027 s, 32.1 MB/s
root@linaro-ubuntu-desktop:/tmp# od -t c test > test.od
^c
root@linaro-ubuntu-desktop:/tmp# vi test.od
...
0000040   L   i   n   u   x   -   3   .   0   .   1   5   -   0   1   3
0000060   6   1   -   g   6   c   d   3   d   5   3   -   d   i   r   t

I ran the below command to copy my updated /boot/uImage to the on board flash at the location that U-Boot expected it to be stored. Of course I took a good back up of the whole start to mmcblk0 first and then ran the above command to verify that the new “L i n u x” and so on version string appeared at the expected location with the expected value. Make sure you have a backup and recovery plan before playing with fixed offsets and dd like this. I wasn’t sure what state my MarS would be in after I ran the command, and was prepared to reuse mfgTool to reflash the MarS and try again.

# dd if=/boot/uImage of=/dev/mmcblk0 bs=1024 seek=1024

After a reboot I was running my updated kernel and had single touch working on the screen. I had also updated the X Server a little bit, too, in preparation for touch using the below commands.

$ uname -a
Linux linaro-ubuntu-desktop 3.0.15-01365-ge16f9b9 #1 
SMP PREEMPT Fri Mar 28 01:17:29 UTC 2014 armv7l armv7l armv7l GNU/Linux
# apt-get remove xserver-xorg-input-synaptics
# apt-get install xserver-xorg-input-tslib  libts-bin 

There is one downside to doing single touch on Linux this way, when you press down and move your finger it is equivalent to holding down a mouse button and dragging the mouse around. So if you are used to scrolling a web browser on a tablet for example, then you will be a little surprised when you start selecting text in Firefox using the single touch interface. I suspect this can be worked around for the browser by an extension but the same unexpected (non scrolling) behavior will be waiting in other applications. You’ll probably want to set up a soft keyboard under Linaro as well so you can type on the screen. On the other hand the single touch should work well for custom QtQuick user interfaces.

Hardware Interaction

Running Linux on the MarS board exposes the GPIO pins using the /sys/class/gpio directory. This is the same method I have shown in a previous article on the BeagleBone Black. Likewise, interrupts on GPIO pins should also work the same way as on the BeagleBone Black. There are also three TWI device files created in /dev, though I am still working out how to make a /dev/spi appear.

root@linaro-ubuntu-desktop:~# ls -l /sys/class/gpio/
total 0
--w------- 1 root root 4096 1970-01-01 01:09 export
lrwxrwxrwx 1 root root    0 1970-01-01 01:09 gpiochip0 -> ../../devices/virtual/gpio/gpiochip0
lrwxrwxrwx 1 root root    0 1970-01-01 01:09 gpiochip128 -> ../../devices/virtual/gpio/gpiochip128
lrwxrwxrwx 1 root root    0 1970-01-01 01:09 gpiochip160 -> ../../devices/virtual/gpio/gpiochip160
lrwxrwxrwx 1 root root    0 1970-01-01 01:09 gpiochip192 -> ../../devices/virtual/gpio/gpiochip192
lrwxrwxrwx 1 root root    0 1970-01-01 01:09 gpiochip32 -> ../../devices/virtual/gpio/gpiochip32
lrwxrwxrwx 1 root root    0 1970-01-01 01:09 gpiochip64 -> ../../devices/virtual/gpio/gpiochip64
lrwxrwxrwx 1 root root    0 1970-01-01 01:09 gpiochip96 -> ../../devices/virtual/gpio/gpiochip96
--w------- 1 root root 4096 1970-01-01 01:09 unexport

Performance

Bonnie wants to create files which are twice the size of the available memory on the system to avoid disk caches from interfering with the benchmark. The MarS has 1 GB of RAM and I didn’t have a full 2 GB of storage free so I decided to limit the size of the files to a few hundred megabytes. The command is shown below and is the same command used to test the flash storage on the BeagleBone Black.

user@mars:~/test$ /sbin/bonnie++ -f -m mars -s 200 -r 100 -d `pwd` 

The MarS got 4.7 megabyte/ second (MB/s) for output and 3.5 MB/s for rewrite. In contrast the BeagleBone Black got 4.2 MB/s and 4.5 MB/s respectively and the ODroid-U2 quad core ARM got 16 MB/s and 12 MB/s respectively. I was a bit surprised by the performance on the MarS as it feels like a fairly fast machine; after running bonnie the MarS was using 150 MB for disk cache. Perhaps the 1 GB of RAM allowed more overall disk cache than some machines and helped with the perceived speed of the MarS board.

To test 2d graphics performance I used version 1.0.1 of the Cairo Performance Demos. The gears test runs three turning gears; the chart runs four line graphs; the fish is a simulated fish tank with many fish swimming around; gradient is a filled curved edged path that moves around the screen; and flowers renders rotating flowers that move up and down the screen. For comparison I used a desktop machine running an Intel 2600K CPU with an NVidia GTX 570 card which drives two screens, one at 2560×1440 and the other at 1080p. It is interesting that the MarS was so much faster on the gradient but considerably slower on the fish demo.

           BBB fps    Mars fps       desktop 2600k/nv570
           at 720p    LVDS at        two screens.
                         1024x768
  
gears 26 18 140 chart 2 2 16 fish 4 0.3 188 gradient 10 17 117 flowers 1 2 170

The Octane 2.0 Javascript benchmark measures how well your Web browser performs various tasks. I used Firefox version 20.0+build1-0ubuntu0.11.10.3 that came with the updates to the Linaro for the MarS to run Octane, giving 930 for Splay, 60 for Regexp, 1011 for pdf.js. Unfortunately the test slowed to a crawl during Box2DWeb so the overall figure is not available. To contrast, the BeagleBone Black got 827, 88, and 401 respectively for Splay, Regexp, and pdf.js.

Power Usage

With the 9.7-inch LVDS touch panel connected and sitting at an idle Linaro desktop, the MarS consumed around 5.4 Watts (W). Running a two parallel task build on openssl 1.0.1e ranged up to 7.7 W of power. When the 9.7-inch screen goes to sleep but the MarS is still running power drops to 3.3 W. Running glxgears with the screen on used 8.9 W, so the 3D stuff was using 4.5 W all by itself.

With the power draw for OpenGL I used a Scythe USB temperature sensor to see how the chip was doing. The table near the MarS measured 32.4 C. After running glxgears for a while I measured 62 C on the CPU. Looking around for temperature monitors on the MarS itself, I found the file /sys/devices/virtual/thermal/thermal_zone0/temp which also crept up to 61 when running glxgears.

Wrap up

The dual core MarS board offers 1 GB of RAM, a large enough on-board flash to still have over a gigabyte free after Linaro is installed, and a bunch of headers to play with. The LVDS screen works well once the software is set up. The main remaining issue is how to set up multitouch input under Linux. The network connection being at gigabit speed may also make the MarS the right choice if you need a fast network connection. The MarS also has a nicer CPU (dual core) and memory specification (1 GB) relative to the BeagleBone Black and Raspberry Pi. Of course, the MarS board is more expensive than the BeagleBone Black and Raspberry Pi as well.

Given that the location of the Linux kernel is known and the only other filesystem contains the Linaro installation, it will be interesting to see what other and newer Linux installations can be made for the MarS. I’m still tinkering with getting a Linux desktop across both the the LVDS and HDMI screens.

We would like to thank element14 for providing review hardware for this article.

LWN.net: Raspberry Pi Foundation announces a new, small-and-modular form factor

This post was syndicated from: LWN.net and was written by: n8willis. Original post: at LWN.net

The Raspberry Pi Foundation has announced a forthcoming addition to the Pi lineup, the “Pi Compute Module,” which is “a Raspberry Pi shrunk down to fit on a SODIMM with onboard memory, whose connectors you can customise for your own needs.” The form factor is intended for those who are going to create their own boards on which to attach the module, although there will be a breakout board designed by the Foundation as well. The module includes the same System-on-Chip as the original Pi and the same eMMC flash storage module; in addition the SODIMM connector will apparently expose more pins than the credit-card form factor, so that “the full flexibility of the BCM2835 SoC (which means that many more GPIOs and interfaces are available as compared to the Raspberry Pi).” The expected release date is sometime in June.

Krebs on Security: Adobe, Microsoft Push Critical Fixes

This post was syndicated from: Krebs on Security and was written by: BrianKrebs. Original post: at Krebs on Security

Adobe and Microsoft each issued updates to fix critical security vulnerabilities in their software today. Adobe patched its Flash Player software and Adobe AIR. Microsoft issued four updates to address at least 11 unique security flaws, including its final batch of fixes for Office 2003 and for systems powered by Windows XP.

crackedwinTwo of the four patches that Microsoft issued come with Redmond’s “critical” rating (its most severe), meaning attackers or malware can exploit the flaws to break into vulnerable systems without any help from users. One of the critical patches is a cumulative update for Internet Explorer (MS14-018); the other addresses serious issues with Microsoft Word and Office Web apps (MS14-017), including a fix for a zero-day vulnerability that is already being actively exploited. More information on these and other patches are available here.

As expected, Microsoft also used today’s patch release to pitch XP users on upgrading to a newer version of Windows, warning that attackers will begin to zero in on XP users even more now that Microsoft will no longer be issuing security updates for the 13-year-old operating system. From Microsoft’s Technet blog:

“From the year that Windows XP was built, cyber attacks have increased in sophistication.  Systems receiving regular updates get the protections they need based on the latest cyber threats.  But at some point an older model of any product will lack the capability to keep up and becomes antiquated.  Obsolescence for Windows XP is just around the corner.

Cybercriminals will work to take advantage of businesses and people running software that no longer has updates available to repair issues.  Over time, attackers will evolve their malicious software, malicious websites, and phishing attacks to take advantage of any  newly discovered vulnerabilities in Windows XP, which post April 8th, will no longer be fixed.”

Microsoft offers free a Windows XP data transfer tool to ease the hassle of upgrading to a newer version of Windows. I would submit that if your PC runs XP and came with XP installed, that it might be time to upgrade the computer hardware itself in addition to the software. In any case, beyond this month is not the greatest idea, and it’s time for XP users to consider other options. Don’t forget that there are many flavors of Linux that will run quite happily on older hardware. If you’ve been considering the switch for a while, take a few distributions for a spin using one of dozens of flavors of Linux available via Live CD.

ADOBE

Adobe fixed at least four vulnerabilities in Flash, all of them critical. The company says it is not aware of any exploits in the wild against the flaws. The latest version is v. 13.0.0.182 for Windows, Mac and Linux systems. The Adobe advisory for the Flash update is here.

This link will tell you which version of Flash your browser has installed. IE10/IE11 for Windows 8.0/8.1 and Chrome should auto-update their versions of Flash. If your version of Flash on Chrome (on either Windows, Mac or Linux) is not yet updated, you may just need to close and restart the browser. The version of Chrome that includes this fix is 34.0.1847.116 for Windows, Mac, and Linux (to learn what version of Chrome you have, click the stacked bars to the right at of the address bar, and select “About Google Chrome” from the drop down menu).

The most recent versions of Flash are available from the Adobe download center, but beware potentially unwanted add-ons, like McAfee Security Scan). To avoid this, uncheck the pre-checked box before downloading, or grab your OS-specific Flash download from here. Windows users who browse the Web with anything other than Internet Explorer will need to apply this patch twice, once with IE and again using the alternative browser (Firefox, Opera, e.g.).

If you use Adobe AIR (required by some desktop software products such as Pandora, e.g.,), you’ll need to make sure that’s updated as well. AIR usually does a good job of checking for new versions on startup. If you’re not sure whether you have AIR installed or what version it’s at, see these directions. The latest version is 13.0.0.83, and is available for manual download here.

flash13-0-0-182

SANS Internet Storm Center, InfoCON: yellow: Security Updates available for Adobe Flash Player – http://helpx.adobe.com/security/products/flash-player/apsb14-09.html, (Tue, Apr 8th)

This post was syndicated from: SANS Internet Storm Center, InfoCON: yellow and was written by: SANS Internet Storm Center, InfoCON: yellow. Original post: at SANS Internet Storm Center, InfoCON: yellow

– Rick Wanner – rwanner at isc dot sans dot org – http://namedeplume.blogspot.com/ – Twitter:namedeplume (Protected)

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Linux How-Tos and Linux Tutorials: How to Create an LTSI Kernel Package for Raspberry Pi and MinnowBoard

This post was syndicated from: Linux How-Tos and Linux Tutorials and was written by: Hashimoto. Original post: at Linux How-Tos and Linux Tutorials

raspberry-piPreviously, in a tutorial titled How to Install the LTSI-3.10 Kernel on Raspberry Pi and MinnowBoard, I introduced how you can build and install a kernel with an LTSI (Long Term Support Initiative) patch applied on Raspberry Pi and MinnowBoard. That time, I installed a kernel image that I built by downloading the kernel source and applying the patch. This time, however, I created a package for easier management. The following describes how you can do that. Most of the steps are actually a repetition of what we did previously, so this time it’ll be quicker. This time, though, I worked on an actual machine in both cases, so it does take some time to compile the kernel.

1. Creating a Kernel Package on Raspberry Pi

For the operating system, I used Raspbian. Since this is based on Debian, the steps to create a kernel package are the same as on Debian. First, obtain the kernel source using the same steps as the last time.

Go to the GitHub page for the Raspberry Pi kernel, and press the Download ZIP button you’ll find toward the bottom right. Then, a kernel source file named linux-rpi-3.10.y.zip will be downloaded. Unpack the file in a suitable location. I unpacked it under /usr/local/src.

root@raspberrypi:/usr/local/src $ gunzip linux-rpi-3.10.y.zip

The version I downloaded was an RPi kernel based on 3.10.33. Next, download the LTSI patch from http://ltsi.linuxfoundation.org/.The version I downloaded was patch-3.10.31-LTSI.gz. Apply this patch to the kernel you downloaded earlier.

root@raspberrypi:/usr/local/src $ cd /usr/local/src/linux-rpi-3.10.y
root@raspberrypi:/usr/local/src/linux-rpi-3.10.y $ gunzip < /usr/local/src/patch-3.10.31-ltsi.gz | patch -p1

A Makefile.rej will be created because the source versions do not match (3.10.31 and 3.10.33). Since the only change is the version information, go ahead and edit the Makefile yourself.

SUBLEVEL = 33
EXTRAVERSION = -ltsi

Next, prepare a .config file. Use the one that is currently executed.

root@raspberrypi:/usr/local/src/linux-rpi-3.10.y $ cat /proc/config.gz | gunzip > .config 
root@raspberrypi:/usr/local/src/linux-rpi-3.10.y $ make oldconfig

The question you get asked with make oldconfig is a new parameter that is not in the version that is being executed, so go with the default settings for now. If you wish to change other parameters, you can do that with the following command.:

root@raspberrypi:/usr/local/src/linux-rpi-3.10.y $ make menuconfig

Now, we’re ready to start creating a kernel package. First, prepare the tools you need to create a package.

root@raspberrypi:/usr/local/src $ apt-get install build-essential kernel-package libncurses5-dev bc

Let’s get it started.

root@raspberrypi:/usr/local/src/linux-rpi-3.10.y $ make-kpkg clean
root@raspberrypi:/usr/local/src/linux-rpi-3.10.y $ make-kpkg --revision 1.0 --initrd kernel-image kernel-headers kernel-source

This will probably take much longer than a coffee break, so go ahead and take a nap. If you wish to run it in the background, do the following.

root@raspberrypi:/usr/local/src/linux-rpi-3.10.y $ nohup make-kpkg --revision 1.0 --initrd kernel-image kernel-headers kernel-source 2>&1 > /tmp/log.txt &

This should keep it running even after you’ve logged out. When you get up in the morning, you should find the following package under /usr/local/src.

root@raspberrypi:/usr/local/src $ ls
linux-headers-3.10.33-ltsi_1.0_armhf.deb
linux-rpi-3.10.y.tgz 
linux-image-3.10.33-ltsi_1.0_armhf.deb 
linux-source-3.10.33-ltsi_1.0_all.deb
linux-rpi-3.10.y 
patch-3.10.31-ltsi.gz 

(The reason you’re seeing linux-rpi-3.10.y.tgz here is that, for some reason, the zip file could not be unpacked properly on Raspberry Pi. So I unpacked it on another machine, created a tgz file, and then put it back to Raspberry Pi. I hope it works on your Raspberry Pi.) Now, let’s install. 

root@raspberrypi:/usr/local/src $ dpkg -i *.deb

You’ll see a lot of messages, but there shouldn’t be any problem. A kernel boot image will be created under /boot. You’ll need to change its name.

root@raspberrypi:/boot# ls -l
Total 24160
-rwxr-xr-x 1 root root 18974 Sep 26 06:57 LICENSE.oracle
-rwxr-xr-x 1 root root 1433275 Mar 22 09:38 System.map-3.10.33-ltsi
-rwxr-xr-x 1 root root 17824 Jan 8 04:50 bootcode.bin
-rwxr-xr-x 1 root root 142 Jan 8 06:13 cmdline.txt
-rwxr-xr-x 1 root root 87181 Mar 22 08:41 config-3.10.33-ltsi
-rwxr-xr-x 1 root root 1237 Feb 3 23:21 config.txt
-rwxr-xr-x 1 root root 5783 Jan 8 04:50 fixup.dat
-rwxr-xr-x 1 root root 2068 Jan 8 04:50 fixup_cd.dat
-rwxr-xr-x 1 root root 8829 Jan 8 04:50 fixup_x.dat
-rwxr-xr-x 1 root root 3700976 Jan 22 11:16 initrd.img-3.10.33-ltsi
-rwxr-xr-x 1 root root 137 Jan 8 08:34 issue.txt
-rwxr-xr-x 1 root root 9789752 Jan 8 04:50 kernel_emergency.img
-rwxr-xr-x 1 root root 2514136 Jan 8 04:50 start.elf
-rwxr-xr-x 1 root root 480216 Jan 8 04:50 start_cd.elf
-rwxr-xr-x 1 root root 3495816 Jan 8 04:50 start_x.elf
-rwxr-xr-x 1 root root 3112072 Jan 22 15:58 vmlinuz-3.10.33-ltsi
root@raspberrypi:/boot# mv kernel.img kernel.org
root@raspberrypi:/boot# mv vmlinuz-3.10.33-ltsi kernel.img

 To be safe, perform sync and reboot.

root@raspberrypi:/boot# sync 
root@raspberrypi:/boot# reboot

After reboot, connect and check.

root@raspberrypi:/boot# uname -a
Linux raspberrypi 3.10.33-ltsi #3 PREEMPT Sat Mar 22 08:49:28 JST 2014 armv6l
GNU/Linux

Well, that’s it. This package is posted on http://ltsi.linuxfoundation.org/downloads, so if you need it, feel free to take it. But no guarantees.

2. Creating a Kernel Package on MinnowBoard

The distribution stored in the SD card that comes with MinnowBoard is Angstrom. As I confessed the last time, I’m not an expert on Angstrom nor Yocto, so I used Debian. I set up Debian on MinnowBoard on a USB flash drive following the Minnowboard:Debian Bare Minimum Bootstrapping steps I will describe below. While it says Minimum, it’s still Debian, so the steps to create a kernel package are the same as on Debian.

First, obtain the kernel source using the same steps as the previous tutorial. Obtain the same source version as the LTSI on Kernel.org. Here, I downloaded linux-3.10.31.tgz. In my case, I needed 8GB of storage in order to build a kernel package. So I prepared a USB flash drive specifically for the build other than for Debian itself. Mount a USB flash drive for the build in a desired location. I mounted it under /mnt and extracted the kernel source. 

root@DebianMinnow:/ $ mount /dev/sdb1 /mnt 
root@DebianMinnow:/$ cd /mnt
root@DebianMinnow:/mnt $ tar xvzf /tmp/linux-3.10.31.tgz

Next, download the LTSI patch from http://ltsi.linuxfoundation.org/.The version I downloaded was patch-3.10.31-LTSI.gz. Apply this patch to the kernel you downloaded earlier.

root@DebianMinnow:/mnt $ gunzip < /tmp/patch-3.10.31-ltsi.gz | patch -p1

Next, prepare a .config file. Use the one that is currently executed. 

root@DebianMinnow:/mnt $ cp /boot/config-3.13-1-686-pae > .config 
root@DebianMinnow:/mnt $ make oldconfig

The question you get asked with make oldconfig is a new parameter that was not in the version that was being executed, so go with the default settings for now. If you wish to change other parameters, you can do that with the following command:

root@DebianMinnow:/mnt $ make menuconfig

Now, we’re ready to start creating a kernel package. Prepare the tools you need to create a package.

root@DebianMinnow:/mnt $ apt-get install build-essential kernel-package libncurses5-dev bc

Let’s get it started.

root@DebianMinnow:/mnt $ make-kpkg clean 
root@DebianMinnow:/mnt $ make-kpkg --revision 1.0 --initrd kernel-image kernel-headers kernel-source

Again, this will probably take much longer than a coffee break, so go ahead and take a nap. But it should be faster than Raspberry Pi. If you wish to run it in the background, do the following:

root@DebianMinnow:/mnt $ nohup make-kpkg –revision 1.0 –initrd kernel-image kernel-headers kernel-source 2>&1 > /tmp/log.txt &

This should keep it running even after you’ve logged out. When you get up in the morning, you should find the following package under /mnt.

root@DebianMinnow:/mnt $ ls 
linux-3.10.33
linux-headers-3.10.33-ltsi_1.0_i386.deb
linux-image-3.10.33-ltsi_1.0_i386.deb
linux-source-3.10.33-ltsi_1.0_all.deb
patch-3.10.31-ltsi.gz

Now, let’s install.

root@DebianMinnow:/mnt $ dpkg -i *.deb

You’ll see a lot of messages, but there shouldn’t be any problem. A kernel boot image will be created under /boot. 

root@DebianMinnow:/boot# ls -l 
Total 33180
-rw-r--r-- 1 root root 1764023 Mar 23 22:00 System.map-3.10.31-ltsi
-rw-r--r-- 1 root root 1842504 Mar 6 01:27 System.map-3.13-1-686-pae
-rw-r--r-- 1 root root 149556 Mar 23 17:07 config-3.10.31-ltsi
-rw-r--r-- 1 root root 155052 Mar 6 01:27 config-3.13-1-686-pae drwxr-xr-x 2 root root 4096 Mar 18 18:15 grub
-rw-r--r-- 1 root root 12166605 Jan 1 2001 initrd.img-3.10.31-ltsi
-rw-r--r-- 1 root root 12456051 Jan 1 2001 initrd.img-3.13-1-686-pae
-rw-r--r-- 1 root root 2631440 Mar 23 22:00 vmlinuz-3.10.31-ltsi
-rw-r--r-- 1 root root 2735776 Mar 6 01:26 vmlinuz-3.13-1-686-pae

Back up the vmlinuz (symbolic link to /boot/vmlinuz-3.13-1-686-pae) under /, and create a new vmlinuz (symbolic link to /boot/vmlinuz-3.10.31-ltsi). 

root@DebianMinnow:/# mv vmlinuz vmlinuz.org 
root@DebianMinnow:/# ln -s boot/vmlinuz-3.10.31-ltsi vmlinuz
root@DebianMinnow:/# ls -l vmlinuz*
lrwxrwxrwx 1 root root 25 Jan 1 2001 vmlinuz -> boot/vmlinuz-3.10.31-ltsi
lrwxrwxrwx 1 root root 27 Mar 18 17:56 vmlinuz.org -> boot/vmlinuz-3.13-1-686-pae

Although the new OS should start up when rebooted as-is, rewrite grub.conf so that the old OS can be selected.

root@DebianMinnow:/# mount /dev/sda1 /efi 
root@DebianMinnow:/# cd /efi/EFI/BOOT  

 Edit the grub.conf under here. I will show only the relevant portion.

#For MBR
menuentry "Debian 7.0 i686 (32-bit, EFI/MBR)" {
insmod part_msdos
insmod ext2
set root='(hd0,msdos2)'
linux /vmlinuz.org root=/dev/sda2 ro rootwait console=ttyPCH0,115200 console=tty0 vmalloc=256MB snd-hda-intel.enable_msi=0
initrd /initrd.img.org }

Copy the above, and add an entry for vmlinuz.org.

#For MBR(LTSI) 
menuentry "Debian 7.0 i686-ltsi (32-bit, EFI/MBR)" {
insmod part_msdos
insmod ext2
set root='(hd0,msdos2)'
linux /vmlinuz root=/dev/sda2 ro rootwait console=ttyPCH0,115200 console=tty0 vmalloc=256MB snd-hda-intel.enable_msi=0
initrd /initrd.img
}
#For MBR 
menuentry "Debian 7.0 i686 (32-bit, EFI/MBR)" {
insmod part_msdos
insmod ext2
set root='(hd0,msdos2)'
linux /vmlinuz.org root=/dev/sda2 ro rootwait console=ttyPCH0,115200 console=tty0 vmalloc=256MB snd-hda-intel.enable_msi=0
initrd /initrd.img.org
}

Once edited, save and then sync the file, and reboot.

root@DebianMinnow:/# umount /dev/sda1 
root@DebianMinnow:/#sync
root@DebianMinnow:/#reboot

After reboot, connect and check.

root@DebianMinnow:/boot# uname -a
Linux DebianMinnow 3.10.31-ltsi #4 SMP Sun Mar 23 17:18:20 JST 2014 i686 GNU/Linux

Well, that’s it. This package is posted on http://ltsi.linuxfoundation.org/downloads, so if you need it, feel free to take it. But no guarantees.

3. For those Who Wish to Execute in a Cross-build Environment

Although I built the kernel on an actual machine this time, you may want to execute in a cross-build environment due to time or storage capacity reasons. It’s easy if you’re using MinnowBoard. Since the machine is Atom, you should be able to build the kernel and create a package as-is in a cross-build environment as well. In the case of Raspberry Pi, build a cross-build environment as explained in the previous tutorial, and then configure make-kpkg options. Since I haven’t tried it myself, I will not be able to describe the steps in detail. Go ahead and give it a try.

 Hisashi Hashimoto is a Senior Engineer at Hitachi.

Raspberry Pi: Raspberry Pi Compute Module: new product!

This post was syndicated from: Raspberry Pi and was written by: James Adams. Original post: at Raspberry Pi

As regular readers will know, it’s been a busy time here at Pi Towers recently with the launch of our new website, free educational materials and £1m education fund.

On the engineering side of things we’ve also been very busy over the past year, and not to be outdone by the education team, we are ready to take the wraps off something special, this time aimed at business and industrial users.

What's this little thing? Read on to find out.

What’s this little thing? Read on to find out.

From humble beginnings, the Raspberry Pi platform has grown and matured: the software is now full-featured and stable, and is still constantly improving thanks to the continuing hard work of our heroic community of volunteers; as well as targeted injections of funding to solve some specific issues. The Pi, and the Broadcom BCM2835 SoC at its heart, are also steadily becoming more open.

We love hearing about what users are doing with their Raspberry Pis, and are constantly amazed at the range of projects, as well as the inventiveness and creativeness of the community. We are also aware that there are a very significant number of users out there who are embedding the Raspberry Pi into systems and even commercial products. We think there needs to be a better way to allow people to get their hands on this great technology in a more flexible form factor, but still keep things at a sensible price.

Like proud parents, we want to free the core technology of the Raspberry Pi to go forth and become an integral part of new and exciting products and devices, and so today we are announcing the forthcoming Raspberry Pi Compute Module.

CM_and_pi-small

Compute Module on the left. What does it do? Read on to find out.

The compute module contains the guts of a Raspberry Pi (the BCM2835 processor and 512Mbyte of RAM) as well as a 4Gbyte eMMC Flash device (which is the equivalent of the SD card in the Pi). This is all integrated on to a small 67.6x30mm board which fits into a standard DDR2 SODIMM connector (the same type of connector as used for laptop memory*). The Flash memory is connected directly to the processor on the board, but the remaining processor interfaces are available to the user via the connector pins. You get the full flexibility of the BCM2835 SoC (which means that many more GPIOs and interfaces are available as compared to the Raspberry Pi), and designing the module into a custom system should be relatively straightforward as we’ve put all the tricky bits onto the module itself.

So what you are seeing here is a Raspberry Pi shrunk down to fit on a SODIMM with onboard memory, whose connectors you can customise for your own needs.

The Compute Module is primarily designed for those who are going to create their own PCB. However, we are also launching something called the Compute Module IO Board to help designers get started.

Empty IO board on the left: Compute Module snapped into place on the right.

Empty IO Board on the left: Compute Module snapped into place on the right.

The Compute Module IO Board is a simple, open-source breakout board that you can plug a Compute Module into. It provides the necessary power to the module, and gives you the ability to program the module’s Flash memory, access the processor interfaces in a slightly more friendly fashion (pin headers and flexi connectors, much like the Pi) and provides the necessary HDMI and USB connectors so that you have an entire system that can boot Raspbian (or the OS of your choice). This board provides both a starting template for those who want to design with the Compute Module, and a quick way to start experimenting with the hardware and building and testing a system before going to the expense of fabricating a custom board.

IO Board

IO Board

Initially, the Compute Module and IO Board will be available to buy together as the Raspberry Pi Compute Module Development Kit.

These kits will be available from RS and element14 some time in June. Shortly after that the Compute Module will be available to buy separately, with a unit cost of around $30 in batches of 100; you will also be able to buy them individually, but the price will be slightly higher. The Raspberry Pi Foundation is a charity, and as with everything we make here, all profits are pushed straight back into educating kids in computing.

I’m sure people will be keen to get their design process started; initially we are releasing just the schematics for both the Compute Module and IO Board, but we will be adding plenty more documentation over the coming days and weeks.

Happy creating!

*But don’t go plugging the Compute Module into your laptop – the pins assignments aren’t even remotely the same!

Krebs on Security: Adobe, Microsoft Push Security Updates

This post was syndicated from: Krebs on Security and was written by: BrianKrebs. Original post: at Krebs on Security

Adobe and Microsoft today each released software updates to fix serious security flaws in their products. Adobe pushed an update that plugs a pair of holes in its Flash Player software. Microsoft issued five updates, including one that addresses a zero-day vulnerability in Internet Explorer that attackers have been exploiting of late.

crackedwinMicrosoft’s five bulletins address 23 distinct security weaknesses in Microsoft Windows, Internet Explorer and Silverlight. The Internet Explorer patch is rated critical for virtually all supported versions of IE, and plugs at least 18 security holes, including a severe weakness in IE 9 and 10 that is already being exploited in targeted attacks.

Microsoft notes that the exploits targeting the IE bug seen so far appear to perform a check for the presence of Microsoft’s Enhanced Mitigation Experience Toolkit (EMET); according to Microsoft, the exploits fail to proceed if EMET is detected. I’ve recommended EMET on several occasions, and would encourage any Windows users who haven’t yet deployed this tool to spend a few minutes reading this post and consider taking advantage of it to further harden their systems. The latest version — 4.1 — is available at this link and requires Microsoft’s .NET Framework 4 platform. For those of you who don’t mind beta-testing software, Microsoft has released a preview version of the next generation of EMET — EMET 5.0 Technical Preview.

This month’s updates include a fix for another dangerous bug – deep within the operating system on just about every major version of Windows  – that also was publicly disclosed prior to today’s patches. Microsoft’s Technet Blog has more details on these and other bulletins released today.

Readers still using Windows XP should remember that after next month, Microsoft will stop releasing security updates for that version of Windows. Microsoft recently announced that it will make available for free a Windows XP data transfer tool to ease the hassle of upgrading to a newer version of Windows. I would submit that if your PC runs XP and came with XP installed, that it might be time to upgrade the computer hardware itself.

In any case, using Windows XP beyond next month is not the greatest idea, and it’s time for XP users to consider other options. Don’t forget that there are many flavors of Linux that will run quite happily on older hardware. If you’ve been considering the switch for a while, take a few distributions for a spin using one of dozens of flavors of Linux available via Live CD.

FLASH UPDATE

brokenflash-aAdobe’s Flash update brings the media player to  v. 12.0.0.77 on Windows and Mac OS X.  This link will tell you which version of Flash your browser has installed. IE10 and Chrome should auto-update their versions of Flash. If your version of Chrome (on either Windows, Mac or Linux) is not yet updated to v. 12.0.0.77you may just need to close and restart the browser.

The most recent versions of Flash are available from the Adobe download center, but beware potentially unwanted add-ons, like McAfee Security Scan). To avoid this, uncheck the pre-checked box before downloading, or grab your OS-specific Flash download from here. Windows users who browse the Web with anything other than Internet Explorer will need to apply this patch twice, once with IE and again using the alternative browser (FirefoxOpera, e.g.). Adobe does not appear to have released any updates for AIR as it often does when pushing new Flash patches.

As always, please drop a note in the comments section if you experience any issues with the updates released today.

adobeupdate3-14

SANS Internet Storm Center, InfoCON: green: Adobe Updates: Flash Player, (Tue, Mar 11th)

This post was syndicated from: SANS Internet Storm Center, InfoCON: green and was written by: SANS Internet Storm Center, InfoCON: green. Original post: at SANS Internet Storm Center, InfoCON: green

Adobe released a new version of Flash Player as part of today's patch Tuesday. No details are available yet. We will update this diary once the details become available. Note that this will also affect browsers like Chrome that include an embeded version of Flash.

 

——
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Linux How-Tos and Linux Tutorials: BeagleBone Black: How to Get Interrupts Through Linux GPIO

This post was syndicated from: Linux How-Tos and Linux Tutorials and was written by: Ben Martin. Original post: at Linux How-Tos and Linux Tutorials

The BeagleBone Black is a small 1Ghz ARM machine with 512Mb of RAM, 2Gb of on board flash memory, and most importantly two headers each with two rows of pin sockets ready for your next embedded project. At around $45 the BeagleBone Black costs around twice what an Arduino board might set you back. For some projects the 32kb of storage space and kilobytes of SRAM offered by the Arduino might be sufficient. If you want to use 100Mb of RAM while talking to other hardware then something like the BeagleBone Black might be the perfect fit.

bbb-trackballA previous article looked at the differences between the Arduino and the BeagleBone Black in how you go about accessing chips over the SPI. This time around the focus will be on how to receive interrupts from your hardware on the BeagleBone Black.

The header pins on each side of the BeagleBone Black can be used for General Purpose I/O (GPIO). This way you can set the voltage to high or low, or if you are reading you can see if the voltage is currently high or low on the pin. Generally, high might be 3.3 volts and low would be the common ground voltage. The GPIO support in Linux can optionally generate interrupts when the signal raises from ground to a high voltage, from the high voltage to ground, or if either of these cases occurs.

Expose the Pins 

As I covered in “Getting Started with the BeagleBone Black” access to the various pins in the headers on the left and right side of the BBB is done through the Linux kernel using its GPIO Interfaces.

The below code exposes pin 42 (GPIO_7) through the Linux kernel and reads the current value of that pin. First you have to map the GPIO_7 pin into the filesystem. This is done by echoing the GPIO pin into the export file. As you can see, below, I created the new gpio7 link using the export file in order to read that pin.

root@bbb:/sys/class/gpio# echo 7 > /sys/class/gpio/export
root@bbb:/sys/class/gpio# ls -lh
total 0
--w------- 1 root root 4.0K Jun  1 10:54 export
lrwxrwxrwx 1 root root    0 Jun  1 10:54 gpio7 -> ../../devices/virtual/gpio/gpio7
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 4.0K Jan  1  2000 unexport
root@bbb:/sys/class/gpio# cd gpio7
root@bbb:/sys/class/gpio/gpio7# cat value 
0

Generate Interrupts

One very simple way to generate interrupts is using a push button. I connected one side of the button to one of the 3.3v outputs on the P9 header and the other side through a resistor to pin 42 (GPIO_7). To verify that the button was working as expected I read the ‘value’ file to see 0, then held the button down and got a 1 while holding down the button which was reverted to 0 again after I released the button. If I was using interrupts I could have received a rising interrupt right when the button was pressed and a falling one right when it was released.

root@bbb:/sys/class/gpio/gpio7# cat value 
0
root@bbb:/sys/class/gpio/gpio7# cat value 
1
root@bbb:/sys/class/gpio/gpio7# cat value 
0

If your hardware supports it for a pin you can turn on interrupts by echoing your desired setting into the edge file as shown below. I say if your hardware supports it because the GPIO in the Linux kernel might allow you to read or write to a pin but only certain pins might be setup in hardware to allow interrupts to be generated. For the BeagleBone Black, “In GPIO mode, each digital I/O can produce interrupts”.

root@bbb:~# echo both > /sys/class/gpio/gpio7/edge 

Set up Monitoring

Then you want to watch the ‘value’ file in the gpio7 directory. As you saw above, the contents of that file did change when I held down the button. But we certainly don’t want to keep checking the file on a regular basis to see if the button is pressed or not. Initially when thinking of file monitoring I thought of inotify, which I didn’t manage to configure to give me an event when the gpio value file was updated by an interrupt. So then I started writing a C++ program to do the file monitoring. To simplify the code a little bit I used the glib2 library instead of the poll() or select() functions. The glib2 library can be used without a UI. Using glib2 made the code simpler and paves the way for graphical applications to get input from custom hardware.

The main() function is shown below. First the gpio7/value is opened and then a glib2 channel is created to trigger the onButtonEvent function whenever the gpio7/value file as a priority event. Note that onButtonEvent will be called right away because there is data available for the gpio7/value file. You could read the while gpio7/value file to stop this initial call to onButtonEvent if it would do something undesired.

int main( int argc, char** argv )
{
    GMainLoop* loop = g_main_loop_new( 0, 0 );
    
    int fd = open( "/sys/class/gpio/gpio7/value", O_RDONLY | O_NONBLOCK );
    GIOChannel* channel = g_io_channel_unix_new( fd );
    GIOCondition cond = GIOCondition( G_IO_PRI );
    guint id = g_io_add_watch( channel, cond, onButtonEvent, 0 );
    
    g_main_loop_run( loop );
}

Fix Interrupt Handler Loops

The “interrupt handler” is shown below. I use quotes here because this is just a normal C function and is not bound by any special requirements that a microcontroller interrupt handler might have. The one thing the onButtonEvent should do is make sure that the current change that triggered the glib2 channel will not trigger again when onButtonEvent returns. Otherwise onButtonEvent will be called again, and if it doesn’t do anything the event will still stand and onButtonEvent will be called again, and so on forever. Luckily there is a message shown on the console when onButtonEvent is called so you can detect and fix these interrupt handler loops fairly easily.

The file for the glib2 channel is what caused the onButtonEvent to be called. One way to clear the event and satisfy glib2 that we have handled the event is to read the file again. Because the file is still at the end of file offset, we have to seek to the beginning and then can read the contents to see if the button is pressed or released. Returning 1 from the onButtonEvent function means that glib2 will not remove the callback.

static gboolean
onButtonEvent( GIOChannel *channel,
               GIOCondition condition,
               gpointer user_data )
{
    cerr << "onButtonEvent" << endl;
    GError *error = 0;
    gsize bytes_read = 0; 
    g_io_channel_seek_position( channel, 0, G_SEEK_SET, 0 );
    GIOStatus rc = g_io_channel_read_chars( channel,
                                            buf, buf_sz - 1,
                                            &bytes_read,
                                            &error );
    cerr << "rc:" << rc << "  data:" << buf << endl;
    
    // thank you, call again!
    return 1;
}

The build procedure just uses a simple Makefile as shown below. In the execution I have pressed the button once (data:1) and released it (data:0). The initial reading occurred right away because the code hadn’t already read the gpio7/value file.

$ cat Makefile
watch-button-glib: watch-button-glib.cpp Makefile
        g++ watch-button-glib.cpp -o watch-button-glib ` pkg-config glib-2.0  --cflags --libs`
$ make
$ ./watch-button-glib
onButtonEvent
rc:1  data:0
onButtonEvent
rc:1  data:1
onButtonEvent
rc:1  data:0

If you echo falling into the gpio7/edge file then onButtonEvent will only be called when you release the button.

Apply to other hardware

The same technique can be used to get input from hardware which looks much more advanced at first glance. For example, the Blackberry Trackballer Breakout has four Hall effect sensors which detect a magnetic field as a while ball rolls. Each time one of these Hall effect sensors triggers it sends an interrupt down the line for its direction of ball motion (up, down, left, right). All you need to do on the BeagleBone Black is monitor 4 GPIO ports and adjust the xaxis and yaxis variables as the interrupts come in. The following modified onButtonEvent function updates xaxis and yaxis as the ball moves and shows you the current value each time.

enum 
{
    DIRECTION_UP = 1,
    DIRECTION_DOWN,
    DIRECTION_LEFT,
    DIRECTION_RIGHT 
};
int xaxis = 0;
int yaxis = 0;
static gboolean
onButtonEvent( GIOChannel *channel,
               GIOCondition condition,
               gpointer user_data )
{
    cerr << "onButtonEvent" << endl;
    int direction = (int)user_data;
    GError *error = 0;
    gsize bytes_read = 0;
    
    g_io_channel_seek_position( channel, 0, G_SEEK_SET, 0 );
    GIOStatus rc = g_io_channel_read_chars( channel,
                                            buf, buf_sz - 1,
                                            &bytes_read,
                                            &error );
    switch( (int)user_data )
    {
        case DIRECTION_UP:
            yaxis++;
            break;
        case DIRECTION_DOWN:
            yaxis--;
            break;
        case DIRECTION_LEFT:
            xaxis--;
            break;
        case DIRECTION_RIGHT:
            xaxis++;
            break;
    }
    cerr << " direction:" << direction << " x:" << xaxis << " y:" << yaxis << endl;
    
    // thank you, call again!
    return 1;
}

I used GPIO pins 70 through 73 inclusive for input from the trackball. These pins are monitored the same way as GPIO 7 in the previous example. The user_data pointer used when setting up the onButtonEvent callback is one of the DIRECTION enum values.

Set permissions

The default permissions on the exported GPIO pins, for example the /sys/class/gpio/gpio72 directory, permit everybody to read the pin but only root to write to the files. This means that you have to permit your normal Linux user account to write to the edge file or setup the interrupts on the GPIO files by sshing into the BeagleBone Black as root. Changing the permissions to the /sys/class/gpio/export file to a user account still means that when a pin is exported, the created gpioNN directory and its files will only be writable by root. This would seem to be an issue that udev rules can solve.

Getting interrupts from your chips is fairly straightforward using the Linux GPIO interface. The collection of programming languages and libraries available on a Linux installation lets you choose which method to use to monitor your gpio/value files and respond to interrupts.

SANS Internet Storm Center, InfoCON: green: Fiesta!, (Fri, Feb 28th)

This post was syndicated from: SANS Internet Storm Center, InfoCON: green and was written by: SANS Internet Storm Center, InfoCON: green. Original post: at SANS Internet Storm Center, InfoCON: green

No, we haven't broken out the beer or decided to start the weekend early. This ISC diary isn't about party time, but rather about the "Fiesta Exploit Kit". We are recently seeing an uptick of it being used on compromised web sites.

Fiesta has been around in one form or another since 2012, when it branched off the "NeoSploit" kit, and is regularly being retrofitted with new exploits to stay effective. The first stage is usually just a redirect, to the actual exploit site from where a heavily encoded/obfuscated JavaScript file gets downloaded. This JavaScript file checks the locally installed software, and then triggers or downloads the matching exploit(s).

The currently most prevalent version of Fiesta seems to use the same five exploits / vulnerabilities since about November last year:

  • CVE-2010-0188 Adobe Reader TIFF vulnerability. The code checks for Adobe Reader versions >= 800 < 821 and >= 900 < 931, and only triggers if a matching (ancient) Adobe version is installed.
  • CVE-2013-0074 Microsoft Silverlight (MS13-022, March 2013). The code checks for Silverlight versions >= 4050401 and < 5120125, and triggers the exploit if applicable. Silverlight 5.1.201.25.0 is the version after patch MS13-022 has been applied
  • CVE-2013-2465 Oracle Java. Of course – there had to be a Java sploit in the mix. The code checks for Java > 630 < 722
  • CVE-2013-0634 Adobe Flash Player. The code checks for Flash Player >= 110000 <= 115502.
  • CVE-2013-2551 Microsoft Internet Explorer (MS13-037, May 2013). The code in this case just checks for IE Versions 6 to 10, and if found, tries the exploit.

A system with reasonably up to date patches should have nothing to fear from the above. The fact that Fiesta has not widely re-tooled to newer exploits suggests though that the above set of vulnerabilities are still netting the bad guys plenty of newly exploited bots.

The existing Snort EmergingThreat signatures for Fiesta are doing a reasonable job at spotting the attack. As for the Snort standard (VRT) ruleset, rule SID 29443 seems to work well right now, it was added in January to match on the URL format: "/^\/[a-z0-9]+\/\?[0-9a-f]{60,66}[\x3b\x2c\d]*$/U" used, and is still triggering frequently on the current Fiesta wave.

One further characteristic of the current Fiesta is also its heavy use of dynamic DNS. Seen this week so far were *.no-ip.info, *.no-ip.org, *.myvnc.com, *.no-ip.biz, *.myftp.com, *.hopto.org and *.serveblog.net. These are DynDNS providers, so obviously not all sites hosted there are malicious. But Fiesta is making extensive use of these services to rapidly shuffle its exploit delivery hosts. The host names used are random character sequences of 10 or 6 chars, current example "ofuuttfmhz.hopto.org". The corresponding sites are sometimes active for less than a hour before the DNS name used in the sploits changes again.

What seems to be reasonably static are the IP addresses – 209.239.113.39 and 64.202.116.124 have both been used for the past two weeks, and the latter hoster seems to be particularly "popular", because the adjacent addresses (64.202.116.122, 64.202.116.125) were in use by Fiesta in late January. Also quite common are landing pages hosted on *.in.ua (Ukraine) domains, like ujimmy.in.ua, aloduq.in.ua, etc. These domains should be infrequent enough in (western) web proxy logs to make them easier to spot.

If you have any other current Fiesta intel (not involving cerveza :), let us know via the contact page or comments below!

 

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

SANS Internet Storm Center, InfoCON: green: Abobe out of band patch announcement (APSB14-07), (Thu, Feb 20th)

This post was syndicated from: SANS Internet Storm Center, InfoCON: green and was written by: SANS Internet Storm Center, InfoCON: green. Original post: at SANS Internet Storm Center, InfoCON: green

Adobe has released security advisory APSB14-07 which is an update for Adobe Flash Player versions 12.0.0.44 and prior. It impacts both Windows and Mac versions, and those on Linux prior to 11.2.202.336.

It addresses CVE-2014-0502 which is being exploited in the wild, and Adobe say you should update asap!

Details are available on the Adobe site.

Steve Hall

ISC Handler

www.tarkie.net

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Krebs on Security: Adobe, Microsoft Push Fixes For 0-Day Threats

This post was syndicated from: Krebs on Security and was written by: BrianKrebs. Original post: at Krebs on Security

For the second time this month, Adobe has issued an emergency software update to fix a critical security flaw in its Flash Player software that attackers are already exploiting. Separately, Microsoft released a stopgap fix to address a critical bug in Internet Explorer versions 9 and 10 that is actively being exploited in the wild.

brokenflash-aThe vulnerabilities in both Flash and IE are critical, meaning users could get hacked just by visiting a compromised or booby-trapped Web site. The Flash patch comes just a little over two weeks after Adobe released a rush fix for another zero-day attack against Flash.

Adobe said in an advisory today that it is aware of an exploit that exists for one of three security holes that the company is plugging with this new release, which brings Flash Player to v. 12.0.0.70 for LinuxMac and Windows systems.

This link will tell you which version of Flash your browser has installed. IE10/IE11 and Chrome should auto-update their versions of Flash, although IE users may need to check with the Windows Update feature built into the operating system.

If your version of Flash on Chrome (on either Windows, Mac or Linux) is not yet updated, you may just need to close and restart the browser. The version of Chrome that includes this fix is v. 33.0.1750.117 for Windows, Mac, and Linux. To learn what version of Chrome you have, click the stacked bars to the right at of the address bar, and select “About Google Chrome” from the drop down menu (the option to apply any pending updates should appear here as well).

The most recent versions of Flash are available from the Adobe download center, but beware potentially unwanted add-ons, like McAfee Security Scan). To avoid this, uncheck the pre-checked box before downloading, or grab your OS-specific Flash download from here. Windows users who browse the Web with anything other than Internet Explorer will need to apply this patch twice, once with IE and again using the alternative browser (Firefox, Opera, e.g.).

FLASH-12-0-0-70

As I noted in my Tools for a Safer PC primer, blocking Javascript by default in your Web browser is the best way to block browser-based attacks — including these Flash zero-day flaws. Several Mac users have written in recently to ask about the whereabouts of a Tools for a Safer Mac post, and while that’s a good idea (and a post that may soon be coming), script-blocking via extensions/add-ons like NoScript and NotScripts is an approach that works across multiple OSes.

Another great cross-platform approach to blocking Flash (and Java) content by default is Click-to-Play, a feature built into Google Chrome, Mozilla Firefox and Opera (and available via add-ons in Safari) that blocks plugin activity by default, replacing the plugin content on the page with a blank box. Users who wish to view the blocked content need only click the boxes to enable the Flash or Java content inside of them. Check out this post for more details on deploying Click-to-Play.

MICROSOFT FIX-IT TOOL

IEwarningMicrosoft has released a security advisory and a FixIt shim tool for a previously unknown zero-day vulnerability in Internet Explorer versions 9 and 10. Microsoft says it is aware of “limited, targeted attacks” that attempt to exploit a vulnerability in Internet Explorer 10. Only Internet Explorer 9 and Internet Explorer 10 are affected by this vulnerability. Other supported versions of Internet Explorer are not affected.

Microsoft says it is working on an official patch, but that in the meantime IE users should consider taking advantage of a new FixIt solution. According to Microsoft, applying the Microsoft Fix it solution here prevents the exploitation of this issue.

Microsoft warns that IE users should make sure they have the latest version of IE before appyling this FixIt solution (that means a visit to Windows Update). Also, the company says that after you install this Fix it solution, you may experience increased memory usage when you use Internet Explorer to browse the web. This behavior apparently occurs until you restart Internet Explorer.

Krebs on Security: Security Updates for Shockwave, Windows

This post was syndicated from: Krebs on Security and was written by: BrianKrebs. Original post: at Krebs on Security

Adobe and Microsoft today each issued patches to fix critical security flaws in their software. Microsoft’s February Patch Tuesday includes seven patch bundles addressing at least 31 vulnerabilities in Windows and related software. Adobe pushed out an update that fixes two critical bugs in its Shockwave Player.

crackedwinMore than half of the updates issued by Microsoft today earned a “critical” rating — Microsoft’s most dire. That rating is assigned to vulnerabilities that can be exploited by malware or malcontents to take complete, remote control over vulnerable systems — with no help from users.

Microsoft is urging Windows users to apply all of the available fixes, but for those who need to prioritize patches (organizations that typically test patches before deploying them enterprise-wide), Redmond places a special focus on MS14-007, a graphics vulnerability in Windows 7/8/8.1 and Windows Server 2007, 2012 and Windows RT.

The cumulative, critical security update for all versions of Internet Explorer (MS14-010) fixes two dozen vulnerabilities, including one that Microsoft says has already been publicly disclosed. The other patch that Microsoft specifically called out — MS14-011 — addresses a vulnerability in VBScript that could cause problems for IE users.

Microsoft also once again is encouraging Windows users who haven’t already done so to consider installing and using its Enhanced Mitigation Experience Toolkit (EMET), a free tool that can help to significantly beef up the security of third-party applications that run on top of Windows. I would second their recommendation, and have reviewed EMET 4.0 here. The latest version — 4.1 — is available at this link and requires Microsoft’s .NET Framework 4 platform.

Speaking of .NET, this month’s updates includes a comprehensive patch for the .NET Framework; experience has taught me to install these separately from other Windows patches, then reboot and install any .NET updates. I’ve run into trouble in the past trying to install .NET updates alongside lots of other simultaneously, but your mileage my vary.

For more on today’s Microsoft patches, check out the Microsoft Security Response Center blog, as well as Qualys’s take on the updates.

Separately, Adobe has issued a critical patch for its Shockwave player software, which fixes two flaws and brings Shockwave to v. 12.0.9.149  on Mac and Windows systems. The latest version is available here.

If you visit this link and see a short animation, it should tell you which version of Shockwave you have installed. If it prompts you to download Shockwave, then you don’t have Shockwave installed and in all likelihood don’t need it. Firefox users should note that the presence of the “Shockwave Flash” plugin listed in the Firefox Add-ons section denotes an installation of Adobe Flash Player plugin — not Adobe Shockwave.

Linux How-Tos and Linux Tutorials: Install Fedora on Intel NUC: A Low-Power, x86-Ready Mini PC With Grunt

This post was syndicated from: Linux How-Tos and Linux Tutorials and was written by: Ben Martin. Original post: at Linux How-Tos and Linux Tutorials

The Intel Next Unit of Computing (NUC) is a very compact computer with an Intel CPU at its heart. The NUC reviewed here has mini DisplayPort and mini HDMI ports, two memory slots, mSATA, USB 3.0, mini PCI Express, an IR receiver, and an internal SATA connector among other things.

The main thing I wanted investigate for this article was how well Fedora 20 runs on this thing. Does audio output over the mini HDMI work out of the box? Does suspend to RAM sometimes decide not to resume? And of course, what sort of performance and power usage is there relative to a traditional desktop machine or the high-end ARM machines such as the ODroid XU?

The NUCs have been around for a little while; there is an older and newer Celeron model, two models featuring Ivy Bridge Core i3 and i5 CPUs, and the latest models with Haswell Core i3 and i5 CPUs. This article looks at the Intel NUC Model D34010WYK which has an Intel Core i3-4010U Haswell CPU and two DDR3 SODIMM slots to accept up to 16 GB of RAM and sells for around $300. For somewhere in the range of $75-$100 more is the NUC with an Intel Core i5-4250U Haswell CPU which has Intel Turbo Boost Technology 2.0 so it can alter the CPU frequency and also features a more powerful Intel graphics chip. Whether you want the Core i3 or Core i5 model depends on if you need the extra CPU performance that the Turbo Boost offers.

The most recent NUC to be released is the new Celeron model which retails for around $150. There are also versions of the Haswell NUCs which have a larger case so you can fit a 2.5-inch drive inside the NUC. The newer Haswell CPUs are more power efficient than the Ivy Bridge CPUs. You should keep a close eye on which Intel Core i3 NUC model you are getting to make sure you know which CPU you are getting.

Storage can be added using the internal mSATA bay, the internal SATA port, or the external USB3 ports. Because the D34010WYK runs the Haswell generation of CPU and uses low-voltage laptop memory, it can idle at very low power consumption levels. The small form factor of the NUC and low power consumption push the NUC much closer to the realm of the 2-3 Watt little ARM machines than the 50-100 W traditional desktop machine.

Some advantages the NUC has over many small form factor machines are the speed of the processor, the ability to have up to 16 GB of RAM, four USB 3.0 ports, and both a mini HDMI and mini DisplayPort connector. Being an Intel Core i3 CPU, if some code works on a regular x86 desktop machine then it shouldn’t require any porting or recompilation for the NUC. This also extends to things such as the Adobe Flash plugin which is not available for ARM machines. Whether or not you want to run such code is another question, but with the NUC you get the choice to do so if you want.

Setting Up

Once you buy the D34010WYK NUC, you have to then add RAM and storage, and while the NUC comes with a power supply, don’t forget to also grab a C5 power cable because you’ll also need one of those to get going.

Intel NUC

In order to use the NUC, you first have to unscrew the base plate which gives you access, as shown in the picture above. In the picture the NUC is upside down after the base plate was removed. The SODIMM RAM slots are on the right of the figure and the wifi and msata cards can be put into the slots on the left side. The CPU itself cannot be seen as it is on the other side of the board.

If you want to easily be able to use the SATA connector shown in the top middle of the picture you might like to consider the larger D34010WYKH model which has more internal room in the case. Otherwise, it seems you are going to have to do some modification of the base plate to let the SATA cable escape the smaller NUC case.

The NUC used for this article was a D34010WYK combined with a single Kingston KVR16LS11/8 8GB DDR3 1600 1.35V SODIMM. While using a single stick of RAM might restrict memory throughput it also leaves the door open for easy future upgrades. The storage was a USB 3.0 pen drive. This kept the price of the whole system at around $400.

Installing Fedora

My initial attempt to install Fedora used an external USB powered DVD drive. That setup caused the NUC not to post. Instead things froze up at the splash screen. Once the DVD was removed the NUC attempted to boot off its network card. So it seemed the hardware was OK.

Luckily the liveusb-creator program makes it very easy to convert from a bootable Fedora 20 ISO to a bootable USB stick. Once you install liveusb-creator, tell it where the ISO file is and select the USB drive from a drop down menu and after some delay writing you’ll soon have a bootable USB stick. Using liveusb-creator is also beneficial because it makes it harder to accidentally write the image to the wrong target disk. I used liveusb-creator to make a 4 GB USB stick that could boot into (and install) Fedora 20.

I wanted to install Fedora 20 onto a larger and much faster 32 GB USB 3.0 pen drive. So I plugged the 4 GB bootable USB stick into one of the front USB 3.0 ports and the 32 GB USB 3.0 stick into one of the rear USB ports. The installer offered the 32 GB disk as the location to install Fedora 20 onto and the installation proceeded.

I’m not sure if it was because the target USB stick had partitions on it already, but my first attempt to install failed during filesystem setup. So I ended up installing without using LVM. Another little trap here was that after installation finished I removed the 4 GB drive that I used to start the installation before booting up again. But the Fedora 20 boot up wanted to find “sdb” which is where the 32 GB disk was during installation. Though the 32 GB USB drive had now moved to sda because the 4 GB stick had been removed.

I assume this issue will not show up if you install to an mSATA drive as its position will not change between boots. To resolve the issue I reconnected the original 4 GB USB stick again and used the boot menu to choose to boot from the 32 GB drive. After doing that a few times I could remove the 4 GB drive and the system booted as expected.

Configuring Sound and IR

Booting into the installed Fedora, the gigabit network worked right away, but my first attempts to use sound produced nothing. Installing and running pavucontrol I altered the Configuration tab to disable the lower Built-in Audio which I assume, due to the stereo nature, was for the headphones on the front of the NUC. Then I got sound over the HDMI cable.

pulseaudio-hdmi

pulseaudio-internal-2

So, USB, network, mini HDMI at 1080, and sound were all working. Next up I chose Suspend to RAM and brought back the machine to the desktop again a dozen times. So far so good. Over ssh the pm-suspend command would also put the NUC to sleep and it could be brought back again by running the following command on another machine:

# ether-wake -i eth0 ma:ca:dd:re:ss:0

The Haswell NUC has an infrared receiver on the front of the unit. I thought getting that working would be a matter of starting lircd and probably telling it what remote I have at hand. Unfortunately there was no /dev/lirc0 device file. And my attempts to cajole a working one into existence were ineffective. I then found this post in an Intel Community Forum. I’ve repeated the commands from the above link below in case the link goes stale. The first command verifies that the IR driver didn’t load properly and the second block creates a state that allows the nuvoton-cir module to load properly. After doing that, the NUC could receive input from an IR remote control.

# dmesg | grep nuvoton-cir
[2.497482] nuvoton-cir 00:08: IR PNP Port not valid!

# modprobe -r nuvoton-cir
# echo "auto" > /sys/bus/acpi/devices/NTN0530\:00/physical_node/resources
# modprobe nuvoton-cir

Testing Power Usage

As for power usage, when plugged in and turned off the NUC drew 1.2 W. After boot up to a KDE 4 desktop the NUC idled at 6.6 W (with two USB sticks, and a USB keyboard and mouse attached). Turning compositing on or off (hotkey alt+shift+f12) didn’t change the power draw. A pm-suspend sleep dropped power consumption to around 1 W. During a make -j 4 compile (up to four jobs at once) of openssl power ranged up to 16 W. While running the Javascript Octane benchmark power usage ranged up to 15 W but was mostly more around 12 W. While running openssl speed power usage was around 11-12 W. Running three instances of openssl speed at once resulted in over 14 W used.

Moving to performance, the Octane 2.0 Javascript benchmark was run using the 64-bit release of Firefox 26.0. The Core i3 NUC got 7843 while an Intel 2600K desktop got 18813 overall. The NUC was running at 1.7GHz while the 2600K can range up to 3.40GHz.

Testing Graphics Performance

To test 2D graphics performance I used version 1.0.1 of the Cairo Performance Demos. The gears test runs three turning gears, the chart runs four line graphs, the fish is a simulated fish tank with many fish swimming around, gradient is a filled curved edged path what moves around the screen, and flowers renders rotating flowers that move up and down the screen. For comparison I used a desktop machine running an Intel 2600K CPU with an NVidia GTX 570 card which drives two screens, one at 2560×1440 and the other at 1080p.

                          NUC fps          Desktop Intel 2600k with NVidia 570 card 
                                                   at 1080p running two screens.

gears                  126                 140

chart                        8                   16

fish                      154                 188

gradient                 43                117

The openssl 1.0.0e “speed” benchmark results are shown below. The NUC has a large performance advantage for RSA operations. It is interesting that for bulk encryption using DES and AES that the ODroid-XU is faster in one of the four tests and around the same performance to the NUC in two of the other tests. For data digests the NUC has a noticeable advantage.

rsa speed test results

rsa verify test Intel NUC

ciphers performance NUC

digests NUC

As for video playback, Big Buck Bunny at 1080 using mplayer spent most CPU time in the 20-30 percent range with occasional peaks up to around 60 percent.

I didn’t test any Wi-Fi card that you can connect to one of the internal ports. A big part of that was to keep the cost down for the overall project. It is easy to add 256 GB mSATA, 16 GB of RAM, and Wi-Fi but if you don’t need these things then you might be better off keeping the initial cost down. The wired gigabit port worked fine and didn’t contribute to an already cluttered Wi-Fi network. Remember to grab the C5 power cable if you are getting a NUC, and make sure you have a mini HDMI cable if you want to use that display connector on the NUC. Apart from needing to direct pulseaudio to use HDMI for sound, and a little tinker for the infrared input, most things on the NUC worked out of the box with Fedora 20.

Many of the ARM machines operate in the 2-3 W at idle and range up into the 10 W range under load. The NUC wants 6-7 W idle and up around 16 W under load. The NUC offered great performance and some very nice Cairo benchmarks.  

Schneier on Security: TRINITY: NSA Exploit of the Day

This post was syndicated from: Schneier on Security and was written by: schneier. Original post: at Schneier on Security

Today’s item from the NSA’s Tailored Access Operations (TAO) group implant catalog:

TRINITY

(TS//SI//REL) TRINITY is a miniaturized digital core packaged in a Multi-Chip Module (MCM) to be used in implants with size constraining concealments.

(TS//SI//REL) TRINITY uses the TAO standard implant architecture. The architecture provides a robust, reconfigurable, standard digital platform resulting in a dramatic performance improvement over the obsolete HC12 microcontroller based designs. A development Printed Circuit Board (PCB) using packaged parts has been developed and is available as the standard platform. The TRINITY Multi-Chip-Module (MCM) contains an ARM9 microcontroller, FPGAA, Flash and SDRAM memories.

Status: Special Order due vendor selected.

Unit Cost: 100 units: $625K

Page, with graphics, is here. General information about TAO and the catalog is here.

In the comments, feel free to discuss how the exploit works, how we might detect it, how it has probably been improved since the catalog entry in 2008, and so on.

Errata Security: That NBC story 100% fraudulent

This post was syndicated from: Errata Security and was written by: Robert Graham. Original post: at Errata Security

Yesterday (Feb 5 2014) On February 4th, NBC News ran a story claiming that if you bring your mobile phone or laptop to the Sochi Olympics, it’ll immediately be hacked the moment you turn it on. The story was fabricated. The technical details relate to going to the Olympics in cyberspace (visiting websites), not going to there in person and using their local WiFi.
The story shows Richard Engel “getting hacked” while in a cafe in Russia. It is wrong in every salient detail.
  1. They aren’t in Sochi, but in Moscow, 1007 miles away.
  2. The “hack” happens because of the websites they visit (Olympic themed websites), not their physical location. The results would’ve been the same in America.
  3. The phone didn’t “get” hacked; Richard Engel initiated the download of a hostile Android app onto his phone. [update here] and he had to disable the security on the phone to do it
I had expected the story to be about the situation with WiFi in Sochi, such as man-in-the-middle attacks inserting the Blackhole toolkit into web pages exploiting the latest Flash 0day. But the story was nothing of the sort.
Instead, the hacking in the story was due to the hostility of Olympic themed websites. The only increased danger from being in Russia is geolocation. Google uses your IP address to increase the of rank local sites, so you’ll see more dodgy Russian sites in the results. You can disable this feature in your Google account settings.

Absolutely 0% of the story was about turning on a computer and connecting to a Sochi network. 100% of the story was about visiting websites remotely. Thus, the claim of the story that you’ll get hacked immediately upon turning on your computers is fraudulent. The only thing that can be confirmed by the story is “don’t let Richard Engel borrow your phone”.
That leaves us with the same advice that we always give people:
  1. don’t click on stuff
  2. patch your stuff (browser, Flash, PDF)
  3. get rid of the really bad stuff (Oracle’s Java)
  4. don’t click on stuff
  5. oh, and if you really are in Sochi, use VPN over the public WiFi
I gleaned these details from Kyle Wilhoit, the expert quoted in the story, and his Twitter feed. He’s working on a blog with the full technical details. I’m sure it’ll be great, with lots of details about what hackers can find with Maltego, the dangers of hostile websites, and so on — the sort of great information totally lost in the nonsense that is the NBC story.

By the way, the easy way to figure out where journalists commit fraud is by watching for “passive voice”. Journalists normally avoid passive voice, preferring stronger language. But, when they need to hide things, they passive voice to cover up details. Saying “was hacked” covers up the fact that Richard Engel hacked himself by knowingly downloading a hostile Android app. In other word, active voice wouldn’t have worked, because it would have required identifying who put the virus on the phone. He couldn’t report that a “hacker put the virus on the phone” because the hacker didn’t, Richard Engel did. He couldn’t very well have reported, in the active voice, “I downloaded the virus”. Thus, the passive voice, “the phone was hacked”, avoiding this inconvenient detail of who did what.


Some forums with lots of comments on this story:

/dev/ttyS0 : Re-enabling JTAG and Debugging the WRT120N

This post was syndicated from: /dev/ttyS0 and was written by: Craig. Original post: at /dev/ttyS0

After de-obfuscating the WRT120N’s firmware, I started taking a closer look at the code, which runs the now-defunct SuperTask! RTOS.

Thanks in no small part to copious debug strings littered throughout the code and some leaked Atheros datasheets, I made good progress in statically disassembling the code. The next step was to start debugging the system while exercising some of the router’s services.

The WRT120N does have a JTAG port (labeled J8), which appears to conform to the MIPS EJTAG standard header:

The WRT120N JTAG header

The WRT120N JTAG header

It didn’t work right out of the box though:

$ sudo openocd -f flyswatter2.cfg -f wrt120n.cfg 
Open On-Chip Debugger 0.7.0 (2014-01-05-12:41)
Licensed under GNU GPL v2
For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'jtag'
adapter speed: 6000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
trst_and_srst separate srst_nogate trst_push_pull srst_open_drain connect_assert_srst
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
mips.cpu
Info : max TCK change to: 30000 kHz
Info : clock speed 6000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: mips.cpu: IR capture error; saw 0x1f not 0x01
Warn : Bypassing JTAG setup events due to errors
Error: Error writing unexpected address 0xffffffff
Error: Error writing unexpected address 0xffffffff
Error: Error writing unexpected address 0xffffffff
Error: Error writing unexpected address 0xffffffff

It turns out that JTAG has been disabled in hardware and in software on the WRT120N. Luckily both were relatively easy to fix.

Patching the Hardware


One of the simplest ways to disable JTAG is to remove jumpers, and that’s exactly what has been done here:

Missing R356 0-ohm jumper

Missing R356 0-ohm jumper

The TDI pin on the JTAG header (pin 2) has been disconnected from the rest of the system by simply removing jumper R356. This was easily remedied with a quick solder blob:

R356 solder blob

R356 solder blob

With TDI re-connected, I was able to reset the system and halt the processor over JTAG:

Open On-Chip Debugger
> reset init
JTAG tap: mips.cpu tap/device found: 0x00000001 (mfg: 0x000, part: 0x0000, ver: 0x0)
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0xbfc00000

Unfortunately, I quickly lost control of execution:

> resume
> halt
Failed to enter Debug Mode!
Halt timed out, wake up GDB.
timed out while waiting for target halted
in procedure 'halt'

After some probing, I found that this is due to the hardware design of the WRT120N: the reset button has been connected to the JTAG TDI pin on the AR7240 SoC. It is common for systems to allow JTAG pins to be re-configured as GPIO pins, so this is not un-heard of. However, this means that JTAG is likely being disabled in software.

Additionally, when depressed, the reset button asserts this pin low; the TDI line driven from my JTAG adapter also idles low. This means that whenever the JTAG adapter was connected to the JTAG header, the system thought that the reset button had been pressed.

I obviously didn’t want JTAG to be disabled, nor did I want the system continually resetting during a debug session. But, since I couldn’t magically redefine hardware pins, these were issues that had to be addressed in software.

Patching the Bootloader


The first firmware patch I needed to make was to the bootloader.

As seen previously, the bootloader checks the reset pin, and if asserted, it boots into a recovery image instead of booting the main image:

if(check_reset_button() != 0) goto load_main_image;

if(check_reset_button() != 0) goto load_main_image;

Since the JTAG adapter pulls the TDI line low, the bootloader wouldn’t even boot the main OS with the JTAG adapter connected; it thought the reset button had been pushed and loaded the recovery image instead!

There were two solutions to this problem. First, I could simply set a breakpoint on this conditional branch and change the register contents so that the recovery image is never loaded.

Besides being a PITA, this approach turned out to be impractical due to the following piece of earlier code:

Setting the RESET_SWITCH bit in the CPU_CLOCK_CONTROL register

Setting the RESET_SWITCH bit in the CPU_CLOCK_CONTROL register

This code is executed very early in the boot process and is in part responsible for configuring the system’s PLL clock. Specifically, the code snippet above sets bit 0 (the RESET_SWITCH bit) in the CPU_CLOCK_CONTROL register; according to the datasheet, this generates a CPU reset, causing the debugger to lose control of execution:

This register [CPU_CLOCK_CONTROL] controls the clock and reset to the CPU. These bits are controlled by driver software…RESET_SWITCH reset[s] during clock switch trigger.

What this means is that I would have to enter JTAG debug mode after the PLL was configured, but before the reset button was checked; a race condition that was difficult to reliably to win.

Instead, I opted to simply patch the bootloader on the flash chip. The check_reset_button function masks out bit 6 of the GPIO_IN register (aka, the TDI pin) by performing a logical AND with 0×40; if that pin is low, the function returns 0 (reset button depressed), else it returns non-zero:

The check_reset_button function

The check_reset_button function

I changed this from a logical AND to a logical OR, ensuring that check_reset_button always returns non-zero regardless of the actual state of the pin. This is just a one bit change to the instruction opcode:

The modified check_reset_button function

The modified check_reset_button function

Desoldering the flash chip and overwriting the bootloader with this patch got me past the bootloader and into the main OS:

> bp 0x800081ac 4 hw
breakpoint set at 0x800081ac
> resume
target state: halted
target halted in MIPS32 mode due to breakpoint, pc: 0x800081ac

However, JTAG debugging was killed shortly thereafter, and the serial console was spammed with “Reset button held…” messages:

Reset button held 0
Reset button held 1
Reset button held 2
Reset button held 3
Reset button held 4
Reset button held 5
Reset button held 6
Reset button held 7
Reset button held 8
Reset button held 9
...

Patching the OS


Something in the OS was disabling JTAG, and the culprit was found in the configure_peripherals function:

GPIO_FUNCTION_1.EJTAG_DISABLE = 1

GPIO_FUNCTION_1.EJTAG_DISABLE = 1

This code is responsible for setting the EJTAG_DISABLE bit inside the GPIO_FUNCTION_1 register. According to the datasheet, this will:

Disable EJTAG port functionality to enable GPIO functionality; can be set to 1 to enable using GPIO_5, GPIO_6, and GPIO_7 as GPIO pins

This was easily fixed by simply nopping out the ori instruction that was used to set the EJTAG_DISABLE bit:

EJTAG_DISABLE bit patched

EJTAG_DISABLE bit patched

For good measure, I also went ahead and nopped out the function call to gpio_tris that configures GPIO#6 (aka, TDI) as a GPIO input:

gpio_tris(GPIO6, INPUT);

gpio_tris(GPIO6, INPUT);

Call to gpio_tris nopped

Call to gpio_tris nopped

And got rid of that pesky reset button check that was spamming my serial console as well:

if(read_gpio_pin(6) != 0) goto reset_not_depressed;

if(read_gpio_pin(6) != 0) goto reset_not_depressed;

if(1 != 0) goto reset_not_depressed;

if(1 != 0) goto reset_not_depressed;

Re-building the Firmware Image


Having patched the OS, I needed to write it back to the flash chip. Not wanting to de-solder the flash chip yet again, I opted to apply the patches via a firmware update.

Since the OS image had been modified, I first needed to figure out the checksum for the firmware update file. It turns out that it is a standard CRC32 checksum that is stored in the firmware footer:

The crc32 function being called from cgi_upgrade

The crc32 function being called from cgi_upgrade

The checksum field itself is set to 0xFFFFFFFF at the time of calculation, and the checksum is calculated over the entire firmware update file, except for the board ID string at the very end.

So, putting everything together, I just needed to:

  • Re-compress the modified OS image
  • Concatenate the LZMA compressed web files and firmware footer with the compressed, modified OS image
  • Re-obfuscate the firmware image
  • Re-calculate and patch the checksum

I threw together a little script to automate this; it’s super hacky, but works so long as I don’t change the size of the decompressed OS image.

After buggering it up the first time, I recovered the system and flashed the modified firmware image through the router’s web interface. After a reboot, lo and behold, JTAG was up and running without issues:

> halt
target state: halted
target halted in MIPS32 mode due to debug-request, pc: 0x800045a4
> reg
===== mips32 registers
(0) zero (/32): 0x00000000
(1) at (/32): 0x804E0000
(2) v0 (/32): 0x00000000
(3) v1 (/32): 0x805BD6E4
(4) a0 (/32): 0x803D0000
(5) a1 (/32): 0x0000000A
(6) a2 (/32): 0x805BD57C
(7) a3 (/32): 0x806BD190
(8) t0 (/32): 0x80003F28
(9) t1 (/32): 0x00000000
(10) t2 (/32): 0x00000050
(11) t3 (/32): 0x807D7CA0
(12) t4 (/32): 0x00000109
(13) t5 (/32): 0x00000000
(14) t6 (/32): 0xEFFFFFFA
(15) t7 (/32): 0x00000001
(16) s0 (/32): 0x80A3E42C
(17) s1 (/32): 0x0000000A
(18) s2 (/32): 0x00000050
(19) s3 (/32): 0x80196100
(20) s4 (/32): 0xFEDFFE95
(21) s5 (/32): 0xB9DFDFDF
(22) s6 (/32): 0xFEFFDD37
(23) s7 (/32): 0xDEDFFBC9
(24) t8 (/32): 0x00000000
(25) t9 (/32): 0x3548A4A8
(26) k0 (/32): 0x0000FC03
(27) k1 (/32): 0xFFFFFFFE
(28) gp (/32): 0x804DA890
(29) sp (/32): 0x80820870
(30) fp (/32): 0x7EFFEFCF
(31) ra (/32): 0x80003FFC
(32) status (/32): 0x0000FC01
(33) lo (/32): 0x851EBB0A
(34) hi (/32): 0x0000031B
(35) badvaddr (/32): 0xACED8496
(36) cause (/32): 0x10004400
(37) pc (/32): 0x800045A4
>

I’ve placed a copy of the modified firmware image up on github, along with the script used to build it. Note that this will not patch the bootloader, although upgrading the bootloader via a firmware update does appear to be supported; I’ll leave that as an exercise to the reader. ;)

Schneier on Security: MAESTRO-II: NSA Exploit of the Day

This post was syndicated from: Schneier on Security and was written by: schneier. Original post: at Schneier on Security

Today’s item from the NSA’s Tailored Access Operations (TAO) group implant catalog:

MAESTRO-II

(TS//SI//REL) MAESTRO-II is a miniaturized digital core packaged in a Multi-Chip Module (MCM) to be used in implants with size constraining concealments.

(TS//SI//REL) MAESTRO-II uses the TAO standard implant architecture. The architecture provides a robust, reconfigurable, standard digital platform resulting in a dramatic performance improvement over the obsolete HC12 microcontroller based designs. A development Printed Circuit Board (PCB) using packaged parts has been developed and is available as the standard platform. The MAESTRO-II Multi-Chip-Module (MCM) contain an ARM7 microcontroller, FPGA, Flash and SDRAM memories.

Status: Available — On The Shelf

Unit Cost: $3-4K

Page, with graphics, is here. General information about TAO and the catalog is here.

Finally — I think this is obvious, but many people are confused — I am not the one releasing these documents. Der Spiegel released these documents in December. Every national intelligence service, Internet organized crime syndicate, and clued terrorist organization has already pored over these pages. It’s us who haven’t really looked at, or talked about, these pages. That’s the point of these daily posts.

In the comments, feel free to discuss how the exploit works, how we might detect it, how it has probably been improved since the catalog entry in 2008, and so on.

SANS Internet Storm Center, InfoCON: green: Adobe Flash Player Emergency Patch, (Tue, Feb 4th)

This post was syndicated from: SANS Internet Storm Center, InfoCON: green and was written by: SANS Internet Storm Center, InfoCON: green. Original post: at SANS Internet Storm Center, InfoCON: green

Adobe today released an emergency patch for a vulnerability that is currently actively exploited. The patch addresses CVE-2014-0497. [1]

The address affects all Windows, OS X and Linux. for Windows/OS X, the current version is now 12.0.0.44 and for Linux 11.2.202.336. Google Chrome users need to update Google Chrome to fix the included version of Flash as do users of Internet Explorer 10 and 11. [2]

[1] http://helpx.adobe.com/security/products/flash-player/apsb14-04.html
[2] http://technet.microsoft.com/en-us/security/advisory/2755801

——
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Krebs on Security: Adobe Pushes Fix for Flash Zero-Day Attack

This post was syndicated from: Krebs on Security and was written by: BrianKrebs. Original post: at Krebs on Security

Adobe Systems Inc. is urging users of its Flash Player software to upgrade to a newer version released today. The company warns that an exploit targeting a previously unknown and critical Flash security vulnerability exists in the wild, and that this flaw allows attackers to take complete control over affected systems.

The latest versions that include the fix for this flaw (CVE-2014-0497) are listed by operating system in the chart below.

flash12-0-0-43

The Flash update brings the media player to version 12.0.0.44 for a majority of users on Windows and Mac OS X. This link will tell you which version of Flash your browser has installed. IE10/IE11 and Chrome should auto-update their versions of Flash to v. 12.0.0.44. If your version of Flash on Chrome (on either Windows, Mac or Linux) is not yet updated, you may just need to close and restart the browser. The version of Chrome that includes this fix is 32.0.1700.107 for Windows, Mac, and Linux (to learn what version of Chrome you have, click the stacked bars to the right at of the address bar, and select “About Google Chrome” from the drop down menu).

The most recent versions of Flash are available from the Adobe download center, but beware potentially unwanted add-ons, like McAfee Security Scan). To avoid this, uncheck the pre-checked box before downloading, or grab your OS-specific Flash download from here. Windows users who browse the Web with anything other than Internet Explorer will need to apply this patch twice, once with IE and again using the alternative browser (Firefox, Opera, e.g.).

Adobe did not include many details in its advisory about the nature of the attack that prompted this update, other than to credit two researchers from Kaspersky Lab for reporting the vulnerability. As such, this flaw may be related to this Feb. 3 blog post by Kaspersky, which references Adobe Flash in the context of a long-running cyber espionage campaign that Kaspersky has dubbed “The Mask”; the security firm says it plans to release more details about this campaign at its analyst summit next week.

Linux How-Tos and Linux Tutorials: How to Resize, Rename, Sort and Proof Photos from the Command Line

This post was syndicated from: Linux How-Tos and Linux Tutorials and was written by: Carla Schroder. Original post: at Linux How-Tos and Linux Tutorials

Today’s ImageMagick lesson covers how to resize images, change case on file extensions, convert file formats, construct a proof sheet of thumbnails, and search and sort photos by their Exif data.

The ImageMagick suite of image processing and manipulating commands has been around forever, and lurks in all kinds of places: it is the image-processing backend in Drupal, Lyx, OpenShot, and many more. ImageMagick is über-powerful, and because it is a command-line program you can build clever scripts with it and automate routine tasks. You can flip, mirror, resize, distort, shear, and rotate images; do special effects, edit colors, and draw lines and shapes; create thumbnails, galleries, and proof sheets. It supports a skillion image formats and has APIs for a horde of programming languages, such as MagickCore (C), MagickWand (C), Magick++ (C++), JMagick (Java), RMagick (Ruby), TclMagick (Tcl/TK), and several more.

The most worthy use of ImageMagick I have ever seen is to manipulate images for the Upside-down-Ternet, which is a slick script that uses iptables and ImageMagick to have fun with freeloaders who poach your wi-fi. It re-directs pages to Kittenwar! and mangles images on other pages.

man imagemagick lists all the commands. There is no imagemagick command. The display command opens a graphical editing interface (fig. 1).

fig-1 The view from Carla's back door in Imagemagick.

The original image was too large, so I resized it with convert:

$ convert fig-1.png -resize 550x fig-1-s.png

The resize value is the width in pixels. Width always comes first, and you can make sure by putting an x after the value, with no space. When you specify only the width then your new image will be exactly that width, and the height will automatically be in proportion. When you want to specify the height, give the height value prefixed with an x, like this:

$ convert fig-1.png -resize x250 fig-1-s.png

One thing you have to watch with the various ImageMagick commands is overwriting your original images. With convert you preserve your original and create the new file by giving it a different name.

Stop Shouting

Windows and a lot of cameras are like old people on Facebook: they shout at you in uppercase. My Canon camera writes filenames in uppercase, so they look like WP7_4117.CR2. You can easily make all file extensions lowercase with this Bash one-liner:

$ for file in *.CR2; do mv $file ${file%%.CR2}.cr2; done

Convert Formats

The convert command converts image file formats. You can modify the upper-to-lowercase incantation to batch-convert formats, like this example that converts .png to .jpg:

$ for file in *.png; do convert $file ${file%%.png}.jpg; done

This preserves your originals and creates new images in the new format with the same filename, like this:

$ ls
bittersweet.jpg              
bittersweet.png              
juniper-berries.jpg          
juniper-berries.png

The default quality level for .jpg files converted from other formats is 92. You can control it with the -quality option with values from 1 to 100, with 1 being maximum compression and crappiest quality, to 100 which is best quality and least compression. This example uses 75, which is a decent level for Web images:

$ for file in *.png; do convert -quality 75 $file ${file%%.png}.jpg; done

Proof Sheet

Now that you have a nice batch of images to admire, make a proof sheet so you can admire them all in a single .jpg:

$ montage -label '%f'-geometry 350x+7+7 '*.jpg' proof-sheet.jpg

This results in something like figure 2, with each image 350 pixels wide, borders of 7 pixels, and the filenames of each image. If you like a nice frame instead of a plain border, -frame [value in pixels] creates a border around each image, and -mattecolor [color] lets you select the border color if you don’t like the default meh gray. Color Names tells you the color codes.

fig-2 photo montage

As with all ImageMagick commands there are a squillion options. Use -pointsize 12 to set a font size of 12 points, or other sizes as you desire, and these options let you fine-tune the labels:

  • %b — file size on bytes
  • %m — file format
  • %G — image dimension in pixels
  • %Q — image compression level.

There are way more, and you can find them all at ImageMagick Escapes.

Extracting Exif

The identify command reads the Exif data of photographs. You can easily view a basic set of information:

$ identify kitten.jpg
kitten.jpg JPEG 3648x2736 3648x2736+0+0 8-bit DirectClass 4.402MB 0.000u 0:00.000

Want to see everything there is to know about your photos? Try this:

$ identify -verbose kitten.jpg

That is a deluge of data, so you can fine-tune it to look for specific information, like which photos with the .cr2 extension in the current directory were taken with a flash:

$ for file in *.cr2; do identify -format '%[exif:flash] [%f]' $file; done
16 [WP7_4272.cr2]
16 [WP7_4273.cr2]
9 [WP7_4274.cr2]
9 [WP7_4275.cr2]

So…9 and 16. Okay. What do those mean? The Exif flash tags are combinations of the following values:

0:  FlashDidNotFire
1:  FlashFired
2:  StrobeReturnLightDetected
4:  StrobeReturnLightNotDetected
8:  CompulsoryFlashMode
16: AutoMode
32: NoFlashFunction
64: RedEyeReductionMode

So 16 means the camera was in auto flash mode, but the flash did not fire. 9 means compulsory flash mode, and it did fire (8 + 1). So you can add an egrep incantation to find only the images where a flash was fired:

$ for file in *.cr2; do identify -format '%[exif:flash] [%f]' $file | egrep ^'1 |9 |17 |65 ' ; done

Note the spaces after each number in the egrep search pattern. That limits your search to those exact numbers, and filters out larger numbers like 11 and 9897 and such.

You can dig up any Exif tag you want with identify, and ImageMagick Escapes describes dozens of escapes to use. But it’s not a complete list, so the quickest way to see what tags you can search on is to run identify -verbose [filename], and then look at the output. It’s going to be different for different image file formats, and it’s going to differ according to whether the images have been edited, and the software used. Here is an abbreviated example:

$ identify -verbose WP7_4275.cr2
    date:create: 2014-01-29T16:35:34-08:00
    date:modify: 2014-01-29T16:35:34-08:00
    dng:Aperture: F5
    dng:FocalLength: 28.0 mm
    dng:ISOSpeed: 640
    dng:Lens: Canon EF 24-105mm f/4L IS
    dng:Model: EOS 7D
    exif:DateTime: 2013:12:25 15:59:28
    exif:Flash: 9
So you could extract some of these this way:
$ identify -format '%[exif:datetime] %[dng:aperture] %[dng:lens] %[dng:model]' WP7_4275.cr2        
2013:12:25 15:59:28 F5 Canon EF 24-105mm f/4L IS EOS 7D 

This gives you a powerful way to find photos with particular traits, such as lens, camera, flash or no flash, date, focal length, size, bit depth…if it’s in Exif you can find and sort it.

One more fun Exif tip: if you’re going to post photos online, you might want to strip the Exif data so you don’t give away too much information. You can do this with the mogrify command:

$ mogrify -strip kitten.jog

Or strip a whole directory of photos:

$ mogrify -strip /imagesforweb/*

Weird and true Exif fact: Even though it is a widely-used standard, it is not maintained by anyone. The current version, 2.3, was released in 2010 by Japan Electronics and Information Technology Industries Association (JEITA) and Camera and Imaging Products Association (CIPA). Since then it has been orphaned.

/dev/ttyS0 : Reversing the WRT120N’s Firmware Obfuscation

This post was syndicated from: /dev/ttyS0 and was written by: Craig. Original post: at /dev/ttyS0

It was recently brought to my attention that the firmware updates for the Linksys WRT120N were employing some unknown obfuscation. I thought this sounded interesting and decided to take a look.

The latest firmware update for the WRT120N didn’t give me much to work with:

Binwalk firmware update analysis

Binwalk firmware update analysis

As you can see, there is a small LZMA compressed block of data; this turned out to just be the HTML files for the router’s web interface. The majority of the firmware image is unidentified and very random. With nothing else to go on, curiosity got the best of me and I ordered one (truly, Amazon Prime is not the best thing to ever happen to my bank account).

Hardware Analysis


A first glance at the hardware showed that the WRT120N had a Atheros AR7240 SoC, a 2MB SPI flash chip, 32MB of RAM, and what appeared to be some serial and JTAG headers:

WRT120N PCB

WRT120N PCB

Looking to get some more insight into the device’s boot process, I started with the serial port:

UART Header

UART Header

I’ve talked about serial ports in detail elsewhere, so I won’t dwell on the methods used here. However, with a quick visual inspection and a multimeter it was easy to identify the serial port’s pinout as:

  • Pin 2 – RX
  • Pin 3 – TX
  • Pin 5 – Ground

The serial port runs at 115200 baud and provided some nice debug boot info:

$ sudo miniterm.py /dev/ttyUSB0 115200
--- Miniterm on /dev/ttyUSB0: 115200,8,N,1 ---
--- Quit: Ctrl+]  |  Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---



=======================================================================
Wireless Router WG7005G11-LF-88 Loader v0.03 build Feb  5 2009 15:59:08
                    Arcadyan Technology Corporation
=======================================================================
flash MX25L1605D found.

Copying boot params.....DONE

Press Space Bar 3 times to enter command mode ...
Flash Checking  Passed.

Unzipping firmware at 0x80002000 ... [ZIP 3] [ZIP 1]  done
In c_entry() function ...
install_exception 
install exception handler ...
install interrupt handler ...
ulVal: 0x484fb
Set GPIO #11 to OUTPUT
Set GPIO #1 to OUTPUT
Set GPIO #0 to OUTPUT
Set GPIO #6 to INPUT
Set GPIO #12 to INPUT
Timer 0 is requested
##### _ftext      = 0x80002000
##### _fdata      = 0x80447420
##### __bss_start = 0x804D5B04
##### end         = 0x81869518
##### Backup Data from 0x80447420 to 0x81871518~0x818FFBFC len 583396
##### Backup Data completed
##### Backup Data verified
[INIT] HardwareStartup ..
[INIT] System Log Pool startup ...
[INIT] MTinitialize ..
CPU Clock 350000000 Hz
init_US_counter : time1 = 270713 , time2 = 40272580, diff 40001867
US_counter = 70
 cnt1 41254774 cnt2 41256561, diff 1787
Runtime code version: v1.0.04
System startup...
[INIT] Memory COLOR 0, 1600000 bytes ..
[INIT] Memory COLOR 1, 1048576 bytes ..
[INIT] Memory COLOR 2, 2089200 bytes ..
[INIT] tcpip_startup ..
Data size: 1248266
e89754967e337d9f35e8290e231c9f92
Set flash memory layout to Boot Parameters found !!!
Bootcode version: v0.03
Serial number: JUT00L602233
Hardware version: 01A

...

The firmware looked to have been made by Arcadyan, and the ‘Unzipping firmware…’ message was particularly interesting; a bit of Googling turned up this post on reversing Arcadyan firmware obfuscation, though it appears to be different from the obfuscation used by the WRT120N.

The only interaction with the serial port was via the bootloader menu. During bootup you can break into the bootloader menu (press the space bar three times when prompted) and perform a few actions, like erasing flash and setting board options:

Press Space Bar 3 times to enter command mode ...123
Yes, Enter command mode ...


[WG7005G11-LF-88 Boot]:?

======================
 [U] Upload to Flash  
 [E] Erase Flash      
 [G] Run Runtime Code 
 [A] Set MAC Address 
 [#] Set Serial Number 
 [V] Set Board Version 
 [H] Set Options 
 [P] Print Boot Params 
 [I] Load ART From TFTP 
 [1] Set SKU Number 
 [2] Set PIN Number  
======================

Unfortunately, the bootloader doesn’t appear to provide any options for dumping the contents of RAM or flash. Although there is a JTAG header on the board, I opted for dumping the flash chip directly since JTAG dumps tend to be slow, and interfacing directly with SPI flash is trivial.

Pretty much anything that can speak SPI can be used to read the flash chip; I used an FTDI C232HM cable and the spiflash.py utility included with libmpsse:

$ sudo spiflash --read=flash.bin --size=$((0x200000)) --verify
FT232H Future Technology Devices International, Ltd initialized at 15000000 hertz
Reading 2097152 bytes starting at address 0x0...saved to flash.bin.
Verifying...success.

The flash chip contains three LZMA compressed blocks and some MIPS code, but the main firmware image is still unknown:

Flash analysis

Flash analysis

The first two blocks of LZMA compressed data are part of an alternate recovery image, and the MIPS code is the bootloader. Besides some footer data, the rest of the flash chip simply contains a verbatim copy of the firmware update file.

Bootloader Analysis


The bootloader, besides being responsible for de-obfuscating and loading the firmware image into memory, contains some interesting tidbits. I’ll skip the boring parts in which I find the bootloader’s load address, manually identify standard C functions, resolve jump table offsets, etc, and get to the good stuff.

First, very early in the boot process, the bootloader checks to see if the reset button has been pressed. If so, it starts up the “Tiny_ETCPIP_Kernel” image, which is the small LZMA-compressed recovery image, complete with a web interface:

Unzipping Tiny Kernel

Unzipping Tiny Kernel

This is nice to know; if you ever end up with a bad firmware update, holding the reset button during boot will allow you to un-brick your router.

There is also a hidden administrator mode in the bootloader’s UART menu:

Hidden bootloader menu

Hidden bootloader menu

Entering an option of ! will enable “administrator mode”; this unlocks a few other options, including the ability to read and write to memory:

[WG7005G11-LF-88 Boot]:!

Enter Administrator Mode !

======================
 [U] Upload to Flash  
 [E] Erase Flash      
 [G] Run Runtime Code 
 [M] Upload to Memory 
 [R] Read from Memory 
 [W] Write to Memory  
 [Y] Go to Memory     
 [A] Set MAC Address 
 [#] Set Serial Number 
 [V] Set Board Version 
 [H] Set Options 
 [P] Print Boot Params 
 [I] Load ART From TFTP 
 [1] Set SKU Number 
 [2] Set PIN Number  
======================

[WG7005G11-LF-88 Boot]:

The most interesting part of the bootloader, of course, is the code that loads the obfuscated firmware image into memory.

Obfuscation Analysis


De-obfuscation is performed by the load_os function, which is passed a pointer to the obfuscated image as well as an address where the image should be copied into memory:

load_os(0xBF040000, 0x80002000);

The de-obfuscation routine inside load_os is not complicated:

De-obfuscation routine

De-obfuscation routine

Basically, if the firmware image starts with the bytes 04 01 09 20 (which our obfuscated firmware image does), it enters the de-obfuscation routine which:

  • Swaps the two 32-byte blocks of data at offsets 0×04 and 0×68.
  • Nibble-swaps the first 32 bytes starting at offset 0×04
  • Byte-swaps each of the adjacent 32 bytes starting at offset 0×04

At this point, the data at offset 0×04 contains a valid LZMA header, which is then decompressed.

Implementing a de-obfuscation tool was trivial, and the WRT120N firmware can now be de-obfuscated and de-compressed:

$ ./wrt120n ./firmware/FW_WRT120N_1.0.07.002_US.bin ./deobfuscated.bin
Doing block swap...
Doing nibble-swap...
Doing byte-swap...
Saving data to ./deobfuscated.bin...
Done!
Analysis of de-obfuscated firmware

Analysis of de-obfuscated firmware

The de-obfuscation utility can be downloaded here for those interested.

Linux How-Tos and Linux Tutorials: How to Watch Live Streaming Video from the Command Line on Linux

This post was syndicated from: Linux How-Tos and Linux Tutorials and was written by: Linux How-Tos and Linux Tutorials. Original post: at Linux How-Tos and Linux Tutorials

There are quite a few popular live streaming services on the web (e.g., Dailymotion, YouTube Live, UStream, etc.). Most of these streaming services are accessed from a web browser via flash plugin. If you heavily use some of those services on Linux, you may notice that your web browser sometimes becomes unresponsive or otherwise consumes […]
Continue reading…

The post How to watch live streaming video from the command line on Linux appeared first on Xmodulo.

Read more at Xmodulo

Linux How-Tos and Linux Tutorials: A Collection of Secret Linux Humor

This post was syndicated from: Linux How-Tos and Linux Tutorials and was written by: Carla Schroder. Original post: at Linux How-Tos and Linux Tutorials

Who says Linux nerds can’t be funny? Enjoy this collection of amusing man pages and prank programs.

fig-1

Oneko the Cute Cursor-Chasing Kitty

oneko launches a tiny kitty cat that chases your mouse cursor. oneko has a number of options: -towindow makes the kitty climb to the top of the active window. -name [name] gives the kitty a name, like Spot. Then you can launch a second kitty to chase Spot:

$ oneko -name Spot
$ oneko -toname Spot

Other options include -tora for tiger stripes, -dog-sakura to run Sakura Kinomoto instead of a cat, and -tomoyo for Tomoyo Daidouji. Whoever they are.

xmoontool – Moon For The Sun / Werewolf Early Warning System

XMoontool is a fun antique program that still runs on modern Linux systems. The original moontool was written by John Walker (founder of Autodesk and co-author of AutoCAD) in 1987 for the SunView windowing system for SunOS. Then Ron Hitchens did some work on it, and in “September 1993- reported to Motif (as God intended) by Cary Sandvig”, which meant it could run on X11. This history is in the source code, in xmontool.c.

The current version, 3.0.3, dates back to 2006, and its age shows in jaggedy fonts and non-standard installation directories. It’s a source build so you will need a build environment (the build-essential package on Debian/Ubuntu/etc.) You’ll also need libXt-dev and libnova-dev. Run make and make install from the source directory, and both the executable and man page install into /usr/X11R6/ directory. What /usr/X11R6/ directory, you ask? The one that the xmoontool installer will create for itself, because that was reserved for X Window System, Version 11 Release 6 which is so obsolete it’s mummy dust.

Ron Hitchens wrote the man page which contains gems like the title, and these wise words of advice:

“…it displays a graphical representation of what the moon would look like right now if you were to go outside and look at it. (Go on, try it, the fresh air may do you some good)…For those who are lycanthropically inclined, the open window tells you when the next full moon will occur. This may or may not be something you’ll want to know.”

fig-2-xmoontool

xmoontools shows its age in its jaggedy fonts and tiny low-res moon image. Mr. Hitchens was kind enough to share some tips for anyone who wants to update and modernize it. When you examine the source files you won’t find any moon pictures because the icon images are bitmaps that were written out as ASCII numbers, and then compiled into the C source code.

“The imagery was not intended to be re-scalable, it was designed specifically for the 64×64 icon size. If I remember correctly, the code basically calculates where the shadow should fall on the image, then copies pixels one-by-one from the moon image, setting the ones in shadow to black (or dark blue for color) in the copy. If one were to make a more modern version, you’d probably build a mask and layer that over the image instead (in those days, we had exactly on bit per pixel on screen). It should be fairly easy to scale the calculations to compute the shadow for any sized image.

“If you really want to modernize it, I’d suggest starting with a more modern UI toolkit and new, higher resolution moon images. Once all the X Windows or SunWindows code is separated out, the remainder basically boils down to deciding how much of the moon to show. There are many ways to do that. The code in moontool/xmoontool is quite primitive because in those days we didn’t have a lot of pixels or memory to work with, or many useful image manipulation libraries, so we had to fondle the bits ourselves.”

If you decide to try this, please let us know the results in the comments.

Silly Man Pages

While we’re on the subject of humorous man pages, try the funny-manpages and asr-manpages packages. asr-manpages were collected from the old Usenet group alt.sysadmin.recovery. Which still exists, by the way, on Usenet and Google Groups. You’ll probably think that a lot of these are just plain dumb, but hopefully you’ll find some chuckles, and maybe get inspired to write your own silly man page. funny-manpages contains these joke man pages:

man 1fun date
man 1fun echo
man 1fun gong
man 1fun grope
man 1fun party
man 1fun rescrog
man 1fun rtfm
man 1fun rm
man 1fun tm
man 1fun xkill
man 1fun baby
man 1fun celibacy
man 1fun flog
man 1fun uubp
man 1fun condom
man 1fun flame
man 1fun xlart
man 6fun sex
man 3fun strfry
man 1fun egrope
man 1fun fgrope

asr-manpages has these:

man 8fun guru
man 8fun nuke
man 8fun bosskill
man 8fun knife
man 8fun pmsd
man 8fun ctluser
man 8fun luser
man 2fun people
man 1fun lart
man 1fun c
man 1fun slave
man 1fun sysadmin
man 1fun think
man 1fun whack
man 3fun chastise
man 8fun axe
man 8fun chainsaw
man 8fun cutter

fig-3-software-failure-2

None of these are real commands; they’re just joke man pages, which is why they’re set apart with the special section names. What, you say, you didn’t know that man pages have section names? Indeed they do, because all the man pages on your Linux system are part of a single giant manual. There are eleven sections, and it is good to know this because many commands have multiple man pages in the different sections, so you need to specify the section to get the one you want. More rarely they’re two different commands, like man 1 apt and man 8 apt. Read man 1 man to learn all about finding, reading, and formatting man pages, and man 7 man to learn how to write a man page.

BSOD Screensaver

The BSOD screensaver, which is part of Xscreensaver, still makes me do a doubletake even when I know it’s running. It displays kernel panic and scary warning messages from all kinds of operating systems: Windows, Linux, Atari, Mac, Apple, Solaris, and many more (figure 3). It’s very configurable and lets you choose the operating systems, duration of each screen, and various color effects.

xjokes Messes With Your Screen

xjokes is a harmless collection of pranks that flash on your screen and then disappear. xjokes includes four commands: yasiti, blackhole, mori1, and mori2mori1 and mori2 are especially alarming, because they cover your screen with images of a girl winking at you (figure 4).

blackhole briefly blanks the screen, and yasiti looks like a little four-toothed spinning blade in the center of the screen. If you’re not into pranks you could use these as reminders to get up and take a break by creating cron jobs to run them at scheduled intervals, like this example that runs mori2 every hour during work hours on weekdays:

$ crontab -e
# m h    dom mon dow   command
  0 8-17 *   *   1-5   /usr/games/mori2

If you want to get creative you can hack the source code and use your own images. The source code is simple, so you can easily find all references to the image files and change them to your own image. Then recompile and see how it looks.

fig-4-xjokes-2