PB scannrange 12-12-2004

[test0r]

@mcMike: Hehe, all you posted is what I already have read in that tutorial linked by you (source code on codeguru.com).
And well, I can say that some steps there are really not needed.

And again (maybe you understand now): Why is there a need to program a DLL for that simple purpose?? You just put your SEHandler (which you say should be in your DLL) into a 2nd allocated memory chunk (just like you have posted for the thread function: "WriteProcessMemory(Handle, memoryaddressForCode, &YourInjectedFunction,MAXSIZE,0)") and you're fine. No need for loading a DLL.


Ok, bf194lover wants his DLL as a library with advanced functionality - but I say: You dont really need it to make a nice small PB hack.

[mcMike]

@mcMike: Hehe, all you posted is what I already have read in that tutorial linked by you (source code on codeguru.com).

Is that a bad thing? I can remove that post if it offends you somehow.

And well, I can say that some steps there are really not needed

Isn't that quite obvious. In _this case_ you can skip all the memory-freeing , priviledges, etc. But if you mean there are uncessary steps in the phases (1-6) I described please feel free to say what exactly?

And again (maybe you understand now): Why is there a need to program a DLL for that simple purpose?? You just put your SEHandler (which you say should be in your DLL) into a 2nd allocated memory chunk (just like you have posted for the thread function: "WriteProcessMemory(Handle, memoryaddressForCode, &YourInjectedFunction,MAXSIZE,0)") and you're fine. No need for loading a DLL.

I tought I said this clearly in my previous post (to bf194lover) ?

[test0r]

Is that a bad thing? I can remove that post if it offends you somehow.

[...]

I tought I said this clearly in my previous post (to bf194lover) ?

NO, it wasnt meant as offense from my side!

And well, I just created my post when you posted your last one

[mcMike]

NO, it wasnt meant as offense from my side!

And well, I just created my post when you posted your last one

Ok. I'm sorry. Having a bad day and took that negatively. My bad.

[goggles99]

Injecting a DLL isn't absolutly necessary, Code injection can be used also...

I am not using the "XP only" Vectored Exception Handling. I use windows 2000 and XP so I decided to use an alternate method. I am hooking the KiUserExceptionDispatcher API an setting up a simple filter to determine if I am in the correct exception, then I act accordingly.

Let me offer a word of advice to all... I would recommend actually finishing this project and getting it working before posting a step-by-step. Otherwise, you will most likely cause others countless wasted hours and many headaches.

here is the order of "Who Calls Who in SEH" if you are interested in this "more flexible" method.

KiUserExceptionDispatcher()

RtlDispatchException()

RtlpExecuteHandlerForException()

ExecuteHandler()

courtesy of Matt Pietrek's... "A Crash Course on the Depths of Win32™ Structured Exception Handling"

[mcMike]

Quicky: After injecting DLL when is DllMain() with DLL_PROCESS_ATTACH called and from where?

[Schooler]

Just curious here of course, but do you disable calls to your DllMain when new threads join/leave the process to reduce risk?

[bf194lover]

Hi,

You let your started RemoteThread ran as separate (new extra) thread in target-process all along? AND you have simple UI in there also? (by clientDLL you mean your DLL that is loaded from injected code I assume).

You control the injectedDLL with messages send FROM your trainer (thus pump messages) ?

I use the thread that executes injected code (code that is written to target process space).
It basically loads the dll (LoadLibrary) and then calls a custom entry point - in same thread context (created by CreateRemoteThread).
The name of client dll to be loaded and entry point are written with injected code.
The thread exists as long as the entry point function doesnt return.
If entry makes a modal message loop it returns (thereby terminating itself) after gui has been closed or forcibly when main app thread exits.

@googles99: Yes, Pietrek is always a good source to read and learn from.
I remember when i was reading his articles for the first time, years ago.
Jeffrey Richter was my hero too.
I own some of the famous books, "windows internals", "advanced windows", "native api reference" worth reading.

uicky: After injecting DLL when is DllMain() with DLL_PROCESS_ATTACH called and from where?

It gets usually invoked, when:

