Cumps.be

GPG in Outlook 2007 – OutlookGnuPG

Gepost op 2009.04.15 | Reacties (39) | C#, Office, OutlookGnuPG, Security, Technologie

A long time ago, I used PGP for signing my email, but I stopped using it. Probably because I didn’t quite get the concept yet, but that has changed now.

Today I switched to GPG for signing my mail and files, with all the required files running from my memory stick.

One thing bothered me however, no Outlook 2007 support at all. There are some plugins around for older Outlook versions, but that didn’t quite work out.

So I decided to develop my own! And after a few weeks of development and testing, it’s done and ready to be set free upon the world.

Let’s have a look at the functionality and how to set it up and use it.

Prerequisites

First of all, a working copy of GPG is required, so visit the GnuPG download page, scroll down and download the command line Windows version.

Install this somewhere on your machine and remember the path where you installed it.

If everything has gone correctly, you can now open a command prompt and type gpg –version and gpg –list-keys to see the version and your keys (which would be empty if you’re using it for the first time).

Visit the Getting Started section of the GnuPG handbook to generate your own key if this is your first encounter.

OutlookGnuPG

There are two main areas in the plugin, functionality for sending a mail (sign/encrypt) and for retrieving a mail (verify/decrypt).

At the moment only plain text emails are supported. No HTML mail or attachments, that’s for a future version

To install the addin, start by adding www.cumps.be to your Trusted Sites (you can do this in Internet Explorer – Tools – Internet Options – Security – Trusted Sites – Sites).

Download the OutlookGnuPG ClickOnce installer and execute it.

This will give you a prompt asking you if everything is fine. Go ahead and install it. You might have to close Outlook before installing.

When the addin is installed, you can open Outlook and a Settings dialog will show up. Click Browse… and select the directory where your the gpg.exe you previously installed is located.

On the second tab you can select the default key you want to use to sign your mails. You will still have a choice to change your key upon sending the actual mail.

Click Ok when done. At this point you can use your Outlook as before, since we haven’t checked any auto-sign/encrypt functionality.

Sending Mail

When you compose a new mail, you will notice the Message ribbon has a new group on it, called OutlookGnuPG, with a Sign and Encrypt toggle button.

Sending out a signed mail is as simply as turning on the Sign button, typing your mail and pressing Send. It will prompt you to select the private key you want to use to sign the mail, and your passphrase.

Creating an encrypted mail follows the same logic, toggle the Encrypt button and send your mail. You will have to select the intended recipients (multiple are possible) and it will encrypt the mail so only these people will be able to decrypt it.

To be absolutely safe, you can toggle both Sign and Encrypt button to send out an encrypted signed message.

Retrieving Mail

Reading mail can be done in two ways in Outlook, either by opening the mail item, or by using the preview pane. It only makes sense there are two ways to verify/decrypt a mail as well then.

The first is very identical to the send functionality. When you open an existing mail, you will notice a new ribbon group, OutlookGnuPG, with a Verify and Decrypt button.

Simply click Verify to check if a signed mail is valid or not. A messagebox will inform you of the status.

Likewise, click Decrypt to decrypt an encrypted email. This will ask you for your private key to decrypt the message with. The message will be decrypted, and the decrypted content will be placed in the message. If the message was also signed, a messagebox will inform you of the status.

The second way is through the preview window. A new commandbar will have appeared on the preview window, with a Verify and Decrypt button, which work exactly the same as the previous buttons.

Credits

OutlookGnuPG is free, only supported by a donate button, so it’s only fair to give the used resources some credits.

Silk Icon Set by Mark James
OpenPGP wrapper by Starksoft
Clipboard Wrapper by Alessio Deiana

Feedback

Got questions? Remarks? Feel free to leave a comment

Update:
Since I won’t have the time to maintain this, I’m releasing the source: cc.outlookgnupg-1.0.8.0.zip

Update 2:
Philippe Teuwen and Thierry Walrant have taken it upon themselves to improve the code I posted above and made it available on github, using GPLv3 as a license. Check it out at: github.com/twalrant/OutlookGnuPG

Obfuscation – Making Reverse Engineering Harder

Gepost op 2007.09.29 | Reacties (5) | C#, Security, Technologie

In a previous article I have demonstrated how easy it is to decompile and reverse engineer .NET assemblies using Reflector and Reflexil. I've also shown that applying a strong name to your assembly does not protect your code from reverse engineering. So, what else is left?

A technique called obfuscating goes a long way in keeping your source code safe. An obfuscator will mangle your code, without changing the actual result, to make it increasingly harder for someone to decompile your code and actually understand it.

Keep in mind however that this is 'security through obscurity', and as such it does not provide solid security, it's just another layer. The more layers, the more walls there are around your assembly to demotivate others into breaking it, but never enough to demotivate 100% of the people. A similar tactic can be found in CD protection schemes, which stops a percentage of users from copying a disk, but not everyone.

There are several possibilities to obfuscate an assembly:

• Renaming

  Classes, methods, parameters, namespaces, fields, ... are renamed to short names, making it much harder to deduct the working of a program from descriptive naming. Unicode characters can be used, making it even harder to understand.

  When there is a lot of code, an obfuscator can also rename different methods to the same name, due to taking advantage of overloading.

  For example, if you have a method GetCustomers without any parameters and GetCustomer(int customerNr), an obfuscator can rename them both to 'a', letting the .NET framework pick the correct one thanks to using overloads.

• Control Flow Alternation

  An obfuscator can turn nicely structured code using if, while, for statements into a big spaghetti mess, by utilizing lots of goto statements. The more code you have, the more difficult it will be to understand the generated spaghetti end result.

• String Encryption

  When code has been turned in to a complex obfuscated mess, it is still possible to find interesting parts due to the readability of strings used, limiting the attack vector to a smaller piece of obfuscated to be understood.

  Obfuscators provide the ability to encrypt strings and decrypt them at run time, making them unreadable in the source code.

• Assembly Linking

  Calls made to .NET Framework methods will still be readable, because of this some obfuscators allow you to link in the .NET Framework assemblies being used, and obfuscating these as well, making it impossible to find anything 'normal' in the IL.

Besides protection features some obfuscator packages out there also provide nice diagram generators to analyze your assembly.

After applying an obfuscator on my previous CrackMe program, this is how it looks when opened with Reflector:

As you can see, Reflector is already unable to generate valid C# code for it. With some obfuscators it is even possible to make Reflector totally unable to output anything, besides IL. Trying to view in C# for example, made Reflector throw an exception.

Testing this on my SuperSecretApplication application, the obfuscator applied several methods on the IL of the assembly:

• Method renaming, using Unicode characters which couldn't get displayed.
• Parameter renaming, using a simply naming scheme.
• Altered control flow, using several jump conditions, as displayed by the arrows in Reflexil.
• String encryption, making it harder to find interesting sections.

As you can see, given enough time, it is possible to figure out the above code and still break it. The more code you have however, the harder it becomes due to the increasing complexity of the obfuscated code, added with the fact that obfuscators will be able to apply even more advanced methods.

Obfuscators also have some disadvantages though. When writing advanced code involving reflection, obfuscating an assembly might break your code, possibly due to class and namespaces being renamed. Debugging also becomes harder because the stacktrace will contain renamed method signatures.

A good obfuscator will offer features to work around these advantages though, by allowing you to mark sections which should be skipped for obfuscation and also providing tools to translate an obfuscated stack trace to the original methods, using a mapping file.

You can find a comparison between several obfuscators on How To Select Guides, including links to individual websites and details about which features they support.

This post is the third in a series on protecting intellectual property.

• Reverse Engineering with Reflector and Reflexil.
• Code Signing as Reverse Engineering Protection.
• Obfuscation - Making Reverse Engineering Harder (this post).

Code Signing as Reverse Engineering Protection

Gepost op 2007.09.15 | Reacties (6) | C#, Security, Technologie

In my last post I spoke about reverse engineering .NET assemblies upon which Gregory asked how to protect his code against it.

Initially I thought signing an assembly would be the easiest way to prevent this, and my first tests confirmed this. I signed the CrackMe from my previous post and tried modifying it again, unsuccessfully.

After changing the code and saving it, Reflexil gave me several options. Adding it to the verification list, resigning it, or leaving it as is.

None of the options proved to be usable for the following reason:

• Adding it to the verification list.
  This won't work with fully signed assemblies. Shawn Farkas explained long ago why this doesn't work. The solution proposed doesn't work if we don't have the original key used to sign the file.
   
• Resigning it.
  Logically this doesn't work, since we don't have the original key.
   
• Leaving it as is.
  When trying to run the modified assembly, an exception will be thrown, preventing it from running.

It seems we managed to protect our code, doesn't it? But we didn't!

I started thinking, since we can easily decompile an assembly, it couldn't be that hard to remove the signature and make it pass all checks again. After playing around with ildasm (Found at: Visual Studio - SDK - v2.0 - Bin) and ilasm (Found at: Microsoft.NET - Framework - v2.0.50727) for a while, my suspicions got confirmed. I managed to run the altered, now unsigned, assembly on my computer, defeating code signing.

This process wasn't error proof however, making round trips through ildasm and ilasm didn't always recreate the original assembly correctly. But why make the round trips in the first place? Why not edit the assembly directly, only removing the signature, instead of having to decompile and recompile the entire code.

A Google search quickly led me to the answer. This code project article describes code signing in great detail and provides a very nice utility to remove the strong name from an assembly, while also keeping into account referencing assemblies.

Using the tool on my CrackMe removed the signature without any problem, after which I could simply modify it as if it was an unsigned assembly using the instructions from my previous post.

In conclusion, I'd say code signing offers no protection against others determined to modify your assemblies. It seems to be like copy protections on games, it will stop a certain percentage of people but not everyone. It's another layer in your protection, making it less attractive to others to even bother trying to break your security.

Should you use code signing? Yes, you should, everything helps and applying a strong name also serves other purposes such as solving versioning issues when using the Global Assembly Cache.

In my next post I'll take a look at another mechanism to protect your code from tampering, obfuscation.

This post is the second in a series on protecting intellectual property.

• Reverse Engineering with Reflector and Reflexil.
• Code Signing as Reverse Engineering Protection (this post).
• Obfuscation - Making Reverse Engineering Harder.

Reverse Engineering with Reflector and Reflexil

Gepost op 2007.09.06 | Reacties (13) | C#, Security, Technologie, Tweaks

I've always been a big fan of Reflector, allowing me to have a look in assemblies to learn new things, debug in case of problems and provide useful information when creating bug reports. Combined with the Reflexil Add-in it's now easy to also modify assemblies yourself.

To demonstrate this, I've created a small CrackMe sample program, which consists out of nothing more then a simple password check. This is how it looks when opened in Reflector, with Reflexil displaying the IL code below it.

Ignoring the fact that the password is out there in the open, let's have a look on how we could easily change the behavior of this assembly.

As you can see on the highlighted line in Reflexil, the instruction will jump to line 11 in case the provided password is false. Let's simply change this to jump when true. Right click the line, select 'Edit...' and change the OpCode to brtrue.s to modify the if statement.

I'm sure this brings back memories for people doing this years ago in assembler, JNE to JE 

To save this change, navigate to the .exe node in Reflector and select 'Save as ...' in the Reflexil dialog.

If you open the new executable in Reflector and have a look at the password check, you'll notice the operator has changed, making all passwords valid except the correct one.

I've attached the .zip of this project and the modified file as a small example to demonstrate how powerful good tools are.

This post is the first in a series on protecting intellectual property.

• Reverse Engineering with Reflector and Reflexil (this post).
• Code Signing as Reverse Engineering Protection.
• Obfuscation - Making Reverse Engineering Harder.