Apple Quarentine & Weird Linker Errors

I’ve been working on a project writing a few passes in LLVM. At some point I started getting linker errors when I tried to compile…

Error opening '/opt/llvm-3.4/Debug+Asserts/lib/LLVMMyLib.dylib': dlopen(/opt/llvm-3.4/Debug+Asserts/lib/LLVMMyLib.dylib, 9): Symbol not found: __ZTVN4llvm17MyClassE
Referenced from: /opt/llvm-3.4/Debug+Asserts/lib/LLVMMyLib.dylib
Expected in: flat namespace
in /opt/llvm-3.4/Debug+Asserts/lib/LLVMMyLib.dylib
-load request ignored.

I spent an hour or so trying to debug this little program and figure out where these linker issues were coming from. At some point, I ran the following:

$ ls -al
total 88
drwxr-xr-x   9 root  wheel   306B Mar 11 16:20 ./
drwxr-xr-x  14 root  wheel   476B Mar  3 16:30 ../
-rw-r--r--   1 root  wheel   296B Mar  3 16:55 CMakeLists.txt
-rw-r--r--@  1 root  wheel   3.7K Mar 10 15:33 MyLib.cpp
-rw-r--r--@  1 root  wheel   2.1K Mar  3 16:34 MyLib.h
-rw-r--r--   1 root  wheel   660B Mar 10 15:46 Makefile

Curious about what the @ symbol meant I turned to google and learned it means the file has extended attributes and you can use the command xattr to view the extended attributes. It turns out that OS X had decided to mark my project with, which it reserves for files it suspects to be malicious. Unfortunately I’ve been unable determine why exactly this happened or what triggered it.

For more information on



I’ve been working on setting up my development environment for the new Wolverine chip from TI (MSP430FR5969) and wanted to document what I did to get it up and running.

One of the constraints that we wanted to meet was using freely available software so that other research groups would be able to replicate and expand on our work. Now, IAR and CCS both have free licenses, but they are code size limited (4k and 16k respectively) such that we can’t fully utilize the Wolverine chip. As such we instead decided to use mspgcc and mspdebug. Thankfully, both of these tools are available on the Ubuntu repositories. For our programmer we used the FET430UIF. I’ll also note that I started off using a fresh Ubuntu 12.04 install but later upgraded to 12.10 for the sake of the repository versions of msp430-gcc and other utilities.

One of the difficulties we ran into, was getting mspdebug working with the Wolverine chip. After receiving a good deal of help from Daniel Beer (the author of mspdebug), I learned that using a FET430UIF with v3 of the firmware could used to program the Wolverine chip on linux by compiling TI’s new open source library.

By following the installation instructions on TI’s page and applying the patch for the matching version I was able to compile the library. Below are the commands I used after downloading TI’s open source code and placed the required third party software in the ThirdParty/ directory.

# Download Dependencies
sudo apt-get install g++ git cmake libusb-dev autotools-dev autoconf automake libtool libudev-dev libusb-1.0-0-dev libfox-1.6-dev libboost-all-dev libreadline6 libreadline6-dev

# Apply the patch
cd ~/Downloads/MSPDebugStack_OS_Package/..
patch -p0 < slac460g_unix.diff

# Install third party programs
cd MSPDebugStack_OS_Package/ThirdParty
chmod +x

# Building and installing the library
export BOOST_DIR=~/Downloads/MSPDebugStack_OS_Package/ThirdParty/boost_version_#/
sudo make install
sudo ldconfig

When I tried to run it with mspdebug I realized the Ubuntu repo was using an older version of mspdebug. By pulling from mspdebug’s git repo and compiling from source I was able to fix these problems.

cd ~/Downloads
git clone git:// mspdebug
sudo make install

…and you should be able to run the following…

$ sudo mspdebug tilib
[sudo] password for mspdev:
MSPDebug version 0.22 - debugging tool for MSP430 MCUs
Copyright (C) 2009-2013 Daniel Beer
This is free software; see the source for copying conditions. There is NO

Found FET: ttyACM0
MSP430_Initialize: ttyACM0
Firmware version is 30301004
MSP430_VCC: 3000 mV
Device: MSP430FR5969 (id = 0x010f)
3 breakpoints available
Chip ID data: 69 81 12

