Log in

View Full Version : Server Thread Recycling (Beginings..)


BanMe
June 21st, 2009, 22:20
*please see "Current Lpc Server" if you seeking source..*
(I Reorganized..)

Sin32:
*Update 1*
fixed logic bug in Native_InitServerHandleTable
Changed name of Native_TryCaptureThread to Native_ReuseWorker.. I also did alot of modification to Native_ReuseWorker in order to provide more redunancy and the ability to Capture the TargetThread as well as the Current Worker..
im working on a feature in NtWaitForSingleObject in the Call to Native_AcceptConnection Request..had reset the event for the wait to happen..
update to code coming after i get it working properly in all debug runs :]


Regards BanMe

BanMe
July 2nd, 2009, 20:38
*UPDATE 1.01av2*
add a Handle Table functions and applied them to alot of the code...(not all but alot).
Current Client Will not work with Current Server...(especially in native mode);
I need to make the DACL for it less restrictive for My Events then the System's default DACL... but I'm working on it
updated alot of functions.. did "some" documenting..(Im working on trying to do the Visual Studio Document as you code with XML bullshit but I dont quite understand that yet...)

regards BanMe

dELTA
July 3rd, 2009, 05:23
Nice to see this interesting work progressing.

BanMe
July 3rd, 2009, 21:59
much more to do and im away atm (at a friends house).. but I've been thinking as to why the RtlIsValidIndexHandle fails in the Native_GetHandleTableHandle Function.. and then it hit me that I just need to move the handle to the object up under the Ptr to next HANDLE_ENTRY... so what I gained from this breif insight is that most functions can be used with Extended structures as long as the base of the structure is still Maintained..now this is all ramblings of a insane person, but for example

Code:

typedef struct _RTL_HANDLE_TABLE_ENTRY
{
struct _RTL_HANDLE_ENTRY*Next;
HANDLE Object;
}RTL_HANDLE_TABLE_ENTRY,*PRTL_HANDLE_TABLE_ENTRY;

and if one has looked at the source my SIN32_HANDLE_TABLE_ENTRY
so not match this structure base..

oh and dELTA, I will be updating here for a long long time.. I hope...

regards BanMe

or one could just use RtlIsValidHandle .. I love finding secondary solutions by looking at functions... lol

dELTA
July 4th, 2009, 18:55
Looking forward to it then.

BanMe
July 5th, 2009, 08:22
Native_GetHandleTableHandle is not working as intended the error resides in test byte ptr[eax],1..in RtlIsValidHandle where eax = Next Entry.., i tried moving it around and that didn't work.. so its been eating at me to figure it out...and so what ive come up with may be a trivial solution but I plan on using the Heap Allocated by Native_CreateHeap = 0x4096 im just gonna do
memmove(ServerHandleTable+sizeof(RTL_HANDLE_TABLE)+(HandleIndex*sizeof(SIN32_HANDLE_TABLE_ENTRY)),Ha ndleEntry,sizeof(SIN32_HANDLE_TABLE_ENTRY));
to pack the records into the allocated space.. and then use CONTAINING_RECORD to query the index's and return ENTRY's. this is also looking to be a more portable solution to this problem.. and more memory friendly...

hope to get this update done by today

regards BanMe

BanMe
July 5th, 2009, 22:31
*update*
the godamn Handle Table!!1i bruteforced it

here a sample no time to post the source til tmo
Code:

CheckTable:
HandleIndex++;
if(!RtlIsValidIndexHandle((RTL_HANDLE_TABLE*)ServerHandleTable,HandleIndex,(PRTL_HANDLE_TABLE_ENTRY* )&HandleEntry))
{
if(HandleIndex > 410)
{
__asm jmp TryBruteForce;
}
__asm jmp CheckTable;
}
else
{
if(HandleEntry->HandleType == HandleType && HandleEntry->HandleState == DesiredState)
{
return HandleEntry->Handle;
}
}
TryBruteForce:
HandleIndex = 0;
TempTable = CONTAINING_RECORD(ServerHandleTable,RTL_HANDLE_TABLE,MaximumNumberOfHandles);
GrabEntry:
HandleEntry = CONTAINING_RECORD(TempTable->CommittedHandles+(HandleIndex*sizeof(SIN32_HANDLE_TABLE_ENTRY)),SIN32_HANDLE_TABLE_ENTRY,Next);
if(HandleEntry)
{
if(HandleEntry->HandleType == HandleType && HandleEntry->HandleState == DesiredState)
{
return HandleEntry->Handle;
}
else
{
HandleIndex++;
__asm jmp GrabEntry;
}
}


