Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Kernel32.dll and dllmain

Kernel32.dll and dllmain

Scheduled Pinned Locked Moved C / C++ / MFC
questionperformance
3 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • H Offline
    H Offline
    hph
    wrote on last edited by
    #1

    hello, as you know, kernel32.dll is loaded at windows startup and remains in memory until reboot or shutdown. Furthermore every .exe and .dll which is going to be executed uses the kernel32.dll which means that it is loaded into the adresse space of the calling process. So far so good! At the moment a dll is loaded into memory its dllmain function should recieve 3 parameters whereas one of those descripes wheather the dll is attached by a process/thread or detached. But in my understanding, a system dll which is already loaded (at startup like kernel32.dll), doesn't get a notification if it is loaded or unloaded into/from a process' adresse space because it is already in the memory! Now is that true or false and how can i examine that ? Thanks in advance!

    A 1 Reply Last reply
    0
    • H hph

      hello, as you know, kernel32.dll is loaded at windows startup and remains in memory until reboot or shutdown. Furthermore every .exe and .dll which is going to be executed uses the kernel32.dll which means that it is loaded into the adresse space of the calling process. So far so good! At the moment a dll is loaded into memory its dllmain function should recieve 3 parameters whereas one of those descripes wheather the dll is attached by a process/thread or detached. But in my understanding, a system dll which is already loaded (at startup like kernel32.dll), doesn't get a notification if it is loaded or unloaded into/from a process' adresse space because it is already in the memory! Now is that true or false and how can i examine that ? Thanks in advance!

      A Offline
      A Offline
      Antti Keskinen
      wrote on last edited by
      #2

      It doesn't sound logical The Kernel32.dll behaves just like any other DLL would. Here is a link to the MSDN site[^] depicting the different reasons for call. According to the MSDN: It is safe to call other functions in Kernel32.dll, because this DLL is guaranteed to be loaded in the process address space when the entry-point function is called. Following this logic, the Kernel32.dll's entry-point function gets called each time it is loaded into the process' address space. For each process that starts, this DLL provides the basic system services. According to the "Virtual Machine" thinking, each process runs seperately, and believes that it is the only process in the system. Thus, each process needs to access basic system services, and they are provided by this DLL. You can use the Dependency Walker to see what DLL's your executable loads when it is started (that is, what executables it needs in order to start up). You cannot track the usability of Kernel32.dll in the whole process, because it gets loaded into the system core memory area. Tampering with this area easily causes an access violation or a machine-wide crash. In conclusion: the Kernel32.dll is active in the system code memory area. From there, it gets loaded into the address space of each process that uses it (all Win32 programs). The entry-point function gets called each time. If you want to test this yourself, create a system-wide service DLL and debug-run it with RunDll32.exe, that loads it into the memory. Now, create a set of new application that load this DLL. Then track it's DllMain-calling sequences by putting a breakpoint there. Not sure if this works though, no guarantees given... -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.

      H 1 Reply Last reply
      0
      • A Antti Keskinen

        It doesn't sound logical The Kernel32.dll behaves just like any other DLL would. Here is a link to the MSDN site[^] depicting the different reasons for call. According to the MSDN: It is safe to call other functions in Kernel32.dll, because this DLL is guaranteed to be loaded in the process address space when the entry-point function is called. Following this logic, the Kernel32.dll's entry-point function gets called each time it is loaded into the process' address space. For each process that starts, this DLL provides the basic system services. According to the "Virtual Machine" thinking, each process runs seperately, and believes that it is the only process in the system. Thus, each process needs to access basic system services, and they are provided by this DLL. You can use the Dependency Walker to see what DLL's your executable loads when it is started (that is, what executables it needs in order to start up). You cannot track the usability of Kernel32.dll in the whole process, because it gets loaded into the system core memory area. Tampering with this area easily causes an access violation or a machine-wide crash. In conclusion: the Kernel32.dll is active in the system code memory area. From there, it gets loaded into the address space of each process that uses it (all Win32 programs). The entry-point function gets called each time. If you want to test this yourself, create a system-wide service DLL and debug-run it with RunDll32.exe, that loads it into the memory. Now, create a set of new application that load this DLL. Then track it's DllMain-calling sequences by putting a breakpoint there. Not sure if this works though, no guarantees given... -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.

        H Offline
        H Offline
        hph
        wrote on last edited by
        #3

        Thanks for your help! Actually i hoped that i am right, but i have expected that! What i try to do is the following: I have written a patch which injects some code into the kernel32.dll (Win98) which should load a specific .dll evertime the kernel32.dll is loaded. I have switched the original kernel32.dll with a boot disk. To get a little bit more specific: i have changed the adresse of the entry-point function, so it jumps to my code, where a specific dll should be loaded, and then jump back to the "real" entry-point-function! The strange but funny thing is, that windows98 starts up as if there is no manipulation in its kernel32.dll! I also have changed the code into something that makes no sense to see what happens, and yes, after that i have gotten a beautiful blue screen! The code to load the additional dll within the kernel32.dll is absolutely correct (that's what i think it is)! I don't have an idea why i doesn't load the dll! Any ideas ? Thanks in advance!

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups