Didier Stevens

Monday 26 November 2018

Quickpost: Compiling with Build Tools for Visual Studio 2017

Filed under: Quickpost — Didier Stevens @ 0:00

Compiling C/C++ programs with Microsoft’s command-line compilers is possible, even if you don’t have Visual Studio installed. You can do this with the Build Tools for Visual Studio 2017 (a free download).

Go to https://visualstudio.microsoft.com/downloads/ and download the Build Tools:

The downloaded file does not include the build tools, but it’s a stager that will download the necessary build tools. It requires .NET, you might get an error if the proper version is not installed:

Installing the correct .NET framework will fix this problem:

Once this download is completed, you can get to the actual installer where you choose the tools you want:

I selected the Visual C++ build tools, a download of about 1 GB:

Once the build tools are installed, you can open a shell via the start menu:

The C/C++ compiler is invoked with command cl:

As an example, I’m compiling the following program:


Quickpost info


 

Monday 19 November 2018

Quickpost: Compiling 32-bit Static ELF Files on Kali

Filed under: Quickpost — Didier Stevens @ 0:00

Here I compile EICARgen on Kali Linux to a 32-bit, statically linked Linux executable.

gcc’s option -m32 creates a 32-bit executable on 64-bit Linux.

If you get this error:

then one way to solve it is by installing libc6-dev-i386 (apt install libc6-dev-i386):

Then option -m32 can be used to create a 32-bit executable:

This executable will not run on 64-bit system that don’t have the libraries we just installed. A work-around is to statically link the ELF file with option -static:

 


Quickpost info


Monday 5 November 2018

Quickpost: Using pcapy with Npcap on Windows

Filed under: Quickpost — Didier Stevens @ 0:00

I installed pcapy on a Windows machine, but importing in Python failed due to a missing DLL.

Process Monitor showed me what was missing: wpcap.dll, a WinPcap DLL:

The DLL was missing because I had installed Npcap (an alternative for WinPcap, that provides loopback packet capture).

This problem can be fixed by setting a toggle to install a WinPcap compatible API (e.g. wpcap.dll) during installation:


Quickpost info


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


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.0.0.1\0"

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

#ifndef DEBUG
#define VER_DEBUG                   0
#else
#define VER_DEBUG                   VS_FF_DEBUG
#endif

VS_VERSION_INFO VERSIONINFO
FILEVERSION     VER_FILEVERSION
PRODUCTVERSION  VER_PRODUCTVERSION
FILEFLAGSMASK   VS_FFI_FILEFLAGSMASK
FILEFLAGS       VER_DEBUG
FILEOS          VOS__WINDOWS32
FILETYPE        VFT_APP
FILESUBTYPE     VFT2_UNKNOWN
BEGIN
    BLOCK "StringFileInfo"
    BEGIN
        BLOCK "040904E4"
        BEGIN
            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
        END
    END
    BLOCK "VarFileInfo"
    BEGIN
        VALUE "Translation", 0x409, 1252
    END
END


/////////////////////////////////////////////////////////////////////////////
//
// 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 28 August 2018

Quickpost: Compiling DLLs with MinGW on Windows

Filed under: Quickpost — Didier Stevens @ 0:00

MinGW is not only available on Kali, of course, but also on Windows. Compiling a DLL is very similar.

MinGW is installed in folder C:\msys64 on my machine.

 

To compile 64-bit executables, you need to start the 64-bit shell first: launch C:\msys64\mingw64.exe

Then you can compile the DLL:

gcc -shared -o DemoDll-x64.dll DemoDll.cpp

For 32-bit executables, it’s the 32-bit shell: launch C:\msys64\mingw32.exe

Then you can compile the DLL:

gcc -shared -o DemoDll-x86.dll DemoDll.cpp

 

It’s also possible to start the shell and compile from a BAT file:

call C:\msys64\msys2_shell.cmd -mingw64 -here -c "gcc -shared -o DemoDll-x64.dll DemoDll.cpp"
call C:\msys64\msys2_shell.cmd -mingw32 -here -c "gcc -shared -o DemoDll-x86.dll DemoDll.cpp"

 

 


Quickpost info


Saturday 18 August 2018

Quickpost: Revisiting JA3

Filed under: Networking,Quickpost — Didier Stevens @ 0:00

A year ago I tried out JA3. Time for a new test.

This new version no longer crashes on some packets, it’s more stable. However, there’s a bug when producing json output, which is easy to fix.

The JA3 Python program no longer matches TLS fingerprints: it produces a list of data (including fingerprint) for each client Hello packet.

Running this new version on the same pcap file as a year ago (and extracting the fingerprints) yields exactly the same result: 445 unique fingerprints, 7588 in total.

I have more matches this time when matching with the latest version of ja3fingerprint.json: 75 matches compared to 24 a year ago.

Notice that Shodan is one of the matched fingerprints.

Let’s take a closer look:

I’m looking for connections with fingerprint digest 0b63812a99e66c82a20d30c3b9ba6e06:

80.82.77.33 is indeed Shodan:

Name: sky.census.shodan.io
Address: 80.82.77.33


Quickpost info


Tuesday 10 July 2018

Quickpost: Compiling DLLs with MinGW on Kali

Filed under: Quickpost — Didier Stevens @ 0:00

To compile the DLLs from this quickpost with MinGW on Kali, you first have to install MinGW.

Issue this command: apt install mingw-w64

Compile for 64-bit: x86_64-w64-mingw32-gcc -shared -o DemoDll.dll DemoDll.cpp

Compile for 32-bit: i686-w64-mingw32-gcc -shared -o DemoDll-x86.dll DemoDll.cpp

Option -shared is required to produce a DLL in stead of an EXE.


Quickpost info


 

Wednesday 27 June 2018

Quickpost: Decoding Certutil Encoded Files

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

As I showed a colleague, it’s easy to analyze a file encoded with certutil using my base64dump.py tool:

Just use option -w to ignore all whitespace, and base64dump.py will detect and decode the base64 string.

As can be seen in the screenshot, it’s a file starting with MZ: probably a PE file.

We can confirm this with my YARA rule to detect PE files:

Or use pecheck.py:

 


Quickpost info


Wednesday 6 June 2018

Quickpost: John & Dummy Hashes

Filed under: Quickpost — Didier Stevens @ 0:00

I knew you could use dummy hashes with John the Ripper (to test rules, for example), I’ve seen it mentioned in the help. It took me some time however to figure out the exact format of a dummy hash.

It’s like this:

$dummy$48336c6c30

48336c6c30 is the hexadecimal representation of string H3ll0.

The hexadecimal string following $dummy$ has to use lowercase letters. If you use uppercase letters, you’ll get the dreaded “No password hashes loaded (see FAQ)”.

Here is an example using l33t rules:

 


Quickpost info


« Previous PageNext Page »

Blog at WordPress.com.