Hi,
I'm having a bit of a problem figuring out quite how a stub is implemented. I get the basic idea - I essentially write skeleton functions that mirror the DLL etc.. that I wish to intercept etc.. and pass those functions I'm not interested in on to the real DLL, etc..
The bit I'm lost on is how to get my code loaded as the "real" DLL in the first place?
In the case of the GINA stub it would appear that I replace the real DLL with my own, and then call a copy of the original. Is it really as simple as that?
Sometimes I think I expect things to be far more complex than they are...
Why do you want to muck around with GINA?
Something I'm working on (it's not for illegal purposes - don't worry - I just need to modify GINA).
Is my general understanding correct?
I've had to fix quite a few computers when MSGINA got replaced by malware so I'm a bit wary...it is part of winlogon and the SAS after all...
>it's not for illegal purposes - don't worry - I just need to modify GINA
Of course (even though GINA is quite a popular vector).
Sorry, but I fix a lot of computers, viruses/malware are no challenge (just boring) so I am sick-and-bloody-tired of this.
The worst thing is seeing masm32 code in them... :'(
yeah askin to mess with GINA is shady, it's also ignored on vista anyway so don't know how much use its of.
Oh... fair enough.
Here's the situation:
I want to add a new authentication mechanism to Windows. I can't say what as it is the subject of one or more patent applications, however, as part of this, I need to modify the behavior of GINA, but not the UI.
If you're unhappy discussing GINA, is there anything like this that we could discuss, as I only want to know the principles, not specifics.
I'm only using MASM as I seem to be getting on with this 10,000% better than my attempts with C++.
I run a legitimate software company, based in the UK. I'm not some kid trying to write a virus.
From Microsoft (I e-mailed them directly):
QuoteThank you in your interest in the latest publications about the Windows GINA. This is not a support alias.
If you can solve your problem by using a GINAHOOK or GINASTUB, that is preferred. Samples of GINAHOOK and GINASTUB can be found in the Platform SDK currently available at:
http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang=en
These samples are older so they don't support the new functions in the Winlogon WLX_DISPATCH_VERSION_1_4 structure function dispatch table (http://msdn.microsoft.com/en-us/library/aa381173.aspx). You will need to add them.
MSDN has documentation on the GINA:
http://msdn.microsoft.com/en-us/library/aa375457(VS.85).aspx
The MSDN had two articles about customizing GINAs that might help you in your GINA project:
* May 2005: Security Briefs: Customizing GINA, Part 1
http://msdn.microsoft.com/en-us/magazine/cc163803.aspx
* June 2005: Security Briefs: Customizing GINA, Part 2
http://msdn.microsoft.com/en-us/magazine/cc163786.aspx
Also in case you had not already heard, beginning with Windows Vista, GINAs will not be supported. They have been replaced by Credential Providers.
The ICredentialProvider interfaces are in the Windows Vista SDK which can be found at http://windowssdk.msdn.microsoft.com/library/:
> User Interface > Windows Shell > Shell Reference > Shell Interfaces
MSDN Magazine has published an article: Create Custom Login Experiences With Credential Providers For Windows Vista which can be found at
http://msdn.microsoft.com/msdnmag/issues/07/01/CredentialProviders/default.aspx
There are five RTM credential provider samples available for download at http://www.microsoft.com/downloads/details.aspx?FamilyID=B1B3CBD1-2D3A-4FAC-982F-289F4F4B9300&displaylang=en
There is also a new CredUI which uses the credential provider infrastructure which can be found in the MSDN at http://msdn2.microsoft.com/en-us/library/aa375178.aspx
All requests for Credential Provider Development support should be directed to Microsoft Services.
The use of SCM notifications and SENS based solutions to replace Winlogon notification packages is in the Winlogon Notification Packages Removed Impact on Windows Vista Planning and Deployment whitepaper which is available for download at
http://www.microsoft.com/downloads/details.aspx?FamilyID=311f4be8-9983-4ab0-9685-f1bfec1e7d62&displaylang=en
I know this won't work in Vista - I need to write this all over again just to work with that (and possibly AGAIN, for Windows 7). ::)
I understand how dodgy this looks, but it isn't.
Are you in the UK?
OK, lots of existing legitimate uses (I looked at the MSDN stuff too, it's all open).
So you are trying to forward functions?
E^cube, what was that about Vista?
Yes.
I'm still researching exactly which bits I'm interested in, but from what I can tell I only need one little bit concerning the actual authentication (the point where the system checks username/password). Everything else just wants forwarding to the real deal.
What I'm particularly interested in right now, is how it hangs together. I want to start writing code to try things, but from what I've read, it is quite easy to break and hard to fix. I'm going to test this in a VM so the breaking part isn't so bad.
Do I need to manually load the real DLL for example (using LoadLibrary or similar)? It's these details I'm unsure of.
This part is just the first of a few things I want to do. I also need to figure out how to write a driver. Plenty of stuff on VxDs but I don't think that is applicable for XP or later.
I've already got the Driver SDKs for XP and Vista, respectively.
If it helps, the admin/mods can see I'm on a fixed IP. They can do various searches on that to verify where I am. Doing a bit more searching they will find a domain name attached to the IP. WHOIS the domain etc...
If I really was a hacker (which I'm not), I'd be pretty dumb to make myself traceable with that kind of info. ::)
If you'd prefer to do this via PM to keep it out of general view, I'm happy with that.
Can I safely assume I'm not giong to get any help with this? :(
Well, the SDK seems to have all of the information you need, and it's not something that is easy to test out so most/all of us won't want to.
I need more fundamental help than that.
It would appear that I need to implement every function in my stub DLL, and call the real DLL.
Pseudo code:
start:
LoadLibrary(Real.DLL)
proc SomeFunc
call RealDLL:SomeFunc
end proc
etc..
Does this look about right?
Actually, after much staring at the screen, I think I've answered my own question! :cheekygreen:
My only problem now is maintaing the stack and registers as apparently if these are not maintained, it can break the Win32 APIs.
I think to do that you do NOT create function protoypes??
.code
DllEntry proc hInstDLL:HINSTANCE, reason:DWORD, reserved1:DWORD
mov eax,TRUE
ret
DllEntry Endp
SomeWin32APIProc proc
; LoadLibrary
; Code
; etc..
SomeWin32APIProc endp
End DllEntry
Tomorrow I'll have a go at creating a stub for one of my own DLL files. :U
Best regards,
Astro.
Hi,
I'm stuck. I've got this so far:
My C++ DLL:
#include <windows.h>
bool CheckForDevice()
{
HANDLE hDevice;
memset(&hDevice,0,sizeof(hDevice));
hDevice = CreateFile("\\\\.\\USB#...(REMOVED)...", 0, 1, NULL, OPEN_EXISTING, 0, NULL);
if(hDevice == INVALID_HANDLE_VALUE)
{
CloseHandle(hDevice);
/*HANDLE ProcessToken;
TOKEN_PRIVILEGES pTokenStruct;
OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &ProcessToken);
LookupPrivilegeValue(NULL, SE_SHUTDOWN_NAME, &pTokenStruct.Privileges[0].Luid);
pTokenStruct.PrivilegeCount = 1;
pTokenStruct.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
AdjustTokenPrivileges(ProcessToken, FALSE, &pTokenStruct, 0, (PTOKEN_PRIVILEGES) NULL, 0); */
//InitiateSystemShutdown(NULL, NULL, 0, TRUE, FALSE);
//CloseHandle(ProcessToken);
return false;
}
else
{
CloseHandle(hDevice);
return true;
}
}
My assembler stub DLL (snippet):
.code
DLL db "CheckDevice2.dll",0
IsDevice proc
LOCAL handle dd ?
LOCAL func db "CheckForDevice",0
; call LoadLibrary and get handle to module
push DLL
call LoadLibrary
mov handle,eax
; get the address of the procedure in the module
push func
push handle
call GetProcAddress
; stuck here.
IsDevice endp
How do I actually call the procedure in my real DLL?
I haven't tried to build this code yet, so not sure if my LOCALs will work either.
Best regards,
Astro.
D'oh!! :cheekygreen:
call eax
?
Best regards,
Astro.
IT works. Here is the completed code.
CheckForDevice in CheckDevice2.dll returns a boolean and takes no arguments.
.386
.model flat,stdcall
option casemap:none
include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib
.data?
handle dd ?
.code
DLL db "CheckDevice2.dll",0
func1 db "CheckForDevice",0
DllEntry proc hInstDLL:DWORD, reason:DWORD, reserved1:DWORD
cmp reason,1h ;DLL_PROCESS_ATTACH
jnz DLL_DETACH
push offset DLL
call LoadLibrary
test eax,eax ; If NULL, DLL did not load!
jz NH ; test should be non-zero, ZF==0
mov handle,eax
mov eax,1h
ret 0Ch
DLL_DETACH:
push handle
call FreeLibrary
ret 0Ch
NH:
mov eax,0h
ret 0Ch
DllEntry Endp
CheckForDevice proc
push offset func1
push handle
call GetProcAddress
call eax
ret
CheckForDevice endp
End DllEntry
QED.
Not bad for starting x86 assembly programming 9 days ago. :8) :U
Best regards,
Astro.
glad you got it working but you should not do heavy work in the entry point of a dll.. including loading a library
http://msdn.microsoft.com/en-us/library/ms682583(VS.85).aspx
QuoteThe entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination, because this can result in a DLL being used after the system has executed its termination code.
same with dll detach. that is the value when the dll is detaching, you can let the system do it. it is ALREADY the result of freelibrary or some variant of it, there is no need to call it again
Hmm.
How would it be done then? In every procedure?
Best regards,
Astro.
well.. i'm not QUITE sure what you're doing. am i correct in saying that you have a dll checkdevice2.dll which has in it a function checkdevice which you want to make available for calling if the dll is mapped into a process' memory space ? if yes, then there is no need to call loadlibrary again. the entry point is accessed as a result of a loadlibrary/ex call with that dll's name as the parameter
just return true from your dllmain
the same is true with your freelibrary call. it is a result of a freelibrary call already.. it's like some thread has called freelibrary or a variant of it like freelibraryandexitthread and the system is telling your dll SOMEONE WANTS TO FREE THIS DLL ANYTHING YOU WANT TO DO BEFORE WE PROCEED ?! and you're like.. YEAH IF YOU COULD FREE THIS DLL IT'D BE GREAT !
Hi,
Yes, I have a DLL called "CheckDevice2.dll".
Best regards,
Astro.