Alain M. Lafon

I just found an article ranking highly on Hacker News (my favourite read) concerning the release of C# 4.0 – you can find it on blogs.msdn.com. On this blog Microsoft claims a couple of highly sophistacated new features. Being the spoiled guy I am, they just seem natural to me. Since they started their article with the words “The dynamic keyword is a key feature of this release.”, let me demonstrate the new features in a really dynamically typed language where they have been around for quite some time: Python

Dynamic

                        dynamic contact = new ExpandoObject();
                        contact.Name = "Patrick Hines";
                        contact.Phone = "206-555-0144";
                        

                        class contact: None
                        contact.Name = "Patrick Hines"
                        contact.Phone = "206-555-0144"
                        

Optional (or Default) Parameters

                        public static void SomeMethod(int optional = 0) { }
                        SomeMethod(); // 0 is used in the method.
                        SomeMethod(10);
                        

                        def some_method(optional = 0): pass

                        some_method()
                        some_method(10)
                        

Named Arguments

                        var sample = new List<String>();
                        sample.InsertRange(collection: new List<String>(), index: 0);
                        sample.InsertRange(index: 0, collection: new List<String>());
                        

                        def foo(bar, foobar): None

                        foo(bar='asdf', foobar=12)
                        foo(foobar=12, bar='asdf')
                        

I honestly know that a comparison of a statically typed language on the CLR and an interpreted dynamic language doesn’t account for too much. But since Microsoft is making a fuzz about dynamic being the keyword of the new release, I felt the urge to drop this note.

The Python code was tested with v2.5 – that’s the oldest installation I’ve got. However, it’s old enough, because .NET didn’t even have decent IPC back then (i.e. Named pipes were added in .NET 3.5).

Well, that’s my rant for the night – I’m going back to teaching myself a real programmers language(Clojure) – as you should, too(;

If you liked the article, follow me on twitter here

Today, a dear friend of mine came up to me and asked about the Python module binascii – particularly about the methods hexlify() and unhexlify(). Since he asked for it, I’m going to share my answer publicly with you.

First of all, I’m defining the used nomenclature:

• ASCII characters are being written in single quotes
• decimal numbers are of the type Long with a L suffix
• hex values have a x prefix

First, let me quote the documentation:

I’ll begin with hexlify(). As the documentation states, this method splits a string which consists of hex-tuples into distinct bytes.

The ASCII character ‘A’ has 65L as numerical representation. To verify this in Python:

>>> long(ord('A'))
65L

You might ask “Why is this even relevant to understand binascii?” Well, we don’t know anything about how ord() does its job. But with binascii we can re-calculate manually and verify.

>>> binascii.hexlify('A')
'41'

Now we know that an ‘A’ – interpreted as binary data and shown in hex – resembles ’41’. But wait, ’41’ is a string and no hex value! That’s no biggy, hexlify() represents its result as string.

To stay with the example, let’s convert 41 into a decimal number and check if it equals 65L.

>>> long('41', 16)
65L

Tada! It seems that ‘A’ = 41 = 65L.
You might have known that already, but please, stay with me a minute longer.

To make it look a little more complex:

>>> binascii.hexlify('A') == "%X" % long('41', 16)
True

Be aware that

>>> "%X" %n

converts a decimal number into its hex representation.

——

binascii.unhexlify() naturally does the same thing as hexlify(), but in reverse. It takes binary data and displays it in tuples of hex-values.

I’ll start off with an example:

	>>> binascii.unhexlify('41')
	'A'

	>>> binascii.unhexlify("%X" % ord('A'))
	'A'

Here, unhexlify() takes the numerical representation 65L from the ASCII character ‘A’

	>>> ord('A')
	65

converts it into hex 41

	>>> "%X" % ord('A')
	'41'

and represents it as a 1-tuple (meaning dimension of one) of hex values.

And now the conclusio – why might all of this be useful?
Right now, I can think of at least four use cases:

• cryptography
• data-transformation (i.e. Base64 for MIME/E-Mail attachements)
• security (deciphering binary readings off a network, pattern matching, …)
• textual representation of escape sequences

Taking up the last example, I’ll show you how to visualize the Bell esape sequence (you know, that thing that keeps beeping in your terminal).
Taken from the ASCII table, the numerical representation of the Bell is 7. Programmers might know it better as a.

	>>> '7' == 'a'
	True

Presuming you read such a character in some kind of binary data – for example from a socket

	>>> foo = '7'

and you want to visualize this data

	>>> print foo

you will not get any results – at least none visible. You might hear the Bell sound if you’re not on a silent terminal.

Now, finally – binascii to the rescue:

	>>> binascii.hexlify('7')
	'07'

Voilà, the dubious string is decrypted.

Lotus Notes has a nifty feature to lull managers into false safety: for volatile/unsafe e-mails (or users), it let’s you disable printing/forwarding and copying to clipboard. This can be done using rules, on the SMTP server and on a per e-mail basis. When writing somebody you really don’t trust with some information (but in his inability to spread the word otherwise – by copy/pasting for example), writing a mail would look like this:

Now, if your victim wants to forward your mail, Lotus Notes would respond with a little pop-up:

This certainly looks like a magical and proprietary feature, doesn’t it?  Let’s look at the source of such a “mail”(aka memo in Notus’ language) – you will have to forward it to another mail-client though, because memos can’t be displayed in source:

...
Subject: Testnachricht
MIME-Version: 1.0
Sensitivity: Private
X-Mailer: Lotus Notes Release 6.5.5  CCH1 March 07, 2006
...

As you can see, there is a proprietary meta-flag Sensitivity: Private. It can be reproduced with any decent mail user agent or programmatically. What follows is a little Python code snippet that just does the trick:

import smtplib
from email.message import Message
msg = Message()
msg.set_payload("Testmessage Body")
msg["Subject"] = "Testmessage from Python"
msg["From"] = "preek@dispatched.ch"
msg["To"] = "somebody@somewhere.com"
msg["Sensitivity"] = "Private"
smtp = smtplib.SMTP("localhost")
smtp.sendmail("preek@dispatched.ch", "somebody@somewhere.com", msg.as_string())

But please, don’t use this information unless you absolutely have to. Lotus Notes.. *brr*.

Enjoy(;

If you liked this article, please feel free to re-tweet it and let others know.