Page 3 of 6 FirstFirst 12345 ... LastLast
Results 51 to 75 of 129

Thread: Use your hardware mouse!

  1. #51
    Join Date
    Oct 2012
    Posts
    1,258
    Mentioned
    40 Post(s)
    Quoted
    588 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    What is this??? The source is already there.. as for compiling it.. if you guys actually wrote a rootkit that does what you say it does, then there's no need for me to help you compile the above because you have enough skills to write your own..

    Attachment 28135


    Also, just stick it in any C++ compiler and hit the play/compile button. It'll work just fine. CodeBlocks + Mingw works as well.
    I've installed codeblocks + mingw, but the "stick it in any c++ compile and hit compile" doesn't seem to be ringing true for me.
    It (the code) terminates quickly, the first issue being that it's unable to find winternl.h that's being called on line 2.
    Build Log: http://i.imgur.com/Xqrd1C5.png
    Do you see any novice mistakes (I am an aboslute novice) being made there that are resulting in this issue? Do you have any suggestions on what I should do to try to get it to compile based on that build log?

    I assume this is an issue of improperly setting up and using codeblocks or mingw since it feels to me like you're saying it should work by default assuming the c++ compiler is setup correctly. Though I do still get the feeling that it's something else, e.g. due to the OS lacking relevant files due to being a different OS version or simply having not updated something. Which versions of windows (7+) should this code work on by default & are there any specific things that are assumed to be installed & updated that may not be by default?

  2. #52
    Join Date
    May 2017
    Posts
    22
    Mentioned
    1 Post(s)
    Quoted
    15 Post(s)

    Default

    It compiles whith vs2015 or vs2017 or requires earlier versions?

  3. #53
    Join Date
    Jul 2009
    Posts
    166
    Mentioned
    5 Post(s)
    Quoted
    69 Post(s)

    Default

    I found this on teh net; https://msdn.microsoft.com/en-us/library/ms703320.aspx Hm can GetMessageExtraInfo haxed?

  4. #54
    Join Date
    May 2015
    Posts
    1
    Mentioned
    0 Post(s)
    Quoted
    1 Post(s)

    Default

    If you are on windows machines, you can use remote desktop (not full screen but windowed) and fake mouse/keyboard events from connected machine, will get 'converted' into real mouse/keyboard events on the remote desktop.
    Dont know if this is usefull

  5. #55
    Join Date
    Feb 2007
    Location
    Colorado, USA
    Posts
    3,716
    Mentioned
    51 Post(s)
    Quoted
    624 Post(s)

    Default

    Quote Originally Posted by Zulu View Post
    If you are on windows machines, you can use remote desktop (not full screen but windowed) and fake mouse/keyboard events from connected machine, will get 'converted' into real mouse/keyboard events on the remote desktop.
    Dont know if this is usefull
    they're as "real" as what we already use
    The only true authority stems from knowledge, not from position.

    You can contact me via matrix protocol: @grats:grats.win or you can email me at the same domain, any user/email address.

  6. #56
    Join Date
    May 2017
    Posts
    22
    Mentioned
    1 Post(s)
    Quoted
    15 Post(s)

    Default

    You will need rootkit to hide remote desktop because is big flag, i give process hide rootkit to whoever learn me how to compile the script Brandon provided or give me the already compiled version hiding virtual input, send PM or if you post it here i post rootkit here for everybody, i suspect code provided by Brandon have bugs

  7. #57
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by pipilica View Post
    You will need rootkit to hide remote desktop because is big flag, i give process hide rootkit to whoever learn me how to compile the script Brandon provided or give me the already compiled version hiding virtual input, send PM or if you post it here i post rootkit here for everybody, i suspect code provided by Brandon have bugs


    Lol.. If you know how to write a RootKit, you should have no problem compiling the code I posted.. and yes I am 100% sure it works and compiles.. After all, "Winternl.h" is a valid Windows Internal header as per:

    https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx


    Anyway guys, if it doesn't compile, your Mingw it outdated or bugged. I know for sure @Kasi; was able to compile it and confirmed it working with RS.


    EDIT: I will upload a compiled version later or upload the full project I guess..


    Compiles for me with Mingw on Windows 10 Pro: https://i.pictr.io/dTTQJ.png

    Last edited by Brandon; 06-15-2017 at 12:33 AM.
    I am Ggzz..
    Hackintosher

  8. #58
    Join Date
    Dec 2007
    Posts
    2,112
    Mentioned
    71 Post(s)
    Quoted
    580 Post(s)

    Default

    Just re-iterating on what Brandon said. If you can write your own root-kit, you can probably write your own simple mouse/keyboard detour.

    For anyone wanting to download a hypervisor rootkit. Don't get it from some dodgy guy advertising on a forum. Check out Blue Pill/SubVirt.

    Can confirm, the code def compiles.

  9. #59
    Join Date
    Jul 2009
    Posts
    166
    Mentioned
    5 Post(s)
    Quoted
    69 Post(s)

    Default

    You don't need to compile Brandons code, it doesn't do anything useful. It only detects if input is hardware or virtual.
    But code to hax somehow windows GetMessage msg things would be nice. Windows driver that would take software input and putout hardware mouse movements would be good to.
    Edit:But there is a code to mess around mouse flags erm.. things.

  10. #60
    Join Date
    Dec 2010
    Posts
    483
    Mentioned
    30 Post(s)
    Quoted
    328 Post(s)

    Default

    Quote Originally Posted by pipilica View Post
    You will need rootkit to hide remote desktop because is big flag, i give process hide rootkit to whoever learn me how to compile the script Brandon provided or give me the already compiled version hiding virtual input, send PM or if you post it here i post rootkit here for everybody, i suspect code provided by Brandon have bugs
    Nobody help this goof monkey.

    unknown.png

  11. #61
    Join Date
    May 2017
    Posts
    22
    Mentioned
    1 Post(s)
    Quoted
    15 Post(s)

    Default

    Quote Originally Posted by the bank View Post
    Nobody help this goof monkey.

    unknown.png
    You offended me first in PM, is not normal to get reply?

  12. #62
    Join Date
    Jul 2009
    Posts
    166
    Mentioned
    5 Post(s)
    Quoted
    69 Post(s)

    Default

    Ehm I am not interested in drama && off-topic.

    So after messing around with Brandons code here is result:
    Code:
    LRESULT CALLBACK MyKeyboardHook(int nCode, WPARAM wParam, LPARAM lParam)
    {	
    	if (nCode == HC_ACTION)
    	{
    		KBDLLHOOKSTRUCT* keyboardHookPointer = (KBDLLHOOKSTRUCT *)lParam; //Cast.
    		if ((keyboardHookPointer->flags & LLKHF_LOWER_IL_INJECTED) || (keyboardHookPointer->flags & LLKHF_INJECTED))
    		{
    			cout << "Fake \n";
    		}
    		else {
    			cout << "Hardware \n";
    		}
    
    		keyboardHookPointer->flags &= ~LLKHF_LOWER_IL_INJECTED; //Remove flag.
    		keyboardHookPointer->flags &= ~LLKHF_INJECTED; //Remove flag.
    	} 
    
    	if (nCode == HC_ACTION)
    	{
    		KBDLLHOOKSTRUCT* keyboardHookPointer = (KBDLLHOOKSTRUCT *)lParam; //Cast.
    		if ((keyboardHookPointer->flags & LLKHF_LOWER_IL_INJECTED) || (keyboardHookPointer->flags & LLKHF_INJECTED))
    		{
    			cout << "Fake2 \n";
    		}
    		else {
    			cout << "Hardware2 \n";
    		}
    	}
    
    	return CallNextHookEx(_hook, nCode, wParam, lParam); //Give Jagex the modified parameters.
    }


    Second is check did it actually changed anything. In picture there some keyboard input and windows on-screen virtual input it seems to be changed. Does it actually changes input flags and send those modified flags back to windows=?
    It currently intercepts all keyboard messages. Is it bad in someway?
    Is while(GetMessage())loop needed? I mean its already hooked. What is its purpose?

  13. #63
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by alar82 View Post
    You don't need to compile Brandons code, it doesn't do anything useful.

    -_- If you don't even know what GetMessage is for in a system wide hook, how can you call it useless.. I actually lol'd



    Second is check did it actually changed anything. In picture there some keyboard input and windows on-screen virtual input it seems to be changed. Does it actually changes input flags and send those modified flags back to windows.
    Yes. It removes the injected flags and passes on the rest of flags to the queue. You can test this by adding a second hook and see if the second hook gets the injected flags


    It currently intercepts all keyboard messages. Is it bad in someway?
    Believe it or not, Jagex already does this in the game.. though, their callback is empty. Fraps FPS does this as well. It isn't harmful but it helps to figure out what windows you actually want it to hook instead of hooking all.


    Is while(GetMessage())loop needed? I mean its already hooked. What is its purpose?
    Without a System Message Queue OR a Message Only Window (`CreateWindow("SYSTEM_MESSAGE_QUEUE", 0, 0, 0, 0, 0, 0, HWND_MESSAGE, 0, 0, 0)`), your hooks will NEVER execute. You'd get no messages and no callbacks. https://stackoverflow.com/questions/...-message-queue
    Last edited by Brandon; 06-16-2017 at 01:59 AM.
    I am Ggzz..
    Hackintosher

  14. #64
    Join Date
    Jul 2009
    Posts
    166
    Mentioned
    5 Post(s)
    Quoted
    69 Post(s)

    Default

    If I run 1 simba hooking before and 2nd after, they seem to get keyboard events same time and both are same(fake or other). Who gets priority? How to get priority over other applications(who maybe want to install they keyboard hook too)?
    Like if rs client had WH_MOUSE_LL hooked and checkin LLMHF_INJECTED flag? Who, how, what :I

    Edit: Logic would dictate that who ever first runs gets priority over others. But this dosent seem to be case here. Installing multiple hooks in 1 plugin resulted lastone to get piority. It seems I must run rs 1st then my plugin, fine
    While looking around in internet I did find this blog thing, its beyond me but maybe it provides interesting reading:


    antiflag.sys - Writing a kernel driver to remove the LLKHF_INJECTED flag
    ------------------------------------------------------------------------

    ################################################## ###################
    written by UsualSuspect for reddit.com/r/reverseengineering, 11/29/10
    May be copied or redistributed as long as the full document as it is
    stays intact.
    ################################################## ###################

    Introduction
    ------------

    A while ago I came across a game that checked for injected keyboard input. It did so by the probably well-known method of using SetWindowsHookEx() with a hook type of WH_KEYBOARD_LL. When a key is pressed, Windows notifies all hooks and supplies the following data structure:


    typedef struct tagKBDLLHOOKSTRUCT {
    DWORD vkCode;
    DWORD scanCode;
    DWORD flags;
    DWORD time;
    ULONG_PTR dwExtraInfo;
    } KBDLLHOOKSTRUCT, *PKBDLLHOOKSTRUCT, *LPKBDLLHOOKSTRUCT;

    The only field of interest for us is flags. When keyboard input is generated by a program using SendInput() (amongst others, as far as I know), Windows sets a flag, which is LLKHF_INJECTED telling the hook procedure the origin of the given input is a program. The problem now is that if we want to cheat in a game, we usually want to fake input such as mouse movements or key presses. Using this hook though, the game would be able to find out we're cheating and possibly ban us. So I had to find I a way to remove this flag. There are dozens of spots where this could be done. We could for example hook the LowLevelKeyboardProc, remove the flag and pass the data on to the original proc.

    The target I was writing the hack for was very careful though and checked each and every function for hooks. It hashed the memory, it made sure system DLLs (such as user32.dll which is of interest for us) weren't tampered with and so on. Although all of this took place in usermode and we could simply defeat all detection mechanisms in place, I decided to take another route. What I wanted to do is write a kernel driver to deal with this issue and thus transparently (for user mode applications) remove the flag. This way, I didn't have to deal with any detection mechanism the game implemented now or in the future.

    Kernel land unfortunately was completely new to me, as I restricted my reverse engineering and hacking exclusivly to user mode so I had to find a way to get started. At this point, I'd like to point out I'm probably wrong about a few assumptions I made and I may state things that are simply wrong in this paper. Feel free to correct me, if this is the case. In the end though, my kernel driver worked, so I was satisfied.

    Getting started
    ---------------

    The goal was writing a kernel driver to globally remove the LLKHF_INJECTED flag so no game or application was enable to distinguish between regular and injected input. Because I've never done kernel stuff I had to read up on it and got the book "Rootkits: Subverting the Windows kernel" by Hoglund and Butler. There I learned how to set up my build environment, how to create the most basic driver and other important things like that. The book is what got me started and I heartily recommend it to readers wanting to do the same. Although I didn't have any hands-on practice with kernel mode code, I knew about a few things in theory, such as SSDT hooks, interrupt hooks, problems that may arise from paging (meaning memory could be paged out, that is written to the pagefile on the disk, and not be available) et cetera.

    With all of this in mind, I set up my environment which consisted of a plain XP SP2 installed on a VirtualBox to which I connected with kd (the kernel debugger from Microsoft found in the Debugging Tools for Windows) using VirtualKD, which is a modification for VMWare/VirtualBox to allow for (way?) faster data transfer. You want to do the same as writing kernel code is tedious and an error usually means a bluescreen. There is no way I would have gone through with it if I didn't have a virtual machine to test my code.

    In order to quickly test if I was successful, I wrote a little tool that installed a global keyboard hook and just tells us if the given input was injected (= flag set) or not, so I didn't have to fire up the game all the time.

    Finding the weak spot
    ---------------------

    Now that my setup was running, I needed to find where to "apply the wrench", i.e. where to apply hooks to patch out the LLKHF_INJECTED flag. To do so, I followed the obvious path of checking what SetWindowsHookEx() does. Following xrefs inside it, I quickly found out it jumps to the kernel counterpart of user32.dll, which happens to be win32k.sys, the kernel driver for GUI-related code.

    .text:77D3E60D _NtUserSetWindowsHookEx@24 proc near ; CODE XREF: _SetWindowsHookEx(x,x,x,x,x,x)+2Ep
    .text:77D3E60D mov eax, 1225h
    .text:77D3E612 mov edx, 7FFE0300h
    .text:77D3E617 call dword ptr [edx]
    .text:77D3E619 retn 18h
    .text:77D3E619 _NtUserSetWindowsHookEx@24 endp

    SetWindowsHookEx() goes through a few calls and ends up here. What this does is call the kernel, so I fired up IDA and checked win32k.sys. This all was purely random, I just followed xrefs, looked at the exports/functions (let IDA download symbols!) etc. In the end I found a few interesting functions, for example:

    NtUserCallNextHookEx
    xxxCallNextHookEx
    xxxCallNextHookEx2

    and the key function turned out to be

    xxxHkCallHook

    There I found several calls that looked interesting, and one in particular was:

    .text:BF9073E5 call fnHkINLPKBDLLHOOKSTRUCT(x,x,x,x,x)

    KBDLLHOOKSTRUCT? Now that sounds exactly like the struct we want to modify! The function itself is rather short and doesn't really do more than calling KeUserModeCallback(). KeUserModeCallback() is the function the kernel uses to call (as the name implies) callbacks in the user mode.

    The call:

    .text:BF92A693 lea eax, [ebp+output_len]
    .text:BF92A696 push eax ; output_len
    .text:BF92A697 lea eax, [ebp+output]
    .text:BF92A69A push eax ; output
    .text:BF92A69B push 36 ; inputlen
    .text:BF92A69D lea eax, [ebp+input]
    .text:BF92A6A0 push eax ; input
    .text:BF92A6A1 push 2Dh ; Call 77D5894D @ User32.dll
    .text:BF92A6A1 ; = DispatchHook()
    .text:BF92A6A3 call ds:KeUserModeCallback(x,x,x,x,x)

    Thanks to some paper at UNINFORMED, I found the parameters for this function. 0x2D is the number of the user mode callback and it turned out to be user32!DispatchHook(). So if you feel like going the easy way, just modify this function in user mode to patch out the flag and you're done. Of course, this would be to easy.

    So what do we do now? There are a handful of functions used in calling hooks. One function, fnHkINLPKBDLLHOOKSTRUCT() most probably is passed a KBDLLHOOKSTRUCT which should contain our flag. If this is the case, we found the weak spot where the actual hook struct is passed through to the user mode. That means we could hook this function, patch out the flag and the structure would end up in user mode with the LLKHF_INJECTED flag removed. To verify this idea, I fired up WinDbg and tried to look at the code.

    kd> u BF92A6A3
    win32k!fnHkINLPKBDLLHOOKSTRUCT+0x4c:
    bf92a6a3 ?? ???
    ^ Memory access error in 'u BF92A6A3'

    Huh? But this is inside win32k.sys, just show me the call already? As it turns out, this wouldn't be as easy as that. After googling my fingers sore, asking lots of sources and more, someone in /r/reverseengineering enlightened me. The problem is that win32k.sys isn't mapped into all processes. So if I happen to break in a process that doesn't have a GUI, there will be no win32k.sys mapped into the process' memory and I can't disassemble it. The solution is simple. Find a GUI process, set the process context to it and you're good. This is how it's done:

    kd> !process 0 0
    **** NT ACTIVE PROCESS DUMP ****

    ...

    PROCESS 86565020 SessionId: 0 Cid: 0250 Peb: 7ffdf000 ParentCid: 0178
    DirBase: 0bc7e000 ObjectTable: e100d928 HandleCount: 334.
    Image: csrss.exe

    !process 0 0 shows the running processes. From what I learned later on, csrss.exe is a GUI process, so we can just use its context. To switch, we simply do

    kd> .process 86565020
    Implicit process is now 86565020
    WARNING: .cache forcedecodeuser is not enabled

    And try disassembling the call again:

    kd> u BF92A6A3
    win32k!fnHkINLPKBDLLHOOKSTRUCT+0x4c:
    bf92a6a3 ff1534aa98bf call dword ptr [win32k!_imp__KeUserModeCallback (bf98aa34)]
    bf92a6a9 8bf0 mov esi,eax
    bf92a6ab e88a63edff call win32k!EnterCrit (bf800a3a)
    ...

    Nice! So now, let's place a bp (which can be done without changing the context to a GUI process, btw.) and examine the input buffer passed.

    kd> bp bf92a6a3
    WARNING: Software breakpoints on session addresses can cause bugchecks.
    Use hardware execution breakpoints (ba e) if possible.
    kd> g
    Breakpoint 1 hit
    win32k!fnHkINLPKBDLLHOOKSTRUCT+0x4c:
    bf92a6a3 ff1534aa98bf call dword ptr [win32k!_imp__KeUserModeCallback (bf98aa34)]

    Alright, right before the call. We know KeUserModeCallback() gets 5 arguments, so let's see what is on the stack. The first should be 0x2D for DispatchHook(), followed by the address to the input buffer.

    kd> dd esp L5
    ed63faec 0000002d ed63fb0c 00000024 ed63fb38
    ed63fafc ed63fb34

    which is true. So now let's see what is in the input buffer.

    kd> dd ed63fb0c L8
    ed63fb0c 000d0000 00000100 00401320 77d26df4
    ed63fb1c 00000025 00000012 00000010 00019816

    I don't know what the first 4 DWORDs are but the next 4 DWORDs look promising. My tool sends an injected VK_LEFT which is 0x25. 0x12 is the scancode (which can differ, it depends on quite a few things from what I read) and the 3rd DWORD should be the flags then. If we search for the value of LLKHF_INJECTED, we will see that it is the value 0x10, which is awesome. Obviously, we know the 7th DWORD in the input buffer is the flags field. So now we know where to apply our hook and where to find the data we need to modify.

    Writing the kernel driver
    -------------------------

    Writing the kernel driver was obviously the most difficult part for me. Finding the weak spot was (even though it probably was not more than educated guesses) rather easy. Writing code that does the patching though is more difficult. The first issue that arises is the one we encountered before: If our kernel driver needs to modify code inside win32k.sys, we have to run inside a process context of a GUI process. Thus, we need to be able to find a GUI process and eventually attach to it.

    Finding a GUI process
    ---------------------

    In theory, finding a GUI process is easy. The process list on Windows is a double linked list of EPROCESS structs. If you want to see what it looks like, type

    kd> dt nt!_EPROCESS
    +0x000 Pcb : _KPROCESS
    ...
    +0x088 ActiveProcessLinks : _LIST_ENTRY
    ...
    +0x130 Win32Process : Ptr32 Void

    Two important fields of the structure are listed. The first one being ActiveProcessLinks which is a structure of two pointers, flink (front link) and blink (back link). One thing I had to learn by mistake was that the points inside the LIST_ENTRY structure point to the ActiveProcessLinks field, and not at the beginning of the _EPROCESS structure. More on that later.
    The second important field is Win32Process which points to some Win32Process structure or something if (and only if!) the process is a GUI process. Now we just need to find some handle (any handle) to an _EPROCESS structure, walk the double linkest list until we find one with a Win32Process field different from 0. Getting a handle to an _EPROCESS structure is easy, we can just use PsGetCurrentProcess().

    Without further ado, here is the code:

    PEPROCESS FindGUIProcess()
    {
    ULONG CurProc;

    CurProc = PsGetCurrentProcess();
    DbgPrint("Starting at %08x\n",CurProc);

    while(*(ULONG*)(CurProc+EPROCESS_WIN32PROC_OFFSET) == 0)
    {
    CurProc = *(ULONG*)(CurProc+EPROCESS_LINK_OFFSET);
    CurProc -= EPROCESS_LINK_OFFSET;
    DbgPrint("Next proc at %08x\n",CurProc);
    }

    //CurProc is a GUI proc!
    return CurProc;
    }

    We get ourselves a handle to the current process and then start the while loop. EPROCESS_LINK_OFFSET is 0x88 for XP SP2 as we could see above. EPROCESS_WIN32PROC_OFFSET is 0x130 as we've seen above, too. If it is 0, the process is not a GUI process, so we need to go to the next entry. We do so by walking through the flink field of ActiveProcessLinks to the next process and then subtract the offset of it because as said above, flink points to the next process' ActiveProcessLinks and NOT to the start of the _EPROCESS structure. We do this as long as Win32Process stays 0. This could possibly lead to an infinite loop but I doubt this scenario ever happens, as csrss.exe is a GUI process, so I skipped adding checks for the case where we traversed the entire linked list without finding a GUI process. It works, that's what matters.

    Now that we have a GUI process, we need to attach. This is simple:

    KAPC_STATE ApcState;

    KeStackAttachProcess(GUIProcess,&ApcState);

    //do stuff

    KeUnstackDetachProcess(&ApcState);

    The next thing to do is "do stuff".

    Applying the hook
    -----------------

    Now that we made sure we're running in a GUI process' context, we have to apply the actual hook. To make life easy, I decided not to hook KeUserModeCallback() (could be done with a SSDT hook) because then I'd have to check if it's a call for DispatchHook() and more important, we'd be called all the time because this is the single point for the kernel to call the user mode. I didn't want to interfer with that. I wanted to do the inline hook.

    If we look at the disassembly again, the call reads:

    kd> u BF92A6A3
    win32k!fnHkINLPKBDLLHOOKSTRUCT+0x4c:
    bf92a6a3 ff1534aa98bf call dword ptr [win32k!_imp__KeUserModeCallback (bf98aa34)]

    It's a total of 6 bytes. FF 15 being the opcode for call, and the following 4 bytes, 0xBF98AA34 (remember, little endian) being the pointer to the location to call. We want to hijack this call.

    To do so, we'd fill it with the bytes "E8 DD CC BB AA", which is a call to AddrOfNextInstruction+0xAABBCCDD. But this call is only 5 bytes long, the original is 6 bytes. Therefore, we have to insert a nop, and the offset we have to stamp in for 0xAABBCCDD is relative to this nop.

    The hook would be:

    char hook[6] = "\xE8\x00\x00\x00\x00\x90";

    And the code to calculate the offset relative to the nop and the stamping in then is:

    const ULONG HookAddr = 0xBF92A6A3;
    *(ULONG*)(hook+1) = (ULONG)WrappedKeUserModeCallback-(HookAddr+5);

    Now we have the 6 bytes which will overwrite the existing six bytes at 0xBF92A6A3 (=HookAddr). But first, we have to gain rights to write to this address. To gain these rights, there are several ways, one being the evil cr0 trick which is a csr (CPU specific register, or something like that) containing information regarding the memory protection. There, you simply unset a flag and may write to wherever you desire. This is dirty (I've been told, it globally removes write protection!) and because the cr0 register belongs to a CPU, you will run into trouble with multi-cores (because each core has its own context), so we don't use that.

    We do it the proper way:

    PMDL pmdlHook;
    PVOID *MappedHook;

    pmdlHook = MmCreateMdl(NULL,HookAddr,6);
    MmProbeAndLockPages(pmdlHook,KernelMode,IoModifyAc cess);
    MappedHook = MmGetSystemAddressForMdlSafe(pmdlHook,HighPagePrio rity);

    MappedHook now points to the same memory as 0xBF92A6A3, the location where we want to write 6 bytes, but with writing rights. Before writing them, we save the original 6 bytes, in case we want to unload the driver (which I recommend for development):

    //Save original data
    RtlCopyMemory(SavedCode,MappedHook,6);

    //Write in our hook
    RtlCopyMemory(MappedHook,hook,6);

    What's left is implementing the WrappedKeUserModeCallback() to remove the evil LLKHF_INJECTED flag:

    NTSTATUS WrappedKeUserModeCallback (
    IN ULONG ApiNumber,
    IN PVOID InputBuffer,
    IN ULONG InputLength,
    OUT PVOID *OutputBuffer,
    IN PULONG OutputLength
    )
    {
    PULONG p = InputBuffer;
    DbgPrint("Flags: %08x\n",p[6]);

    //Remove the injected flag
    p[6] &= ~LLKHF_INJECTED;

    return OrigKeUserModeCallback(ApiNumber,InputBuffer,Input Length,OutputBuffer,OutputLength);
    }

    Because this function is only called at the single location we hooked, we don't have to make sure the caller is right and just can assume the input buffer is as specified above. The flags are the 7th DWORD, where we simply patch out the LLKHF_INJECTED and pass it on to the original KeUserModeCallback() which will then call DispatchHook() and pass the modified structure to all LowLevelKeyboardProcs. The address of the original KeUserModeCallback() can be read from 0xBF98AA34 as this is the address in win32k.sys' import table. I just hardcoded the address. This is bad practice, but again, it works (for XP SP2).

    That's it. Before any low level keyboard hook is called, it will go through our code which makes sure, no LLKHF_INJECTED flag is set, so: Mission Accomplished!


    Conclusion
    ----------

    We now have a functioning kernel driver to remove LLKHF_INJECTED flags, so no user land program should be able to distinguish injected input from regular input and therefore we can cheat as much as we want. To do this, we reverse engineered user32.dll as well as its kernel counterpart, win32k.sys to find a weak spot where the KBDLLHOOKSTRUCT is passed through, so we can patch out the injected flag. After we found the weak sport, we implemented the kernel driver to do just that. To be able to write our hook, we had to find a GUI process and attach to it, otherwise we wouldn't be able to access win32k.sys. Having solved this issue, we wrote a wrapper for KeuserModeCallback() that removes the injected flag and made sure the code flow went through at the right time.

    Last words
    ----------

    Kernel driver development is frustrating. The debugging cycles are longer, because a mistake means a reboot. Documentation is sparse and finding the information you want is difficult. If you spent 30% of your time researching before coding hacks in user mode, you could at least double the research time for kernel mode, from my experience.

    Regarding the final code: It's not nice. We use magic numbers, that only work for a single release (in this case, again, XP SP2) and we are most probably not thread safe. Especially the RtlCopyMemory() to write hook may lead to a bluescreen with the "right" timing. Thing is, it works and it's only a single point of failure. If loading the kernel driver works without a bluescreen, you're good. The above mentioned Rootkit book has a chapter on synchronisation issues and how to handle them, but to be honest, I was to lazy to write it as of yet. If you want to port this code to Win 7, you just need to check WinDbg for the offsets and disassemble win32k.sys for the new weak spot.

    I decided against releasing full source code. I'm confident that readers that want to get it done can get it done now. If there are questions or corrections, feel free to contact me!

    References
    ----------

    - [1] http://www.awarenetwork.org/etc/beta/?x=1
    - "Rootkit: Subverting the Windows kernel" by Hoglund and James Butler
    - sourcecode for other rootkits
    - A lot of Google-fu
    No I am not writing kernel driver But I want to my hook stay at top.

  15. #65
    Join Date
    Feb 2011
    Location
    The Future.
    Posts
    5,600
    Mentioned
    396 Post(s)
    Quoted
    1598 Post(s)

    Default

    Quote Originally Posted by alar82 View Post
    If I run 1 simba hooking before and 2nd after, they seem to get keyboard events same time and both are same(fake or other). Who gets priority? How to get priority over other applications(who maybe want to install they keyboard hook too)?
    Like if rs client had WH_MOUSE_LL hooked and checkin LLMHF_INJECTED flag? Who, how, what :I

    Edit: Logic would dictate that who ever first runs gets priority over others. But this dosent seem to be case here. Installing multiple hooks in 1 plugin resulted lastone to get piority. It seems I must run rs 1st then my plugin, fine
    While looking around in internet I did find this blog thing, its beyond me but maybe it provides interesting reading:

    No I am not writing kernel driver But I want to my hook stay at top.

    Yes, but if you are detouring the function that creates these hooks (IE: You are hooking SetWindowsHookEx), then you are essentially in control if you've done it first because all future hooks and callbacks go through you. This means, you are free to do whatever you like.. even denying them or further trampolining them.


    Flow 1:

    Code:
    1. Run Process with injected module/plugin or suspended injection. For SMART, it loads plugins before RS so there's no need to run in suspended more or inject.
    
    2. Hook `SetWindowsHookEx` -> `CustomSetWindowsHookEx`.
    
    3. In `CustomSetWindowsHookEx`, detour the callback of the low-level hooks and call `SetWindowsHookEx`.
    
    4. In the `MyMouseHookCallback` and `MyKeyboardHookCallback`, remove all injected flags.
    
    5. Call original `MouseHookCallback` and `KeyboardHookCallback`.
    
    6. Continue Process.

    Flow 2:
    Code:
    1. Run Process with injected module/plugin or suspended injection. For SMART, it loads plugins before RS so there's no need to run in suspended more or inject.
    
    2. Hook `CallNextHookEx` -> `CustomCallNextHookEx`
    
    3. In `CustomCallNextHookEx`, remove injected flags if they exist and call the original `CallNextHookEx`.
    
    4. Continue Process.

    The reason that guy created a Kernel Driver was because his hooks were being detected and he didn't want to deal with the detection or the removal of it.
    I am Ggzz..
    Hackintosher

  16. #66
    Join Date
    Sep 2012
    Location
    Netherlands
    Posts
    2,752
    Mentioned
    193 Post(s)
    Quoted
    1468 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    Yes, but if you are detouring the function that creates these hooks (IE: You are hooking SetWindowsHookEx), then you are essentially in control if you've done it first because all future hooks and callbacks go through you. This means, you are free to do whatever you like.. even denying them or further trampolining them.


    Flow 1:

    Code:
    1. Run Process with injected module/plugin or suspended injection. For SMART, it loads plugins before RS so there's no need to run in suspended more or inject.
    
    2. Hook `SetWindowsHookEx` -> `CustomSetWindowsHookEx`.
    
    3. In `CustomSetWindowsHookEx`, detour the callback of the low-level hooks and call `SetWindowsHookEx`.
    
    4. In the `MyMouseHookCallback` and `MyKeyboardHookCallback`, remove all injected flags.
    
    5. Call original `MouseHookCallback` and `KeyboardHookCallback`.
    
    6. Continue Process.

    Flow 2:
    Code:
    1. Run Process with injected module/plugin or suspended injection. For SMART, it loads plugins before RS so there's no need to run in suspended more or inject.
    
    2. Hook `CallNextHookEx` -> `CustomCallNextHookEx`
    
    3. In `CustomCallNextHookEx`, remove injected flags if they exist and call the original `CallNextHookEx`.
    
    4. Continue Process.

    The reason that guy created a Kernel Driver was because his hooks were being detected and he didn't want to deal with the detection or the removal of it.
    can I please buy a piece of your brain

  17. #67
    Join Date
    Aug 2012
    Location
    127.0.0.1
    Posts
    74
    Mentioned
    1 Post(s)
    Quoted
    26 Post(s)

    Default

    the bank of knowledge prevails

  18. #68
    Join Date
    Feb 2007
    Location
    Colorado, USA
    Posts
    3,716
    Mentioned
    51 Post(s)
    Quoted
    624 Post(s)

    Default

    Quote Originally Posted by pipilica View Post
    You will need rootkit to hide remote desktop because is big flag, i give process hide rootkit to whoever learn me how to compile the script Brandon provided or give me the already compiled version hiding virtual input, send PM or if you post it here i post rootkit here for everybody, i suspect code provided by Brandon have bugs
    vs doesn't auto link libraries you have to manually link to it
    download the windows SDK
    pretty basic shit
    now let's be serious here: do you even know what a rootkit is?


    Quote Originally Posted by Hoodz View Post
    can I please buy a piece of your brain
    I remember when his name was green
    The only true authority stems from knowledge, not from position.

    You can contact me via matrix protocol: @grats:grats.win or you can email me at the same domain, any user/email address.

  19. #69
    Join Date
    Jan 2012
    Posts
    12
    Mentioned
    0 Post(s)
    Quoted
    10 Post(s)

    Default

    Wondering if the actual mouse + original client + simba + aerolib (no smart in essence ) is used do they still set the flag as virtual?

    Or is it already fixed on SMART? What about keyboard inputs?

  20. #70
    Join Date
    Dec 2007
    Posts
    2,112
    Mentioned
    71 Post(s)
    Quoted
    580 Post(s)

    Default

    Quote Originally Posted by freepeeg View Post
    Wondering if the actual mouse + original client + simba + aerolib (no smart in essence ) is used do they still set the flag as virtual?

    Or is it already fixed on SMART? What about keyboard inputs?
    If you're using SMART, you don't have to worry about this. Events are injected straight into the client and does not touch the windows side of things.

    if you are using the official client / generating clicks through the use of SendMessage/SendInput/PostMessage then you do need to worry about this. However, it could be argued that it doesn't really matter what you use as the clients aren't installing/using the hooks atm.

    I personally believe that not using a 3rd party loader makes a massive difference though.

  21. #71
    Join Date
    Jan 2012
    Posts
    12
    Mentioned
    0 Post(s)
    Quoted
    10 Post(s)

    Default

    Quote Originally Posted by Kasi View Post
    If you're using SMART, you don't have to worry about this. Events are injected straight into the client and does not touch the windows side of things.

    if you are using the official client / generating clicks through the use of SendMessage/SendInput/PostMessage then you do need to worry about this. However, it could be argued that it doesn't really matter what you use as the clients aren't installing/using the hooks atm.

    I personally believe that not using a 3rd party loader makes a massive difference though.
    Do aerolibs human mouse functions use SendMessage/SendInput/PostMessage? The actual mouse does move on the screen but i guess it's faked by the functions mentioned?
    Last edited by freepeeg; 07-16-2017 at 11:28 AM.

  22. #72
    Join Date
    Dec 2007
    Posts
    2,112
    Mentioned
    71 Post(s)
    Quoted
    580 Post(s)

    Default

    Quote Originally Posted by freepeeg View Post
    Do aerolibs human mouse functions use SendMessage/SendInput/PostMessage?
    Yes.

  23. #73
    Join Date
    May 2017
    Posts
    22
    Mentioned
    1 Post(s)
    Quoted
    15 Post(s)

    Default

    Quote Originally Posted by Brandon View Post
    Lol.. If you know how to write a RootKit, you should have no problem compiling the code I posted.. and yes I am 100% sure it works and compiles.. After all, "Winternl.h" is a valid Windows Internal header as per:

    https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx


    Anyway guys, if it doesn't compile, your Mingw it outdated or bugged. I know for sure @Kasi; was able to compile it and confirmed it working with RS.


    EDIT: I will upload a compiled version later or upload the full project I guess..


    Compiles for me with Mingw on Windows 10 Pro: https://i.pictr.io/dTTQJ.png


    Post a compiled version to see if it works as you said , it does not compile no matter what i do, if loads winternl.h, gives cod errors

  24. #74
    Join Date
    Mar 2012
    Location
    127.0.0.1
    Posts
    3,383
    Mentioned
    95 Post(s)
    Quoted
    717 Post(s)

    Default

    Quote Originally Posted by pipilica View Post
    Post a compiled version to see if it works as you said , it does not compile no matter what i do, if loads winternl.h, gives cod errors
    sorry compiled versions of code aren't allowed on villavu. you'll have to compile it yourself.


  25. #75
    Join Date
    May 2017
    Posts
    22
    Mentioned
    1 Post(s)
    Quoted
    15 Post(s)

    Default

    At least the project , i get 11 errors on code , i m starting to think Brandon code is a joke to make us struggle whith it

Page 3 of 6 FirstFirst 12345 ... LastLast

Thread Information

Users Browsing this Thread

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •