Cmake Openssl And Mingw On Windows

01 Apr 2017

If you found this you are probably having issues linking OpenSSL to MinGW-w64 using CMake (or CLion) on Windows. In this post I will give a quick overview on how to get this to work on a clean Windows machine…

The distribution I used to get it to work is Win64OpenSSL-1_2_2k.exe. The issue was that there are no MinGW-compatible link libaries. To solve this you can use my genlib tool to generate them:

cd c:\OpenSSL-Win64
set PATH=%PATH%;c:\genlib

genlib ssleay32.dll
genlib libeay32.dll

copy *.a lib\

The CMakeLists.txt looks like this:

# Project configuration
cmake_minimum_required(VERSION 2.7)

# Use C++11

# Project source files
set(SOURCE_FILES main.cpp)
add_executable(OpenSSLTest ${SOURCE_FILES})

# OpenSSL (find, include, link) 
find_package(OpenSSL REQUIRED)
target_link_libraries(${PROJECT_NAME} ${OPENSSL_LIBRARIES})

And some simple test code:

#include <iostream>
#include <openssl/ssl.h>

int main() {
    std::cout << "SSLeay Version: " << SSLeay_version(SSLEAY_VERSION) << std::endl;
    auto ctx = SSL_CTX_new(SSLv23_client_method());
    if (ctx) {
        auto ssl = SSL_new(ctx);
        if (ssl) {
            std::cout << "SSL Version: " << SSL_get_version(ssl) << std::endl;
        } else {
            std::cout << "SSL_new failed..." << std::endl;
    } else {
        std::cout << "SSL_CTX_new failed..." << std::endl;

If everything is configured correctly this should print:

SSLeay Version: OpenSSL 1.0.2k  26 Jan 2017
SSL Version: TLSv1.2

If you cannot be bothered to run genlib yourself, you can find a copy the required files here and get started immediately.

Hope this helped,


Leave a comment

My Inactivity

22 Sep 2016

Currently I do not have much time to update this blog because I am writing for the x64dbg blog, check it out!


Leave a comment

Github Gpg

30 May 2016

Hello everyone,

Today I saw this broadcast on Github which states that GPG signature verification was added to Github. It took me a bit of searching before I got it to work from both the command line and Git Extensions so in this guide I will explain how I did it.

Installing Git (Extensions)

The first thing to install is the latest (v2.0.0+) version of Git for Windows.

After will have to install Git Extensions. Make sure to select the -SetupComplete but do not install MsysGit from there since you already installed a newer version.

Make sure you configure Git (Extensions) correctly so your identity is in sync with your Github email/username.

Installing GPG

You can download and install GPG from here. Next verify that you installed everything correctly:

C:\Users\Admin>git --version
git version

C:\Users\Admin>gpg --version
gpg (GnuPG) 2.0.30 (Gpg4win 2.3.1)
libgcrypt 1.6.5
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: C:/Users/Admin/AppData/Roaming/gnupg
Supported algorithms:
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2

If you get any errors, make sure you added everything to your PATH environment variable.

Generating GPG Keys

Follow this guide. In short:

C:\Users\Admin>gpg --gen-key
gpg (GnuPG) 2.0.30; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
Is this correct? (y/N) y

Real name: githubgpgtest
Email address:

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   4096R/6B84CA35 2016-05-30
      Key fingerprint = DF55 D8E3 B4E5 9614 7ADF  8E6E E5B6 4A58 6B84 CA35
uid       [ultimate] githubgpgtest <>
sub   4096R/63BEB3EE 2016-05-30

Notice: I will be using 6B84CA35 as my identifier for my key, you should use your own in the upcoming commands.

Adding your key to Github

Follow this guide. In short:

C:\Users\Admin>gpg --list-keys
pub   4096R/6B84CA35 2016-05-30
uid       [ultimate] githubgpgtest <>
sub   4096R/63BEB3EE 2016-05-30

C:\Users\Admin>gpg --armor --export 6B84CA35
Version: GnuPG v2


Add your key to your Github account through this page:

github screenshot

Configuring Git

Set your globally installed GPG version in Git (make sure to alter this path if you installed gpg2.exe in a different location):

git config --global gpg.program "C:/Program Files (x86)/GNU/GnuPG/gpg2.exe"

Then set your generated signing key:

git config --global user.signingkey 6B84CA35

These commands enable automatic GPG signing for commits and tags (which is required if you want this to work with Git Extensions):

git config --global commit.gpgsign true
git config --global tag.gpgsign true

Now when commiting the Git Extensions it should show you the following dialog:

gpg password

After pushing to the repository Github shows your commits as verified:



That’s about it, your passphrase should cache for a while so you shouldn’t be bothered with entering your passphrase every single time you commit. You can configure your caching times here:

gpg cache

The first entry is the default-cache-ttl option, the second max-cache-ttl:

--default-cache-ttl n
    Set the time a cache entry is valid to n seconds. The default is 600
--max-cache-ttl n
    Set the maximum time a cache entry is valid to n seconds. After this time a
    cache entry will be expired even if it has been accessed recently. The
    default is 2 hours (7200 seconds).

If you enjoyed this post, feel free to share it with your friends through social media.


Leave a comment

Dynamic Menu Builder

03 Feb 2016

Hello folks,

While on the plane back home I decided to write another little blog post. This time I will be showing you a nice class I came up with for x64dbg to manage menu items.

The problem

As with every abstraction it starts with a problem you are trying to solve. In this case the problem was code duplication and general tediousness with the construction of the context (right click) menus in x64dbg.

The general idea of Qt is great. From my understanding, every context menu is a QMenu with a bunch of QAction or other QMenu items in it. When a user right-clicks in the widget a signal will be emitted and the widget can connect to the signal, construct the QMenu and ‘execute’ the menu on the mouse position. Each QAction has a signal called triggered() which you can connect to a slot in your widget to handle the click event.

If there is no variation in the menu everything works perfectly fine. You just create all the actions, menus and connections in the constructor and store the final QMenu item in the class. Then when you need the menu you do mMenu->exec(position) and you are done with it.

In x64dbg the menus are based on the context, so the static approach doesn’t work. What we did was create and connect all the QAction items in the constructor and then dynamically create the menu. What this did was create a lot of fragmentation. All the actions had to be declared in the header, the slots for the actions had to be declared in the header and the source and adding a new action would result in a lot of code that looked exactly like this:

mFollowAddress = new QAction("&Follow in Disassembler", this);
connect(mFollowAddress, SIGNAL(triggered()), this, SLOT(followAddress()));

For actions with a shortcut and an icon it was even worse:

mToggleBreakpoint = new QAction("Toggle Breakpoint", this);
connect(mToggleBreakpoint, SIGNAL(triggered()), this, SLOT(toggleBreakpoint()));

Shortcuts also require setting the actual shortcut in a dedicated slot called refreshShortcutsSlot() which is connected to the settings dialog so shortcuts are updated when the user updates the settings:

void ReferenceView::refreshShortcutsSlot()

Finally the menu is created in contextMenuEvent like this:

if(apiAddressFromString(mCurList->getCellContent(mCurList->getInitialSelection(), 1)))

As you can imagine, adding an action with an icon, a shortcut and some context-dependent behaviour was a very tedious process and this needed to change.

Part of the solution is a MenuBuilder class. This is a recursive datatype (like QMenu) but it lazily builds the menu, which allows for proper context-awareness.

To achieve context-awareness, each QAction/QMenu/MenuBuilder you add to a MenuBuilder is paired with an std::function. If the callback returns true, the item is added to the final QMenu, otherwise it is ommitted. This allows for constructs like this:

mBuilder->addAction(followAction, [this](QMenu* menu)
{ //only add followAction if the selected address is readable.
    return DbgMemIsValidReadPtr(this->selectedAddress());

The followAction will only be added to the final QMenu if the currently selected address is a valid memory address. This is a huge save in code, the menu creation slot can be replaced with:

QMenu menu;

There are some extra features (like using the menu parameter of the lambda to add extra actions to the final QMenu, but if you want more details, read the code here.


The next problem to solve is the creation of the QAction and QMenu items. The solution was to create a few simple helper methods in the base class (AbstractTableView):

template<typename T>
inline QAction* makeAction(const QString & text, T slot)
    return connectAction(new QAction(text, this), slot);

inline QAction* connectAction(QAction* action, const char* slot)
    connect(action, SIGNAL(triggered(bool)), this, slot);
    return action;

inline QAction* connectAction(QAction* action, QActionLambda::TriggerCallback callback)
    auto lambda = new QActionLambda(action->parent(), callback);
    connect(action, SIGNAL(triggered(bool)), lambda, SLOT(triggeredSlot()));
    return action;

The makeAction uses a template because I added lambda support to the actions. This is not in Qt 4 and rather simple to implemented so I decided to add it:

class QActionLambda : public QObject
    typedef std::function<void()> TriggerCallback;

    QActionLambda(QObject* parent, TriggerCallback callback)
        : QObject(parent),

public slots:
    void triggeredSlot()

    TriggerCallback _callback;

Now to create an action you’d write:

makeAction("Selection (&No Bytes)", SLOT(copySelectionNoBytesSlot()))

And similarly an action with shortcut and icon:

makeShortcutAction(QIcon(":/icons/images/highlight.png"), "&Highlighting mode", SLOT(enableHighlightingModeSlot()), "ActionHighlightingMode")

Final words

I guess that’s about it for this blog post. If you want to see what the final menu creation code looks like, check out the code here. For reference, the old code is available here, as you can tell it is a great improvement.

Finally, I know reader interaction has been practically non-existent on this blog so far, however it would be nice if you could send me parts of x64dbg you’d like to get insight in development-wise. Any other topics (reversing/programming) related are also welcome!



Leave a comment


31 Jan 2016

Today I wrote an answer on Quora about how OllyDbg was written. I thought it was interesting so I decided to cross-post it here as a blog entry:

Writing a tool like OllyDbg is not a trivial task. OllyDbg is in essence a debugger with code analysis features, however it has a big range of relatively small extra features that make it a nice thing to use. As of my qualifications, I’m the main developer of x64dbg, which is heavily influenced by OllyDbg and offers similar features but on the 64-bit platform.

The debugger part starts out quite simply. Check out Creating a Basic Debugger for a simple example of what a debugger looks like. In essence you start a process (debuggee) with a special flag so it sends information (debug events) to the debugger. The debugger then processes these events and shows information about the process to the user. Certain events (mainly single-step and breakpoint exceptions) are used to control the execution of the debuggee. If you are interested in a little more detail, check out GleeBug. It is a debug library that will be used in x64dbg soon.

The code analysis is a far more difficult problem to solve. The ‘easy’ part involves giving information about instructions pointing to memory/exported symbols and providing nice syntax highlighting. An all-white deadlisting of instructions is not very friendly to read and OllyDbg does various things to ease the experience. The hard part is actually doing control flow analysis (detecting functions and loops for instance). If you’re interested I wrote up the details of a very naive algorithm here. Some more involved algorithms are available here (by me) and here (by Nukem). Analysis is really, really hard to get working right. There are lots of corner cases and obfuscated binaries that ‘fool’ your analysis and things get especially fuzzy when control flow branches inside of other instructions or otherwise breaks the linear disassembly.

Even if you have a really good debugger and code analyser, you are still far from done. Once people start using your software, bug reports and feature request will come raining in and it can sometimes be soul-destroying to work on a project like this (especially with just intellectual motivation).

Everything needs to be very generic and getting things stable becomes a very complex problem very quickly. See the x64dbg bug tracker if you are interested in what kind of issues people have and report.

Another thing that makes OllyDbg great is that it’s so user-friendly. There are no complex commands involved and everything can be done from the graphical user interface. This is what I believe makes OllyDbg strong. Creating a GUI similar to the one of OllyDbg is rather complex (and boring). It involves custom painted components and a lot of menus.

Finally, OllyDbg offers a great plugin ecosystem, allowing people to extend/modify OllyDbg in lots of ways. People created hundreds of plugins, ranging from simple breakpoint managers to a total overhaul of the program. Creating a system like this is very challenging and pleasing everyone is really hard. It involves writing wrappers around internal functionality and make those available to the plugin writer. You also need to provide the plugins with an interface to hook in the debug loop and intercept debug events.

I hope this answers your question. Feel free to ask me if you need more information.

More content is coming soon to this blog, stay tuned!


Leave a comment