regards BanMe

BanMe
July 6th, 2009, 22:26
*update* 1.01av3
the godamn Handle Table!! is workable..
I bruteforced it if RtlIsValidIndexHandle Fails..I basically emualte it without doing the checks on the handle_entry..
added the ServerHandleTable to the PEB in order to use in function where it isn't passed in..
also good news the Old client works with this release..ill be placing that up here soon..
many hacks added..until I can find operable solutions that aren't hacks
Currently working on fixing Native_DispatchThread..I copy the param(PORT_MESSAGE) to *Context.esp and FlushInstructionCache esp then set the Context and resume the thread.. unforntunatly this isnt enough because NtAcceptConnect fails..im pretty sure i need to pushad popad in Native_GetHandleTableHandle(havent gotten to that yet)

regards BanMe

dELTA
July 7th, 2009, 06:41
Just for encouragement, I don't think that the lack of response is because people don't find your project cool, but rather because the absolute majority (including me) don't know what the hell you're talking about most of the time when it comes to the details of this project.

I'm not even sure that Kayaker feels completely at home with it?

I think though that when it starts to show the cool reversing stuff you can do with it, if you would choose to implement such stuff, people will be much more positive.

Please keep up the good work anyway.

BanMe
July 7th, 2009, 09:27
Thank you dELTA I really needed that..
It's hard to implement the reversing capabilities without a solid base.
so that is what I am currently working on making it as solid and redundant as it possibly can be..cause eventually I want it to be operable without a VM..and not cause to many bsod's.

But again thanks for the encouragement
Regards BanMe

disavowed
July 7th, 2009, 10:34
I second what dELTA's comment above.
Quote:
I want to implement a way for the server to reduce thread usage by reusing dying threads..

I assume this is to improve performance? How much of a performance impact is there in spawning new threads? How many cycles do you expect to be able to save with your changes? My guess is that if your perf is taking such a bad hit because you're re-spawning so many new threads, then you should re-evaluate the design of your server instead of trying to figure out how to spawn "new" threads more efficiently (and in this context, by "you" I mean "somebody", not "BanMe" himself).

This is the whole idea behind a thread pool (http://en.wikipedia.org/wiki/Thread_pool).

BanMe
July 7th, 2009, 11:19
yes a thread pool is something to be thought of but im just doing it this way..there was no performance hit but there was alot special circumstance's that pushed me towards doing things a certain way..the fact that i abhore global data(handles,and other stuff)and I know that Im not just going blindly anaylizing everything, a Internal Database hit me as a decent idea in order to avoid global's and this is why I did thing "differently"..Also with the lack of success in being able to properly call RtlRemoteCall before(I can now..in fact im adding that as a errored to behavior for Native_DispatchThread..) in the previous release of the server, this seemed like a satisfactory solution..If you dont think it is, I would enjoy to hear your ramblings on this... Also the statement I made above needs a little revision..

Quote:

I want to implement a way for the server to reduce thread usage by reusing dying threads..


Instead I made a Suspended "Thread Pool" and located the "handles there types and States" in the handle Table. I still need to update "the state" of the handle in the table, after return of the handle from "Suspended" to "Running" and implement Thread recapturing but this is all trivial..
I also added redundancy as well if a "Suspended" thread cant be found then it Create's one and so forth.

Quote:

then you should re-evaluate the design of your server instead of trying to figure out how to spawn "new" threads more efficiently (and in this context, by "you" I mean "somebody", not "BanMe" himself).


as you can see ive also evaluated many things though I am unsure of what you mean by the last segment..

regards BanMe

disavowed
July 7th, 2009, 16:59
i was just saying that it should be interpreted as "then one should re-evaluate the design of one's server instead of trying to figure out how to spawn "new" threads more efficiently"
in other words, i wasn't talking about you specifically

BanMe
July 13th, 2009, 20:53
*bugfix*1.02bv2
added a Dacl so "everyone" can access event's from win32..
fixed the connection synchronization and client communications bugs..
removed all traces of hope for running a console from native mode.. :[

if your testing this you need to #define _NATIVE_ as a preprocessor if your compiling it subsystem:native..dont do that if your compiling subsystem windows and you want a cool window or console to use..also few other minor fixes..

regards