BanMe
June 22nd, 2009, 19:19
Source For Client..
regards BanMe
regards BanMe
View Full Version : Bare Bone Client
dELTA
June 24th, 2009, 11:34
This is a cool project, and I'm looking forward to the possibilities it might open to reversers. 
Can't give much more detailed feedback than that at this point though, sorry about that.
Can't give much more detailed feedback than that at this point though, sorry about that.BanMe
June 24th, 2009, 21:11
yes, the possibilities is what has been driving me to make this project..I also know that I will not be able to fully develop the project, without the help of others and there feedback. I greatly appreciate any and all feedback even if it is not detailed.
regards BanMe
p.s: Ive removed the Current Version of the Client as it unusable.. if you really want it.. pm me
and I will be updating when the new client is ready
regards BanMe
p.s: Ive removed the Current Version of the Client as it unusable.. if you really want it.. pm me
and I will be updating when the new client is ready
BanMe
July 9th, 2009, 21:32
I am working as hard as I can on the new version of the Client which opens events to synchronize Communications, Im having a lot of fun, and doing something I have a passion for.I can't usually pay attention long enough to anything except things that interest me..(comes in handy..around the house..)I know I mess up alot when I post on the board..fast mind slow fingers.. and I really try to fix it.. albeit my many edits :/ so please bear with me as I am definitly not perfect, and do not wish to be. 
updates should be sometime relativly soon..
BanMe
updates should be sometime relativly soon..BanMe
Kayaker
July 9th, 2009, 23:19
No problem BanMe, we're still interested, even if most of us can't follow all the action so far. I've traced through the Sin32 server in Softice with an NMS made with Ida2Sice from the PDB you provided (useful, keep that up).
I certainly don't fully (or even partially) understand it yet, but maybe with the client it will behave as it's supposed to and it will start to make sense. This concept of "plugins" is interesting, I'm wondering what might open up on that front.
Keep up the good work anyway.
I certainly don't fully (or even partially) understand it yet, but maybe with the client it will behave as it's supposed to and it will start to make sense. This concept of "plugins" is interesting, I'm wondering what might open up on that front.
Keep up the good work anyway.
BanMe
July 10th, 2009, 08:47
well Let me see if I can shed some light into that area of "plugins" as hopefully I can show the way I see it..
In the server I create a HandleTable in pass all the handles and Messages into the table.. this all happens before I start "Listening" for connections like every good server should..but Included in the Connections parameters is the handle to the "shared section", this section is where I plan to implement the "plugable" functionality..I got this idea from you excellent posting for the Csrss API calls that you made(Kayaker) and from Windows Local Shellcode injection paper by cesar cerudo.from what I can put together in my head on how csrss executes the "API's" in the "Context" of the calling process, I found this to be "the" more then probable solution.then the only further step I needed to take was to add my love of "the generic redundancy and make it little more dynamic".
So in the End of all this, my foresight leads me to believe we will need a "second server\client relationship" similar to the approach of a debugger but not like one in any way..ioono that sounds fucked up...but The client in time will eventually be made into a "coldpatch" of ntdll. we need to communicate with both the server "to retrieve Data or code" the client previously sent and we need to communicate with the "Client" in order get what we need done.ie we need to be able to give it commands, these commands will then be extrapolated into "MESSAGE's" and sent to the server which will then call the appropriate handler and map code to the "shared section" and then it will need to "call the client thread into the code gracefully and return it back to where it was..(another reason for the implementation of CallOutRecaptureRoutine..)
I hope some of this helps in the understanding..
regards BanMe
In the server I create a HandleTable in pass all the handles and Messages into the table.. this all happens before I start "Listening" for connections like every good server should..but Included in the Connections parameters is the handle to the "shared section", this section is where I plan to implement the "plugable" functionality..I got this idea from you excellent posting for the Csrss API calls that you made(Kayaker) and from Windows Local Shellcode injection paper by cesar cerudo.from what I can put together in my head on how csrss executes the "API's" in the "Context" of the calling process, I found this to be "the" more then probable solution.then the only further step I needed to take was to add my love of "the generic redundancy and make it little more dynamic".
So in the End of all this, my foresight leads me to believe we will need a "second server\client relationship" similar to the approach of a debugger but not like one in any way..ioono that sounds fucked up...but The client in time will eventually be made into a "coldpatch" of ntdll. we need to communicate with both the server "to retrieve Data or code" the client previously sent and we need to communicate with the "Client" in order get what we need done.ie we need to be able to give it commands, these commands will then be extrapolated into "MESSAGE's" and sent to the server which will then call the appropriate handler and map code to the "shared section" and then it will need to "call the client thread into the code gracefully and return it back to where it was..(another reason for the implementation of CallOutRecaptureRoutine..)
I hope some of this helps in the understanding..
regards BanMe
BanMe
July 11th, 2009, 19:57
New Version Of Client 1.1a
This version does synchonize Communications with the Server..
as always bug reports, comments and questions are always welcome!! (they help me think of a valid answer..at the minimum..) lol see download in the Server Thread
enjoy
regards BanMe
This version does synchonize Communications with the Server..
as always bug reports, comments and questions are always welcome!! (they help me think of a valid answer..at the minimum..) lol see download in the Server Thread
enjoy
regards BanMe
BanMe
July 17th, 2009, 22:22
*Current Client Does not work with current Server but will tommorow(small things to do) *
PLease Enjoy the Code for now..Also as a download is the document kleissner
said i could share..(for those who follow..) not much info but its a good piece
regards BanMe
*PLease Enjoy the Code for now..Also as a download is the document kleissner
said i could share..(for those who follow..) not much info but its a good piece
regards BanMe
BanMe
July 18th, 2009, 16:01
what you dont like new hooking ideas... :d
and the initial tests and dry runs for hooking with a system mapped shared section o0
maybe its all lost on non 'dev' type's as I am not a good explainer of what indeed I am trying to accomplish.
so maybe if I explain the code as I 'see' it...(cause out of sight, out of my mind for me xD )
this client Opens Events for Synchronization(Sync) and Communication(Comm) after opening on success of said handles I Set the Event off for Comm,this Event Triggers the server to start Listen(thistimeatleast) the client then creates it own section to use for mapping by the system(sharing is nice ).
this can summed up by the code here:
Then client Connects to the Server this is the fun part..
after NtCompleteConnect is called successfully by the server the client Waits for the comm event to be signaled by the server. this is done to ensure the Server Has Called NtReplyWaitRecievePort is called(otherwise you have client waiting before server waits..(lame..)so..this can be represented as this small part of code..
heres the new bit ive come up with
Upon Successful Reply From The server I then Call a InitUserHooks and pass in the ClientView mapped by the call in the server to NtReplyPort...In InitUserHooks I then use the View to point my hooks to :d this code here represents that..(part of the InitUserHooks routine I use for hooking
I know, I know its not complete yet and Still needs revision but the concept and usage are there
Hopefully in the future I hope to be able to 'attach' the section to the PE during runtime so no "out of image range" detections work.. I could also forge my own entry into peb..and then hide myself after the hooks are installed.but that is all superficial as hotpatchs are going to be in the 3rd or 4th revision of the client '_' so maybe something to look forward to..
Iono its all up to these fun test's and outcomes and hopefully sometime a little feedback :]
regards BanMe
and the initial tests and dry runs for hooking with a system mapped shared section o0
maybe its all lost on non 'dev' type's as I am not a good explainer of what indeed I am trying to accomplish.
so maybe if I explain the code as I 'see' it...(cause out of sight, out of my mind for me xD )
this client Opens Events for Synchronization(Sync) and Communication(Comm) after opening on success of said handles I Set the Event off for Comm,this Event Triggers the server to start Listen(thistimeatleast) the client then creates it own section to use for mapping by the system(sharing is nice ).
this can summed up by the code here:
Code:
RtlInitUnicodeString(&Unicode,LpcCommEvent);
InitializeObjectAttributes(&oa,&Unicode,OBJ_KERNEL_HANDLE,0,0);
Status = NtOpenEvent(&CommEvent,EVENT_ALL_ACCESS,&oa);
if!NT_SUCCESS(Status))
{
__leave;
}
RtlInitUnicodeString(&Unicode,LpcEventName);
InitializeObjectAttributes(&oa,&Unicode,OBJ_KERNEL_HANDLE,0,0);
Status = NtOpenEvent(&SyncEvent,EVENT_ALL_ACCESS,&oa);
if(!NT_SUCCESS(Status))
{
__leave;
}
Status = NtSetEvent(CommEvent,&EventState);
if(!NT_SUCCESS(Status))
{
return STATUS_UNSUCCESSFUL;
}
Then client Connects to the Server this is the fun part..
after NtCompleteConnect is called successfully by the server the client Waits for the comm event to be signaled by the server. this is done to ensure the Server Has Called NtReplyWaitRecievePort is called(otherwise you have client waiting before server waits..(lame..)so..this can be represented as this small part of code..
Code:
NtWaitForSingleObject(CommEvent,FALSE,0);
InitializeMessageHeader(&MessageHeader, sizeof(PORT_MESSAGE), LPC_NEW_MESSAGE+11);//10 defined so imma use 11 ..
Status = NtRequestWaitReplyPort(PortHandle,&MessageHeader,&MessageHeader);
if(!NT_SUCCESS(Status))
{
RtlInitUnicodeString(&Unicode,L"NtRequestWaitReplyPort Status:"
__leave;
}
heres the new bit ive come up with
Upon Successful Reply From The server I then Call a InitUserHooks and pass in the ClientView mapped by the call in the server to NtReplyPort...In InitUserHooks I then use the View to point my hooks to :d this code here represents that..(part of the InitUserHooks routine I use for hooking
Code:
ULONG SizeFirstHk = *(ULONG*)CodeView.ViewBase;
ULONG Hook_BaseThreadStartThunk = (ULONG)CodeView.ViewBase+4;
ULONG Hook_BaseProcessStartThunk = Hook_BaseThreadStartThunk + SizeFirstHk;
__asm
{
pushad
lds esi, Addr_BaseThreadStartThunk
les edi, CodBaseThread
mov ecx,0x5
rep movsb
mov edi, Addr_BaseThreadStartThunk
mov eax, Hook_BaseThreadStartThunk
sub eax, edi
sub eax,5
mov byte ptr [edi+0], 0xE9// ; jmp short
mov dword ptr [edi+1], eax
mov esi, Addr_BaseProcessStartThunk
les edi, CodBaseProcess
mov ecx,0x5
rep movsb
mov edi, Addr_BaseProcessStartThunk
mov eax, Hook_BaseProcessStartThunk
sub eax,edi
sub eax,5
mov byte ptr [edi+0],0xE9
mov dword ptr [edi+1],eax
popad
}
I know, I know its not complete yet and Still needs revision but the concept and usage are there
Hopefully in the future I hope to be able to 'attach' the section to the PE during runtime so no "out of image range" detections work.. I could also forge my own entry into peb..and then hide myself after the hooks are installed.but that is all superficial as hotpatchs are going to be in the 3rd or 4th revision of the client '_' so maybe something to look forward to..
Iono its all up to these fun test's and outcomes
and hopefully sometime a little feedback :] regards BanMe
Powered by vBulletin® Version 4.2.2 Copyright © 2018 vBulletin Solutions, Inc. All rights reserved.