Tag Archives: Hanny

Fixing HDMI-CEC on the Wandboard

I (Hanny) have recently bought a Wandboard Quad and have been playing with it since I got it. My primary objective was to get XBMC running on that device using ArchLinuxARM which was possible after some fiddling with the proprietary stuff (this deserves its own post some time in the future). Many thanks to Stéphan Rafin, without his work, I would not have been able to do that.

After finding out (also, thanks Stéphan) that the Freescale i.MX6 SoC on the Wandboard supports HDMI-CEC, I was eager to get it running on the wandboard. Sadly though the CEC signal is not properly routed on the wandboard.

But according to a post in the wandboard forums with instructions, you can actually fix this if you have some soldering skills (which I have absolutely not!). So I handed my board to a fellow PI member (Neutrino) who will describe the things he did:

The pins for CEC are available but there is no connection from the SoC to the HDMI-connector. But if you have some SMD-soldering skills (or a friend who can do that), you can fix it yourself. Be careful though as this WILL VOID YOUR WARRANTY.

It isn’t hard to solder the 3 things but you should be careful not to damage a pad. You need a soldering tip with 1,5-3mm width, thin solder, an electronic tweezer and a good loupe (or microscope). Soldering flux is also helpful for good joints.

1. You have to remove the 0Ω resistor R383 on the bottom side of the processor board. Maybe you could unsolder it carefully, to recycle it in step 2. Because it is in tiny 0402 package I unsoldered it at one time with a 2mm width soldering tip on the side over both soldering joints and add a bit solder until I could smoothly push the resistor from the pads.
2. We need to connect the 2 empty pads of R405 on the bottom of the baseboard. We could use the R383 resistor or a piece of wire which we cut after soldering on both pads or maybe we simple solder a soldering blob over the two pads (I took a new 0Ω resistor in 0402 package because I had it in my reach).
3. The “most difficult” part is to solder a wire from the connector-side pad of R383 to the testpoint TP78 on the bottom side of the processor board. Cut a 2cm piece of insulated thin wire bend it right and remove insulation or enamel the ends before soldering it.
 

Bottom side of processor board.

Bottom side of processor board. The white line shows to the testpoint-labels. The purple line illustrate the wire.

Enamelled copper wire from below pad of R383 to testpoint TP78.

Enamelled copper wire from below pad of R383 to testpoint TP78.



This two empty pads of R405 have to be short connected together.

This two empty pads of R405 have to be short connected together.



Thanks again Neutrino!

To me(Hanny), the needed software-modifications are far more simpler :)

Now that you have routed the cec signal to the right pins, you just need a slightly modified kernel and a modified libCEC (thanks again, mighty Stéphan :)).

You’ll have to compile the modified kernel (be sure to set CONFIG_MXC_HDMI_CEC in the kernel config) and the modified libCEC and install both (you can find PKGBUILDs for ArchlinuxARM here).
If you now connect hdmi to a CEC-enabled tv (every manufacturer calls it differently!), cec-client should spit out some data!

Compiling xbmc with

should enable libCEC in xbmc. Afterwards, xbmc should recognize your TV as CEC input device and the whole thing should work!

Impressionen FWSV-Schulkonzert 2010

Obwohl das Schulkonzert bei uns erst morgen aufgeführt wird, gibt es hier schon brandaktuelle Bilder ;P Dabei handelt es sich aber mehr um “technische Impressionen” (aka. Poserpics) vom Bühnenaufbau, unserer neu eingerichteten Beleuchterkammer und den Mischpulten für Sound&Light. Als inoffizieller Ex-Beleuchter bemüh ich mich erst garnicht, über die technischen Details, die mir nur waage bekannt sind, zu sprechen, sondern hoffe einfach, dass diese hier von dem Kollege früher oder später nachgetragen werden :)

WPA2 hacking mit pyrit

Neulich hatte ich, dank Robert, mal die Gelegenheit ein relativ Leistungsstarkes System (QuadCore, GeForce 8800GTX) für WPA2-hacking zu missbrauchen. Wir haben das ganze schon einmal mit der guten alten aircrack-ng Suite ausprobiert, sind dort aber trotz der Leistung nur auf 2k Keys/s gekommen.

Für die, denen der Process nicht so geläufig ist: Im Gegensatz zu WEP ist bei WPA/WPA2 keine so grundlegende Implementierungslücke bekannt, was den cracking-Aufwand ungleich größer macht. Mit genügend Packets (IVs) lässt sich ein WEP AccessPoint verdammt einfach “öffnen”, bei WPA2 existiert etwas in der Art aber nicht, deshalb gibt es hier eine andere Vorgehensweise:

Man snifft einen sog. Handshake eines WPA-Clients zum AccessPoint mit, und generiert anschließend Hashes  aus Passwort und ESSID. Diese Hashes hängen nur von Passwort und ESSID ab, einmal generierte Hashes können also für alle APs mit gleicher ESSID genutzt werden. Das Generieren der Hashes ist der mit Abstand “teuerste” Teil des Prozesses. Mit den generierten Hashes kann man nun einen Abgleich über einen vorliegenden Handshake laufen lassen.

