[Update 2] TrueCrypt seems hacked, don’t download version 7.2

28 Mai

tl;dr: Don’t use and download TrueCrypt 7.2 at the moment! It might harm your data! According to my research, only the encryption got removed, but I might be wrong!

Currently,

the TrueCrypt website shows this page:

truecrypt

 

It suggests that you move from TrueCrypt to Bitlocker. Some hours before, a version 7.2 got uploaded, which is lighter than the before current version 7.1a. I did a quick diff on the source of 7.2 and 7.1a, and these are my results:

  • All methods, which take care of boot encryption, contain the following line:
    AbortProcess („INSECURE_APP“);
  • All hints (Donating, Explanation of keyfiles, etc) were removed.
  • Release date changed from „February 7, 2012“ to „5/2014“
  • All drive encryption routines were changed, so that they will fail.
  • No help entries in the menu
  • The Setup removes all links to the web- and helpsite.
  • Hint in the license got removed, which stated that you should name TrueCrypt in your product.
  • Following was removed from the ReadMe:III. FreeBSD and OpenSolarisIV. Third-Party Developers (Contributors)V. Legal Information

    VI. Further Information

Besides from that, it seems as if no further action has been taken, so no backdoors have been introduced. However, it seems very odd to me. The signature is valid, and the intruder must have gained access to nearly all the accounts. I’m really curious do know what’s going on here. Until that, don’t use and download the version offered on this site. Don’t use TrueCrypt 7.2!

Update

In fact, creating a volume is not working. A dialogue is displayed instead. I took some Screenshots of the modified version:

tc_start tc_new_volume

 

Update 2

I wrote a follow up on this article: The TrueCrypt aftermath: What now?

[Update] Getting „Super Mario Kart“ into the third dimension… Somehow.

9 Mai

//Update: I’ve added the files that I used to print everything out. You can find them at the end of this post. It’s DinA4 at 300 dpi.

When I was like eight years old, the SNES was a must-have for every kid. Luckily, I begged long enough and finally got one. 🙂

One of my favourite games was „Super Mario Kart“. Yesterday, I read about a guy on MAKE:Magazine, how creates 3d dioramas from NES games. An instant „I can do that, too!“ came into my mind, so I grabbed foamed rubber, a RIBBA frame (the small one) and a SNES emulator.

The SNES emulator was needed to create the image I wanted: The victory ceremony you get after you’ve won the championship. So I fired up the emulator, loaded up the rom (no illegal action intended!) and enjoyed the fun part of this project: Playing. 😀

This is the picture I got:

Where everything began...

Where everything began…

Unfortunately, I’ve no pictures from the building process. But I’ll describe what I did.

First of all, I loaded the screenshot into gimp, and began to cut out all the parts I wanted to pop out. The holes, the cut out parts left behind, where then „repaired“, which was quite a lot of work. I did this, because I wanted to be able to put the popped out parts where I want to. After some two or three hours, I finished it, and arranged everything so I could print it out.

The images were cut out (I’ll never do that again, I swear! It’s really fiddly) and glued onto the foamed rubber. Everything was then arranged and put into the RIBBA frame. This is the final result:

The final result! :)

A close up.

 

I removed some of the details to reduce the overall complexity of this project. However, it took me nearly a whole day from planning to finish. It was fun, it‘ looks really nice on the wall. 😉

//Update:

Here is the template, there are three DinA4 pages:

Templates (22 kb, *.zip file)

 

dgMicMute – A tool for muting your mic, the easy way…

5 Mai

A few days ago, a co-worker asked if anyone knows a simple tool, with which you can mute your microphone like you can mute the volume of the speakers of your computer. We were baffled: Not a single tool was found that actually worked under Windows 7.

challenge_accepted

First, I needed to find a way to actually communicate with the microphone. On good ol‘ Windows XP days, there was some P/Invoke magic which you could use, and some Win32 API calls. Hold on, P/Invoke?

Yeah, love that! It’s quite fun fiddeling around with the API, doing some Marshalling, thinking about how to cast things to managed types. I knew, there was an API for that, and so I did some googeling – I ended up with what’s called the Core Audio API. Oh, that’s some great stuff, even with a nice reference, how to implement stuff, and – hold on, what the… ?

Unfortunately, no plain P/Invoke. Instead, I have to deal with COM-Interfaces. Seriously? We don’t like each other. But, it’s ok. I can handle that. I looked around and found some implementations, but I decided to do it the hard way, and that’s where the fun started.

The Base Class

First I started bulding the base class, which should be called by the application. It’s as simple as this one:

using System.Linq;
using dgMicMute.Enumerations;
using dgMicMute.Implementations;

namespace dgMicMute
{
    public delegate void VolumeNotificationEvent(AudioVolumeNotificationData data); 

    /// <summary>
    /// Starting point: http://msdn.microsoft.com/en-us/library/dd370805(v=vs.85).aspx
    /// </summary>
    public class DgMic
    {
        private MMDeviceCollection _devices;
        private int _count;
        public event VolumeNotificationEvent OnVolumeNotification = delegate { };

        public DgMic()
        {
            MMDeviceEnumerator enumerator = new MMDeviceEnumerator();
            _devices = enumerator.EnumerateAudioEndpoints(EDataFlow.eCapture,
                EDeviceState.DeviceStateActive);

            _count = _devices.Count;

            for (int i = 0; i < _count; i++)
            {
                _devices[i].AudioEndpointVolume.OnVolumeNotification += AudioEndpointVolume_OnVolumeNotification;
            }
        }

        void AudioEndpointVolume_OnVolumeNotification(AudioVolumeNotificationData data)
        {
            OnVolumeNotification(data);
        }

        public void SetMicStateTo(DgMicStates state)
        {
            for (int i = 0; i < _count; i++)
            {
                try
                {
                    _devices[i].AudioEndpointVolume.Mute = state == DgMicStates.Muted;
                }
                catch
                {
                    //We don't care about it beeing set or not.
                    //Sometimes, it doesn't work.
                }
            }
        }

        public bool AreAllMicsMuted()
        {
            var result = from p in _devices where p.AudioEndpointVolume.Mute == false select p;

            return !(result.Any());
        }
    }
}

Roundabout 60 lines, and that’s it. Yeah, well, almost. To make these 60 lines work, I needed to implement „some“ Interfaces:

some_interfaces

Which is ok, really. They are all quite well documented. And I felt free to leave out some stuff I don’t need. For my next project, I’ll take CSCore, which is by now the best library I’ve seen so far.

However, back to the class. In fact, it’s pretty abstract. You can switch the Microphone on or off (via setting the state based on the enum), and you can get to know, if all mics are muted. That’s it.

To accomplish that, you need a reference to the Device and it’s AudioEndpointVolume interface. You can get that by enumerating through all Devices (via the corresponding IMMDeviceEnumerator-Interface). In this case, I’m only interested in so called „communication“-devices, which are mostly microphones.

To mute or un-mute the microphone, I iterate through all known devices and set their state corresponding:

public void SetMicStateTo(DgMicStates state)
{
	for (int i = 0; i < _count; i++)
	{
		try
		{
			_devices[i].AudioEndpointVolume.Mute = state == DgMicStates.Muted;
		}
		catch
		{
			//We don't care about it beeing set or not.
			//Sometimes, it doesn't work.
		}
	}
}

And, to get the information, if all devices are muted or not, I do a little bit of LINQ (Love it! <3)

public bool AreAllMicsMuted()
{
	return !((from p
			  in _devices
			  where p.AudioEndpointVolume.Mute == false
			  select p).Any());
}

Now, for deeper information, you can read through the reference, starting here.

In fact, this is only a short summary about the interfaces being used, but it’s actually enough to get some insights. The API is quite powerful. I’m still missing an interface to grab the PCM data not only from an endpoint, but to intercept it directly from a certain application to the endpoint. As far as I know, this is not possible.

The Application

The Application itself should seaminglessly integrate into the taskbar. This is accomplished by using an icon that looks like the loudspeaker in Windows 7. Keep in mind that the Icon is normally hidden in the taskbar, so you have to set it to visibile like it’s explained here. I have no idea how it will look on Windows 8. And when it’s muted, it is resembled by the „head“ getting „red“.

It’s as simple as that. During installation, you can add it to autostart. The tool itself has no „Add to Autostart“-function, nor has it a global hotkey. However, it has a „force“ mode.

The „Force“-Mode.

During development, I noticed that Skype sets the microphone back to normal, if you start a call. Which is, normally, perfectly fine. However, many Notebooks or Ultrabooks have an integrated mic, so in theory, each application could re-enable the microphone. Maybe sometimes, this is just not what you want. So, you can enable a „Keep State“ in the context menu. The application gets notified if the state of the microphone changes. It then tries to set it back to muted (or unmuted, depending on your selection). This might not work from time to time, though.

That’s it.

Just a few lines on this topic. However, if you like this tiny little tool and can’t wait to get it, head over to my Tools-Section to please your desire. 😀

P.S.:

The tool itself is open source. So, feel free to head over to the GitHub-project, fork it and add the missing features (Hotkey, Add to Autostart – you know. 😉 ) by yourself. 😉

Die perfekten Pommes

27 Apr

Hinweis: Wenn ihr heute Nacht schlecht gepennt habt, dann solltet ihr vielleicht lieber morgen Pommes machen. Hier wird Öl auf über 170°C und mehr erhitzt. Dabei solltet ihr wach sein, damit nichts schief geht. Für eventuelle Schäden, die durch das Befolgen dieser Anleitung entstehen, übernehme ich keine Verantwortung. Echt nicht.

Pommes kann man auch wunderbar ohne Friteuse selber machen. Ihr benötigt dafür:

Einkaufsliste / Utensilien

  • Kartoffeln (Ich hab‘ mehligkochende verwendet, soll wohl prinzipiell mit jeder Sorte gehen.)
  • Frittieröl (Achtet wirklich darauf, dass es sich um Frittieröl handelt. Andere Öle könnten den hohen Temperaturen nicht standhalten.)
  • Einen großen Topf (MIT PASSENDEM DECKEL!) (Und mit „groß“ meine ich eigentlich „hoch“.)
  • Haushaltsthermometer (Must-Have)
  • Schaumkelle (Pfannenwender geht auch)

Zubereitung

  1. Schneidet die Kartoffeln in Stifte, wie man sie als typische Pommes eben kennt. Ich habe gelesen, dass man sie wohl nicht zu schälen braucht, aber da wars schon zu spät. 😛
    Probiert es einfach mal aus, die Kartoffeln ungeschält zu lassen. Würde mich über Feedback freuen. 🙂

    Pommes geschält und gewaschen.

    Pommes geschält und gewaschen.

    Die Pommes habe ich vorher in Wasser einweichen lassen, ungefähr ne halbe Stunde. Zumindest abwaschen solltet ihr sie, denn die Kartoffelstärke ist sowohl Freund als auch Feind. Ein kleines bisschen Rest-Stärke gibt eine wunderbare Kruste, zuviel Stärke verhindert die Krustenbildung. Denkt daran, die Pommes abzutrocknen!

  2. Als nächstes füllt ihr das Frittieröl in einen Topf. Als Richtwert: Ich habe in einen 5l Topf 2l Öl reingekippt. Wichtig ist, dass ihr genug Platz nach oben lasst, da das Öl sprudelt, sobald das Frittiergut drin ist. Erhitzt nun das Öl auf 140°C.

    Das Öl bekommt langsam Temperatur

    Das Öl bekommt langsam Temperatur

  3. Sobald das Öl die Temperatur erreicht hat, tut ihr einen Teil der Pommes in den Topf. Ihr solltet darauf achten, dass die Pommes „schwimmen“ können, also lieber etwas zuwenig als zu viele in den Topf tun. Frittiert sie nun für 2 Minuten vor.

    Der erste Durchgang

    Der erste Durchgang

  4. Nach den zwei Minuten holt ihr die Pommes mit einer Schaumkelle oder einem Pfannenwender aus dem dem Topf und legt sie auf Küchenkrepp, damit das überschüssige Fett aufgesogen werden kann.

    Der erste Durchlauf ist abgeschlossen. :P

    Der erste Durchlauf ist abgeschlossen. :P

  5. Sobald ihr alle eure Pommes einmal durch den Topf gejagt hab, erhöht ihr die Temperatur des Öls auf 170°C. Wie Eingangs erwähnt, hält diese Temperatur nur spezielles Frittieröl durch. Generell gilt: Wenn es anfängt zu rauchen (ein bisschen Dampf ist beim frittieren normal), dann solltet ihr abbrechen, da sich eventuell krebserregende Stoffe im Öl bilden können.
    Gebt die Pommes nun in das Öl, und frittiert sie solange, bis sie goldbraun sind.

    "Eine neue Runde, eine neue Wahnsinnsfahrt!"

    „Eine neue Runde, eine neue Wahnsinnsfahrt!“

  6. Dann die Pommes aus dem Topf holen, nach Belieben würzen und servieren – und guten Appetit. 😉

    Yummi. :)

    Yummi. :)

    Und nochmal der Hinweis: Man löscht einen Fettbrand NIEMALS mit Wasser. Wissenschaftliche Erklärungen, weshalb und warum, finden sich genug im Netz. Sollte es doch zur Flammenbildung kommen, Topfdeckel drauf! Das entzieht dem Feuer den Sauerstoff. Hilft das nicht, oder schlagen euch die Flammen schon meterhoch entgegen, Türen schließen, Feuerwehr rufen und das Haus verlassen. Sachwerte kann man ersetzen.
    P.S.: Der Flammpunkt von Frittieröl wird durch Verunreinigungen herabgesetzt, 250°C – 300°C solltet ihr nicht überschreiten! Allerdings – wenn ihr die ganze Zeit beim Topf bleibt, die Temperatur kontrolliert, und den Topf von der Platte nehmt, wenn es raucht, passiert auch nichts. 😉

The HudsonBeacon

16 Mrz

At my company, we are using Hudson as our CI-System. Some weeks ago, I created my first project on the CI. I kept on working, did some Check-Ins – and after some hours, I realized that the project was broken. I just noticed it accidentally, so I thought about a solution.

Some weeks (months) ago, I ordered the Blinkstick, created by Arvydas. In fact, it’s an LED you can plug into your computer and control via an API or even via a Web-Interface (see the website for further info). I bought it with no further usage in mind (it glows. I mean – yeah, that’s enough, isn’t it? 😛 ). In fact, the stick ain’t that expensive – like £9.99 if you buy the „solder it yourself“-kit, and £14.99 if you take the pre-soldered.

Hint: For this project, I’m using version 1.0 of the stick, which uses a Piranha RGB LED. The new and improved version 1.1 has a presoldered SMD RGB LED, which is much brighter and has a better mixture of colors. I really like the new version – although I don’t know what to do with it yet.^^

After the failure, I thought about utilizing the blinkstick as an indicator for the status of my own builds on the companies CI-System. Sometime ago, someone used a traffic light for this purpose. I got inspired by this built an started coding.

The Hardware

I ordered the BlinkStick I’m using for this project quite a while ago. So basically, everything concerning the hardware portion of this project was already in place.

The Software

I’m a .NET-Guy. Yeah, some of you might not like that, but hey – I really love using C#. I was pretty excited when I noticed that the BlinkStick – Application was written in C# AND GPL’ed.

I took all the guts that are necessary to talk to the BlinkStick and worked out a stripped down demo application. And then, there was light. 😉

First Test

Afterwards, I thought about how one might manage to get the states of the projects out of Hudson. Fortunately, Hudson offers a feed with the last build states of all projects in a view. So I created a view with all my projects, accessing the latest-Feed.

I wanted the stick to glow like every 30 or something minutes in green, if everything is alright. It should, however, glow red if a built failed. The stick does this now by pulsing four times red, then waiting for the time that is set in the settings, and pulsing again four times, and so on… The stick pulses blue, if the server is not reachable.

Finally, it was like some hours where I build the application which resides in the system tray and offers a settings dialog, in which you can set the uri for the feed, the brightness of the stick and the timings for certain settings.

hudsonBeaconSettings

The application itself might be buggy, as it was written in a few hours without much of testing.

All in all, it was a fun project, and I’ll might be updating it from time to time. If you want, feel free to get a BlinkStick, fork the project on github and build your own HudsonBeacon. 😉

Last but not least, I made a small video with the different states:

P.S.: This project was build with extensibility in mind. In fact, it’s written against interfaces. So, you might exchange the Hudson stuff for a system of your choice. It’s up to you. 😉

Links

The Project on GitHub: The HudsonBeacon
The Hardware: The BlinkStick