PasswordSpy - Retrieving lost passwords using Windows hooks



Click here for larger image

Environment: VC5, VC6

Introduction

It was several years ago when I downloaded some sample code posted here on CodeGuru, a program called Eureka that was designed to "retrieve" forgotten passwords in Windows. It was not a password cracker; instead, it used a security hole in Windows to copy the password from another running program. I was intrigued by the program, so I decided to write my own version. Later, once Windows 2000 was released, I was disappointed to see that Microsoft had fixed the "bug" and so programs like these didn't work on Windows 2000 (and nowadays Windows XP). But after several failed attempts, I finally found a way to copy the password while running on any 32-bit Windows OS.

Use

PasswordSpy is a very simple program to use. You simply start the program that contains the forgotten password as well as PasswordSpy. Then, drag the magnifying glass from PasswordSpy over the "****" field and PasswordSpy will display the password. It should be noted that PasswordSpy is not intended for mischievous purposes. PasswordSpy has been tested on Win95/98/ME and WinNT/2K/XP.

Features

In addition to being a useful application, PasswordSpy demonstrates some useful and interesting code.

  • A single instance application. If the user starts a second copy of PasswordSpy, the first copy is brought to the foreground instead of starting a second copy.
  • "Always on top." With a single line of code, you can set or remove the "always on top" state from your application.
  • Inter Process Communication. PasswordSpy uses several forms of IPC, including the WM_COPYDATA message as well as memory-mapped files.
  • Setting windows hooks. To extract the password on Windows2000 and WindowsXP, you must set a hook into the remote process.

Code Details

By far, the most interesting aspect of PasswordSpy is the technique of setting a Windows hook with the SetWindowsHookEx API. With this function, you can install a hook into either the whole system or a specific process. There are a dozen different types of hooks to install; each type monitors for a specific set of events. When one of those events happens, your hook code gets called. PasswordSpy uses the WH_GETMESSAGE hook, which monitors for calls to GetMessage and PeekMessage. For more background info on hooks, please read the MSDN on SetWindowsHookEx.

I have found several examples of hooks on the Internet, in books, in the MSDN, and right here on CodeGuru. But, every example I saw had at least one bug in the code. Here, I'll address the problem as well as my solution.

The hardest part about using Windows hooks is properly storing the handle to the hook. Before you can set a hook, you need two things: 1) A DLL containing the hook function and 2) the ID of the thread you want to hook. Now, supposing Process A sets a hook into Process B. After hooking Process B, the hook handle is returned to Process A and the DLL is mapped into Process B's address space. When one of the hooked events in Process B happens, your hook code gets called from Process B. (It should be noted that your hook code gets called from the remote process! In your hook code, if you call GetCurrentProcessId, you get the PID of the hooked process, not your original program that set the hook.) From the hook code, you can do whatever you want, but before your hook code exits, you are supposed to call CallNextHookEx. If you fail to call this function, any other hooks that might be installed will fail to get the message. The problem is that CallNextHookEx requires the handle to the hook, but that handle was returned to Process A and we're currently in Process B. Thus, some sort of Inter Process Communication is needed to transfer the hook handle.

Most hook samples solve this problem by creating a "shared" section in the DLL.

#pragma data_seg("Shared")
HHOOK g_hHook = NULL;
#pragma data_seg()
#pragma comment(linker, "/section:Shared,rws")

In a nutshell, this creates a single variable that is shared by all loaded instances of that DLL. So, if five processes load this DLL, all five have access to that variable. But, there are a few problems with this method. For starters, some compilers may not support this option. Second, what if Microsoft decides to change how "shared" sections work in future versions of Windows? That would mean this technique would no longer work. Also, this method has no thread synchronization, and because you have multiple threads accessing this variable, thread synchronization is important.

To solve these problems, I used memory mapped files for the IPC, and a mutex for thread synchronization. I encapsulated all this code into a class I called CIPC. By using memory mapped files, I solve the problem of special compiler options because none are needed; it's done using nothing but Win32 API calls. Plus, MMFs are a supported way of sharing data between multiple processes, so Microsoft is not likely to change that in future versions of Windows. And, the mutex ensures that thread access is synchronized.

//***********************************************
// IPC.h
//***********************************************
#ifndef _IPC_H_
#define _IPC_H_

#define IPC_SHARED_MMF  _T("{34F673E0-878F-11D5-B98A-00B0D07B8C7C}")
#define IPC_MUTEX       _T("{34F673E1-878F-11D5-B98A-00B0D07B8C7C}")

// Class for Inter Process Communication using Memory Mapped Files
class CIPC
{
public:
  CIPC();
  virtual ~CIPC();

  bool CreateIPCMMF(void);
  bool OpenIPCMMF(void);
  void CloseIPCMMF(void);

  bool IsOpen(void) const {return (m_hFileMap != NULL);}

