Xin đóng góp diễn đàn 1 Bài viết rất hay về InjectDLL,chỉ xin trích lại,không dịch để giữ nguyên ý nghĩa của bài viết

Introduction

Windows provides API function called, CreateRemoteThread [Reference 2] which allows any process to execute thread in the context of remote process. This method has been mainly used to inject DLL into remote process, the technique popularly known as 'DLL Injection'. Especially malware programs exploited this mechanism to evade their detection by injecting their DLL into legitimate process's such as Explorer.exe, Winlogon.exe etc.
Vista & Session Separation

This DLL Injection technique using CreateRemoteThread technique has worked flawlessly till Vista without any limitations. However since Vista onwards things have changed with the introduction of 'Session Separation' [ Reference 3 ]. This was one of so many defenses introduced in Vista towards securing the system. 'Session Separation' ensured that core system processes including services always run in session 0 while all user process's run in different sessions. As a result any process running in user session failed to inject DLL into system process as CreateRemoteThread did not work across session boundaries...

This is clearly evident from the MSDN documentation of CreateRemoteThread function...

"Terminal Services isolates each terminal session by design. Therefore, CreateRemoteThread fails if the target process is in a different session than the calling process."
About NtCreateThreadEx Function

With the failure of CreateRemoteThread, there was need for universal solution for remote thread execution on Vista and Windows 7 platform. Then comes the function, NtCreateThreadEx [Reference 1], the undocumented function which provides complete solution for executing remote thread across session boundaries. It allows any process to inject DLL into any other process irrespective of session in which it is running as long as it has sufficient privileges.

Here is the prototype of NtCreateThreadEx function [undocumented]
Mã:
typedef NTSTATUS (WINAPI *LPFUN_NtCreateThreadEx)
(
  OUT PHANDLE hThread,
  IN ACCESS_MASK DesiredAccess,
  IN LPVOID ObjectAttributes,
  IN HANDLE ProcessHandle,
  IN LPTHREAD_START_ROUTINE lpStartAddress,
  IN LPVOID lpParameter,
  IN BOOL CreateSuspended,
  IN ULONG StackZeroBits,
  IN ULONG SizeOfStackCommit,
  IN ULONG SizeOfStackReserve,
  OUT LPVOID lpBytesBuffer
);

This function is almost similar to CreateRemoteThread function except the last parameter which takes unknown buffer structure. Here is the definition of that buffer structure parameter...
Mã:
//Buffer argument passed to NtCreateThreadEx function

struct NtCreateThreadExBuffer
{
  ULONG Size;
  ULONG Unknown1;
  ULONG Unknown2;
  PULONG Unknown3;
  ULONG Unknown4;
  ULONG Unknown5;
  ULONG Unknown6;
  PULONG Unknown7;
  ULONG Unknown8;
};

This information is derived based on reverse engineering work. Hence meanings and importance of internal fields of this buffer structure is not clear.


Executing Remote Thread into System Process using NtCreateThreadEx Function
The steps involved in the execution of the remote thread using NtCreateThreadEx is almost similar to that of CreateRemoteThread function. Hence the traditional steps such as allocating memory, copying the thread code into remote process are not repeated here. For detailed steps you can refer to article, "Three Ways to Inject Your Code into Another Process"

Before we begin, we need to load NtCreateThreadEx function from Ntdll.dll as shown below.
Mã:
HMODULE modNtDll = GetModuleHandle("ntdll.dll");

