The Mystery of the Encrypted Gauss Payload

There are many remaining mysteries in the Gauss and Flame stories. For instance, how do people get infected with the malware? Or, what is the purpose of the uniquely named “Palida Narrow” font that Gauss installs?

Perhaps the most interesting mystery is Gauss’ encrypted warhead. Gauss contains a module named “Godel” that features an encrypted payload. The malware tries to decrypt this payload using several strings from the system and, upon success, executes it. Despite our best efforts, we were unable to break the encryption. So today we are presenting all the available information about the payload in the hope that someone can find a solution and unlock its secrets. We are asking anyone interested in cryptology and mathematics to join us in solving the mystery and extracting the hidden payload.

The containers

Infected USB sticks have two files that contain several encrypted sections. Named “System32.dat” and “System32.bin”, they are 32-bit and 64-bit versions of the same code. These files are loaded from infected drives using the well-known LNK exploit introduced by Stuxnet. Their primary goal is to extract a lot of information about the victim system and write it back to a file on the drive named “.thumbs.db”. Several known versions of the files contain three encrypted sections (one code section, two data sections).

The decryption key for these sections is generated dynamically and depends on the features of the victim system, preventing anyone except the designated target(s) from extracting the contents of the sections.

By the way, the 64-bit version of the module has some debug information left in it. The module contains debug assertion strings and names of the modules:

.\loader.cpp

NULL != encSection

Path

NULL != pathVar && curPos < pathVarSize

NULL != progFilesDirs && curPos < progFilesDirsSize

NULL != isExpected

NULL != key

(NULL != result) && (NULL !=str1) && (NULL != str2)

.\encryption_funcs.cpp

Read more: SecureList

Posted via email from Jasper-net

It's RX v2 Baby! Reactive Extensions v2.0 RTW, with details, download and the SDK too!

Today, we’re extremely pleased to announce the availability of Reactive Extensions for .NET (Rx) v2.0 RTM, aligned with the availability of Visual Studio 2012 RTM and Windows 8 RTM for MSDN subscribers. This is a major milestone for the Rx project and we hope you’ll love what you see!

In this post, we’ll focus on how to download and install the bits for use in various application frameworks. Unlike previous posts about the v2.0 pre-releases, we’ll defer further technical details to a series of follow-up posts. Nonetheless, we’ll give a brief introduction into the use of Portable Library with Rx v2.0 RTM.

Note: We’ve written this post in the typical font used for big announcements nowadays – Comic Sans – in honor of the Higgs boson discovery. In case you don’t want to partake in this celebration for the remainder of the post, click here to switch fonts.

Before we get started, make a note of the supported platforms for this release:

.NET Framework 4

.NET Framework 4.5

.NET Framework 4.5 for Windows Store apps

Silverlight 5

Windows Phone 7.5

Although this post was authored on Windows 8 using Visual Studio 2012 for screenshots, Rx can be used with Visual Studio 2010, and/or on older versions of the operating system as well. (For example, at the time of writing this post, Windows Phone development wasn’t yet publicly available in Visual Studio 2012, so that’d be a case where you have to use Visual Studio 2010 for the time being.)

Reactive Extensions for JavaScript (RxJS) users can expect the v2.0 release – including support for WinJS used in Windows Store apps – to hit the web very soon. Watch this blog for the announcement

Read more: Greg's Cool [Insert Clever Name] of the Day

Read more: Reactive Extensions v2.0 has arrived!

Posted via email from Jasper-net

Task Parallel Library: 1 of n

Introduction

I recall the first time I created a UI in .NET that had to go and get some data from a database, and the amount of data that I fetched was way larger in production that my code assumed it would be in my dumbed down test setup. Guess what happened... my UI froze as soon as it used real data. The reason for this is that the UI thread (i.e., the only thread in my naive UI) was being used to carry out this fetching of data from the backend database. Yikes! Surely there is a better way.

As it turned out, there was. .NET offered (and still does) a wide variety of Threading classes to help with just this sort of situation, such as Thread, BackgroundWorker, ThreadPool etc.

So I got to know and love some of these classes in the System.Threading namespace, and they did make a massive difference to the responsiveness of my application, all cool.

Thing is, some of the code one has to write when doing some of this threading stuff using the System.Threading namespace (from here on in "classic threading") took a lot of work in some cases, and just was not that intuitive at times. Classic threading is well known as the domain of experts; after messing with its quirks for long enough, one can begin to see why... You are like frack, where did that Exception come from, ahhhh I am using a shared data object with multiple threads, aha! This has by the main stay been a mixture of intuition/luck/skill... and not necessarily in equal parts.

Luckily, help is at hand. With .NET 4.0, there is a new kid in town. It is called a Task, which some of you may know is part of the Task Parallel Library (TPL), which is a new collection of very, very useful (and I feel highly intuitive) classes aimed at not only making your parallel programming easier to read, but also offers lighter weight objects when compared to the classic threading alternatives. For example, when a new Thread is started in .NET, there is a whole process that goes with that, such as creating queues, thread local storage, managing the Thread's lifecycle etc. This takes time. OK, so you could use the classic threading ThreadPool, which does allow you to queue up work item delegates directly to the ThreadPool, which means you are not impacted by the overhead of creating a new Thread yourself, as the ThreadPool will manage all new Thread creation etc.

However, even using the classic threading ThreadPool, there were problems in that you could not cancel a work item once it has been queued with the ThreadPool, or get a return result that easily. It just doesn't read that well either. There is an excellent article here on CodeProject that tackles some of these issues: Smart ThreadPool, which is pretty excellent actually. However, the new TPL infrastructure has got all these problems covered, and many many more useful features in my opinion.

A TPL Task actually uses the ThreadPool internally, if you use the default scheduler, which you more than likely will most of the time. The scheduler can be swapped out, and that is something I will be showing in a subsequent article. For the time being, if we assume we are using the default scheduler, Tasks will be allocated threads by the the use of a ThreadPool, which handles the creation of Threads to carry out Tasks, so a lot of the heavy lifting (so to speak) is done behind the scenes for us by TPL.

Read more: Codeproject

QR: 

Posted via email from Jasper-net

Arduino Installer For Atmel Studio 6

Project Description

Install binaries with core library and Arduino libraries in Atmel Studio 6. Creates two project templates, one for sketches and another one for Arduino libraries. All you need to do is download, configure the installation script (arduino port, speed, chip, etc) and run install.bat.

Read more: Codeplex

QR: 

Posted via email from Jasper-net