seeseekey.net - Invictus Deus Ex Machina

Vor eini­ger Zeit spielte ich mit dem Gedan­ken einen Disas­sem­bler für Mac OS X zu pro­gram­mie­ren. Aller­dings wollte ich nicht alles neu erfin­den und schaute mich des­halb nach einem pas­sen­den Frame­work um. Gefun­den habe ich dabei Capstone.

capstone-engine.org

Dabei han­delt es sich um ein freies, unter einer BSD-Lizenz lizen­zier­tes, Frame­work zur Disas­sem­blie­rung. Über ver­schie­dene Bin­dings kann das Frame­work aus den unter­schied­lichs­ten Pro­gram­mier­spra­chen ange­spro­chen wer­den. So gibt es unter ande­rem Bin­dings für C#, Java, Ruby und Python. Das Frame­work selbst ist dabei in C geschrie­ben. Caps­tone unter­stützt dabei eine Reihe von Pro­zes­sor­ar­chi­tek­tu­ren wie X86, Sparc, MIPS und ARM. Bezo­gen wer­den kann Caps­tone unter capstone-engine.org.

Bei EncFS han­delt es sich um eine Imple­men­tie­rung eines Ver­schlüss­lungs­sys­tems für beste­hende Datei­sys­teme. Bei die­sem Sys­tem wird jede Datei für sich ver­schlüs­selt und das dar­un­ter lie­gende Datei­sys­tem genutzt. Neben der Ori­gi­nalim­ple­men­tie­rung von EncFS gibt es auch Por­tie­run­gen in andere Pro­gram­mier­spra­chen. Mit die­sen Por­tie­run­gen kön­nen EncFS ver­schlüs­selte Daten auch unter Java und .NET aus­ge­le­sen werden.

Die Java­va­ri­ante von EncFS trägt dabei den Namen „encfs-java“ und ist auf Git­Hub zu fin­den. Neben die­ser gibt es auch eine Vari­ante für .NET wel­che in C# geschrie­ben ist und auf Bit­Bu­cket zu fin­den ist. Ursprüng­lich han­delt es sich bei „encfs-dotnet“ um eine Por­tie­rung von „encfs-java“. Mitt­ler­weile wurde diese Imple­men­tie­rung aber kom­plett neu geschrie­ben. Wie bei der Ori­gi­nalim­ple­men­tie­rung, han­delt es sich auch bei den Por­tie­run­gen um freie Soft­ware. Die Java-Portierung steht dabei unter der GPL, wäh­rend die .NET Imple­men­tie­rung unter der LGPG steht, was deren Ver­wen­dung fle­xi­bler gestaltet.

Wei­tere Infor­ma­tio­nen gibt es unter:
https://de.wikipedia.org/wiki/EncFS

Möchte man in einer .NET respek­tive Mono­spra­che einen Anwen­dung schrei­ben wel­che mit der Twit­ter API inter­agiert, so sollte man hier­für eine Biblio­thek nut­zen um den Auf­wand in Gren­zen zu halten.

tweetinvi.codeplex.com

Eine emp­feh­lens­werte Bibli­to­thek in die­sem Bereich ist dabei Tweet­invi wel­che auf Code­P­lex zu fin­den ist. Tweet­invi ist dabei unter der Micro­soft Public License lizen­siert und somit freie Soft­ware. Die Biblio­thek ist dabei pro­blem­los in der Lage meh­rere Mil­lio­nen Tweets zu ver­ar­bei­ten und befin­det sich in akti­ver Ent­wick­lung. Ein ein­fa­ches Bei­spiel um einen Tweet abzu­set­zen könnte dabei so aussehen:

IToken token=new Token(twitterAccessToken, twitterAccessTokenSecret, twitterConsumerKey, twitterConsumerSecret);
ITweet tweet=new Tweet(tweetText, token);
bool success=tweet.Publish();

Damit hätte man den ers­ten Tweet mit die­ser Biblio­thek abgesendet.

Manch­mal möchte man eine Zei­chen­kette im Arbeits­spei­cher nicht län­ger als nötig im Klar­text vor­hal­ten. Hier­für gibt es unter .NET/Mono die Klasse „Secu­re­String“. Diese ver­schlüs­selt den Klar­text, so das die­ser nicht ohne wei­te­res im Spei­cher zu fin­den ist. Lei­der ist die Nut­zung der „Secu­re­String“ etwas komplizierter:

