Didier Stevens

Wednesday 20 May 2009

Download My Hakin9 Article “Anatomy of Malicious PDF Documents”

Filed under: Malware,PDF — Didier Stevens @ 18:21

Hakin9 has released my article “Anatomy of Malicious PDF Documents” from their latest issue. Get it here in exchange for an e-mail address.


Tuesday 19 May 2009

Another Lowcost RFID Detector

Filed under: Hardware,RFID,smart card — Didier Stevens @ 21:30

Patrick Gueulle published a logging program (French article) for BasicCards. A BasicCard is a smartcard programmable in a variant of the BASIC language. Patrick’s BasicSPY program logs all APDU requests to a file stored on the smartcard. After using the BasicCard programmed with BasicSPY in a reader, you can retrieve the log file and observe the commands send by the reader to the card.

Patrick’s terminal program to manage the internal file (I translated the menu to English):


A new type of BasicCard was announced in January: the Dual Interface BasicCard. This smartcard also has a contactless ISO14443/A interface. In other words, this smartcard has a HF RFID interface!

This smartcard is handy to make another lowcost RFID detector: I install BasicSPY on my Dual Interface BasicCard and hold it against an (unknown) RFID reader. When the reader supports ISO14443/A , it will send APDUs to the BasicCard which will log them in the internal file. Later retrieval of the internal file reveals the APDUs send to the smartcard:



Thursday 14 May 2009

Malformed PDF Documents

Filed under: Malware,My Software,PDF — Didier Stevens @ 7:55

For the sake of this post, I consider a PDF document malformed when it doesn’t observe the basic structure of a PDF document.

I’ve seen a couple of malicious, malformed PDF documents. The most recent was a malicious swine flu PDF document that contains another, bening, PDF document with information about the swine flu (obtained from the CDC site). This second PDF document is displayed to mislead the user while the exploit runs.


This second PDF document is XOR-encoded and appended to the end of the malicious PDF document, making the malicious PDF document malformed (FYI: the PDF file format supports embedded files, but this wasn’t used here). A PDF reader like Adobe or Foxit has no problems opening this malformed PDF, because it scans a PDF document for the trailer (%%EOF) starting from the end of the document. Everything that follows this trailer and doesn’t adhere to the PDF syntax is just ignored.


I’ve added some new features to my PDF tools to handle malformed PDF documents.


The new version of PDFiD has an –extra option. Like it names imply, use it to add extra analysis data to the PDFiD report. The extra option adds entropy calculations to the report:


For a normal PDF file, expect the total entropy and the entropy of bytes inside stream objects to be close to the maximum value 8.0. This means that the distribution of byte values is close to random, which is characteristic of compressed and encrypted data.

Outside streams objects, the data appears much less random, and the entropy is much lower, usually around 4.0 or 5.0.

However, for malformed PDF documents, where data is added without using stream objects, the entropy outside stream objects is much higher. Here is the report for the malicious swine flu PDF:


Another datum added to the report by using the –extra option is for the end-of-file marker %%EOF.

The “%%EOF” line mentions the number of times %%EOF appears in the document (more than once usually indicates incremental updates). “After last %%EOF” counts the number of bytes after the last %%EOF. This value will be not be zero when data has been appended.


The previous versions of pdf-parser output a lot of “todo 10” data (an indication of malformed PDF data) when they parse a malformed PDF document. I’ve suppresed this behavior, you’ll need to use option –verbose to enable it from now on, should you need it. Since I first use PDFiD to check a PDF document before using pdf-parser, I don’t consider the “todo” output relevant anymore, as PDFiDs entropy and %%EOF report will tell me if a PDF document is malformed.


But the other new option in pdf-parser, –extract, is more important. Example:

pdf-parser.py –extract payload.bin malformed.pdf

This option will extract all malformed data from malformed.pdf and write it to file payload.bin, giving you easy access to the embedded payload.


