1. Unpinning Importet .dll's


    ever wantet to unload a .dll from memory which was importet via the Import Table ? no , well i have , and turns out that windows prevents you from doing this , for security obiviously , as it would be pretty bad to unload a .dll by accident youd later need , but none the less i did some research and found out its more then possible if you preform a little magic , so here are the steps described which are required to do this.

    1) Unpinning dll's

    when windows Loads a .dll into your process space , the .dll is added to the PEB to be more exact in the PEB->LoaderData this Double linked list contains all the Modules Loaded into our image space , lets take a look what it looks like.

    typedef struct _PEB_LDR_DATA
    ULONG Length;
    BOOLEAN Initialized;
    PVOID SsHandle;
    LIST_ENTRY InLoadOrderModuleList;
    LIST_ENTRY InMemoryOrderModuleList;
    LIST_ENTRY InInitializationOrderModuleList;

    now you see it contains multiple things , for this article the only ones we are interestet in are the 3 LIST_ENTRY's , these 3 are pointers to double linked lists , each entry in the double linked lists contains 1

    typedef struct _LDR_MODULE {
    LIST_ENTRY InLoadOrderModuleList;
    LIST_ENTRY InMemoryOrderModuleList;
    LIST_ENTRY InInitializationOrderModuleList;
    PVOID BaseAddress; PVOID EntryPoint;
    ULONG SizeOfImage;
    ULONG Flags;
    SHORT LoadCount; SHORT TlsIndex;
    LIST_ENTRY HashTableEntry;
    ULONG TimeDateStamp;

    now all this , is various info about our .dll , but lets go back to when Windows Loads a .dll , Everytime you call LoadLibraryA("mydll.dll") windows will add a entry ( if it doesent excist already) and increase the LoadCount by 1 , now what happens when it loads a .dll via our ImportTable ?

    well more or less the same except it sets LoadCount to -1 , which means the .dll is pinned , and if this is the case windows will refuse to unload the .dll from memory.

    So how do we change this ? well take a look at this code:

    bool Mem_Manager::UnPinnAlldlls() {
    OutputDebugStringA("UnPinning All Dll's");
    DWORD PebAddr = 0;
    mov eax,DWORD PTR FS:[0x18]
    mov eax,DWORD PTR DS:[eax+0x30]
    mov PebAddr,eax
    PPEB Peb = (PPEB)PebAddr;
    _LDR_MODULE *peb_ldr_module;
    peb_ldr_module = (_LDR_MODULE*)Peb->Ldr->InLoadOrderModuleList.Flink;
    // Go through each modules one by one in their load order. DWORD First = 0; while((DWORD)peb_ldr_module != First)
    if(First == 0)
    First = (DWORD)peb_ldr_module;
    peb_ldr_module->LoadCount = 1;
    peb_ldr_module = (_LDR_MODULE*)peb_ldr_module->InLoadOrderModuleList.Flink;

    return true;

    what happens is:
    1. Gets Addr of PEB via __asm{} block
    2. Access PEB->PEB_LDR_DATA
    3. Get First Loaded Module via : Peb->Ldr->InLoadOrderModuleList.Flink
    4. Log Address of First Entry ( as its a Recursive Double linked list , so we stop once we been all the way round)
    5. Set RefCount of LoadedModule to 1 , so we can unload it with FreeLibrary
    6. Get Next LoadedModule Via: peb_ldr_module->InLoadOrderModuleList.Flink

    so once , these steps have been preformed , you can unload any .dll with a simpel call to FreeLibrary("dllName.dll") and it will be free'd from memory

    hope somebody found this interesting , else oh well
  2. Interesting Kernel32 Constant

    while i was doing some Research i stumpled on something which i found very interesting , i was attempting to Change the Location of Peb->ProcessHeap , which i did successfully , but the application still continued to use the Old Heap , which i dident want , so i startet digging and came across something ive never seen before.

    in the Api LocalAlloc i found that it keeps a Constant copy of Peb->ProcessHeap inside Kernel32 itself.

    7C809A63 FF35 A453887C PUSH DWORD PTR DS:[7C8853A4] -> contains copy of Peb->ProcessHeap

    so modifying the PEB only had limited success , but changeing this Value aswell . fixed my problem.

    i guess pretty clearly this Push ..should have been a call GetProcessHeap() instead , or somebody else has a view why windows would do like this ?


    Updated October 11th, 2008 at 07:39 by Arcane

  3. POP SS and Debuggers

    This little trick is very interesting, my first encounter with it was in a commercial protection, it left me wondering why a Push / Pop SS would implicit execute the next instruction without the Debugger knowing of it, i.e. raising a single-step exception, so I’ve decided to look into it and try to figure out why, and I believe I have found the explanation , but first let me show you how this technique can be used to detect debuggers relying on the Single Step flag for tracing.

    If a debugger executes something like this:

    PUSHFD -> push Efflags to Stack .

    debuggers such as Olly is kind enough to “shadow” itself, And clean the result produced by this instruction and removing the trap flag from the EFflags pushed to stack.

    But if it’s done like this:

    Push ss
    pop ss

    Olly will not remove the trap flag, which is very interesting and leaves it very vulnerable to trace detection. The Explanation seems to be pretty straight forward if you check out the Intel manuals and look up pop , you will find a passage similar to this :

    A POP SS instruction inhibits all interrupts, including the NMI interrupt, until after
    Execution of the next instruction. This action allows sequential execution of POP SS
    And MOV ESP, EBP instructions without the danger of having an invalid stack during
    An interrupt1. However, use of the LSS instruction is the preferred method of loading
    the SS and ESP registers.

    Well most of this can be boiled down to , if POP SS is executed , the CPU will prevent triggering of interrupts , as to avoid corruption of the stack. So why on earth is this affecting us when we are tracing using the single-step flag, well simply because when the Single-step flag is set , it triggers and interrupt in the CPU , but when a POP SS is executed it won’t trigger interrupts before it has executed the next instruction after it , and thus olly will never get a single-step exception for the PUSHFD and won’t know it has been executed , and thus wont clean out the trap-flag and leave us vulnerable to detection.

    Circumventing this trick , is tricky since simply patching it out is easy , but if implementet correctly it can prevent tracing of your code very effectively and be a pain in the ass.

    Comments and suggestions , are always welcome

    Updated August 21st, 2008 at 15:16 by Arcane