Didier Stevens

Monday 22 October 2018

New tool: decompress_rtf.py

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

A reader over at the Internet Storm Center asked how to analyze a particular email file (.msg) with my oledump.py tool. MSG files are ole files, and can be analyzed with oledump. In this particular email, one stream contains compressed RTF.

I quickly wrote a tool to decompress compressed RTF using Python module compressed_rtf, using my binary file Python template.

Template process-binary-file.py is a Python program that reads binary files (normal files, stdin, contained in a ZIP file, …) and comes with various options to process these files. The class cBinaryFile can read a complete or partial file into memory for further processing.

Just a few lines of code of the template need to be added/changed to create this new decompression tool.

First I need to import module compressed_rtf. A single line “import compressed_rtf” would be sufficient, but I’m adding some error handling in case the module is not installed:

    import compressed_rtf
except ImportError:
    print('Module compressed_rtf missing, please install with command: pip install compressed_rtf')

Next, I search for “# —– Put your data processing code here —–” (line 1315 in the current version 0.0.1 of the template):

Lines 1316 and 1317 (starting with oOutput.Line) are just demo lines, to be replaced by this line:

        oOutput.Line(compressed_rtf.decompress(data), eol='')

Variable data contains the complete binary content of the processed file (e.g. the compressed RTF), and a call to method compressed_rtf.decompress will decompress the data. Then I output the result with method Line of object oOutput. I use this method in stead of a print statement, because then I have more control over the output format and destination by using command-line option -o. eol=” directs the Line method not to append a new-line after outputting the decompressed RTF file.

That’s essentially all that needs to be done to create this new tool with my template.

Documentation is also important, so I also updated the description (line 5), date (line 8) and the manual (starting line 67).

And now with this tool, I can decompress compressed RTF streams found inside a .msg file:

decompress_rtf_V0_0_1.zip (https)
MD5: 41127F62897479FB5135D36675C396F5
SHA256: 581F2E1B2B508C3941EC22040FB0C76999E5DF293C8AD0DC1FDE921D121F3A26

Sunday 21 October 2018

Release: Python Tool Templates

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

I’m releasing the templates for Python tools I shared and used during my BruCON and Hack.lu 2018 workshops.

There’s a template for text files and one for binary files.

python-templates_V0_0_1.zip (https)
MD5: 99E9D87681470F1BAE020B68F2853F49
SHA256: 2CA24AD6928FA2FE2DE894FEFBD1B41238B723D46ADED4064D26374A805BA1C4

Wednesday 10 October 2018

KEIHash: Fingerprinting SSH

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

keihash.py is a program to parse pcap files and calculate the KEIHash of SSH connections.

The KEIHash is the MD5 hash of the Key Exchange Init (KEI) data (strings). For obvious reasons, I could not call this an SSH fingerprint. This is inspired by JA3 SSL fingerprinting.

It can be used to profile SSH clients and servers. For example, the hash for the latest version of PuTTY (SSH-2.0-PuTTY_Release_0.70) is 1c5eaa56f3e4569385ae5f82a54715ee.

This is the MD5 hash of:


These are all the strings found in the Key Exchange Init packet, prefixed by their length and concatenated with separator ;.

With this, I’ve been able to identify SSH clients with spoofed banners attempting to connect to my servers.

keihash_V0_0_1.zip (https)
MD5: 674D019A739679D9659D2D512A60BDD8
SHA256: DB7471F1253E3AEA6BFD0BA38C154AF3E1D1967F13980AC3F42BB61BBB750490

Monday 1 October 2018

Title: Overview of Content Published in September

Filed under: Announcement — Didier Stevens @ 0:00

Here is an overview of content I published in September:

Blog posts:

YouTube videos:

Videoblog posts:

SANS ISC Diary entries:

Monday 24 September 2018

Quickpost: Signing Windows Executables on Kali

Filed under: Quickpost — Didier Stevens @ 0:00

Windows executables (PE files) can be signed on Kali using osslsigncode.

osslsigncode needs to be installed:

apt install osslsigncode

Then you need a certificate. For this demo, I’m using a self-signed cert.

The command to sign file demo-x64.exe with the demo certificate using SHA1 and timestamping, is:

osslsigncode sign -certs cert-20180729-110705.crt -key key-20180729-110705.pem -t http://timestamp.globalsign.com/scripts/timestamp.dll -in demo-x64.exe -out demo-x64-signed.exe

The signed file is demo-x64-signed.exe

To dual sign this executable (add SHA256 signature), use this command:

osslsigncode sign -certs cert-20180729-110705.crt -key key-20180729-110705.pem -t http://timestamp.globalsign.com/?signature=sha2 -h sha256 -nest -in demo-x64-signed.exe -out demo-x64-dual-signed.exe

The signed file is demo-x64-dual-signed.exe

Of course, Windows reports the signatures as invalid, because we used a self-signed certificate. For a valid signature, you can add your certificate to the trusted root certificates store, buy a code-signing certificate, …

For single SHA256 signing, use the second osslsigncode command without option -nest.


Quickpost info

Sunday 23 September 2018

Update: pecheck.py Version 0.7.4

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

This update improves digital signature handling.

pecheck-v0_7_4.zip (https)
MD5: E0F90B85576F7BC42BB8601E650134FB
SHA256: E011CD82F5E3244553FBA52DDF3F0D3076E88A6F35E50AA18AC0DAAC6ED91389

Monday 17 September 2018

Quickpost: Compiling EXEs and Resources with MinGW on Kali

Filed under: Quickpost — Didier Stevens @ 0:00

To compile a Windows executable with version information and an icon on Kali, we use MinGW again.

The version information and icon (demo.ico) we want to use are defined in a resource file (demo.rc):

#include "winver.h"

#define IDI_ICON1                       101

// Version

#define VER_FILEVERSION             0,0,0,1
#define VER_FILEVERSION_STR         "\0"

#define VER_PRODUCTVERSION          0,0,0,1
#define VER_PRODUCTVERSION_STR      "\0"

#ifndef DEBUG
#define VER_DEBUG                   0
#define VER_DEBUG                   VS_FF_DEBUG

    BLOCK "StringFileInfo"
        BLOCK "040904E4"
            VALUE "CompanyName", "example.com"
            VALUE "FileDescription", "demo"
            VALUE "FileVersion", VER_FILEVERSION_STR
            VALUE "InternalName", "demo.exe"
            VALUE "LegalCopyright", "Public domain"
            VALUE "OriginalFilename", "demo.exe"
            VALUE "ProductName", "demo"
            VALUE "ProductVersion", VER_PRODUCTVERSION_STR
    BLOCK "VarFileInfo"
        VALUE "Translation", 0x409, 1252

// Icon

// Icon with lowest ID value placed first to ensure application icon
// remains consistent on all systems.
IDI_ICON1               ICON                    "demo.ico"

More info on the VERSIONINFO resource can be found here.
We use the resource compiler windres, and then the gcc compiler.

Compile for 64-bit:

x86_64-w64-mingw32-windres demo.rc demo-resource-x64.o
x86_64-w64-mingw32-gcc -o demo-x64.exe demo-resource-x64.o demo.c

Compile for 32-bit:

i686-w64-mingw32-windres demo.rc demo-resource-x86.o
i686-w64-mingw32-gcc -o demo-x86.exe demo-resource-x86.o demo.c


DemoResource_V_0_0_0_1.zip (https)
MD5: 9104DDC70264A9C2397258F292CC8FE4
SHA256: 722B3B52BAE6C675852A4AC728C08DBEEF4EC9C96F81229EF36E30FB54DC49DE

Quickpost info

Tuesday 11 September 2018

WiFi Pineapple NANO: Persistent Recon DB

Filed under: WiFi — Didier Stevens @ 0:00

The WiFi Pineapple’s recon DB (recon.db) is volatile, because it is stored (by default) in the /tmp folder.

I store my recon.db on the SD card to make it persistent (survives a reboot).

First the SD card has to be formatted:

Then the “Scans Location” field can be changed from /tmp/ to /sd/:

recon.db is an SQLite database, that can be browsed with tools like sqlitebrowser:

Monday 10 September 2018

Firmware Upgrade: WiFi Pineapple NANO

Filed under: WiFi — Didier Stevens @ 0:00

This is mainly a reminder for myself, as I don’t often update my WiFi Pineapple NANO.

Updating the NANO performs a reset.

I connect my NANO via a USB cable to my laptop. The USB cable allows me to flip the NANO to access the reset button.

I login via HTTPS port 1471

I connect the NANO to a WiFi access point:

Once connected, I can check for upgrades:

And then perform the upgrade:

This will take several minutes, after the upgrade is performed, this dialog will appear:

From here on, the NANO has to be setup again:

I press the reset button quickly to perform a setup with WiFi disabled.

And configure the NANO, just like for first use:

I select France for Radio Country Code, because Belgium is not an option:

At this point, the setup is not yet complete for me.

I store the recon.db on an sd card, so this has to be configured:

And I also install modules:

That I install on the SD card:

Once installed, some modules need dependencies to be installed too:


Wednesday 5 September 2018

Overview of Content Published in August

Filed under: Announcement — Didier Stevens @ 0:00

Here is an overview of content I published in August:

Blog posts:

YouTube videos:

Videoblog posts:

SANS ISC Diary entries:

NVISO blog:

« Previous PageNext Page »

Blog at WordPress.com.