Code Injection - Nachtrag 1

In den letzten Tagen und Wochen habe ich weiter an meinen kleinen Tools gebastelt und sie so verändert, dass nur noch eine Anwendung benötigt wird.
Diese Konsolenanwendung beinhaltet auch die Dll selbst, welche mittels LoadLibrary in dem Remote Prozess geladen wird. 

Der Ablauf:

• Konsolenanwendung startet
• PID Eingabe
• Dll wird im tmp Ordner erzugt ( versteckt in einer Text Datei mittels Alternate Data Stream )
• Code Injection wird durchgeführt
• Tmp Datei wird gelöscht
• Programm beendet sich

Getestet habe ich das Programm unter folgenden Betriebssystemen und Virenscannern:

Wer das Programm selber gerne mal testen möchte kann es hier downloaden:

http://wcqtff.willcodejoomlaforfood.de/botoxconsole.7z

Folgende Testpunkte sind interessant:

• Erkennt der Virenscanner Schadcode in der botoxconsole.exe  ?
• Wird die CodeInjection erfolgreich ausgeführt

Ob die Injection geklappt hat oder nicht, merkt man wenn man dem entsprechenden Programm den Focus verleiht
und die F1 Taste drückt. Nun sollten mehr oder weniger Messageboxen erscheinen.

Nach dem Neustart der Anwendung ist wieder alles beim alten.

Heute möchte ich den ersten Teil meiner Research Arbeit über Code Injection vorstellen. Es handelt sich um den Aufbau und die Idee dahinter.
Es gibt zwar schon fertige Lösungen und Frameworks auf diversen Seiten im Internet, aber ich wollte eine Möglichst einfache Klasse schreiben,
mit wenig Overhead und Assembler.

Die Idee:

Mittels der CreateRemoteThread Funktion ist es möglich einen Thread in einem anderen Prozess zu starten, diese Tatsache ansich fand ich schonmal sehr spannend.
Dies ist der übliche Weg wie Debugger arbeiten. Mein Ziel war es also ein kleines Programm zu schreiben welches einen Thread in einem anderen Prozess erstellt und
eine MessageBox mit der Pid darstellt. Ist dies erstmal geschafft, kann man noch mehr tolle Sachen im anderen Prozess veranstalten.

Der Aufbau:

Nach etlichen Versuchen und Ansätzen bin ich zu folgendem Aufbau gelangt. Meine Lösung besteht aus 2 Teilen. 

• Ein Programm welches die Injection druchführt
• Eine DLL die den entsprechenden Code ausführt

Vorteil, man kann die DLL beliebig austauschen und muss nicht sein eigentliches Programm anpassen.

Weiterführende Links:

• http://msdn.microsoft.com/en-us/library/ms682437%28VS.85%29.aspx

Nun im zweiten Teil möchte ich das eigentliche Programm vorstellen. Es handelt sich um eine Konsolenanwendung,
welche eine PID einliest. Danach wird versucht, diesem Prozess den Code zu injizieren. Wichtig dabei ist, das man über
entsprechende Rechte verfügt. Ganz konkret ist das Debug
Recht gemeint ( SE_PRIVILEGE_ENABLED ).

Mittles der Funktionen OpenProcessToken, LookupPrivilegeValue und AdjustTokenPrivileges ist es recht
einfach die Rechte eines Prozesses zu verändern.

Hier ein kleines Code Schnipsel:

OpenProcessToken( GetCurrentProcess(), 
   		             TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, 
			     &hAppToken ) 
LookupPrivilegeValue( NULL, 
                                SE_DEBUG_NAME, 
                                 &debugLuid ) 

AdjustTokenPrivileges( hAppToken,
                                  FALSE,
                                  &tokenPrivileges,
                                  sizeof( tokenPrivileges ),
                                  NULL,
                                  NULL )

Nun wird mittels der Funktion VirtualAllocEx Arbeitsspeicher im entsprechenden Prozess allokiert. Danach müssen noch die
eigentlichen Daten in diesen Speicher geschrieben werden, dies übernimmt WriteProcessMemory.
War auch das schreiben erfolgreich, wird nun die eigentliche Funktion zum erstellen eines Threads aufgerfuen.
Die CreateRemoteThread Funktion, bei Erfolg erhält man ein HANDLE auf den Thread im anderen Prozess.

Nun schauen wir uns die 3 Schritte im Detail an:

VirtualAllocEx:

 const std::string dll = "botox.dll"; 

