ManualMap - A manual mapper for x86 modules

[Cypher]

[~Unknown~]

..pic

I think you scared him off... lol.... xD

[Cypher]

I was excited somebody else was working on a public mapper. Now I'm sad.

[DarkLinux]

Well it just does not solve all my problems... Drivers would be the next step...

[sitnspinlock]

Well it just does not solve all my problems... Drivers would be the next step...

wut is your problem son

[DarkLinux]

Manual mapping is the act of allocating a virtual block in the target process, then writing an image file to it, mapped in the same fashion as the native loader. The only benefits you have are, no peb ldr data entry, and no mapped section object. But you could still find the region with virtual queries. Unless you hooked ntqueryvirtualmemory. But then blizz could map the syscall id and call it manually, game over. Therefor rootkit/drivers

[Cypher]

Manual mapping is the act of allocating a virtual block in the target process, then writing an image file to it, mapped in the same fashion as the native loader. The only benefits you have are, no peb ldr data entry, and no mapped section object. But you could still find the region with virtual queries. Unless you hooked ntqueryvirtualmemory. But then blizz could map the syscall id and call it manually, game over. Therefor rootkit/drivers

"But then blizz could map the syscall id and call it manually, game over." <-- Similar to how Blizzard detected LuaNinja, so there's certainly precedent.

Manual mapping isn't really useful for public cheats, but it's fun to try and write one! (More useful in packers etc)

[DarkLinux]

More useful in packers? What is a packer... I guess I'm not up to date with the tech lingo.

I would love to know what you think about drivers and how you would implement something like manual mapping with drivers. I know they are also not the best solution. As glider used drivers but became detected.

[Cypher]

More useful in packers? What is a packer... I guess I'm not up to date with the tech lingo.

I would love to know what you think about drivers and how you would implement something like manual mapping with drivers. I know they are also not the best solution. As glider used drivers but became detected.

A packer as in a binary protector/packer. Something like UPX that takes a binary and 'packs' it somehow (either to compress it, or obfuscate it, or both).

Anyway, writing a driver to cloak arbitrary memory regions is hard, especially in multi-core/multi-processor systems. It's not something I've investigated in a long long time (since about the time Glider was just getting popular, and a friend and I were toying with the idea of writing an injected bot protected by a memory cloaking driver), so I'm definitely not the person to ask for up-to-date information on how one might go about doing that.

People have certainly tried implementing such rootkits, but I don't know of any off the top of my head that are much more than proof-of-concepts developed for presentations or white-papers. I can't even think of any public attempts to write one that worked on x64 and/or multi-processor/core systems (at least not without a gigantic perf hit).

Sorry I can't be of any help. If you do try it though be sure to start a thread here recording your progress, it'd be quite interesting.

[sitnspinlock]

edit: first post was probably hard to understand, ill try harder.

maybe you can as cypher said, start a project and post it here. I can help you because i have done this on multi-cpu platforms already.

these steps aren't going to be great in detail, just the general idea of what you need to do.

