Hardening consulting (Posts about freerdp)

QFreeRDP platform QPA

David FORT — Mon, 05 Jan 2026 07:11:00 GMT

First post of 2026, I wish you all the best for the new year.

In this post, I'm going to talk about an old project that I find very interesting and that is still up-to-date even after more than 10 years of existence: qfreerdp_platform. I've made some interesting improvements to this project recently, so I'm going to talk about them.

Qt internals

The Qt framework works with an abstraction of the platform on which it runs: Qt is designed with independent classes that implement widgets, QML scripting, rendering, etc. But the components that interacts with the system, such as sending content to the graphics card or collecting signals from input devices (keyboard, mouse, or touchscreen), are implemented by a QPA, a Qt Platform Abstraction. For example, when you run a Qt application on Linux, there will be a heuristic system that will either load the QPA for X11 (xcb) or the Wayland QPA.

I already mentioned this in 2013 in this post. An interesting thing is that you can force the QPA that will be used by an application by passing the parameter -platform <name of qpa> when calling the Qt program (this is why you have to pass the command line parameters to QApplication, so that Qt can treat the arguments that are for him). The really surprising thing is that any Qt program, without rebuild, can run on both X11 and Wayland, or on a QPA that it is told to use...

Read more… (4 min remaining to read)

FreeRDP and server-side kerberos

David FORT — Mon, 08 Dec 2025 11:08:00 GMT

Lately, I've been exploring topics related to FreeRDP with remote credential guard, Kerberos, and NLA, so I'm writing this post on how Kerberos-ize FreeRDP server-side.

NLA, SPNego and Kerberos

The whole Kerberos process starts with NLA: if you connect to an RDP server with mstsc and the configuration is fairly standard, when you run mstsc /v:dc.hardening2.com, mstsc will:

Read more… (4 min remaining to read)

Exploring NTLM_REMOTE_SUPPLEMENTAL_CREDENTIAL

David FORT — Fri, 05 Dec 2025 06:08:00 GMT

Some time ago, I've been working on the kerberos part of remote credential guards, and after complains about compatibility against windows 11 and recent DCs, I have looked at the NTLM part.

Remote credential guards

The idea behind remote credential guards is that we connect to a remote machine, the password is not sent but we still have SSO. So in theory, even if we connect to a compromised machine, we will not have our password stolen.

Accendino 0.5.10 alpha 1

David FORT — Fri, 03 Oct 2025 06:15:00 GMT

More improvements on Accendino, with that 0.5.10alpha1 version which is the stabilization course for 0.5.10.

FFmpeg is one of those softwares that are horrible to automatically build under windows (just behind OpenSSL), and one of the targets for this version was to be able to build FreeRDP with the support of FFmpeg under windows with the Visual Studio toolchain, and do all that automatically. No by hand hacks to make it work, just

$ accendino --targets=freerdp3 freerdp.accendino

It checks out, compiles and it's ready.

New features in version 0.5.10 alpha 1

Support for Msys2

First step to compile FFmpeg with Visual Studio: you need to execute commands under msys2, and therefore this version brings package installation support to this environment. If you put 'msys2/yasm' in packages dependencies, accendino will install the corresponding packages in the msys2 environment.

Extract from the FFmpeg accendino file:

...

ffmpegPkgs = {
    'Darwin': ['nasm'],
    'Windows': ['choco/nasm|path/nasm', 'msys2/make', 'msys2/yasm', 'msys2/diffutils'],
}

...

This support was not very complex to implement because msys2 uses pacman as package manager, which is already supported in accendino for ArchLinux. We already had everything we needed to list installed packages and run package installations.

A new makeMsys2 builder type has been added for CustomCommandBuildArtifact, which allows to launch make but in the msys2 environment, that's the way to build FFmpeg with MSVC.

Toolchain

This version brings the notion of toolchain, which basically allows to specify which buildchain to use. Under the Unixes, we have the choice between gcc and clang, and under windows we will detect Visual Studio and you can use with MSVC or clang (vs/msvc or vs/clang).

The toolchain support enables to set the right environment variables for gcc or clang builds (which will then be used by meson, cmake or others), but also to call the VsDevCmd.bat script of visual studio (or its powershell equivalent).

All of this was required for FFmpeg, because when you do the build process by hand, you open a Visual Studio development shell that allows you to have the PATH positioned properly, then from there you run a msys2 shell that will inherit of these values, and the build is launched inside this msys2 shell.

The build process under windows has therefore also been redesigned and so now we generate a powershell script containing all commands and this powershell script is then executed. This facilitates management of environment variables, but also debugging, because you can easily restart the script with exactly the same environment (because all this is done in the powershell script itself). With all these additions, we automate the construction of FFmpeg under windows with Visual Studio.

Even if we already had the possibility to make a cross compilation with mingw on Linux and then transfer the files under windows, it is so more convenient to build on windows and use directly VisualStudio if you have to do a debugging session.

With the support of the toolchains, the BuildArtifact gains a new toolchainArtifacts argument that gives the list of artifacts that should be pulled from the toolchain. The default value is to indicate that it is desired to use a C compiler (c), but you can also add c++ for projects coded in this language.

Various other changes

A lot of other improvements have been made in this version:

