Page 5 of 6 FirstFirst ... 3456 LastLast
Results 61 to 75 of 81

Thread: Question about stealth methods

  1. #61
    Registered User
    Join Date
    Dec 2001
    Posts
    752
    my 2cp ... they will not put very much effort in this .. perhaps try to find sniffers that are compiled 1:1 from this forum, but not more. Why ? there is no much ROI in this - if they very much complicate the storage of the key they build themself traps that could make EQ not work properly. This would cause much help calls and much trouble ...

    I think they got more or less what they wanted: To cut down the users that have a fully functional SEQ

    /wave

    LordCrush who will have colored dots back soon

  2. #62
    Registered User
    Join Date
    Dec 2001
    Posts
    752
    Hmm i maybe stupid, but i cannot figure out how i have to combine the inputbuffer

    Code:
    BOOL requestDrv(PVOID inAdr, int inSz, PVOID outAdr, int outSz, long IOCtlReq)
    i have to put the function number (in this case 16)
    the offsert and the processname into that buffer at adr inAdr so that i can be extracted here:

    Code:
    ...
    
    	pIOBuffer = (PULONG)pIrp->AssociatedIrp.SystemBuffer;
    
    	// Check to ensure input buffer is big enough to hold a port number and
    	// the output buffer is at least as big as the port data width.
    	// Used terms:
    	// VA - virtual address = normal address used in programs
    	// PA - physical address
    	//
    	// check input & output
    
    	nPort = *pIOBuffer; // Get read type
    
    	// return result
    
    	switch (nPort){
    
    ...
    
    // first parameter (8 bytes) is still function (=16)
    // second parameter (8 bytes) is offset of key
    // third parameter (8 bytes) is process name up to 7 chars (0 at end)
    
             	if (InBufferSize<24) return STATUS_INVALID_PARAMETER;
                    cs= (char*) (pIOBuffer+2);
    	        cs[7]=0; //Get Proc Name mx Len 7
    			pv=myFindProcess(cs); // find process, name in first param
    			nOut=0;
    			if (pv){
    				KeAttachProcess(pv); // attach to process
    				d32=myGetPA((DWORD32)*(pIOBuffer +1)); // first get PA for given VA. For myGetPA see case #13
    				nOut=myReadPA(d32); // then return result read from PA. For myReadPA see case #10
    				KeDetachProcess();
    how is that buffer filled ?

    any hints are greatly apreciated
    -- Lord Crush

    Greater Faydark has to be cleaned from all Elves !

    This is a HOTKEY !!!

  3. #63
    Registered User
    Join Date
    Dec 2001
    Posts
    752
    Lostinspace or anyone of the driver Guru´s are you still around ?

    I have some little questions about the implementation of the usermode sniffer


    Thank you much in advance
    -- Lord Crush

    Greater Faydark has to be cleaned from all Elves !

    This is a HOTKEY !!!

  4. #64
    Registered User
    Join Date
    Nov 2002
    Posts
    36
    Ok Finally got time to work on my little kernnel driver. With Win2K SP3, my build # is 0x893. This is not one of your examples.

    My question is: In Find Process... How do you determine ListEntryOffset and NameOffset values for an OS?

    The values in your example ListEntryOffset=0xA0; NameOffset=0x1FC for Win2K are returning mush.

    Any hints would be appreciated.

  5. #65
    Registered User
    Join Date
    Dec 2001
    Posts
    752
    gawker - i fear lostinspace is not longer on the boards

    i have given up on working for the kerneldriver ... perhaps later again
    -- Lord Crush

    Greater Faydark has to be cleaned from all Elves !

    This is a HOTKEY !!!

  6. #66
    Registered User
    Join Date
    Oct 2002
    Posts
    235

    Comments

    Gawker, I can assure for build 0x893, that the numbers you have 0xA0 and 0X1FC are accurate and work fine, as that is the build I use on all my machines.

    I can not post my version of the driver. I use a one time pad encryption to pass the information in and out of my driver. There is not a one to one relationship between the size of the information passed and the size of the key etc. I also do not include any constants in the driver, and all constants are decrypted on the fly and used then destroyed.

    I highly doubt this is needed, but it took only minutes to add and will help to make the driver much less likely of being listed under the "interesting events" that SOE might report to HQ (like say if they snooped all ioctl calls and noticed their key or eqgame.exe embedded in the passed data.) VERY unlikely, but possible.

    Please post more information about what your problem is, and I will attempt to determine what problem your having.

  7. #67
    Registered User
    Join Date
    Dec 2001
    Posts
    752
    Fester just one quick question ...

    to debug a driver you need 2 boxes and do debuging from the 2nd box ?

    my devicedriver compiles but i get nothing back now i am looking into options to get more information out of the driver.

    Hmm anyone knows if the numbers, that come from lostinspace work for XP Sp1 ?
    -- Lord Crush

    Greater Faydark has to be cleaned from all Elves !

    This is a HOTKEY !!!

  8. #68
    Registered User
    Join Date
    Oct 2002
    Posts
    59
    Gawker, that offset is what i found in few posts around net, but i checked them against some header files like ntifs.h, and they seemed ok.

    I did testing only on XP though, but I think offset is same for XP sp1 too.

    LordCrush, about previous question: make structure with 3 data variables 8 byte long, and fill those parameters according to which function you call. For example :

    typedef struct _input_buff {
    DWORD64 Param1;
    DWORD64 Param2;
    char Param3[8];
    } drvBuff;

    For function 16, you would do something like :
    Param1=16;
    Param2= KeyOffset;
    strcpy(Param3, "EQGAM");

    Also, for debugging, if you have XP, you DO NOT need second box and cables. If you have WinDbg, you have Kernel debug option, and it has two standard options (COM, 1394) that you have under win2k also, and have one additional option on XP: 'Local' - kernel debug on local machine. That is very useful option, for debugging, and also for finding OFFSETS of kernel variables ... if you download all necessary symbol files.

    Another, maybe even better option, is to use OutputDebugString in kernel driver to send your debug messages at various places in your driver code, and to use DebugView from SysInternals to watch those messages.
    Last edited by lostinspace; 02-19-2003 at 05:56 AM.

  9. #69
    Registered User
    Join Date
    Dec 2001
    Posts
    752
    Wooot,

    thank you - i ll try if i get an hour time
    -- Lord Crush

    Greater Faydark has to be cleaned from all Elves !

    This is a HOTKEY !!!

  10. #70
    Registered User
    Join Date
    Oct 2002
    Posts
    235

    WinDBG

    WinDbg is the best method to debug.

    If you can not do that, you can debug by passing information back to your userland program in a format you create.

    You will need to compiling and installing a new device driver with each version of your test driver. Use a bit field (32 bits) of flags or pass enough information that you can return a lot of debug text in a large buffer (8192 bytes or more.)

    There are two ways to check the values for XP sp1. The first is to link against (or just read) the ntifs.h and capture the address (&) of the needed elements in the structure and subtract the address of your test struct beginning. The other is to use a search routine to look for valid values for the elements you need and return these, to which you later use to verify they are correct.

    OK, also more important notes:

    1) You need to make a driver inf file to install a new driver. Installing the .sys file in windows/system is generally not a reliable way to update the loaded driver and can run into problems with windows file protection (or force you to reboot for each new version of the driver.)

    2) You need a new Globally unique identifier because SoE may find it interesting that a large number of people use the same identifier that the published (or sample driver) has. Each new snooper kernel driver person needs a GUID (use GUIDGEN.exe to make yours.)

  11. #71
    Registered User
    Join Date
    Aug 2002
    Posts
    143
    There's no need to use an inf file. You can dynamically load drivers using the same methods used by the utilities at sysinternals.com. Installing utility drivers in system32/drivers is just overkill.

  12. #72
    Registered User
    Join Date
    Nov 2002
    Posts
    36

    Trouble with KeAttachProcess

    I am having trouble with the following section of code.

    if (pv){
    KeAttachProcess(pv); // attach to process
    d32=myGetPA((DWORD32)*(pIOBuffer +2)); //changed to +2 because we are using DWORD64 parameters
    nOut=myReadPA(d32);
    KeDetachProcess();
    }

    I have checked to see that pv is returning different data for each process tested, but nOut returns the same value for all apps.

    It appears that I am not connecting to the process because nOut remains the same if I comment out the KeAttachProcess and KeDetachProcess lines ( I suppose that the values are for my current memory space.

    A few of questions:

    How can I verify if KeAttachProcess was successful?
    How can I verify that pv is returning valid process addresses?
    Is there anything I need to do different since I am making calls to functions to return nOut (am i somehow losing my attachement to process pv)?

    Thanks for any help. I will continute to fiddle with the code and figure what I am doing wrong. BTW thanks, this exercise is teaching much about the DDK.

  13. #73
    Registered User
    Join Date
    Oct 2002
    Posts
    235

    Change

    if (pv){

    typedef struct _input_buff {
    DWORD64 Param1;
    DWORD64 Param2;
    char Param3[8];
    } *idp;

    idp = (typedef struct _input_buff *) pIOBuffer;

    KeAttachProcess(pv); // attach to process
    d32=myGetPA((DWORD32) idp->Param2);
    nOut=myReadPA(d32);
    KeDetachProcess();
    }

    You were always assigning d32 to myGetPA((DWORD32) 0);

    The pIOBuffer is PULONG, so it is 32 bits and that put the source of the *() to the high 32 bits of the Param1 field (which is 0, because Param1=16).

  14. #74
    Registered User
    Join Date
    Oct 2002
    Posts
    235

    Answers

    >> How can I verify if KeAttachProcess was successful?

    If pv is valid, it is very likely working.

    >> How can I verify that pv is returning valid process addresses?

    If build 0x893 and *(((uchar*)pv)+NameOffset) == 'e' then it is valid. ('e' of "eqgame.exe")

    >> Is there anything I need to do different since I am making calls to functions to return nOut (am i somehow losing my attachement to process pv)?

    If Attach succeeded, you can't "lose" attachment unless you call Detach.

    >> It appears that I am not connecting to the process because nOut remains the same if I comment out...

    This is likely because the first 8 bytes (at offset 0x0) in each process is likely the same and there is ALWAYS a current process during kernel calls, it is just that it may not be the process you think. This would be a means by which removing the calls (keattach and kedetach) would result in the same output for nout.

  15. #75
    Registered User
    Join Date
    Oct 2002
    Posts
    59
    I use something like following code.

    If you use following struct as input buffer, and pIOBuffer is of type PULONG :
    ULONG funcNumber;
    ULONG KeyOffset;
    char processName[8];

    case 16: // read key completely, based on app name and offset
    // next 3 lines may vary according to your parameter struct
    DWORD64 fnNum = *(pIOBuffer +0); // function number
    DWORD64 inArg2 = *(pIOBuffer +1); // offset
    char* cs = (char*)(pIOBuffer +2); // process name
    // once parameters are read, following is same
    cs[7]=0;
    DbgPrint("Function number %x", fnNum);
    DbgPrint("Process name %s",cs);
    DbgPrint("Key offset %x",inArg2);
    pv=FindProcess(cs); // find process, name in first param
    if (pv){
    DbgPrint("Process found %s at %p",cs,pv);
    KeAttachProcess(pv); // attach to process
    d32=myGetPA((DWORD32)inArg2); // first get PA for given VA
    DbgPrint("Physicall address=%x",d32);
    nOut=myReadPA(d32); // then return result read from PA
    DbgPrint("read Key=%x",nOut);
    KeDetachProcess();
    }else{
    nOut=0;
    DbgPrint("Not found process!");
    }
    break;


    //----
    If you use this struct as input buffer, and pIOBuffer is of type PULONG :
    DWORD64 funcNumber;
    DWORD64 KeyOffset;
    char processName[8];
    ... then first 3 lines should be:
    DWORD64 fnNum = *(pIOBuffer +0); // function number
    DWORD64 inArg2 = *(pIOBuffer +2); // offset
    char* cs = (char*)(pIOBuffer +4); // process name

    //----
    If you use this struct as input buffer, and pIOBuffer is of type PDWORD64 :
    DWORD64 funcNumber;
    DWORD64 KeyOffset;
    char processName[8];
    ... then first 3 lines should be:
    DWORD64 fnNum = *(pIOBuffer +0); // function number
    DWORD64 inArg2 = *(pIOBuffer +1); // offset
    char* cs = (char*)(pIOBuffer +2); // process name

    //... and so on

    You can set any input structure you like, as long as it starts with function number. First example is in line with last posted code example, where parameters were 4-byte long (ULONG), and pIOBuffer is of type PULONG.

    Use DebugView from Sysinternals to check on data displayed with DbgPrint if you want to test/debug this easily. Once debuged, comment all those DbgPrints ...

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

You may post new threads
You may post replies
You may post attachments
You may edit your posts
HTML code is Off
vB code is On
Smilies are On
[IMG] code is Off