-determine cpu topology and number of logical processors (use the windows provided api's or CPUID. i personally used and prefer the latter)

-determine a method to flush the L2 cache on all logical cpu's after your modification process.

-find and locate the VAD of your target process

-walk the VAD avl tree (recursion) and unlink the targeted memory region.

-if this memory gets paged out, the page fault handler uses the VAD of the current task for the page-in process. if its not there - BSOD

-add the pages to the working set with VirtualLock or lock them from your driver, but beware that a process terminating with locked pages also = BSOD. so register a callback?

you can pm me if you need help.

[DarthTon]

You can actually disable DEP for process in run-time. Just set only these flags in KPOCESS:

Flags.ExecuteEnable		
Flags.ImageDispatchEnable	
Flags.ExecuteDispatchEnable

And voila! you can use SEH handlers out of image.

[sitnspinlock]

You can actually disable DEP for process in run-time. Just set only these flags in KPOCESS:

Flags.ExecuteEnable		
Flags.ImageDispatchEnable	
Flags.ExecuteDispatchEnable

And voila! you can use SEH handlers out of image.

yeh but i think their idea was to not implement a driver just for that single purpose of changing kexecute_flags.

assuming no cert, they'd have to ask their users to install a driver with their machine booted in test mode.

to that extent, some types of DRM know whether or not the system was booted with those flags and fail to work. (because CI.dll initializes in a different manner based on testsigning or /debug)

[DarthTon]

Hm, using only usermode stuff you can write this function into target process

typedef _EXCEPTION_DISPOSITION(__cdecl *_pexcept_handler)
    (
        _EXCEPTION_RECORD *ExceptionRecord,
        void * EstablisherFrame,
        _CONTEXT *ContextRecord,
        void * DispatcherContext
    );

LONG CALLBACK VectoredHandler32( _In_ PEXCEPTION_POINTERS ExceptionInfo )
{
    EXCEPTION_REGISTRATION_RECORD  *pFs    = (EXCEPTION_REGISTRATION_RECORD*)__readfsdword(0);
    EXCEPTION_DISPOSITION            res    = ExceptionContinueSearch;

    // Prevent CRT from calling handlers in chain with EH_UNWINDING
    for(; res == ExceptionContinueSearch && pFs && pFs != (EXCEPTION_REGISTRATION_RECORD*)0xffffffff; pFs = pFs->Next, __writefsdword(0, (DWORD)pFs))
    {
        ExceptionInfo->ExceptionRecord->ExceptionFlags &= ~EXCEPTION_UNWIND;

        if(pFs->Handler)
        {
            // Last frame contains special handler with __stdcall convention
            if(pFs->Next != (EXCEPTION_REGISTRATION_RECORD*)0xffffffff)
                res = ((_pexcept_handler)pFs->Handler)(ExceptionInfo->ExceptionRecord, pFs, ExceptionInfo->ContextRecord, NULL);
            else
                res = pFs->Handler(ExceptionInfo->ExceptionRecord, pFs, ExceptionInfo->ContextRecord, NULL);

            // Unwind stack properly
            if(res == ExceptionContinueSearch)
            {
                ExceptionInfo->ExceptionRecord->ExceptionFlags |= EXCEPTION_UNWIND;

                if(pFs->Next != (EXCEPTION_REGISTRATION_RECORD*)0xffffffff)
                    res = ((_pexcept_handler)pFs->Handler)(ExceptionInfo->ExceptionRecord, pFs, ExceptionInfo->ContextRecord, NULL);
                else
                    res = pFs->Handler(ExceptionInfo->ExceptionRecord, pFs, ExceptionInfo->ContextRecord, NULL);
            }
        }
    }

    // We are screwed if got here
    return EXCEPTION_CONTINUE_SEARCH;
} 

And execute "AddVectoredExceptionHandler(0, &VectoredHandler32)" there. This will redirect to first SEH frame handler, no matter where it resides.

Edit: Should now work properly for nested SEH frames, C++ EHa and unwind C++ stack.

[Cypher]

Hm, using only usermode stuff you can write this function into target process

typedef _EXCEPTION_DISPOSITION(__cdecl *_pexcept_handler)
    (
        _EXCEPTION_RECORD *ExceptionRecord,
        void * EstablisherFrame,
        _CONTEXT *ContextRecord,
        void * DispatcherContext
    );

LONG CALLBACK VectoredHandler32( _In_ PEXCEPTION_POINTERS ExceptionInfo )
{
    EXCEPTION_REGISTRATION_RECORD  *pFs    = (EXCEPTION_REGISTRATION_RECORD*)__readfsdword(0);
    EXCEPTION_DISPOSITION            res    = ExceptionContinueSearch;

    // Prevent CRT from calling handlers in chain with EH_UNWINDING
    for(; res == ExceptionContinueSearch && pFs && pFs != (EXCEPTION_REGISTRATION_RECORD*)0xffffffff; pFs = pFs->Next, __writefsdword(0, (DWORD)pFs))
    {
        if(pFs->Handler)
        {
            // Last frame contains special handler with __stdcall convention
            if(pFs->Next != (EXCEPTION_REGISTRATION_RECORD*)0xffffffff)
                res = ((_pexcept_handler)pFs->Handler)(ExceptionInfo->ExceptionRecord, pFs, ExceptionInfo->ContextRecord, NULL);
            else
                res = pFs->Handler(ExceptionInfo->ExceptionRecord, pFs, ExceptionInfo->ContextRecord, NULL);
        }
    }

    return EXCEPTION_CONTINUE_SEARCH;
} 

And execute "AddVectoredExceptionHandler(0, &VectoredHandler32)" there. This will redirect to first SEH frame handler, no matter where it resides.

Edit: Should now work properly for nested SEH frames.

Neat! I'm curious, does that also cope with C++EH? I seem to remember issues caused by the CRT doing its own extra checks etc on C++EH.

[DarthTon]

My code does seem to work for C++EH. But if exception isn't caught by first frame, c++ stack won't be unwinded properly (no destructors will be called). For such cases manual unwinding is needed.