SecureString secureString=new SecureString();
secureString.AppendChar('g');
secureString.AppendChar('e');
secureString.AppendChar('h');
secureString.AppendChar('e');
secureString.AppendChar('i');
secureString.AppendChar('m');

// in Klartext umwandeln
IntPtr secureStringPointer=Marshal.SecureStringToBSTR(secureString);
string klartext=Marshal.PtrToStringAuto(secureStringPointer);

Hier muss man abwä­gen, ob sich die Nut­zung eines sol­ches Kon­struk­tes lohnt, oder man wei­ter­hin nor­male Strings für sen­si­ble Daten nutzt.

Manch­mal möchte aus einer Desk­to­pan­wen­dung her­aus eine Mail ver­schi­cken. Das ist inso­fern pro­ble­ma­tisch, da man die Zugangs­da­ten für einen Mai­lac­count nicht in einer Anwen­dung hin­ter­le­gen sollte. Aus Web­an­wen­dun­gen her­aus ist das Sen­den von Mails dage­gen eine ein­fa­che Sache. Also was liegt näher als die­sen Vor­teil für das Sen­den von Mails aus Desk­to­pan­wen­dun­gen her­aus zu nutzen.

<?php
    $reciever=$_POST["reciever"];
    $allowedRecieverDomain="example.org";
    $subject=$_POST["subject"];
    $text=$_POST["message"];

    //Sender
    $senderName="Mailer";
    $sender="mailer@example.org";

    //Additional challenge
    $challenge="abc123";
    if($challenge!=$_POST["challenge"]) return;

    //Check reciever
    $atCount=substr_count($reciever, "@");
    if($atCount>1) return;

    if(!(strpos($reciever, "@" . $allowedRecieverDomain)===FALSE))
    {
        mail($reciever, $subject . " - (" . date("d.m.y - H:m:s") . ")", $text, "From: $senderName <$sender>");
    }
?>

Ein klei­nes PHP Skript mit dem Namen „mailer.php“ sorgt dafür das die Mail bzw. der Text der Mail in Emp­fang genom­men wird. Anschlie­ßend wird nach­ge­schaut ob die Mail an einen vali­den Sen­der adres­siert ist. In die­sem Bei­spiel wer­den nur Mails an @example.org wei­ter­ge­lei­tet. Schließ­lich möchte man keine Spamschleu­der betrei­ben. Nun müs­sen die Para­me­ter in der Anwen­dung noch per POST-Request über­ge­ben wer­den. Unter C# könnte das ganze so aussehen:

System.Net.ServicePointManager.Expect100Continue=false;

string url="http://example.org/mailer.php";

using(var wb=new WebClient())
{
    var data=new NameValueCollection();
    data["sendername"]="Mailer";
    data["sender"]="mailer@example.org";
    data["reciever"]="developer@example.org";
    data["subject"]="Mail from Application";
    data["message"]="Message";

    var response=wb.UploadValues(url, "POST", data);
}

Der Quell­code ist dabei auf Git­Hub zu fin­den und steht unter der AGPL.

Unter .NET ist es manch­mal sehr nütz­lich zu wis­sen, ob an die Anwen­dung ein Debug­ger ange­hängt ist. Im Name­space „System.Diagnostics“ gibt es dazu auch die pas­sende sta­ti­sche Eigen­schaft mit dem Namen „IsAt­ta­ched“. Die Nut­zung könnte dabei so aussehen:

if(Debugger.IsAttached==true)
{
    //Do something
}

Der Quell­text in den Block­klam­mern wird dabei nur dann aus­ge­führt, wenn ein Debug­ger an die Anwen­dung ange­han­gen ist. Das kann die IDE (Visual Stu­dio und Co.) sein, es kann aber auch ein bös­wil­li­ger Angrei­fer sein — wobei es natür­lich Ver­fah­ren gibt, die Erken­nung auszuhebeln.

Unter .NET gibt es eine Reihe von Attri­bu­ten, wel­che für ver­schie­denste Zwe­cke not­wen­dig sind. Natür­lich ist es inter­es­sant zu erfah­ren wel­che Attri­bute es gibt. Auf den ers­ten Blick sieht es so aus, als ob es in der MSDN von Micro­soft keine Auf­lis­tung der Attri­bute gibt.