Die Aircrack-ng Suite vereinfacht diesen Prozess, das Programm generiert und checkt alles automatisch, benötigt wird eine Wordlist und ein cap-File mit Handshake. Leider gibt es im Internet Programme, welche die Hashes wesentlich schneller generieren, als Aircrack: pyrit

Das Programm nutzt die (relativ neue) CUDA(Nvidia)/Stream(ATi)/OpenCL(offener Standard) Technik der neueren Grafikkarten um eine massive Beschleunigung zu erreichen. Auf unserem Testsystem lief die CPU mit rund 4×500 Keys/s, die Grafikkarte aber mit etwa 7k Keys/s! Somit lag unsere Gesamtleistung bei etwa 9k Keys/s, Peaks lagen teilweise bei 9.7.

Durch pyrit wird der Vorgang also stark beschleunigt, da WPA Keys aber mindestens 8-stellig sein müssen ist hier an Bruteforcing noch nicht zu denken, somit bleibt einem nur eine Dictionary/Wordlist-attack. Hiermit sind wir auch schon an der Schwachstelle des Systems angelangt: ohne gute Wordlist sind die Chancen tatsächlich einen Hit zu bekommen gleich Null. Nachdem unser erster Test vollkommen ins Wasser ging (englische Wordlist, etwa 1.5GB), hab ich mich mal nach sinnvollen Wordlists umgeschaut und kaum was gutes gefunden. Also sind wir zu dem Schluss gelangt, dass man sich selbst eine zusammenstellen sollte, hier gibt es ganz gute Anfänge. Mit Hilfe von “sort” und “uniq” kann man damit ganz gute Listen erstellen. Die Schwachstelle einer solchen Liste ist allerdings, dass fast niemand ein Wort wie “Baggerfahrer” als Key benutzt ( ich bin mir nicht sicher warum, aber selbst WEP Netzwerke haben dann meistens eine Mutation des Wortes als Passwort, wie zB “Baggerfahrer123”), also sollte die so generierte Wordlist noch mutiert werden. (Lässt sich mithilfe einfachster Python-scripte sehr leicht machen, da pyrit auch stdin als Eingabe akzeptiert)

Um hier nochmal ein etwas “handfesteres” Tutorial abzuliefern, schildere ich mal die grundsätzliche Vorgehensweise (hier am Beispiel von CUDA):

Hier genutzt: pyrit SVN rev 199

Man braucht:

  • einen WPA-Handshake im cap-Format (sehr einfach zu erstellen mit Aircrack-ng, Tutorials gibts bei der Suchmaschine deiner Wahl)
  • pyrit, am besten die neuste dev-Version
  • cowpatty
  • eine GPU mit CUDA/Stream/OpenCL-Support (nicht zwingend, aber strengstens empfohlen)
  • Im Falle von CUDA am besten die 3.0 Beta verwenden, war bei uns kompatibler und ebenso stabil (dürfte mittlerweile neuere Versionen geben, einfach bisschen rumprobieren :))

Nachdem der CUDA-Driver und das Toolkit richtig installiert sind, baut man pyrit nach den Instructions, bei cowpatty genügt ein make.

Falls man keine MySQL oder sonstige Datenbank als Backend nutzen möchte, braucht pyrit keine weitere Konfiguration.

Mit “pyrit -i wordlist.txt import_passwords” lässt sich die Wordlist einlesen, wer die Wordlist gerne durch einen Manipulator jagen will, kann das in etwa so machen “./mymanipulator.py wordlist.txt | pyrit -i – import_passwords”.

Anschließend erstellt man eine ESSID mit “pyrit -e MyESSID create_essid”, welche man dann mit “pyrit -e MyESSID batch” angreifen kann. Nach dem generieren der Hashes checkt man diese mit Cowpatty “pyrit -e MyESSID -o – export_cowpatty | /path/to/cowpatty -d – -s MyESSID -r mycap.cap”.

Das ganze lässt sich auch perfekt mit einem Rutsch erledigen, dazu bedienen wir uns mal wieder einer einfachen Pipe:

“pyrit -e MyESSID -o – batch | /path/to/cowpatty -d – -s MyESSID -r mycap.cap”

Am besten man hofft nun auf einen Treffer, genügend Zeit hat man ja :)

Disclaimer:

Dieser Artikel dient zur reinen Information und Fortbildung. Das Umgehen von Sicherheitsbeschränkungen Dritter ist nicht vorgesehen.

26C3

Seit gestern sind wir nun wieder beim ST der hier “öfters” mal die Events hostet :)