You can download a normal and malformed Hello World PDF file here to get familiarized with my updated tools. 4096 random bytes have been appended to the end of the PDF document to make it malformed.

Here is a last example when the entropy calculation can be handy even if the payload is stored inside a stream object:


The reason the total entropy and entropy of bytes inside stream objects is very low here, is that this malicious PDF document has a payload with a very long, uncompressed NOP-sled (more than one million times 0x90).

Monday 11 May 2009

PDF Filter Abbreviations

Filed under: My Software,PDF — Didier Stevens @ 0:00

@binjo ‘s tweet made me realize PDF filter abbreviations do apply to stream objects too, although the PDF reference document only defines them for inline images. Here are the abbreviations:

  • ASCIIHexDecode -> AHx
  • ASCII85Decode -> A85
  • LZWDecode -> LZW
  • FlateDecode -> Fl
  • RunLengthDecode -> RL
  • CCITTFaxDecode -> CCF
  • DCTDecode -> DCT

This means that, for example, a flatedecode filter for a stream object can not only be specified as /Filter /FlateDecode, but also as /Filter /Fl.

I updated my PDF-tools to support this.

And jprosco e-mailed me an update to my pdf-parser tool to support ASCIIHexDecode, because he had to analyze some malicious PDF documents that used it to encode the JavaScript.

Sunday 10 May 2009

Quickpost: Disinformational Tweets

Filed under: My Software,Nonsense,Quickpost — Didier Stevens @ 12:55

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.


The program requires the twitter module, itself requiring the simplejson module.

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.


disinformational-tweets_v0_0_1.zip (https)

MD5: 36CDB584634ED299E7ACE0D64E846003

SHA256: C5FCE76443549C3A8882B799B6F7A754EF6AEE5F11F3E94FF255EE541205C17B

Quickpost info

Wednesday 6 May 2009

A Very Brief History of Foxit Reader and JavaScript

Filed under: PDF,Vulnerabilities — Didier Stevens @ 23:45

As I often read questions about Foxit Reader and JavaScript support, I decided to write down this very brief history.

Foxit Reader is a lightweight PDF reader, it consist of exactly one EXE file.

Up to Foxit Reader version 2.1, there was no built-in support for JavaScript. If you needed JavaScript, you had to install a plugin (this was actually just a DLL).

Version 2.1 came with builtin JavaScript support. No more plugin, the DLL was merged into the EXE. But the Foxit developers made a design decision with important security implications: you couldn’t disable JavaScript support. Uptil version 2.1, it was easy to disable JavaScript: don’t install the plugin. But with version 2.1, JavaScript was embedded.

Version 2.2 and 2.3 didn’t change this, that’s what prompted me to publish a hack to disable JavaScript.

We had to wait for version 3.0 to be able to disable JavaScript:


But at least, this preference was implemented as it should. Once you disable JavaScript, you get no warnings you’ve disabled JavaScript. This is unlike Adobe Reader:


If you disable JavaScript in Adobe Reader, you’ll be proposed to re-enable it each time you open a PDF document with JavaScript. This is extremely confusing for the average user.

Foxit has started to provide an iFilter. I hope Foxit will never integrate this iFilter in their Foxit Reader setup program, because iFilters increase the attack surface.

Shellcode 2 VBScript

Filed under: Hacking,My Software — Didier Stevens @ 9:06

I had not posted my Python script to convert shellcode to VBScript, so here it is.


shellcode2vbscript_v0_1.zip (https)

MD5: AAB0431127C657C9A3EF67E1C73E6711

SHA256: D1CDDAFCB734EC3F35E558DECFF2EDB73DC0C394936814B602B605F09DE4A5E5

Monday 4 May 2009

Quickpost: Using Your Poken as a Lowcost LF RFID Detector

Filed under: Hardware,Quickpost,RFID — Didier Stevens @ 0:01

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.


Quickpost info

Blog at WordPress.com.