Die Auf­lis­tung der Attri­bute in der MSDN

Beim genaue­ren Hin­schauen, wird man bemer­ken das es diese Liste gibt. Attri­bute wer­den in .NET von der „Attribute“-Klasse abge­lei­tet. Wenn man sich die Doku­men­ta­tion für diese Klasse anschaut wird man fest­stel­len, das es unten einen Bereich „Inheri­tance Hier­ar­chy“ gibt, wel­cher alle abge­lei­te­ten Klas­sen auf­lis­tet und somit auch alle Attribute.

Im Web kennt man sol­che Boxen zu genüge. Ein Such­feld in wel­chem in aus­ge­grau­ter Schrift „Suchen“ oder ähn­li­ches steht. Unter .NET ist das ganze lei­der nicht als vor­ge­fer­tig­tes Con­trol vor­han­den, so das man hier selbst Hand anle­gen muss. Für ein sol­ches Con­trol nimmt man eine Text­Box und setzt die Events „Enter“ und „Leave“ und befüllt sie wie folgt:

string grayedText="Search...";

private void tbSearch_Enter(object sender, System.EventArgs e)
{
	if(tbSearch.Text==""||tbSearch.Text==grayedText)
	{
		grayedText=tbSearch.Text;
		tbSearch.Text="";
		tbSearch.ForeColor=Color.Black;
	}
}

private void tbSearch_Leave(object sender, System.EventArgs e)
{
	if(tbSearch.Text=="")
	{
		tbSearch.ForeColor=Color.Gray;
		tbSearch.Text=grayedText;
	}
}

Damit steht in der Text­Box der aus­ge­graute Text „Search…“ wel­cher ver­schwin­det, sobald man den Fokus in die Text­Box setzt. Der Platz­hal­ter­text wird nur dann ange­zeigt, wenn kein Inhalt in der Text­box vor­han­den ist.

Wenn man mit nicht von einer Cer­ti­fi­cate Aut­ho­rity signier­ten Zer­ti­fi­ka­ten arbei­tet, so wird man frü­her oder spä­ter fol­gende Feh­ler­mel­dung unter .NET zu sehen bekommen.

Das Remotezertifikat ist laut Validierungsverfahren ungültig.

Gege­ben sei dabei fol­gen­des Beispiel

SmtpClient client=new SmtpClient(host, port);
client.EnableSsl=true;

SSL ist zwar akti­viert, aber das Zer­ti­fi­kat kann in die­sem Fall nicht vali­diert wer­den. Eine Methode um die Vali­die­rung abzu­schal­ten ist dabei fol­gen­den Ein­zei­ler über diese Zei­len zu schreiben:

ServicePointManager.ServerCertificateValidationCallback=delegate { return true; };

Danach bekommt man keine Zer­ti­fi­kats­war­nung mehr und kann die Ver­bin­dung nutzen.

Der Kindle als eBook Rea­der macht vie­les rich­tig. Nur beim Über­tra­gen von eige­nen Doku­men­ten wird es schwie­rig. Es gibt zwar die Mög­lich­keit Doku­mente per Mail oder USB auf den Kindle zu brin­gen, aller­dings wird das in man­chen Fäl­len etwas umständlich.

Der Kindle Paper­white im aus­ge­schal­te­ten Zustand

So bie­tet Ama­zon eine Kon­ver­tie­rung von PDFs in ein auf dem Kindle les­ba­res For­mat an. Um das ganze zu ver­ein­fa­chen, habe ich eine kleine Anwen­dung namens „Kindle Uploa­der“ geschrie­ben. Nach der Kon­fi­gu­ra­tion kann man ganze Ord­ner oder auch ein­zelne Dateien an sei­nen Kindle sen­den. Mit Hilfe der Option „-con­vert“ ist es mög­lich die Kon­ver­tie­rung in das AZW For­mat (für bes­sere Les­bar­keit) anzustoßen:

kindleuploader.exe -convert test.pdf folder test.txt

Die Anwen­dung ist dabei freie Soft­ware unter der GPLv3 und kann auf Git­Hub „besich­tigt“ wer­den. Alter­na­tiv kann das ganze als aus­führ­bare Datei her­un­ter­ge­la­den werden.