VirtualAllocEx( hRemoteProcessHandle, 
                     NULL, 
                     dll.length(),
                     MEM_RESERVE|MEM_COMMIT, 
                     PAGE_EXECUTE_READWRITE ) 

Wir übergeben das Prozess HANDLE, die Länge des DLL Names ( Anzahl der zu reservierenden Bytes , danach noch die entsprechenden
Flags das der Speicher auch ausführbaren Code enthält.
Wir erhalten einen void Pointer als Antwort.

WriteProcessMemory:

Nach dem erfolgreichen reservieren von Arbeitsspeicher müssen wir nun noch die Daten in diesen schreiben. In diesem Fall der Name der Dll,
welche vom Prozess geladen werden soll.

 WriteProcessMemory( hRemoteProcessHandle, 
                                reinterpret_cast<LPVOID>( pRemoteMemory ), 
                                dll.c_str(),
                                dll.length(), 
                                NULL )  

Wieder wird das Prozess HANDLE übergeben, sowie den Pointer der auf den zuvor allokierten Arbeitsspeicher zeigt. Danach die eigentlichen
Daten, mit Längeangabe.

CreateRemoteThread:

Nun die eigentliche Erstellung mittels CreateRemoteThread:

reinterpret_cast<LPVOID>( GetProcAddress( GetModuleHandle( L"kernel32.dll" ), "LoadLibraryA" ) ); 

CreateRemoteThread( hRemoteProcessHandle, 
                                NULL, 
                                NULL, 
                                reinterpret_cast<LPTHREAD_START_ROUTINE>(pLoadLibrary), 
                                reinterpret_cast<LPVOID>(pRemoteMemory), 
                                NULL, 
                                NULL ); 

Auch hier zuerst das Prozess HANDLE, danach einen Pointer auf eine ThreadProc in diesem Fall die LoadLibrary Funktion der kernel32.dll.
Danach den Arbeitsspeicher, fertig. Zurück bekommt man ein HANDLE auf den Thread.

Bei meinen Recherchen, hatten viele Leute Probleme mit dieser Lösung unter Windows Vista. Dies kann ich aber nicht bestätigen,
mein Programm wurde unter
Windows Vista 64 bit entwickelt und getestet. Bei allen Versuchen war die Adresse von LoadLibraryA in der kernel32.dll konstant gleich.

Weiterführende Links:

• http://msdn.microsoft.com/en-us/library/aa366890%28VS.85%29.aspx
• http://msdn.microsoft.com/en-us/library/ms681674%28VS.85%29.aspx
• http://msdn.microsoft.com/en-us/library/ms682437%28VS.85%29.aspx

Den dritten un letzten Teil widme ich der DLL, welche den auszuführenden Code beinhaltet. Dieser Teil ist recht einfach zu
implementieren. Im Grunde wird bei LoadLibrary einfach ein weiteren Thread gestartet, welcher dann die Arbeit übernimmt.

Der Einstiegspunkt - LoadLibrary:

Wird die Dll von einem Prozess geladen wird einfach ein weiteren Thread gestartet.

BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID /* lpvReserved */)
{
   if (dwReason == DLL_PROCESS_ATTACH )
   {
        DoAction();
   }

   return TRUE;
}

Die DoAction Funktion erzeugt einen neuen Thread, welcher über alle Fenster mittels EnumWindows iteriert.

 void DoAction()
{
    CreateThread( NULL,
                  0,
                  ThreadProc,
                  0,
                  0,
                  0);    
}
DWORD WINAPI ThreadProc(  LPVOID lpParameter )
{

   EnumWindows( EnumWindowsProc, 0 );
  
   while( 1 )
   {
       Sleep( 100 );
   }

    return 0;
} 
BOOL CALLBACK EnumWindowsProc( HWND hwnd, LPARAM lParam ) 
{
    const DWORD currentID = GetCurrentProcessId();
    DWORD procid = 0;
    GetWindowThreadProcessId (hwnd, &procid);

    if( currentID == procid )
    {
        SetWindowsHookEx( WH_KEYBOARD, KeyboardProc, NULL,  );
    }
    return TRUE;
}
LRESULT CALLBACK KeyboardProc( int nCode, WPARAM wParam, LPARAM lParam )
{
   // implementation

}

Weiterführende Links:

• http://msdn.microsoft.com/en-us/library/ms684175%28VS.85%29.aspx 
• http://msdn.microsoft.com/en-us/library/ms633497%28VS.85%29.aspx
• http://msdn.microsoft.com/en-us/library/ms644990%28VS.85%29.aspx

Hier möchte ich nun ein selbstgeschriebenes Tool names who vorstellen. Der Name orientiert sich an dem gleichnamigen Linux Tool.

Who ist eine kleine Konsolenanwendung, welche alle Windows Sessions auflistet und im Sekundentakt aktualisiert. Benutzt wird dabei folgende WTS* API:

• WTSQuerySessionInformation
• WTSEnumerateSessions
• WTSGetActiveConsoleSessionId
• WTSFreeMemory

Zu finden ist es in folgendem Repository: svn://willcodejoomlaforfood.de/tools/trunk/windows/who

Hier möchte ich kurz eine Lösung vorstellen, für alle die Probleme mit dem Kompilieren der Windows Socket API ( winsock2.h ) haben.

Das Problem ergibt sich durch macro redifintions:

1>\windows\v6.1\include\ws2def.h(91) : warning C4005: 'AF_IPX': Makro-Neudefinition
\windows\v6.1\include\winsock.h(460): Siehe vorherige Definition von 'AF_IPX'
\windows\v6.1\include\ws2def.h(127) : warning C4005: 'AF_MAX': Makro-Neudefinition
\windows\v6.1\include\winsock.h(479): Siehe vorherige Definition von 'AF_MAX'
\windows\v6.1\include\winsock.h(402): Siehe vorherige Definition von 'SO_DONTLINGER'
\windows\v6.1\include\ws2def.h(207) : error C2011: 'sockaddr': 'struct' Typneudefinition
\windows\v6.1\include\winsock.h(485): Siehe Deklaration von 'sockaddr'
\windows\v6.1\include\ws2def.h(385) : error C2143: Syntaxfehler: Es fehlt '}' vor 'Konstante'
\windows\v6.1\include\ws2def.h(385) : error C2143: Syntaxfehler: Es fehlt ';' vor 'Konstante'
\windows\v6.1\include\ws2def.h(385) : error C2059: Syntaxfehler: 'Konstante'
\windows\v6.1\include\ws2def.h(438) : error C2143: Syntaxfehler: Es fehlt ';' vor '}'
\windows\v6.1\include\ws2def.h(519) : warning C4005: 'IN_CLASSA': Makro-Neudefinition
\windows\v6.1\include\winsock.h(287): Siehe vorherige Definition von 'IN_CLASSA'
\windows\v6.1\include\ws2def.h(525) : warning C4005: 'IN_CLASSB': Makro-Neudefinition
\windows\v6.1\include\winsock.h(293): Siehe vorherige Definition von 'IN_CLASSB'
\windows\v6.1\include\ws2def.h(531) : warning C4005: 'IN_CLASSC': Makro-Neudefinition
\windows\v6.1\include\winsock.h(299): Siehe vorherige Definition von 'IN_CLASSC'
\windows\v6.1\include\ws2def.h(542) : warning C4005: 'INADDR_ANY': Makro-Neudefinition
\windows\v6.1\include\winsock.h(304): Siehe vorherige Definition von 'INADDR_ANY'
\windows\v6.1\include\ws2def.h(578) : error C2011: 'sockaddr_in': 'struct' Typneudefinition
\windows\v6.1\include\winsock.h(312): Siehe Deklaration von 'sockaddr_in'
\windows\v6.1\include\winsock2.h(132) : error C2011: 'fd_set': 'struct' Typneudefinition
\windows\v6.1\include\winsock.h(68): Siehe Deklaration von 'fd_set'
\windows\v6.1\include\winsock2.h(167) : warning C4005: 'FD_SET': Makro-Neudefinition

Das Problem ist die Include Reihenfolge der Windows Header Dateien. Eigentlich ist man gewöhnt zuerst die <windows.h> zu includieren, danach alles andere.
Leider ist die winsock2.h eine Ausnahme, diese muss vor der windows.h includier werden.

Weiterführende Links:

• http://msdn.microsoft.com/en-us/library/ms742213%28VS.85%29.aspx

Manchmal möchte man für Debug Ausgaben bzw Logging gerne die GUID Struktur in einen lesbaren String konvertieren. Auf der Suche nach einer Lösung kamen wir Windows API Funktionen
wie StringFromCLSID oder StringFromGUID2 entgegen, welche eigentlich den Zweck erfüllen. Leider muss man sich noch um den allokierten Speicher kümmern.
Durch Zufall bin ich auf einen Konstruktor des ATL::CComBSTR gestossen, welcher schon die ganze Arbeit erledigt :) Hier ein kleines Beispiel:

inline void DebugOutGuid( GUID g )
{ 
    OutputDebugString( ATL::CComBSTR( g ) );
} 

Die  DebugOutGuid Funktion kann auch mit folgenden Typen aufgerufen werden.

• GUID
• IID
• REFIID
• REFCLSID
• CLSID

Typedefs and defines:

typedef struct _GUID {
    unsigned long  Data1;
    unsigned short Data2;
    unsigned short Data3;
    unsigned char  Data4[ 8 ];
} GUID;

#define REFCLSID const IID &
#define REFIID const IID &

typedef GUID IID;
typedef GUID CLSID; 

Weiterführende Links:

• http://msdn.microsoft.com/en-us/library/ms683893(VS.85).aspx
• http://msdn.microsoft.com/en-us/library/ms683917(VS.85).aspx

An dieser Stelle möchte ich eine neue Klasse in meiner BonnyCXX Klassensammlung vorstellen: Dll.
Diese Klasse vereinfacht das arbeiten mit Dll's enorm. Laden, Funktionen suchen und Entladen sind mit einer Zeile Code möglich.

Hier die aktuelle Header Datei.

/*
 Bonny C++ Library - libbonny

 Axel Sauerhoefer
 Jockgrimerstr. 13
 76764 Rheinzabern

 axel[at]willcodeqtforfood.de
 http://www.willcodeqtforfood.de

 This file is part of libbonny.

 Libbonny is free software: you can redistribute it and/or modify
 it under the terms of the GNU General Public License as published by
 the Free Software Foundation, either version 3 of the License, or
 (at your option) any later version.

 Libbonny is distributed in the hope that it will be useful,
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.

 You should have received a copy of the GNU General Public License
 along with Libbonny.If not, see <http://www.gnu.org/licenses/>.


	3:6:2009   18:44
*/

#ifndef _BONNYCXX_SYSTEM_DLL_H
#define _BONNYCXX_SYSTEM_DLL_H 1

#include <boost/tuple/tuple.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/noncopyable.hpp>
#include <boost/function.hpp>

namespace BonnyCxx{
	namespace System {

/**
*  @brief DllVersion
*
* Typedef a simple tuple to store the dll version information.
*
* 1: The major version of the DLL. If the DLL's version is 4.0.950, this value will be 4. 
* 2: The minor version of the DLL. If the DLL's version is 4.0.950, this value will be 0. 
* 3: The build number of the DLL. If the DLL's version is 4.0.950, this value will be 950. 
*/
typedef	boost::tuple< std::wstring,  // The major version of the DLL
					  std::wstring,  // The minor version of the DLL
					  std::wstring  // The build number of the DLL
								  > DllVersion;

/**
* @brief forward and typedefs
*/
class Dll;
typedef boost::shared_ptr<Dll> DllPtr;

/**
* @brief Dll
*
* Simple dll class wrapper, simple working with dll's ( e.g. load, execute methods ... )
*
* @code
* 
* using namespace BonnyCxx::System;
*
* //Create an interface pointer
* DllPtr pDllInstance = Dll::Create( L"shdocvw.dll" );
*
* //Load the library
* if( pDllInstance->Load() == false )
* {
*	return false;
* }
*
* //Get the dll version if available
* DllVersion version = pDllInstance->GetVersion();
*	
* std::wcout << L"Dll Major version: " << version.get<0>() << std::endl;
* std::wcout << L"Dll Minor version: " << version.get<1>() << std::endl;
* std::wcout << L"Dll Build version: " << version.get<2>() << std::endl;
*
*  // Or resolve directly the method by using GetFunction function like this
* DLLGETVERSIONPROC pFunc = pDllInstance->Resolve<DLLGETVERSIONPROC>( L"DllGetVersion" );
*
* if( pFunc )
* {
*	DLLVERSIONINFO dvi = {};
*	dvi.cbSize = sizeof(dvi);
*            
*	const HRESULT hr = (*pFunc)(&dvi);	
*
*	if( SUCCEEDED( hr ) )
*	{
*		std::wcout << L"Dll Major version: " << dvi.dwMajorVersion << std::endl;
*		std::wcout << L"Dll Minor version: " << dvi.dwMinorVersion << std::endl;
*		std::wcout << L"Dll Build version: " << dvi.dwBuildNumber  << std::endl;
*	}
* }
* //Unlaod the dll
*	if( pDllInstance->UnLoad() == false )
*	{
*		return false;
*	}
*
* @endcode
*/
class Dll : public boost::noncopyable
{
public:

	/**
	* D'Tor
	*/
	~Dll(){};

	/**
	* Try to load the library
	*
	* @return bool true on success otherwise false
	*/
	bool Load();

	/**
	* Unload the library
	*
	* @return bool on success otherwise false
	*/
	bool UnLoad();

	/**
	* Check if the given dll is loaded or not.
	*
	* @return bool true if the dll was successfully loaded, otherwise false
	*/
	const bool IsLoaded() const;

	/**
	* Get version information about the dll
	*
	* @return DllVersion
	*/
	const DllVersion GetVersion() const;

	/**
	* Resolve a dll function/method by given signature, 
	* Must use ugly void*, virtual template functions not possible ;)
	*/
	template< typename Func >
	Func Resolve( const std::wstring& signature ) const
	{
		std::string ascii( signature.length(), ' ');
		std::copy( signature.begin(), signature.end(), ascii.begin() );
		return reinterpret_cast<Func>( GetProcAddress( m_handle, ascii.c_str() ) );
	}

	/**
	* Inplace factory, create an instance of DllPtr @see DllPtr
	*
	* @param std::wstring dll name
	* @return DllPtr object
	*/
	static DllPtr Create( const std::wstring& dll );

private:

	/**
	* C'tor
	*
	* Construct our Dll object, and store the given dll name into 
	* a member variable m_dllName.
	*/
	explicit Dll( const std::wstring& dll ) 
		: m_dllName( dll ),
		m_handle( NULL )
	{
		
	}

	/**
	* hold the dll name, e.g. path
	*/
	std::wstring m_dllName;

	/**
	* Dll handle
	*/
	HMODULE m_handle;

}; //end class IDll

	} //end namespace System
} //end namespace BonnyCxx


#endif //_BONNYCXX_SYSTEM_DLL_H

 Der gesamte Quellcode ist in folgendem Subversion Repository verfügbar: svn://willcodejoomlaforfood.de/bonny/trunk/bonny

Heute wollte ich ein kleines Wort zu CExceptions verlieren, bzw. wie man diese korrekt in einem catch Block abhandelt. Ich als absoluter MFC Neuling bin wohl in eine sehr weit verbreitete Pitfall gelaufen.
Ich habe mich gewundert warum meine COleException nicht von meinem catch Block behandlet wurde:

try{ 
 ... 
}catch( COleException& oe ) {
   //error handling
} 

Korrekterweise muss man alle CExceptions als Pointer behandlen und nicht als Referenz :/ Darauf muss man erst mal kommen ^^

try{ 
 ... 
}catch( COleException* oe ) {
   //error handling
   oe->Delete(); 
} 

Im Teil der Reihe "QT 4.5.0 OpenSource, Windows Vista, Visual Studio 2008" möchte ich ein howto bloggen, wie man die neuste Version der Klassenbibliothek QT aus dem Hause Nokia auf einem Windows Vista mit Visual Studio 2008 kompiliert und erfolgreich installiert.

Im Teil 1 geht es um QTDIR, QMAKESPEC und die Konfiguration configure.

QTDIR:

Die QTDIR Umgebungsvariable zeigt auf das Installationsverzeichnis von QT.

Beispiel: d:/development/qt/4.5.0/

Unterhalb von 4.5.0 befinden sich dann alle Unterordner.

QMAKESPEC:

QMakespec ist eine weitere Umgebungsvariable, welche das Betriebssystem und den Kompiler spezifiert. In meinem Fall win32-msvc2008.

Alle verfügbaren Kombinationen findet man im Ordner %QTDIR%/mkspecs/

Konfiguration:

Die Konfiguration erstelle ich immer über die Kommandozeile. Mit dem Tool configure lasse ich mir zunächst alle verfügbaren Parameter anzeigen, danach starte ich den Vorgang:
Hier meine aktuelle Konfiguration:

configure -debug-and-release -shared -no-fast -exceptions -accessibility \
             -stl -no-qt3support -qt-zlib \
             -qt-gif -qt-libpng -qt-libmng \
             -qt-libjpeg -rtti  -openssl -webkit -phonon-backend -scripttools   

Nachtrag OpenSSL:

Damit QT auch mit https Verbindungen zurrecht kommt, muss zusätlich das OpenSLL Paket installiert werden:

• http://www.slproweb.com/products/Win32OpenSSL.html

Danach noch die Umgebungsvariablen INCLUDE,LIB anpassen, Beispiel:

INCLUDE=D:\development\OpenSSL\include
LIB=D:\development\OpenSSL\lib