accendino files have been added for Cairo, cJson and qfreerdp_platform, which allows to build these projects very easily and have a more feature complete FreeRDP under windows;
now when accendino detects a rebuild for an item, it will also rebuild all the items which that item depends on;
with this version we look for the accendino files passed in command line in the current path and then in the pockets: no need to give the complete path when the accessino file is stored in a pocket directory;
the include() command has a new include_once parameter (true by default) which allows to specify that a file should only be included once during the execution of accendino;
CI tests have been added to validate that everything is working properly after changes, this allows to validate a number of build cases with accendino under linux and even windows;

To conclude

With these changes, you can easily have the latest FreeRDP under windows with every possible features with a simple:

C:\Users\david> accendino --targets=freerdp3 freerdp.accendino

VisualStudio will be detected, any packages installed, etc.

And under Linux:

$ accendino --targets=qfreerdp_platform-qt6 --toolchain=clang qfreerdp_platform.accendino

and you have qfreerdp_platform compiled for Qt6 under clang. There's really no excuse to not have tested these nice projects yet !

This is basically the functional scope that will be in the 0.5.10 release, any feedback or bug reports are welcome.

Release of Accendino 0.5.9

David FORT — Mon, 10 Feb 2025 10:15:00 GMT

I made some updates to my Accendino script, until it became a program of its own with interesting features. This version 0.5.9 adds a lot of nice things compared to the previous version. Over time, I see Accendino more as a program allowing to build a complex software from several software sources, and on several platforms. For now my case study is FreeRDP, I try to have accendino files that allow to build FreeRDP from scratch on as many platforms as possible (linux, mac, windows, mingw, ...)

History

Originally accendino was just a small script to run the Ogon installation instructions. It was a bit more complex because you could specify the git locations to download. For example, to use the Forgiare repositories instead of the official Ogon repositories. With version 0.5.0, I extended its features quite a lot:

the ability to include accendino files to reuse existing definitions;
the program sources have been greatly extended and no longer necessarily come from git. We can have local sources, or from git. Many git options are now accessible;
Read more… (5 min remaining to read)

Quick tip: massif tool of Valgrind

David FORT — Tue, 18 Jun 2024 05:08:00 GMT

A little tip that I discovered some time ago: the massive tool from valgrind. It can address cases where we have a program that eats up too much memory unnecessarily, but since it does cleanups correctly at the end, we don't see anything with standard leak tools like valgrind or asan.

Massif

This is where the massif tool from valgrind comes in as well as the massif-visualizer visualization tool. This tool will allow you to regularly take snapshots of memory allocations, and to see the callstacks of location in our programs that make these allocations.

Smartcard logon with FreeRDP

David FORT — Wed, 04 Oct 2023 05:08:00 GMT

In (the future) FreeRDP 3.0, there is support for the smartcard logon, on which I have worked, let's give some details.

Smartcard support

We start by checking that we can access the smartcard, in my case it is a yubikey(TM):

$opensc-tool -l
# Detected readers (pcsc)
Nr. Card Features Name
0 Yes Yubico YubiKey OTP+FIDO+CCID 00 00

Read more… (4 min remaining to read)

UDP support in FreeRDP part 2

David FORT — Mon, 09 Jan 2023 10:08:00 GMT

Let's take a closer look at the RDPUDP protocol which will transport data over UDP. To begin with, remember that only channel data can be transported on top of UDP, so it doesn't affect older graphics orders (so forget speed up of bitmapUpdates with UDP), however it will work with any egfx transported graphics. The migration from TCP to UDP is done through the dynamic channel, so drdynvc is mandatory. This mechanism also allows static channels to be migrated to UDP by setting the TRANSPORTTYPE_UDP_PREFERRED flag in the gcc packet of multi-transport channel data.

UDP support in FreeRDP part 1

David FORT — Sun, 31 Jan 2021 10:08:00 GMT

Months that I have not posted anything. So let's begin with some wishes for the new year, let's hope the Covid will be more quiet in 2021.

I'm currently working on implementing UDP support in FreeRDP, so let's have a serie of post on that subject. I'm gonna begin with an overview, how it works, implications and I'll certainly go more in the details in the next posts.

Overview of the UDP transport

Documentation and specifications

The UDP transport is described in multiple specifications:

MS-RDPBCGR : the core RDP specification, we have some flags in GCC packets, and of course the description of multi-transport;
MS-RDPEMT : this document describes multi-transport, that allows to install multiple transports at the same time;
MS-RDPEUDP : the UDP transport itself;
MS-RDPEUDP2 : the new version of the protocol;
MS_RDPEDYC : dynamic channels specification;

Read more… (4 min remaining to read)

Using FreeRDP logging facility

David FORT — Wed, 30 Jan 2019 10:12:00 GMT

When you're working on FreeRDP, it's quite usual to increase the log level and to have to collect a massive amount of logs. And most often it doesn't fit in the terminal backscroll history, or it is so slow (terminal rendering is CPU intensive) that you need a file storage. Another case is when you're on a remote host and you want to retrieve the log over the network.

As each time I want to use the WLog capacities I'm looking at the source code, I had the idea to write that post on the subject, so that next time I will look at this text.