Available commands:
= erase isearch power save_raw simio
alias exit load prog set step
break fill load_raw read setbreak sym
cgraph gdb md regs setwatch verify
delbreak help mw reset setwatch_r verify_raw
dis hexout opt run setwatch_w

Available options:
color gdb_loop
enable_bsl_access gdbc_xfer_size
enable_locked_flash_access iradix
fet_block_size quiet

Type “help ” for more information.
Use the “opt” command (“help opt”) to set options.
Press Ctrl+D to quit.

(mspdebug) _

Tips n’ Tricks

  • Use a boost library >= 1.47.0
  • Use IAR or CCS to update FET430UIF without worrying too much about bricking your FET
  • Use Ubuntu 12.10 or later enable pulling from the latest repositories
  • v2 of the FET430UIF blinks {red, red, red, green} on initialization while v3 goes straight to green

Fuzzing: Setting up the Target

In order to get useful results while from fuzzing our target application, we need to first set up the target machine to include a debugger and an agent to log crashes and restart the target application after a crash. For this we’ll be using the following applications:

  • WinDbg
  • !exploitable (WinDbg plugin)
  • Peach Fuzzer



WinDbg is a debugging platform provided by Microsoft for debugging both user level programs and kernel level code. Attaching WinDbg to our target application will enable us to retrieve detailed information about it post-mortem.

WinDbg is freely available from Microsoft as a part of their SDK that is posted here. You don’t have to install the SDK itself or a number of the other tools that are packaged along with it.


!exploitable is a WinDbg plugin used to create automated crash reports and risk assessments. It can classify the likeliness of a crash being the result of an exploitable vulnerability. We will log the output from !exploitable and WinDbg.

!exploitable is freely available here. You can unzip the directory and copy the contents of msecextensions/<x86 or x64>/Release to C:/Program Files (x86)\Windows Kits\8.0\Debuggers\<x86 or x64>\.


Peach is not only our fuzzing platform but we will also use it’s agent on the target machine to facilitate restarting the target application and logging the information from WinDbg and !exploitable.

  1. Install the Microsoft .NET V4 Framework.
  2. If you didn’t install WinDbg before… do it
  3. Download the binary release of Peach and unzip to a working directory

By running Peach on the target machine with a copy of the Peach pit file we are using for fuzzing, Peach will automatically restart the target application and store crash information from WinDbg when it finds a value that crashes the software.

Fuzzing: Use all the fuzzers!

My first project with SPQR is a vulnerability assessment of an anesthesia machine. Unfortunately we do not have 24/7 access to the machine and we are still trying to schedule our first meeting. In order to get the most out of the time we do have with it I’ve been working on compiling a list of tools, their uses, and tutorials I’ve been going through to get up to speed on them.

Right now this is taking the format of a dump of urls I’ve found useful, hopefully over the next few days I’ll be adding posts specific to tools describing their use.

Fuzzing Frameworks

Peach – Fuzzing framework that uses xml “peach-pits” to “intelligently” fuzz an application. Requires prior knowledge of a protocol in order to generate and mutate fuzzing inputs. Peach is one of the few free fuzzers that is still in active development. Most of the other fuzzers have fallen by the way side over the past few years. Another benefit of Peach is that it allows for running the tests automatically (rather than causing a crash and requiring human interaction to relaunch) as well as automatic logging of debug information.
Example file format fuzzing:
Network fuzzing (more interesting):

SPIKE – A fuzz scripting framework. More hands on than peach, scripting out each event and using the SPIKE API to define the packet structure. Downside is it lacks a way to restart crashed applications, requiring a manual restart instead. It has also been out of development for a while, it seems to have been “replaced” by Sulley.

Sulley – Aimed to be more powerful than SPIKE while retaining ease of use. No longer in development. Need to investigate further…

Web App Specific Fuzzers

Burp – Web proxy scanner/fuzzer. Fancy user interface that couples with a proxy server to inspect packets being sent/received and identify potential vulnerabilities. Requires human intuition to find potentially exploitable fields but given the fields it will automate the fuzzing. (XSS, SQL inject, brute force login)

For a more detailed comparison of fuzzing tools:

These are only a few of the fuzzing tools out there, for more tools use your google-fu to find stuff like this: