My Blog

Today, I released version 3.0 of my nuget package LegacyWrapper. LegacyWrapper 3.0 supports calling methods from legacy DLLs with a convenient managed method call.

Ransomware has been an emerging threat for the last years. In May this year, a specific Ransomware called WannaCry brought news back onto this topic. While working on a paper on ransomware, I did some research on how ransomware attacks can be prevented - or how malware can be hidden from Antivirus software.

Today, I released version 2.1 of my nuget package LegacyWrapper. It comes with a major enhancement regarding the cross-architecture loading of DLLs: It is now possible to load 64bit DLLs from a 32bit process:

using (var client = new WrapperClient(TestDllPath, TargetArchitecture.Amd64))
{
    result = (int)client.Invoke<TestStdCallDelegate>("TestStdCall", new object[] { input });
}

As the second constructor parameter is optional and defaults to X86, the new release should be fully backwards compatible.

When I migrated my website to Jekyll a few months ago, I used a free template for my layout. Although it looked quite good, it came with a major tradeoff. It used Skel, a JavaScript framework for responsive websites. Skel loads arbitrary CSS stylesheets with JavaScript, based on the user’s screen resolution. This may sound convenient, but the page will load visibly slower, because the stylesheets will only load after all the JavaScript is loaded and executed. See an example of Skel in action in the following listing:

skel.init({
    reset: 'full',
    breakpoints: {
        global:   { range: '*', href: '/css/style.css', containers: 1400, grid: { gutters: 50 } },
        wide:     { range: '-1680', href: '/css/style-wide.css', containers: 1200, grid: { gutters: 40 } },
        normal:   { range: '-1280', href: '/css/style-normal.css', containers: 960, viewport: { scalable: false } },
        narrow:   { range: '-980', href: '/css/style-narrow.css', containers: '95%', grid: { gutters: 30 } },
        narrower: { range: '-840', href: '/css/style-narrower.css', grid: { collapse: 1 } },
        mobile:   { range: '-736', href: '/css/style-mobile.css', containers: '100%', grid: { gutters: 15, collapse: 2 } }
    },
    // ...
});

Since the launch of Let’s Encrypt CA in late 2015, obtaining TLS certificates has become cheap, quick and easy. Statistics this month showed Let’s Encrypt has yet issued nearly 1.8 million certificates. But it seems like this information hasn’t arrived at some website owners and API developers.

So I wrote a little script to poison DNS requests and let a little node.js script exchange all pictures requested by the victim (I will perhaps blog about this script another time). Sites and apps using TLS are perfectly fine, because they will reject connections to the fake webserver without a valid certificate. Without transport security, things get mad.

As a mainly WPF developer, I decided to take a look at the new Universal Windows Platform (UWP). In this post I will focus on some small differences between WPF and UWP, including StringFormat and DataTemplates.

Adobe just released some new security-related patches for their Flash Player.

My question here is not “why again”, because I expected that. We all expected that. The real question is - who the hell still uses flash? And why are guides like “This is how you secure your flash installation now” so popular? (The expression “security hole” is always particularly funny; that’s obviously no hole here, because a hole clearly has an edge ;) )

The times when you needed Flash for watching YouTube videos are gone (they support HTML5 since, uh…) and they even set HTML5 as default in early 2015. So please stop writing tutorials on how to secure flash and start writing tutorials on how to use other technologies. Thanks.

When loading unmanaged / native libraries from managed .NET code, the normal way is to use the “Platform Invoke (P/Invoke)” mechanism.

[DllImport("shell32.dll", CallingConvention = CallingConvention.Winapi)]
static extern int DllGetVersion(ref DLLVERSIONINFO pdvi);

The problem

P/Invoke has an annoying limitation: You can not load a x86 (32bit) library into a 64bit process and vice versa. This is especially problematic when your application is compiled with the “AnyCPU”-flag - which lets the .NET runtime decide which architecture to use at runtime - and there is only one 32bit version of a specific dll. If recompiling the library against a different architecture is not an option, you have to find another solution.

GitHub Twitter

Codefoundry