Die Einführung des Jugendmedienschutz-Staatsvertrags JMStV erfordert das Anbringen von Warnhinweisen zu dieser Seite. Erläuterungen zu den Piktogrammen finden sich im Mouse-Over.
Vielen Dank, dass Sie diese Hinweise beachten.
⇦2010

2014-01-12

Getting rid of that sticky tape

Like most people in the hacker and computer security community I've got a small piece of sticky tape covering the webcam in my laptop. At times I remove it, if I actually want to use said camera. But then you normally can not reuse it and need a new piece of tape. Quite annoying.

Manufactuers of course tell us, that the LED would indicate somebody using the camera. The problem is, that the camera in all tested models so far can be activated without the LED lighting up. But there was a simple fix to that: Couple the LED with a small mechanical shutter in front of the lens that is powered through the very same circuit as the LED. See my hand drawn sketch (which also misses a reverse polarity protection diode in parallel to the solenoid). Coupling the camera status LED with a mechanical shutter.

2012-03-29

Offener Brief an Frau Hohlmeier

Sehr geehrte Frau Hohlmeier,

heute veröffentlichte das EU-Parlament die Pläne zur Umsetzung einer neuen Cybercrime-Richtlinie

http://www.europarl.europa.eu/news/de/pressroom/content/20120326IPR41843/html/Hacking-IT-systems-to-become-a-criminal-offence

Darin wird auch explizit das Verbot der Herstellung und des Einsatzes von "Cyber-attack tools" gefordert (in der offiziellen Mitteilung des EU-Parlaments):

Cyber-attack tools

The proposal also targets tools used to commit offences: the production or sale of devices such as computer programs designed for cyber-attacks, or which find a computer password by which an information system can be accessed, would constitute criminal offences.

..., die Sie auf Ihrer Homepage ausdrücklich begrüßen:

http://www.monika-hohlmeier.de/eu-strafrecht-cyber-angriffe-sind-kein-kavaliersdelikt-konsequente-strafen-gegen-hacker-attacken-unternehmen-muessen-ihre-it-systeme-besser-schuetzen-ep-innenausschuss-zu-neuer-eu-richtlinie/

Sie schreiben:

Kein Autobauer darf es sich leisten einen Wagen ohne Sicherheitsgurte in den Verkehr zu schicken. Und wenn er dies doch tut, so muss er für möglichen Schaden haften. Diese Regeln müssen auch in der virtuellen Welt gelten.

Um bei ihrem schönen Auto-Vergleich zu bleiben: Ein solches Verbot von "Cyber-attack tools" käme einem Verbot von Crashtests in der Automobilindustrie gleich. Auf der einen Seite fordern Sie -- sinnvollerweise -- "(...) dass IT-Anbieter künftig stärker in die Pflicht genommen werden müssen.", gleichzeitig wollen sie aber genau die Werkzeuge illegalisieren, die genau dafür notwendig sind.

Man kann IT-Systeme nicht absichern, ohne sie durch aktive Angriffe auf Schwachstellen zu Überprüfen. Genauso wie man die Sicherheit von Automobilen nicht ohne Crashtests ermitteln kann.

Hackertools/Cyber-attack tools sind die Crashtests der IT. Man muss dabei auch ganz klar feststellen, dass man nicht zwischen guten und bösen Cyber-attack tools unterscheiden kann. Es spielt für den eigentlichen Angriff keine Rolle ob man zu Demonstrationszwecken mittels eines Angriffs den Windows-Taschenrechner startet (die Standard-Demonstration bei einer gefundenen Sicherheitslücke), oder stattdessen ein Spionage- oder Schadprogramm installiert und startet. Für das angegriffene Computersystem besteht darin kein Unterschied, es handelt sich in beiden Fällen um den selben Code. Der Unterschied besteht in weniger als ~25 Buchstaben Programmtext. Angenommen man würde Werkzeuge für die Überprüfung der Sicherheit von Systemen von den Verboten ausnehmen. Genau diese Werkzeuge ließen sich in böswillige Angriffswerkzeuge wandeln, durch den bloen Austausch von nur ein paar Zeichen.

Dazu weise ich Sie auch auf StGB §202c hin, der schon im Jahr seiner Einführung, 2007 war das, zu einigem Unmut in der IT-Sicherheitsbranche geführt hat.

