This is the Python program I wrote to take a picture every minute:
#!/usr/bin/python
__description__ = 'Tool to take pictures with a Nokia phone at regular intervals'
__author__ = 'Didier Stevens'
__version__ = '0.1.1'
__date__ = '2009/06/22'
"""
Source code put in public domain by Didier Stevens, no Copyright
https://DidierStevens.com
Use at your own risk
History:
2009/06/17: start
2009/06/22: refactoring
Todo:
Get Threading to work
"""
import camera
import time
import os
timelapseFolder = 'e:\\timelapse\\'
sleepTime = 57
def TakeAndSavePicture():
global timelapseFolder
now = '%04d%02d%02d-%02d%02d%02d' % time.localtime()[0:6]
pic = camera.take_photo()
pic.save(os.path.join(timelapseFolder, now, '.jpeg'))
print 'Picture taken: %s' % now
def Main():
global timelapseFolder
global sleepTime
print 'Timelapse photography started'
if not os.path.isdir(timelapseFolder):
os.mkdir(timelapseFolder)
print 'Timelapse folder created: %s' % timelapseFolder
print 'Wait between pictures %d' % sleepTime
while True:
TakeAndSavePicture()
time.sleep(sleepTime)
if __name__ == '__main__':
Main()
And then I use Avisynth to combine the jpeg pictures in a movie like this (I join pictures 00001.jpg through 00197.jpeg, 5 per second and produce a 25 fps movie):
The XBee shields I obtained use a XBee series 2 module, while the instructions on the Arduino site are for the older XBee module.
After configuring one of my XBee modules as coordinator, the XBee modules were able to communicate with each other.
You need the X-CTU configuration program to configure an XBee series 2 module as coordinator. To connect the XBee module to your PC, you’ve to:
1) remove the ATmega µp from the Arduino board (remember the orientation of the ATmega chip to put it back afterwards):
2: set the jumpers on the XBee shield to USB:
3) Connect the XBee shield to the Arduino, and then connect the Arduino via USB to your computer, run the X-CTU configuration program and read the configuration:
4) Select the coordinator function set and write it to the XBee module:
When the XBee module has restarted and if your other XBee module is powered on, you’ll see the LEDs of both modules starting to flash, indicating they formed a WPAN network.
After configuring the XBee module, revert to the original hardware configuration: disconnect the Arduino board from your PC, set the jumpers on the XBee shield back to XBee and reinsert your ATmega µp in the Arduino board (watch out for the polarity of the chip).
In response to Bruce Schneier’s latest post, let me explain how you can corrupt your own PDF documents for free. Open your PDF document with a binary editor, search for references to the root object (/Root), and overwrite the reference (36 in my example) with a non-existing reference, like 00.
This useless Python program is the result of some lazy Sunday coding. It will create random tweets based on a template file. You could use it to try to protect your privacy on Twitter by disinforming potential data miners.
Will I use it for my Twitter account? No, I don’t need a program to disinform
Each time you run the program, it will post one random tweet. This tweet is generated from a templates file. Each line in the templates file is the template for a tweet. You can use variables (between curly braces, example: {location}) in the templates to increase the number of possible tweets. Variables and their values are also stored in the template file, after the template lines. Your template file must allow the program to generate at least 2 different tweets, because it generates a tweet different from the last tweet.
And you need to create a credentials file (disinformational-tweets.cred) with the Twitter credentials of the account for which the program has to generate random Tweets. The first line of the credentials file has to contain the username, the second line has to contain the password.
A Firefox plugin to generate these tweets would probably be more ‘useful’, but hey, it’s a lazy Sunday.
Here’s an alternate use for your Poken: use it to detect 125 kHz RFID readers. Its led will blink red when you bring it next to a LF RFID reader (125 kHz). It will not react with a 13.56 MHz reader; and I haven’t tested with a 134.2 kHz reader.
This is a beta release of my new version of PDFiD tool because Adobe recommends disabling JavaScript to protect yourself against the new vulnerabilities in JavaScript functions getAnnots() and spell.customDictionaryOpen().
PDFiD version 0.0.6 has several new features which I’ll explain in a later post. Now I want to explain the disarm feature. Disarm will disable JavaScript inside the PDF document.
Command “PDFiD -d document.pdf ” will analyze the PDF document and generate a new version called document.disarmed.pdf.
In this new version, names /AA, /OpenAction, /JS and /JavaScript have their case swapped (/aa, /oPENaCTION, /jsand /jAVAsCRIPT). As the PDF language is case sentitive, these new names have no meaning and therefor the automatic actions and scripts are effectively disabled. All PDF readers I’ve used just ignore unknown names, they don’t generate and error or stop rendering the document.
This substitution trick will not work if the actions and scripts are hidden in object streams (/ObjStm) and could render a document unreadable if encryption is used.
My training by Saumil Shah was excellent! Highly recommended if you want to learn exploit development without reversing.
I didn’t attend a lot of briefings, the subjects were less interesting to me than past years. But I did a lot of networking, I met many interesting people. I had lunch with Moxie Marlinspike, the author of SSLStrip. He has interesting viewpoints: did you know he started to develop SSLStrip in 2002? It’s only because he was done experimenting with it that he decided to disclose! And we share a common interest in CRASS.
Thanks to everybody I met at BH, the networking was excellent! I estimate I distributed 50 of my PDF stickers . You gave me a lot of ideas that will require even more time to develop. Like past years, I got a new stego idea but this time, I’m reserving it for Brucon’s hacker challenge. You’ll have to wait for October for the disclosure.
This year was also the first time I had a 2D-barcode on my badge:
The above picture doesn’t actually show my real barcode, but one I made for this post. My real barcode contains my business coordinates. A hint if you want to find out what’s on this one: it’s a PDF417 barcode (this PDF stands for Portable Data File, not Portable Document Format).
My previous blogpost showed how minimal user interaction can still get a malicious PDF document to infect a machine. Remembering F-Secure’s misadventure with .WMF and Google Desktop Search, I took some time to look at Windows Indexing Service. The news is not good. This time, I can get a PoC PDF document to trigger the /JBIG2Decode bug without any user interaction whatsoever. And the bug happens in a process running with Local System rights!
On a Windows XP SP2 machine with Windows Indexing Services started and Adobe Acrobat Reader 9.0 installed, there is absolutely no user interaction required to trigger the /JBIG2Decode vulnerability. When the PoC PDF file is on the disk, it will be indexed by Windows Indexing Services and the buggy /JBIG2Decode code will be executed.
When Adobe Acrobat Reader 9.0 is installed, it also installs an IFilter (AcroRdIF.dll). This COM object extends the Windows Indexing Service with the capability to read and index PDF documents. When the Windows Indexing Service encounters a PDF file, it will index it. The content indexing daemon (cidaemon.exe) calls the Acrobat IFilter (AcroRdIF.dll) which loads the Acrobat PDF parser (AcroRD32.dll). If the PDF document contains a malformed /JBIG2Decode stream object, it will result in an access violation in the instruction at 0×01A7D89A.
In other words, if you’ve a malicious PDF document on a machine with Windows Indexing Services, it can infect your machine. And you don’t need a user to open or select the PDF document.
The good news is that Windows Indexing Services is not started on a default Windows XP SP2 install. Update: Although Windows Indexing Services is not on by default, after you’ve executed a search as local admin, you’ll be asked if you want “to make future searches faster”. If you answer yes, Windows Indexing Services will be automatically started.
The bad news is that Windows Indexing Services runs under the local system account on Windows XP SP2. This results in a privilege escalation.
Consider a Windows machine with Windows Indexing Services running, Adobe Acrobat reader installed and a file sharing service (FTP/IIS/P2P/…). Uploading a specially crafted PDF document to this machine will give you a local system shell.
To disable Windows Indexing Services’ capability to index PDF documents, unregister the IFilter: regsvr32 /u AcroRdIf.dll
My PoC PDF file also triggers in /JBIG2Decode in Windows Desktop Search (I tested version 4.0). But Windows Desktop Search has a better security architecture than Windows Indexing Service. Although the service runs under the Local System account, the actual calling of the IFilters is done in a separate process that runs under the Local Service account (this account has less privileges and can’t take full control of the machine).
I’ve not analyzed other applications using IFilters. If you use ScarePoint (that’s how my wife, who has to work with it, calls it) or another IFilter supporting application and you want to be safe, unregister the Acrobat IFilter.
And don’t forget that, depending on your Windows version and CPU, you’re also protected by technologies like DEP and ASLR.
Google Desktop Search doesn’t use IFilters, unless you’ve installed this plugin to add IFilter support to Google Desktop Search.
Sometimes a piece of malware can execute without even opening the file. As this is the case with the /JBIG2Decode vulnerability in PDF documents, I took the time to produce a short video showing 3 ways the vulnerability can trigger without even opening the PDF document.
The first 2 demos use a “classic” /JBIG2Decode PDF exploit, the third demo uses a new PoC /JBIG2Decode PDF exploit I developed. This PDF document has a malformed /JBIG2Decode stream object in the metadata instead of the page. All PDF documents used have just a malformed /JBIG2Decode stream object, they don’t include a payload (shellcode), neither a JavaScript heap spray.
So how is it possible to exploit this vulnerability in a PDF document without having the user open this document? The answer lies in Windows Explorer Shell Extensions. Have you noticed that when you install a program like WinZip, an entry is added to the right-click menu to help you compress and extract files? This is done with a special program (a shell extension) installed by the WinZIp setup program.
When you install Adobe Acrobat Reader, a Column Handler Shell Extension is installed. A column handler is a special program (a COM object) that will provide Windows Explorer with additional data to display (in extra columns) for the file types the column handler supports. The PDF column handler adds a few extra columns, like the Title. When a PDF document is listed in a Windows Explorer windows, the PDF column handler shell extension will be called by Windows Explorer when it needs the additional column info. The PDF column handler will read the PDF document to extract the necessary info, like the Title, Author, …
This explains how the PDF vulnerability can be exploited without you opening the PDF document. Under the right circumstances, a Windows Explorer Shell Extension will read the PDF document to provide extra information, and in doing so, it will execute the buggy code and trigger the vulnerability. Just like it would when you would explicitly open the document. In fact, we could say that the document is opened implictly, because of your actions with Windows Explorer.
So let me demo 3 circumstances under which a PDF Shell Extension will act and thereby trigger the vulnerability. One important detail before I do this: when the exception occurs in the Adobe Acrobat code, it is trapped by Windows Explorer without any alert. That’s why in the demos, I attached a debugger (ODBG) to Windows Explorer to intercept and visualize this exception. So each time the vulnerability triggers, the view switches to the debugger to display the exception.
In the first demo, I just select the PDF document with one click. This is enough to exploit the vulnerability, because the PDF document is implicitly read to gather extra information.
In the second demo, I change the view to Thumbnails view. In a thumbnail view, the first page of a PDF document is rendered to be displayed in a thumbnail. Rendering the first page implies reading the PDF document, and hence triggering the vulnerability.
In the third demo, I use my special PDF document with the malformed stream object in the metadata. When I hover with the mouse cursor over the document (I don’t click), a tooltip will appear with the file properties and metadata. But with my specially crafted PDF document, the vulnerability is triggered because the metadata is read to display the tooltip…
So be very careful when you handle malicious files. You could execute it inadvertently, even without double-clicking the file. That’s why I always change the extension of malware (trojan.exe becomes trojan.exe.virus) and handle them in an isolated virus lab. Outside of that lab, I encrypt the malware.