Anlass dazu ist, wer hätte es gedacht, der 26C3. Eigentlich wollten wir ja nach Berlin, dann nach Karlsruhe und jetzt sind wir mal wieder hier geblieben.
Leider haben wir hier aufgrund der Location und anderen aktuellen Problemen etwas eingeschränktes Internet, was uns zu einigen “routing-über-externes-WLAN”-Maßnahmen getrieben hat:

WLAN-Client

WLAN-Client im hintersten Zimmer

Omni

Etwas übertriebene Omni-Antenne am Fenster

Zaun

Aufbauen der Antenne

Leider war es uns nicht möglich, mehr als zwei sinnvolle Routen zu finden, das Setup ist nun relativ einfach

  • default route über (mehr oder weniger) natives Netz hier
  • Traffic zu einem bestimmten Server in FR. läuft durch SSL-tunnel über ein anderes WLAN

Somit erreichen wir ein einigermaßen sinnvolles Load-balancing und können surfen _und_ 26C3 schauen :) Topics waren bis jetzt:

  • Routing
  • Routing
  • WLANs öffnen
  • Routing
  • VPN
  • 26C3 (vorallem hacked)
  • pCNC (Hard- & Software)

feedcher

Nachdem ich mich bisher eher im Hintergrund betätigt hab’, meld’ ich mich nun auch mal zu Wort.
Ich versuche mal das Programm vorzustellen an dem ich momentan am ehesten arbeite :) : den feedcher.

Der Post hier wird vermutlich ab und an mal editiert werden, der jetzige Status ist mehr ‘ne Preview.

Warum der Name?

feedcher ist eine Zusammensetzung von “feed” im Sinne von RSS Feed und dem englischen Wort “fetch” was im Grunde schon den kompletten Sinn des Programms erklärt.

Sinn des Programms

Das Programm soll, bzw. ist schon auf eingeschränkte Art und Weise, fähig sein, RSS Feeds von externen Seiten zu fetchen. Mit fetchen meine ich hier aber nicht einfach die XML-ähnliche Datei des RSS Feeds auszulesen und zu speichern, sondern den kompletten Content der verlinkten Seiten zu analysieren und die wichtigen Sachen  zu speichern.

Der Hintergrund hierfür ist, dass viele (auch sehr große Seiten) die ursprüngliche Idee des RSS-Feeds (zumindest meiner Interpretation nach) etwas vernachlässigen, denn der <item> Block einer RSS-XML sollte meiner Meinung nach den kompletten Text des Artikels beinhalten, dies tut er aber in den seltensten Fällen. Wäre der <item>-Block korrekt, wäre es möglich den Feed zu laden und anschließend, unabhängig vom Zugang zum Internet, zu lesen.

Der feecher soll diese Lücke stopfen und den tatsächlichen Inhalt des <item> in einer MySQL Datenbank ablegen, diese stellt die ideale Möglichkeit dar, den Inhalt danach weiter zu verarbeiten (php, download als tgz, Erstellung eines neuen, vollständigen RSS etc)

Implementierung

Das Programm soll nach einer bereits bekannten Methode funktionieren (siehe munin oder logwatch):

Ein sogenannter Node lädt, verwaltet und ruft Plugins für jeden einzelnen RSS Feed auf, die dem Node dann die Daten zuführen und anschließend in die Datenbank geschoben werden. Der Node ist in dem Fall in C++ geschrieben, verwendete Libraries sind bis jetzt openssl (md5), curl (http) und mysqlpp (MySQL, obviously).

Die Plugins können in jeder beliebigen Sprache geschrieben sein, sie müssen nur auf stdout ihre Config und später in Dateien ihre Results ausgeben können (Ruby, Perl, Python…).

Bearbeitung eines Beispielfeeds

Der Node erkennt ein Plugin, holt sich dessen Config (Argument ist hier “autoconfig”) über den stdout (nach dem Schema “feedUrl=www.foobar.foo”) und holt sich den Feed. Nun wird jeder <item>-Block md5-gehashed und überprüft ob dieser Hash schon in der Datenbank existiert, wenn nicht wird der <item>-Block in eine Datei geschrieben und das Plugin mit dem Filename als Parameter aufgerufen. Das Plugin verarbeitet nur den <item>-Block und schreibt die Ergebnisse in seine neue Datei, welche der Node anschließend einliest und die ermittelten Daten in die Datenbank schreibt.

Status

Die Grundzüge des feechers funktionieren schon, eine bestimmte, hier nicht genauer genannte, Seite wird bereits korrekt eingelesen und verarbeitet. Im Moment hängt es noch an dem Vorhandensein eines korrekten Plugins, das von mir (in Python) geschriebene Plugin schafft es bisher nicht, die HTML-Tags korrekt zu entfernen, das sollte aber das kleinste Problem werden.

Die Entwicklung liegt zwar momentan auf einer kurzen Eisstrecke, wird aber bestimmt wieder anlaufen, auf Anfrage kann man die Quellen aber jetzt schon erhalten :)

mfg Hanny

PS: Feedback & comments are highly appreciated