if( !modNtDll )
{
   printf("
 failed to get module handle for ntdll.dll, Error=0x%.8x", GetLastError());
   return;
}

LPFUN_NtCreateThreadEx funNtCreateThreadEx =
             (LPFUN_NtCreateThreadEx) GetProcAddress(modNtDll, "NtCreateThreadEx");

if( !funNtCreateThreadEx )
{
   printf("
 failed to get funtion address from ntdll.dll, Error=0x%.8x", GetLastError());
   return;
}

Now setup the buffer structure which is passed as last parameter to NtCreateThreadEx function.
Mã:
//setup and initialize the buffer
NtCreateThreadExBuffer ntbuffer;

memset (&ntbuffer,0,sizeof(NtCreateThreadExBuffer));
DWORD temp1 = 0;
DWORD temp2 = 0;

ntbuffer.Size = sizeof(NtCreateThreadExBuffer);
ntbuffer.Unknown1 = 0x10003;
ntbuffer.Unknown2 = 0x8;
ntbuffer.Unknown3 = &temp2;
ntbuffer.Unknown4 = 0;
ntbuffer.Unknown5 = 0x10004;
ntbuffer.Unknown6 = 4;
ntbuffer.Unknown7 = &temp1;
ntbuffer.Unknown8 = 0;

Finally execute remote thread 'pRemoteFunction' into remote process using NtCreateThreadEx function. Here one can use 'LoadLibrary' function address instead of 'pRemoteFunction' thread to implement 'DLL Injection' technique.
Mã:
NTSTATUS status = funNtCreateThreadEx(
                        &hThread,
                        0x1FFFFF,
                        NULL,
                        hProcess,
                        (LPTHREAD_START_ROUTINE) pRemoteFunction,
                        pRemoteParameter,
                        FALSE, //start instantly
                        NULL,
                        NULL,
                        NULL,
                        &ntbuffer
                        );

Now check for the result of NtCreateThreadEx function and then wait for it to execute completely.
Mã:
if (hThread == NULL)
{
    printf("
 NtCreateThreadEx failed, Error=0x%.8x", GetLastError());
    return;
}
Mã:
//Wait for thread to complete....
WaitForSingleObject(hThread, INFINITE);

Finally retrieve the return value from the remote thread function, 'pRemoteFunction' to verify the result of function execution.
Mã:
//Check the return code from remote thread function
int dwExitCode;
if( GetExitCodeThread(hThread, (DWORD*) &dwExitCode) )
{
     printf("
 Remote thread returned with status = %d", dwExitCode);
}

CloseHandle(hThread);

The steps illustrated above are almost similar except that here NtCreateThreadEx is used instead of CreateRemoteThread for creating thread in the context of remote process.
Limitations of NtCreateThreadEx Method

Though NtCreateThreadEx provides universal solution on Vista/Win 7 platform for remote thread execution, it is risky to use in the production code as it is undocumented function. As things may change with new version and suppor packs, enough testing is necessary before putting it into production especially when injecting code into system critical process such as LSASS.EXE, CSRSS.EXE.

Another limitation is that it cannot be used in earlier platforms before Vista, such as Windows XP because NtCreateThreadEx function is available only Vista onwards. However developers can easily tune their code to dynamically use CreateRemoteThread function on XP and NtCreateThreadEx for Vista/Windows 7.
Alternative Techniques

Another way to inject DLL into system process is to write the service process (which will run in session 0) and then issue the command from user process to that service to inject DLL into any system process using the CreateRemoteThread function.

This technique will work for any system process running in session 0. But it will fail to execute thread into any other process running in session other than 0.

Though it is a clumsy way of doing the work, it still holds good solution to inject thread into system process only.
Conclusion

This article provides practical implementation of using NtCreateThreadEx function to execute remote thread into any process on Vista/Windows 7 platform. Though it is undocumented function, it provides universal solution for executing code in any process across session boundaries imposed by Vista.
References

1. NtCreateThreadEx Function http://undocumented.ntinternals.net/...eThreadEx.html
2. MSDN Documentation of CreateRemoteThread Function: http://msdn.microsoft.com/en-us/libr...37(VS.85).aspx
3. Impact of Session 0 Isolation on Services http://www.microsoft.com/whdc/system...n0Changes.mspx
4. Three ways to inject code into remote process: http://www.codeproject.com/KB/threads/winspy.aspx


Passsword store:


Saved Password Locations
Many people ask me about the location in the Registry or file system that applications store the passwords. So I prepared a list of password storage locations for popular applications.
Be aware that even if you know the location of the saved password, it doesn't mean that you can move it from one computer to another. many applications store the passwords in a way that prevent you from moving them to another computer or user profile.

* Internet Explorer 4.00 - 6.00: The passwords are stored in a secret location in the Registry known as the "Protected Storage".
The base key of the Protected Storage is located under the following key:
"HKEY_CURRENT_USER\Software\Microsoft\Protecte d Storage System Provider".
You can browse the above key in the Registry Editor (RegEdit), but you won't be able to watch the passwords, because they are encrypted.
Also, this key cannot easily moved from one computer to another, like you do with regular Registry keys.

IE PassView and Protected Storage PassView utilities allow you to recover these passwords.


* Internet Explorer 7.00 - 8.00: The new versions of Internet Explorer stores the passwords in 2 different locations.
AutoComplete passwords are stored in the Registry under HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2.
HTTP Authentication passwords are stored in the Credentials file under Documents and Settings\Application Data\Microsoft\Credentials , together with login passwords of LAN computers and other passwords.

IE PassView can be used to recover these passwords.


* Firefox: The passwords are stored in one of the following filenames: signons.txt, signons2.txt, and signons3.txt (depends on Firefox version)
These password files are located inside the profile folder of Firefox, in [Windows Profile]\Application Data\Mozilla\Firefox\Profiles\[Profile Name]
Also, key3.db, located in the same folder, is used for encryption/decription of the passwords.


* Google Chrome Web browser: The passwords are stored in [Windows Profile]\Local Settings\Application Data\Google\Chrome\User Data\Default\Web Data
(This filename is SQLite database which contains encrypted passwords and other stuff)


* Opera: The passwords are stored in wand.dat filename, located under [Windows Profile]\Application Data\Opera\Opera\profile


* Outlook Express (All Versions): The POP3/SMTP/IMAP passwords Outlook Express are also stored in the Protected Storage, like the passwords of old versions of Internet Explorer.

Both Mail PassView and Protected Storage PassView utilities can recover these passwords.



* Outlook 98/2000: Old versions of Outlook stored the POP3/SMTP/IMAP passwords in the Protected Storage, like the passwords of old versions of Internet Explorer.

Both Mail PassView and Protected Storage PassView utilities can recover these passwords.



* Outlook 2002-2008: All new versions of Outlook store the passwords in the same Registry key of the account settings.
The accounts are stored in the Registry under HKEY_CURRENT_USER\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\[Profile Name]\9375CFF0413111d3B88A00104B2A6676\[Account Index]
If you use Outlook to connect an account on Exchange server, the password is stored in the Credentials file, together with login passwords of LAN computers.

Mail PassView can be used to recover lost passwords of Outlook 2002-2008.


* Windows Live Mail: All account settings, including the encrypted passwords, are stored in [Windows Profile]\Local Settings\Application Data\Microsoft\Windows Live Mail\[Account Name]
The account filename is an xml file with .oeaccount extension.

Mail PassView can be used to recover lost passwords of Windows Live Mail.


* ThunderBird: The password file is located under [Windows Profile]\Application Data\Thunderbird\Profiles\[Profile Name]
You should search a filename with .s extension.



* Google Talk: All account settings, including the encrypted passwords, are stored in the Registry under HKEY_CURRENT_USER\Software\Google\Google Talk\Accounts\[Account Name]


* Google Desktop: Email passwords are stored in the Registry under HKEY_CURRENT_USER\Software\Google\Google Desktop\Mailboxes\[Account Name]


* MSN/Windows Messenger version 6.x and below: The passwords are stored in one of the following locations:
1. Registry Key: HKEY_CURRENT_USER\Software\Microsoft\MSNMessenger
2. Registry Key: HKEY_CURRENT_USER\Software\Microsoft\MessengerServ ice
3. In the Credentials file, with entry named as "Passport.Net\\*". (Only when the OS is XP or more)


* MSN Messenger version 7.x: The passwords are stored under HKEY_CURRENT_USER\Software\Microsoft\IdentityCRL\C reds\[Account Name]


* Windows Live Messenger version 8.x/9.x: The passwords are stored in the Credentials file, with entry name begins with "WindowsLive:name=".

These passwords can be recovered by both Network Password Recovery and MessenPass utilities.


* Yahoo Messenger 6.x: The password is stored in the Registry, under HKEY_CURRENT_USER\Software\Yahoo\Pager
("EOptions string" value)



* Yahoo Messenger 7.5 or later: The password is stored in the Registry, under HKEY_CURRENT_USER\Software\Yahoo\Pager - "ETS" value.
The value stored in "ETS" value cannot be recovered back to the original password.



* AIM Pro: The passwords are stored in the Registry, under HKEY_CURRENT_USER\Software\AIM\AIMPRO\[Account Name]


* AIM 6.x: The passwords are stored in the Registry, under HKEY_CURRENT_USER\Software\America Online\AIM6\Passwords



* ICQ Lite 4.x/5.x/2003: The passwords are stored in the Registry, under HKEY_CURRENT_USER\Software\Mirabilis\ICQ\NewOwners \[ICQ Number]
(MainLocation value)



* ICQ 6.x: The password hash is stored in [Windows Profile]\Application Data\ICQ\[User Name]\Owner.mdb (Access Database)
(The password hash cannot be recovered back to the original password)


* Digsby: The main password of Digsby is stored in [Windows Profile]\Application Data\Digsby\digsby.dat
All other passwords are stored in Digsby servers.


* PaltalkScene: The passwords are stored in the Registry, under HKEY_CURRENT_USER\Software\Paltalk\[Account Name].