Speaking at Toorcon Seattle, Twice

On April 18th, I'll be speaking at Toorcon Seattle at 8:35pm regarding a traffic light controller's firmware.
Inside a Traffic Light Controller's Firmware
The Econolite ASC/3 is a black-box device that manages traffic and pedestrian cross-walk lights. Having been given a unit and instructions to make it programmable from Matlab, I did what any self-respecting engineer would do. Namely, I disassembled its firmware, identified its checksumming algorithm, and mapped the relevant bytes of its file format. A bit of XML magic later, and I had a library for reading, writing, and signing configurations. This brief talk will discuss my adventure. It will not discuss forcing a green light or similar tomfoolery.

The following afternoon at 2:40, I'll be speaking at the same conference regarding msp430static.
Homegrown Analysis Tools for 16-bit Microcontroller Firmware
16-bit architectures are a playground for analysis tool developers. This talk will cover the author's development of a reverse-engineering tool for the MSP430. Both the tool and this talk feature function isolation, recovery of stripped symbol information, call-graph generation, simulation, and scripting. Rather than focusing on the usage of the tool, the intent of this talk is to demonstrate how members of the audience might write their own. Source code will be available online, and a personal walkthrough of the code will be performed during the Q&A session for those that are interested.

ImageCraft and AS430 Library Formats for the MSP430

by Travis Goodspeed <travis at utk.edu>
at the Extreme Measurement Communications Center
of the Oak Ridge National Laboratory

I've been playing with various MSP430 compilers lately in an attempt to add import macros to msp430static. GNU's objdump makes this trivially easy for mspgcc, but I haven't been so lucky with the other compilers. One exception is ImageCraft's compiler, whose library format is beautifully manageable. This short article will discuss that format, with sufficient depth that a decoder or encoder script may be written. I will also discuss another tool, the AS430 assembler, which uses a similar file format.

A free 4kb version is available at http://www.imagecraft.com/. It works perfectly in Linux, just run `wine iccv7430_demo.exe', installing it to /opt/iccv7430/. Once installed, the IDE can be launched by `wine /opt/iccv7430/bin/icc430ide.exe'.

The following image shows the opening lines of libc.a, which is in a relocatable object format similar to that of the AS430 linker's.

You can find a description of the linking format, here.

The S-line tells us that the object's symbol name is _abs. The T-line contains the object code, "00 00 0e 93 03 34 3e e0 ff ff 1e 53 30 41". This R-line specifies no relocation.

The code, which begins at the third byte of the T-line, disassembles to the following in word-wise notation:

0x930E cmp #0, r14
0x3403 jge +8
0xE03E XOR #0xFFFF,r14
0xFFFF
0x531E add #1, r14
0x4130 ret

Quite obviously, this inverts and adds 1 to r14 if its value is less than 0. In C,

int _abs(int x){
  if(x<0)
    return -x;
  else
    return x;
}

It's worth noting that r14 can be inverted with a single word, 0xE33E, rather than the two used here by use of the constant generator. That is exactly what GCC does:

   0:   0f 93           cmp     #0,     r15     ;r3 As==00
   2:   02 34           jge     $+6             ;abs 0x8
   4:   3f e3           inv     r15             ;
   6:   1f 53           inc     r15             ;
   8:   30 41           ret

Getting back to the format at hand, AS430 may be downloaded here. Go for the latter link, as it's direct and doesn't require that you run Simtel's win32 downloader application.

Once downloaded, Linux users should install by use of the following commands:

karen% sudo ln -s `pwd`/ASXMAK/LINUX/EXE/AS430 /usr/local/bin/as430
karen% sudo chmod +x ASXMAK/LINUX/EXE/*
karen% 

Moving the T430.ASM example to T430.asm, calling "as430 -o T430" creates T430.rel, in the same relocatable object format used above. It's rather inconvenient that the tool is case-sensitive and windows-oriented, but it works well in Linux once you recognize its difficulty with case-sensitive filesystems.

Object division is different in ImageCraft. Note the ^M entries in the screenshot, which in emacs denote a CR. The entries only exist between the .begin/.end macros, suggesting that the file was produced with more than one tool. This makes sense: one tool is the archiver, while the other is the assembler. The archiver uses LF, as in Unix textfiles, while the assembler uses CRLF, as in DOS textfiles.

Just to be sure this would ship in production code, I used abs() in an example project and found the following in the output ihex:

:14F064000495FD3B30410E9303343EE0FFFF1E53304130410

'3EE0FFFF' is the little-endian equivalent of '0xE03E 0xFFFF' above.

Some other formats, all of them ASCII, deserve mention here. The first being the debug format, which is built into PROJECT.dbg by the IDE.

IMAGECRAFT DEBUG FORMAT
VERSION 1.2
CPU MSP430
FRAMEPOINTER R1
DIR z:\home\travis\tmp\icc\
FILE foo.c
FUNC main F052 fV
BLOCK 3 F052
DEFREG x 5 I
DEFREG y 4 I
LINE 3 F052
LINE 4 F052
LINE 5 F05E
LINE 6 F060
LINE 6 F062
LINE 6 F062
LINE 6 F064
BLOCKEND 0 F068
FUNCEND F068
FILE foo.s
LINE 16 F052
LINE 17 F056
LINE 18 F05A
LINE 19 F05C
LINE 22 F05E
LINE 25 F060
LINE 30 F062
LINE 33 F064
LINE 34 F066
LINE 38 F068
START F000

This is easy enough to read. FILE defines a source file, FUNC defines a function, BLOCK defines a region of code, DEFREG defines which register a variable is contained within, and LINE denotes the address to which a particular line has been compiled.

PROJECT.lst contains annotated machine code. PROJECT.mp describes memory areas and linking information.

PROJECT.mak is a makefile. Building from the command-line works perfectly with the proper environment variables, but without them the unregistered version will refuse to run outside of the IDE.

karen% wine /opt/iccv7430/bin/imakew.exe -f FOO.mak 
    icc430 -c -IC:\icc\include\ -e -D__ICC_VERSION="V7.06A" -DF148  -l -g -Wf-hwmult -Wa-g  z:\home\travis\tmp\icc\foo.c
    icc430 -o FOO -LC:\icc\lib\ -g -blit:0xF000.0xFFDF -bdata:0x0200.0x0A00 -dram_end:0x0A00 -fintelhex -binfo:0x1000 @FOO.lk  
Device 3% full.
karen% 

I like the ASCII nature of the compiler's file formats, which makes them very easy to parse. For this reason, the compiler was the first after GCC to be supported in msp430static.

Speaking April 4th at UT, Knoxville

I'll be repeating my Texas Instruments Developer Conference talk in room 206 of Claxton Hall at the University of Tennessee, Knoxville on Friday, April 4th from five to seven o'clock for the local chapter of the ACM. The abstract follows:

Stack Overflow Exploits for Wireless Sensor Networks Over 802.15.4

Stack overflows have been a threat to security since the early 1980s,
but developers consistently leave such vulnerabilities open to attackers
because of mistakes in boundary checking.  These mistakes are quickly
found and either fixed or exploited on servers and personal computers.
In industrial embedded systems, however, they are often left in deployed
products because of high replacement costs and the perceived difficulty
level of an attacker reaching the deployed system.  IEEE 802.15.4,
Zigbee (R), ISA100 and wireless sensor networks using these protocols
are fertile ground for such exploits.  This presentation presents an
application-layer protocol implementation that is vulnerable to a buffer
overflow, showing step-by-step how an attacker could write an exploit
that injects and executes arbitrary machine code over the air -- and how
you can prevent such an attack.  The target system is a Telos B wireless
sensor node running TinyOS 2.x on the TI MSP430 microcontroller with a
TI/Chipcon CC2420 radio.

Please email me, travis at utk.edu, if you are interested in attending a hands-on workshop later that evening.

ImageCraft V7 Symbol Importing for MSP430static

by Travis Goodspeed <travis at utk.edu>
at the Extreme Measurement Communications Center
of the Oak Ridge National Laboratory

I just committed r38 of msp430static which adds support for importing symbols from ImageCraft V7 for MSP430. A short example follows.

I'll use the following C code, but any will suffice.

void main(){
         int x=0xFFFF;
         x+=1;
         x+=0xFFFF;
         x+=abs(5);
}

Compiling it yields many files. The two of interest are FOO.hex and FOO.mp. The former is imported by converting it to msp430-elf and dumping the resulting ELF file.

karen% msp430-objcopy -I ihex -O elf32-msp430  FOO.hex foo.exe
karen% msp430-objdump -D foo.exe | m4s init
karen%

Symbols are then imported with the .symbols.import.ic7 macro.

karen% m4s .symbols.import.ic7 <FOO.mp
karen%

At this point, msp430static knows the name of every function in my image. Here is the callgraph of my program above.


Note that my examples are in Linux. ICC 7 works perfectly as both an IDE and compiler under Wine.