  bool ReadIPCMMF(LPBYTE pBuf, DWORD &dwBufSize);
  bool WriteIPCMMF(const LPBYTE pBuf,
                   const DWORD dwBufSize);

  bool Lock(void);
  void Unlock(void);

protected:
  HANDLE m_hFileMap;
  HANDLE m_hMutex;
};

#endif


//***********************************************
// IPC.cpp
//***********************************************
#include "IPC.h"

//***********************************************
CIPC::CIPC() : m_hFileMap(NULL), m_hMutex(NULL)
{
}

//***********************************************
CIPC::~CIPC()
{
    CloseIPCMMF();
    Unlock();
}

//***********************************************
bool CIPC::CreateIPCMMF(void)
{
  bool bCreated = false;

  try
  {
     if(m_hFileMap != NULL)
        return false;    // Already created

     // Create an in-memory 4KB memory mapped
     // file to share data
     m_hFileMap = CreateFileMapping((HANDLE)0xFFFFFFFF,
         NULL,
         PAGE_READWRITE,
         0,
         4096,
         IPC_SHARED_MMF);
     if(m_hFileMap != NULL)
        bCreated = true;
  }
  catch(...) {}

  return bCreated;
}

//***********************************************
bool CIPC::OpenIPCMMF(void)
{
    bool bOpened = false;

    try
    {
        if(m_hFileMap != NULL)
            return true;    // Already opened

        m_hFileMap =
          OpenFileMapping(FILE_MAP_READ | FILE_MAP_WRITE,
            FALSE,
            IPC_SHARED_MMF);
        if(m_hFileMap != NULL)
            bOpened = true;
    }
    catch(...) {}

    return bOpened;
}

//***********************************************
void CIPC::CloseIPCMMF(void)
{
    try
    {
        if(m_hFileMap != NULL)
            CloseHandle(m_hFileMap), m_hFileMap = NULL;
    }
    catch(...) {}
}

//***********************************************
bool CIPC::ReadIPCMMF(LPBYTE pBuf, DWORD &dwBufSize)
{
  _ASSERTE(pBuf);

  bool bSuccess = true;

  try
  {
     if(m_hFileMap == NULL)
         return false;

     DWORD dwBaseMMF = (DWORD)MapViewOfFile(m_hFileMap,
                FILE_MAP_READ | FILE_MAP_WRITE,
         0, 0, 0);
     _ASSERTE(dwBaseMMF);

     // The first DWORD in the MMF contains the size of the data
     DWORD dwSizeofInBuf = dwBufSize;
     CopyMemory(&dwBufSize, (LPVOID)dwBaseMMF, sizeof(DWORD));

     if(dwSizeofInBuf != 0)
     {
         if(dwBufSize > dwSizeofInBuf)
             bSuccess = false;
         else
              CopyMemory(pBuf,
                  (LPVOID)(dwBaseMMF + sizeof(DWORD)),
                  dwBufSize);
     }

     UnmapViewOfFile((LPVOID)dwBaseMMF);
  }
  catch(...) {}

  return bSuccess;
}

//***********************************************
bool CIPC::WriteIPCMMF(const LPBYTE pBuf, const DWORD dwBufSize)
{
    _ASSERTE(pBuf);

    bool bSuccess = true;

    try
    {
        if(m_hFileMap == NULL)
            return false;

        DWORD dwBaseMMF = (DWORD)MapViewOfFile(m_hFileMap,
            FILE_MAP_READ | FILE_MAP_WRITE,
            0, 0, 0);
        _ASSERTE(dwBaseMMF);

        // The first DWORD in the MMF contains the size of the data
        CopyMemory((LPVOID)dwBaseMMF, &dwBufSize, sizeof(DWORD));
        CopyMemory((LPVOID)(dwBaseMMF + sizeof(DWORD)),
                            pBuf, 
                            dwBufSize);

        UnmapViewOfFile((LPVOID)dwBaseMMF);
    }
    catch(...) {}

    return bSuccess;
}

//***********************************************
bool CIPC::Lock(void)
{
    bool bLocked = false;

    try
    {
        // First get the handle to the mutex
        m_hMutex = CreateMutex(NULL, FALSE, IPC_MUTEX);
        if(m_hMutex != NULL)
        {
            // Wait to get the lock on the mutex
            if(WaitForSingleObject(m_hMutex, INFINITE) ==
                                   WAIT_OBJECT_0)
                bLocked = true;
        }
    }
    catch(...) {}

    return bLocked;
}

//***********************************************
void CIPC::Unlock(void)
{
    try
    {
        if(m_hMutex != NULL)
        {
            ReleaseMutex(m_hMutex);
            CloseHandle(m_hMutex);
            m_hMutex = NULL;
        }
    }
    catch(...) {}
}

Countering PasswordSpy

Now that you know how to programmatically "copy" the password from another application, the next logical question is: "How do you prevent PasswordSpy from copying passwords from applications you write?" If your application stores and displays passwords, and especially if you are concerned about security, you probably want to protect your application from programs such as PasswordSpy.

Because PasswordSpy can copy passwords out of other programs, the solution to protecting your own programs is to never display the real password in the first place. The best solution is to display a bogus password in the password control. That way, if someone uses PasswordSpy to retrieve the password, all they get back is a bogus password, not the real thing. Included in the download is a program called AntiPwdSpy. This program shows how to protect your password controls from being "spied." The AntiPwdSpy program behaves exactly the same as the Windows NT Services dialog and the Windows NT User Manager.

There are other ways to counter programs such as PasswordSpy. One way is to intercept the WM_GETTEXT message. This works, but using the bogus password method has other benefits. By replacing the real password with a bogus one, it is not possible to determine the length of a password by looking at the password control. If a program displays the text "***" in a password control, right away you know that password is only three characters in length. This greatly compromises the security of that password by revealing the password's length. But, if that password control displayed "**************", as is done in most Microsoft programs, you do not know anything about the password.

References

I must give credit where credit is due. The following two projects found here on CodeGuru helped me write this program.

Downloads

Download demo project - 25 Kb
Download source - 27 Kb


Comments

  • nicely done! (64bit issues)

    Posted by mateuscb on 05/07/2009 02:12pm

    Nicely done on the project. As for all the comments about the validity of this project;
    this is a great exercise on windows hook, IPC, and memory maps. 
    I was playing around on my 64bit OS, and found a couple small glitches. 
    Here is what I did to fix it, if anyone is interested:
    
    ----- change CreateFileMapping to use predefined (ln 33)----
    m_hFileMap = CreateFileMapping(INVALID_HANDLE_VALUE,
    
    ----- change pointer math in ReadIPCMMF
    bool CIPC::ReadIPCMMF(LPBYTE pBuf, DWORD &dwBufSize)
    {
    	_ASSERTE(pBuf);
    
    	bool bSuccess = true;
    
    	try
    	{
    		if(m_hFileMap == NULL)
    			return false;
    
    		DWORD* pdwBaseMMF = (DWORD*)MapViewOfFile(m_hFileMap, FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0);
    		_ASSERTE(pdwBaseMMF);
    
    		// The first DWORD in the MMF contains the size of the data
    		DWORD dwSizeofInBuf = dwBufSize;
    		dwBufSize = *pdwBaseMMF;
    
    		if(dwSizeofInBuf != 0)
    		{
    			if(dwBufSize > dwSizeofInBuf)
    				bSuccess = false;
    			else
    				CopyMemory(pBuf, pdwBaseMMF + 1, dwBufSize);
    		}
    
    		UnmapViewOfFile((LPVOID)pdwBaseMMF);
    	}
    	catch(...) {}
    
    	return bSuccess;
    }
    
    ----- change pointer math in WriteIPCMMF
    bool CIPC::WriteIPCMMF(const LPBYTE pBuf, const DWORD dwBufSize)
    {
    	_ASSERTE(pBuf);
    
    	bool bSuccess = true;
    
    	try
    	{
    		if(m_hFileMap == NULL)
    			return false;
    
    		DWORD* pdwBaseMMF = (DWORD*)MapViewOfFile(m_hFileMap, FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0);
    		_ASSERTE(pdwBaseMMF);
    
    		// The first DWORD in the MMF contains the size of the data
    		*pdwBaseMMF = dwBufSize;
    		CopyMemory(pdwBaseMMF + 1, pBuf, dwBufSize);
    
    		UnmapViewOfFile((LPVOID)pdwBaseMMF);
    	}
    	catch(...) {}
    
    	return bSuccess;
    }

    Reply
  • Read This Small Poem For Windows Family.

    Posted by King on 03/11/2004 08:20am

    I Came.
    I Saw.
    I Read.
    now...
    XP is Dead.
    
    Great Going Sir.

    Reply
  • What is the real purpose of these kinds of programs?

    Posted by Legacy on 02/04/2004 12:00am

    Originally posted by: John T Edwards

    "It should be noted that PasswordSpy is not intended for mischievous purposes."

    Can you explain to me some other valid purpose for this?

    Reply
  • PwdSpy, NAV, and Power Spider

    Posted by Legacy on 01/30/2004 12:00am

    Originally posted by: Brian Friesen

    Several people have brought it to my attention that Norton AntiVirus reports that PwdSpyHk.dll is the "Power Spider" virus. This is a false positive, PasswordSpy is not a virus! What has apparently happened is some developer out there with malicious intentions has used my article and my source code to write a virus, which has since been dubbed "Power Spider." But because this virus was written using my source code to do part of its evil work, NAV confuses PasswordSpy with this virus. I have contacted Norton about this issue, but it is clear Norton does not care one iota about resolving this, nor are they willing to admit their scanner is producing a false positive. Interestingly enough, other virus scanners (such as McAfee) which also scan for Power Spider do not confuse it with PasswordSpy. Only NAV has this problem, which only confirms my feelings that NAV is a ****py product.

    Anyway, I have just updated the source code and downloads for PasswordSpy. NAV will not confuse this new version with Power Spider. However all previous downloads will have this problem.

    If you don't believe me that PasswordSpy is not a virus, then you don't have to download or use it. But as a developer you can read through all the source code and compile it for yourself, so you should be able to see PasswordSpy is indeed NOT A VIRUS.

    Oh, if the developer who wrote Power Spider is reading this post, I have one thing to say to you. You SUCK!

    Brian

    Reply
  • VIRUS

    Posted by Legacy on 01/09/2004 12:00am

    Originally posted by: Angry

    for a litle, i woud catch two virusis downloading your spy password so please put you]r program on hack sites to fake same beginners
    by,by beginners

    Reply
  • grateful acknowlegent

    Posted by Legacy on 11/13/2003 12:00am

    Originally posted by: D. Richter

    When I began proramming I was told to visualize windows sockets as if the Unix input/output redirection of porting code was a fair similarity, or baseline. The streaming of source through the compiler should occur as the directives lead them and the libraries pre-defined the system calls. I salute your coding prowess. Passing a command line to the main() as opposed to invoking one almost forced a retalation of an applet that would stream as data upon loading a browser, define itself as a provider of data objects, and verify that expanded cab files having digital signatures of a recognizable flow in IE. This code of yours combined with a working ability to use TCP/IP should be formidable against an applet that serves to emulate a terminal, or display type, yet get straight to an IP and evade the dns resolution and proxy detection. When script embedded in tags loads and the data is consumed to output graphics that alter baud, font, key stroke appearance at will, while noting a text buffer, your code is good at what is meant to do. If IE is an interface shell shell program with maybe a different tree structure or search query than browsers that offer a different channel selection (with server connection), decompiling script to get to the difficult remains standard while every transaction on IE is cached, much more than URL history, cookies, and temp files. Build ups, unrequested information, etc. While this caching is meant to balance abstract and the concrete, it may be missing character counting and data window possibilites, as it also(probably in an effort to speed up patching), allow downloading so they can install these updates, maybe noting system and device files noted during initiation to see if who is who. sequential security get easily predicted tospike a dll and force the excess to overflow into the system. That's why I try to learn. When he data structures are perfect tolet the program run, the algorithms used provide options for strings or what bits are so frequent they encode easily.
    
    The data boxes are easy calcuations. Which ones steal the bandwidth or which ones are field for input are options in your open source. Have a good one.

    Reply
  • SP2

    Posted by Legacy on 09/15/2003 12:00am

    Originally posted by: forgie

    with SP2 installed on win XP it looks Microsoft has fixed bug.
    It does not function any more. I can see just stairs : *****

    forgie

    Reply
  • I wanted to do this thing.

    Posted by Legacy on 08/10/2003 12:00am

    Originally posted by: Karunakar

    hello sir,
    
    Actually every time when i used to logon to my system I thought of hacking that password.U have made life easy for me.thank u .


    Reply
  • great_work

    Posted by Legacy on 02/22/2003 12:00am

    Originally posted by: Kaustuv Basu

    this is a great application software for the administrators of the machines. we system administrators need some of these to keep track of the authorised person.
    

    Reply
  • Thank you for the base work

    Posted by Legacy on 01/02/2003 12:00am

    Originally posted by: ZHEFU ZHANG

    Hi, Brian:
    I am the author of http://www.codeguru.com/ieprogram/SPwdSpy.html
    Thank you very much for the base work of Password Peeker. I used your resource file directly for I like the style of it.
    And also one word, the Arnold head is really cool, I love it. In this July 3, we can see <<Terminator 3>>.
    Nice work of yours!

    Reply
  • Loading, Please Wait ...

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Protecting business operations means shifting the priorities around availability from disaster recovery to business continuity. Enterprises are shifting their focus from recovery from a disaster to preventing the disaster in the first place. With this change in mindset, disaster recovery is no longer the first line of defense; the organizations with a smarter business continuity practice are less impacted when disasters strike. This SmartSelect will provide insight to help guide your enterprise toward better …

  • Live Event Date: August 20, 2014 @ 1:00 p.m. ET / 10:00 a.m. PT When you look at natural user interfaces as a developer, it isn't just fun and games. There are some very serious, real-world usage models of how things can help make the world a better place – things like Intel® RealSense™ technology. Check out this upcoming eSeminar and join the panel of experts, both from inside and outside of Intel, as they discuss how natural user interfaces will likely be getting adopted in a wide variety …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds