Monthly Archives: August 2010

Inception Movie Review from a Data Security Perspective

This is part of my ongoing series of extremely limited perspective movie reviews:

Previous Reviews:

Like the previous ones: SPOILER ALERT. Inception is the kind of movie where you might not want to know anything going in. So, please don’t read further if you don’t want any part of the plot spoiled.

In Inception there’s an elite team that can infiltrate your subconscious while you’re dreaming and extract secret information while your defenses are down. The plot of the movie is set up when someone asks them if they can do an “inception” where they plant an idea into a victim’s subconscious. Since the idea is detrimental to the victim, they must somehow convince him that it is his, and that it will be good for him to follow through with it.

Obviously, extraction directly relates to data security, and the attacks and defenses that are discussed in the movie have analogous ones in the security world. An obvious one is a honeypot and how it relates to the labyrinths that the dream architects construct.

[Honeypots] computers run special software, designed to appear to an intruder as being important and worth looking into. In reality, these programs are dummies, and their patterns are constructed specifically to foster interest in attackers.

Creating a honeypot is like “taking two minutes to create a maze that takes a minute to solve.”

Things like a “militarized subconscious”, “totems”, and “forgers” have counterparts in the network security world.

But, what about “inception”? After thinking about it for a few minutes, I remembered this story from WWII. In 1943, the Allies wanted to convince the Germans that they would attack through Sardinia, not Sicily, so:

The idea, very simply, was to get a dead body, equip the dead body with false papers, and then drop it somewhere the Germans would find it

[…] And it was an elaborate creation: the fictitious Major Martin was equipped with ticket stubs, keys, a religious medal, letters from an imaginary father and fiancee, and unpaid bills. Cholmondeley and Montagu thought that the more convincing his personal story was, the more likely the Germans would be to believe the ruse. And along with the personal items, he carried carefully faked letters hinting that the Allies were planning to invade Greece and Sardinia, not Sicily.

But, this is not a computer attack. While the idea of data tampering is nothing new, I haven’t heard of a tampering attack with the intent to mislead someone into making a bad decision. Data tampering is often used to gain access for another purpose or to cover up tracks (e.g. log tampering).

But, I suspect that this is a real threat as well. One so good, that it  often goes undetected.

Making Xcode’s Build and Analyze much better

A few weeks ago, I discovered that the Build and Analyze in Xcode didn’t find as many problems as scan-build did directly when you turn all options on.

On the Clang analyzer site, they have instructions for setting up the latest analyzer so that Xcode would use it. Unfortunately, the settings that find some very common problems are off by default. Here are instructions for getting the Clang analyzer to run with those options on.

To make sure you are doing it right, make your project completely succeed a Build and Analyze, then comment out a release that you are doing in any dealloc. Rerun Build and Analyze — it should not find this problem.

Then,

1. If you don’t have it, download and untar the latest checker
2. Make a script file called full-analyze-clang and put it in the checker’s bin directory, with this code

#!/bin/bash
CLANG="`dirname $0`/clang"
CLANG_CMD="\"$CLANG\" -Xanalyzer -analyzer-check-objc-missing-dealloc -Xanalyzer -analyzer-check-objc-missing-dealloc -Xanalyzer -analyzer-experimental-internal-checks $*"
eval $CLANG_CMD

3. From the Terminal, run this command to make the script executable

chmod +x full-analyze-clang

4. In the checker root directory, there is a script called set-xcode-analyzer. Run it like this:

sudo ./set-xcode-analyzer --use-checker-build=FULL_PATH_TO_CHECKER/bin/full-analyze-clang

replacing FULL_PATH_TO_CHECKER with the path to the checker directory where you untarred it in step 1.

5. To test, Run the Build and Analyze on the project you set up with the bad dealloc. If it finds 0 errors, this could be because something is wrong with the way the script is set up.

Important parts if this stops working with a future clang:
The set-xcode-analyzer expects a directory or a full-path to clang. It checks to see it has a full-path by looking for a path ending with “clang”, which works for us because our script’s name ends in “clang”. If they change this script in the future, this might not work

Build and Analyze just reports a successful build if our script reports errors — it’s just looking for the existence of result files. You might need to add logging lines to the script to figure out what’s going on. Log to a full-path because the current directory is inside Xcode’s path somewhere when the script is run.

Use something like this as your last line to debug:

eval $CLANG_CMD > `dirname $0`/cl.out 2> `dirname $0`/cl.err

Get iPhone programming tips in your inbox with my Beginner iPhone Programming Tips newsletter.