1) a client does an explicit LoadLibrary (for explicitly loaded DLLs)
2) a client loads (for an implicitly loaded DLL)
3) any threads are created or destroyed by the client (unless the DllMain has called DisableThreadLibraryCalls..

The OS loader calls it and does much more work under hood.

Here is some decent info (among other stuff):

http://www.microsoft.com/msj/0999/hood/hood0999.aspx
http://msdn.microsoft.com/library/de...se/dllmain.asp
http://msdn.microsoft.com/msdnmag/is...E/default.aspx
http://blogs.msdn.com/oleglv/archive.../12/43069.aspx

ust curious here of course, but do you disable calls to your DllMain when new threads join/leave the process to reduce risk?

You think of DisableThreadLibraryCalls()?
Not necessary.

[PITA11]

From leecher, to nopper, to caver, to DMA, and now to SEH, will it ever end?
I am too old for this shihite..MY POOR FEEBLE BRAIN HOITS Let the edumacation continue..Thanks everyone!! :ermm:

[mcMike]

Hi,

I use the thread that executes injected code (code that is written to target process space).
It basically loads the dll (LoadLibrary) and then calls a custom entry point - in same thread context (created by CreateRemoteThread).
The name of client dll to be loaded and entry point are written with injected code.

I understood that In NT/2K/XP-only there's a shortcut. You can pass the functionpointer to LoadLibrary() for CreateRemoteThread() and all you have to inject is name of the DLL to be loaded. So no stub is needed for loader . It would be like:

GetProcaddress() for LoadLibrary(). Allocate memory for remote-thread storage and writeProcessMemory() the name of the DLL_to_be_loaded there. Then CreateRemoteThread() and pass the funcPointer for LoadLibrary() and address of the location where DLLname is stored. The DLLMain gets called as soon as it's loaded.

(Hmm. If it works Test0r was right. There are some things to shortcut. I read the tuts too fast and that slipped by. This is mentioned in GodeGuru's article )

@googles99: Yes, Pietrek is always a good source to read and learn from. I remember when i was reading his articles for the first time, years ago. Jeffrey Richter was my hero too. I own some of the famous books, "windows internals", "advanced windows", "native api reference" worth reading.

When I started windows-programming there were nothing else written than good'old Petzold Then came the MFC and things got lot "easier".


Thanks for the links (again).

[mcMike]

Hello,

I ran to a weird problem with VB. I spend like 6 hours trying to write DLLinjector with CreateRemoteThread()-method and passing LoadLibraryA() as entrypoint.
Never got it to work. Then I used like 10 minutes to port it to C and got it working at the first run.

I would like to use VB for injector for other reasons so does anyone got any idea what could be wrong? I do it exacly same than with C but when the remote thread starts the EIP is pointing to totally wrong place (outside off all valid addresses) and target process of course crashes.

I verified that I get same procAdress for LoadLibraryA with VB and C. I check that all the handles are valid etc. and anyway they are exactly same in both (VB/C). It just looks like CreateRemoteTread() is getting the ThreadStartAddress wrongly when passed from VB. Could there be some address-conversion stuff (hibyte/lowbyte hiword/loword etc.) in VB when passing function pointers that I'm not aware of?

Anyway. The nice thing is that CreateRemoteThread(pfnLoadLibrary)-method works and it's only like 8 lines of code to completely inject DLL and have DLLMain called.

[test0r]

I understood that In NT/2K/XP-only there's a shortcut. You can pass the functionpointer to LoadLibrary() for CreateRemoteThread() and all you have to inject is name of the DLL to be loaded. So no stub is needed for loader . It would be like:

GetProcaddress() for LoadLibrary(). Allocate memory for remote-thread storage and writeProcessMemory() the name of the DLL_to_be_loaded there. Then CreateRemoteThread() and pass the funcPointer for LoadLibrary() and address of the location where DLLname is stored. The DLLMain gets called as soon as it's loaded.

Wow, am I ingenious?! Yes my intelligent brain also brought that nice method up (without knowing shit before) - but it didnt work :ermm: . Though I didnt have much time yesterday which could be the reason why I ****ed it up, will try ASAP again!

When I started windows-programming there were nothing else written than good'old Petzold Then came the MFC and things got lot "easier".

Yea, I also think MFC is a very nice library every Windows Programmer should use. WHY the heck re-invent the wheel? ...

[test0r]

OK, got the Loader-Thread shortcut thing done - Didnt put the dll name string into "enemy" address space.


btw, no need for a GetProcAddress() call. Just use "(LPTHREAD_START_ROUTINE)LoadLibrary" as parameter #4 in CreateRemoteThread() (this is for C++ of course).

[bf194lover]

btw, no need for a GetProcAddress() call. Just use "(LPTHREAD_START_ROUTINE)LoadLibrary" as parameter #4 in CreateRemoteThread() (this is for C++ of course).

That way you are begging for problems
Your code has to be executed in DllMain() then - with an active OS loader lock.
There are several restrictions in DllMain (search MSDN).

Its better to explicitly load dll in thread, leaving simple init() stuff in Dllmain (or nothing but return 1) and call dedicated export (after loadlibrary succeeded) to do stuff.

Regards

[mcMike]

OK, got the Loader-Thread shortcut thing done - Didnt put the dll name string into "enemy" address space.


btw, no need for a GetProcAddress() call. Just use "(LPTHREAD_START_ROUTINE)LoadLibrary" as parameter #4 in CreateRemoteThread() (this is for C++ of course).

Test0r. I love the way you think. KISS (Keep It Simple Stupid).
Yes. This will remove one extra step.

Did you mean that YOU didn't put the dllname to target process and therefore didn't get it to work or do you mean that it can be passed some other way?

That way you are begging for problems
Your code has to be executed in DllMain() then - with an active OS loader lock.
There are several restrictions in DllMain (search MSDN).

Its better to explicitly load dll in thread, leaving simple init() stuff in Dllmain (or nothing but return 1) and call dedicated export (after loadlibrary succeeded) to do stuff.

Regards

Wouldn't it be possible to call that export with another CreateRemoteThread() ?
(Me don't like to inject stub )

btw, BF194Lover. As so many ppl has said this before; You really amaze me. This reminds me of a scene in Wayne's World 1: Worshipping, "we're not worth it, we're not worth it....
I love the stuff you pointed me into in your PM. Thanks alot (again).
The DllInject with uncle Bill's library is only 4 lines anymore (well, single line once you get process handle). Not that I mind the length of code but it offers some much more. CHEERS !