Als Dienstleister im Bereich der IT-Sicherheit suche ich aktiv solche Sicherheitslücken und entwickle auch die Werkzeuge um sie zu Demonstrationszwecken auszunutzen. Es geht nicht anders. Man kann nur das Vorhandensein von Sicherheitslücken zeigen. Es ist aber nicht möglich für ein Programm zu sagen, dass es keine Sicherheitslücken hat. Dies wurde 1936 von Alan Turing in seinem Aufsatz zum sog. "Entscheidungsproblem" mathematisch bewiesen.

Der Rest der Mitteilung vom EU-Parlament zeugt leider von weitergehender Unkenntnis: So wird u.a. immer noch die IP-Adresse eines Geräts im Internet mit der Identität des Geräts und/oder des Benutzers davon gleichgesetzt. Dies ist schlichtweg falsch: So gibt es viele Netzwerke, u.a. die meisten mobilen Internet-Zugänge über GSM oder UMTS, bei denen sich mehrere Netzteilnehmer eine einzelne IP teilen. Bei Festnetzanschlüssen (z.B. DSL oder Einwahl über ISDN) wechselt die IP-Adresse bei jeder Einwahl, oder spätestens nach 24 Stunden.

Bei IP-Spoofing handelt es sich auch nicht um eine Form von "Identitätsdiebstahl" sondern allenfalls um die Falsch-, oder Nichtangabe eines Absenders. Vor allem aber stellt IP-Spoofing schon seit Jahren kein ernst zu nehmendes Sicherheitsproblem mehr dar; heutige Kommunikationsprotokolle im Netz sichern die Verbindung mit Hilfe kryptographischer Methoden wirksam ab.

Als IT-Dienstleister im Sicherheitsbereich sehe ich den aktuellen Vorstoß des EU-Parlaments mit einem sehr unguten Gefühl. Mir erscheint das Ganze vor allem als blinder Netzpolitik-Aktionismus angesichts der aktuellen Erfolge der Piratenpartei.

Ich möchte mit einem Zitat von Alexander Pope schließen, das gerade angesichts der Komplexität bezüglich des Internet und von IT-Systemen mehr als angebracht ist:

"A little learning is a dangerous thing;
Drink deep, or taste not the Pierian spring."

Mit freundlichen Grüßen

Wolfgang Draxinger

2012-03-29

Das war's dann mit dem Studentenleben

Es ist offiziell: Ich bin seit heute kein Student mehr, ich habe meine Diplomarbeit abgegeben!

2012-02-13

Make yourself a network audiosystem with shell scripts

A few people may remember my response to Lennart Poettering: Do you know about shell scripts? Shell scripts are an incredibly powerfull tool, because they allow to combine a number of simple programs into something very sophisticated. Today I present you: A network audio system consisting of sox, netcat, celt and of course a shell, for which I use simple /bin/sh. We also use a bit help of the OS kernel, so that this whole thing works as if it were an actual ALSA audio device.

Recipe

You need

  • sox to get the audio out of ALSA
  • celt - namely the programs celtenc and celtdec
  • netcat for networking
  • The snd-aloop kernel module

The server

#!/bin/sh
RATE=48000
CHANNELS=2
FORMAT=s16
PORT=12345

nc6 -l -p ${PORT} --continuous --exec \
   "celtdec - - | play -t ${FORMAT} -r ${RATE} -c ${CHANNELS} -"

The client

#!/bin/sh
RATE=48000
CHANNELS=2
SERVER=... # set this to your audioserver address
PORT=12345

# set this to one end of the ALSA loopback.
# hw:1,1,0 means, that we'll playback to hw:1,0,0
AUDIODEV=hw:1,1,0 

rec -r ${RATE} -b 16 -s -t wav | celtenc - - | nc6 ${SERVER} ${PORT}

And that's it. Of course this simple scheme has a few drawbacks. For one, the stream is transmitted in a OGG container. That one must be contiguous, so we use a TCP connection here. And due to the involved buffers this is not very low latency. Clearly, by writing a custom tailored server you can greatly reduce the latency. Despite this, it works surprisingly well: I just watched an episode of the IT-Crowd using it, having mplayer adjust the A/V-Offset. In my network, over a WiFi link I have about 200ms latency.

So start the server on your audio output machine by invoking the server script. On your client machine first load the loopback module ~/ $ sudo modprobe snd-aloop and use ~/ $ aplay -l to list the sound devices. If the loopback is registered as card 1 you're good to go. Otherwise adjust the client script. Then start it. You should see sox recording and giving you a UV meter of the audio "input".

Now you can use whatever ALSA capable program to play audio. The device would be hw:1,0,0 in our case. For example mplayer:

/netstorage/media/video/series/The_IT-Crowd/S02/ $ mplayer -ao alsa=hw=1.0.0 The_IT-Crowd_SO2E01.mkv

PulseAudio? Who needs it anyway!

2011-12-27

Scheisse ich bin ein Mem

Scheisse ich bin ein Mem

2011-12-02

Bit manipulation trickery

One recurring task when working with data structures is finding out if a given number (say an index into a sorting tree) is a power of 2.

A number is a power of two, if exactly one bit is set, so it all boils down to testing for that.

There are several way to do this. The most naive and inefficient way is to test for all the powers of two representable in a given amount of bits.

int ispow2(int x) 
{
    int bc = 0;
    for(int i = 0; i<sizeof(x)*CHAR_BITS; i++) {
        if( 1<<i & x )
            bc++;
        if(bc > 1)
            return 0;
    }
    return bc == 1;
}

This function is suboptimal, since it's O(n)

A better way, circulating the net for years is this little gem of bit trickery, which executes O(1)

int ispow2(int x)
{
    return !( (~(~0U>>1)|x) & (x-1) );
}

Unfortunately it only works for a specific type (you can of course adjust the most significant bit constant. But say you'd want to use this in a type agnostic macro. What I've seen in circulation is this (using the typeof Compiler extension -- which is not part of the C core language specification):

#define ISPOW2(x) ( ! ( (~(~((typeof (x))0) >> 1) | (x)) & ((x) - 1) ) )

Slightliy better is this:

#define ISPOW2(x) ( ! ( (1<<(sizeof(x)*CHAR_BIT-1) | (x)) & ((x) - 1) ) )

But those attempts look in the wrong direction: That most significant bit is only set to account for the case if x is 0.

In a project I wrote about 1 year ago I (re?-)invented the following method which works with any integral type:

#define ISPOW2(x) ( (x) && !( (x) & ((x) - 1) ) )

So far I've never seen it in circulation in the Internet. Maybe I am the first guy to write it that way, but I don't think so. (if I am: cool!)Nope. Some guys pointed to me to several bit twiddling hacks documents, where this is written that way. But you know what? I don't care, I came up with it myself, instead of just reading it somewhere. Of course credit where is credit due. I'm still interested who did invent that thing first.

2011-09-30

A Case against Wayland

If you didn't know already, I'm telling it here again: I'm not very keen of Wayland and the mentality it was created in. If you had to summarize it in one sentence it is this:

"Graphic clients take full control of the rendering process, the graphics system shall be only a thin layer that passes control of the output device over to the clients."

In Wayland terms, Wayland manages shared memory (framebuffers) and defines a protocol to pass those regions of graphics memory to clients which then use their method of choice to draw on it. Sounds good, right?

WRONG!

High quality graphics rendering is a notoriously difficult subject. To make matters worse many parameters directly depend on the output device. Just to name a few:

  • subpixel arrangement

    Just do a Google image search for "subpixel arrangement" to get an idea what's in the wild already and what will hit us in the near future. The 5 subpixel layouts offered by FreeType ({horizontal,vertical}{RGB,BGR}, None), do not nearly account for what's out there. To make matters worse, a system may be confronted with different subpixel arrangements on the same workspace (think multihead configuration). If rendering (of subpixel dithering/antialiasing) happens client side you'll get serious problems if you have connected, say, an AMOLED screen and a video projector (no subpixels at all) in clone mode; you'll get weird colour seam artifacts on the projector if you render for AMOLED and blurry fonts on the AMOLED if you render for the projector; oh and if you add a pivot function (display rotation) you'll have to switch arrangements in situ. So far you have to restart applications on Linux after a switch to use it.
  • color management

    Same problem like with subpixels, but another subspace. If you get direct access to the framebuffer you'll write exactly those values as they are sent to the device; unless your framebuffer was in a so called "contact color space" and a color transformation happened before sending it to the device. Admittedly, one could do color management in the compositor.
  • physical resolution

    Pixels are not necessarily square -- or rectangular in the future; I hope that one day we'll work with displays using a tightest circle packing arrangement for pixels (honeycombs), with >200 pixels per cm; you'd need not antialiasing on such high resolution displays, but still subpixel dithering. Now imagine a honeycomb pixel display sharing the workspace with a square pixel video projector.
  • rendering performance

    Most of the time the suggested rendering backends for applications are OpenGL and/or OpenVG. Unfortunately OpenGL is not the best choice when it comes to font rendering. However (font) glyphs are ther major information carrier on your typical computer screen. There are some attempts for high quality font rendering with OpenGL (Google "Vector Texture Maps" or "Valve Distance Maps"), but they're not very efficient: A 600kB vector font file blows up to several MB of texture data for just one single glyph size. Technically modern graphics cards are more than capable of rendering vector fonts, filled curves that is, directly (the Cairo developers are working on a curve renderer based on OpenGL Fragment Shaders), but then you have two additional layers of indirection. Also it still doesn't solve the problem of device dependence.

The high quality printer business knows this for years. All the better printers expect their input data as either PostScript or PDF. Why? Because those are not readily rendered raster images (which is what a printer actually puts on the medium), but abstract descriptions of the final result. Similarly the original TeX did output a format called DVI (DeVice Independent). Then a raster image processor (RIP) turns it into a raster image, carefully tailored to the characteristics of the device. There are businesses specialized in the development of device specific RIPs.

So lets say we get all those issues solved in the Wayland infrastructure. Then you're still stuck with the Wayland compositor being responsible for window management and input event retrieval/disposal. You've read right folks: The Wayland compositor is responsible for reading events from /dev/input/* processing them (a nasty business BTW, because many input devices out there are really fucked up), and handing it out to the clients.

Then it defines the whole window management behavior. Yes! With Wayland you can't simply switch your window manager, leaving the rest of the system untouched. You want another window manager, you need to implement a full Wayland compositor. Taking care of all the scrunities involved. Even worse, if the Linux developers decided on creating a new input device interface, say to address some upcoming issues, all Wayland compositors need to be updated. There's a nice German term for this: "Arbeitsbeschaffungsmaßnahme".

And after all of this it's responsible for compositing the windows to the screen(s), which means all the "eye candy" (I call it distractions) apply.

Wayland severely violates one of the core principles of X11: The separation of method and policy. A Wayland compositor mixes method and policy.

I tell you where this will end: In a plugin/module system. A core/mainline Wayland server (managing buffers of square pixel framebuffer memory regions), to which modules are attached that deal with input processing, window management and composition-effects. For stability reasons those will run in separate processes communicating with Wayland through some IPC mechanism (and if Murphy applies this will probably be D-Bus). Then, to tackle all those problems with device dependent rendering, an abstract rendering protocol/library will be introduced. Congratulations! You've just reinvented X11! The whole complexity of X11 is not some anachronistic burden, it's a necessity. I fully understand the X11 as we have it now, doesn't implement all the things we'd require for true device independence as I outlined above, mostly because X11 itself is pixel based.

On the Wayland homepage you can find this picture:

X architecture according to Wayland developers
X architecture according to Wayland developers.

However this picture is terribly simplified.
First it should be said that the Compositor, just like the Window Manager (they don't need to be the same!) are just regular X Clients themself. Designating the Compositor as something "special" is just wrong.
Second it completely omits the fact, that the X server is not monolithic and does not accesses all the different kernel interfaces from the same core code. There are in fact several modules, often in multiple instances, each responsible for one specific interface or device.

This is a much more accurate picture of what the X architecture looks like:

A more accurate picture of the X architecture
A more accurate picture of the X architecture.

If you want to replace X11 with something better (not worse), be my guest, you're preaching to the choir.

My dream graphics system was completely abstract. Creating a window didn't involve selecting visual formats, framebuffer configurations. It was just "a window". Only when actual content is involved I want to tell the rendering subsystem, which color space I use. Ideally all applications worked in a contact color space (e.g. CIE XYZ or Lab), but sending images in some arbitrary color space, together with color profile information. Fonts/Glyphs would be rendered by some layer close to the hardware, to carefully adjust the rasterizing to the output devices properties. And last but not least the whole system should be distributed. Being able to "push" some window from one machine's display, to another machine's (and this action triggering a process migration) would be pinnacle. Imagine you begin writing an email on your smartphone, but you realize you'd prefer using a "usable" keyboard. Instead of saving a draft, closing the mail editor on the phone, transferring the draft to the PC, opening it, editing it there. Imaging you'd simply hold your smartphone besides your PC's monitor a NFC (near field communication) system in phone and monitor detects the relative position, and flick the email editor over to the PC allowing you to continue your edit there. Now imagine that this happens absolutely transparent to the programs involved, that this is something managed by the operating system.

This is where I want to go. Not that cheap effects lollipop desktops Ubuntu/Canonical, Intel, RedHat/Fedora and Gnome(3) aim for.

2011-05-09

Sicherheitsmaßnahmen: Kontraproduktiv

Vor ein paar Tagen hat eine in einem ICE deponierte CD hektische Betriebsamkeit ausgelöst. "Gut," mag sich da so mancher denken, "es ist nichts passiert, aber was wäre gewesen wenn?"

Leider übersehen unsere Entscheider und die, die noch mehr Überwachung fordern ein kleines Detail: All ihre Maßnahmen bewirken keinen Schutz, im Gegenteil, es sind sogar sehr effektive Angriffsverstärker: Durch ein paar geschickt platzierte, vorgebliche "Pläne" für einen "Angriff" könnte man so sehr effektiv wichtige Wirtschaftszentren für mehrere Stunden, wenn nicht Tage lahmlegen. Man müsste die Pläne nur echt aussehen lassen.

Das ist so ein wenig wie Return Based Programming: Anstatt den vollständigen Shell-Code selbst mitzubringen, bringt man das System dazu, sich selbst mit seinem eigenen Inventar lahmzulegen.

2011-05-04

Osama Bin Laden wirklich durch Kopfschuss getötet?

Am Frühstückstisch wurde gerade eine tolle Verschwörungstheorie ausgesponnen: Mal angenommen die USA und Pakistan wussten, in gegenseitigem Einverständnis, wo sich Osama Bin Laden versteckt hielt. Weder die USA noch Pakistan hatten ein richtiges Interesse daran Osama Bin Laden zu fassen, töten oder sonstwie festzusetzen. Die USA nicht, weil die "Suche" nach Bin Laden auf politisch vertretbarem Weg gigantische Geldsummen für den Militäreinsatz in Afghanistan legitimierte. Pakistan nicht, weil die sich genau den peinlichen Fragen, denen sie sich ja jetzt stellen müssen, ausgesetzt sahen.

Also lässt man Osama Bin Laden als "Das Arschloch im Wandschrank" in vollem Wissen (in einem angeblichen Safehouse des ISI) leben und hin und wieder mal eine Video- oder Audiobotschaft verbreiten.

Jetzt kommt die Verschwörungstheorie: Am 1. Mai ist Osama Bin Laden gestorben. Nein, nicht durch Kopfschuss, oder irgend eine andere Gewalteinwirkung. Ganz natürlich, an irgendeiner Krankheit oder einem Herzinfarkt oder sowas in der Art krepiert. Natürlich kann man das so nicht stehen lassen, die Schmach für die USA den Staatsfeind Nr. 1 nie gefasst zu haben. Pakistan hätte es sicher auch nicht gefallen, wenn da auf einmal ein natürlich zu Tode gekommener Bin Laden durch die Straßen von Abbottabad getragen worden wäre.

Also zieht man schnell eine Aktion durch, in deren Rahmen man der Leiche noch schnell einen Kopfschuss verpasst. Und damit nicht bei einer Autopsie festgestellt wird, das Todeszeitpunkt und Zustand der Organe und Grund des Todes irgendwie nicht zu dem Einschussloch im Kopf passen, wird in aller Schnelle der Leichnam auf See bestattet.


Advertisement free Blog

The Out Campaign: Scarlet Letter of Atheism

Valid XHTML 1.0 Transitional CSS ist valide!


PGP Key:479F 96E1 2B49 8B0D 69F1 94EE F11B E194 2E6C 2B5E (last 32 bit of fingerprint are ID).

Impressum

This is a noncommercial private webpresence / weblog (blog), of
Dies ist eine nicht-kommerzielle Webpräsenz / Weblog (Blog), von

Wolfgang Draxinger

Please obtain the technical and administrative contact information from the WHOIS data of this domain. Technische und administrative Kontaktdaten sind bitte den WHOIS-Daten dieser Domain zu entnehmen.