[Tutorial]Reading Modules (DLLS) and DLL explanations

Results 1 to 7 of 7
  1. #1
    Enthusiast gazettefan is offline
    MemberRank
    Feb 2009 Join Date
    49Posts

    [Tutorial]Reading Modules (DLLS) and DLL explanations

    Hello agains folks,

    Rotana asked in the other topic about reading dll's so I'll show how to do it.

    To start our function is:
    Code:
    void ReadModules()
    {
        HANDLE snap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0);
        PROCESSENTRY32 Processie;
        memset(&Processie,0,sizeof(Processie));
        Processie.dwSize = sizeof(Processie);
    	while(Process32Next(snap,&Processie))
        {         
    		HANDLE snapmodules = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE,0);
    		MODULEENTRY32 ModuleEntrie;
    			memset(&ModuleEntrie,0,sizeof(ModuleEntrie));
    			ModuleEntrie.dwSize = sizeof(ModuleEntrie);
    				while(Module32Next(snapmodules,&ModuleEntrie))
    				{
    					printf("\nAttached Module (Dll): %s",ModuleEntrie.szModule);      
    				}
    			CloseHandle(snapmodules);
        }
        CloseHandle(snap);  
    }
    It'll snap all modules inside of the process, and show all attached dll's to it.

    Since we're talking gunz->antihack we should check if there is a dll we don't want running into our process using
    Code:
    if(strcmp(ModuleEntrie.szModule,"ourdll.dll") && strcmp(ModuleEntrie.szModule,"kernel32.dll") != 0)
    EndApplication();
    
    (...)
    If it finds a dll that is not allowed into the list it'll kill the process, example:

    You have all dll's from gunz dbghelp.dll, fmod.dll, gdiplus.dll, kernel32.dll, ntdll.dll, user32.dll (...) etcetc

    Check if the module read is not one of their names, if not kill gunz, but wait what if the guy names his dll to an allowed one?

    Ok so we already know that that function sucks, what will be doing in this case is to check the base address from the dll.

    The base address is a signature, umm, like md5, but you can't check the md5 of a running on you process, oh wait YOU CAN!

    The problem is, dll's used in another version of windows may have different signatures, but not their base address, so that is why we will be using it.

    To retrieve the base address of a module simply use
    Code:
    void ReadModules()
    {
        HANDLE snap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0);
        PROCESSENTRY32 Processie;
        memset(&Processie,0,sizeof(Processie));
        Processie.dwSize = sizeof(Processie);
    	while(Process32Next(snap,&Processie))
        {         
    		HANDLE snapmodules = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE,0);
    		MODULEENTRY32 ModuleEntrie;
    			memset(&ModuleEntrie,0,sizeof(ModuleEntrie));
    			ModuleEntrie.dwSize = sizeof(ModuleEntrie);
    				while(Module32Next(snapmodules,&ModuleEntrie))
    				{
    					printf("\nAttached Module (Dll): %s",ModuleEntrie.szModule);  
    printf("\n Base Address %x",ModuleEntrie.modBaseAddr);    
    				}
    			CloseHandle(snapmodules);
        }
        CloseHandle(snap);  
    }
    And it'll display the base address of all dll's inside your process.
    Now we can use a better function
    Code:
    unsigned long kerneladdress = 0x7c000000; //not real ones just for tutorial
    unsigned long ntdlladdress = 0x8b000000; 
    
    (...)
    if(ModuleEntrie.modBaseAddr != kerneladdress || ModuleEntrie.modBaseAddr != ntdlladdress)
      EndApplication();
    (...)
    We have just checked the base address of the dll running inside the process, if not one of our allowed base address one, we kill the application.

    Oh wait, but there is one more problem, C++ forbids the comparison between pointer and integer, so we have to come up with another function

    We will first declare a HANDLE (which is void*) and copy our data into it look

    Code:
    HANDLE kerneladdress; // which can be also represented by void* kerneladdress;
    memcpy(&kerneladdress,"\x00\x00\x80\x7c",4);
    
    (...)
    if(ModuleEntrie.modBaseAddr != kerneladdress)
    EndApplication();
    (...)
    Now we have a valid function to compare their base address.

    Well it's simply it! Use it however you want, If you have any idea of how can I improve this I will be glad to hear, also if you have seen I did any mistake please tell me.

    Here is the full source avaliable for you to do whatever you want with it. (also the complete project below just open Project1.dev)
    ATTENTION: COMPILE WITH DEV-CPP (GCC COMPILER)

    Code:
    #include <Windows.h>
    #include <stdio.h>
    #include <TlHelp32.h>
    
    void ReadModules()
    {
         HANDLE kerneladdress;
         memcpy(&kerneladdress,"\x00\x00\x80\x7c",4);
    
        HANDLE snap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS,0);
        PROCESSENTRY32 Processie;
        memset(&Processie,0,sizeof(Processie));
        Processie.dwSize = sizeof(Processie);
    	while(Process32Next(snap,&Processie))
        {         
          if(strcmp("Project1.exe",Processie.szExeFile) == 0) //show only the dll's of our process
          {
    		HANDLE snapmodules = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE,0);
    		MODULEENTRY32 ModuleEntrie;
    			memset(&ModuleEntrie,0,sizeof(ModuleEntrie));
    			ModuleEntrie.dwSize = sizeof(ModuleEntrie);
    				while(Module32Next(snapmodules,&ModuleEntrie))
    				{
    					printf("\nAttached Module (Dll): %s",ModuleEntrie.szModule);    
                        printf("\nBase address : %x,",ModuleEntrie.modBaseAddr);  
                          if(kerneladdress == ModuleEntrie.modBaseAddr)
                         {
                            printf("Wow you have found kernel dll running in here!");
                          }
    				}
    			CloseHandle(snapmodules);
            }
        }
        CloseHandle(snap);  
    }
    
    
    int main(int argc, char *argv[])
    {
    	SetConsoleTitle("ReadModules");
    		ReadModules();
    
    	system("pause>nul");
    
    return 0;
    }
    Have a good time guys
    Attached Files Attached Files


  2. #2
    Account Upgraded | Title Enabled! TheCodeOfGunz is offline
    MemberRank
    Oct 2010 Join Date
    PhilippinesLocation
    532Posts

    Re: [Tutorial]Reading Modules (DLLS) and DLL explanations

    Thanks again man this guy is friendly newbie <3.

  3. #3
    Apprentice Siloow is offline
    MemberRank
    Jan 2009 Join Date
    15Posts

    Re: [Tutorial]Reading Modules (DLLS) and DLL explanations

    Indeed, thanks!

  4. #4
    The beer?? Its here !!! Rotana is offline
    MemberRank
    Jan 2007 Join Date
    The NetherlandsLocation
    1,733Posts

    Re: [Tutorial]Reading Modules (DLLS) and DLL explanations

    Nice post,

    I didn't ask for this, but just notice on your previous post that it won't check dll's.

    Anyways keep on the good work.

    Offtopic. Do you have some knowledge of mrs files?
    I can use some help with mine mrs class.
    Compile / Decompile and updating mrs files.

  5. #5
    Slothstronaut Justice For All is offline
    MemberRank
    Aug 2011 Join Date
    Almost thereLocation
    3,254Posts

    Re: [Tutorial]Reading Modules (DLLS) and DLL explanations

    Nice man, very nice, you're very generous for creating these tutorials to help people out.

  6. #6
    amPerl savetherobots is offline
    MemberRank
    Apr 2010 Join Date
    214Posts

    Re: [Tutorial]Reading Modules (DLLS) and DLL explanations

    This is very useful for aspiring programmers, I salute you for trying to help this dying community :)

  7. #7
    Just Me iceman4154 is offline
    MemberRank
    Oct 2007 Join Date
    Columbus, OhioLocation
    217Posts

    Re: [Tutorial]Reading Modules (DLLS) and DLL explanations

    Good tutorial. :)

    You could obfuscate the way you are loading your dll then encrypt your exe.You will need a server side antihack as well though. A knowledgeable hacker will attack your server more than other clients. You could completely change the packet encryption algorithm (this would need to be done in MatchServer.exe, Locator.exe, MatchAgent.exe and your client exe). You could create an auto-ban function, so when people try to inject "malicious" dll's it will ban the logged in account (this would have to be done by hooking the login post function, so you know the current account information). Another good idea would be a "heart beat" packet that tells the server that the client side of the antihack is operational (if client misses three "beats" either close gunz or ban/warn account).

    Honestly the only way to completely protect the client is to work at a kernel level by making a ring 0 driver (really not a lot of info on the internet about how to make these, lol).



Advertisement